BOOST und das Ende des Prefetch: Warum Grace Hopper beide Speichertiere gleichzeitig will

Ein Paper von September 2026 der Georgia Tech, NVIDIA Research und Stanford — BOOST (arXiv:2609.13592, Saxena, Ju, Taneja, Tsai, Jaleel, Kozyrakis, Qureshi)¹ — macht eine Behauptung, die nach routiniertem Serving-Tuning klingt und tatsächlich das Ende eines Paradigmas bedeutet: Host-Memory-Tiering für KV-Cache und Gewichte sollte nicht auf Prefetching gebaut werden, weil Prefetching die nutzbare Bandbreite der schnellen Tier, die es füttern soll, mechanisch reduziert. Der Runtime bedient beide Tiers gleichzeitig, proportional zu ihrer Bandbreite, und misst in vLLM auf Grace Hopper durchschnittlich +31% Durchsatz, während Prefetching die Latenz messbar verschlechtert — TPOT verschlechtert sich um 6% bei iso-batch¹²³.

Das hype-nahe Framing, das man anderswo lesen wird, lautet „31% gratis Durchsatz aus dem RAM, das Sie schon besitzen". Die hype-resistente Version ist enger und interessanter: Auf genau dieser Klasse eng gekoppelter CPU-GPU-Systeme ist die Host-Tier ein ~10%-Bandbreiten-Peer und ein ~10%-Kapazitäts-Anbau, und der komplette Designraum der Tiering-Systeme nach dem Muster „Daten vor Nutzung in die schnelle Tier verschieben" zahlt eine Schreibsteuer, die es nie zurückholt. Dieser Guide rechnet das Ledger in Python nach (Sie können dieselbe Arithmetik laufen lassen), trennt die Durchsatz-Geschichte von der Latenz-Geschichte und zieht die Silizium-Grenze, die die Behauptung ehrlicherweise nicht überschreiten darf — dieselbe Grenze, an die unsere UNISON-Analyse von der anderen Seite stieß: UNISON wollte dediziertes Scheduler-Silizium; BOOST holt real gemessene Gewinne aus 800 Zeilen Python in einer Serving-Engine, auf echter Hardware. Die Spannung zwischen diesen beiden Behauptungen ist die eigentliche Geschichte.

1. Die Behauptung — und was worauf gemessen wurde

Zuerst die Provenienz: Georgia Tech + NVIDIA Research + Stanford, integriert in vLLM v0.17.0 mit rund 800 Zeilen Python/PyTorch, ohne Kernel-Änderungen — es funktioniert über mmap/mbind-Page-Placement und einen erweiterten KV-Pool-Manager; FlashAttention-3 und die Closed-Source-cuBLAS-Kerne laufen unangetastet². Die Evaluations-Hardware ist ein Grace Hopper GH200: 96 GB HBM, 480 GB CPU-Speicher, laut Paper Peak-HBM-Bandbreite 3,63 TiB/s und in der Praxis gemessen 3.330 GiB/s, gemessene C2G-Lesebandbreite (Chip-to-GPU über cache-kohärentem NVLink-C2C) 350 GiB/s — genau dieses gemessene Paar ergibt das Bandbreitenverhältnis α ≈ 10%, an dem das ganze Paper hängt². Wir haben jede Zahl unten im arXiv-HTML-Volltext verifiziert; die Industrie-Presse (Semiconductor Engineering) zitiert das Abstract korrekt³.

Drei Headline-Zahlen, die sich unterschiedlich zerlegen — deshalb lohnt es sich, sie getrennt zu halten:

• +31% durchschnittlicher Durchsatz, bis zu 40% bei Max-Batch-Skalierung gegen HBM-only-Serving (gemessen)².
• +4,3% TPOT bei iso-batch — derselbe Batch, weniger Millisekunden pro Token, rein aus zusätzlicher Bandbreite².
• −6% TPOT für Prefetching unter denselben Iso-Batch-Bedingungen — das amtierende Paradigma verliert Latenz auf genau der Workload, der es helfen soll¹.

