DeepSeek V4 Flash 0731 VRAM Requirements: 162 GB Measured

How Much VRAM Does DeepSeek V4 Flash 0731 Need?

DeepSeek V4 Flash 0731 VRAM requirements land between 162 and 178 GB at 4-bit, and the spread is the interesting part. DeepSeek released the official DeepSeek-V4-Flash-0731 weights on 31 July 2026 under MIT, and Unsloth published GGUF conversions the same afternoon. The 4-bit build measures 155.1 GB. The lossless 8-bit build measures 161.9 GB. The gap between them is 6.8 GB, which is roughly 4%, and that single number tells you more about this model than any benchmark on the card does.

For scale: Kimi K3’s lossless build from the same quantizer is 1,561 GB. This one is 9.6 times smaller and lands in the same conversation on agentic benchmarks. Here is what is measured, what is computed, and what is still someone’s unverified claim.

DeepSeek V4 Flash 0731 VRAM Requirements at a Glance

Weights are measured from the published GGUF files. KV cache is computed from DeepSeek’s own config.json. The headroom row is a range, and the next section explains why it has to be.

For the lossless build, add about 7 GB to every row: 169 to 186 GB at 32K.

The million-token context costs about 4 GB. Not 400 GB. Going from 32K to a full million adds under 4 GB, roughly 2% on top of the weights. That is the compressed attention doing its job, and the mechanism is below.

Why We Publish a Range and Not One Number

Most calculators, ours included until now, hand you a single total. On a model this size that hides a real disagreement, so here it is in the open.

Weights and KV cache are measurable. Runtime headroom is not a constant. It is the scratch space the runtime needs to actually do the arithmetic, and it moves with your context length, batch size and runtime version.

Unsloth’s published guidance implies about 4.4% on this model. Back it out of their own table: 155.1 GB of weights against a stated 162 GB total, and 161.9 GB against 169 GB. Both rows land on 4.4%. Our calculator plans for 15%, deliberately.

Neither is wrong. They answer different questions. Theirs is the measured floor on a working configuration. Ours is a planning margin, sized so that nobody buys or rents hardware and then hits an out-of-memory crash on a longer context.

How to use the range: if your memory pool clears the top of it, you are fine. If you sit between the two numbers, it will probably run and you have no room for error. Below the floor, it will not.

One caveat on our own tool. It sizes from DeepSeek’s official 166.9 GB checkpoint rather than from a GGUF repack, so the calculator reports about 192 GB at Q4 where this article says 178. That is the conservative end of the conservative end. The measured GGUF figures in the table above are the ones to plan against.

What Fits It

These are configurations the vLLM project has published recipes for, not our arithmetic. We do not own this hardware and have tested none of it.

vLLM 0.26.0 is the minimum for either checkpoint, which is the likeliest reason an attempt fails on an older install.

Two linked DGX Sparks are the configuration local testers are actually using, and it is worth being precise about what that is: two 128 GB nodes over a network link, not one 256 GB address space.

Run your own setup through the VRAM calculator if it is not listed. If none of this is in reach, renting is the cheaper way to find out whether the model earns the hardware.

Where to Get It

• Weights: deepseek-ai/DeepSeek-V4-Flash-0731 (48 safetensors shards, 166.9 GB, MIT, ungated)
• GGUF: unsloth/DeepSeek-V4-Flash-0731-GGUF
• vLLM recipe: recipes.vllm.ai
• Technical report: arXiv 2606.19348

As of the afternoon of 31 July, conversions had appeared from bartowski, bullerwins and ddh0, plus EXL3 builds at seven bpw levels, MLX and NVFP4. The base repository took 767 likes in about nine hours.

Why the Parameter Count Looks Different Depending on Where You Read It

You will see this model called 284B in some places and 304B in others, and both appear in circulation on launch day.

284B is the figure to use. It is what the architecture computes to from config.json: 43 layers of 256 experts at 4096 by 2048, plus shared experts, attention, the indexer and embeddings. The 304B number comes from HuggingFace’s automatic dtype summary, which counts the packed FP4 expert tensors by element rather than by stored width.

Active parameters per token are 13B either way, and that is the number that governs speed.

