## What DeepSeek V4.1 Flash actually costs to run
**A million tokens of context costs 0.87 GiB.** That is the whole story, and it is the first time we have run these numbers and found the context column boring. DeepSeek publishes the figure directly in the model card: the global KV cache is **890 bytes per token**, which they state is roughly a quarter of DeepSeek V4 Flash.
Put that against what a million tokens costs on models people actually run today. Every row is our [model catalogue](/what-llm-can-i-run/) computing the same thing, at an fp16 cache where the architecture uses one. **The V4.1 Flash row is DeepSeek’s own 890 bytes per token carried straight through**, not something we derived:
| Model | KV cache at 1M tokens | At 128K |
|—|—|—|
| DeepSeek V4.1 Flash | 0.87 GiB | 0.11 GiB |
| DeepSeek V4 Flash | 3.70 GiB | 0.47 GiB |
| GLM 5.3 Flash | 13.96 GiB | 1.87 GiB |
| Qwen3.8 27B | 64.15 GiB | 8.02 GiB |
| GLM 5.3 | 93.00 GiB | 11.63 GiB |
| Llama 3.1 70B | 320.00 GiB | 40.00 GiB |
GLM 5.3 needs 93 GiB of cache to hold what V4.1 Flash holds in 0.87. Those two are the fairest pair in the table, because they are almost the same size once you count everything, and the section below shows why.
One caveat on the Llama row, and it is ours to make rather than yours to spot. DeepSeek’s 890 bytes per token is a natively FP4 cache. Our Llama figure is fp16, which is what you actually get by default, so the raw 368x gap is part format and part architecture. Put Llama’s cache at FP4 too and it would be around 80 GiB, still roughly 90 times more than V4.1 Flash for the same window. The architecture is doing most of the work, not the number format. Llama 3.1 70B is also a 128K model natively, so its 1M row is a thought experiment; the ratio at 128K is identical.
So the interesting thing about this release is an inversion. For three years the rule on this site has been that long context is what kills you: the weights fit, then you open the context slider and the card runs out. Here the weights are the entire problem and the context is close to free.
## The weights are the problem, and they are a large one
The published release is 510.30 GB across 48 shards, which we measured from the repository rather than deriving from the parameter count. It ships as FP8 with the experts at FP4, so this is not a full precision file waiting to be quantized down. It is already mixed precision on arrival.
**UPDATED 2026-09-10, the day this published.** An earlier version of this section said nothing you own runs it. That was wrong within hours, and it was a predictable kind of wrong.
**People are running it on desk hardware, and the Engram table is why.** The 203 GB of Engram is a sparse lookup, so it does not have to be resident. Leave it on NVMe and what must sit in memory is roughly 307 GB, not 510.30.
Three independent reports on release day:
– **@Tech2Wild, 4x DGX Spark at TP4**, MXFP4, vLLM with DSpark and CUDA graphs, keeping the Engram tables on disk. He reports 77.2 tok/s peak single stream, 52 on code in his benchmark and 72 on a warm code run, 23 on prose, 214 aggregate at six streams, and a 1.03M token KV pool with 1M context proven. Also a hardware note worth repeating: 5 tok/s eager, 41 with CUDA graphs and DSpark, 77 after clearing two GPUs stuck below 1 GHz, which needed the Spark unplugged because a reboot did not clear it.
– **@MiaAI_lab, 3x DGX Spark**, running, no figures published yet.
– **@0xSero, 4x RTX PRO 6000**, with the n-gram table offloaded to NVMe.
**It runs, and it is not fast.** @MiaAI_lab reports **17 tok/s on prose** with the official FP8 build on three Sparks. @Tech2Wild reports **23 on prose** on four with MXFP4, alongside 77.2 peak on counting and 72 on a warm code run.
**Do not read 17 against 23 as the price of offloading.** Both rigs offload and neither has a choice: three Sparks is a 384 GB pool against 510.30 GB of weights, and four is 512 GB, which clears the weights by 1.7 GB and so leaves nothing for activations or cache. What separates those two numbers is box count, quantization and stack.
**The stack looks like the largest term of the three.** On one machine and one model, @Tech2Wild reports **5 tok/s in eager mode, 41 with CUDA graphs and DSpark, and 77 after clearing two GPUs stuck below 1 GHz**, which needed the Spark unplugged because a reboot did not clear it. Nobody has published the measurement that would actually price the offload, which is the same rig with the table resident against the table on disk, and on a Spark that cannot be run at all.
None of these are ours and none are reproduced by us. **What is fair to say is the narrower thing: the weights do not fit a single machine anybody reading this owns**, and a three or four box desk cluster with fast storage is the current floor. Two RTX 5090s give you 64 GB. One DGX Spark gives you 128. A single H200 gives you 141. Fully resident, without offload, you are still looking at about seven H100s or four H200s.
A GGUF conversion has already started and it does not help yet. `vcruz305/DeepSeek-V4.1-Flash-GGUF` appeared the morning of release with three of seven Q2_K parts uploaded. **llama.cpp support is still an open draft pull request**, so the file is being built ahead of anything that can load it. That is worth watching rather than waiting on, because a new attention layout is not a repackaging job.
Set against its predecessor the trade is stark. Our [DGX Spark sizing for V4 Flash](/deepseek-v4-flash-dgx-spark/) puts that model at 166.9 GB. **V4.1 Flash cut the cache to a quarter and tripled the download.** That is the bargain on offer, and whether it is a good one depends entirely on how long your sessions run.
That makes this a rented hardware model for almost everybody, in the same bracket as the 1.6T V4 Pro and GLM 5.3. Our [GPU rental comparison](/rent-a-gpu-for-ai/) covers what an hour of that costs.
The 0.87 GiB matters anyway, and here is why. On a rented multi GPU box, the KV cache is what decides how many concurrent users you can serve and how long each conversation can get before you evict it. A model that holds a million token conversation in under a gigabyte can hold a great many of them at once. DeepSeek’s own framing in the model card is agentic workloads, where a session accumulates context for hours, and that is the workload the cache size actually governs.
## Where it sits in the size class, and it breaks the pattern
This is the part that surprised us, and it took a second look to get right.
**The 552B figure is the backbone only.** DeepSeek lists a further 196B of Engram conditional memory, a table read sparsely by token lookup rather than run through on every forward pass. Count it and the model stores about 748B parameters, which is not between GLM 5.3 Flash and GLM 5.3 at all. It is level with GLM 5.3.
The file listing says the same thing. Shards 47 and 48 are **101.54 GB each**, 203.07 GB together and 39.8% of the download, while the other 46 shards total 307.22 GB, which is about what a 552B backbone costs at FP8 with FP4 experts. The Engram table is those two shards.
So the comparison is not a smaller model punching up. It is two models of the same size, one of which needs 107 times less cache:
| Model | Parameters | Active per token | KV at 1M |
|—|—|—|—|
| GLM 5.3 Flash | 320B | 18B | 13.96 GiB |
| DeepSeek V4.1 Flash | 552B backbone plus 196B Engram | 8B prefill, 16B decode | 0.87 GiB |
| GLM 5.3 | 753B | not published | 93.00 GiB |
GLM 5.3 stores about 753B and spends 93 GiB on a million tokens. V4.1 Flash stores about 748B and spends 0.87. Normally these columns move together, because more layers holding more heads is exactly what a bigger model is. That relationship is broken here on purpose.
**The Engram is not a plain lookup table, and the tensor list settles it.** Only two of the forty layers carry one, layers 1 and 14, and each holds six tensors rather than a single embedding:
| Tensor | Shape | Size |
|—|—|—|
| `engram.embed.weight` | 384,006,168 x 256, FP8 | 98.31 GB |
| `engram.embed.scale` | 384,006,168 x 8 | 3.07 GB |
| `engram.q_weight` | 4 x 5120, BF16 | 40 KB |
| `engram.k_weight` | 4 x 5120, BF16 | 40 KB |
| `engram.wkv.weight` | 25600 x 6144, FP8 | 0.16 GB |
There is a query, a key and an output projection around the table, so this is a learned retrieval rather than an index-and-read. **But the machinery is 0.16 GB against a table of 101.4, so 99.84% of it is the part you can leave on disk** and 160 MB is the part that has to run every forward pass.
The row count is the giveaway. **384,006,168 rows** is not a vocabulary, which is 129,280 on this model. It is n-gram scale, which is why the people running it call it the n-gram table. Those figures reconcile exactly: 98.31 plus 3.07 plus 0.16 is the 101.54 GB shard, and 384,006,168 x 256 x 2 layers is 196.6B parameters, which is the 196B the card claims.
It also means the cheaper model in this class is not the cheaper model to serve. GLM 5.3 Flash is smaller on disk and we carry NVIDIA’s official NVFP4 build of it at 204.44 GB, roughly 40% of V4.1 Flash’s footprint. But at a 512K session, GLM 5.3 Flash is already spending about 7 GiB on cache where V4.1 Flash spends under half of one. Which is cheaper depends entirely on how long your sessions run, and that is a question nobody had to ask a year ago.
## How they got there
DeepSeek names several changes in the model card, and four of them bear on the cache. We have not run any of this and none of the mechanisms below are ours. The card also lists Single-Pass mHC residual mixing, the Engram memory above, and DSpark speculative decoding, which affects [tokens per second](/llm-tokens-per-second/) rather than footprint:
A causal encoder decoder, which they abbreviate CED. The 40 layers are organised as a 20 layer causal encoder followed by a 20 layer decoder, and the decoder’s global KV cache is projected from the final encoder hidden states rather than built from each decoder layer’s own. This is also why the activated parameter count is two numbers rather than one: **8B on prefill and 16B on decode.**
Compressed Sparse Attention 2. Each attention layer gets one of three static modes, Full, Reindex or Reuse, which lets layers share main KV and indexer keys and reuse sparse attention indices instead of each computing its own.
FP4 main KV caching, E2M1 with one E4M3 scale per 16 channels. The cache itself is four bit.
SWA Bounded Replay, which reconstructs sliding window KV state by replaying only the most recent tokens rather than persisting that state, which they say cuts the persistent cache to roughly an eighth of V4 Flash’s.
Our entry uses DeepSeek’s published 890 bytes per token directly rather than deriving it. That is a deliberate choice and worth stating plainly: those four mechanisms interact in ways a component by component model built from a config file would get wrong, and a number we invented would be less trustworthy than the number the lab measured. Where they publish, they outrank our arithmetic.
## The benchmarks, against V4 Flash and against V4 Pro
**All figures below are DeepSeek’s own, from the model card. Nobody has independently reproduced them, and the model is one day old.**
The comparison that matters for anyone already running V4 Flash:
| Benchmark | V4 Flash | V4.1 Flash | Change |
|—|—|—|—|
| Terminal-Bench 2.1 | 82.7 | 90.6 | +7.9 |
| DeepSWE v1.1 (Resolved) | 54.4 | 74.2 | +19.8 |
| Codeforces (Rating) | 3289 | 3471 | +182 |
| CyberGym | 76.7 | 88.1 | +11.4 |
| AutomationBench | 37.7 | 54.8 | +17.1 |
| HLE with tools | 51.5 | 63.9 | +12.4 |
| SEC-Bench Pro | 30.9 | 62.8 | +31.9 |
| GPQA Diamond | 89.9 | 90.9 | +1.0 |
DeepSWE resolved rate goes from 54.4 to 74.2, which is the single largest move on the card and the one closest to what people use a coding model for.
Against their own 1.6T V4 Pro it is stranger. V4.1 Flash activates 16B per token on decode against V4 Pro’s 49B, and beats it on Terminal-Bench 2.1 (90.6 against 87.9), DeepSWE (74.2 against 62.7), Codeforces (3471 against 3348), AutomationBench (54.8 against 43.2) and CyberGym (88.1 against 83.3).
Where it loses is knowledge, and the pattern is consistent. On the base model card, V4 Pro leads SimpleQA-Verified 55.2 against 42.3 and MultiLoKo 50.9 against 45.5. A 1.6T model has stored more facts than a 552B one, and no architecture change fixes that. DeepSeek’s own card also puts its Terminal-Bench 3.0 and 4.0 scores at 30.0 and 31.2, behind the leaders in the four frontier columns it chose to publish against, though ahead of some of them: it beats K3 on both and GLM 5.3 on 3.0. That is their comparison table and their numbers, not a ranking we assembled.
Read it as an agentic and coding release rather than a general capability jump. That is where every large gain sits.
## What to do about it
Running local models on your own hardware, nothing changes today. What your card can actually hold is still the question our [GPU buying guide](/best-gpu-for-local-llm/) answers, and nothing in this release moves it. This does not fit and there is no GGUF. Our [model catalogue](/what-llm-can-i-run/) carries it so you can see the numbers, not because you can run it.
Renting makes the question session length. The cache arithmetic above is the reason to look, not the benchmark table. Check what you currently pay to hold long sessions open.
Choosing in this size class, GLM 5.3 Flash is a smaller download and a much larger cache. Set both against your real context length before assuming the smaller file is the cheaper model. It sits alongside the other [Chinese open weight releases](/chinese-open-weight-models/) worth tracking, and [Ling 3.0 Flash](/ling-3-0-flash-vram-requirements/) makes the same single box argument at a quarter the parameters.
## FAQ
**How much VRAM does DeepSeek V4.1 Flash need?**
The weights are 510.30 GB as published, FP8 with FP4 experts, measured across 48 shards in DeepSeek’s repository. The KV cache adds 890 bytes per token, so a full one million token context is another 0.87 GiB. In practice that means four H200s or about seven H100s before anything is resident.
**Can I run DeepSeek V4.1 Flash on a DGX Spark?**
Not on one. A Spark has 128 GB of unified memory against 510.30 GB of weights. **On four, yes, and it is being done.** @Tech2Wild reports it running at TP4 across four Sparks in MXFP4 by keeping the 203 GB of Engram tables on disk, which leaves about 307 GB to hold, and measures 77.2 tok/s peak single stream with a 1M token context proven. @MiaAI_lab reports it on three. Neither figure is ours and neither has been reproduced.
**Is there a GGUF for DeepSeek V4.1 Flash?**
A partial one appeared on release day, `vcruz305/DeepSeek-V4.1-Flash-GGUF`, with three of seven Q2_K parts uploaded. Nothing can load it yet: llama.cpp support is still an open draft pull request. The architecture is new, so this is not a repackaging job.
**Why is the KV cache so much smaller than V4 Flash?**
DeepSeek attributes it to four changes together: a causal encoder decoder layout where the decoder’s global cache is projected from encoder states, Compressed Sparse Attention 2 sharing keys and indices across layers, a four bit FP4 cache, and SWA Bounded Replay reconstructing sliding window state instead of storing it. They state the result as 890 bytes per token, roughly a quarter of V4 Flash.
**Is DeepSeek V4.1 Flash better than V4 Flash?**
On DeepSeek’s own agentic and coding benchmarks, clearly. DeepSWE resolved goes 54.4 to 74.2 and Terminal-Bench 2.1 goes 82.7 to 90.6. On world knowledge the older, much larger V4 Pro still leads. No independent reproduction of any of these figures exists yet.
**What licence is DeepSeek V4.1 Flash under?**
MIT, per the repository. It is multimodal, taking images and text, and supports a one million token context.
**How many parameters is DeepSeek V4.1 Flash?**
552B backbone parameters, plus a further 196B of Engram conditional memory that is stored but only sparsely read, so about 748B in total. Activated parameters are two numbers rather than one because of the encoder decoder split: 8B per token during prefill and 16B during decode.
