HBF als dritte KV-Tier: 24x Sessions oder 5x schlechtere Latenz — das Medium ist in Ordnung, die Placement-Politik entscheidet

Zwei Papers, vier Wochen Abstand im Sommer 2026, derselbe Blick auf eine neue Speichertechnologie — High-Bandwidth Flash (HBF), 3D-NAND gestapelt hinter einem HBM-artigen On-Package-Interface — und gegenteilige Urteile. Ein IEEE-CAL-Paper aus der POSTECH-Linie (arXiv:2609.25782, Baek, Ji, Yoo, Kim) meldet, dass eine HBM-plus-HBF-Hot-Cold-Hierarchie 24x mehr Concurrent-Sessions pro GPU beherbergt und zugleich die Leseleistung um 7,6 kW pro 8-GPU-Node senkt¹. Eine Full-Stack-Charakterisierung der Peking-Universität (arXiv:2608.11668, Li, Bian, Huang, Zhao, Sun, Zhuo) — betitelt „HBF Sucks?" — baute das Naheliegende, einen SSD-artigen Mooncake-KV-Offload-Stack mit HBF darunter, und maß eine 2–5,5x schlechtere End-to-End-Latenz sowie einen Rückgang der maximalen SLO-Goodput um den Faktor 1,1–2,7².

Keines der Papers liegt falsch, und genau das ist der Punkt dieses Guides. Das Medium ist in beiden dasselbe; die Stream-Form, die es schlucken soll, ist es nicht. Das eine Design übergibt HBF einen kleinen, immutablen, einmal geschriebenen Cold-Pool, der nur beim Fortsetzen einer pausierten Agenten-Session gelesen wird. Das andere übergibt ihm den gnadenlosen Transient-KV-Schreibstrom eines ausgelasteten Serving-Nodes — in den HBF-Sucks-Traces operational 48–140 TB Schreibvolumen pro Tag, jeder Trace über beide Endurance-Envelopes — eine Last, die, in den Worten des Gegen-Papers, alle drei Bedingungen verletzt, unter denen eine schnellere Far-Tier überhaupt etwas bringt: Read-I/O-Bound, mehr Lese- als Schreibzugriffe, nachhaltig lieferbare Bandbreite². Die entscheidende Variable ist die Placement-Politik, nicht das Silizium. Dieser Guide rechnet die Arithmetik beider Urteile in Python nach, bepreist das Flash-Medium ehrlich (Endurance, Latenz, Energie, Page-Granularität) und fügt HBF in den Tiering-Thread ein, den wir diesen Monat aufgebaut haben: UNISON für das Host-DRAM-Scheduling pausierter Sessions, BOOST für konkurrenten Host-Zugriff — und jetzt die On-Package-Flash-Tier, in die beide letztlich münden.

1. Was HBF tatsächlich ist — und was verifiziert gegen simuliert ist

HBF überträgt HBM-Verpackungsdisziplin auf NAND: gedünnte Dies hinter einem Base-Die gestapelt, präsentiert über ein breites On-Package-Interface. Die erste öffentliche Spezifikation, veröffentlicht von SanDisk und SK hynix über das Open Compute Project am 3. August 2026, legt den Systemvertrag fest: 8-High- und 16-High-NAND-Stacks mit bis zu 512 GB pro Stack, drei gestufte Bandbreitenklassen von rund 0,4 bis 3,0 TB/s pro Stack und UCIe als Host-Interface statt eines proprietären PHY³. SanDisks First-Generation-Ziele sind 1,6 TB/s Lesebandbreite und 512 GB pro Stack — gegen HBM4 mit 48–64 GB pro Stack sind das grob 8–10x Kapazität pro Stack (SanDisk wirbt mit 8–16x Kapazität bei ähnlichen Kosten pro Stack, der schärfste Satz ihrer Materialien)³. Der Preis, der mit den Bits kommt: Lesezugriffe dauern ~25 Mikrosekunden — zwei Größenordnungen hinter HBM mit ~100 ns — bei Page-Granularität von zig Kilobytes, und die Endurance wird durch Program/Erase-Zyklen begrenzt, die kein Stapeln ändert.

