DeepSeek V4.1-Flash, Explained Like You’re New: KV Caches, MoE, and the 890-Byte Trick

Deep­Seed­ed? No — Deep­Seek. In Sep­tem­ber 2026 the Chi­nese AI lab released a paper titled “Deep­Seek-V4.1-Flash: Push­ing the Lim­its of KV Cache Com­pres­sion,” and the name does not odd­ly over­sell it: the whole paper is about mak­ing a giant lan­guage mod­el cheap­er to run by shrink­ing some­thing called the KV cache. If that phrase means noth­ing to you, good — this post explains every term from scratch, the way I wish some­one had explained it to me.

The vocab­u­lary you need first

Token

LLMs do not read words; they read tokens — short chunks of text (a word, part of a word, or a punc­tu­ation mark) con­vert­ed to num­bers. “Chat­ting” might be 2–3 tokens. Every price quote and con­text win­dow in AI is mea­sured in tokens.

Con­text win­dow

The con­text win­dow is how much text the mod­el can “see” at once — its work­ing mem­o­ry. V4.1-Flash han­dles up to one mil­lion tokens, rough­ly 1,500 pages. Old­er mod­els han­dled a few thou­sand, which is why early chat­bots for­got what you said ten mes­sages ago.

Atten­tion (and why it needs a cache)

The core operation inside a trans­former is attention: for each new token, the mod­el looks back at all pre­vi­ous tokens and decides which ones mat­ter for pre­dict­ing what comes next. To do this effi­cient­ly, the mod­el stores a com­pact sum­ma­ry of every past token so it never has to recon­struct them. Those sum­maries come in two flavors — keys (K) and val­ues (V) — and the col­lec­tion of them for the whole con­ver­sa­tion is the KV cache.

Here is the prob­lem the paper attacks: the KV cache grows with every token you feed the mod­el. A mil­lion-token con­ver­sa­tion means a mil­lion-token-sized cache. That cache has to live some­where, and “some­where” is expen­sive hard­ware.

HBM and SSD

HBM (High Band­width Mem­o­ry) is the extremely fast, extremely expen­sive mem­o­ry stacked on top of the GPU itself. The active KV cache must live here, or every gen­er­at­ed word stalls. SSD stor­age is the slow, cheap tier used to save caches of pre­vi­ous con­ver­sa­tions so they can be resumed with­out recom­pu­ta­tion. HBM capac­i­ty is often the real bot­tle­neck on how many users a server can serve.

Prefill vs decode

Serv­ing a request has two phases. Prefill: read the entire prompt (all those tokens of con­ver­sa­tion his­to­ry) and build the KV cache. Decode: gen­er­ate the answer one token at a time, reusing that cache. Agent work­loads — where an AI reads files, tool results, and logs before emit­ting a short answer — are input-heavy: huge prefill, small decode. Deep­Seek’s insi­ght: opti­mize each phase separately.

Mix­ture-of-Experts (MoE)

A dense acti­vates every para­me­ter for every token. A Mix­ture-of-Experts model con­tains many “expert” sub-net­works and routes each token to only a few of them. V4.1-Flash has 552B total para­me­ters but acti­vates only a slice per token — big brain, small effort. That is how it gets flag­ship-class qual­i­ty with pri­ces that embar­rass Western labs.

The big idea: a Causal Encoder–Decoder

Most LLMs today are one stack of iden­ti­cal lay­ers that both reads your prompt and writes the answer. V4.1-Flash splits the job. Its 40 lay­ers divide into a 20-layer causal encoder that pro­cesses your input, and a 20-layer decoder that gen­er­ates out­put. “Causal” means the encoder still only sees left-to-right (no peek­ing at future tokens), pre­serv­ing nor­mal LLM behavior.