Man beachte die Asymmetrie sofort: 31% ist überwiegend ein Kapazitäts-Effekt, 4,3% der Bandbreiten-Effekt und −6% die Kosten des Prefetch-Paradigmas selbst. Der Rest dieses Artikels ist die Arithmetik, die diese drei Zahlen unausweichlich statt beeindruckend macht.

2. Das Bandbreiten-Ledger: Warum Prefetch die Host-Bandbreite beim Decode nie nutzen kann

Die Kernbeobachtung des Papers ist eine Buchhaltungsidentität — und Buchhaltungsidentitäten sind das beste Hype-Gegengift, das es gibt. Ein Prefetching-Tier schreibt jedes host-residente Byte in HBM, bevor die SMs es lesen. Dieser Schreibvorgang konkurriert um das HBM-Interface mit den Demand-Lesen des Decode-Schritts. Die Bandbreite des Host-Links wird ausgegeben, um Daten über C2C zu ziehen — und dann ein zweites Mal als Schreib-Traffic auf den HBM-Pins:

• 1 GB vom Host über C2C lesen: verbraucht C2C-Bandbreite, die während des Decode sonst nie anfällt.
• Diese 1 GB in einen HBM-Staging-Puffer schreiben: verbraucht HBM-Schreibbandbreite.
• Als Demand-Load zurücklesen: verbraucht HBM-Lesebandbreite.

Pro geliefertem Byte zahlt ein Prefetcher also HBM-Schreiben + HBM-Lesen + C2C, und nur der C2C-Anteil ist eine neue Ressource — alles andere wird von der Tier abgezogen, die man eigentlich entlasten wollte. Schlimmer: Die Schreibvorgänge sind rekurrent, denn das Offload-Working-Set ist weit größer als jeder Staging-Puffer, sodass gestagte Bytes nach Nutzung verdrängt und in der nächsten Decode-Iteration erneut geholt werden². Das Paper misst den Schaden mit 211 GiB/s verlorener Demand-Lesebandbreite auf Llama-3.3 70B in vLLM² — rund 6,3% der 3.330 GiB/s Baseline:

# Grace Hopper, papier-gemessen (arXiv:2609.13592v1, Abs. 5.1)
HBM  = 3330   # GiB/s gemessene Demand-Bandbreite
C2G  = 350    # GiB/s gemessene Chip-to-GPU-Lesebandbreite
alpha = C2G / HBM            # 0.105 -> das Paper rundet auf 10%
 
prefetch_loss = 211          # GiB/s an Prefetch verlorene Demand-Bandbreite (Abb. 3)
print(alpha, prefetch_loss / HBM)   # 0.105, 0.0633

Jetzt das Staging-Puffer-Ledger — dort, wo die „5+ GB aggressiver Puffer"-Folklore auf die Realität trifft. Nehmen wir Llama-3.3 70B in FP8 — grob 70 GB Gewichte, die jeder Decode-Schritt durchläuft (KV kommt obendrauf). Eine typische Tiering-Policy lagert einen von K Layern zum Host aus und prefetcht asynchron. Die Schreib-Arithmetik pro Decode-Schritt:

W = 70.0   # GB FP8-Gewichte, gelesen pro Decode-Schritt (KV obendrauf)
for K in (10, 8, 5):
    staged = W / K          # GB pro Schritt in HBM-Staging geschrieben
    print(f"K={K}: {staged:.1f} GB geschrieben/Schritt = "
          f"{100*staged/W:.1f}% zusätzliche HBM-Schreiblast ggü. Gewicht-Lesen")
# K=10: 7,0 GB geschrieben/Schritt = 10,0% zusätzliche HBM-Schreiblast
# K=8:  8,8 GB geschrieben/Schritt = 12,5% ...
# K=5: 14,0 GB geschrieben/Schritt = 20,0% ...