Timeline-Ehrlichkeit, weil Vendor-Folien sie verwischen werden: SanDisks Roadmap von August 2025 versprach HBF-Samples für das zweite Halbjahr 2026 und Inferenzgeräte-Samples für Anfang 2027. Stand Investor Day, 13. August 2026, ist der erste HBF-Die getaped out, Inferenzprodukt-Samples weiterhin für 2027 terminiert, Massenproduktion für 2028 — während SK hynix' FMS-2026-Keynote Full-Spec-Samples auf Anfang 2028 legte⁴. Niemand außerhalb der Hersteller hat einen physischen Stack vermessen. Jedes quantitative Ergebnis unten — inklusive des Papers, um das es hier geht — ist trace-basierte Simulation über analytische Modelle, kein Silizium. Die Methodik-Sektion des CAL-Papers sagt es selbst: ein hausinterner, trace-getriebener Simulator mit analytischen Latenz- und Leistungsmodellen auf einem modellierten B200-Node⁵. Entsprechend labeln.

2. Bimodaler agentischer KV: Warum die Zugriffsverteilung zwei Buckets hat

Der erste Beitrag des CAL-Papers ist eine Workload-Beobachtung, keine Hardware-Beobachtung — und an ihr hängt alles andere. Agentische Sessions verhalten sich nicht wie Chat-Traffic. Eine Session lebt stundenlang als Loop aus Decode-Schritten, Tool-Aufrufen und Nutzereingaben; ihr KV-Cache wächst über die gesamte Session, statt pro Query zurückgesetzt zu werden. Während sie decodiert, wird der ganze Cache jeden Schritt gelesen. Während sie auf ein Tool oder einen Menschen wartet — das ist die meiste Zeit; das Paper modelliert Idle-Gaps mit einem Median von ~8 Sekunden und einem Mittel von ~23 Sekunden — ist der Cache toter Ballast, der trotzdem vorgehalten werden muss, denn Fortsetzen ohne ihn bedeutet, den gesamten Kontext neu zu berechnen⁵.

Wir haben diese Form auf der Flottenseite in unserem Agenten-Fleet-Economics-Stück quantifiziert: Am Matt-Barrie-Ankertag (~44 Agenten, ~4B Tokens) waren rund 75% aller Tokens Cache-Reads des eigenen Fleet-Kontexts, keine frische Arbeit — ein Agent, der 50 Schritte gelaufen ist, sendet seine ersten 49 Schritte 50-mal zurück. Diese Looping-Fraktion ist die traffikseitige Signatur derselben Bimodalität, die das CAL-Paper speicherseitig misst: In seiner Simulation belegt der Hot Set — der KV des gerade decodierenden Batchs — ~96 GiB, etwa 3% der Gesamt-KV-Kapazität, zieht aber ~98% des Lesetraffiks⁵.

Rechnen Sie die Session-Arithmetik für die Workload des Papers nach, Qwen3-Coder-30B-A3B (48 Layer, 4 KV-Heads, head_dim 128 in der Formel aus unserem Glossar — 2 x Layer x kv_heads x head_dim x 2 Byte pro Token, das die 96 KiB/Token des Papers exakt rekonstruiert):

kv_per_token = 2 * 48 * 4 * 128 * 2          # Bytes, BF16
print(kv_per_token / 1024)                    # 96.0 KiB -> deckt sich mit dem Paper
peak_ctx = 16700
print(peak_ctx * kv_per_token / 2**30)         # 1.53 GiB KV bei Peak 16.7k Kontext
print(3900 / 165)                              # 23.6 -> die im Abstract gerundeten „24x"

Ein HBM-only-B200 mit 192 GiB saturiert bei 165 Concurrent-Sessions für diesen Trace; eine 3-TiB-HBF-Cold-Tier erweitert auf 3.900⁵. Beide Zahlen sind Simulationsausgaben, und die „24x" ist ein Runden von 23,6x — aber der Kapazitätsmechanismus ist reine Arithmetik: Ohne Tiering streiten Cold-Pool und Hot Set um dieselben 192 GiB, und der Cold-Pool ist ~30x so groß wie der Hot Set.

