DeepSeek-V4-Flash Fits Because Its Experts Are 4-Bit

If you are sizing a machine for DeepSeek-V4-Flash, the number in every headline is the wrong one to budget against. The model activates 13 billion parameters per token, and it holds 284 billion (technical report). The first number sets your speed. The second sets your memory bill. We size Mixture-of-Experts hosts off the second one, and the reason the second one is survivable at all is a single line in the config file: the experts ship in 4 bits.

DeepSeek published DeepSeek-V4-Flash-0731 on 31 July 2026 as the official release superseding the preview, with the architecture and size unchanged (MarkTechPost). The weights are MIT-licensed and the download is free (model card). What follows is the arithmetic behind the memory number, where the popular "runs on a laptop" claim comes apart, and how we changed our host sizing because of it.

The Number Everyone Quotes Is the Wrong Number

Active parameters set the compute per token. Total parameters set the memory bill, because the router can call any expert on any token, so every expert must be resident in memory.

That distinction is the whole post. A router that selects 6 experts out of 256 for each token does not let you keep only 6 experts in memory — it selects a different six on the next token. Every expert has to be resident, or the token stalls on a disk read. ModemGuides puts the consequence plainly: a 13B dense model needs about 8GB at 4-bit precision, while V4-Flash at comparable precision needs roughly twenty times that (hardware reality check). A practitioner thread on the Hugging Face forum compresses it into four words: "Not a 13B memory problem" (discussion).

We now size every mixture-of-experts host off the total parameter count and treat the active count purely as a throughput figure, because on this model the two numbers differ by a factor of 22. That habit costs nothing when the two figures are close and saves a procurement cycle when they are not.

❌ Sizing from the headline: "13B active, so a 24GB card should cover it." ✅ Sizing from the checkpoint: 284B resident weights, so the floor is measured in hundreds of gigabytes and the 24GB card is not in the conversation.

What the Config File Actually Says

The DeepSeek-V4-Flash checkpoint is mixed precision by design: MoE expert weights are stored in FP4 while attention, normalisation and router parameters stay in FP8.

This is not a community quantization applied after release. It is native to the shipped weights, and you can read it directly out of config.json (config):

"expert_dtype": "fp4",
"n_routed_experts": 256,
"num_experts_per_tok": 6,
"n_shared_experts": 1,
"num_hidden_layers": 43,
"hidden_size": 4096,
"moe_intermediate_size": 2048,
"quantization_config": {
  "quant_method": "fp8",
  "fmt": "e4m3",
  "weight_block_size": [128, 128]
}

The vLLM recipe for the model states the same split in prose: expert weights in FP4, the remaining attention, norm and router parameters in FP8 (vLLM recipes). Two dtypes, one checkpoint. Which half dominates decides everything downstream, and that is a question the config answers.

Where the 284 Billion Parameters Live

Expert tensors account for roughly 278 of V4-Flash's 284 billion parameters, which is why the storage format chosen for experts sets almost the entire memory footprint.

The config gives you enough to check this without downloading anything. Each expert is a SwiGLU feed-forward block mapping a hidden size of 4096 through an intermediate size of 2048, across three matrices — gate, up and down. That is 3 × 4096 × 2048, or about 25.2 million parameters per expert. With 256 routed experts plus 1 shared expert, a single layer carries roughly 6.5 billion parameters in experts alone. Across 43 layers, that is about 278 billion.

Against a published total of 284 billion, the experts are approximately 98% of the model. Everything else — attention, embeddings, norms, the router itself — shares the remaining few billion.

Run the same arithmetic on the active path and it reproduces the published figure. Six routed experts plus the one shared expert is 7 active experts per layer, about 176 million parameters, or roughly 7.6 billion across 43 layers. Add the attention stack and embeddings, which are dense and always active, and you land near the 13 billion activated parameters the technical report reports. The config is internally consistent, which is a useful thing to confirm before you trust any number derived from it.

The shape is deliberate rather than incidental. The V4 family pairs a hybrid attention stack — Compressed Sparse Attention and Heavily Compressed Attention — with Manifold-Constrained Hyper-Connections, and the technical report puts the result at 27% of DeepSeek-V3.2's per-token inference FLOPs and 10% of its KV cache at a one-million-token context (technical report). Sparse routing and compressed attention are solving two different problems: routing keeps the compute per token small, compressed attention keeps the context affordable. Neither one shrinks the resident weights, which is precisely why the storage dtype has to do that job separately.

Now apply the dtypes. At half a byte per parameter, 278 billion expert parameters occupy roughly 139GB. The few billion non-expert parameters at one byte each add single-digit gigabytes. Had those same experts shipped in FP8, they would occupy about 278GB; in BF16, well over half a terabyte. The FP4 decision is not a rounding detail. It is the difference between a single high-memory machine and a multi-node deployment.

The Memory Bill in Bytes, Not Parameters

The shipped DeepSeek-V4-Flash checkpoint measures about 167GB on disk, and the smallest quantized build that vendors recommend is 103GB with a 110GB working-memory floor.

Parameter counts are a proxy. Bytes are the constraint, and the byte figures are published. The fused 0731 checkpoints are approximately 167GB on disk versus approximately 160GB for the preview, with the attached speculative decoding draft module accounting for the difference (vLLM recipes).

Below full precision, Unsloth publishes a calibrated ladder. The recommended UD-IQ3_XXS build is 103GB, and their guidance is to have at least 110GB of RAM available, because the file size excludes KV cache and context allocation. The UD-Q8_K_XL build is V4-Flash in full original precision at 162GB (Unsloth docs).

