DeepSeek V4 Hardware Requirements: Flash vs Pro

DeepSeek V4-Flash needs between 82.5 GB and 168 GB of memory just for weights, and V4-Pro needs between 850 GB and 913 GB. The "13B activated" figure in every headline is a throughput number, not a memory number — routing picks 6 of 256 experts per token, but all 256 must be resident before the first token appears. Practically: Flash is a 128 GB-and-up unified-memory or multi-GPU model, and the only build that meaningfully moves that line is unsloth's UD-IQ1_S at 82.5 GB. Pro is a server model — the smallest DeepSeek-V4-Pro-0813 build published anywhere is 849.7 GB, which no single consumer box holds.

This page is a spec lookup, not a setup walkthrough. Every size below was read from the Hugging Face repository file listings and safetensors headers on 23 August 2026 and is reproducible: open the repo, sum the shards. Where a number is derived rather than published, the arithmetic is shown. There are no throughput figures anywhere on this page, because we do not own a 4×GB300 node and will not pretend otherwise.

If you want the install steps instead, they live on our DeepSeek V4 local setup page.

How Much Memory Does DeepSeek V4 Actually Need?

Start with the two official checkpoints. Both are MIT-licensed, both declare a 1,048,576-token position limit in config.json, and both ship weights that are already quantised — which is the single fact that makes DeepSeek V4 behave differently from every other model you have sized.

Architecture rows come from each repo's config.json. The 284B/13B and 1.6T/49B splits are stated on Ollama's model pages for deepseek-v4-flash ("a Mixture-of-Experts model with 284B total parameters and 13B activated, built for efficient reasoning across a 1M-token context window") and deepseek-v4-pro ("1.6T total parameters and 49B activated"). The disk figures are the sum of the model-*.safetensors shards reported by the Hugging Face API for each repo.

Note the gap between the two Pro columns and the two Flash columns. Flash is roughly one fifth the weight of Pro on disk and needs about one quarter the compute per token. That ratio, not the benchmark table, is the reason almost everyone asking this question ends up on Flash.

Why Doesn't 13B Active Mean 13GB of VRAM?

Because activated parameters govern how much arithmetic happens per token, and total parameters govern how much memory has to be filled before any arithmetic happens at all. These are two different budgets and the marketing number is always the smaller one.

Here is the routing, straight out of Flash's config.json: n_routed_experts: 256, num_experts_per_tok: 6, n_shared_experts: 1. Every token is scored against all 256 routers, six experts win, the shared expert always runs. So 7 of 257 experts do work — about 2.7% of the expert weights.

The catch is that the winning six change on every token, and nothing predicts which six. Keep only the popular experts in VRAM and the other 250 still have to be somewhere the GPU can reach within a token's budget. That is why the memory requirement tracks the 284B number and the speed characteristic tracks the 13B number.

You can verify the 13B yourself from the tensor shapes in the checkpoint. Per layer, reading the safetensors header of model-00002-of-00048.safetensors:

attention   wkv [512,4096] + wq_a [1024,4096] + wq_b [32768,1024]
            + wo_a [8192,4096] + wo_b [4096,8192]     = 106,954,752
router      ffn.gate [256,4096]                       =   1,048,576
shared expert   w1 + w3 + w2, each [2048,4096]-shaped =  25,165,824
6 routed experts  6 x 25,165,824                      = 150,994,944
                                                        -----------
per layer                                             ~ 284,950,000
x 43 layers                              = 12.25B
+ embedding + lm_head (2 x 129,280 x 4,096) = 1.06B
                                           -------
                                             13.3B  active

Which matches the published 13B. The same arithmetic on Pro's config (61 layers, hidden 7,168, expert intermediate 3,072, top-6 of 384) lands on 49.1B, matching its published 49B. Both figures are honest, and neither one is your VRAM budget.

If this is the first MoE you have sized, our guide to VRAM requirements by model size covers the dense case, and what quantisation actually costs covers the trade you are about to make.

Is DeepSeek V4 Flash 284B or 304B?

Both, and the difference is the speculative-decoding module. This trips up everyone comparing sources, because Hugging Face's model header says 304B while Ollama's page says 284B, and the numbers are 20B apart.

The repo has 48 shards. Shard 1 is the embedding, shard 45 is the output head, shards 2–44 are the 43 transformer layers, and shards 46, 47 and 48 are three more full MoE layers — the DSpark draft module the model card describes as "a speculative decoding module attached." Three extra layers of 256 experts is 19.3B parameters. 304.18B minus 19.3B is roughly 284B.

So:

• 284B = the model that answers you. This is what llama.cpp reports; issue #26399 logs a loaded Flash checkpoint as "145.63 GiB, 284.33 B params, arch deepseek4."
• 304B = the same model plus the DSpark draft head, which is what Hugging Face's parameter counter totals. Ollama's page splits the difference by describing the model as 284B in prose and listing "Size 304B parameters" in the sidebar.
• The draft head is also distributed on its own. In the unsloth GGUF repo it is a separate 10.9 GB dspark- file, so you can skip it and save that memory if you are not using speculative decoding.

The same structure appears in Pro: 66 shards = embedding + 61 layers + output head + 3 DSpark layers, which is why its two published totals are 1.6T and 1.65T.

The part almost nobody mentions: the weights ship pre-quantised

Flash's config.json contains "expert_dtype": "fp4". That is not a suggestion for you — it describes the file. Reading the safetensors header directly, a routed expert's first matrix is stored as layers.0.ffn.experts.0.w1.weight, dtype I8, shape [2048, 2048], paired with layers.0.ffn.experts.0.w1.scale, dtype F8_E8M0, shape [2048, 128]. The shared expert's equivalent tensor is F8_E4M3 at [2048, 4096] — full width.

Half the width, one scale per 32 values: the routed experts are 4-bit values packed two to a byte with block scales. That is MXFP4. Attention and the shared expert are FP8.

This has one consequence that dominates the rest of this page:

• Flash's routed experts are 296.35B parameters at 4 bits = 148.2 GB, which is 95.5% of the 155.1 GB UD-Q4_K_XL GGUF.
• Pro's routed experts are 1.623T parameters at 4 bits = 811.7 GB, which is 95.5% of the 849.7 GB UD-Q4_K_XL GGUF.

In other words, a "Q4" build of DeepSeek V4 is not a compression of anything — it is a repack at native precision. Everything smaller is genuinely lossy in a way that a Q4 of a BF16-released model is not, and everything larger is padding the 5% that was never 4-bit to begin with. Which is exactly why unsloth's Pro Q8_K_XL (873.4 GB) is only 2.8% bigger than its Q4_K_XL (849.7 GB): there is almost nothing left to upcast.

Which DeepSeek V4 Flash Build Fits Your Machine?

Every published Flash build, sorted by size. "Effective bpw" is file bytes × 8 ÷ 284.33B parameters — arithmetic, not a quality score. Sizes are the sum of the file's shards as reported by the Hugging Face API, in GB (10⁹ bytes) and GiB (2³⁰ bytes) because llama.cpp reports the latter and your OS reports the former.

Three things worth reading off that table:

1. The floor is about 82 GB, not 32 GB. There is no 4-bit-class build under 80 GB and there is unlikely to ever be one, because 296B expert parameters at 2 bits is still 74 GB before anything else.
2. Everything at or above 155 GB is the same information. UD-Q4_K_XL, the two MXFP4 repacks and the official safetensors differ by under 8%, and that difference is FP8 attention layers being stored slightly differently, not model quality.
3. The 2.5-ish bpw cluster is where the interesting engineering is. Four separate groups independently landed between 91.5 and 98.6 GB, which is not a coincidence: that is the largest build that fits a 128 GB machine with room for context.

What Does DeepSeek V4 Pro Need?

Short version: a rack. Longer version, every published DeepSeek-V4-Pro-0813 build:

That is the whole list as of 23 August 2026. Nobody has published a sub-4-bit 0813 build, and the reason is the one from the previous section: 1.623T expert parameters at 4 bits is 811.7 GB, so the file cannot go meaningfully below 850 GB without re-quantising weights that were already 4-bit. Even pushing Pro into the 2.5 bpw band that makes Flash interesting would land near 500 GB — which is the entire memory of a maxed-out 512 GB Mac Studio, with nothing left for the OS or a context window.

The earlier Pro preview checkpoint does have community GGUFs down to 574 GB, but it is a different model with a different parameter count, so do not read those sizes across to 0813.

Pro's practical answer for almost everyone reading this: use it through an API, and run Flash locally. Note that Flash-0731 was released specifically as the model that "outperforms DeepSeek-V4-Pro (Preview) on benchmarks listed below despite its far smaller activated parameter count" — the gap between the two you can actually host is narrower than the parameter counts suggest.

Can an RTX 5090 Run DeepSeek V4 Flash?

Not on its own. A 5090 has 32 GB of VRAM. The smallest published Flash build is 82.5 GB. That is a 50 GB shortfall against the smallest file that exists, so every 5090 configuration is an offload configuration, not a resident one.

