DeepSeek-V4.1-Flashs KV-Cache-Kompression, bis ins Byte geprüft: 890 Bytes pro Token sind ein Design, kein Wunder

Langlaufende Agenten haben die Ökonomie des Transformer-Servings auf eine spezifische, mechanische Art gebrochen: Sie sind inputlastig. Ein Coding-Agent, der ein Repository liest, Tools aufruft und iteriert, prefüllt Hunderttausende von Token und erzeugt vergleichsweise wenige — die Kosten pro bedienter Session dominieren also die KV-Cache-Bytes, die gespeichert, bewegt und über Runden hinweg warmgehalten werden. DeepSeeks Antwort ist DeepSeek-V4.1-Flash¹: ein multimodaler MoE mit 552B Backbone (plus 196B Speichermodul) und 1M-Token-Kontext, dessen Kopfzahl ein globaler KV-Cache von 890 Bytes pro Token ist — ungefähr 1/4 von DeepSeek-V4-Flash bei gleicher Sequenzlänge in HBM und ungefähr 1/8 im persistenten Speicher. Der Blog inszeniert es als Kostenstory für Agenten; das Paper als Co-Design-Story². Beide Rahmungen stimmen, und keine ist der interessante Teil. Der interessante Teil ist, dass 890 Bytes kein einzelner Trick sind — es ist das Produkt von vier unabhängigen Kompressionsachsen (einer neu strukturierten Encoder-Decoder-Aufteilung, dreifacher Cross-Layer-Wiederverwendung, 4-Bit-Quantisierung mit Norm-Argument und einem Deployment-Trade, der Sliding-Window-Zustand gar nicht mehr persistiert), die jeweils einzeln bekannte Vorarbeit sind, hier aber mit ungewöhnlicher Disziplin komponiert und ab dem ersten Token mittrainiert werden. Dieser Guide nimmt jede Achse bis zur Arithmetik auseinander, prüft, ob die veröffentlichte Konfiguration die Kopfzahl tatsächlich reproduziert, und identifiziert die Stellen, an denen die Komposition brechen könnte. Dieser Artikel wird mit einem interaktiven Architekturdiagramm des kompletten Inference-Stacks ausgeliefert.

1. Warum KV-Bytes Agenten bepreisen

Decode in einem Transformer ist ein bandbreitenbegrenztes Problem: Jedes generierte Token erfordert das erneute Lesen des KV-Caches aus dem HBM, und die FLOPs, die dieses Lesen ermöglicht, sind gegenüber den bewegten Bytes verschwindend wenig. Cache-Bytes zu senken bedeutet daher fast linear, Decode-Latenz zu senken — aber für Agenten ist die größere Einschränkung Kapazität, nicht nur Bandbreite. Die Gewichte dieses Modells sind in Summe groß (552B Backbone-Parameter), aber nur 8B aktivieren pro Token im Prefill und 16B im Decode; der KV-Cache pro Anfrage ist es, der mit der Konkurrenz multipliziert. Bei den beanspruchten 890 B/Token kostet ein voller 1M-Token-Kontext rund 933 MB HBM (890 Bytes x 1.048.576 Token — unsere Berechnung in Zelle 2 unten); die V4-Flash-äquivalente Baseline beim 4-fachen würde rund 3,7 GB pro Kontext verlangen. Der Unterschied ist der Unterschied zwischen Dutzenden und Hunderten paralleler Million-Token-Sessions pro Node — die Zahl, die entscheidet, ob Agent-Workloads außerhalb eines Labors überhaupt servierbar sind.

Persistenz ist die zweite Hälfte der Ökonomie. Ein Multi-Turn-Agent wiederverwendet seinen Präfix über Runden hinweg, der Cache muss also zwischen Runden überleben: In V4 wurden globaler KV und Sliding-Window-KV (SWA) beide persistiert, von LRU-Eviction verwaltet, mit konfigurierter Residenz oberhalb von 72 Stunden — und SWA-KV allein machte knapp die Hälfte des persistenten Caches aus. Für Zustände, deren tatsächliches Wiederverwendungsfenster Minuten innerhalb einer lebenden Session beträgt, ist SSD-Residenz auf 72-Stunden-Zeitskala eine Fehlanpassung; V4s Alternative ("Zero SWA Caching", exakte Neuberechnung) war, so das Paper selbst, in Produktion zu teuer, weil exakte Wiederherstellung von SWA-Zustand über L Schichten das Replay von L x n_win Token erfordert. V4.1s Zug — den wir in Abschnitt 5 bepreisen — ist, SWA-KV gar nicht mehr zu persistieren, ihn in einem Host-DRAM-Pool zu halten, der aus 10% des Hostspeichers pro Maschine provisioniert wird, mit einer TTL von Minuten, und Treffer-freie Fälle durch ein begrenztes, approximatives Replay überlebbar zu machen. Das Design steht oder fällt damit, dass dieses Replay sowohl billig als auch harmlos ist; beide Eigenschaften sind prüfbar, und das Paper selbst markiert die zweite als mathematisch nicht garantiert.

