KITE: Das Modell skalieren, die KV-Rechnung einfrieren — welche Prefill-Invariante arXiv:2609.27294 wirklich beweist (und was nicht)

Das Teuerste, was ein Sprachmodell pro frischem Token tut — an FLOPs, an Bandbreite und an der HBM-Rechnung, die beiden folgt —, ist nicht das Denken. Es ist das Schreiben von Attention-Keys und -Values. KV-Zustand wird von den eigenen Schichten des Modells produziert, deshalb ist die Kopplung im Standard-Fall brutal: Wächst das Modell, zieht jeder frische Prompt-Token mehr und breitere Schichten durch den Prefill-Durchlauf und schreibt einen fetteren KV-Cache — zum Schreibpreis, den die eigene Memory-Tier vorgibt. arXiv:2609.27294, „KITE: KV-Invariant Transformer Expansion for Efficient Agentic LLM Scaling" (Hu, Wei, Zhou, Zhou, Li, Chen, Li, Wang, Zhu, Zhang, Jiang — StepFun, eingereicht am 23. September 2026), ist der Versuch, diese Kopplung auf Architekturebene zu brechen: das Modell skalieren, die KV-Rechnung einfrieren¹.

Die Idee, instantiiert als Step Scale Transformer (SST), ist ein Zwei-Turm-Decoder. Ein kleiner Turm — der Prefiller — produziert allein die Keys und Values jeder Schicht. Ein zweiter Turm — der Decoder — schreibt überhaupt kein KV; er berechnet nur seine eigenen token-lokalen Queries und liest Schicht für Schicht den Cache des Prefillers. Die gesamte neue Kapazität lebt im lesenden, nicht im schreibenden Turm. Da der Prefill-KV nur vom Prefiller kommt, lautet der Anspruch des Papiers strukturell: Prefill-Bill-Invarianz. Bulk-Prompt-Verarbeitung ankert an der Geometrie des kleinen Turms, egal wie groß der Reader wächst.

Diesen Anspruch ernst zu nehmen lohnt sich — und es lohnt sich, ihn über das Abstract hinaus zu zerlegen, denn die Schlagzeile des Abstracts — ein 67B-MoE-SST mit 2,15B aktiven Parametern pro Decode-Token schlägt 47B- und 63B-Vergleichsmodelle beim Training-Loss bei vergleichbarer kumulativer Rechenleistung — ist eine Proxy-Geschichte, keine Serving-Geschichte. Dieser Guide verifiziert jede Zahl am Primärtext, rechnet die KV-Pin-Identität und ein Fleet-Gegenmodell in Python durch — und räumt den drei Dingen, die die Invariante nicht kauft, gleichberechtigte Hauptabschnitte ein: Reader-Writer-Co-Training-Risiko, Loss-gegen-Capability und Decode-seitige Attention-FLOPs. Im Tiering-Thread, den wir hier seit Monaten bauen, ist das das Architektur-Seitenstück zur Memory-Frage: was, wenn das Modell selbst aufhört, die heißen Daten wachsen zu lassen?

1. Die Architektur — und was wirklich invariant ist

Auf Schichtebene ist SST nicht exotisch. Jeder Turm ist ein Standard-Transformer-Stack — im Experiment je 18 Schichten, Hidden-Weite 2.304, MoE-Feed-Forwards (512 geroutete Experten, 8 gewählt), das gleiche SSSF-Aufmerksamkeitsmuster (Sliding + Full) wie die ganze Modellfamilie, ein geteiltes Embedding und ein geteilter Output-Head, nicht getied². Der Trick ist die Arbeitsteilung. Der Prefiller läuft zuerst über die volle Sequenz und produziert layer-wise K und V. Jeder Decoder-Block berechnet danach nur eine Query aus seinem eigenen Hidden State und attendiert über das KV des Prefillers auf der korrespondierenden Schicht — unter der originalen kausalen Maske. Residual-Stream, FFN/MoE-Arbeit und eine parameterfreie RMSNorm-„Entry-Bridge" (Embedding plus finaler Prefiller-State) des Decoders sind alle token-lokal: Gegeben die Ausgaben des Prefillers hängt keine Decoder-Position von einer anderen Decoder-Position ab².