What Actually Changed in 0731

This is the part most coverage is getting wrong, and it matters if you already downloaded the preview.

DeepSeek’s follow-up post states that 0731 keeps the exact same model architecture and size as the preview, and that the day’s upgrade applied only to the API. We checked rather than repeating it. Diffing the published config.json against the preview gives two differences and nothing else:

1. Four new dspark_* keys, which attach a speculative decoding module
2. compress_ratios grows from 44 entries to 46, the two extra being trailing zeros

Every field that drives memory is untouched: 43 layers, hidden size 4096, 256 routed experts with 6 active plus 1 shared, head dimension 512, one KV head, 1M maximum position. The GGUF files confirm it independently, since UD-Q4_K_XL and UD-Q8_K_XL measure exactly the same as the preview builds did. The vLLM project says the same from the serving side: the architecture matches the preview, so an existing serving config carries over.

Practically: if you are sizing hardware, preview figures carry over unchanged. If you are choosing which to download, take 0731, because the agentic gains are real and the memory cost is about 7 GB.

The 7 GB That Buys Speculative Decoding

This is the most useful thing in the release and almost nobody is framing it correctly.

Speculative decoding normally costs you a second model resident in memory. You load the big model, then a small draft model alongside it, which is why most local users never bother.

0731 ships the draft module inside the weights. vLLM’s own recipe page puts the cost plainly: about 167 GB on disk against about 160 GB for the preview, and the draft module is the difference. Our own measurements agree from three directions:

So it is roughly 7 GB for speculative decoding with no second model to load, and it turns on with one flag:

--speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'

Why the Lossless Build Costs Only 7 GB More Than 4-Bit

DeepSeek ships the experts natively in FP4. Not quantized down after the fact: trained and released that way, with expert_dtype: fp4 in the config. The experts are the overwhelming majority of the 284B parameters.

So “quantizing to 4-bit” barely touches them, because they were already there. And going up to 8-bit cannot recover precision that was never in the file. Unsloth mark UD-Q8_K_XL as 100% bit-exact with a KL divergence of about zero. Q8 is not a high-quality approximation of this model. Q8 is this model.

One caveat, because it is a real trap. A naive repack that upcasts those FP4 experts into wider containers does exist and is genuinely bigger: there is a published plain Q8_0 at 302.3 GB. It contains no more information than the 161.9 GB build. If you are downloading, check the file size, and prefer a build whose name says it preserves the native expert width.

The measured ladder, from the preview build where the full range exists. Same architecture, so these carry to 0731:

Unsloth’s combined RAM and VRAM guidance for the same ladder: 92 GB at 1-bit, 102 GB at 2-bit, 110 to 135 GB at 3-bit, 162 GB at 4-bit, 169 GB lossless. Their recommended settings are --temp 1.0 --top-p 1.0 --min-p 0.0 --ctx-size 32768, with --n-gpu-layers tuned down until it stops running out of memory. Our guide to llama.cpp’s offload flag covers what that last one actually does on a constrained card.

Against Kimi K3, Carefully

The obvious question after Kimi K3’s requirements is whether a model a tenth the size can be in the same league. The honest answer needs two tables.

Memory, measured, same quantizer, same naming scheme:

Both figures come from Unsloth, both are measured file sizes, neither is estimated.

Benchmarks are harder. Moonshot and DeepSeek published separate tables using different harnesses, so you cannot read across them. What you can do is check whether the two labs agree on a model they both scored. Both cards include GLM-5.2:

Two of four agree exactly. Two do not. So only two of these can honestly be read across the cards:

Read that honestly. V4 Flash 0731 does not match Kimi K3. It sits between K3 and GLM-5.2 on both, and on AutomationBench much nearer the top of that range. For a model needing a tenth of the memory, that is a genuinely strong result, and a more useful claim than “beats K3” would have been.

One caveat on DeepSeek’s own table: it compares 0731 against V4-Pro Preview, not a shipped V4-Pro, and DeepSeek says the official Pro release is still to come. Their table also includes Claude Opus 4.8, which beats 0731 on all nine rows. They published that column themselves.