Eine Deflation, bevor die Mechanik beginnt. Die Vergleiche 1/4 und 1/8 gelten gegen DeepSeeks eigenen V4-Flash — eine bereits heftig cache-optimierte Baseline —, nicht gegen einen generischen dichten Transformer, gegenüber dem das Verhältnis weit dramatischer ausfiele (das Paper zitiert separat eine 437-fache Reduktion des globalen KV pro Token gegenüber V1 in seiner Abbildung 1, was generationsübergreifende, marketingnahe Arithmetik ist, kein kontrollierterr Vergleich). Und die 890 zählen nur das globale KV: Pro-Schicht-SWA-KV in FP8 liegt obendrauf, begrenzt durch das Fenster statt durch die Sequenzlänge — real, aber nicht dasselbe wie "890 Bytes und sonst nichts". Unsere Berechnungen in diesem Guide jenseits der 890 selbst stehen alle unter einem expliziten Annahme-Label.

2. CED: Prefill wird ein halbes Modell, und SWA verweigert die Mitarbeit

Die erste Achse ist architektonisch. V4.1-Flash teilt seine 40 kausalen Transformatschichten in einen 20-Schicht-kausalen Encoder und einen 20-Schicht-Decoder (die ersten zwei Schichten sind reines SWA; die übrigen 18 Encoderschichten und alle 20 Decoderschichten tragen den spärlichen globalen Zweig). Der entscheidende Move, im Geist von YOCO geerbt³: Die globalen KV-Einträge des Decoders stammen überhaupt nicht aus Decoder-Hidden-States. Jede Decoderschicht projiziert ihr globales K und V aus dem finalen Hidden State des Encoders mit schichtabhängigen Gewichten — C_l = H_(L/2) W_KV^l und Z_l = H_(L/2) W_Z^l für Schichten oberhalb von L/2, wobei die C des Papers die Haupt-KV-Einträge sind und Z ihre Kompressionsgewichte. Eine geteilte Repräsentation, 20 billige Per-Layer-Projektionen.

Der Ertrag ist Prefill-Asymmetrie. Weil der globale Cache der Decoder-Hälfte eine Projektion einer Größe ist, die die Encoder-Hälfte bereits berechnet hat, fällt die Prefill-Komplexität von O(N x L) auf O(N x L/2 + n_win x L/2), was das Paper zu "effectively halving the overall computation" aufrundet. Von dort kommt auch der Split 8B-Prefill / 16B-Decode: Prefill läuft im Wesentlichen durch die Encoder-Hälfte, Decode durch alles. Für inputlastige Agent-Workloads — Prefill-Token übertreffen generierte Token um Größenordnungen — ist das die richtige Seite, billig zu machen, und es ist die größte Kosten-Asymmetrie des Designs.

Was nicht mitmacht, ist der SWA-Zweig. CED hält Sliding-Window-Attention konventionell und schichtweise über alle Schichten: Das lokale K/V jeder Schicht stammt aus dem Hidden State dieser Schicht. Das ist eine bewusste Entscheidung (sie erhält die Rechentiefe der lokalen KV-Generierung, und gestapelte lokale Fenster sind es, die SWA sein effektives mehrschichtiges Rezeptivfeld geben), aber sie hat eine strukturelle Folge: Decoder-SWA-KV lässt sich nicht aus dem Encoder projizieren — es erfordert das Ausführen der Decoderschichten selbst, womit der Encoder-Abkürzer die Schleife nicht schließt. Das exakte Prefillen von Decoder-SWA-KV erfordert die Verarbeitung von zusätzlichen n_win x L/2 Token, und die exakte Rekonstruktion von SWA-Zustand nach einem Cache-Miss erfordert das Replay von L x n_win Token — der Term, der V4s Zero SWA Caching unwirtschaftlich machte. Hier sitzt der Haken für alles in Abschnitt 5. Das Paper stützt sich auf ein Resultat von Chen et al. (2025) — dass das effektive Rezeptivfeld von SWA viel kleiner ist als das theoretische n_win x L/2 —, um die Begrenzung dieses Replays zu lizenzieren; die Linie beachten: Die Approximation wird durch Vorarbeit aus Messungen lizenziert, nicht durch irgendetwas aus V4.1s eigenem Training.

3. CSA2: drei multiplikative Dimensionen, drei Modi, eine Kadenz

Die zweite Achse ist CSA2, und die klarste Rahmung ihres Beitrags ist diese: Jede Achse ist Vorarbeit. Entry-Size-Kompression sind GQA und MLA; Sequenzkompression (m Token pro Eintrag) ist V4s eigenes CSA; Schichtkompression ist Cross-Layer-Attention. Der eigene Related-Work-Abschnitt des Papers nennt die Vorfahren: IndexCache wiederverwendet Top-K-Indizes über Schichten⁴, YOCO teilt Caches über Decoder-Hälften, CLA-basierte Arbeit (Brandon et al., 2024) teilt KV über Schichten. Was fehlte — und was CSA2 tatsächlich beansprucht — sind alle drei Dimensionen gemeinsam: mit entkoppelter Cache-Freigabe und Index-Wiederverwendung, statisch zugewiesen, sodass das Deployment genau weiß, was zu prefetchen ist.

Jede CSA2-Schicht operiert in einem von drei Modi:

