DeepSeek V4.1 Flash 1017 Scores Better on the Same 510 GB

What is DeepSeek V4.1 Flash 1017?

It is the same machine in a fresh coat of paint, and that is the finding. DeepSeek released DeepSeek V4.1 Flash 1017 on 17 October 2026 at 08:35 UTC, open weights, MIT licence, calling it "a minor update to DeepSeek-V4.1-Flash" in its own card. We then compared the two Hugging Face repositories file by file. The config is the same 3,311-byte file with the same blob id. All 48 weight shards are the same size. The parameter tally is identical to the single digit: 763,205,315,794. What differs is the bytes inside the files: every shard carries a different SHA-256. New weights, same shapes.

For anybody who sized the original V4.1 Flash, the memory answer did not move. The download is 510.3 GB. The context math is the carried 0.87 GiB per million tokens. Everything below is what did change, and the one number on the download page that people keep reading wrong.

We compared the repos, and not one file size moved

Sizes are shapes multiplied by dtypes. Shapes and dtypes are proven identical above, so every quantized build of the new weights will land at the old model's size for the same rung. That is arithmetic, not a guess, and it is why our calculator shipped the 1017 entry with the original's geometry on day one: 40 layers, 5,120 hidden, 384 routed experts with 6 active per token, and the 1,048,576-token window that YaRN stretches out of a native 65,536.

The one figure people quote wrong on this model family is what the 510.3 GB actually is. And the Engram is not a 1017 arrival: the September release carried the same two shards at the same sizes, and only their contents moved with the rest, which is how our original V4.1 Flash sizing page splits it too. Two shards, 47 and 48, hold 101,535,150,936 and 101,537,926,640 bytes. Between them, 203.07 GB. Those two shards contain exactly six tensors each, all of them the Engram lookup tables for layers 1 and 14. The network, the vision tower and the embeddings are 307.2 GB. The rest is a dictionary.

@Tono_Ken3 had that split read from the file listing at 08:31 UTC, four minutes before DeepSeek's own announcement: 204 GB of the 510, he posted, and about 30 tokens a second as the target for the 306 GB that remains. That is 203.07 GB against 204, and 307.2 against 306. Two independent reads of the same files, and the file listing is the ground truth for both.

The Engram table matters to your hardware because a lookup is not a read of everything. The weights get streamed every token; the table answers a few address lookups per token, the way Qwen3.8 Flash Next's 51.2 GB n-gram table does on its model. DeepSeek's is near four times bigger, and llama.cpp-family engines, which is what the day-one GGUF builds are made for, keep input lookups like this in system RAM by default, off the card. The model catalogue sizes this family that way, and it is the difference between a model that needs a rack of memory and one that needs a rack of NVMe.

What the scores say

Four rows of the card's benchmark table, with the open models DeepSeek lines up beside its own; the full table also carries GPT-5.6 Sol and Opus 5 columns. Read it as DeepSeek's figures, which is what they are:

GLM's 42.0 is its text-only subset, the card's dagger.

Two sentences about what the table means for somebody running models at home. First, the jump is against itself: from 31.2 to 42.3 on Terminal-Bench, in DeepSeek's own numbers, against the model every sizing page already covers. Second, the lab's stated pitch is shorter outputs at higher scores, which is the one benchmark direction that turns into speed on your hardware without anybody touching a quantizer. Fewer tokens to the same answer is free tokens per second.

The testers who read the launch thread agreed with the first sentence in the numbers above. @ItsmeAjayKV, who runs a 3060 and a 3090 and puts quants in his bio: "It's way better than first v4.1-flash and absolutely crushes other giant open weight models GLM-5.3, Kimi K3 on benchmarks." His read of the table, not ours.

The serving side weighed in too. @vllm_project congratulated the release and quoted its numbers on the previous model: 830K tokens per second per GPU at 100 per user, 1.3B tokens per dollar on the SemiAnalysis AgentX harness. His post scopes those to the original V4.1 Flash, and the 1017 inherits its architecture, so the serving sentence is about last month's model, not this week's.

