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

Jeder frische Prompt-Token erzeugt Attention-Keys und -Values. Deren Speicherung und spätere Lesezugriffe können erhebliche Speicherkosten verursachen; zum Prefill-Rechenaufwand gehören aber auch Projektionen und Feed-forward-Arbeit. In einer klassischen Modellfamilie kann eine größere Zahl oder Dimension KV-produzierender Schichten die Cache-Kosten pro Token erhöhen; Parameterwachstum allein muss das nicht. 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 klar hypothetisches Kapazitätsbeispiel 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 while Prefiller geometry stays fixed
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. Ein Kapazitätsszenario, keine Umrechnung von API-Abrechnung

Die KV-Identität pro Token lässt sich auf ein hypothetisches Residency-Beispiel anwenden, ohne abgerechnete API-Cache-Read-Tokens mit physischem HBM-Traffic gleichzusetzen. Angenommen, 44 Sessions halten gleichzeitig je 50.000 KV-Tokens. Modellgewichte, Fragmentierung, Sharing, Offload und Allokator-Overhead bleiben außen vor:

sessions, tokens_each = 44, 50_000
for name, kib_per_token in [("63B classic", 88), ("67B SST", 72)]:
    gib = sessions * tokens_each * kib_per_token * 1024 / 2**30
    print(f"{name}: {gib:.1f} GiB resident KV")

63B classic: 184.6 GiB resident KV
67B SST: 151.1 GiB resident KV

Das sind 33,5 GiB oder 18,2 % weniger logische KV-Kapazität für diese erfundene Last. Der Unterschied folgt allein aus 22 gegenüber 18 KV-schreibenden Schichten bei der angegebenen Geometrie. Er ist weder eine gemessene Serving-Ersparnis noch eine Geldrechnung. Abgerechnete API-Cache-Read-Tokens spiegeln Wiederverwendung und Preispolitik des Anbieters wider; durch Multiplikation mit KV-Bytes pro Token kann man daraus keine HBM-Lesezugriffe ableiten. Dafür wären Serving-Engine, Attention-Muster, Cache-Platzierung und Ausgabelänge nötig. Künftige KITE-Varianten behalten 72 KiB/Token nur, solange die KV-produzierende Prefiller-Geometrie konstant bleibt².

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 attendiert weiterhin gemäß Sliding-Window-plus-Full-Muster (SSSF) über das KV des Prefillers — Cache-Lesezugriffe sind 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: Die Full-Attention-Schichten verursachen weiterhin kontextlängenabhängigen Aufwand, während Sliding-Window-Schichten auf ihre Fenstergröße begrenzt sind — 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.