• Full Mode berechnet eigenes Haupt-KV und Indexer-Q, projiziert Indexer-K aus diesem Haupt-KV (ein Kompressionspfad weniger als V4s CSA, das Indexer-K separat aus Hidden States ableitete) und erzeugt frische Top-K-Indizes.
• Reindex Mode wiederverwendet Haupt-KV und Indexer-K der vorigen Schicht, berechnet eigenes Indexer-Q, rescored und erzeugt frisches Top-K.
• Reuse Mode wiederverwendet Haupt-KV und die neuesten Top-K-Indizes und führt überhaupt keine Indexer-Berechnung aus.

Jede Schicht, in jedem Modus, behält ihr eigenes globales Q und SWA-KV — geteilt werden die teuren persistenten Größen. Die statischen Kadenz-Zuweisungen aus der Konfigurationstabelle: Die 18 CSA2-Encoderschichten laufen mit Kompression m=2 (zwei Token pro Eintrag) in drei Gruppen von sechs — eine Full, fünf Reuse. Die 20 Decoderschichten laufen mit m=1 in fünf Gruppen von vier: Die erste Gruppe ist Full + 3 Reuse, die übrigen vier sind Reindex + 3 Reuse. Die Decoder-Kadenz ist der Ort, an dem sich das Rest-Risiko konzentriert — Auswahl kommt an genau fünf Schichten in den Cache (eine Full, vier Reindex), und jede Reuse-Schicht downstream konsumiert sie ungeprüft. Gegenüber V4 sind die Vereinfachungen real: Die überlappenden Quell-Einträge und das absolute Positions-Embedding im CSA-Kompressor sind weg, die Indexer-K-Projektion ist vereinheitlicht, und V4s CSA-HCA-Hybrid ist durch pures CSA2 ersetzt.

Die verbleibenden Indexer-Kosten begrenzt der Hierarchical Sparse Indexer (nur Decoder, in Training und Inferenz identisch angewandt). Die erste Full-Schicht scored den vollständigen kausal sichtbaren Bereich und macht blockweise Kandidatenauswahl — maximal 2.048 Blöcke à 8 Positionen, ein Pool von bis zu 16.384 Kandidatenpositionen. Spätere Reindex-Schichten scoren nur diesen Pool, ihre Indexer-Kosten pro Query sind also konstant, unabhängig von der Kontextlänge. An der Grenze bepreist:

# Cell 4: Hierarchical Sparse Indexer cost bound at 1M context
H, D = 32, 128            # indexer query heads, indexer head dim
S = 1_048_576             # 1M-context visible range
POOL = 2048*8             # 2048 blocks x 8 positions
full_mac = H*D*S
pool_mac = H*D*POOL
print(f"full-range indexer scoring @1M: 32 heads x 128 dims x {S:,} positions = {full_mac:,} MACs")
print(f"candidate-pool scoring:         32 heads x 128 dims x {POOL:,} pool     = {pool_mac:,} MACs")
print(f"pool is {100*POOL/S:.2f}% of the full range -> later Reindex indexers cost is")
print(f"constant per query, independent of context ({full_mac/pool_mac:.1f}x cheaper than full scan)")
print(f"the first Full layer still scans all {S:,} positions: {full_mac:,} MACs, unavoidable")

full-range indexer scoring @1M: 32 heads x 128 dims x 1,048,576 positions = 4,294,967,296 MACs
candidate-pool scoring:         32 heads x 128 dims x 16,384 pool     = 67,108,864 MACs
pool is 1.56% of the full range -> later Reindex indexers cost is
constant per query, independent of context (64.0x cheaper than full scan)
the first Full layer still scans all 1,048,576 positions: 4,294,967,296 MACs, unavoidable

(Unsere Berechnung, /usr/bin/python3, aus der veröffentlichten Indexer-Konfiguration: 32 Heads, Head-Dim 128, Top-k 512, Pool 2.048 x 8.) Die 1,56% sind der ganze Trick: Der Pool ist ein festes Budget, tiefere Indexer hören auf zu fragen, ob der Kontext 4K oder 1M ist. Die Kosten verschwinden nicht — sie konzentrieren sich in der ersten Full-Schicht, die mit 4,29 Milliarden MACs pro Decoder-Seiten-Query-Satz bei 1M Kontext selbst weit von gratis ist — und die Qualität des Pools ist jetzt ein Single Point of Failure für jede Reindex-Schicht darüber. Das verdiente die fünfte Zelle Skepsis: Hierarchisches Pooling macht die durchschnittliche Query billiger, indem es die Pool-Auswahl-Query obligatorisch und ungeprüft macht.

4. FP4: das Norm-Argument, und die Jagd nach dem 890-Byte-Ledger

Die dritte Achse ist Speicherpräzision. V4.1-Flash speichert seinen Haupt-KV-Cache in MXFP4 — dem OCP-Standardformat, E2M1-Payloads mit einem E4M3-Scale pro 16 Kanälen, dem Schema von NVFP4 folgend, aber dessen zweite globale Scale-Stufe bewusst weglassend⁵. Die Rechtfertigung ist ein Norm-Argument, das es ausformuliert zu werden wert ist, weil es die seltene Quantisierungsentscheidung ist, die hergeleitet statt gebenchmarkt ist:

