An infra-oriented diagram of the DeepSeek-V4.1-Flash architecture

DRAFT (unlisted study). Prose below is AI-drafted and awaits a human edit pass — see the disclosure footnote.1

DeepSeek's V4.1-Flash (September 2026) is a 552B-parameter MoE, plus 196B of Engram lookup tables, that activates 8B parameters per prompt token and 16B per generated token. Three ideas do most of the work. A causal encoder–decoder split: the lower 20 layers are the encoder, and the upper 20 layers' global KV cache is projected once from the encoder's output rather than computed per layer, so prefill runs half the network. Compressed Sparse Attention 2: each layer's global attention is statically one of three modes — Full layers build a KV cache and an index, Reindex layers borrow the cache but pick their own top-512, Reuse layers borrow both — so only four of forty layers hold global KV. And Single-Pass mHC: the residual stream is four parallel copies, mixed by per-token coefficients around every sub-layer. Below is the same infra-oriented treatment the DeepSeek-V3 diagram got: the kernels you actually run, with their parameter counts. Primary sources: the V4.1 tech report, the checkpoint's config.json and reference inference/model.py, and the tensor shapes in its safetensors headers.

Reading notes, relative to the DeepSeek-V3 diagram:

Computing the parameter count

The tally in the margin sums the grey parentheticals; hover a row to see which boxes it covers. It has three positions: total, and the parameters touched per token in decode (all 40 layers plus the head) and in prefill (the 20 encoder layers plus the decoder's single KV projection — the decoder body never runs on prompt tokens). The routed experts are 543.6B of the 552B; the attention path of a whole layer is 127M, and a Full layer's CSA2 machinery adds 8–11M on top of that.2

The KV cache

The headline of the tech report is 890 bytes of global KV per token, and it falls straight out of the diagram. Four layers hold a main KV cache of 512 FP4 values with one E4M3 scale per 16 channels (288 bytes per entry) and an indexer key of 128 FP4 values with one E8M0 scale per 32 (68 bytes). The three encoder caches hold one entry per two tokens and the decoder cache one per token, so per token there are 2.5 entries: 2.5 × (288 + 68) = 890. The sliding-window caches are per layer but bounded (128 entries of 528 FP8 bytes each), and are never persisted.

1 Disclosure: this draft study — prose, diagram, and parameter model — was generated by Fable (Claude) from primary sources, and has not yet had a human edit pass. It is not part of the published series.

2 Counting conventions. Tensor shapes were read from the safetensors headers of all 48 shards of the published checkpoint (FP4 experts count two parameters per stored byte) and cross-checked against config.json and inference/model.py. Everything is counted — RMSNorm weights, both router biases, the attention sinks, the mHC coefficient predictors. The backbone (embedding, 40 layers, final norm, head) is then exactly 551,566,180,464 parameters, the advertised 552B; the two Engram modules add exactly 196,928,504,320, the advertised 196B. Excluded: the 485M DeepSeek-ViT vision tower and aligner (a separate input pathway) and the 14.2B DSpark drafter (three extra MoE blocks under mtp.*, trained after pre-training). For the per-token counts we follow DeepSeek's convention: the embedding and Engram table lookups are not counted, the head is. Decode gives 16,130,588,784 ("16B"); prefill gives 7,895,563,064 ("8B").