What a 5090 changes is how well the offload goes, and that depends entirely on the system RAM behind it:

Definitions, because "runs" is doing a lot of work in that table:

• Runs — the whole build fits in the fastest memory pool (discrete VRAM, or unified memory on Apple Silicon and Strix Halo) with room left for KV cache and compute buffers.
• Offloads — it fits in VRAM plus system RAM together, so the runtime keeps the overflow experts in host RAM and moves them across PCIe on demand. It works. Whether it works fast enough for you is a question this page deliberately does not answer with a number we did not measure.
• No headroom — the file alone is within a few GB of total system memory, before the OS, the KV cache and the compute buffers. Treat it as no.
• No — exceeds VRAM plus RAM, so pages come off the SSD.

Two of those rows are not hypothetical. The 6× MI50 machine is the rig in llama.cpp issue #26399, running the 145.63 GiB MXFP4 build "fully GPU-resident across all 6 cards, no CPU expert offload." The dual-Strix-Halo case is issue #26768, two 128 GB Strix Halo boxes joined over RPC to hold the 161.9 GB UD-Q8_K_XL.

If you are choosing a card rather than choosing a model, the honest read is that no consumer GPU is the deciding component here — total system memory is. Our RTX 5090 vs 4090 comparison and the dual-3090 versus single-5090 build math both apply, but for a 284B MoE the DDR5 budget matters more than either. How much system RAM local AI needs is the more relevant page.

What about the KV cache at 1M context?

Budget for it separately, and treat the following as a ceiling rather than a measurement. The checkpoint's wkv projection emits 512 values per token per layer. DeepSeek's own vLLM example runs --kv-cache-dtype fp8, one byte per value. So the upper bound is:

Flash: 43 layers x 512 values x 1 byte = 22,016 bytes/token
       128K tokens -> ~2.8 GB     1M tokens -> ~23 GB
Pro:   61 layers x 512 values x 1 byte = 31,232 bytes/token
       128K tokens -> ~4.0 GB     1M tokens -> ~33 GB

That is a genuine ceiling, not a figure to plan against: config.json sets sliding_window: 128 and a compress_ratios list that alternates 4 and 128 across layers, so most layers store considerably less than the uncompressed bound. The real number is lower and we are not going to invent a compression factor to make it precise.

What Breaks After It Loads?

Sizing is necessary but it is not sufficient, and DeepSeek V4 is three weeks old in the llama.cpp tree. These are open reports, linked so you can check whether they have been fixed since:

The pattern is that CUDA and Metal support landed first and AMD is still catching up on this architecture specifically. If you are buying for DeepSeek V4 and were leaning AMD, read those two ROCm issues before you order — the AMD versus NVIDIA versus Intel comparison covers the general case, but this model's specific gaps are current.

Does Ollama Run DeepSeek V4 Locally?

Not the official model, no. This surprises people, so it is worth being blunt about: ollama.com/library/deepseek-v4-flash is tagged cloud, and all three of its tags are :cloud variants — deepseek-v4-flash:cloud, :0731-cloud and :preview-cloud. ollama run deepseek-v4-flash:cloud sends your prompt to Ollama's servers. Same for deepseek-v4-pro, whose three tags are also cloud-only.

Community pushes do run locally, and their sizes match the GGUF table above exactly — frob/deepseek-v4-flash-0731 lists 284b-a13b-ud-q2_k_xl at 97 GB, ud-q3_k_xl at 128 GB, ud-q4_k_xl at 155 GB, mxfp4 at 156 GB and ud-q8_k_xl at 162 GB. Those are the unsloth and bartowski builds repackaged, so nothing on this page changes.

The practical rule: if the tag ends in -cloud, your hardware is irrelevant and so is this page. If it does not, size it from the table. For everything else in the catalogue, our Ollama model RAM and VRAM table is the general reference.

What This Page Does Not Tell You

• No tokens per second, anywhere. We do not own a GB300 node, a 512 GB Mac Studio or a 6× MI50 rack, and a throughput number for a 284B MoE is worthless without the exact build, backend, context depth and offload split it was taken at. Where a speed figure appears above it is quoted from a linked GitHub issue and attributed to the reporter.
• No quality ranking of the small quants. UD-IQ1_S at 2.32 bpw and UD-Q2_K_XL at 2.72 bpw are 14 GB apart and we have not evaluated either. The bpw column is division, not judgement.
• Sizes drift. When this was written unsloth had published thirteen Flash builds plus two standalone DSpark draft heads, and exactly two Pro-0813 builds. More will appear. Re-check the repo listings before you plan a purchase around a number here.
• Strix Halo's GPU share is configurable. The 128 GB row assumes you have given the GPU a large enough share in BIOS; the default split will not hold a 96 GB model.
• We have not verified the DSpark draft head is optional in every runtime. It ships as a separate GGUF in the unsloth and ggml-org repos, which strongly implies it is, but vLLM and SGLang load it from the same checkpoint as the target model.