Ein 5–6-GB-Staging-Puffer hält nicht einmal das K=10-Offload-Slice (7 GB) — jeder Decode-Iteration staged also, verdrängt und staged erneut: wiederkehrende HBM-Schreiblast in derselben Größenordnung wie das α, das eigentlich addiert werden sollte. Das ist der strukturelle Grund, warum ein idealer, perfekt überlappender Prefetcher trotzdem nicht gewinnen kann: Wird der Anteil α der Daten gestagt, ist die effektive Demand-Bandbreite bei HBM × (1 − α) gedeckelt, denn jedes gestagte Byte muss in HBM landen. Konkurrierendes Lesen beider Tiers erreicht HBM × (1 + α). Das Verhältnis der beiden Schranken ist (1 + α)/(1 − α)²:

for a in (0.03, 0.105, 0.44):
    print(f"alpha={a:.3f}: CAP/Prefetch-Schranke = {(1+a)/(1-a):.2f}x")
# alpha=0,030:  1,06x  (GB200-Klasse: 2 GPUs teilen eine CPU)
# alpha=0,105:  1,23x  (gemessen GH200; das Paper nennt 22% bei alpha=10%)
# alpha=0,440:  2,57x  (projiziert Vera-Klasse, 900 GB/s C2G)

So lässt sich das Paradigma-Resultat am saubersten aussprechen: Prefetching verwandelt die zweite Tier von einer Bandbreiten-Quelle in eine Bandbreiten-Steuer. Es ist kein Tuning-Versäumnis, kein DMA-Overlapping-Fehler und kein Cleverness-Fehler — es steht so im Ledger, sobald jedes Host-Byte erst ein HBM-Byte werden muss.

3. Warum konkurrenter, proportionaler Zugriff gewinnt: Tiers addieren, nicht mitteln

BOOSTs Alternative ist das, was das Paper CAP-Zugriff nennt — concurrent und proportional: Innerhalb jeder Welle aus Threadblocks werden beide Tiers gleichzeitig gelesen, mit exakt α/(1+α) der Zugriffe auf den Host und 1/(1+α) auf HBM. Die Proportionalitätsbedingung ist alt (bandbreiten-proportionales Page-Placement reicht bis 2015 zurück); die Konkurrenz innerhalb einer Welle ist die neue Bedingung — sie existiert, weil moderne GPUs 2-MB-Pages verwenden. Eine Welle berührt Dutzende 2-MB-Pages, nicht die Tausende 4-KB-Pages, die zufälliges proportionales Placement aus 2015 in jeder Welle von selbst ins Gleichgewicht brachten. Zufälliges, im Mittel proportionales Placement schwankt pro Welle stark: Manche Wellen übersenden die Host-Tier und stapeln sich auf ihr, während HBM leer läuft; andere berühren den Host kaum. Der kontrollierte Sweep des Papers ist brutal: Der Speedup peakt bei 7,4% bei einem Host-Anteil von 8,3% (nahe dem proportionalen 9,1%), und ein deutlich überproportionaler Host-Anteil ist ein 6,7%-Slowdown². Proportional ohne Konkurrenz = kein Gewinn; Konkurrenz mit schiefer Proportion = Verlust. Beide Eigenschaften tragen.

Zwei Mechanismen liefern das ohne Kernel-Änderungen. Für statische Gewichte das Modulo-basierte Page-Placement (MPP): die ersten K Pages auf HBM, die (K+1)-te auf den Host, wiederholen — das Zugriffsverhältnis ist in jeder Welle deterministisch ohne Varianz, und CTAs bleiben über Tiers hinweg ungespalten (ein CTA mit Tier-übergreifendem Footprint stapelt seinen SM auf Host-Loads). Für dynamisches KV der Data Shape Remapper (DSR): ganze KV-Heads werden den Tiers zugeordnet — ein Head eines Modells mit H Heads auf den Host gibt Head-genaue Kontrolle, mit einem Tensor-Layout-Rearrange, damit Heads kontigu und page-alignt bleiben. Der Runtime reserviert rund 9,6 GB (2% der 480 GB Host-Seite) in 1-GB-Pages und migriert nichts — Daten werden dort gelesen, wo sie liegen, cacheline-genau über cache-kohärente Load-Store-Semantik².

Die Bandbreitenschranke ist dann schlicht additiv. Beide Tiers sättigen pro Welle:

print(f"Zwei-Tier-Schranke = HBM + C2G = {3330+350} GiB/s vs {3330} HBM-only "
      f"-> {(3680/3330-1)*100:.1f}% max")
# 3680 GiB/s -> 10,5% max. Bandbreitengewinn bei iso-batch (Papers ~1,1x-Framing, alpha 9-11% je SKU)

Das ist die ehrliche Decke: ~11%, nicht 31%. Woher kommt der Rest — die 31%? Man trenne die beiden Effekte — genau diese Trennung ist der Artikel.

4. Der 4,3 / −6 / +31-Split: Latenz kauft 11%, Kapazität den Rest

Im Iso-Batch-TPOT-Experiment ist der Batch fixiert (10 Requests für Llama-3.3 70B, 88 für Qwen3-Next 80B), sodass nur Bandbreite das Ergebnis ändern kann. Dort liefert BOOST 4,3% durchschnittliche TPOT-Verbesserung — das geometrische Mittel des Papers, und das ist der richtige Aggregator, wenn die Zahlen pro Modell 4,5% (MoE) und 4,2% (dense) sind². Prefetching liefert unter identischen Bedingungen −6% — das heißt, BOOST endet 11% vor dem amtierenden Ansatz, und der MoE-Fall ist für Prefetch noch schlimmer: Die dynamische Expert-Aktivierung desynchronisiert das Prefetch-Timing, verpasst das Zeitfenster und kostet das MoE 9,3% TPOT². Der gemessene Check dazu: BOOSTs Gesamt-(HBM+C2G)-Auslastung verbessert sich um 3% über HBM-only und um 12% über Prefetching².

Jetzt Durchsatz. Im High-Throughput-Modus skaliert die Serving-Engine die Batch-Größe automatisch auf den verfügbaren Speicher — und das ist der Kapazitäts-Hebel, den das Abstract explizit macht: Liegen 20% des HBM-Speichers in KV, vergrößern 10% zusätzliche Kapazität aus der Host-Tier den KV-Raum um 50% und erlauben bis zu 1,5× so viele nebenläufige Requests¹. Zerlegt man diese Dekomposition numerisch:

total = 1.31            # gemessener durchschnittlicher Durchsatzgewinn
concurrency_share = 1.04  # Paper: Konkurrenz-Zugriff bringt ~4%, das keine Kapazitäts-Mechanik liefert
print(f"implizierter Kapazitäts-Faktor = {total/concurrency_share:.2f}x")  # 1,26x

Das ehrliche Lesen von „+31%": grob ein 1,26×-Kapazitätseffekt über die Batch-Größe (mehr residentes KV und Gewichte → mehr gleichzeitige Requests), kombiniert mit einem 1,04×-Bandbreiten-Effekt pro Request. Der Batch-Headroom absorbiert zusätzlich die Host-Trägheit: Bei hohem Batch ist das Decode pro Request latenz-toleranter (einige Requests warten ohnehin), also fällt ein etwas langsamerer Durchschnittszugriff weniger ins Gewicht als bei exakt fixiertem Batch. Das ist mechanisch der Grund, warum Prefetching trotzdem +17% Durchsatz gewinnt (Kapazität ist Kapazität, selbst über ein verlustbehaftetes Paradigma), aber TPOT verliert — und warum BOOSTs Vorsprung vor Prefetching bei Durchsatz 15% und bei TPOT 11% beträgt¹². Wer „31% schnellere LLMs" zitiert, hat eine Iso-Latenz-Messung in eine Batch-Skalierungsmessung geklappt — zwei verschiedene Achsen.

Zwei Anti-Hype-Details aus den Sensitivitäts-Sektionen verdienen denselben Rang wie die Headlines:

• Die Batch-Größe ist eine echte Randbedingung. Der Kernel-Speedup des dense Modells zerfällt von 7% bei Batch 8 auf 6% bei Batch 64 und kippt bei Batch 256 in einen 0,5%-Slowdown — bei großem Batch teilen sich mehrere CTAs eine Gewichts-Tile und L2-Wiederverwendung zählt, und Grace Hopper cached GPU-zu-Host-Loads gerade nicht im L2, sodass Host-Reads den Wiederverwendungspfad umgehen². Das MoE zeigt das Inverse: −2% bei Batch 16 (zu wenige Threadblocks für das Verhältnis), +6% bei Batch 256. BOOST ist ein Werkzeug für ein bestimmtes Serving-Regime, keine universelle Konstante.
• Weighted Interleave — die „nahe-liegende" Alternative — bringt schon den größten Teil des Durchsatzes und nichts von der Latenz. Weighted-Interleave-Placement hebt den Durchsatz um 30% über Kapazität, landet bei iso-batch TPOT aber bei 0.99: proportional im Mittel ohne Per-Welle-Konkurrenz². Wem es nur um Tokens-pro-Sekunde bei gesättigten Batches geht, gehört ein Teil des BOOST-Gewinns vielleicht schon.

5. Der Silizium-Scope-Guard: NVLink-C2C ist die Behauptung, PCIe ist es nicht

Hier werden die meisten Zweitquellen falsch liegen — deshalb als harte Regel. α ≈ 10% gilt, weil Grace Hoppers Host-LPDDR5X hinter einem cache-kohärenten NVLink-C2C-Port mit gemessen 419 GiB/s Peak / 350 GiB/s nachhaltig erreichbar liegt, gegen HBM mit gemessen 3.330 GiB/s (3,63 TiB/s Spezifikation)². Pro SKU nennt das Paper C2G-Lesen bei 450 GB/s gegen HBM bei 4.000–4.900 GB/s, daher „9% bis 11%"¹. Grob gesagt: Die Host-Lesebandbreite ist ein Zehntel der HBM — nur wenn der Host so nah ist. Die besondere Grace-Hopper-Eigenschaft ist, dass die Host-Tier fast ein Peer des Interconnects ist: LPDDR5X der ~512-GB/s-Klasse durch einen C2C-Port der 600-GB/s-Klasse — fast die gesamte Host-Bandbreite ist an die GPU lieferbar.

Ein über PCIe angehängter x86-Host hat diese Eigenschaft überhaupt nicht. PCIe Gen5 x16 peakt bei 64 GB/s (roh, realistisch ~50 GB/s) gegen 4–8 TB/s HBM: α ≈ 1–2%, eine Größenordnung dünner. Die Schranken-Arithmetik gilt weiter richtungsweise — auch dort verlieren Prefetcher (1−α)/(1+α) — aber der Preis schrumpft auf niedrige einstellige Prozent, während die Fixkosten (Staging-Puffer, Migrationskontrolle, Pinning) bleiben. Schlimmer: PCIe fehlt die cache-kohärente Load-Store-Semantik, der Trick „lies es, wo es liegt, mit ganz normalen Loads" existiert dort nicht; man ist im DMA-und-warten-Territorium — was der Grund ist, warum das Prefetch-Paradigma auf PCIe-Systemen überhaupt so gebaut wurde, wie es gebaut ist. Das Paper selbst zieht diese Linie: „Unlike traditional PCIe-connected systems… we focus on tightly-coupled CPU-GPU systems like GH200"².

Man dehne den Guard über Produktlinien, bevor es das Marketing tut:

• GB200: zwei Blackwell-GPUs pro Grace-CPU — die CPU-Bandbreite wird geteilt, das Paper setzt α um 3% an². Der Zwei-Tier-Preis verschwindet fast, obwohl es weiter NVLink-kohärent ist.
• Vera-Klasse (Zukunft): projiziert 900 GB/s C2G, α bis 44% — dort projiziert das Paper BOOSTs Vorteil über Prefetching auf bis zu 60% und seine eigenen Gewinne auf bis zu 3ײ. Projektion, kein Silizium; entsprechend behandeln.
• PCIe x86 + DDR5: der schlimmste Fall für das Lesen beider Tiers. Prefetch-Tiering ist dort kein Fehler — es ist die einzige Option, die der Interconnect lässt.