Dieser letzte Satz ist die tragende Einschränkung, und das Papier formuliert sie selbst als Randbedingung des ganzen Paradigmas: Die zukünftige KV-Produktion darf nicht von historischen Decoder-Zuständen abhängen². Die Invariante ist strukturell, keine eingefrorenen Gewichte — der Prefiller trainiert weiter:

• Prefill. Nur der Prefiller verarbeitet den Prompt und schreibt den KV-Cache. Der Decoder rechnet nur die finale Prompt-Position (für das erste Output-Token); alles andere, was er tut, ist token-lokal, Zwischenpositionen werden einfach weggelassen. Bulk-Prefill-Rechenleistung gleich der Rechenleistung des kleinen Turms.
• Decode. Jeder neue Token durchläuft beide Türme — der Prefiller erweitert den KV-Cache, der Decoder liest ihn und sagt das nächste Token voraus.
• Training. Beide Türme trainieren nach der Expansion gemeinsam; Gradienten erreichen den Prefiller durch das wiederverwendete KV, nichts ist eingefroren².

Die Invariante ist also präzise: Die Prefill-KV-Rechnung ist auf das layers x kv_heads x head_dim des Prefillers festgenagelt — unabhängig von der Reader-Kapazität. Die eigene Parameter-Buchhaltung des Papiers macht die Trennung explizit: Nur der Prefiller enthält K/V-Projektionen in der effektiven Architektur².

2. Der Anspruch, am Primärtext verifiziert

Die Skalierungs-Leiter hält Tokenizer, Datenrezept und Trainingsprotokoll identisch und zählt kumulative Trainingsrechenleistung — beide Trainingsstufen für SST, da das Modell von einer 33,8B-Quelle upgecycelt wird (rund 168B Quell-Tokens plus 222,55B Fortführungs-Tokens, zusammen 390,54B)². Ihr gegenüber stehen zwei klassische, from scratch trainierte Transformers derselben Familie: 47B (1,48B aktiv pro Decode-Token, 443,16B Tokens) und 63B (2,02B aktiv, 334,62B Tokens). Alle drei Endpunkte liegen bei rund 100 % des theoretischen Trainings-FLOPs-Budgets des 47B-Modells (B_ref, etwa 5,17e21 FLOPs)². Verifizierte Ergebnisse an den finalen Checkpoints:

Der SST-Prefiller trägt exakt die 1,120B aktiven Body-Parameter des Quellmodells pro Token — Bulk-Prefill läuft mit den Ressourcen eines 33,8B-Modells, während das Gesamtmodell 67B hat². Für die Inferenz nutzt das Papier einen analytischen Proxy (Active-Body-Zählungen mit 75 % Prefill / 25 % Decode-Kostengewichtung, normiert auf 47B klassisch): SST landet bei 0,933 gegenüber 1,365 für 63B klassisch und 1 als Referenz — 6,7 % unter 47B und 31,6 % unter 63B². Der Proxy ist zu seinen eigenen Grenzen ehrlich: Mit den beobachteten prefill-lastigen OpenRouter-Mixes (67,4–76,7 % Uncached-Input-Anteil an den Charges über sechs Frontier-Modelle) bleibt SST 1,3–7,9 % unter 47B und 27,7–32,5 % unter 63B, aber der Break-even gegen 47B liegt bei einem Prefill:Decode-Mix von 65,5:34,5 — wird der Traffic decode-lastig, ist die 67B-SST teurer als die kleinere Baseline². Das Fazit des Papiers stempelt den Scope selbst: kein Skalierungsgesetz, keine kausale Zurechnung pro Zutat, kein gemessener Serving-Speedup².

3. Die KV-Pin-Identität, durchgerechnet