1. Die größte trainierte RMSNorm-Gewichtsmagnitude im Modell liegt bei ungefähr 1.
2. Nach RMS-Normalisierung ist die L2-Norm des 512-Kanal-KV-Latents daher durch sqrt(512) ≈ 22,6 begrenzt.
3. RoPE ist eine Rotation; Rotationen erhalten L2-Normen — der maximale absolute Kanalwert nach der Rotation ist also ebenfalls durch ~22,6 begrenzt.
4. Das Format stellt Magnituden bis E2M1s 448 mal E2M3s größtem Scale 6 = 2688 dar.
5. 2688 / 22,6 ≈ 118,8-facher Headroom gegen die Norm-Schranke — und 2688 / 10 ≈ 268,8-fach gegen die ~10, die im Training maximal beobachtet wurden. Kein globaler Scale nötig; das Format hat Reichweite im Überfluss.

# Cell 3: FP4 range analysis (MXFP4 E2M1 + per-16 E4M3 scale, no global scale)
e2m1_max, e4m3_scale_max = 448.0, 6.0
quant_max = e2m1_max*e4m3_scale_max
print(f"representable max magnitude: E2M1 448 x E4M3 scale 6 = {quant_max:.0f}")
import math
norm_bound = math.sqrt(512)
print(f"L2 norm bound of 512-ch latent after RMS norm (largest weight ~1): sqrt(512) = {norm_bound:.3f}")
print(f"RoPE preserves L2 norm -> max |value| after rotation <= {norm_bound:.3f}")
print(f"headroom vs norm bound: {quant_max/norm_bound:.1f}x")
print(f"headroom vs observed max magnitude ~10 during training: {quant_max/10:.1f}x")
print()
bits_fp4 = 4 + 8/16      # E2M1 4 bits + one E4M3 scale byte per 16 channels
bits_fp8 = 8
print(f"effective bits/element: FP4 {bits_fp4} vs FP8 {bits_fp8} -> {bits_fp8/bits_fp4:.2f}x ('nearly halves')")
ch = 512
per_tok_fp4 = ch*bits_fp4/8 ; per_tok_fp8 = ch*bits_fp8/8
print(f"per-token main K (or V), 512 ch: FP4 {per_tok_fp4:.1f} B vs FP8 {per_tok_fp8:.0f} B")
print(f"per-token K+V: FP4 {2*per_tok_fp4:.1f} B vs FP8 {2*per_tok_fp8:.0f} B ({2*per_tok_fp8/(2*per_tok_fp4):.2f}x)")

representable max magnitude: E2M1 448 x E4M3 scale 6 = 2688
L2 norm bound of 512-ch latent after RMS norm (largest weight ~1): sqrt(512) = 22.627
RoPE preserves L2 norm -> max |value| after rotation <= 22.627
headroom vs norm bound: 118.8x
headroom vs observed max magnitude ~10 during training: 268.8x
 
effective bits/element: FP4 4.5 vs FP8 8 -> 1.78x ('nearly halves')
per-token main K (or V), 512 ch: FP4 288.0 B vs FP8 512 B
per-token K+V: FP4 576.0 B vs FP8 1024 B (1.78x)

(Unsere Berechnung, /usr/bin/python3, aus den Angaben in Abschnitt 2.4.4 des Papers.) Drei deployment-relevante Details, die das Abstract nicht trägt: FP4 ist hier ein Speicher-Format, kein Rechenformat — Werte werden vor der Attention dequantisiert, es wird also keine native FP4-Matmul gebraucht und die Formatwahl bindet die Accelerator-Roadmap nicht; quantisiert wird nach RoPE, weil Prä-RoPE-Quantisierung nur marginale Genauigkeit brachte, aber Decode-Overhead hinzufügte; und der SWA-KV-Cache bleibt FP8, explizit wegen seiner Quantisierungsempfindlichkeit. Das Norm-Argument ist also eine Aussage nur über den globalen Zweig — und es ist genau die Art von Argument, die bricht, wenn ein künftiger Trainingslauf RMSNorm-Gewichte deutlich über 1 produziert, was die Schranke enger ziehen würde, auf der das ganze Format ruht.

Nun die adversariale Frage: Reproduziert die Konfiguration tatsächlich 890 Bytes pro Token? Das Paper veröffentlicht die Komponenten-Dims, aber keinen Byte-Ledger für die 890 — die Zahl erscheint im Abstract und in Abbildung 1 ohne Dekomposition. Wir können jedoch Kandidaten-Buchführungen aus der Konfiguration aufzählen und prüfen, welche nahekommt. Pro Token-Seite (K oder V) einer unkomprimierten 512-Kanal-Schicht kostet MXFP4 0,5 Byte/Kanal plus ein Scale-Byte pro 16 Kanäle: 512 x 0,5 + 512 x 1/16 = 288 B, passend zum Output von Zelle 3. Von dort:

# Cell 1: hunting for a byte ledger consistent with the paper's 890 B/token global KV
FP4_B, SCALE_B, CH = 0.5, 1.0/16, 512    # E2M1: 0.5 B/channel + one E4M3 scale byte per 16 ch
side = CH*FP4_B + CH*SCALE_B             # one token-side (K or V) of ONE uncompressed layer
print(f"per token-side (512 ch), FP4 MXFP4 incl. scales: {side:.0f} B")
pair = 2*side                            # K + V of one uncompressed layer
print(f"K+V of one uncompressed layer: {pair:.0f} B")
 
