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.
UPDATED 2026-10-24: one 12 GB card now runs it. The 510.30 GB below is what the lab ships and it is still the resident number. Strata 0.2.4 runs the 1017 reweight, which has the same shapes, on one 12 GB card with 46 to 64 GB of RAM by keeping the busiest experts in RAM and streaming the rest from the SSD, and Project Maya runs it on its own quants. The section near the end has the sizes and the speeds.
Put that against what a million tokens costs on models people actually run today. Every row is our model catalogue 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; her figures followed within hours, below.
- @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. What would actually price the offload is the same rig with the table resident against the table on disk, and on a Spark that comparison cannot be run at all.
None of these are ours and none are reproduced by us. What was fair to say in September was the narrower thing: the 510.30 GB of weights do not fit a single machine anybody reading this owns, and a three or four box desk cluster with fast storage was the floor for running them as shipped. The offloading engines in the 24 October section below change that floor, not the resident arithmetic. 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.
UPDATED 2026-10-25: llama.cpp build b11870 (25 October 02:15 UTC, pull request #31086, co-authored by Unsloth’s Daniel Han) added DeepSeek-V4.1-Flash to upstream llama.cpp; the release notes say it converts the Engram table to BF16 and give no speed or memory figures, and we have not tested it. Whether an existing GGUF loads in that build is a separate question we have not tested. Unsloth’s unsloth/DeepSeek-V4.1-Flash-1017-GGUF is a ladder of nine rungs, from UD-IQ1_S at 233.0 GB to UD-Q8_K_XL at 508.4 GB (summed from the files in the repository, Engram table included), and its card points to Unsloth’s llama.cpp pull request or the Unsloth Desktop app to run it. The 11 September paragraph below is the record of what was true then.
UPDATED 2026-09-11: the GGUF is complete, and upstream llama.cpp could not run it yet. vcruz305/DeepSeek-V4.1-Flash-GGUF finished its ladder a day after release. Summed from the files in the repository: Q1_0 105.9 GB, Q2_K 264.5 GB, Q3_K_M 347.3 GB, Q4_K_M 444.7 GB and Q8_0 508.0 GB. Conversion support is an open draft, pull request #28696, and upstream llama.cpp had no runtime for this architecture, so a converted file did not load. The converter is writing that runtime on his own branch, and by his repository on September 11 it generates from the real Q2_K file on one DGX Spark, on the CPU backend, at 2.3 tokens per second, with context held at 16K until a masking step is finished. He says in his own post that he would rather the loader refuse than run V4.1 as V4 and return fluent but wrong output.
Set against its predecessor the trade is stark. Our DGX Spark sizing for V4 Flash 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 the 510.30 GB original 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 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.
Day two: faster on three boxes, and the single box claims
UPDATED 2026-09-11. A day of tuning moved the numbers further than the hardware did. Two testers have now published a speed, a full recipe you can rerun, and a day of iteration on this model, each read at their own post and repository:
| Who | Hardware | Stack | Prose, one stream | Also reported |
|---|---|---|---|---|
| @MiaAI_lab | 3x DGX Spark | SGLang, MXFP4 experts, FP8 dense, speculative decoding | 37.9 tok/s | 78.6 aggregate at four streams |
| @MiaAI_lab | 4x DGX Spark | same recipe, TP4 path, from her post (the repository has not measured four) | 46 tok/s | 102 aggregate at four streams, prefill above 3,500 |
| @Tech2Wild | 4x DGX Spark | vLLM, DSpark, CUDA graphs, MXFP4 | 24.4 tok/s | 73.8 on code, same boot |
One more report has less behind it so far: @WescheNex1q gives 33.02 on prose, warm and single stream, on four Sparks using @Tech2Wild's recipe, a single post without a recipe of its own.
@MiaAI_lab's prose figure on the same three boxes went from 17 in her first replies, to about 28 that evening, to 37.9 in her repository a day later, and the repository explains why three is the floor for her recipe. The checkpoint is 476 GiB. Move the two Engram tables, 189 GiB, onto NVMe and about 305 GiB still has to be resident. Split across two Sparks that is 145 GiB each, more than the 121.7 GiB a Spark has. Split across three it is about 101 GiB each, and it fits. The squeeze has a price she states plainly: 256K of context is configured, but only about 32K is usable by default, because a long prefill exhausts the head node's memory; with her empty cache setting she pushed a single prompt to 208K.
A fourth box buys headroom more than speed. Her post reports 46 tok/s on prose on four, with a 4M token KV pool against 750K on three, and her repository puts the weights at about 77 GiB per Spark instead of 101. The repository's own measurements are still all from three boxes, so the four box figure is the newer and less documented of the two.
Running on one machine and being usable on one machine are different claims. The single box reports so far are each one person's result. @0xBakeer has it on one Spark at a median 2.68 tok/s with speculative decoding and 1.75 without, his own figures, on an FP4 build; in his words it is slow and nowhere near usable. The GGUF's converter gets 2.3 tok/s from the Q2_K file on one Spark, on the CPU backend, on his own development branch. The Hugging Face uploader Vontra reports up to 9.46 tok/s on a 256 GB M3 Ultra Mac Studio with an experimental 2 bit build and its own runtime, measured on a 14 token prompt with an answer of nine tokens, 57 GiB of Engram tables left on SSD, and long context untested. @antirez has it running on a 128 GB M5 Max through his DwarfStar engine, streaming from SSD, and gives no speed.
Three tokens a second is worth doing the arithmetic on. A 1,000 word answer is roughly 1,300 tokens by the usual rule of thumb, and DeepSeek's own API guide, at about 0.3 tokens per English character, implies more, so at 3 tok/s it takes over seven minutes. And this model does not write short answers: Artificial Analysis measured it at about 89,000 output tokens per task on its Intelligence Index, one of the most verbose models it has tested. At 3 tok/s that is more than eight hours for one average task. At @MiaAI_lab's 37.9 it is 39 minutes. A post that says a model runs, without the speed, has not told you whether you can use it.
Day three: one box stopped being a stunt
UPDATED 2026-09-12. The paragraph above is two days old and the person in it has already made it wrong. @0xBakeer's single DGX Spark went from a median 2.68 tok/s to between 17.1 and 36.6, depending on what you ask it for, and he publishes the build that did it.
Nothing about the hardware changed. What changed is the format the resident experts are kept in. His first build held 3,926 experts, 25.6% of the 15,360, in a 73.8 GB FP4 arena, and decoded at a median 2.68 tok/s. Recompressing the experts to a 3-bit per-row codebook fits 6,779 of them, 44.1%, into a 98 GB arena, and the router now finds what it needs already in memory on every step of his test.
| Who | One machine | What is resident | Measured |
|---|---|---|---|
| @0xBakeer | DGX Spark, 128 GB unified, local NVMe | 6,779 of 15,360 routed experts, 44.1% of them, in a 98 GB arena as a 3-bit per-row codebook | 17.1 tok/s prose, 24.3 Python, 28.2 JavaScript, 31.8 SQL, 36.6 on a single file HTML game. Prefill 337 tok/s on a 5,014 token prompt |
| JigSawPT | RTX 5090, 31.8 GiB VRAM, 125.7 GiB system RAM, NVMe | 18 GiB of expert cache in VRAM, 72 GiB pinned in RAM, out of a 502 GB checkpoint | 5.12 tok/s on new content, 21.27 on content whose experts are already cached |
Both stream the rest off the disk as the forward pass asks for it, and both publish the repository rather than the screenshot.
The gap inside the second row is the thing to understand before you buy anything. 5.12 against 21.27 is the same machine, the same weights and the same prompt length. The only difference is whether the experts a token needs are already in memory. JigSawPT states the ceiling with no disk read at all as 6.2 tok/s, which tells you the 21.27 is a cache that happened to be warm and not a speed you can plan a workday around. His own stall breakdown says where the time goes: 54% waiting on NVMe, 26% on PCIe, 20% computing.
One box is now usable for some jobs and not others, and the arithmetic says which. Artificial Analysis measured this model at about 89,000 output tokens per task at maximum reasoning effort. At @0xBakeer's 36.6 on code that is 41 minutes. At his 17.1 on prose it is 87 minutes. At JigSawPT's 5.12 on new content it is nearly five hours. The same model, on one machine each, spanning a working lunch to a working day.
Two caveats the testers put in writing themselves. @0xBakeer's runs are 512 completion tokens each, on a build capped at 32,768, and he states that no long generation has been measured on it, so this is arithmetic on his rate and not a job his box has done. JigSawPT's figures point the same way: his working set grows with the content, 105 GiB by 128 tokens, so 5.12 is a starting rate and five hours is the floor. Take these as the best case each machine has earned.
The multi box picture moved too, and in a direction that matters for anyone pricing a second machine:
- @sfxnz put it on two Sparks with an EXL3 cut at 2.0 bits per weight and the Engram tables on disk, and measures 21.2 tok/s on prose with a 0.365 second time to first token. His post says 23; his repository says 21.2, and the repository is the one with the method in it.
- @yunwei37 wired four Sparks as a direct ring with no switch at all and gets 50.14 tok/s as a mean across workloads at one request, 68.06 on code, and 144.71 aggregate at eight concurrent requests. He also answered a 993,435 token needle correctly at a 1,048,576 max length, which is the deepest measured retrieval on this model in the published runs we track. Others have configured the full window: @sfxnz serves at 1,048,576 and @Tech2Wild proved a 1M ceiling with a 1,078,380 token KV pool. @yunwei37 is the one who published the retrieval at that depth.
- @Tech2Wild's tenth boot reaches 73.8 tok/s on code on four Sparks, and states what his drafter actually delivers: DSpark commits a mean of 3.57 tokens per verification step, ranging from 1.88 to 5.92.
One warning that comes free with all of this. JigSawPT measured the same DSpark draft head as neutral across his mixed benchmark: minus 4% on cold content, level once cached, on prompts whose acceptance ran from 51 to 79%. Acceptance is not doing nothing. On verbatim repetition, where the draft was accepted 97% of the time, he measured plus 12% cold and plus 15% resident. The catch is that ordinary content never reaches that acceptance, and below it a verification step pays for the union of experts its whole block needs, which on a disk bound machine is most of the cost. Acceptance is not throughput, and a recipe that quotes one is not quoting the other.
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 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.
UPDATED 2026-09-11: a running deployment now backs the number. @MiaAI_lab's SGLang recipe records the global cache at 1,670.75 bytes per token, the same on every node, stored in FP8 rather than FP4. That is 1.9 times DeepSeek's 890, against the 1.8 times that eight bits per value against four and a half predicts once FP4's scale factors are counted, so the two agree to within about 6%. The figure this article rests on has its first independent check.
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.
UPDATED 2026-09-11: the first independent scores. Artificial Analysis puts V4.1 Flash at 40 on its Intelligence Index, ahead of DeepSeek's own 1.6T V4 Pro 0813, and tied for first on its AutomationBench-AA at 69%, level with GPT-6 Astra. The same evaluation names the cost: about 89,000 output tokens per task, 62% more than V4 Pro 0813, which matters more on your own hardware than on an API. On LMArena's Code Arena WebDev board it opened around 14th overall at 1,620, but that is an early AutoEval score cast by a reward model, not by live human votes.
One 12 GB card: Strata and Project Maya, 24 October
The resident numbers above stay true for llama.cpp and vLLM style engines, and ISTA-DASLab's own card said llama.cpp did not support DeepSeek V4.1 as of 23 October; build b11870 added it upstream on 25 October, untested here. Two engines that place the experts across the GPU, RAM and the SSD do not need them. Strata 0.2.4 runs DeepSeek V4.1 Flash 1017 on one 12 GB card with 46 to 64 GB of RAM, from its Terminal, on ISTA-DASLab's IQ1_M, IQ2_XXS and IQ2_XS files: 239, 257 and 274 GB to download in Strata's figures, 231.32, 248.84 and 265.83 GB in ISTA's own totals (backbone plus a shared 110.60 GB Engram file). Strata's release table shows about 5 tokens a second on an RTX 5070 with 64 GB of RAM and about 8 to 10 on an RTX 3060 with 46 GB, at 2.00 bits; its note says a slow NVMe drive lowers every number. Those figures are for 0.2.4 and the engine ships almost hourly.
Project Maya runs the same model on its own quants: Maya-S at 347.5 GB to download and Maya-XS at 280.9 GB, which Maya's card describes as the whole model in a 128 GB PC's memory. @niklaslenz_ai measured Maya-S on one RTX 5090 with 96 GB of RAM at 22.9 tok/s on code and 18.9 on prose (Maya 1.1.22, 128K context, 23 October). Strata's notice says its DeepSeek engine files come from Maya's, and that "Project Maya is itself built on Strata", so for the first time two engines run the same model; the runs so far use different builds, versions and RAM sizes, so none is a head to head. Check your own card in our Strata calculator and our Maya calculator, which link to each other with your card and RAM, and read the Strata article for the side-by-side with every run credited.
What to do about it
Fully resident, a single card still does not come close, and upstream llama.cpp could not run the GGUF until build b11870 added the model on 25 October, which we have not tested. With offloading, one 12 GB card and 46 to 64 GB of RAM now runs it in Strata at single digit tokens a second (see the 24 October section). Three or four DGX Sparks with the Engram tables on NVMe is where usable speed starts today: single stream prose at 24 to 46 tok/s across @Tech2Wild's and @MiaAI_lab's reports. The 46 is one post on four boxes, and on three her recipe leaves about 32K of context usable by default. What your card can actually hold is still the question our GPU buying guide answers. Our model catalogue carries it so you can see the numbers.
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 worth tracking, and Ling 3.0 Flash makes the same single box argument at a quarter the parameters.
FAQ
Can DeepSeek V4.1 Flash run on one 12 GB graphics card? Yes, with offloading. Strata 0.2.4 (24 October) runs the 1017 reweight on one 12 GB card with 46 to 64 GB of RAM, keeping the busiest experts in RAM and streaming the rest from the SSD. Strata's own table shows about 5 tokens a second on an RTX 5070 and about 8 to 10 on an RTX 3060; the weights are ISTA-DASLab's 239 to 274 GB files. Project Maya runs it too, on its own Maya-S and Maya-XS quants.
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. With offloading it is far less: Strata 0.2.4 runs ISTA-DASLab's 239 to 274 GB builds of the 1017 reweight on one 12 GB card with 46 to 64 GB of RAM.
Can I run DeepSeek V4.1 Flash on a DGX Spark? Not usefully on one. @0xBakeer has it running on a single Spark at about 3 tok/s, his figure, without speculative decoding and without a stated quantization, and the GGUF's converter reports 2.3 on one Spark on the CPU backend. On three or four it runs at a usable speed, single stream: @MiaAI_lab reports 37.9 tok/s on prose on three with SGLang, with about 32K of context usable by default, and 46 on four in a later post, and @Tech2Wild 24.4 on prose and 73.8 on code on four with vLLM, both keeping the 203 GB of Engram tables on NVMe. None of these figures are ours and none has been reproduced by us.
Is there a GGUF for DeepSeek V4.1 Flash?
Yes. As of 25 October, upstream llama.cpp has the model: build b11870 added DeepSeek-V4.1-Flash and converts the Engram table to BF16, with no speed or memory figures published and no test of ours; Unsloth’s unsloth/DeepSeek-V4.1-Flash-1017-GGUF ladder runs from 233.0 GB at UD-IQ1_S to 508.4 GB at UD-Q8_K_XL. Before that, on 11 September, upstream could not run it. vcruz305/DeepSeek-V4.1-Flash-GGUF now holds a full ladder, from 105.9 GB at Q1_0 to 508.0 GB at Q8_0, summed from its files. At that time conversion came from an open draft pull request, #28696, and upstream llama.cpp had no runtime for this architecture. The converter's own branch generates from the real Q2_K file on one DGX Spark, on the CPU backend, at 2.3 tokens per second by his account, with context capped at 16K for now.
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. Artificial Analysis now scores it 40 on its Intelligence Index, ahead of V4 Pro 0813, and 69% on its AutomationBench-AA against 54% for V4 Flash 0731, so the direction holds independently, though it is also one of the most verbose models they have measured.
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. Totals from 748B to 769B circulate depending on what is counted; Artificial Analysis's launch post gives 763B, while its model page lists 552B.