Die KV-Cache-Formel aus unserem Glossar lautet Bytes pro Token = 2 x Schichten x kv_heads x head_dim x Gewicht-Bytes³. Unter KITE fällt jeder Faktor außer Schichten des Prefillers aus dem Skalierungspfad heraus — kv_heads und head_dim gehören zum kleinen Turm, und die Weite des Readers taucht nie auf. Die Identität gegen die Geometrie aus Tabelle 2/5 des Papiers (8 KV-Heads, head_dim 128, BF16)²:

# KV-pin identity: keys+values are 2 tensors x layers x kv_heads x head_dim x 2 bytes (BF16)
def kv_kib(layers, kv_heads=8, head_dim=128, bytes_w=2):
    return 2 * layers * kv_heads * head_dim * bytes_w / 1024
 
print(kv_kib(18))   # 72.0 KiB/tok — SST: pinned to the 18-layer Prefiller, FOREVER
print(kv_kib(20))   # 80.0 KiB/tok — 47B classic
print(kv_kib(22))   # 88.0 KiB/tok — 63B classic: attention state muscles with the model
 
# the paper's inference proxy, reproduced from Table 2/6 active-body counts (robust to 0.1%)
prefill_sst = 1.120 / 1.477      # bulk prefill = source-sized Prefiller
decode_sst  = 2.155 / 1.477      # both towers, per decode token
decode_63   = 2.016 / 1.477      # 63B classic is prefill-and-decode symmetric
print(round(0.75 * prefill_sst + 0.25 * decode_sst, 3))   # 0.933
print(round(1 - (0.75 * prefill_sst + 0.25 * decode_sst), 4))          # 0.0665 -> 6.7%
print(round(1 - (0.75 * prefill_sst + 0.25 * decode_sst) /
              (0.75 * decode_63  + 0.25 * decode_63), 4))              # 0.3161 -> 31.6%

Das reproduziert die 6,7 % und 31,6 % des Abstracts auf die Ziffer genau aus den Tabellen des Papiers². Aber achten Sie darauf, was die Identität wirklich sagt: Das KV pro Token der SST liegt bei 72 KiB — 18 % kleiner als die 88 KiB des 63B-Vergleichsmodells — ein Nebeneffekt des Zwei-Turm-Designs (der KV-produzierende Stack ist flacher als die 22 Schichten des Vergleichsmodells), nicht die Invariante selbst. Die Invariante ist, dass ein künftiger, breiterer SST mit 4.608-breitem Reader oder mehr Experten dieselben 72 KiB schreibt. Ein hypothetisches Modell derselben Familie, klassisch auf 40 Schichten bei 16 KV-Heads skaliert, würde 320 KiB pro Token schreiben — das 4,4-Fache der SST-Rechnung, auf jedem frischen Token, für immer. Genau diese Lücke verkauft das Paradigma.

Und um die zweite Zeile der Identität exakt zu machen: Prefill-KV ist nur die halbe frische Token-Rechenleistung. Die Forward-FLOPs-Buchhaltung des Papiers setzt 63B klassisch bei rund 5,149B und den SST-Prefiller bei rund 3,087B FLOPs pro Token auf Trainingssequenzlänge — die 40 % Prefill-Ersparnis sind real, aber durch den Nicht-Attention-Anteil (MoE und Readout) begrenzt, den der Reader-Turm erst beim Decode erreicht².

4. Das Fleet-Gegenmodell: der Residency-Term, eingefroren vs. wachsend

Die Zahl, die im September 2026 Wellen schlug, war Matt Barries Anker-Tag: rund 44 Agenten, etwa 4B Tokens, davon rund 3,0B — eine Looping-Fraktion von 75 % — Cache-Rereads des eigenen Kontexts, und rund 1B frisch (die Rechnung haben wir im Fleet-Ökonomie-Stück zerlegt)⁴⁵. In der eigenen Rahmung des Papiers ist Agenten-Traffic exakt das Input-lastige Regime, auf das KITE zielt: Uncached-Input übersteigt Output tokenmäßig um den Faktor 10–16 über die sechs gesampelten OpenRouter-Modelle². Rechnen wir also einen Fleet-Tag — rund 0,9B frische Input- plus 3,0B Re-Read-Tokens — unter 63B klassisch versus SST:

# Barrie-shape fleet day: ~0.9B fresh input, 3.0B re-reads (75% looping), ~0.1B output
fresh, reads, out = 0.9e9, 3.0e9, 0.1e9
 
# forward FLOPs/token from the paper's theoretical accounting (App. C): prefill vs decode
pre_63, pre_sst = 5.148513e9, 3.087252e9    # bulk prefill: full 63B vs 1.12B-active Prefiller
dec_63, dec_sst = 5.148513e9, 5.410678e9   # decode: both towers + readout -> SST pays MORE
 
pf_63, pf_sst = fresh * pre_63, fresh * pre_sst
print(f"{pf_63:.3e}", f"{pf_sst:.3e}", "prefill saving:", round(1 - pf_sst/pf_63, 3))  # 0.4
dc_63, dc_sst = out * dec_63, out * dec_sst
print("decode penalty:", round(dc_sst/dc_63 - 1, 3))                                   # 0.051
print("day total:", f"{pf_63 + dc_63:.3e}", "->", f"{pf_sst + dc_sst:.3e}",
      round(1 - (pf_sst + dc_sst)/(pf_63 + dc_63), 3))                                # 0.355
 
# the term the abstract does not headline: per-token KV, frozen vs growing
kv_63, kv_sst = 88 * 1024, 72 * 1024        # bytes/token: 22 vs 18 KV-writing layers, from cell 1
print(fresh * kv_63 / 1e12, "TB KV written (63B)", "|", fresh * kv_sst / 1e12, "TB (SST)",
      "|", round(1 - kv_sst / kv_63, 3))   # 81.1 vs 66.4 TB, -18.2%
print(reads * kv_63 / 1e12, "TB re-read traffic (63B) vs", reads * kv_sst / 1e12, "TB (SST)")
 
# residency: ~44 agents x ~50k tokens of live context parked in HBM
residency_tokens = 44 * 50_000
print(round(residency_tokens * kv_63 / 2**30, 1))    # 184.6 GiB live KV (63B)
print(round(residency_tokens * kv_sst / 2**30, 1))   # 151.1 GiB live KV (SST)

Vier Erkenntnisse, die die Arithmetik erzwingt. (1) An diesem Barrie-förmigen Tag liegen die geschätzten Forward-FLOPs der SST insgesamt 35,5 % niedriger — die Prefill-Ersparnis (40 % von rund 4,6e18 FLOPs) überdeckt die Decode-Strafe. (2) Frisch geschriebenes KV sinkt um 18,2 % (81,1 TB auf 66,4 TB pro Fleet-Tag) — und das ist das eigentliche Gebiss der Invariante: Eine künftige KITE-Expansion auf 100B+ schreibt dieselben 66,4 TB, ein klassisch skaliertes Modell nicht. (3) Die 3,0B Re-Reads bewegen über den Tag 270 TB KV beim 63B-Klassiker gegenüber 221 TB bei der SST: Jeder Re-Read berührt den Cache, den der Schreib-Turm dimensioniert hat — die Looping-Fraktion erbt den Rabatt. (4) Die Residency — die Größe, die unser Metering-Stück als die eigentliche Ware eines geteilten Servers ausgewiesen hat⁶ — sinkt für dieselben 44 parkten Agenten von rund 185 GiB auf rund 151 GiB. Und wieder ist die eingefrorene Seite dieses Terms der vorausschauende Anspruch: Die Residency-Kosten des Parkens eines Agenten hören auf, mit dem Modell zu wachsen. Das sind Identitäts-Rechnungen auf den eigenen Active-Zählungen des Papiers, keine gemessenen Serving-Zahlen — das Papier hat auf Serving-Ebene selbst nichts gemessen².

5. Hype-Brecher 1: die Turm-Trennungs-Wette

