D

Public paper breakdown

DeepSeek-V4 Technical Report Explained Step by Step

How V4 makes a million-token context actually affordable — compressed attention (CSA + HCA), a much smaller KV cache, mHC, and Muon — explained with diagrams, not walls of text.

Based on “DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence.” · Read the original

What you’ll learn

  • Why a million tokens is a memory problem, not just a bigger number
  • What the KV cache is — and why it becomes the bottleneck
  • How CSA compresses history, then reads only the useful bits
  • How HCA squeezes harder and reads all of what's left
  • Why V4 alternates CSA and HCA layers
  • Where the savings actually come from
  • What mHC and Muon change — and what they don't
  • How Pro and Flash differ

The problem, in one breath

Reasoning models, big codebases, long tool-use sessions — they all want to keep more in context. But plain attention gets expensive fast as the history grows, in two ways at once.

Attention compute

Every new token has to figure out which of the earlier tokens matter. More history → more comparisons.

KV-cache memory

The model stores each past token's key and value so it doesn't recompute them. That store grows with the sequence.

The whole idea in one line

Shrink the history, look at only the parts that matter, keep a rough global view, and make deep layers propagate cleanly — so a million tokens fit in a budget you can ship.

What's actually new

V4 isn't a rewrite. Most of it is V3 carried forward — the new work is concentrated in attention, residuals, and training.

Kept from DeepSeek-V3

Inherited
  • Transformer backbone
  • DeepSeekMoE feed-forward layers
  • Multi-Token Prediction
  • Auxiliary-loss-free load balancing (tweaked)

New or upgraded in V4

New in V4
  • Hybrid CSA + HCA attention
  • Manifold-Constrained Hyper-Connections (mHC)
  • Muon for most weights
  • Compressed, mixed-precision KV cache
  • FP4 tricks in the indexer and post-training

The whole model, left to right

One token's path through V4. The teal stages are the new work; the muted ones come straight from V3.

Simplified for teaching — CSA and HCA sit on different layers, not side by side on one.

Start with the KV cache

Every token the model has seen leaves behind a key and a value it reuses instead of recomputing. That growing pile is the KV cache — and at a million tokens it, not the math, is what pins you down.

Key point

V4's real trick is making that pile smaller and reading less of it per token — everything below is a version of those two moves.

Plain attention, in five boxes

A 30-second refresher, because CSA and HCA are both edits to this loop. For each new token:

Attention(Q,K,V)=softmax ⁣(QKtopdk)V\operatorname{Attention}(Q, K, V) = \operatorname{softmax}\!\left(\dfrac{Q K^{\text{top}}}{\sqrt{d_k}}\right) V

Attention(Q, K, V) = softmax( Q · Kᵀ / √(d_k) ) · V

K and V are exactly what the cache stores. The cost of scoring and blending grows with how many entries are in there — which is the whole problem at a million tokens.

Compressed Sparse Attention (CSA)

CSA makes two moves: squeeze the history into fewer blocks, then let a cheap indexer pick only the blocks worth reading in full.

Counts in the diagram are illustrative — the shapes show the mechanism, not the paper's configured numbers.

Key point

Compression cuts how many entries exist; sparsity avoids reading all of them. CSA uses both.

The Lightning Indexer, up close

This is the “pick the blocks worth reading” step. It's deliberately cheap — a representative form of its score:

It,s=j=1HIwt,jI  ReLU ⁣(qt,jIksI)I_{t,s} = \sum_{j=1}^{H_I} w^{I}_{t,j}\;\operatorname{ReLU}\!\left(q^{I}_{t,j}\cdot k^{I}_{s}\right)

I(t, s) = Σ_j w_j · ReLU( q_j · k_s )

  1. Cheap queries and keys

    qt,jI,  ksIq^{I}_{t,j},\; k^{I}_{s}

    The current token t gets a few tiny indexer-query heads; every compressed block s carries an indexer key. These are separate from — and far cheaper than — the real attention heads.

  2. Non-negative match, per head

    ReLU(qt,jIksI)\operatorname{ReLU}(q^{I}_{t,j}\cdot k^{I}_{s})

    Each head dot-products with the block's key and passes it through ReLU, so a head can only add to a block's relevance, never subtract.

  3. One score per block

    jwt,jI()\sum_{j} w^{I}_{t,j}(\,\cdot\,)

    A learned weight per head sums them into a single number for each block. That number picks what to look at — it isn't the output itself.