What you can download today

The lab ships the FP8 safetensors, 510.3 GB, dynamic quantization on 32 by 32 blocks with FP4 routed experts (expert_dtype: "fp4" in the config, and the reference kernels are described in the repo as dense-fp8 and MoE-fp4). Around it, a conversion wave that started inside six hours of the weights landing:

NVIDIA's own NVFP4 build, 26,835 downloads and counting, is still cut from the original V4.1 Flash. A day-one download of the 1017 through any engine other than the FP8 original is a community conversion. Both conversions were read file by file and entered the same morning: mrfakename's ladder filled all four rows, 264.52, 347.27, 444.74 and 507.95 GB, and LibertAIDAI's community NVFP4 transcode came in at 429.01 GB, 98.28 GB under NVIDIA's 527.29 GB build of the original, because the transcode packs the Engram tables as FP4 too (104.77 GB against the 203.07 GB those tables weigh at FP8). Unsloth's own ladder answered on 18 October: UD-Q4_K_XL at 500.71 GB and UD-Q8_K_XL at 508.38 GB, and those two files now size the entry's Q4_K_M and Q8_0 rows. mrfakename's two low rungs, 264.52 and 347.27 GB, keep the Q2_K and Q3_K_M rows as placeholders, read from their live files every day, so a vanished shard makes noise rather than a stale table. Read from the GGUF headers tonight, the table is the difference: both Unsloth files hold the Engram lookup near its official weight, 203.09 GB in the Q4 file and 203.39 in the Q8, against the 203.07 GB it carries in the FP8 checkpoint, while mrfakename's plain 444.74 GB Q4 file shrinks that table along with the rest. Same rung letter, different file, and it is the lookup table, not the network, that moved. On 2026-10-18 @jayleaton published an EXL3 pack sized 203.8 GB at a 2.8-bit target for two DGX Sparks on TensorFold with the 1M window and a 2.1M-token cache; we record his pack and his own small-sample evals (“at least as good, in a smaller pack”, his words) and do not carry it as a rung, because an EXL3 bit count is a conversion target, not a byte guarantee.

The arithmetic checked itself within hours. mrfakename's llama.cpp ladder, published about six hours after the weights, lands within 0.01 GB of the old ladder on every rung we compared: 264.52, 347.27, 444.74 and 507.95 GB. The sizes are from its own file listing; whether a given llama.cpp build loads this architecture is a separate question we have not tested.

The first runs, two days in

The wave turned from conversions into measurements. @mxfp0 ran DeepSeek V4.1 Flash 1017 on four DGX Sparks wired tensor-parallel, switchless, one request at a time: prose about 41 tokens per second, code about 67, prefill about 1700 tok/s, and “still room for improvement probably” in his own words. Hours later on the same rig he reported prose 73.2 and prefill 5298 after a tuning push. Neither post names the engine or the window.

@Tech2Wild published his own harness on the same four-box shape: 165.7 tok/s throughput, and beside it a 98.6 score on a 69-scenario tool eval of his own design, a quality figure rather than a speed one. His follow-up explains the wiring: every step, the Sparks swap work over RoCE, and adding a second network cable raised long prompt reads by about 15 percent.

For anyone reading a single card into this, the blockers arrived in the same wave. @TeksEdge sized a community VQ conversion at about 113.6 GB targeting one 128 GB DGX Spark, and said plainly that the quant has not been benchmarked on a Spark and that mainline llama.cpp does not support V4.1 yet. The first engine of the ones we track to load a -1017 build on consumer cards was Strata: @WMjjRpISUEt2QZZ ran a Q4_K_M file on two RTX 5090s with eight-channel DDR5, a momentary peak just past 100 tok/s, then 55 to just under 60 sustained once the prompt passed 10K tokens, his own tuning loop with his own caveat.

