DeepSeek V4.1 Flash 1017: 890 bájt KV-cache tokenenként, és mit nyer ezzel egy ágens

A DeepSeek ma reggel kiadta a V4.1 Flash 1017-et: a V4.1 Flash modell dátummal jelölt pillanatképét, amely elérhető a DeepSeek API-n, az OpenRouteren és MIT-licencű súlyokként a Hugging Face-en. A legtöbb hír egy benchmarkkal nyit: 77,0 a DeepSWE v1.1-en, a Claude Opus 5 előtt. A szám valós, de ez a modell legkevésbé érdekes része.

Az érdekes rész az alatta lévő architektúra, amelyet a DeepSeek V4.1 Flash technikai jelentése ír le. Szinte minden tervezési döntés egyetlen kérdésre felel: mennyire lehet kicsi a KV-cache, mielőtt romlik a minőség? A válasz tokenenként 890 bájt. Ez a cikk végigveszi, hogyan jutottak ide, mit tesz hozzá az 1017-es frissítés, mit mondanak és mit nem a benchmarkok, és mennyibe kerül egy ágenst futtatni rajta.

A modell dióhéjban

Miért a KV-cache a valódi szűk keresztmetszet

Egy kódoló ágens nem úgy viselkedik, mint egy chatbot. Minden körben újraküldi a hosszú, egyre növekvő előzményt, hozzáfűzi az eszközök eredményeit, a modell pedig viszonylag keveset ír. A terhelés bemenetnehéz, és ami drága, az a bemenettel skálázódik: a cache-ből kimaradó tokenek prefill-számítása és a memória, amely ezeknek a tokeneknek a KV-cache-ét tárolja. Ha olvastad a context rotról és a compactionről szóló cikkemet, ez ugyanannak a problémának az infrastruktúra-oldala.

A DeepSeek V4 már két ágra bontotta a figyelmet: egy csúszóablakos ágra (SWA), amely csak a legutóbbi tokeneket látja és fix memóriát igényel, és egy tömörített globális ágra, amely a teljes kontextust látja. Hosszú szekvenciáknál a globális ág uralja a memóriát, és ennek a GPU-memóriában (HBM) kell lennie. Ráadásul a prefix-újrahasznosításhoz megőrzött cache-ek SSD-n vagy hosztmemóriában élnek, mozgatásuk pedig sávszélességbe kerül. A V4.1 Flash mindhármat támadja: a számítást, a HBM-et és a tartós tárolást.

Causal Encoder-Decoder: miért csak 8B paramétert használ a prefill

Az első ötlet a YOCO-ból (You Only Cache Once) származik, kibővítve. A 40 réteg egy 20 rétegű kauzális encoderre és egy 20 rétegű decoderre oszlik. Egy hagyományos transzformerben minden réteg a saját rejtett állapotából számolja a kulcsokat és értékeket. Itt a decoder-rétegek nem: a globális KV-bejegyzéseiket közvetlenül az utolsó encoder-réteg rejtett állapotából vetítik ki, decoder-rétegenként külön tanult vetítéssel.

Ebből fakad az aszimmetrikus paraméterszám. Egy prompt-tokenhez a modellnek csak az encoder-felet kell lefuttatnia, hogy előállítsa az összes globális KV-bejegyzést, amelyet a decoder később olvas, ezért aktivál a prefill tokenenként 8B paramétert. Egy generált tokennek mind a 40 rétegen át kell mennie, így a dekódolás 16B-t aktivál. A tanulmány szerint a prefill komplexitása O(N·L/2) O(N·L) helyett: nagyjából fele annyi számítás minden olyan tokenre, amely nincs a cache-ben. Egy ágenshurokban ez minden eszközeredmény.

Van egy bökkenő. A csúszóablakos ág továbbra is rétegenként, a réteg saját rejtett állapotából számolja a kulcsokat és értékeket, így a lokális feldolgozás mély marad. A decoder SWA-cache-ének pontos feltöltéséhez ablak × L/2 tokent kellene újra átfuttatni a decoderen. A DeepSeek válasza a Decoder SWA Bounded Replay: csak az utolsó 128 tokent (az ablakméretet) futtatják újra, és elfogadnak egy közelítő állapotot. A tanulmány szerint a minőségromlás elhanyagolható, és a visszajátszást az utótanítás során szimulálják, hogy a modell megtanuljon együtt élni vele.