Three numbers are worth carrying into a hardware decision:

Build	File size	Working memory floor
Shipped 0731 checkpoint	~167GB	above the file size
Full-precision GGUF (`UD-Q8_K_XL`)	162GB	above the file size
Recommended 3-bit (`UD-IQ3_XXS`)	103GB	110GB

There is also more than one checkpoint. The vLLM recipe lists four: the default 0731 release with the DSpark draft module, the earlier FP8 preview weights, a DSpark preview build, and an NVFP4 variant published by NVIDIA in which the MoE experts are re-quantized to standard NVFP4 while attention, shared experts, router head and draft module stay FP8. That variant targets Blackwell GPUs, and it carries a caveat worth reading before you pick it: its experts do not support the FP8-only fused MoE kernel, so it falls back to the default backend (vLLM recipes). Picking a checkpoint is therefore a throughput decision as well as a memory one.

The gap between file size and working floor is the part teams forget. A 1M-token context window (technical report) does not come free of charge in memory, and the published file sizes do not include it.

There is a smaller lesson buried in the numbers, and it is the same lesson as the parameter counts. Published totals for this model do not agree — write-ups citing 304 billion parameters circulated alongside the 284 billion figure. The technical report settles it at 284 billion with 13 billion activated, and the vLLM recipe and the vendor spec tables agree. When a headline figure is contested, the file size on disk is the number that will actually stop your deployment, and nobody disputes 167GB.

Why "Runs on a Laptop" Keeps Getting Repeated

Claims that DeepSeek-V4-Flash runs on a 32GB laptop without a GPU conflict with the published build sizes, where the smallest recommended quantization needs a 110GB memory floor.

The claim is everywhere, and the appeal is obvious: 13 billion active parameters sounds like a model that belongs on a developer workstation. We have not tested a 32GB configuration, and the vendor-published numbers argue against it — 110GB is the floor for the smallest build that Unsloth recommends (Unsloth docs). ModemGuides reaches the same conclusion from the hardware side and identifies 128GB machines as the practical target, noting that Apple sells the M3 Ultra Mac Studio at 96GB, which puts the obvious candidate just under the bar (hardware reality check).

Quantizing further is a real lever, but it stops being free. The same analysis measures 2-bit class builds at about 78% top-token agreement against the reference weights. That is a quality decision, not a packaging decision, and it belongs in the evaluation stage rather than the procurement stage. If you are going to trade precision for memory, measure the trade on your own tasks — the same discipline that applies whenever an evaluation harness sits between a model and a score.

What This Changes About How You Size a Host

For mixture-of-experts models, size the host from total parameters and the checkpoint's storage dtype, then use the active parameter count only to predict throughput.

Three practices follow from the arithmetic above.

Read the storage dtype before the parameter count. expert_dtype told us more about the memory bill than the headline 284 billion did, because it applies to 98% of the parameters. A model with fewer total parameters stored in BF16 can easily need more memory than this one.

Treat active parameters as a throughput number. They explain why DeepSeek can serve V4-Flash at $0.14 per million input tokens and $0.28 per million output tokens (API pricing). They explain nothing about what the weights weigh.

Separate the licence question from the hardware question. The MIT licence on these weights is a genuine result, and an open-weight licence settles what you are permitted to do. It does not settle what you are equipped to do. Those are two independent gates, and the second one is decided by the numbers in this post.

The capability behind the interest is real. DeepSeek-V4-Flash-0731 scores 82.7 on Terminal Bench 2.1 against 72.1 for DeepSeek-V4-Pro (Preview), and 54.4 on DeepSWE against 7.3 for its own preview (model card). Simon Willison calls it possibly the best value-per-intelligence model available and notes Artificial Analysis ranking it ahead of MiniMax M3, a 428B model (weblog). None of that changes the byte count, and the byte count is what your purchase order has to satisfy.

This is the same failure mode we wrote about when ARC-AGI-3 measured the harness, not just the model: a number gets attached to a model when it was actually produced by the configuration around it. Here the number is 13 billion, the configuration is a 6-of-256 router, and the thing being measured is speed rather than size. If you are weighing this class of model against a hosted frontier option, our DeepSeek V4 comparison sets out the trade in more detail, and the inference configuration entry covers the settings that move throughput once the weights are resident.

If you are deciding whether a model in this class belongs in your stack, and you want the sizing settled before the hardware is bought rather than after, our team does exactly this kind of evaluation.

Frequently Asked Questions

How much memory does DeepSeek-V4-Flash actually need? Plan for at least 110GB. Unsloth's recommended 3-bit build is 103GB and its guidance is a 110GB memory floor, because file sizes exclude KV cache and context allocation. Full original precision is 162GB (Unsloth docs).

Why does 13B active not mean 13B of memory? Because the router can select any 6 of 256 experts on any token, so all experts must stay resident. Active parameters govern compute per token; total parameters govern the memory bill (hardware reality check).

What does FP4 change in practice? Experts hold roughly 98% of the parameters, so storing them at half a byte instead of one byte roughly halves the resident footprint. The split is native to the checkpoint, not a community re-quantization (vLLM recipes).

Is DeepSeek-V4-Flash really 284B or 304B parameters? The technical report states 284 billion parameters with 13 billion activated, and the vLLM recipe agrees. Higher figures circulated in secondary write-ups. The checkpoint measures about 167GB on disk either way (technical report).

Can I run it without a GPU? We have not tested that configuration, and the published build sizes argue against a 32GB machine. The smallest recommended build needs a 110GB memory floor, which points at 128GB systems rather than laptops (hardware reality check).