DeepSeek-V4.1-Flash

Reading input and writing output are different jobs

Prefill processes the tokens already in the input and prepares the cache for generation. Decode generates new tokens one at a time. In an agent loop, a long tool result creates new prefill work even when the next instruction the model writes is short.

Imagine a workflow that reads 10,000 input tokens and writes 100 output tokens each round. Making each input token cheaper affects a hundred times as many tokens as making each output token cheaper. That does not predict total time, because prefill can process many tokens in parallel and decode cannot, but it shows where to start measuring.

The launch describes an uneven split: 8 billion active parameters per token during prefill and 16 billion during decode. These count the parameters that take part in computation, not the 552 billion stored in the backbone. [1]

Building the decoder’s memory from the encoder

The model card describes 40 layers split into two halves: a 20-layer causal encoder and a 20-layer decoder. The decoder’s global cache entries are computed by projecting the encoder’s final outputs, so old prompt tokens do not have to pass through the whole decoder. Each decoder layer’s local sliding-window state still requires extra computation. [2]

Think of a research team that prepares a structured dossier once, after which several readers each consult a view derived from it. Building the dossier has to preserve what those readers will need later. Here the dossier and the views are learned, and the encoder is causal: when it processes a token, it cannot use later tokens.

As a result, most long-prompt tokens skip the full decoder, while generated tokens still go through the whole model. The design shifts the balance between input work and output work; it does not make every token cheaper.

Sharing the cache across layers

DeepSeek-V4 compressed the cache along the sequence. V4.1’s Compressed Sparse Attention 2 (CSA2) also shares global cache entries between layers. A layer runs in one of three modes. In Full mode, it computes its own cache entries and its own selection of which entries to read. In Reindex mode, it shares another layer’s entries but makes a fresh selection. In Reuse mode, it shares both. Every layer keeps its own queries and its own local-window state. [3]

The figure models a simple, uniform cache. Sixteen layers that each store 4,096 entries of 128 numbers at 8 bits need 4,096 × 16 × 128 × 1 byte = 8,388,608 bytes, or 8 MiB. If each group of four layers shares one copy, the global cache falls to 2 MiB. The calculation assumes perfectly uniform sharing; the real model assigns layers differently and stores additional data.

Sharing the selection saves search work; sharing the entries saves storage. They are separate decisions. A layer can reuse another layer’s records yet ask its own question about which ones matter, which is exactly what Reindex mode does.

Fast memory, persistent storage and recomputation

The release distinguishes memory on the accelerator itself, its high-bandwidth memory (HBM), from a persistent cache kept in the host computer’s memory or on SSD, which lets a server reuse work across requests. It reports savings for each against V4-Flash separately. Merging them into one “memory saved” number would hide an important difference. [1]

CSA2 stores its main cache entries in a 4-bit floating-point format (FP4). For the local-window state, the model uses bounded replay: when that state is missing, it recomputes a recent stretch of tokens instead of storing the state permanently. The recomputation is approximate; it does not exactly reproduce what processing the full history would have given. [3]

Take a hypothetical server. Keeping one gigabyte of reusable global cache may spare it from rereading a long document. Keeping the local state as well would reduce recomputation further but use more storage. Recomputing a short recent stretch spends arithmetic to save storage and transfer. Which choice wins depends on how often the same context is reused.

Several mechanisms in one release

The model card also documents a vision encoder and projector; Engram, a conditional memory read by looking up token sequences; revised mixing of the residual streams; and DSpark, a speculative-decoding method. These are separate components. Image input, memory lookup, stream mixing and draft generation should not be credited to cache sharing. [2]

The page’s cache formula is entries × numbers per entry × stored layer copies × bits per number. It is a checklist for seeing what an optimization changes. It leaves out the weights on purpose, because a smaller conversation cache does nothing to shrink hundreds of billions of parameters.

When a workload has many long tool results, input processing and cache reuse can dominate. When a short question gets a long answer, decoding may dominate instead. The same model can be in either situation, so a performance claim needs the workload, the cache-reuse assumptions and the number precision stated beside it.

Simplifications and limits

• The cache figure uses made-up uniform sizes and cannot estimate the release’s total runtime memory.
• Bounded replay reconstructs the local state approximately; it does not exactly recompute the full history.
• The active parameter counts for prefill and decode are not the memory needed to store the weights.

Follow the idea

DeepSeek-V2DeepSeek-V3.2 / ExpDeepSeek-V4

Sources and further reading

Primary papers, model cards, and release posts. Facts describe the versions named here; the interactive calculations are teaching models. Research cutoff: October 3, 2026.

1. Official DeepSeek-V4.1-Flash releaseSeptember 10 release, open-weight link, active parameter counts and separate HBM/SSD comparisons.
2. Official DeepSeek-V4.1-Flash model cardCausal encoder–decoder layout, multimodal input, additional components and MIT license.
3. DeepSeek-V4.1-Flash technical reportSections 2.2–2.4 and 3.2: CSA2 modes, FP4 main KV and approximate bounded replay.