3. Write-on-Evict: Die Placement-Politik, die die Endurance in der Garantie hält

Der Policy-Einblick des CAL-Papers ist ein einziger Satz, den man sich merken sollte: Weil autoregressives Decodieren nur appended und ein KV-Block nach dem Schreiben nie modifiziert wird, sind KV-Blöcke immutabel — unter einer Write-on-Evict-Politik wird jeder Block höchstens einmal in seiner Lebensdauer in HBF geschrieben. Der Block erreicht HBF nur bei der Demotion aus dem HBM; wird er beim Fortsetzen wieder aufgenommen und später wieder eviziert, ist die HBF-Kopie weiterhin gültig, es passiert kein Rewrite⁵. Schreibzugriffe sind strikt auf den Eviction-Pfad beschränkt, und Eviction ist per Definition ein Idle-Block-Ereignis: LRU hält den pro-Schritt-gelesenen Hot Set natürlich im HBM und demoviert den Zustand pausierter Sessions, den nichts anfasst.

Genau das macht Flash-Endurance in diesem Design zur Nicht-Story und im SSD-Offload zur Schlagzeile. Rechnen Sie das Budget für die SLC-Annahme des Papers nach (3 TiB, 100.000 P/E-Zyklen, Write-Amplification 1.02 dank erase-block-alignter immutabler Appends — gegen 2–4 bei einer General-Purpose-SSD):

budget_gib = 3 * 1024 * 100_000               # total beschreibbare GiB über die Lebensdauer (3 TiB x 100k P/E)
churn_day = 3900 * 0.82                       # GiB, wenn der ganze Cold-Pool einmal/Tag umschlägt
print(budget_gib, "GiB Budget;", churn_day, "GiB/Tag bei vollem Churn")
print(budget_gib / churn_day / 365)   # ~263 Jahre bei naivem Voll-Churn

Die naive Grenze ist absurd sicher, weshalb die eigene Zahl des Papers die lastabhängige ist: Write-on-Evict liegt unterhalb einer Decode-Batchgröße von 32 bei praktisch unbegrenzter Lebensdauer (nichts wird eviziert) und erreicht selbst bei Volllast noch ~20 Jahre, während All-KV-to-Flash — die Politik, die jeden produzierten KV-Block nach HBF schreibt — von ~11 auf ~8 Jahre fällt und die 5-Jahres-Garantie nur knapp hält⁵. Dieselbe Stack, dasselbe Medium, dasselbe Endurance-Rating: einmal geschrieben gegen jeden Schritt geschrieben. Die Placement-Politik ist der gesamte Unterschied.

Nun die Gegenseite desselben Ledgers. HBF-Sucks vermisst echte Produktionstraces (vier zweistündige Qwen-Bailian-Traces, fünf Dense- und MoE-Modelle) und findet, dass Transient-KV operational 48–140 TB Schreibvolumen pro Tag auf einem ausgelasteten Node erzeugt, jeder Trace über beide Endurance-Envelopes². Setzen Sie das gegen einen TLC-HBF-Stack — TLC ist, was ein kostenoptimierter All-Flash-Pool tatsächlich verwenden würde — mit ~3.000 P/E-Rating:

tlc_budget_gib = 3 * 1024 * 3000  # GiB, die ein 3-TiB-TLC-Package über die Lebensdauer schreibt
churn_gib = 140e12 / 2**30 / 8    # 140 TB/Tag Node-Churn, verteilt über 8 Packages
print(tlc_budget_gib / churn_gib / 365)          # ~1,5 Jahre pro Package
print(tlc_budget_gib / (140e12 / 2**30) / 365)   # ~0,19 Jahre, wenn ein Package alles aufnimmt

