DeepSeek V4.1 Flash Hands-On: 65 Million Tokens Burned for Under $1

A Surprising Result From DeepSeek

DeepSeek^Ad has delivered another unexpected answer. The newly released V4.1 Flash is not only faster and more capable — most importantly, it's cheaper. In one real-world test, a developer ran it for 89 minutes, consumed nearly 65 million tokens to build a complete application, and spent less than $1 in total. Behind this lies a suite of architectural innovations, not just parameter scaling.

One Extreme Real-World Test

To stress-test this model, the tester used DeepSeek's own runtime framework, DeepSeek Harness. What makes this framework interesting is its "everything is a plugin" philosophy: you can let the model modify itself, with plugins taking effect dynamically at runtime — changing the UI, logic, and features — and it actually runs.

The task was far from trivial: building a LLM watermarking web application. This is a technology for determining whether a given piece of text was generated by a large language model. The tester submitted a relatively complex prompt, the model ran for a full 89 minutes, and consumed nearly 65 million tokens.

The results were impressive: the final application featured a polished UI and complete functionality. It loaded a small LLM, highlighted different tokens in red and green during text generation, and the watermarking mechanism worked correctly. Total cost: under $1. That kind of price-to-performance ratio is nearly unmatched in today's model ecosystem.

Causal Encoder-Decoder: The Secret to Cheap Inference

V4.1 Flash is a multimodal Mixture of Experts (MoE) model with 552 billion backbone parameters, supporting context lengths up to 1 million tokens, with native image and text processing. But what truly sets it apart is its architectural design.

DeepSeek V4.1 Flash uses a Causal Encoder-Decoder (CED) architecture: a 40-layer transformer where the first 20 layers are a causal encoder and the last 20 are a decoder. This differs fundamentally from the classic GPT-2-style architecture, where all layers are decoders and every token passes through all 40 layers.

The key insight here is that input and output token counts are often extremely asymmetric. In a coding scenario, the model reads large code files but only generates a small snippet; in a research scenario, it reads massive documents but condenses the result into a brief answer. Input vastly outnumbers output.

The CED architecture targets exactly this: the encoder (half the model) only runs when processing input tokens, and the decoder (the other half) only runs when predicting outputs. This means the input phase only activates half the model's weights, significantly reducing compute and resource requirements.

Mixture of Experts (MoE) is another foundation for understanding V4.1 Flash's efficiency. Unlike dense models, MoE models replace feed-forward network layers with multiple "expert" sub-networks, with a gating router dynamically selecting a small number of experts to handle each token at inference time rather than activating all parameters. This means the model has 552 billion total parameters, but only a fraction are involved in any given token's computation — roughly 8 billion during prefill and 16 billion during decoding. This "large but sparse" design allows the model to retain enormous knowledge capacity while compressing per-inference compute to levels comparable to much smaller models — one of the mainstream approaches to cost reduction in large-scale language models today.

KV Cache Slimming: From 400KB to Under 1KB

Another clever aspect of the CED architecture lies in how it handles the KV cache.

In a traditional architecture, every layer maintains its own independent KV cache — after a token passes through a layer, its hidden state is projected into K and V vectors for subsequent tokens to use during prediction. In the CED architecture, the decoder's global KV cache no longer comes from each layer's own hidden states, but is projected from the final layer of the encoder.

In simple terms: when predicting the 10th token, you need the KV cache from the previous 9 tokens. In a traditional architecture, this cache is distributed across all layers. In CED, it's retained only in the encoder portion, and the decoder reuses this cache with almost no loss in quality.

This yields dramatic memory savings. The numbers the tester cited are striking: in the DeepSeek V1 era, each incremental token required nearly 400KB of KV cache. V3.2 brought that down to 48KB. V4.1 Flash requires less than 1KB per token — approximately 890 bytes.

What does this mean in practice? Filling the full 1-million-token context window requires only about 1GB of memory. By comparison, another recent model requires 52KB per token, meaning the same context window would consume 52GB.