Zeigt ein Vendor-Deck einen Grace-Hopper-Balken neben einen PCIe-Server-Balken mit derselben „+31%"-Überschrift, dann lügt das Deck zweimal.

6. Der UNISON-Kontrast: dieselbe Workload-Diagnose, umgekehrte Kostenmodell

Unsere UNISON-Analyse hat den Near-Memory-Scheduler für Agenten-KV auf Tool-Wait-Sessions behandelt: das Working-Set der pausierten Flotte (100 Agenten bei 100k-Kontext ≈ 703 GB reiner KV-Zustand), das Recency- und Timeout-Policies falsch ranken, adressiert durch dediziertes 28-nm-Scheduling-Silizium (0,169 mm², 13,6 mW bei 150 MHz, 2,00 µs im Mittel pro 64-Session-Scan). Der ehrliche Vorbehalt, den wir dort markiert haben — und jetzt deutlicher: UNISONs Evaluation läuft auf einem hausgemachten, trace-getriebenen Modell eines Rubin-Klasse-GPUs — nicht auf echtem Silizium⁴. BOOSTs Evaluation läuft auf einem echten GH200 mit echtem vLLM, echter FlashAttention-3, echtem cuBLAS².

Dieser Kontrast ist eine echte offene Frage im Tiering-Stack, und kein Paper beantwortet sie allein. UNISONs Behauptung: Tier-Placement-Scheduling ist event-getrieben, latenz-kritisch und gehört in Silizium nahe am Memory-Controller. BOOSTs Behauptung: Tier-Bandbreiten-Extraktion ist ein Placement-Problem, das ein 800-Zeilen-Runtime heute auf Commodity-Hardware löst, ohne Kernel-Änderungen und ohne neues Silizium. Das sind eigentlich nicht dieselbe Behauptung — UNISON schedult wann/wo KV über eine Tier-Hierarchie wohnt unter Agenten-Duty-Cycles; BOOST entscheidet aus welcher Tier jedes Byte gelesen wird, damit beide gleichzeitig sättigen — aber sie konkurrieren um dasselbe Betreiber-Budget (Engineering-Aufmerksamkeit, Adoptionsrisiko), und die Beweislast liegt derzeit beim Silizium-Lager, dessen auffälligstes 2026-Resultat simulationsbasiert bleibt. Wer sein entscheidendes Argument für Near-Memory-Silizium daraus macht, dass „die Scheduling-Entscheidungen zu feinkörnig für Host-Software sind", muss inzwischen ein System schlagen, das eine 7,3%-Hand-Kernel-Schranke zu 96% erreichte — mit 0 Zeilen Kernel-Code, aus Python heraus².

Das Gegenargument überlebt trotzdem, und man sollte beide am Leben lassen statt einen Sieger zu erklären: BOOST kann einer pausierten Flotte nicht helfen — seine Mechanismen setzen aktiv dekodierende Kernel mit konstanten Per-CTA-Zugriffsströmen voraus; zum Tool-Wait-Residency sagt es nichts, und sein Welle-Bewusstsein löst sich auf, wenn die Wellen aufhören. Das billigste neue HBM ist das Host-DRAM, das man schon besitzt — unser Argument aus der HBM4-Mangel-Ökonomie — aber ob das Host-DRAM als Bandbreiten-Peer (BOOSTs Regime) oder als Cold Storage für geparkte Sessions (UNISONs Regime) dient, hängt vom Duty Cycle der Workload ab, und eine echte Flotte hat beides. Der Prefetch-Incumbent wird unterdessen trotzdem weiter ausgeliefert: vLLM v0.30.0s HiSparse-Host-Tier lagert KV-Pages unter GPU-Druck in gepinnten Host-Speicher aus mit Per-Request-GPU-Hot-Buffern und gebündelter Host-zu-Gerät-Mediation — gut gebaute Prefetch-Maschinerie, exakt das Paradigma, das BOOSTs −6%/+17%-Zahlen einpreisen⁵. Der Kontext der Serving-Engine-Churn zählt hier: Release-Features gegen gemessene Behauptungen lesen, nicht gegen Release Notes.