What People Are Actually Measuring

Four figures exist as of 31 July, and the spread between them is the story.

With full methodology published:

• tonyd2wild, launch scripts on GitHub under Apache 2.0: about 40 tok/s single-stream, about 92 aggregate at 8 concurrent, on 2x DGX Spark over a 200GbE RDMA link, vLLM at tensor-parallel 2, FP8 KV cache, MTP speculative decoding at about 78% draft acceptance, 500K max context.
• entrpi, on the NVIDIA developer forums: 18.8 to 20.6 tok/s plain decode, 27 to 35 with speculation, 800 tok/s prefill at 12K, on a single 128 GB DGX Spark at 2-bit expert weights.

From X, with hardware but not quantization:

• @0xSero: 77 tok/s at the full 1M context window on 2x Sparks, while running a 12B vision model alongside on the same machines. The context length makes this the most useful of the four.
• @Tech2Wild: 82.3 tok/s peak, 82.3 sustained, 871 tokens in 11 seconds, TTFT 0.17s, on DGX Spark. The task was counting to 300.

How to read them. The single-Spark number is 20 to 35. The two-Spark numbers are 40 to 82. Counting to 300 is close to the most predictable generation possible, and this model ships with a speculative decoding module that is at its best on exactly that, so 82 is an upper bound rather than throughput you should plan around. Neither X post states the quantization, which is the one thing that would make them directly comparable.

That gap is the normal shape of local-AI speed reporting rather than anything unusual about these testers, and we flagged the same pattern when Kimi K3 went local. We will update this page as configurations get published.

Where This Sits Among Open Models

The Chinese open-weight labs have been setting the pace through 2026, and this release sharpens the pattern rather than changing it. What changed is the hardware bar. K3 was a model you read about. V4 Flash 0731 at 162 GB is a model a well-funded individual can actually run, and that is a different kind of release.

If you want to know what your own hardware can handle, the GPU-first tool answers it directly.

FAQ

How much VRAM does DeepSeek V4 Flash 0731 need?
Between 162 and 178 GB at 4-bit, and 169 to 186 GB for the lossless build. The 4-bit weights measure 155.1 GB and the lossless weights 161.9 GB. The spread is runtime headroom: 162 GB is the measured floor from Unsloth’s own guidance, and 178 GB is a planning margin with room for longer contexts.

Is DeepSeek V4 Flash 0731 different from the preview version?
Architecturally, no. DeepSeek states that 0731 keeps the exact same architecture and size, a diff of the published config files confirms it, and the vLLM project says an existing serving config carries over. The only additions are a bundled speculative decoding module and two trailing zeros in one array. The agentic benchmark scores are substantially higher.

Why is the 8-bit version only 7 GB larger than the 4-bit version?
Because the experts ship natively in FP4. Going up to 8-bit cannot restore precision that was never in the file, and Unsloth mark their 8-bit build as 100% bit-exact, so it is the full-precision version rather than an approximation. Note that a naive repack which upcasts the experts does exist at 302.3 GB, and it contains no extra information.

Does DeepSeek V4 Flash 0731 have 284B or 304B parameters?
284B. That is what the architecture computes to from the published config. The 304B figure is HuggingFace’s automatic dtype summary, which counts packed FP4 expert tensors by element rather than by stored width. Active parameters are 13B either way.

How fast does DeepSeek V4 Flash 0731 run locally?
Published measurements range from 18.8 tok/s on a single DGX Spark at 2-bit up to about 82 tok/s on two linked Sparks on a trivial counting task. The best-documented figure is about 40 tok/s single-stream on two Sparks with vLLM, tensor-parallel 2 and FP8 KV cache. We have not tested any of these.

How does DeepSeek V4 Flash 0731 compare to Kimi K3?
On the two benchmarks that can be read honestly across both vendors’ tables, K3 scores higher: 67.5 against 54.4 on DeepSWE, and 30.8 against 25.1 on AutomationBench. V4 Flash 0731 needs about a tenth of the memory, 161.9 GB against 1,561.2 GB for the lossless builds.

What licence is DeepSeek V4 Flash 0731 under?
MIT, in the repository and on the weights.