# encoder: 18 CSA2 layers, m=2 -> entries cover 2 tokens; 3 groups of 6 share one main KV each
enc_group = pair/2                       # m=2 halves per-token cost of the shared tensor
enc = 3*enc_group
print(f"encoder: 3 groups x {enc_group:.0f} B = {enc:.0f} B/token")
 
# candidate A: encoder-only accounting (all decoder global KV somehow amortized/shared)
print(f"candidate A (encoder only): {enc:.0f} B vs paper 890 B -> {890/enc*100-100:+.1f}% off")
 
# candidate B: encoder + ONE decoder main KV (Full layer, m=1, group 1)
decB = enc + pair
print(f"candidate B (enc + 1 decoder main KV): {decB:.0f} B -> {890/decB*100-100:+.1f}% off")
 
# candidate C: encoder + decoder group-1 main KV at FP4 with K/V sharing one latent (512 ch total)
latC = CH*FP4_B + CH*SCALE_B             # 512-ch latent shared by K and V post-projection
decC = enc + latC
print(f"candidate C (enc + 1 decoder 512-ch latent): {decC:.0f} B -> {890/decC*100-100:+.1f}% off")
 
# candidate D: 3 enc groups + 1 shared decoder latent + shared indexer K
# indexer: 32 heads x 128 dim = 4096 ch, FP4, per-16 scales, shared cross-layer
idx = 4096*FP4_B + 4096*SCALE_B
decD = enc + latC
print(f"indexer K, uncompressed FP4 (32x128): {idx:.0f} B -> too large alone; skip in D")
print(f"candidate D (= C): {decD:.0f} B")
print()
print("closest consistent read: 864 B (encoder 3 x 288) is 3.0% below 890;")
print("the residual 26 B/token is not attributable from published config alone.")
print("The paper publishes no per-tensor byte ledger for the 890; all of the")
print("above are OUR assumption-dependent computations from the config table.")

per token-side (512 ch), FP4 MXFP4 incl. scales: 288 B
K+V of one uncompressed layer: 576 B
encoder: 3 groups x 288 B = 864 B/token
candidate A (encoder only): 864 B vs paper 890 B -> +3.0% off
candidate B (enc + 1 decoder main KV): 1440 B -> -38.2% off
candidate C (enc + 1 decoder 512-ch latent): 1152 B -> -22.7% off
indexer K, uncompressed FP4 (32x128): 2304 B -> too large alone; skip in D
candidate D (= C): 1152 B
 
closest consistent read: 864 B (encoder 3 x 288) is 3.0% below 890;
the residual 26 B/token is not attributable from published config alone.
The paper publishes no per-tensor byte ledger for the 890; all of the
above are OUR assumption-dependent computations from the config table.

(Unsere Berechnung, /usr/bin/python3; alle Kandidaten annahmeabhängig.) Das ehrliche Fazit: Eine reine Encoder-Lesart — drei cross-layer-geteilte Haupt-KV-Tensoren bei m=2, je 288 B — landet bei 864 B/Token, 3,0% unter den veröffentlichten 890; der Rest von 26 B/Token gehört plausibel zu irgendeinem Decoder-seitigen Beitrag oder komprimierten Indexer-Anteil, den die Konfigurationstabelle nicht festnageln lässt, und jede der naheliegenden Dekompositionen, die einen vollen unkomprimierten Decoder-Tensor behalten, schießt deutlich darüber hinaus (1.152-1.440 B). Wir können also sagen: Die 890 sind mit der beschriebenen Architektur konsistent, innerhalb weniger Prozent, unter einer Cross-Layer-Sharing-Lesart des Encoders — aber der exakte Ledger ist vom Paper her unterbestimmt, und wer einen HBM-Pool auf diese Zahl budgetiert, sollte eine Marge von ±5% tragen plus einen SWA-KV-Zuschlag obendrauf. Uns ist kein anderer veröffentlichter Versuch dieser Dekomposition bekannt.

5. SWA Bounded Replay: aus einer katastrophalen Einbusse wird eine billige

Die vierte Achse ist ein Deployment-Trade, und sie ist die am ehesten unterschätzte. SWA-Abhängigkeiten akkumulieren über Schichten: Exakte Rekonstruktion des SWA-KV von L Schichten nach einem Miss erfordert das Replay von L x n_win Token — bei L = 40 Schichten und n_win = 128 sind das 5.120 Token volltiefer Neuberechnung. V4s eigener Zero-SWAV-Caching-Vorschlag versuchte genau diese Wiederherstellung und erwies sich, so das Paper, in Produktion als zu teuer. Bounded Replay gibt Exaktheit auf: Es werden nur die jüngsten n_win = 128 Token replayed, SWA auf das Replay-Segment gestutzt — eine Query an Position i attendiert auf SWA-Keys in [max(s, i-W+1), i] bei einem Replay ab s. Die Arithmetik:

# Cell 2: SWA Bounded Replay arithmetic (L=40 layers, n_win=128)
L, W = 40, 128
exact, bounded = L*W, W
print(f"exact SWA reconstruction: L x n_win = {L} x {W} = {exact:,} tokens")
print(f"bounded replay:            n_win    = {W} tokens   ({exact/bounded:.0f}x cut)")
dec_exact = (L//2)*W
print(f"decoder-half exact:        (L/2) x n_win = {L//2} x {W} = {dec_exact:,} -> bounded {W} ({dec_exact/W:.0f}x cut)")
print()
print("replay overhead as % of prefill compute (our computation, naive token-count model):")
for P in (1_000, 8_000, 65_536, 524_288, 1_048_576):
    print(f"  prompt {P:>9,}: bounded {100*W/P:6.3f}%   V4-exact {100*exact/P:7.2f}%")
print()
# cache sizes at 1M tokens
B = 890
mb = B*1_048_576/1e6 ; mib = B*1_048_576/2**20
print(f"global KV @1M tokens: {B} B/token x 1,048,576 = {B*1_048_576:,} B = {mb:.0f} MB = {mib:.1f} MiB")
print(f"V4-Flash-equivalent global KV (4x): {4*mb:.0f} MB ({4*mib:.1f} MiB)")
print()
# how many 1M contexts fit in an 80-GiB HBM remainder (our hardware assumption)
for inst in (80.0, 60.0, 40.0):
    cap = inst*2**30
    n = cap/(B*1_048_576)
    print(f"80→{inst:.0f} GiB HBM pool (weights/activations already resident): {n:.1f} million-token contexts")

exact SWA reconstruction: L x n_win = 40 x 128 = 5,120 tokens
bounded replay:            n_win    = 128 tokens   (40x cut)
decoder-half exact:        (L/2) x n_win = 20 x 128 = 2,560 -> bounded 128 (20x cut)
 
replay overhead as % of prefill compute (our computation, naive token-count model):
  prompt     1,000: bounded 12.800%   V4-exact  512.00%
  prompt     8,000: bounded  1.600%   V4-exact   64.00%
  prompt    65,536: bounded  0.195%   V4-exact    7.81%
  prompt   524,288: bounded  0.024%   V4-exact    0.98%
  prompt 1,048,576: bounded  0.012%   V4-exact    0.49%
 
global KV @1M tokens: 890 B/token x 1,048,576 = 933,232,640 B = 933 MB = 890.0 MiB
V4-Flash-equivalent global KV (4x): 3733 MB (3560.0 MiB)
 
80→80 GiB HBM pool (weights/activations already resident): 92.0 million-token contexts
80→60 GiB HBM pool (weights/activations already resident): 69.0 million-token contexts
80→40 GiB HBM pool (weights/activations already resident): 46.0 million-token contexts

(Unsere Berechnung, /usr/bin/python3; die GiB-Zeilen unterstellen einen HBM-Node der 80-GiB-Klasse mit 40-80 GiB Rest nach Gewichten, Aktivierungen und Engram-Shards — diese Hardware-Aufteilung ist unsere Annahme, nicht die des Papers.) Zwei Lesarten fallen heraus. Erstens die Umkehrung des Trades: Unter exakter Wiederherstellung skalierte die Replay-Kosten mit der Architektur (5.120 Token, 512% des Prefills eines 1K-Prompts — daher "prohibitively expensive"); unter Bounded Replay ist es eine konstante 128 Token, also 12,8% des Prefills eines 1K-Prompts, aber 0,012% bei 1M. Das ist ein neuer Trade-Off-Punkt zwischen Speicher und Rechnung im Designraum, und er ist es, was die Pool-Löschung finanziert. Zweitens wiederholt sich hier die Kapazitätsarithmetik aus Abschnitt 1 konkret: Bei 933 MB pro Million-Token-Kontext passen 92 parallele solcher Kontexte in einen nominalen 80-GiB-HBM-Pool gegenüber grob 23 beim V4-Flash-äquivalenten 3,7 GB — der Konkurrenz-Limiter verschiebt sich um den Faktor vier.

Die Deployment-Form hat drei bewegliche Teile. Encoder SWA Bounded Replay macht Prefix-Caching nur noch vom globalen KV abhängig — bei Global-Hit/SWA-Miss werden die letzten 128 Token des gecachten Präfixes replayed und regenerieren nur SWA-KV, während das gecachte globale KV ohne Neuberechnung wiederverwendet wird. Decoder SWA Bounded Replay begrenzt den Decoder-Forward auf 128 Token, indem die Encoder-Outputs der Replay-Token unter derselben SWA-Stutzung durch die Decoderschichten laufen — das Paper sagt, dies "nearly halves total prefill computation", konsistent mit der CED-Analyse O(N x L/2). Und der DRAM-Pool: SWA-KV verlässt die Persistenz vollständig und lebt in einem verteilten Hostspeicher-Pool, provisioniert aus 10% Host-DRAM pro Maschine, mit einer TTL von Minuten und sofortigem Recycling für neue Sessions, während das globale KV seine garantierte 72-Stunden-Persistenz-Lebensdauer behält. Die eigenen Worte des Papers verdienen hier den letzten Platz: Dieses begrenzte Replay ist der Grundpfeiler — es macht aus einer katastrophalen Einbusse eine gnädige, billige Degradation.

Der Vorbehalt, ebenfalls vom Paper selbst: Der replayte Zustand ist approximativ, und das globale und SWA-KV für das ungecachte Suffix hängen von der Cache-Hit-Position ab — derselbe Prompt, an verschiedenen Cache-Positionen fortgesetzt, produziert Zustände, die mathematisch nicht identisch sind. Das Paper berichtet experimentelle Evidenz, dass die Degradation vernachlässigbar ist, und es hat das Replay im Post-Training simuliert, damit das Modell sich daran anpasst. Das ist eine empirische Lizenz für eine mathematische Approximation — genau die Art von Ding, das hält, bis es nicht mehr hält, wovon Abschnitt 7 handelt.

6. Das Supporting Cast

Vier weitere Komponenten vervollständigen die Effizienzgeschichte, jede einen Absatz Engineering-Respekt verdient:

• Single-Pass mHC. Das Multi-Head-Convolution-Input-Mixing-Design wird so aufgerüstet, dass die Input-Mixing-Koeffizienten um einen Block verschoben werden — jeder Block verwende für seinen Input die Koeffizienten des Vorgängers und sagt die eigenen für den nächsten voraus. Diese Verschiebung macht die Pipeline fusibel: Der Mega-mHC-Deployment-Kernel fusioniert Residual-Update, Input-Mixing und Koeffizienten-Prädiktion in einen Durchgang mit (2n+2)d Aktivierungs-Lese/Schreibzugriffen gegenüber (3n+2)d für die mHC-Form — er halbiert den Aktivierungsspeicher-Verkehr gegenüber der ursprünglichen Multi-Kernel-Implementierung, während das Pretraining den Multi-Kernel-Pfad behält. Der mHC-Expansionsfaktor ist 4, mit 20 Sinkhorn-Knopp-Iterationen.
• Engram. Ein 196-Mrd.-Parameter-Sparse-Conditional-Memory-Modul (zwei Module an den Schichten 1 und 14, nullindiziert), mit 8 Hash-Heads, N-Gram-Ordnungen 2/3/4, gesamter Embedding-Dimension 2048 pro Ordnung, ~16M-Eintrag-Tabellen mit distinkten Primzahlgrößen, FP8-Tabellen und -Projektionen. Die kurze kausale Konvolution des Originaldesigns ist als inferenzseitig nicht lohnend weggelassen; deterministisches Adressieren erlaubt das Prefetchen der Embeddings aus dem Hostspeicher über RDMA, wobei das Prefetch des ersten Moduls die Rechnung im ersten Transformer-Block überlappt. Es entkoppelt Memorisierung von Rechnung — und bringt 196 Mrd. eigene Parameter außerhalb des 552-Mrd.-Backbones unter.
• DSpark. Spekulatives Decoding mit drei Transformer-Blocks, die unter einem 128-Token-Sliding-Window entwerfen, fünf Draft-Positionen pro Durchgang parallel, ein Markov-Head für Draft-Token-Abhängigkeiten und ein Confidence-Head, das die per-Position-Akzeptanz vorhersagt. Der Scheduler wählt die Verifikationslänge aus profilierten Engine-Throughput-Kurven, um den systemweiten Token-Throughput unter Last zu maximieren. Trainiert in einer eigenen Post-Pretraining-Phase mit eingefrorenem Backbone und im Post-Training aligned gehalten, ohne dass DSpark-Gradienten in den Backbone fließen — es ersetzt V3s mittrainierten MTP-Block. Zu beachten, was das Confidence-Scheduling tatsächlich ist: Spekulatives Decoding, als Cluster-Level-Throughput-Politik neu gestimmt, nicht nur als Latenz-Trick pro Anfrage.
• Kernel- und Topologie-Buchführung. Reuse-Schichten laufen mit nur 15 Kernels im Prefill und 11 im Decode — bei speichergebundener Ausführung sind Launch-Anzahlen und fusionierte Lese Latenz. MoE: 1 Shared- + 384 geroutete Experten, 6 aktive pro Token, Experten-Intermediär-Dim 2304, SwiGLU bei 10 geclamped, mit modalitätsspezifischem Auxiliary-Loss-freiem Balancing (getrennte Text/Bild-Korrektur-Biases, Update-Geschwindigkeit 0,001, kleiner Sequenz-Balance-Loss bei 0,0001). Deployment ist EPD-disaggregiert — Encoder-, Prefill- und Decode-Pools skalieren unabhängig. Der Vision-Stack (DeepSeek-ViT von Grund auf trainiert, 2D-RoPE, lineare Patch-Projektion aus Muon-Kompatibilität, Pixel-Unshuffle reduziert visuelle Token um Faktor 9, 32 Schichten, Hidden 1024, Patch 14, plus ein 2-Schicht-MLP-Projektor mit Hidden 5120, multimodal vom Pretraining-Start) speist dieselbe Cache-Maschinerie.

Pretraining-Kontext, für den Check der These "Compression eingetrainiert": 45T multimodale Token, Sparse Attention von Grund auf bei 64K ohne Dense-Warmup, auf 1M erweitert bei 34T, Batch-Größe fest bei 100,6M Token, LR 2,6e-4 bis 28T, Cosine-Decay auf 2,6e-5 zwischen 28T und 40T, gehalten bis 45T. Die Kompression ist nicht nachträglich aufgesetzt — das Modell hat nie einen dichten KV-Cache gekannt. (Self-Hosting-Kostenmathematik für diesen Stack ist hier bewusst out of scope; das behandeln wir separat.)

7. Was brechen könnte

Die Falsifikationssignale, in der Reihenfolge, in der ein skeptischer Betreiber sie testen sollte:

1. CSA2-Auswahl an einem einzigen Punkt. Im Decoder wird Top-K-Auswahl an genau einer Full-Schicht und vier Reindex-Schichten berechnet; jede Reuse-Schicht (15 der 20 Decoderschichten) konsumiert diese Indizes ungeprüft. Ein systematischer Auswahlfehler an der einzelnen Full-Schicht vergiftet den gesamten Downstream-Stack, und die Pool-Wiederverwendung in Reindex verstärkt ihn. Der Limitations-Abschnitt des Papers nennt das explizit: "potential selection errors in CSA2... may still cause capability degradation in untested boundary cases". Der reproduzierbare Test: Needle-Retrieval-Aufgaben, deren Ziel knapp unterhalb der Top-k-Grenze (k=512) bei 512K-1M-Kontext liegt, über viele Seeds — ein Verteilung von Fehlwürfen statt gnädiger Degradation ist die Versagens-Signatur.
2. Positionsabhängigkeit des Bounded Replay. Das Paper stellt — ohne es zu vergraben, was Anerkennung verdient — klar, dass replayte Zustände von der Cache-Hit-Position abhängen und über Positionen mathematisch nicht identisch sind. Das ist direkt testbar: derselbe Prompt, zwei verschiedene Cache-Fortsetzungspunkte, Vergleich der Output-Divergenz. Ein Vendor, dessen Produkt deterministisch-wirkende Agent-Sessions ist, liefert ein System aus, dessen Outputs über Cache-Schedules nur statistisch stabil sind. Diese Divergenz — sollte sie draußen auf irgendeiner Eingabeklasse auftauchen — ist die am wenigsten wegdispensierbare Verwundbarkeit des Designs, weil das Replay strukturell ist: Es gibt keinen Config-Flag, das Exaktheit wiederherstellt, ohne L x n_win erneut zu zahlen.
3. FP4-Fehler bei kleinen Magnituden. E2M1 hat eine 1-Bit-Mantisse; sein relativer Fehler ist am größten, wo Werte klein sind, und kleine Magnituden sind genau dort, wo Langkontext-Attention-Logits und Needle-Retrieval leben. Das Norm-Argument in Abschnitt 4 ist ein Bereichs-Argument — es bescheinigt, dass nichts clippt, und Clipping war nie das Risiko. Die Evidenz für Harmlosigkeit ist QAT plus beobachtete Trainings-Magnituden, und die FP8-Empfindlichkeit des eigenen SWA-Zweigs ist die interne Evidenz, dass das Team weiß, wo die Klippe ist. Ein 512K-1M-Needle-Benchmark mit FP4 gegen eine FP8-KV-Ablation ist der Test; der Limitations-Abschnitt des Papers nennt "sparse retrieval over long contexts and SWA state reconstruction at cache-resumption boundaries" — genau diese beiden Klassen — als eigene Stress-Prioritäten.

8. Fazit und Ehrlichkeit zum Geltungsbereich

Was das Design tatsächlich ist: vier bekannte Kompressionsachsen (YOCO-artiger asymmetrischer Prefill, dreidimensionale Cross-Layer-Wiederverwendung in der IndexCache/CLA-Linie, NVFP4-artige Speicherquantisierung und ein Replay-gegen-Persistenz-Trade), multiplikativ komponiert und von Grund auf mittrainiert, verpackt in Deployment-Maschinerie — ein Speicher-Tier, ein Drafter, fusionierte Kernels, EPD-Disaggregation —, die die Kompression annimmt statt sie zu tolerieren. Die 890 B/Token sind mit der Architektur konsistent (unsere beste Dekomposition: 864, innerhalb von 3,0%), aber aus der veröffentlichten Konfiguration nicht vollständig herleitbar; das 1/4 und 1/8 gelten gegen die eigene optimierte Vorgängergeneration des Vendors; die Benchmark-Paritätsansprüche sind Selbstauskunft des Vendors, neben eingeräumten Lücken (das wissenschaftsorientierte Terminal-Bench 4.0, Multimodal gegen Riesen-Closed-Source) — und "über 95% der realen Aufgaben" ist eine Aussage über deren Task-Verteilung, die niemand von außen ziehen kann. Was Skepsis übersteht: die norm-hergeleitete FP4-Formatwahl, der konstant-kostende Indexer-Pool und die Trade-Arithmetik des Bounded Replay — alles Mechanik, alles prüfbar, alles oben von uns nachzurechnen. Was zu beobachten bleibt: ob die Auswahl der einzelnen Full-Schicht, der positionsabhängige Replay-Zustand und das 1-Bit-Mantissa-Verhalten über langen Kontexten auf Eingaben halten, die dem Evaluations-Suite in nichts ähneln. Das Paper benennt alle drei als ungetestete Grenzen; das ist der korrekte letzte Satz jeder ehrlichen Besprechung.

9. Quellen