FAQ

What are the minimum hardware requirements for DeepSeek V4 Flash?

Roughly 96 GB of total system memory, and that is for the smallest build in existence (unsloth UD-IQ1_S, 82.5 GB) with enough headroom left for the OS and a modest context. For a native-precision build at 155.1 GB, plan on 192 GB. There is no configuration built around a single consumer GPU that holds this model in VRAM — a 5090's 32 GB is 50 GB short of the smallest file that exists.

How much VRAM does DeepSeek V4 Pro need?

More than any single machine you can buy. The smallest published DeepSeek-V4-Pro-0813 build is unsloth's UD-Q4_K_XL at 849.7 GB, the official safetensors are 892.7 GB, and NVIDIA's NVFP4 conversion is 913.1 GB. DeepSeek's own model card serves it on a 4×GB300 node. It cannot be shrunk much further either, because its routed experts are already 4-bit and account for 95.5% of that Q4 file.

DeepSeek V4 Flash is 13B active — can I run it on a 24GB GPU?

No. Activated parameters set how much compute each token costs, not how much memory the model occupies. All 256 routed experts have to be reachable because the six that get picked change every token and nothing predicts which. The memory requirement follows the 284B total, which is 82.5 GB at the very smallest published precision.

Is DeepSeek V4 Flash 284B or 304B parameters?

284B is the model; 304B includes the DSpark speculative-decoding module bolted on top. The repo's last three of 48 shards are three extra MoE layers worth about 19.3B parameters, which is exactly the gap. llama.cpp reports the checkpoint it loads as 284.33B. Both numbers are correct depending on what you are counting.

Why is a Q8 build barely bigger than a Q4 build?

Because the released weights are already 4-bit. Flash's config.json declares "expert_dtype": "fp4", and the routed-expert tensors are stored as packed 4-bit values with one E8M0 block scale per 32 weights. Those experts are 95.5% of a Q4_K_XL file, so a "Q8" build can only upcast the remaining 5% — which is why unsloth's Pro Q8_K_XL (873.4 GB) is 2.8% larger than its Q4_K_XL (849.7 GB) rather than double.

Does the 1M context change the memory requirement?

Yes, on top of every weight figure on this page. As a ceiling, Flash's compressed KV is 43 layers × 512 values × 1 byte per token at the FP8 cache dtype DeepSeek's own example uses, which is about 23 GB at a full million tokens. The real number is lower because compress_ratios compresses most layers further. Separately, llama.cpp issue #27021 reports ROCm failing above 128K context on this architecture, so on AMD the practical ceiling today is lower than the architectural one.

Can I run DeepSeek V4 on a Mac?

Flash, yes, if you bought enough memory. MLX conversions exist at 92.5 GB (OptiQ-2bit), 96.5 GB (2bit-DQ) and 151.5 GB (4bit), so a 256 GB Mac Studio holds the 4-bit build comfortably and a 128 GB machine holds the 2-bit ones. Pro at 849.7 GB does not fit any Mac. Note issue #26694, which reports Flash degenerating into repetition in long agentic chats on Metal, is still open.

Sources

• deepseek-ai/DeepSeek-V4-Flash-0731 — model card, config.json, inference/README.md and the 48-shard file listing (created 31 July 2026)
• deepseek-ai/DeepSeek-V4-Pro-0813 — model card, config.json and the 66-shard file listing (created 13 August 2026)
• ollama.com/library/deepseek-v4-flash and deepseek-v4-pro — the 284B/13B and 1.6T/49B splits, the 1M context figure, and the cloud-only tag list
• unsloth/DeepSeek-V4-Flash-0731-GGUF and unsloth/DeepSeek-V4-Pro-0813-GGUF — GGUF build sizes
• ggml-org, bartowski, mlx-community and nvidia — the remaining Flash builds
• llama.cpp issues #26399, #26537, #26654, #26694, #26768, #27021 and #27155

Repo sizes were read from the Hugging Face model API on 23 August 2026 and tensor dtypes and shapes from the safetensors headers of model-00002-of-00048.safetensors (Flash) and model-00002-of-00066.safetensors (Pro).