CSA2: a legtöbb rétegnek nincs saját cache-e

Egy KV-cache három tengely mentén zsugorítható: kisebb bejegyzésekkel (GQA, vagy MLA a megosztott latens vektorával), kevesebb bejegyzéssel a szekvencia mentén (minden m tokent egybe tömörítve), vagy kevesebb másolattal a rétegek között. A Compressed Sparse Attention 2 a DeepSeek kísérlete arra, hogy mindhármat egyszerre használja. A V4 CSA-jához hasonlóan minden rétegnek van egy könnyű indexelője, amely pontozza a tömörített globális KV-bejegyzéseket, és lekérdezésenként kiválasztja a legjobb 512-t; a lekérdezés ezután erre az 512 bejegyzésre és a saját lokális ablakára figyel.

Az újdonság a rétegek közötti újrahasznosítás. Minden CSA2-réteg statikusan a három mód egyikét kapja:

• A Full mód saját fő KV-t számol, ebből vetíti ki az indexelő kulcsait, és az indexelővel friss top-512 indexeket választ. Ez felel meg egy V4-es CSA-rétegnek.
• A Reindex mód az utolsó Full réteg fő KV-ját és indexelőkulcsait használja újra, de saját indexelő-lekérdezést számol, és saját top-512-t választ. A cache közös, a kiválasztás eltérhet.
• A Reuse mód a cache-t és a legutóbbi indexeket is átveszi, és egyenesen a ritka figyelemre ugrik. Semmilyen indexelési munka.

Mindhárom módban minden réteg saját lekérdezést és saját csúszóablakos KV-t számol, így a rétegek nem válnak egymás másolataivá. Így néz ki a 40 réteg tényleges elrendezése:

Számoljuk össze: a 38 globális figyelmű rétegből csak 4 számol saját fő KV-t, további 4 futtat indexelőt egy közös cache felett, 30 pedig csak újrahasznosít. A decoder egyetlen Full rétege m = 1 tömörítést használ, vagyis a decoder tömörítetlen bejegyzéseket olvas, míg az encoder fél felbontással cache-el. A CSA2 a tömörítőt is egyszerűsíti: a V4 CSA-ja minden tömörített bejegyzést 2m átfedő forrásbejegyzésből és abszolút pozíciós beágyazással épített; a CSA2 elhagyja az átfedést és a pozíciós beágyazást, az indexelőkulcsokat pedig a fő KV vetítésével kapja külön tömörítési út helyett. Kevesebb mozgó alkatrész, gyorsabb tanítás.

A hierarchikus ritka indexelő

Az újrahasznosítás csökkenti az indexelési menetek számát, de minden megmaradt indexelő továbbra is a teljes látható kontextust pontozza, ami a hosszal lineárisan nő. A decoderben ezért az első Full réteg kettős szerepet kap: a saját top-512-je mellett 8 pozíciós blokkokat pontoz a maximális indexpontszámuk szerint, és megtartja a legjobb 2048 blokkot, ami 16 384 pozíciós jelöltkészlet. A későbbi Reindex rétegek csak ezen belül pontoznak. Rögzített készletméret mellett lekérdezésenkénti költségük konstans lesz, nem lineáris a kontextushosszban. Az utótanításban kerül be, és tanításkor és inferenciakor azonosan működik, így a mélyebb indexelők ugyanazzal a korláttal tanulnak, amellyel később dolgoznak.

FP4 KV-cache és a 890 bájtos keret

A harmadik emelő a pontosság. A V4 már FP4-et használt az indexelő lekérdezéseihez és kulcsaihoz; a V4.1 Flash a kvantálástudatos tanítást kiterjeszti a fő KV-cache-re. A formátum E2M1 értékek, 16 csatornánként egy E4M3 skálával, vagyis NVFP4 a második szintű globális skála nélkül. Ezt itt biztonságos elhagyni, mert az értékek korlátosak: RMSNorm és RoPE után az 512 csatornás KV-latens csatornánként nem lépheti túl a √512 ≈ 22,6-ot, tanítás közben a megfigyelt maximum 10 körül volt, a formátum pedig 448 × 6 = 2688-ig ér. A kvantálás RoPE után történik. A csúszóablakos cache FP8-ban marad, mert a tanulmány szerint túl érzékeny a kvantálásra.