For model providers, this is a decisive difference. If a GPU rack has 1TB of VRAM, the size of each user's KV cache directly determines how many users can be served simultaneously — and users equal token sales, which equals revenue versus cost. What looks like a "small" architectural tweak translates into a massive cost advantage. Additionally, the model activates only ~8 billion parameters per token during prefill and ~16 billion during decoding.

KV Cache is the core source of memory overhead in Transformer inference. During autoregressive generation, the model must "look back" at all previous tokens' attention information each time it generates a new token. To avoid redundant computation, the Key and Value vectors produced at every layer for every token are cached. In a traditional N-layer model, you accumulate N sets of KV caches — the longer the context and the more layers, the greater the VRAM consumption. The CED architecture breaks the "layers × tokens" linear growth pattern by having the decoder uniformly reuse the KV representations from the encoder's final layer output. Memory overhead is determined primarily by the number of encoder layers rather than all layers — this is the structural reason per-token cache drops from hundreds of KB to under 1KB.

Ingram Conditional Memory: Knowledge Without Permanent VRAM Residency

V4.1 Flash also introduces a mechanism called Ingram. The model's 552 billion are "backbone parameters," which implies there are non-backbone parameters as well — specifically, 196 billion parameters in the Ingram conditional memory.

Traditional LLMs like GPT-2 have only a single embedding layer at the beginning of the model, mapping token IDs to embedding vectors. Ingram adds additional embedding vectors in subsequent layers as well. The cleverest part: during inference, through deterministic addressing, these embeddings can be prefetched from host memory. That is, the system can know which embedding vectors will be needed before they are actually required.

This allows Ingram parameters to enrich the model's knowledge and capabilities without permanently occupying precious GPU VRAM — they can be offloaded to host memory, representing yet another substantial resource saving.

Deterministic addressing is the technical key that enables Ingram's prefetching capability. In traditional attention mechanisms, the model must "see" the full context before deciding which knowledge representations to activate — this is dynamic and non-deterministic, making advance scheduling impossible. Ingram's design means that given an input token sequence, the additional embedding vectors required can be deterministically computed before the main computation begins. This allows the system to asynchronously prefetch the next batch of embeddings from host memory (RAM) or disk into the device buffer while the GPU is still executing the previous batch. This CPU-GPU cooperative async pipeline lets nearly 200 billion parameters' worth of knowledge participate in inference on demand, without occupying precious HBM VRAM — an important engineering approach for deploying ultra-large models in resource-constrained environments.

MIT License and the Signal of a Price War

Multiple service providers went live with the model shortly after its release. Pricing: $0.15 per million input tokens, $0.60 per million output tokens, with cached input tokens priced at less than $0.01 per million.

More critically, it uses the MIT license — anyone can freely host and use it without restriction. This contrasts with models like Kimi K3, which are open-weight but still require a commercial agreement with the originating company for large-scale deployment (above certain revenue or user count thresholds).

On coding performance, the tester cited SWE-bench-style benchmark data where V4.1 Flash scored 74.2, placing it in the same tier as Opus 5 and GPT-4.5. Yet those closed-source models cost more than 10x as much. While benchmark scores don't perfectly translate to real-world coding ability, they're a reasonable reference point. When a model that costs 10x less achieves comparable scores, the justification for paying a premium is becoming increasingly hard to make.

Frontier Capability Is Moving Toward Self-Hostability

Beyond this specific model, the tester identified two broader signals that make this release particularly exciting.

First, we're entering an era where a class of models is approaching frontier-level performance on tasks like coding and knowledge work — and they can be self-hosted. Whether you're renting GPUs or running consumer hardware, you no longer need to depend on access to closed-source model providers.

Second, this is extremely healthy for market competition. When models this powerful appear at this price point, other vendors are forced to lower prices too. As consumers, this means we get the same richness of intelligence and capability with less memory and less compute.

Perhaps in the not-too-distant future, we'll be able to run a genuinely capable model for coding and knowledge work on an ordinary Mac or PC, and it'll just work — and that's the most exciting part of all.