Source note

This mirrors the Lightning Indexer from DeepSeek's sparse-attention line (introduced with V3.2); exact head counts and precision live in the report. It selects candidates — it isn't the final attention, and comparing it to search is just an analogy.

Reading another architecture paper this closely? Upload it and get the same treatment — diagrams, notation, worked steps.

Break down a paper

Heavily Compressed Attention (HCA)

HCA takes the opposite bet: compress much harder, end up with only a handful of blocks, and just read all of them. No picking.

CSA vs HCA in one line

CSA: keep more detail, read a chosen slice. HCA: keep a tiny gist, read all of it. “Dense” here means dense over those few blocks — never over every original token.

Why run both?

Because they fail differently. CSA can miss a relevant block; HCA can blur detail. Alternate them layer by layer and each covers for the other — sharp detail from CSA, broad gist from HCA.

Compression

CSA:
Moderate (~×4)
HCA:
Heavy (~×128)

Sparse selection

CSA:
Yes — top-k
HCA:
No

Core attention over

CSA:
Only the selected blocks
HCA:
All of the (few) blocks

Recent window

CSA:
Yes
HCA:
Yes

Its job

CSA:
Grab the relevant detail
HCA:
Hold a broad global gist

Where it can slip

CSA:
Indexer misses something
HCA:
Compression blurs detail

The payoff, at one million tokens

Versus DeepSeek-V3.2, the report estimates how much compute and cache V4 needs per generated token. Short bars are the point.

Lower is better · DeepSeek-V3.2 = 100% (full track)

  • V4-Pro · inference FLOPs27%

    compute to make the next token

  • V4-Pro · KV-cache size10%

    stored context state

  • V4-Flash · inference FLOPs10%
  • V4-Flash · KV-cache size7%

Reported by DeepSeek in the official technical report; not independently reproduced by Deconstructed. FLOPs are precision-normalized — real latency depends on hardware, kernels, batch size, bandwidth, and caching.

Where the savings come from

Not from CSA alone — it's architecture, precision, and systems work stacked together.

Architecture

  • Compress the KV history along the sequence
  • Top-k sparse retrieval in CSA
  • Heavy compression in HCA
  • Shared key-value MQA + grouped output projections
  • Smaller top-k than V3.2

Precision

  • Mixed KV storage: BF16 for position, FP8 for the rest
  • FP4 math inside the Lightning Indexer
  • FP4 routed-expert weights in post-training
  • Heterogeneous, even on-disk KV for shared prefixes

Systems

  • Fused MoE kernels
  • Overlapped compute, comms, and memory
  • Two-stage contextual parallelism
  • Store-vs-recompute choices for the sliding window

Why it beats V3.2 at long context

V3.2 was already sparse. V4 pushes further on several fronts at once.

Compress before you pick

V3.2 already did sparse attention. V4 compresses the KV history first, so the indexer ranks a smaller, pre-summarized set.

Add a global gist

HCA contributes a tiny, densely-read summary that sits next to CSA's selective detail.

Interleave the two

Alternating CSA and HCA layers gives the model both sharp detail and broad context.

Squeeze precision and I/O

A smaller top-k, mixed-precision KV, a low-precision indexer, and better shared-prefix storage stack on top.

Keep the roles straight

mHC and Muon changed too, but neither shrinks the KV cache — mHC is about residual propagation, Muon is a training optimizer. Different parts of the system.

mHC, in a paragraph

V4 also changes how signal moves between layers. A normal residual carries one stream forward and adds each block's output. Hyper-Connections use several streams and learn to mix them — more expressive, but unconstrained mixing can destabilize a very deep stack. mHC keeps the mixing matrices doubly stochastic, so you get the extra streams without the instability.