A három emelő együtt a globális cache-t, vagyis azt a részt, amelynek a HBM-ben kell maradnia, tokenenként 890 bájtra viszi: ez nagyjából a V4 Flash negyede, és a DeepSeek grafikonja szerint 437-szer kisebb, mint a DeepSeek V1-nél. Teljes, 1M tokenes kontextusnál ez szekvenciánként kb. 0,9 GB globális cache. Ehhez jön az Encoder SWA Bounded Replay: a csúszóablakos állapot egyáltalán nem kerül a tartós prefix-cache-be; cache-találatkor a modell újrafuttatja a cache-elt prefix utolsó 128 tokenjét, és ebből közelítő lokális állapotot épít. Ez a tartós helyigényt SSD-n vagy hosztmemóriában a V4 Flash nagyjából nyolcadára csökkenti.

Rekonstruálható a 890? Nagyjából, olyan feltevések mellett, amelyeket a tanulmány nem részletez. Ha minden fő KV-bejegyzés az 512 csatornás latens 4,5 biten (288 bájt), és minden indexelőkulcs 128 csatorna ugyanígy (72 bájt), akkor a decoder egyetlen közös cache-e m = 1 mellett tokenenként 360 bájt, az encoder három Full rétegének cache-e m = 2 mellett 3 × 180 = 540. Ez kb. 900 bájt, közel a közölt számhoz. Ez az én becslésem, nem a DeepSeek bontása; főleg arra jó, hogy lássuk: a számot az határozza meg, milyen kevés rétegnek van saját cache-e.

A számítási oldal ugyanezt a görbét követi. A tanulmány 2. ábrája szerint a kontextus 256-szoros növelése, 4K-ról 1M tokenre, a tokenenkénti dekódolási FLOP-ot csak kb. negyedével emeli. A dekódolás költsége szinte független a kontextushossztól, és pontosan ez kell egy hosszan futó ágensnek.

Engram, DSpark és egymenetes mHC

Három további komponens kevésbé központi a cache-történetben, de magyarázza a paraméterszámot és a kiszolgálási sebességet:

• Az Engram egy feltételes memóriamodul, amely elválasztja a memorizálást a számítástól: hash-elt n-gram keresések (2-es, 3-as és 4-es rend, nyolc hash-fej, egyenként kb. 16M bejegyzéses táblák) adnak beágyazásokat a reziduális folyamhoz. A 196B paraméter két modulban van az 1. és a 14. rétegnél, FP8-ban tárolva. Mivel a címzés a bemeneti tokenekből determinisztikusan következik, a kiszolgáló stack RDMA-n előtöltheti a sorokat a hosztmemóriából, amíg az első transzformerblokk fut, így ezeknek a paramétereknek nem kell GPU-memória.
• A DSpark a V3 többtokenes előrejelző modulját egy külön tanított spekulatív dekóderre cseréli: három transzformerblokk 128 tokenes ablakkal egy menetben öt pozíciót vázol fel, egy kis Markov-fej modellezi a vázlattokenek közötti függéseket, egy megbízhatósági fej pedig az elfogadást becsli, így az ütemező a pillanatnyi terhelés alapján kérésenként választhatja meg az ellenőrzés hosszát. Az előtanítás után, befagyasztott gerinccel tanítják, és az RL alatt szinkronban tartják, így a rolloutokat is gyorsítja.
• Az egymenetes mHC a V4 többfolyamos reziduális kapcsolatát (négy reziduális folyam) módosítja. Minden blokk most az előző blokk által számolt bemenetkeverési együtthatókat használja, ami megszüntet egy adatfüggést, így egyetlen fúzionált kernel egyszer olvassa és egyszer írja a reziduálist. A tanulmány szerint ez felezi az aktivációs memóriaforgalmat, (4n + 4)·d-ről (2n + 2)·d-re, elhanyagolható minőségvesztéssel.