Das ist es, was das Abstract nicht ausspricht — und was in der Ablations-Schublade des Papiers auffällig fehlt. Das ganze Paradigma ruht auf einer Annahme ohne direkten Test im Papier: dass ein klein-bleibender Prefiller Keys und Values lernen kann, die für unbegrenzt wachsende Reader-Kapazität gut genug bleiben. Der Reader ist, wo das gesamte Intelligenzwachstum passiert — aber jedes Bit davon konsumiert den Output desselben Writers. Das Papier berichtet keine Ablation, die die Prefiller-Größe bei festem Decoder variiert, keinen eingefrorenen Prefiller-Arm, und testet umgekehrte oder geteilte KV-Zuordnung nur als illustrierte Design-Optionen². Figure 6 des Papers rahmt Konnektivität (KV-Zuordnung, Hidden-State-Bridges, Kapazitätsaufteilung) explizit als unerforschte Freiheitsgrade, „not assumed to have equal cost or quality"².

Die eigenen Ergebnisse des Papiers dokumentieren die Ko-Adaptationskosten — benannt als Risiko werden sie nicht. In §2.3/§3.2: Gradienten fließen über das wiederverwendete KV in den Prefiller hinein, die Repräsentationen des Writers passen sich durch das gesamte Joint-Training an den Reader an; der Loss steigt bei der Konversion und sinkt dann durch die Fortführung (Abbildung 4) — die Signatur eines Systems, das seinen Writer nach dem Hinzufügen des Readers neu einpasst. Und der Sanity-Check liegt in den Vergleichsmodellen selbst: Der 63B-Klassiker mit 22 KV-Schreib-Schichten bei Weite 2.816 erreicht 1,5921 mit weniger Gesamttraining (334,62B Tokens), als die 47B-Baseline für 1,6006 bei 443,16B braucht — tiefere Stacks schreiben offenbar stärkeres KV pro Token; vielleicht ist KV-Produktion doch nicht die Schicht-Spar-Version, als die das Paradigma sie behandeln möchte. Braucht der Reader an Frontier-Skalen mehr vom Writer — breiteres KV pro Schicht, mehr Heads, mehr Schichten —, muss der Prefiller wachsen, die 72-KiB-Linie bricht, und die Skalierung koppelt wieder zusammen — mitsamt dem Cache-Ökonomie-Ertrag: Der Wert des Einfrierens von 72 KiB/Token hängt davon ab, dass 72 KiB der Endpunkt ist. Das Papier bestätigt das weder noch widerlegt es; es zeigt nur, dass der aktuelle Reader — ein 2,155B-aktiver Decoder — mit einem 1,120B-aktiven Writer bei 390B Trainings-Tokens zufrieden ist. Ob das beim nächsten Expansionsschritt hält, ist die gesamte Wette.

6. Hype-Brecher 2: die Loss-Leiter ist keine Capability-Leiter

„Niedrigerer Trainings-Loss bei vergleichbarer kumulativer Rechenleistung" ist ein sauberer Skalierungs-Leiter-Anspruch — und dieses Papier verdient Anerkennung dafür, beide Trainingsstufen zu zählen: die Upcycling-Route darf ihre Quell-Tokens nicht verstecken². Aber man sollte präzise sein, was auf der Leiter steht. Trainings-Loss ist ein Anpassungsmaß, kein Fähigkeitsmaß; der Unterschied beträgt 0,0106 gegen das 47B-Modell und 0,0021 gegen das 63B auf EMA-200 am Endpunkt — ein relativer Vorsprung von 0,13 % im letzteren Fall². Fairerweise: Das Papier berichtet auch Downstream-Tasks, und dort schlägt SST beide Baselines auf allen sieben (OpenBookQA 75,00 vs. 71,00/68,50; MMLU 60,54; GSM8K 58,38; MATH 34,36; HumanEval 37,80; MBPP 51,40; BBH 52,74 — plus held-out arXiv-NLL von 1,4421, niedriger als beide)². Es sind Standard-Benchmarks an je einem Checkpoint; keine Fehlerbalken, keine Serving-Messungen, keine Langkontext-Tests, keine Agenten-Loop-Evaluationen — für ein Papier, dessen Titel „Agentic LLM Scaling" enthält, ist der Beleg agentischer Überlegenheit eine OpenRouter-Charge-Anteils-Tabelle, kein Eval². Und die Inferenzzahlen sind ein analytischer Proxy über Active-Body-Parameterzählungen, den das Papier selbst zweimal „not measured serving speedups" stempelt². Befund zur Beweislage: Loss-Leiter solide, Benchmark-Vorsprung dünn, aber konsistent, agentischer Anspruch ungetestet, Kostenanspruch analytisch.