Das ist das HBF-Sucks-Endurance-Urteil in wenigen Zeilen Python, und es ist keine Kritik am NAND — der kapazitativ gematchte ersetzte SSD-Pool (vier KIOXIA CM7-V mit 3,2 TB, 38,4 TB/Tag Vendor-Rating gegenüber dem 21,7-TB/Tag-Budget der HBF-Tier) verteilt dieselben Schreibzugriffe über deutlich mehr rohen NAND. Es ist Kritik daran, einen schreiblastigen, wiederverwendungsarmen Strom in eine Tier zu lenken, deren Schreibbudget durch die On-Package-Kapazität begrenzt ist.

4. Warum das Drop-in scheitert: drei verletzte Bedingungen und eine nächste Fehldeutung

Die am meisten zitierte und am häufigsten misverstandene Zahl des HBF-Sucks-Papers: Als die Autoren HBFs Lese- und Schreiblatenz um 3,75x skalierten, bewegte sich die End-to-End-Latenz um weniger als 1%². Flash-Latenz — wofür jedermann instinktiv den Zeigefinger hebt — ist hier fast irrelevant. Was das Drop-in tötet, ist strukturell: Die zweistufige Mooncake-artige Hierarchie hält wiederverwendbares KV in der Near-Tier und übergibt HBF „einen gnadenlosen schreiblastigen Strom. Schreibzugriffe übersteigen Lesezugriffe in jedem Trace", sodass ein 3D-ICE-Thermalmodell zeigt, dass der Stack sein Thermallimit weit unterhalb der Peak-Bandbreite erreicht². Das schnellere Gerät liefert das langsamere System, weil es als Müllhaufen benutzt wird: Transient-KV mit nahezu null Wiederverwendung wird geschrieben, eviziert und überschrieben — auf der Schreibseite eines Mediums, dessen gesamter ökonomischer Wert auf der Leseseite liegt.

Daher das Kosten-Nutzen-Modell des Papers: Eine schnellere Far-Tier zahlt sich nur aus, wenn (1) Read-I/O der Flaschenhals ist, (2) Lese- Schreibzugriffe überwiegen und (3) die gelieferte Bandbreite nachhaltig ist. Transient-KV verletzt alle drei gleichzeitig². Pausierte Cold-Pools verletzen keine — sie werden einmal geschrieben, einmal pro Fortsetzen gelesen und dazwischen tun sie nichts. Gleiches Medium, gegenteilige Urteile, und die entscheidende Variable ist der Strom, den man hineinrichtet.

5. Die 25-Mikrosekunden-Frage: Fortsetzungspfad in Ordnung, Pro-Schritt-Pfad fatal

Das CAL-Paper modelliert die HBF-Zugriffslatenz mit 25 Mikrosekunden. Ist das schnell oder langsam? Das hängt komplett davon ab, wie oft der Lesevorgang stattfindet — rechnen Sie das Latenzbudget gegen den Decode-Schritt nach, auf dem er sonst säße:

tbt_ms = 14          # TBT des Papers bei 72 tok/s pro Agent, A innerhalb des SLO
hbf_us = 25
print(hbf_us / (tbt_ms * 1000))     # 0.18% eines Decode-Schritts pro Lesevorgang
 
hot_gib = 96         # Hot Set am simulierten Betriebspunkt
for bw_tbps in (0.4, 3.0):          # HBF-Spec Grade 1 und 3
    print(f"Hot Set aus HBF: {hot_gib*1024/bw_tbps/1000:.0f} ms/Schritt vs 50 ms SLO")
# Grade 1: 246 ms/Schritt; Grade 3: 33 ms/Schritt -> beide über Budget, plus Compute

Einmal pro Fortsetzen, über die durch Sub-Array-Parallelität amortisierte KV-Übertragung der fortgesetzten Session und überlappt mit der CPU-seitigen Arbeit (Tokenisierung, Ergebnisparsen), die jedem Agenten-Turn vorausgeht, sind 25 Mikrosekunden pro Block Rauschen: Das Paper attributiert ~0,084 ms Overhead einem HBF-gestützten Fortsetzen, gegen 1,0 ms über NVLink-C2C-Hostspeicher, 7 ms über PCIe und 14 ms Rekomputation — wobei Rekomputation die Turn-Kosten bei hoher Concurrency verdoppelt und HBF-Loads reine I/O abseits des Compute-Pfads sind⁵. Beachten Sie die Reihenfolge: Bei Flash-Klasse-Bandbreite schlägt On-Package-HBF eine Host-DRAM-Offload-Tier beim Fortsetzen — dasselbe interconnect-gebundene Argument wie in unserem BOOST-Stück, von der Cold-Pool-Seite her erreicht.