A képbemenet natív, nem utólag hozzácsavart. Egy DeepSeek-ViT encoder (32 réteg, 14-es patchméret, 2D-RoPE) egy 3 × 3-as pixel-unshuffle-ön keresztül táplálja a gerincet, ami kilencedére csökkenti a vizuális tokenek számát, és kb. 1344 × 1344 pixeles bemenetig működik. A MoE-routerben a szöveges és a képi tokenek külön terheléselosztási eltolást kapnak, így az egyik modalitás nem takarhatja el a szakértők egyenlőtlen terhelését a másikban.

Tanítás: 45T token, ritka figyelem az első lépéstől

Az előtanítás 45T tokenen futott, 7 : 1 arányban tisztán szöveges és multimodális adattal, rögzített 100,6M tokenes batchcsel. A ritka figyelmet a kezdetektől 64K szekvenciahosszon tanították, sűrű bemelegítő szakasz nélkül, és 34T tokennél bővítették 1M-ra. A tanulási ráta 28T tokenig 2,6 × 10⁻⁴ volt, 40T-ig koszinuszgörbén 2,6 × 10⁻⁵-re csökkent, és a végéig ott maradt. A tanulmány nem számol be instabilitásról.

Az optimalizáló beállítása megér egy pillantást, ha magad is tanítasz modelleket. A súlymátrixok Muont használnak, a query- és key-súlyok pedig fejenkénti Muont, így minden figyelemfej saját prekondicionálót kap. A nagy, beágyazásszerű mátrixok (Engram-táblák, tokenbeágyazás, kimeneti fej) nem Adamot használnak, amelynek állapota 196B paraméternél óriási lenne, hanem momentumos frissítést, majd Sinkhorn-kiegyensúlyozást, amely kiegyenlíti a sorok és oszlopok RMS-ét. A DeepSeek szerint ez jobb az Adamnál, és csak egy momentumpuffer kell hozzá. Az eredmény, a V4.1-Flash-Base, tudásban, következtetésben és kódolásban hozza a V4-Pro-Base szintjét, harmadannyi teljes és negyedannyi aktív paraméterrel.

A gondolkodási erőfeszítés mint betanított tárcsa

Az utótanítási recept szándékosan unalmas: felügyelt finomhangolás, RL és on-policy desztilláció, mint a V4-nél, a munka a szintetizált ágensfeladatokba és környezetekbe ment. Egy mechanizmus viszont mindenkinek fontos, aki üzemelteti. RL közben a rendszerprompt tartalmaz egy Reasoning Effort: {effort} sort 1 és 100 közötti értékkel, a jutalomban pedig van egy hosszbüntetés a gondolkodási tokenekre, amelynek együtthatója az erőfeszítés értékével exponenciálisan csökken. A jutalmakat erőfeszítési szintenként normalizálják, így a modell szintenként külön hosszkeretet tanul, nem egyetlen kompromisszumot.

A nyilvános API három előbeállítást kínál, amelyek erre az értékre képeződnek le: max = 100, high = 75, low = 50. Saját üzemeltetésnél nem vagy az előbeállításokhoz kötve: a tanulmány szerint a köztes értékek a betanított szintek között interpolálnak.

Mit változtat az 1017-es frissítés

Az 1017 megtartja az architektúrát, és a viselkedést változtatja. A DeepSeek bejelentése Pareto-javulásról beszél: jobb pontszámok, gyorsabb feladatvégzés és rövidebb kimenet egyszerre, a DeepSeek saját harnessére és olyan ágensekre hangolva, mint a Tencent CodeBuddy. A The Decoder szerint a frissítés teljes projektek nulláról építéséhez önvisszajelzéses megerősítéses tanulást (RLSF) használ, ahol a modell saját magabiztossága vagy önkritikája a jutalomjel. A modellkártya nem részletezi a módszert, ezt tehát hírként kezeld, ne dokumentált tényként.

Íme a számok a modellkártyáról, mind a DeepSeek saját közlése:

