DeepSeek V4.1 Flash: KV-Cache auf ein Viertel gedrückt - 890 Bytes pro Token

Was als Post-Training-Iteration begann, entpuppt sich laut DeepSeeks Technical Report als Architektur-Neubau: DeepSeek-V4.1-Flash drückt die KV-Cache-Kompression an die Grenze des Machbaren. Hintergrund sind Long-horizon Agent Workflows, deren Kontext immer länger wächst und deren Tool-Calls massive Prefill-Last erzeugen. Der Cache in HBM und externem SSD wird so zum Skalierungs-Nadelöhr.

CED, CSA2, FP4

Das 552B-Parameter-Modell (nativ multimodal, bis 1 Million Token Kontext) setzt auf eine Causal Encoder-Decoder (CED)-Architektur: Der Decoder gewinnt sein globales KV aus den finalen Hidden States des Encoders. Mit YOCO-Logik müssen lange Prompts nur die ersten 20 der 40 Schichten durchlaufen - Prefill aktiviert 8B Parameter pro Token, Decode 16B. Der Cache selbst wird quer zu drei Dimensionen komprimiert (CSA2): 512-dimensionaler Latent-Vektor statt per-Head-Schlüssel, Encoder verschmilzt je 2 Positionen zu einem Cache-Eintrag, und mehrere Schichten teilen sich dasselbe globale KV - das Netz behält nur 3 Encoder-Caches plus 1 Decoder-Cache. Zusammen mit FP4-Quantisierung: rund 890 Bytes pro Token für Cache und Indexer.

Das Ergebnis

Gegenüber DeepSeek-V4-Flash fällt der Runtime-KV-Cache auf ein Viertel, der persistente Cache sogar auf ein Achtel - bei besserer Gesamtqualität. Im Feld misst die Analyse von zartbot nahezu 420 Tokens/s. Der Blog erkennt in CED eine Recursive-Transformer-Variante: Q wird neu projiziert, KV wird in der Rekursion wiederverwendet. Zartbots Fazit nach Lektüre des Reports: “eigentlich sollte es DeepSeek-V5 Flash heißen.”

Quelle: zartbot