7. Hype-Brecher 3: der Reader attendiert trotzdem — Decode-FLOPs frieren nicht ein

Die Invariante deckt die Prefill-Rechnung ab. Sie sagt nichts über Decode, und die Buchhaltung des Papiers ist dazu erfrischend direkt: Beim 75:25-Mix ist SST billiger, aber pro Decode-Token kostet die SST mehr — jeder generierte Token durchläuft beide Türme (rund 5,411B Forward-FLOPs/Token gegenüber 5,149B beim 63B in der Buchhaltung des Papiers, Attention beider Türme eingerechnet, ein geteilter Readout)². Der Decoder führt weiterhin volle Attention über das KV des Prefillers aus — das Lesen des Cache ist nicht gratis. Der Break-even gegen 47B liegt beim Prefill:Decode-Mix 65,5:34,5; darunter ist die 67B-SST in der eigenen Abbildung 5 des Papiers teurer als die 47B-Baseline². Für Reasoning-lastige Workloads — lange Thinking-Traces, niedriger Prefill-Anteil — zeigt die Ökonomie der Architektur in die falsche Richtung, und keine KV-Pin-Identität rettet das. Die Decode-Frage ist auch dort, wo Langkontext-Realität beißt: Ein Reader, der über ein 200k-Token-KV attendiert, zahlt Attention-FLOPs, die mit der Kontextlänge skalieren, und nichts im Zwei-Turm-Split reduziert sie — die HBF-Tiering-Arithmetik (Bandbreite und FLOPs des Re-Readens großer Caches) gilt unverändert. KITE friert die Schreib-Seite ein; die Lese-Seite bleibt Ihre Rechnung.

8. Was man tatsächlich folgern sollte

KITE ist ein genuin interessanter Architektur-Move — und eines der wenigen Skalierungs-Papiere des Jahres 2026, dessen Kosten-Schlagzeile sich aus den eigenen Tabellen per Hand reproduzieren lässt. Das Leiter-Ergebnis ist real: Bei gleicher kumulativer Trainingsrechenleistung erreicht ein Modell, dessen Prefill auf einem Writer in 33,8B-Größe mit 2,155B-aktivem Reader läuft, niedrigeren EMA-200-Loss als sowohl ein 47B- als auch ein 63B-from-scratch-Modell, mit moderat besseren Benchmarks und einem analytischen Inferenz-Kosten-Proxy, der in Input-lastigen Mixes 6,7–31,6 % niedriger liegt. Die Fleet-Arithmetik in Abschnitt 4 ist der Steelman: In einer agenten-dominierten Welt, in der drei Viertel der Tokens Selbst-ReReads sind, ist eine Architektur, deren KV-Residency mit dem Modell nicht mehr wächst, echtes Geld wert.

Drei Etiketten bleiben. Die Turm-Trennungs-Annahme — dass ein kleiner Writer für einen immer größeren Reader gut genug Keys produziert — ist eine Wette, die die Ablationen des Papiers nicht testen; beobachten Sie, ob künftige KITE-Expansionen berichten, den Prefiller vergrößern zu müssen. Der Capability-Nachweis ist eine Loss-Leiter plus sieben kleine Benchmark-Deltas, ohne agentisches Eval in einem Papier über agentisches Skalieren. Und alle Kostenangaben sind Active-Parameter-Proxys, keine Serving-Messungen — Decode kostet pro Token mehr, der Break-even liegt bei 65,5:34,5. Nichts davon macht das Papier falsch. Es macht es, wie alles in diesem Genre, zu einem Anspruch über die Trainingskurve — die Serving-Geschichte noch zu laufen, und die Attention des Readers weiterhin zu zahlen ist.