Einmal pro Decode-Schritt ist dieselbe Latenz eine Wand: Der Hot Set muss aus einer Tier strömen, die ihn alle 14 ms trägt — weshalb das Design des Papers den Decode-Phase-KV ausschließlich aus HBM liest, immer — das Fortsetzen stellt zuerst in HBM wieder her, sodass die TBT vollständig unabhängig von der Cold-Position ist⁵. Genau die 25-Mikrosekunden-Nuance, die Vendor-Decks verwischen werden: HBF-Latenz ist für einen Idle-Fanout-Wiederaufnahmepfad in Ordnung und für eine batch-synchrone Pro-Schritt-Tier disqualifizierend. Das Paper, das HBF für Transient-KV auf den Pro-Schritt-Pfad legt — HBFlex, das auf einer DeepSeek-V4-Pro-Workload vollständig aus HBF serviert — muss sein ganzes Architekturbudget aufwenden (Placement-Balancing, aggregierter Writeback in Compute-Fenstern, lebensdauergeführtes Block-Packing), um Schreib-Lese-Interferenz und Garbage Collection zu bekämpfen, die eine Write-Amplification von ~30x erreicht — auch das ist trace-basierte Simulation⁶. Die GC-Zahl ist die SSD-Offload-Pathologie mit anderem Hut.

6. Die −7,6-kW-Leistungsbehauptung nachgerechnet

Die zweite Headline des Abstracts — Write-on-Evict senkt die Leseleistung um 7,6 kW pro 8-GPU-Node gegenüber dem Servieren allen KV aus Flash — klingt nach Green-Marketing, ist aber die Lese-Energie-Lücke bei mechanischer Arbeit. HBFs pro-Bit-Leseenergie ist unstandardisiert (das Paper fegt 8–30 pJ/bit), HBM liegt bei ~3,5 pJ/bit. Am modellierten Betriebspunkt — Hot Set 96 GiB, gelesen in jedem 14-ms-Decode-Schritt, angenommen 20 pJ/bit — zahlt die All-KV-to-Flash-Baseline HBF-Leseenergie auf jedem aktiv gelesenen KV-Byte:

hot, step_s = 96, 0.014
rate = hot * 2**30 / step_s        # Byte/s an Hot-Set-Lesesten
p_hbf = rate * 20e-12 * 8          # W bei 20 pJ/bit
p_hbm = rate * 3.5e-12 * 8
print(p_hbf, p_hbm, p_hbf - p_hbm)      # ~1178 W vs ~206 W -> ~972 W
print((p_hbf - p_hbm) * 8 / 1000)       # ~7.8 kW/Node gegen 7.6 kW im Paper

Unsere Rekonstruktion landet bei 972 W pro Gerät gegen ~950 W im Paper und 7,8 kW gegen 7,6 kW pro Node — innerhalb der Modellrundung ihrer Zahl⁵ (die Sensitivitätsspanne des Papers über den gefegten Leseenergiebereich beträgt 2,1–12,2 kW pro Node). Die Richtung der Behauptung ist physikalisch solide: Der Vorteil von NAND ist Idle-Leistung — der Cold-Pool kostet Milliwatt pro GB vorzuhalten, während die Kosten des Hot Sets pro Zugriff anfallen, und die Beschränkung des Zugriffs auf HBM begrenzt die teuren Joules auf 3% der Bytes. Aber die Einschränkung bleibt: Das ist ein Modeloutput, keine Messwertablesung. Der 20-pJ/bit-Input ist eine Annahme aus einer Leistungsbudget-Referenz, gefegt, weil kein Standardwert existiert⁵. Behandeln Sie die Kilowatt als plausible Spanne, nicht als Datenblatt.

7. Kapazitätsökonomie: drei Populationen, ein Sizing-Ledger