PureTensor published the other corner of the local story the same weekend, relayed by @Dataphil3: the -1017 filled a four-card node of RTX PRO 6000 Max-Q cards in SGLang, tensor and expert parallel 4, the official FP8 checkpoint at 476 GiB with the Engram table near 189 GiB held in host RAM, and it decoded 102 tokens per second on one request and 463 across eight, with 9,237-token-second prefill. Their efficiency tier, Nemotron 3.5 Super VL in NVIDIA's NVFP4 on two Workstation Edition cards sharing memory with eight other services, answered 226 and 1,535 on the same bench. The paper is careful about what it does not claim and so are we: different card variants, one evaluation day, footprint figures rather than a model-versus-model race. Every figure here, theirs and the Spark runners', enters our speed collection as an attributed row with its unstated fields named. What one Spark costs to hold is already arithmetic, not speculation: about 113.6 GB by that community sizing, 444.74 GB at the Q4_K_M rung of the published ladder. What it costs to load them, on the engine of your choice, is the question each run above answers one box at a time.

How to run it, per the card

Temperature 1.0, top_p 1.0, context 1M, and max_tokens of at least 256K. That last one is the unusual instruction. The card pitches this release as faster task completion with shorter outputs and names its harnesses, DeepSeek Harness, Tencent CodeBuddy, WorkBuddy; a floor of 256K on max_tokens fits loops that think long and answer short. The card ships no Jinja chat template. The prompt format lives in a Python reference encoding, tested for tool calls, thinking mode, numeric reasoning effort and interleaved images, plus deepseek-recipe, DeepSeek's Rust encoder. If your serving stack parses chat templates at boot, that file is now your work.

One more card detail worth knowing before you benchmark anything: the repo's own interactive example passes --temperature 0.6 while the card recommends 1.0. Both figures are DeepSeek's own, and the card does not reconcile them. Run the one your harness defaults to, and write it in your report.

Check your own box on the calculator, where this model is in since launch day. The old V4.1 Flash sizing page answers the memory question unchanged, the tokens-per-second table already carries the measured runs people published against the original, and if you are deciding hardware for agentic models, the RTX Spark versus Ryzen AI Max comparison is where 307.2 GB of weights gets honest.

FAQ

Is DeepSeek V4.1 Flash 1017 a new model?

No, and the files say so. It is DeepSeek's own "minor update" to the V4.1 Flash weights: the config file is byte-identical, all 48 shards keep their exact sizes, and only the contents changed. Every memory figure for the original carries over.

What does DeepSeek V4.1 Flash 1017 need to run?

510.3 GB to download. Of that, 203.07 GB is the Engram lookup table, which llama.cpp-family engines hold in system RAM rather than VRAM, and the remaining 307.2 GB is the network. The million-token cache is 0.87 GiB, the same compressed-KV math as the original. That hardware profile is what two DGX Sparks or a server card with real bandwidth exist for.

Did anything change for VRAM requirements?

Nothing changed in size; everything people will measure is in speed and output length. Higher Terminal-Bench and ProgramBench scores at shorter outputs, DeepSeek's own figures, mean the same cards complete the same tasks in fewer tokens. Sizing answers live in the calculator and did not move.

Are there GGUF builds of the 1017?

Yes, and they started the morning the weights landed: mrfakename's llama.cpp ladder at 08:28 UTC and a Baekpica VQ build tagged for the Spark at 10:10, both within six hours. Four GGUF rungs are selectable: from 18 October the Q4_K_M and Q8_0 rows are sized from Unsloth's own ladder (500.71 and 508.38 GB), while the two low rungs come from mrfakename as placeholders until Unsloth ships them. The NVFP4 row is still LibertAIDAI's community transcode; NVIDIA's own NVFP4 build remains cut from the original 4.1 Flash. And loading any of those files on a given llama.cpp build is a separate question, one @TeksEdge put plainly: mainline llama.cpp does not support V4.1 yet.