A táblázatot két irányból érdemes olvasni. Az elődjéhez képest az 1017 minden sorban javul, a legnagyobbat ott, ahol az ágens terminálban dolgozik vagy teljes programot épít: Terminal-Bench 4.0 +11,1, ProgramBench +8,8, Apex +7,5, HLE +5,8. Az Opus 5-tel szemben vegyes a kép. A Flash nyer a munkafolyamat-jellegű ágensbenchmarkokon (DeepSWE, Automation-Bench, Agents' Last Exam, Apex), és egyértelműen veszít a nehéz következtetésen és a mély szoftverfejlesztésen: 14 pont a HLE-n, 9,5 a Terminal-Bench 4.0-n, 8 a ProgramBench-en, 7 az NL2Repo-n. A technikai jelentés ki is mondja: tudományos jellegű, szakértői tudást igénylő ágensfeladatokon megmarad a lemaradás az óriásmodellekhez képest.

Az igazi hír: költség feladatonként

A rövidebb kimeneteken térül meg a frissítés. A DeepSeek DeepSWE-költséggrafikonja a The Decoder szerint az 1017-et 77,0%-on mutatja, valamivel 0,20 $ alatt feladatonként. Alacsony erőfeszítési szinten is 72% fölött van kb. 0,10 $-ért. Az előző V4.1 Flash 74,2%-ot ért el kb. 0,50 $-ért. Ugyanez a grafikon a GPT-6 Astrát, a Gemini 3.8 Flasht és a Claude Opus 5-öt feladatonként 2 és több mint 10 $ közé teszi. A fenti fenntartás itt is áll: ez a gyártó grafikonja, és a dolláronkénti pontosság a saját feladataidon másképp nézhet ki.

A listaár az OpenRouteren millió bemeneti tokenenként 0,15 $, millió kimeneti tokenenként 0,60 $ és millió cache-olvasásonként 0,003 $, 1M kontextussal és legfeljebb 393 216 kimeneti tokennel. Egy részlet a legtöbb beszámolóból kimarad: az ár napszakfüggő. Hétköznap 01:00 és 04:00, valamint 06:00 és 10:00 UTC között, vagyis a pekingi munkaidőben, mindhárom ár duplázódik. Az ezeken kívül ütemezett batch-feladatok fele annyit fizetnek.

A döntő arány a cache-olvasás és a friss bemenet között van: 50 az 1-hez. Vegyünk egy szemléltető, 50 körös ágensmenetet, körönként 200K tokenes kontextussal, ebből 195K cache-elt prefix, 5K új token és 2K token kimenet. Körönként ez kb. 0,0006 $ cache-olvasás, 0,00075 $ friss bemenet és 0,0012 $ kimenet, vagyis csúcsidőn kívül nagyjából 0,13 $ az egész menet. Ha a prefix eltörik, és semmi sincs cache-ben, csak a bemenet körönként 0,03 $, menetenként 1,50 $: több mint tízszer annyi ugyanazért a munkáért. Az architektúra olcsóvá tette a cache megtartását; hogy ki tudod-e használni, azt a promptod szerkezete dönti el. A prefix stabilan tartásáról a prompt cachingről és routingról szóló útmutatóm szól.

A modellel együtt a DeepSeek megnyitotta saját Search és Fetch API-jait: 1000 sikeres kérésenként 0,75 $, fiókonként másodpercenként legfeljebb 5 kéréssel. A DeepSeek Harnessen, a Claude Code-on vagy a Codexen keresztüli szerveroldali eszközhívások 2026. október végéig ingyenesek.

Meghívás és saját üzemeltetés

Az OpenRouteren keresztül a modell egy szokásos, OpenAI-kompatibilis chat completion. A modellkártya 1,0-s temperature-t és top_p-t, hosszú ágensfutásokhoz pedig legalább 256K-s max_tokens keretet javasol; az erőfeszítési előbeállítás az OpenRouter reasoning paraméterén megy át. A DeepSeek saját API-ján a modell neve deepseek-flash.

// Node 22+, OpenRouter. Rutinkörökhöz alacsony erőfeszítés, nehezekhez high vagy max.
const res = await fetch('https://openrouter.ai/api/v1/chat/completions', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.OPENROUTER_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    model: 'deepseek/deepseek-v4.1-flash-1017',
    reasoning: { effort: 'low' },
    temperature: 1.0,
    top_p: 1.0,
    messages: [
      // Ezt a prefixet tartsd bájtra azonosan minden körben: a cache-olvasás a friss bemenet 1/50-e.
      { role: 'system', content: SYSTEM_PROMPT },
      ...history,
      { role: 'user', content: task },
    ],
  }),
})
const data = await res.json()
console.log(data.choices[0].message.content, data.usage)

