IN THIS BREAKDOWN · 10 SECTIONS
You can read 20% of this breakdown.
The paper in one minute
DeepSeek-V2 attacks two different costs with two different changes. Mixture-of-experts layers cut the compute per token. Multi-head latent attention cuts the memory each token occupies in the KV cache, which mixture-of-experts does nothing about and which decides how many requests fit on a GPU at long context.
Multi-head latent attention (MLA). Ordinary attention caches a key and a value vector for every head in every layer. MLA instead projects each token's hidden state down to one latent vector of 512 numbers, caches that, and reconstructs the per-head keys and values from it with up-projection matrices. Because those up-projections can be merged into the query and output weights at inference time, the model never needs to materialize full keys and values. Rotary position embeddings do not survive that merge, so MLA adds a small separate key of 64 numbers, shared across heads, that carries position. Per token per layer, the cache holds 576 numbers instead of the 32,768 that full multi-head attention would need at this size.
DeepSeekMoE. Every feed-forward block except the first becomes 2 shared experts that see every token plus 160 small routed experts, of which 6 are chosen per token. Many small experts let each specialize; shared experts hold common knowledge so the routed ones need not duplicate it. Each token's experts are limited to 3 of the 8 devices that hold them, and three balance losses keep experts, devices and communication even.
The model has 236B parameters with 21B active per token, trained on 8.1 trillion tokens, extended from 4K to 128K context with YaRN, then fine-tuned on 1.5 million instruction examples and trained with reinforcement learning using GRPO. It matched the best open models of mid-2024 on English benchmarks while being far cheaper to train and serve than DeepSeek's earlier dense 67B model.
Research notes: the problem, approach and results
total parameters against parameters activated per token (abstract)
KV cache elements per token per layer with MLA (512 latent + 64 rotary), against 32,768 for full multi-head attention (Section 3.1.2)
maximum generation throughput of DeepSeek 67B, over 50K tokens per second on 8 H800 GPUs (Section 3.2.3)
Bigger language models cost more to train and, at long context, far more to serve, because the KV cache grows with heads, layers and tokens and limits how many requests fit on a GPU. Mixture-of-experts cut training compute but not the cache.
Replace multi-head attention with multi-head latent attention (MLA): compress keys and values into a small shared latent vector, cache only that plus a small decoupled rotary key, and fold the up-projections into the query and output matrices. Use DeepSeekMoE feed-forward layers with fine-grained and shared experts, device-limited routing and three balance losses. Pretrain on 8.1T tokens, extend context to 128K, then SFT and GRPO.
DeepSeek-V2 (236B total, 21B active) reached MMLU 78.5, close to Llama 3 70B's 78.9. Against DeepSeek 67B it used 42.5% fewer GPU-hours per trillion tokens, 93.3% less KV cache (with 6-bit cache quantization) and served over 50K generated tokens per second on one 8-GPU node, 5.76x the older model.
Why it matters to an FDE
At long contexts, the KV cache, not the weights, usually decides how many users a GPU can serve. DeepSeek-V2 is the paper that made the cache itself an architecture target, and its descendants (DeepSeek-V3 and R1) are models customers ask about.
Cache size sets concurrency. A model whose cache is a tenth the size can hold roughly ten times as many concurrent long conversations in the same leftover memory. When comparing models for a long-document or agent workload, compute KV bytes per token from the architecture, not just the parameter count.
Efficiency headlines combine several changes. The paper's 93.3% cache reduction comes from MLA together with quantizing the cache to about 6 bits. MLA alone, at the same precision, is about an 82% reduction against DeepSeek 67B. Both numbers are useful; quoting the wrong one to a customer sets the wrong expectation for their own deployment.
MoE plus MLA needs serving support. Absorbing the up-projections, fine-grained expert kernels and expert parallelism all need engine support. Before committing, check that the customer's serving stack implements MLA efficiently.
Understand the mechanism. Try it on a real problem.
Unlock this breakdown and 290 more papers.
Premium opens every paper in full, plus every answer, concept, course and guide on the site. One payment for six months of access.
6 months · One payment · No auto-renewal
- ◇1 architecture diagram
- </>1 runnable code experiment
- ▦2 results tables
- ?5 interview questions with answers
- 03Key takeaways
How MLA compresses the cache, DeepSeekMoE, routing limits, efficiency and two misreadings
Free account - 04How it works
MLA projections and absorption, decoupled RoPE, the MoE layer, routing, balance, training
Premium - 05The numbers that matter
Base and chat benchmarks against Llama 3 70B and Mixtral 8x22B, and the efficiency figures
Premium - 06Try it yourself
Compute KV cache for MHA, GQA, MQA and MLA, decompose the 93.3%, and simulate device-limited routing
Premium - 07Where it breaks
Engine support, memory for 236B parameters, mixed headline numbers, chat trade-offs and gaps
Premium - 08Using it on a deployment
Sizing a node, estimating concurrency from the latent cache, and checking engine support
Premium - 09Interview angles
Five questions this paper prepares you for, with answer hints
Premium - 10Read next
Where to go from here on this site
Premium
