Auf einem Monitor läuft eine Ausgabezeile durch: knapp 420 Tokens pro Sekunde, während der Kontext im Hintergrund der Millionengrenze entgegenwächst. Der Autor des Blogs zartbot hält das zunächst für eine gewöhnliche Nachjustierung — ein weiteres Flash-Modell, etwas schneller, etwas günstiger. Seine Einschätzung kippt erst, als die Ankündigung kommt, alle Pro-Modelle der V4-Reihe offline zu nehmen, und kurz darauf der technische Bericht „DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression“ vollständig vorliegt. Laut seiner Darstellung hätte das Modell eher DeepSeek-V5 heißen müssen, so tief greifen die Änderungen in die Architektur.
Was daran schwer wiegt, zeigt ein Bild aus dem Sitzungsalltag. Jedes Mal, wenn ein Sprachmodell Text verarbeitet, legt es für jedes Token eine Art Protokolleintrag an — Key und Value im Attention-Mechanismus. Dieses Protokoll wird bei jedem weiteren Schritt erneut gelesen. Der KV-Cache ist also nichts anderes als die fortlaufende Mitschrift einer Sitzung, und er wächst mit jedem Token mit. Solange ein Gespräch drei Absätze lang ist, fällt das nicht weiter auf.
Sobald aber ein Agent stundenlang Werkzeuge aufruft, Dateien liest und Zwischenergebnisse anhängt, wächst das Protokoll schneller als der eigentliche Inhalt. Wer über Serving-Kosten nachdenkt, landet genau hier: Der teuerste Posten ist dann nicht mehr die Rechenleistung pro Token, sondern das Bewegen und Aufbewahren dieser Mitschrift. Die Komprimierung ist deshalb kein Randdetail, sondern der eigentliche Zweck dieser Version.
Warum Long-Horizon-Agenten den KV-Cache zum Engpass machen
Der Bericht beginnt mit einer nüchternen Beobachtung: Long-horizon-Agenten haben ultra-lange Kontexte von einem Sonderfall zu einer regulären Last gemacht. Solche Abläufe brauchen nicht nur effiziente Verarbeitung langer Sequenzen, sondern auch persistente Speicherung, Wiederverwendung und Übertragung großer KV-Caches. Damit wird Cache-Verwaltung von einem Implementierungsdetail zu einer Grundfähigkeit des Deployments. Rechenleistung, Speicher und Kommunikation werden dadurch stärker belastet.
Die Vorgängerarchitektur kombiniert eine Sparse Attention, die den gesamten Kontext abdeckt, mit einer Sliding-Window-Attention für das lokale Fenster. Das senkt die Rechenkosten langer Sequenzen spürbar. Was bleibt, ist die andere Hälfte des Problems: In langen Kontexten dominiert der globale KV-Cache, wird für Prefix-Reuse persistiert, belegt Host-Speicher und SSD-Kapazität und belastet zusätzlich die Interconnect-Bandbreite beim Verschieben. All das drückt den Durchsatz, erhöht die Deployment-Kosten und begrenzt am Ende, wie lang und wie breit Agenten überhaupt laufen können.
Die Schlussfolgerung im Bericht ist entsprechend schlicht: Der Key-Value-Footprint muss weiter runter, sonst lässt sich das Scaling nicht fortsetzen. Genau hier setzt DeepSeek-V4.1-Flash an. Das Modell hat 552 Milliarden Parameter, verarbeitet multimodal und unterstützt Kontexte bis eine Million Token. Entscheidend ist jedoch nicht die Größe, sondern was mit dem Cache passiert.
Causal Encoder-Decoder: Prefill läuft nur durch die halbe Tiefe
Die auffälligste Änderung betrifft die Arbeitsteilung im Netz. Das Modell hat insgesamt 40 Layer, aber nur die ersten 20 bilden den Encoder, die letzten 20 den Decoder. Der globale KV-Cache des Decoders entsteht, indem die finalen Hidden States des Encoders projiziert werden. Für den Prefill, also das Verarbeiten des eingegebenen Textes, müssen deshalb nur die ersten 20 Layer durchlaufen werden.
Bleib kurz beim Bild der Mitschrift: Bisher musste jede Etage des Hauses das komplette Protokoll selbst führen. Jetzt schreibt ein Vorzimmer die verbindliche Fassung, und die hinteren Etagen lesen daraus. Das klingt nach einer kleinen Umstellung, ist aber der Grund, warum die aktivierten Parameter im Prefill bei etwa 8 Milliarden liegen und im Decode bei etwa 16 Milliarden. Der Autor vergleicht den Ansatz mit der Idee hinter YOCO, also dem Gedanken, dass tiefe Schichten nicht zwingend einen eigenen, vollständigen Cache brauchen.
Für Agenten ist das die richtige Stelle zum Sparen. Diese Workloads sind input-dominiert: Ein langer Prompt mit Werkzeugausgaben kommt herein, die Antwort ist vergleichsweise kurz. Wenn der teure Teil des Vorwärtsdurchlaufs nur noch durch die halbe Tiefe muss, sinkt der Rechenaufwand genau dort, wo er am stärksten weh tut. Der Decode bleibt vollständig und damit qualitativ unbeschnitten.
CSA2: Kompression in vier Richtungen gleichzeitig
Die eigentliche KV-Cache-Komprimierung verteilt sich auf mehrere Dimensionen, die in der Praxis zusammenwirken. Zuerst die Kopfzahl, ähnlich wie bei GQA: Statt für jeden Attention-Kopf eigene Keys und Values zu halten, teilen sich die Köpfe eine gemeinsame latente Repräsentation. Dann die Blockbildung, wie sie aus CSA und HCA bekannt ist. Interessant ist, dass das Team die stark komprimierende HCA-Variante fallen lässt und stattdessen CSA weiterentwickelt — zu CSA2, das zusätzlich über Layer hinweg teilt.
In der Kanal-Dimension nutzt CSA2 einen 512-dimensionalen latenten Vektor, der die Keys und Values aller Attention-Köpfe gemeinsam repräsentiert. Davon entfallen 64 Dimensionen auf RoPE, der Rest auf NoPE. Die Query-Seite arbeitet mit einer Low-Rank-Projektion vom Rang 1280, die Ausgabeprojektion ist in acht Gruppen mit je Rang 1024 aufgeteilt. Übertragen auf die Mitschrift: Es gibt nicht mehr für jeden Zuhörer eine eigene Stenografie, sondern eine gemeinsame Chiffre, die alle lesen können.
In der Sequenz-Dimension fasst der Encoder zwei benachbarte Positionen über gelernte kanalweise Gewichte zu einem einzigen Cache-Eintrag zusammen. Der Decoder behält dagegen Einträge pro Position, weil dort die Auflösung gebraucht wird. In der Layer-Dimension teilen mehrere Schichten denselben globalen KV, sodass im gesamten Netz nur drei Encoder-Kopien und eine Decoder-Kopie übrig bleiben. In der Sprache des Bildes: Aus vielen Einzelheften werden wenige Sammelbände, und ein Teil der Einträge wird gleich doppelt belegt.
Dazu kommt eine numerische Optimierung, die in der Übersicht schnell untergeht: Der KV-Cache läuft in FP4, also mit vier Bit pro Wert. Zusammen mit dem Indexer-Aufwand ergibt das ein Speicherwachstum von rund 890 Byte pro Token. Unterm Strich steht laut Bericht ein Laufzeit-KV-Cache von etwa einem Viertel und ein persistenter KV-Cache von etwa einem Achtel des Vorgängers — eine vierfache Komprimierung, ohne dass die Aufgabenqualität darunter leiden soll.
Sparse Attention braucht einen Indexer, und der kostet selbst
Die Attention selbst kombiniert ein lokales Sliding Window von 128 Token mit globaler, sparse ausgewählter Aufmerksamkeit. Welche Positionen global berücksichtigt werden, entscheidet ein Indexer, der per Top-K 512 Kandidaten auswählt. Dieser Indexer ist selbst ein Teil des Modells mit eigenen Köpfen und Dimensionen, und er ist der Grund, warum die Kompression nicht nur den Haupt-Cache betrifft. Auch die Index-Strukturen müssen gespeichert, quantisiert und bewegt werden.
Ein Detail: Welche Layer als Quellen dienen. Für den globalen Modus sind vier Schichten vorgesehen, für den Voll- plus Reindex-Modus acht, verteilt über die Tiefe des Netzes. Der Kandidatenpool wird aus einer bestimmten Schicht aufgebaut, die Kandidaten selbst werden blockweise verwaltet. Man merkt daran, wie stark diese Architektur inzwischen auf Speicherverhalten hin entworfen ist und nicht mehr allein auf Rechenoperationen.
Der Autor zeichnet die Beschreibung des Causal Encoder-Decoder in seinem Beitrag neu und kommt dabei zu einer Lesart, die deutlich einfacher zu greifen ist als der Originaltext. Er liest die Architektur als eine Art rekursiven Transformer: Q wird im Verlauf der Rekursion verändert, KV wiederverwendet. Wer diese Perspektive einmal hat, erkennt das Muster auch in der Cross-Layer-Kompression wieder — es ist ein Teilen und Weiterreichen, nicht bloß ein Wegwerfen von Information. Auf einen verwandten Aufsatz zu Schleifen und Transformer-Architekturen verweist er dabei ausdrücklich.
Was messbar ist: Durchsatz, Speicher und nahezu lineares Wachstum
Die Zahlen, die der Autor nennt, sind der Grund für seine Einschätzung. Er beobachtet knapp 420 Token pro Sekunde im Betrieb. Wichtiger noch ist das Verhalten über die Länge: Mit wachsendem Kontext steigt der Rechenaufwand im Bereich bis eine Million Token nahezu linear und liegt weit unter dem, was frühere Generationen benötigen. Genau das ist die Voraussetzung dafür, dass lange Agentenläufe nicht an der Komplexitätskurve scheitern.
Daneben stehen Bauteile, die einzeln weniger spektakulär sind, in Summe aber das Bild vervollständigen. Die Residualverbindungen laufen über mehrere Ströme, deren Mischmatrix per Sinkhorn-Iterationen nahe an eine doppelt stochastische Matrix herangeführt wird. Eine spekulative Decoding-Komponente arbeitet mit kleinen Draft-Blöcken, die aus dem Mittel der Residualströme parallele Vorschläge berechnen und über ein Konfidenzmaß entscheiden, wie viel verifiziert wird. Dazu kommen bedingter Speicher sowie ein Vision-Zweig, der Bilder mit Patchgröße 14 verarbeitet und über eine 3×3-Verdichtung auf rund ein Neuntel der Tokenzahl reduziert, mit maximal 1024 visuellen Token pro Bild.
Einordnung: Was das konkret bedeutet
Für den Betrieb ist die wichtigste Konsequenz die Verschiebung des Engpasses. Wenn der persistente KV-Cache auf ein Achtel schrumpft, passen deutlich mehr Prefixe dauerhaft auf die vorhandene SSD, und Prefix-Reuse wird von einer Optimierung zu einer Selbstverständlichkeit. Zusammen mit dem halbierten Prefill-Durchlauf senkt das die Kosten genau jener Last, die Agentenprodukte dominieren: viel Eingabe, wenig Ausgabe, viele Werkzeugaufrufe, sehr lange Sitzungen. Mehr parallele Agenten pro Knoten sind damit keine Frage besserer Hardware, sondern besserer Cache-Architektur.
Ein Vorbehalt bleibt. FP4 im KV-Cache und das Teilen von Keys und Values über Schichten hinweg sind bewusste Approximationen. Der Bericht behauptet hohe Qualität bei den Aufgaben, und der Autor bestätigt das aus seiner Nutzung — aber die Grenze verläuft pro Workload unterschiedlich. Wer feingranulare Numerik, seltene Randfälle oder exakte Reproduzierbarkeit braucht, sollte messen statt übernehmen. Der Indexer für die Sparse Attention fügt außerdem eigene Buchführung hinzu, die man in Speicherbudgets und Profiling einrechnen muss.
Das reicht über ein einzelnes Modell hinaus. Lange Zeit wurde Sprachmodell-Effizienz in FLOPs diskutiert; inzwischen entscheidet der Speicher, genauer: die Bewegung und Haltung von Zwischenzuständen. Für Systeme in dieser Phase zählen konkrete Kennzahlen: Byte an KV-Cache pro Token und pro Kontextlänge, Trefferquote bei Prefix-Reuse, Durchsatz pro GB HBM. DeepSeek-V4.1-Flash ist in dieser Lesart kein schnelleres Modell, sondern ein Beleg dafür, dass KV-Cache-Komprimierung inzwischen zu den Kernaufgaben im Systembau gehört.
Quelle: zartbot.github.io