Warum überhaupt On-Package-Flash, wenn Host-DRAM (UNISONs Tier) und SSDs (Mooncakes Tier) bereits existieren und liefern? Dichte pro Dollar. Flash liefert grob 8–16x die Kapazität von HBM bei ähnlichen Kosten pro Stack³; Host-DRAM addiert eine CPU, einen kohärenten Link und die Speichermarge eines anderen; SSDs addieren Millisekunden und eine PCIe-Queue. Fürs Fleet-Sizing modellieren Sie die KV-Population als drei Eimer und lassen jedes Medium seinen Eimer bepreisen:

• Hot (aktiv decodierend, jeder Schritt gelesen): HBM. Bandbreiten- und energiegebunden, ~3% der KV-Bytes, ~98% der Lesevorgänge⁵.
• Pausiert (zwischen Turns, einmal pro Fortsetzen gelesen): HBF. Einmal bei Eviction geschrieben, einmal pro Fortsetzen gelesen, ~25 Mikrosekunden amortisierte Latenz gegen eine sekundenlange Idle-Gap.
• Eviziert/beendet (Session vorbei, Prefix vielleicht später wiederverwendbar): SSD-Pool. Hier zahlt sich die Mooncake-Wiederverwendungsmaschinerie aus — an wirklich kalten Daten.

Das ist die dreischichtige Arbeitsteilung, zu der auch die herstellerseitige Analyse konvergierte: HBM für aktiven KV und schreiblastigen Zustand, HBF für große, mehrheitlich gelesene Objekte, SSD für den kalten Rest³ — und es ist die Kapazitätsökonomie hinter unserem HBM4-Knappheitsstück: Der billigste Ausweg aus einer HBM-Kapazitätskrise besteht darin, aufzuhören, toten Kontext darin zu lagern. Das allgemeine KV-Tiering-Prinzip aus jenem Stück des Sommers gilt auch für die neue Tier: Die Hierarchie sollte die Zugriffsverteilung abbilden, nicht einebnen.

8. Was trägt, was simuliert ist — und die Falsifikationsliste

Für diesen Guide an den Primärquellen verifiziert: der CAL-Volltext (165 → 3.900 Sessions, 96 KiB/Token, 1,53 GiB Peak-KV, 0,82 GiB durchschnittlich resident, 14 ms TBT / 72 tok/s am Betriebspunkt, 0,084 ms HBF vs 1,0 ms C2C vs 7 ms PCIe vs 14 ms Rekomputation als Fortsetzung-Overheads, Hot Set 96 GiB / 3% Kapazität / 98% der Lesevorgänge, Write-on-Evict ~20 Jahre vs All-KV 8–11 Jahre unter Last, 950 W/Gerät und 2,1–12,2 kW/Node über den 8–30-pJ/bit-Sweep, SLC 3 TiB / 100k P/E / WAF 1.02, Idle-Gaps Median ~8 s, Mittel ~23 s)¹⁵; Abstract und Modell des HBF-Sucks-Papers (2–5,5x Latenz, 1,1–2,7x Goodput-Verlust, die 3,75x-Latenzskalierung, die E2E um weniger als 1% bewegt, das Dreiparameter-Nutzenmodell, thermals limitierte Bandbreite, TLC-Verschleiß vor dem ersetzten SSD-Pool)²; HBFlex' gemessener-GC-Rahmen (Write-Amp ~30x auf DeepSeek-V4-Pro, ebenfalls trace-simuliert)⁶; die OCP-Spezifikationsdetails und Vendor-Timelines³⁴. Unsere Python-Rechnungen oben: die Rekonstruktion der 96 KiB/Token, die 1,53-GiB-Session-Größe, die 23,6x-Session-Skalierung, die 972-W-→-7,8-kW-Leistungsrekonstruktion, das Grade-1/Grade-3-Pro-Schritt-Budget und die TLC-Endurance-Grenze (~1,5 Jahre pro Package bei Node-weitem Churn). Alles als Simulation Gelabelte ist Simulation — HBF-Silizium wurde bislang nirgendwo unabhängig vermessen.