7. Was wir verifiziert haben, was nicht — und die Falsifikationsliste

Was hier trägt, für diesen Guide an den Primärquellen geprüft: die Abstract-Zahlen (31%, 4,3%, −6%, 15%)¹³, die Grace-Hopper-Zahlen im HTML-Volltext (3,63 TiB/s Spezifikation, 3.330/350 GiB/s gemessen, α = 10%, 211 GiB/s Prefetch-Verlust = 6,3% der Baseline, 9,6 GB Host-Reserve, 800 LoC, vLLM v0.17.0, das 7,4%-CAP-Peak und die 6,7%-Oversubscription-Strafe, die Batch-Übergänge, GB200 α=3%, Vera α≤44%)². Die (1+α)/(1−α)-Ledger-Schranke ist die eigene Ableitung des Papers und oben in Python nachgerechnet; unser Staging-Puffer-Walkthrough (70 GB FP8-Gewichte, K=10 → 5+ GB stale pro Schritt) ist unser Modell ihrer Abb. 3, mit ihrem gemessenen Verlust als Anker — der Walkthrough ist eine Plausibilitätsprüfung, die 211 GiB/s sind die Ground Truth.

Ehrliche Scope-Grenzen des Resultats selbst:

1. Eine Hardware-Familie, eine Engine, eine Paper-Version. Nur GH200, nur vLLM v0.17.0, v1 bei Einreichung (11. September 2026)¹. Keine SGLang-Integration, keine GB200- oder H100-Zahlen ohne α-Emulation — die Skalierbarkeits-Evidenz jenseits der Qwen2.5-72B-Studie fehlt. Optimismus entsprechend einpreisen.
2. Durchgängig FP8-Modelle. Das Ledger gilt bei jeder Präzision, aber das Verhältnis von KV- zu Gewicht-Bytes — und damit, wie viel des Gewinns Attention- statt Gewicht-getrieben ist — verschiebt sich mit der Quantisierung; FP4-KV-lastige Workloads sind nicht direkt gemessen.
3. Welle-Bewusstsein ist API-fragil. MPPs Determinismus hängt an 2-MB-Pages, der aktuellen CTA-Struktur und dem aktuellen Tiling. Ein Treiber-Update mit anderer Page-Größe oder ein Kernel-Wechsel mit anderer CTA-Form lässt BOOST Richtung Zufalls-Placement-Verteilung degradieren — der Runtime jagt ein bewegtes Ziel, lautlos.
4. Peak gegen gemessen. Spec-Sheet-Arithmetik mit den Marketing-Zahlen statt der gemessenen 3.330 GiB/s understated α und jede abgeleitete Zahl; Spec-Sheet-Zähler und Praxis-Nenner nie mischen — auch beim C2C-Spread dieses Papers (419 gegen 350 GiB/s) nicht.
5. Der UNISON-Hebel, unverblümt: BOOSTs auf-Silizium-gemessene Glaubwürdigkeit schneidet in beide Richtungen — die Validierungs-Lücke von UNISON (ein Trace-Modell, kein Rubin-Silizium, siehe unsere Analyse dort) liest sich jetzt rauer. Man beobachte erst, ob der Silizium-Pfad eine hardware-gemessene Wende liefert, bevor man die übrigen Claims bepreist. Diese Watchlist ist Ihre.

Das Urteil, ohne Hype: keine Silizium-Revolution, keine gratis 31%, sondern ein klares Buchhaltungsresultat, das zufällig mit der richtigen Hardware ankommt, um es zu demonstrieren. Jedes Tiering-System, das beim Decode Host-Daten in schnellen Speicher stagt, verbraucht genau das Interface, das es schützen will; solange eine NVLink-Klasse-Kopplung die Host-Bandbreite innerhalb einer Generation der schnellen Tier hält: beide gleichzeitig lesen — proportional, pro Welle. Ob sich das auf Ihre Flotte überträgt, hängt an der Zahl, die in keiner Pressemitteilung steht: Ihrem α — gemessen, auf Ihrer SKU, mit Ihren Batch-Größen.

Quellen