Why split? Because read­ing and writ­ing have dif­fer­ent costs. The encoder run is cheap — only 8B para­me­ters acti­vate per token dur­ing prefill. The decoder is heav­ier — 16B per token dur­ing decode. Read more than you write? You pay the read price, not the write price. The paper cred­its the YOCO (“You Only Cache Once”) line of research as ins­pi­ra­tion for this design.

Com­pressed Sparse Atten­tion 2 (CSA2)

Next trick: stop every lay­er from keep­ing its own full KV cache. CSA2 assigns each of the decoder’s atten­tion layers one of three roles:

  • Full: a “pro­duc­er” lay­er. It reads the whole his­to­ry, builds the glob­al KV cache, and selects the top-k most rel­e­vant pas­sages (the “Top-K” sparse atten­tion indices).
  • Reindex: a “borrow­er with opin­ions.” It reuses the pro­duc­er’s cached KV but runs its own small scout to pick a fresh set of rel­e­vant positions.
  • Reuse: a “full bor­row­er.” It takes both the cached KV and the position choic­es from an ear­li­er lay­er, skip­ping the search entirely.

Every lay­er still keeps a small slid­ing win­dow — a short-term mem­o­ry of the last ~128 tokens — so local text flows remain per­fect­ly pre­cise. The huge glob­al cache exists once instead of twenty times.

FP4 stor­age

Mod­els nor­mal­ly cache keys and val­ues in 16-bit num­bers. V4.1-Flash trains from the start to store its glob­al cache in FP4 — four bits, a 4× size cut — using quan­ti­za­tion-aware train­ing (the mod­el learns to live with the low­er pre­ci­sion rather than hav­ing it imposed after­wards). The slid­ing win­dow stays at FP8 because the authors mea­sured that squeez­ing it fur­ther hurts quality.

SWA Bound­ed Replay

When an old con­ver­sa­tion resumes from SSD, the slid­ing-win­dow state is nor­mal­ly gone (it changes every turn, so nobody stores it). Exact­ly rebuild­ing it would mean re-reading thou­sands of tokens through every lay­er. SWA Bounded Replay instead recon­structs it approx­i­mate­ly — replay­ing just the most recent 128 tokens per lay­er — which the paper reports costs almost no quality.

The rest of the novelty pile

The paper also men­tions Engram con­di­tion­al mem­o­ry (a 196B-param­e­ter look­up table the mod­el consults sparse­ly for facts and pat­terns) and DSpark spec­u­la­tive decod­ing (a small draft­er proposes sev­er­al tokens at once and the big mod­el ver­i­fies them in batch — same answer, faster). These mat­ter, but the KV-cache work is the headline.

Why the num­bers are a big deal

  • Glob­al KV cache: 890 bytes per token in HBM — about 1/4 of its pre­de­ces­sor V4-Flash, despite being smarter.
  • Per­sis­tent SSD cache foot­print: about 1/8 of the pre­vi­ous gen­er­a­tion.
  • Decode cost across a 4K → 1M token con­text: grows by only ~25%, where old­er mod­els bal­loon.
  • Trained on 45 tril­lion tokens, with rein­force­ment-learn­ing post-train­ing that pushed it ahead of Deep­Seek’s own flag­ship V4-Pro on sev­er­al bench­marks — for less money.

Deep­Seek is live with it on their API (mod­el name deepseek-flash), retired the pre­vi­ous gen­er­a­tion, and is rout­ing V4-Pro traf­fic to this small­er, cheap­er model. Pub­lic weights are on Hug­ging Face.

The one-sen­tence takeaway

Deep­Seek-V4.1-Flash’s paper argues that the road to cheap mil­lion-token AI agents is not a big­ger GPU — it is stop­ping every lay­er from hoard­ing its own copy of the con­ver­sa­tion. Share the cache, shrink it to four bits, make read­ing cheap, and rebuild the small stuff only when asked. The rest of the indus­try is going to be copy­ing this play­book.

Leave a Reply

Your email address will not be published. Required fields are marked *