Falsifikations-Watchlist, in der Reihenfolge, die die These töten würde:

1. Physische Stacks liefern langsamer als die Spec. All dies setzt Grade-1-bis-3-Bandbreitenklassen und ~25 Mikrosekunden in der Volumenproduktion voraus. Erste unabhängige Messungen (2028-Klasse, nach aktuellen Timelines⁴) verschieben jede Zahl hier: Landet die effektive Bandbreite am Low-Grade und schlagen Page-Granularitäts-Strafen auf zufällige Fortsetzungs-Lades, schrumpft der Fortsetzungsvorteil gegenüber NVLink-C2C auf null.
2. Echte Agenten-Fleets sind vielleicht nicht so pausiert. Die Bimodalität ruht auf schwer-lastverteilten Idle-Gaps aus einem skalierten Replay — Tausende Sessions, rekonstruiert aus einem kleinen SWE-bench-Trajektoriensatz⁵. Ein Fleet mit kurzen, dichten Tool-Loops und hoher Duty-Cycle sieht eher wie eine Durchsatz-Workload aus, die — wie das Paper zugibt — mit Big-Batch-Serving auf HBM ohnehin besser bedient wird.
3. Der Write-on-Evict-/LRU-Vertrag ist fragil. Recency-als-Politik trägt, bis der Hot Set selbst das HBM übersteigt (das Paper verzichtet bewusst auf Pinning, weil Pinning dort verklemmt⁵). Eine Workload mit großem aktiv gelesenem Working Set — Long-Context-Single-Stream-Reasoning, nicht Agenten-Fanout — eviziert den eigenen Hot Set und zahlt 25 Mikrosekunden pro Schritt. Die Politik, die im einen Regime rettet, verschlechtert im anderen — dies ist die Lektion aus UNISONs Duty-Cycle-Modell, eine Ebene tiefer.
4. Die Endurance-Zahlen sind SLC. Ein kostenoptimiertes Produkt liefert TLC oder QLC; dann ist die obige HBF-Sucks-TLC-Arithmetik die relevante, und Write-Budgeting wird zur First-Class-Software-Anforderung — exakt die „Wiederverwendungs-bewusste Platzierung, Schreibbudgetierung, Thermalkoordination", die das Gegen-Paper verschreibt².

9. Urteil — und wohin das im Thread gehört

Ohne Hype: HBF ist weder Revolution noch Fehler. Es ist eine Kapazitätstier mit Flash-Ökonomie und Near-Memory-Bandbreite, und die beiden September-Papers sind zwei Hälften einer einzigen Ingenieursregel: Übergib dem Flash die Population „nie schreiben, selten lesen", und es ist die beste Kapazität-pro-Watt-und-Dollar-Tier im Stack; übergib ihm die Population „ständig schreiben, selten lesen", und es ist die schlechteste. Die 24x-Session-Behauptung und die 2–5,5x-Latenz-Behauptung sind beide real, beide simuliert — und beide handeln von Policies, nicht von Medien.

Im Thread: UNISON schedulet pausierte Session-KV über Host-DRAM und bewies, dass das Scheduling-Problem real ist; BOOST bewies, dass die Host-Tier während des Decodes ein Bandbreiten-Peer ist, wenn konkurrent zugegriffen wird; das CAL-Paper zeigt, warum die nächste Ebene — On-Package-Flash — das Cold-Pool-Problem der UNISON-Art erleichtert (Fortsetzen in 0,084 ms statt 1,0 ms über C2C), aber nicht verschwinden lässt: Etwas muss weiterhin entscheiden, welche Population wo lebt und wann. Diese Entscheidungsschicht ist exakt der Punkt, an dem UNISONs Scheduler-Silizium, BOOSTs proportionales Placement und HBFs Write-on-Evict-Politik aufeinandertreffen. Wenn die HBF-Hardware 2027 irgendwo nahe der Spec landet, wird die Debatte 2028 in dieser Serie nicht lauten, ob man die Tier hinzufügt — sondern, wem die Placement-Politik gehört, die sie füttert. Dem Flash ist es egal. Die Stromform ist alles.

Quellen