DeepSeek-V4.1-Flash-1017 appeared on Hugging Face today, 17 October, under the MIT licence, and DeepSeek's API now serves it under the deepseek-flash name; the old deepseek-v4-flash name is retired and routes to it too. DeepSeek calls it "a minor update to DeepSeek-V4.1-Flash" with gains in reasoning, coding, agentic tasks and vision, and shorter outputs. Three weeks ago we sized V4.1 against the two GB10 boxes that run V4-Flash for us and declined the upgrade; yesterday we put Meta's 816B Muse Spark Open through the same harnesses. So the questions today are short: what changed, did it move the fit, and which of the three current candidates belongs on two DGX Sparks, and which on four.
Test rig. The "pair" is DeepSeek-V4-Flash-0731 at NVFP4 with its DSpark drafter on two GB10 workstations, tensor parallel over one 200 Gb cable. V4.1-Flash-1017 ran on DeepSeek's own API today, once at reasoning effort high, the same setting as the September V4.1 run it is compared with, and once at low. Muse Spark Open ran on Together AI's API yesterday at effort low. Sizes are summed from the Hugging Face file listings. Every number is ours unless the section says whose it is.
Same model, retrained
The 1017 checkpoint is the V4.1-Flash we sized in September with new weights in the same tensors. The shard count is the same 48, the byte count is 475.3 GiB against 475.2, and every config field matches: 40 layers, 384 routed experts with 6 active and one shared, 5,120 hidden, Engram lookup tables at layers 1 and 14 with 384 million 4-gram slots each, a 512-wide sparse index, 1M context. Nothing in the fitting question moved. The routed experts are still about 300 GiB at their native 4 bits, which is more than two Sparks hold before a byte of context; four Sparks hold them with room, and the 196B of Engram tables page from NVMe at 2 to 3 ms a step in the community build.
What moved is behaviour, and DeepSeek's card makes one claim we can test: shorter outputs and faster task completion on agentic work.
What DeepSeek reports
These are DeepSeek's numbers from the model card, unverified by us.
| benchmark | V4.1-Flash | V4.1-Flash-1017 |
|---|---|---|
| Terminal-Bench 4.0 | 31.2 | 42.3 |
| DeepSWE v1.1 | 74.2 | 77.0 |
| Automation-Bench v1.0.6 | 54.8 | 60.5 |
The card recommends temperature 1.0, top-p 1.0 and a max_tokens of at least 256K, and says the update "reduces task execution time and output length". API pricing is unchanged: $0.15 per million input tokens and $0.60 per million output at off-peak rates, double at peak.
What we measured: seven repairs, three models
The agent harness gives a model a small broken repository and four tools, list, read, write and run the tests, then counts what a single completion cannot show: whether the tests pass at the end, checked by the harness and not self-reported; how many turns and tool calls it took; whether it ever ran the tests before declaring the job done; wasted re-reads; tokens and reasoning tokens. Seven repositories, from an off-by-one to a stale cache and a misleading stack trace.
| Row | pair, V4-Flash | V4.1-Flash, 25 Sep, high | 1017, high | 1017, low | Muse Spark Open, low |
|---|---|---|---|---|---|
| solved | 7/7 | 7/7 | 7/7 | 7/7 | 7/7 |
| mean turns | 5.0 | 4.4 | 4.3 | 4.1 | 5.0 |
| mean tool calls | 4.4 | 4.9 | 4.6 | 4.6 | 4.4 |
| never ran tests · wasted re-reads | 0 · 0 | 0 · 0 | 0 · 0 | 0 · 0 | 0 · 0 |
| output tokens, all seven | 3,069 | 4,151 | 3,952 | 2,915 | 3,672 |
| of which reasoning | 0 | 1,017 | 831 | 328 | 695 |
| wall clock, all seven | 59 s | 44.5 s | 40.3 s | 34.1 s | 52.9 s |
At equal effort, 1017 against its own September run thinks 18% less, answers 5% shorter and finishes 9% sooner, at the same 7/7 and the same turns to a tenth. That is the direction DeepSeek claims, at a size our tasks can barely register. The dial does far more than the retrain: at effort low, 1017 still solves all seven, never skips the tests, and does it in 2,915 tokens with 328 of reasoning, fewer tokens than the pair writes with no reasoning at all, and in the shortest wall time of the five columns. Every column here is 7/7 with no skipped tests and no re-reads, so the harness is saturated on correctness and what it ranks is economy. The pair is the slowest on the clock only because its decode is a desk against a datacentre; the stale-cache task at low needed no reasoning tokens whatsoever.
Per task the picture is the same. The two-file repair is the one that makes every model think: 425 reasoning tokens for 1017, 332 in September, 0 on the pair, all three solved in five turns. The stale-cache task dropped from five turns to four between September and today, and the misleading trace from six tool calls to five. Those are the retrain's gains where seven small repositories can see them; the rest of the saving is the effort setting, which readers running agents on the API control themselves. Terminal-Bench's 31 to 42 is a harder class of task, long sessions in a real shell, and nothing here contradicts it; nothing here confirms it either.
Why an "NVFP4 variant" cannot shrink V4.1
A reader asked whether a 4-bit build of V4.1, like the NVFP4 V4-Flash the pair runs, would bring it to two boxes. No, and the reason is in the shard index. The native checkpoint already stores its experts at 4 bits with FP8 block scales; attention and the dense layers are FP8, and the Engram tables are int8. That is why 763B parameters take 475 GiB and not the 710 that FP8 throughout would give. A Blackwell NVFP4 re-pack would convert the experts' format for the FP4 tensor cores and shave the FP8 attention and dense layers, a few tens of GiB off the 475 at most. It cannot halve anything, because the half that matters is already 4-bit. On four Sparks it would be a speed question, and the community four-Spark build already feeds the native 4-bit experts through the same kernels. Our quantization explainer has the formats; the lesson repeats from the Muse piece: a precision on a model card tells you nothing until you know which tensors it applies to.
The ladder: three models, two box counts
| Row | DeepSeek-V4-Flash-0731 | DeepSeek-V4.1-Flash-1017 | Muse Spark Open |
|---|---|---|---|
| parameters | 304B, 13B active | 763B: 552B backbone + 196B Engram; 8B active prefill, 16B decode | 816B, 42B active |
| released as | FP8 by DeepSeek; NVFP4 DSpark build by NVIDIA | FP8 attention and dense, 4-bit experts, int8 Engram; 48 shards | bf16; NVFP4 by Meta, experts only |
| weights on disk | 155 GiB (NVFP4, running) | 475 GiB native | 1,531 GiB bf16; 496 GiB NVFP4 |
| KV cache per token | 3,514 B | 890 B | not published; grouped-query attention with 16 KV heads |
| two Sparks, 208 GiB for the model | yes, 2.9M tokens of KV left | no, the experts alone exceed it | no, 2.4× over |
| four Sparks, ~416 GiB | yes, and barely faster than two | yes, Engram paged from NVMe, 81.6 GiB per box in the community build | no at NVFP4: 496 GiB plus KV plus bf16 encoders |
| decode, one stream | 33 tok/s prose, 88 structured, on the pair | 74 code / 51 math / 38 reasoning on four Sparks, community build of the September V4.1, same shapes | about 100 tok/s hosted; NVIDIA's recipe starts at four GB200s |
| vision | no | yes, 32-layer encoder | yes, plus audio and video |
| licence | MIT | MIT | Muse Model License |
The four-Spark V4.1 row is not ours: it is a community build measured on four DGX Sparks in September, included because it is the only native-precision run of V4.1 on this hardware and because 1017 has the same shapes. The pair's row is production. The Muse row is Together's service and Meta's listings.
The verdict
- Two Sparks: V4-Flash, and only V4-Flash. It is the one model of the three that fits, and on every harness we own it scores level with the two that do not. The retrain did not change that.
- Four Sparks: V4-Flash or V4.1-Flash-1017, not Muse. The reason to buy two more boxes has sharpened a little: 890 bytes of KV per token, a 1M context under a gigabyte, native vision, and now an agentic model that thinks a fifth less than it did in September. Whether that is worth two boxes depends on whether your tasks look like Terminal-Bench or like our seven repairs. Ours do not justify it; the September arithmetic on prefill and price still holds.
- Muse Spark Open is a service at any Spark count. Eight boxes would hold its weights on a fraction of a B200 node's bandwidth. Rent it if you want it.
- If you already pay for the API, you have 1017 whether you asked or not. Same price, a little less thinking, the same seven out of seven, and at effort low it repairs code in fewer tokens than any model in this table.
Related reading
- Should You Upgrade to DeepSeek V4.1 Flash? We Tested It on Two DGX Sparks — the September sizing, the eight harnesses, the four-box arithmetic
- Muse Spark Open 816B: How Much VRAM, and Does It Beat DeepSeek V4 Flash? — the 496 GiB build and the harness tie
- DeepSeek-V4-Flash on Two GB10s: 304B Params, 1M Context, 83 Watts — how the pair runs
- DeepSeek V4.1 Flash on Nvidia 5090? — the same model against 32 GB
- Best Model for a Dual DGX Spark: DeepSeek-V4-Flash vs Qwen3.8-Flash-Next vs GLM-5.3-Flash — what else fits 256 GB
- 4-Bit Quantization Decoded — INT4 QAT, MXFP4, NVFP4