A saját üzemeltetés lehetséges, és az MIT-licenc jogilag egyszerűvé teszi, de nem egy GPU-s projekt: nagyjából 750B paraméterrel kell számolni az Engram-táblákkal együtt, plusz egy inferencia-stackkel, amely érti a CED-et, a CSA2-t, az FP4 KV-t és a korlátos visszajátszást. A súlyok repója saját inferenciakódot és konverziós útmutatót ad; az olyan motoroknak, mint a vLLM, általában kell egy kis idő, mire egy új figyelemkialakítást hatékonyan támogatnak. Ha adatvédelmi okból választod ezt az utat, a saját üzemeltetésű LLM-ekről, GDPR-ról és költségről szóló cikk mérlegelései közvetlenül érvényesek. Saját telepítésben az erőfeszítés értékét előbeállítás helyett közvetlenül a rendszerpromptban is megadhatod:

Reasoning Effort: 60 (range 1–100; higher values request more thorough reasoning)

Korlátok, amelyekről érdemes tudni

• Tervezett közelítések. A korlátos visszajátszás csak közelítőleg rekonstruálja a csúszóablakos állapotot, a ritka indexelő pedig rossz 512 bejegyzést is választhat. A DeepSeek saját összegzése mindkettőt a lehetséges minőségromlás forrásaként nevezi meg teszteletlen szélsőséges esetekben, főleg hosszú kontextusú ritka visszakeresésnél és a cache-folytatási határoknál.
• A csúcstól való lemaradás valós. Nehéz következtetésben és szakértői szintű terminálmunkában az Opus 5 jócskán elöl van. A Flash erős alapértelmezés tömeges munkára, nem az erősebb modell helyettesítője a legnehezebb feladatokon.
• Joghatóság. A DeepSeek API-t Kínából üzemeltetik. A kiadás előtti napon a The Decoder arról is beszámolt, hogy Kína szigorítani tervezi a nyílt súlyú modellek közzétételének szabályait, ami a jövőbeli kiadásokat érintheti, a már MIT alatt közzétett súlyokat viszont nem.

Mit kezdenék vele

1. Felvenném a rövid listára a nagy volumenű ágensmunkához: tesztgenerálás, refaktorálás, kódáttekintési körök, adatkinyerés. Itt a legnagyobb a feladatonkénti költségelőny és a legkisebb a minőségi különbség.
2. Futtasd le a saját evaljaidat low és high szinten, mielőtt bármit átállítasz. Az érdekes munkapont a nagyjából fele árú low előbeállítás.
3. Nehézség szerint routolj. Tarts meg egy csúcsmodellt a nehéz esetekre, a tömeget pedig bízd a Flashre, ugyanazzal a mintával, mint a routing-útmutatómban.
4. Tervezz a cache-re és az órára. Ilyen árak mellett a stabil prefix és a csúcsidőn kívüli batch-ütemezés többet ér bármelyik benchmarkpontnál.

A kiadás tágabb tanulsága, hogy a következő árcsökkenések a memóriából jönnek, nem a FLOP-okból. Egy modell, amelynek negyedannyi cache kell, ugyanazon a hardveren négyszer annyi párhuzamos, hosszú kontextusú menetet tud kiszolgálni, és ez teszi lehetővé a 0,20 $-os ágensfeladatokat. Ha segítség kell abban, hol a helye egy ilyen modellnek egy valós rendszerben, az AI engineering oldalon leírom, hogyan dolgozom.

Források

• DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression, technikai jelentés, arXiv:2609.19969
• DeepSeek-V4.1-Flash-1017 modellkártya, Hugging Face
• DeepSeek V4.1 Flash 1017 árak és szolgáltatók, OpenRouter (árak 2026. október 17-i állapot szerint)
• Deepseek V4.1 Flash 1017 beats larger rivals in agentic tasks, The Decoder
• DeepSeek opens V4.1-Flash-1017 weights and $0.75 Search API, AI Weekly
• A DeepSeek bejelentése, X