Not attention

mHC doesn't pick context or shrink the cache — it's a residual-connection change between layers. Full mHC breakdown →

Muon, in a paragraph

V4 trains most weights with Muon (AdamW still handles embeddings, heads, and norms). Roughly: it keeps momentum, orthogonalizes the matrix update, rescales it, then applies it — which the report links to faster, steadier training on matrix-shaped weights.

Training only

Muon is an optimizer. It doesn't run at inference and doesn't create the context window — it just gets you to better weights.

How the model gets built

Two configs, trained long, then assembled from specialists.

Transformer layers

V4-Pro:
61
V4-Flash:
43

Hidden dimension

V4-Pro:
7168
V4-Flash:
4096

CSA compression rate

V4-Pro:
4
V4-Flash:
4

HCA compression rate

V4-Pro:
128
V4-Flash:
128

CSA top-k

V4-Pro:
1024
V4-Flash:
512

Sliding-window size

V4-Pro:
128
V4-Flash:
128

mHC expansion factor

V4-Pro:
4
V4-Flash:
4

mHC Sinkhorn iterations

V4-Pro:
20
V4-Flash:
20

Total parameters

V4-Pro:
1.6T
V4-Flash:
284B

Activated parameters

V4-Pro:
49B
V4-Flash:
13B

Configuration figures reported by DeepSeek in the official technical report.

Pretraining: Flash on 32T tokens, Pro on 33T. Training starts with short sequences and stretches them stage by stage up to a million tokens — so long context is trained in, not bolted on. (“Native” doesn't mean every task benefits from using all million.)

Post-training: build domain specialists, then distill them into one model.

Common mix-up

These “specialists” are separate teacher models. They're not the routed MoE experts inside a single Transformer layer.

The report also describes reasoning-effort modes — Non-think, Think High, Think Max — which spend more test-time compute for harder problems. Same model, different budgets, not different architectures.

Pro vs Flash

Two separate models with different targets — not the same model at two precisions.

Total parameters

DeepSeek-V4-Pro:
1.6T
DeepSeek-V4-Flash:
284B

Activated per token

DeepSeek-V4-Pro:
49B
DeepSeek-V4-Flash:
13B

Context length

DeepSeek-V4-Pro:
1M tokens
DeepSeek-V4-Flash:
1M tokens

Pretraining tokens

DeepSeek-V4-Pro:
33T
DeepSeek-V4-Flash:
32T

Built for

DeepSeek-V4-Pro:
Max capability
DeepSeek-V4-Flash:
Cheaper inference

Knowledge

DeepSeek-V4-Pro:
Higher
DeepSeek-V4-Flash:
Lower (smaller scale)

Reasoning

DeepSeek-V4-Pro:
Stronger overall
DeepSeek-V4-Flash:
Competitive on some tasks with more thinking budget

Flash isn't a quantized Pro, and matching Pro on a few reasoning tests doesn't make them equivalent. Pro is bigger and pricier; Flash is smaller and much cheaper to run long-context, but weaker on knowledge-heavy work.

What the report doesn't prove

A fair breakdown says where the claims stop. The report does not show that:

  • every million-token prompt is handled with equal accuracy
  • the model perfectly recalls every fact buried in a long context
  • a smaller KV cache means lower latency on every system
  • compressed attention keeps all the original information
  • Pro and Flash are equally capable
  • the reported evals have been independently reproduced

Common confusion points

The questions that trip most people up on a first read of the V4 report.

Got another architecture paper you're wrestling with?

Upload it to Deconstructed for section-by-section explanations, notation, equation walkthroughs, and comparisons.

Sources

Every claim above traces to one of these. Figures attributed to the report are DeepSeek's own estimates, not independently reproduced.

Unofficial derivative papers are left out as primary sources. Engram / “Conditional Memory via Scalable Lookup” may show up as related future research, but it isn't part of the released V4 architecture per the main report.

More public breakdowns

We’re adding new public breakdowns over time. Each one walks through a foundational paper with the same step-by-step style.