UNISON und die pausierte Flotte: Warum Agenten-KV-Traffic jede Cache-Policy bricht

Agenten-Serving hat ein Caching-Problem, das weder LRU noch TTL sehen kann, weil es in der Lücke zwischen zwei Ereignissen lauert. Ruft ein Agent ein Tool auf, steht seine GPU leer — die Session ist aber nicht tot, und sobald das Tool zurückkommt, läuft die Session mit ihrem kompletten KV-Präfix weiter. Ein Paper der Fudan-Universität von September 2026, UNISON (arXiv:2609.09643, He, Li und Zeng, eingereicht am 9. September 2026)¹, baut einen Near-Memory-Scheduler exakt um diese Blindstelle — lesenswert weniger wegen der Headline-Zahlen als wegen der Präzision, mit der es die Workload-Diagnose trifft: Eine auf einem Tool-Wait geparkte Session gilt für jede Recency- oder Timeout-Policy als „kalt" und wird Sekunden vor der Rückkehr des Tools entriert. Dieser Guide rechnet das Working Set durch, verifiziert den Mechanismus am arXiv-Text selbst, bepreist den Chip und ist schonungslos dabei, welche Gewinne ein Radix-Baum ohnehin geliefert hätte.

Das Working Set der pausierten Flotte: 703 GB, die irgendwo sitzen müssen

Zuerst die Kernarithmetik mit den site-verifizierten KV-Cache-Zahlen. DeepSeek-V3 MLA speichert 576 latente Elemente pro Token pro Layer über 61 Layer in bf16 — 70.272 B ≈ 68,6 KiB pro Token². Ein einzelner Agent mit 100k-Kontext trägt damit:

Jetzt die pausierte Flotte. Hundert Agenten, jeder bei 100k Kontext geparkt, während ihre Tools laufen:

In Python nachgerechnet: 100 × 100.000 × 70.272 B = 702,72 GB (654,5 GiB). Das sind rund neun GPUs der 80-GB-Klasse voller reinem KV-Zustand — belegt von Sessions, die nichts generieren, keine einzigen Attention-FLOPs zahlen und dennoch in Sekunden bis Minuten mit byte-genauen Präfixen fortsetzen müssen. Das ist die Storage-Array-Sicht auf agentische Inferenz aus unserem KV-Tiering-Guide: Die dominierende Ressource der Flotte sind residente Bytes, nicht Rechenleistung, und die Tool-Wait-Duty-Cycle entscheidet, wo diese Bytes leben.

Warum genau dieser Zustand beiden Standard-Policy-Klassen das Genick bricht:

• Recency-Klasse (LRU) wirft das Falsche raus. LRU rangiert nach letztem Zugriff. Ein tool-wartender Agent hat sein KV seit der letzten beendeten Runde nicht angefasst — eventuell seit Minuten. In einem umkämpften Pool sieht er älter aus als ein Gesprächs-User, der vor zwei Sekunden den Endpoint gepingt hat. LRU opfert den pausierten Agenten zuerst.
• Timeout-Klasse (TTL) wirft ihn nach Plan raus. Eine TTL-Policy verfällt Sessions nach fixem Idle-Fenster. Tool-Latenz ist aber heavy-tailed: Ein Code-Sandbox- oder Browser-Schritt dauert Sekunden bis Zehnersekunden. Jede brauchbar kurze TTL erfasst auch die Sessions, deren Tools zufällig langsam sind — was UNISONs eigene Formulierung als „behandelt ein lebendes Warten als kalte, wegwerfbare Einheit" trifft.¹
• Das Versagen ist strukturell, nicht tuning-bar. Es gibt keinen Schwellwert auf Recency oder Idle-Zeit, der „wartet auf ein Tool, kommt zurück" von „Session vorbei" anhand der Zugriffshistorie trennt — weil die unterscheidende Information, der Mechanismus der Loop, in der Job-Struktur lebt, nicht im Access-Log.

Ein konkretes Failure-Mode: eine Coding-Agent-Flotte mit Sessions von 30–60 Runden und Tool-Gaps von 2–30 s teilt sich einen Pool für die halbe Flotte. Bei jedem Burst entriert LRU exakt die Sessions mitten im Tool-Call — die mit dem meisten gebankten Kontext und den höchsten Re-Prefill-Kosten, falls verloren. Der Reflex „alles 30 s pinnen" (TTL) dreht das Versagen um, löst aber nichts: Er bindet Kapazität an längst beendete Sessions und verliert trotzdem den Agenten, dessen Tool 45 s brauchte.

Die Related-Work-Sektion des Papers sagt dasselbe auf Systemebene: PagedAttention paget den Pool wie virtuellen Speicher, SGLang nutzt Präfixe über einen Radix-Baum wieder — aber „beide entrieren nach Block-Recency, sodass eine auf einem Tool-Wait lebende Session" strukturell falsch gerankt wird.³

Zwei Verfeinerungen, bevor es um Silizium geht. Erstens können die 703 GB dieser Beispiel-Flotte bei entsprechend dimensioniertem HBM dort bleiben, verdrängt und neu berechnet oder in Host- beziehungsweise andere Speicherebenen verschoben werden. Keine dieser Optionen ist grundsätzlich unmöglich. Zweitens hängen Platzierung und Eviction von erwarteter Rückkehrzeit, Transferkosten und Konkurrenzverkehr ab. PCIe 5.0 x16 erreicht theoretisch rund 63 GB/s Nutzdaten je Richtung nach Kodierung, vor Transaktions- und Software-Overhead; die tatsächliche Bandbreite eines CXL-Geräts hängt von Link, Speicher, Zugriffsmuster und Auslastung ab. Eine pauschale Aussage von „wenigen GB/s“ oder drei Größenordnungen Abstand ist daher unbelegt. Ein Transfer von 7 GB während einer zehnsekündigen Tool-Pause kann Latenz verbergen, falls Bandbreite verfügbar ist, verbraucht aber weiterhin Bandbreite und Energie. Den Link-Basiswert nennt die PCI-SIG-FAQ zu PCIe 5.0. UNISONs Near-Memory-Scheduling adressiert diesen Platzierungskonflikt; seine Vorteile müssen für eine konkrete Hierarchie gemessen werden.

UNISONs Kernzahlen im Überblick

• 1.415 Sessions / 33.596 Turns, drei Modellfamilien, Coding- und General-Mission-Traces — bescheiden nach Produktionsmaßstäben, stattlich für ein Scheduling-Paper¹
• Hit-Rate +0,3 % bis +23,1 % gegen die besten Nicht-Oracle-Alternativen — die Breite dieser Spanne ist die Contentions-Geschichte in einer Zahl¹
• AMAT −22 % bis −51 % — Average Memory Access Time, die Metrik, die Tier-Platzierung bepreist¹
• TTFT −58 % bis −89 % auf Long-Horizon-Traces — ein Hit vermeidet das Re-Prefill eines ~7-GB-100k-Präfixes komplett¹²
• 0,169 mm² / 13,6 mW / 150 MHz bei 28 nm, 64 Sessions pro Core, Kendall τ > 0,998 gegen die Floating-Point-Referenz¹³

Jede dieser Zahlen stammt aus dem arXiv-Abstract oder dem HTML-Volltext, für dieses Stück abgerufen und geprüft — Quellen je in den Fußnoten. Jetzt der Mechanismus.

UNISON verifiziert: SPEAR + TIDE, ein geteilter Ranking-Kern

Im eigentlichen Paper (Abstract und HTML-Volltext)¹³ halten die Akronyme der Prüfung stand, und die Architektur ist wirklich gemeinschaftlich, nicht zwei angenagelte Heuristiken:

• UNISON = Unified Native Inter-turn Session Orchestration Nexus — ein ereignisgetriebener Near-Memory-Scheduler für Session-KV-Residency.
• SPEAR = Survival-Penalty Eviction for Agent Return-gap. Er entscheidet, wer den Pool verlässt — aus Gap-Durchschnitt plus turn-indizierter Hazard-Funktion: Sessions mit historisch langen Tool-Returns und vielen gebankten Runden überleben länger, weil die Survival-Kurve sagt, dass sie wiederkommen.
• TIDE = Tiering in Idle-window DMA Events. Er entscheidet, wer im Fast Tier sitzt — die beobachtete Wartezeit selbst wird als DMA-Budget ausgegeben: Während der Agent pausiert, wandern seine Blöcke zwischen Hierarchie-Tiers über Bandbreite, die sonst brachläge.

Zahlen-Check der Verluste nüchtern betrachtet: Selbst mit der gemeinsamen Policy beträgt der Hit-Rate-Gewinn auf manchen Traces nur 0,3 Prozent — das Wert-Dach jedes Schedulers entscheidet sich daran, wie oft der Pool überhaupt umkämpft ist, und Agenten-Flotten mit geringer Nebenläufigkeit kämpfen schlicht nicht. Die TTFT-Gewinne sind dafür riesig, weil der Gegenpol Re-Prefill ist: Ein gerettetes Präfix ist ein komplett vermiedener 100k-Token-Prefill — inkrementell ist daran nichts.

• Das Kern-Co-Design-Argument: SPEAR und TIDE teilen ein live Ranking, und das Papier enthält eine Struktur-Notwendigkeitsanalyse, wonach das vereinheitlichte Near-Memory-Design „nicht in unabhängige IPs zerlegt oder in Software realisiert werden kann, ohne dokumentierte Failure-Modes wieder einzuführen."¹ Der letzte Halbsatz ist die Autoren-Behauptung — dazu unten mehr.

Die Evaluation, gegen den Abstract verifiziert: Coding- und General-Mission-Benchmarks über drei Modellfamilien, insgesamt 1.415 Sessions und 33.596 Turns. Die gemeinsame Policy ist auf jedem Trace der beste Nicht-Oracle-Eintrag, mit Hit-Rate-Steigerung 0,3 % bis 23,1 %, AMAT-Senkung 22 % bis 51 % und TTFT-Senkung 58 % bis 89 % auf Long-Horizon-Traces.¹ Dazu gibt es eine vLLM-basierte Produktionsstack-Validierung gegenüber LRU über verschiedene Tool-Call-Frequenz-Schemata.³ Noch ein Prüf-Blick auf die Trace-Formulierung: „bester Nicht-Oracle-Eintrag auf jedem Trace" ist ein echter Satz — ein Oracle mit perfektem Zukunftswissen gewinnt trotzdem, und das Paper behauptet das Gegenteil nie. Ehrlich ist die Lesart: Der Scheduler schließt einen Großtteil der Strecke von LRU Richtung Belady-Klasse, und die Oracle-Lücke zeigt, wie viel Mechanismus-Information fehlt (vor allem: Tool-Ausgänge sind stellenweise echt unvorhersehbar, das holt kein Hazard-Modell zurück).

Das Survival-Framing verdient Nachdruck, denn es ist der konzeptionelle Kern des Papers. Zugriffshistorien-Policies sind Punkt-Schätzer: „Wie frisch wurde das angefasst?" SPEAR passt stattdessen eine Survival-Funktion über den Return-Gap an — wie viel länger dauert das Tool dieser Session, gegeben ihre Historie und den Rundenindex? — und bestraft Eviction entsprechend. Das ist derselbe statistische Wechsel, der CDN-Caching von LRU zu gelernten Relaxed-Belady-Policies brachte (das Paper zitiert diese Linie in der Related Work³). Der Rundenindex kodiert eine empirische Regelmäßigkeit von Agenten-Loops: Wer 40 Tool-Calls überstanden hat, kommt fast sicher vom 41. zurück — genau das Signal, das ein Access-Log nicht ausdrücken und ein Timeout nicht darstellen kann.

Für die Serving-Ökonomie tragen die AMAT- und TTFT-Zahlen: Ein Hit, der das Re-Prefill eines 100k-Präfixes vermeidet, spart nicht die nächste GPU-Sekunde des Agenten, sondern das komplette Re-Prefill — bei 7 GB pro Session der Unterschied zwischen „Resume in einem DMA-Durchlauf" und „ein buchlanger Kontext neu lesen und rechnen".

Chip-Ökonomie im Kleinen: 0,169 mm², 13,6 mW, 150 MHz

Der Scheduler-Kern ist ein 28-nm-CMOS-Block: 0,169 mm², 13,6 mW, 150 MHz, deckt 64 Sessions ab und reproduziert das Floating-Point-Ranking bei Kendall τ > 0,998 gegen die Referenz.¹³ Was für eine Silizium-Klasse ist das? Winzig. Zum Maßstab: kleiner als eine einzelne HBM4-PHY, mit weniger Leistungsaufnahme als eine dimmbare LED — Embedded-Controller-Klasse, der Block-Typ, der im Dutzend neben einem Memory-Controller sitzt. Dabei arbitriert er über die Residency einer Hierarchie, die in unserem Flotten-Rahmen Hunderte Gigabyte hält.

Das scheinbare Paradox — mW-Logik, die TB-Traffic steuert — löst sich auf, sobald man sieht, was ein Scheduler real bewegt: Pointer und Entscheidungen, keine Bytes. Die DMA-Engine und die Hierarchie bewegen die Bytes; SPEAR + TIDE entscheiden nur, welche Blöcke jene Engines anfassen und wann. Eine Residency-Entscheidung sind ein paar hundert Bit Zustand pro Block; der Block selbst ist 70 kB oder mehr. Die Asymmetrie zwischen Kontrolle und Daten beträgt fünf bis sechs Größenordnungen — und genau das ist das ökonomische Argument für Near-Memory-Scheduling: Cent-Logik neben den Speicher legen, damit Dollar-Bandbreite nie an die falschen Blöcke verschwendet wird. Sanity-Check inklusive: die eigenen Zahlen des Papers: bei 64 Sessions und 150 MHz beträgt die mittlere Scan-Latenz 2,00 µs, im Worst Case 3,14 µs — gerade 0,31 % des kleinsten beobachteten Tool-Gaps (1 ms) und weit unter den Medianen von 3,7–7,2 s; das Ranking ist gegenüber den Ereignissen, die es rangiert, praktisch instantan. Ein Host-Scheduler zülte für dieselbe Entscheidung CPU-Interrupts und PCIe-Roundtrips und hätte streng schlechtere Platzierung zum Zugreifen.

Die Hardware-Framing des Papers — „a negligible overhead relative to the KV hierarchy it manages"¹ — übersteht diesmal den Kontakt mit dem Datenblatt: 13,6 mW sind rund ein Hunderttausendstel des Envelopes einer einzigen Rubin-Klasse-GPU (ca. 1.400 W). Selbst rack-weit multipliziert (64 Sessions pro Core, also rund 32 Cores bzw. 0,44 W für 2.000 Sessions) kostet die Policy-Logik weniger als ein Gehäuselüfter. Die Bytes, die sie schützt, kosten Megawatt. Nicht irgendeine einzelne Hit-Rate, sondern dieses Verhältnis ist das Argument, das das Paper wirklich trifft.

Das Kendall-τ-Ergebnis ist der Glaubwürdigkeits-Check: Die Fixed-Point-Version des Rankings bei 150 MHz stimmt mit der Floating-Point-Referenz nahezu perfekt überein (Kendall τ > 0,998) — das Silizium ist keine Näherungsschmiede, es ist die Policy.

Das Software-Gegenspiel: Was RadixAttention schon heute liefert

Hier schonungslos bleiben, denn ein Teil von UNISONs Headline-Territorium ist heute in Software erreichbar. RadixAttention (arXiv:2312.07104) — der SGLang-Prefix-Cache — organisiert KV als Radix-Baum über Token-Sequenzen und nutzt geteilte Präfixe wieder, mit bis zu 6,4× höherem Durchsatz auf präfix-lastigen Multi-Turn-Aufgaben — das Paper führt dies auf das gesamte SGLang-System zurück (Radix-Reuse + komprimierte FSMs + Runtime), nicht allein auf den Baum.⁴ Eine Agenten-Session ist exakt ein präfix-lastiger Workload: Jede Runde erbt fast den ganzen bisherigen Kontext, ein gehaltener Präfix ist also ein komplett vermiedener Re-Prefill. Das Paper kennt diese Linie selbst (Related Work zitiert den Radix-Runtime), und sein Workload-Modell hält fest, dass das residente KV „präfix-lastig, weil spätere Runden das meiste ihres Kontexts von früheren erben, sodass ein Hit das Re-Prefill des vollen Präfixes vermeidet."³

Der Unterschied ist nicht rhetorisch, er entscheidet, was Sie deployen: Die Ranking-Hälfte von UNISON (Survival-Penalty-Eviction) kann ein Serving-Team als Patch in den Block-Manager seines Runtimes bringen — keine neue Hardware, kein Schedule-Risiko. Die Data-Path-Hälfte (Idle-Window-DMA-Tiering) braucht CXL-Spill-Infrastruktur oder den Near-Memory-Block des Papers — genau darauf müsste eine Produktionsadoption warten.

Also den Gewinn nach Mechanismus splitten:

• Rank-new-blocks-first-Gewinne — software-replizierbar. Vieles an SPEAR ist Policy: das Wissen, dass eine tool-wartende Session zurückkommt, aus Gap-Statistik und Rundenindex. Nichts daran braucht 28-nm-Silizium. Ein Runtime könnte Survival-Penalty-Eviction morgen im Host-Scheduler implementieren — SGLang hat mit der Radix-Baum-Blockgranularität bereits den Aufhänger. Wenn UNISONs Hit-Rate-Gewinne überwiegend aus besserer Eviction-Reihenfolge kommen (die LRU-Baselines im vLLM-Teil deuten genau darauf), fängt das Software-Gegenspiel sie ein.
• Data-Movement-Offload-Gewinne — hier liegt die echte Hardware-Geschichte. TIDEs Beitrag ist nicht das Ranking, sondern das Idle-Window-DMA: Während die Flotte tool-wartet, liegt die Lesebandbreite des Speichersystems brach, und Blöcke dann zu migrieren ist in einem Sinne gratis, wie es ein Host-Copy (der PCIe/CPU-Zyklen auf dem Serving-Knoten verbrennt) nie ist. Auf genau diesen Pfad zielt die Struktur-Notwendigkeitsbehauptung: Software-Tiering führt die Failure-Modes wieder ein, weil der Host die Migrations-Steuer mit Datenpfad-Zyklen zahlt.¹ In den AMAT-Reduktionen sollte sich das zeigen — und das ist der Teil, den eine cleverere Eviction-Reihenfolge allein nicht liefert.
• Der ehrliche, verifizierbare Split: das Paper berichtet seine Software-Ablationen als „führt dokumentierte Failure-Modes wieder ein", nicht als saubere Tabelle mit X-Prozent-Ranking-Anteil.¹ Das ist schwächere Evidenz als eine Dekompositionstabelle, und ein skeptischer Leser behandelt die „in Software unmöglich"-Framing als unbelegt, bis jemand eine Survival-Penalty-Eviction-Policy in vLLM schifft und das Delta misst.

Wann man das nicht braucht: Single-User-Setups, kurz-kontextige Chat-Modelle oder Flotten, deren Tool-Calls getarnte synchrone API-Hops unter 100 ms sind — das Working Set trennt sich nie von der Rechnung, und eine Idle-Window-DMA-Engine würde nichts schedulen. Das Muster verdient Silizium erst, wenn Pause-Resume-Duty-Cycles und Präfixgrößen Residency zum bindenden Engpass machen.

Urteil

UNISON ist das bislang glaubwürdigste Stück eines bestimmten Musters: Agenten-Session-KV-Policy aus dem Serving-Runtime heraus und in billiges Silizium neben dem Speicher, den es verwaltet, verlagern. Was es verifizierbar richtig macht: die Workload-Diagnose (Recency- und Timeout-Proxies rangieren lebende Tool-Waits nachweislich falsch), ein prüfbares Leistungsdatenblatt (13,6 mW sind ein Rundungsfehler gegen den Idle-Verbrauch eines einzigen HBM-Stacks) und einen Mechanismus — Idle-Window-DMA-Tiering —, der echt datenpfad-geboren ist statt einer Scheduling-Heuristik mit Hardware-Anstrich.

Die Einschränkungen gehören genauso ins Protokoll. Es ist ein Forschungsprototyp ohne Tapeout; die Trace-Klasse sind akademische Agenten-Benchmarks (1.415 Sessions), keine Produktionsflotte mit adversariellen Tenants; die Spanne „+0,3 % bis +23,1 %" zeigt extreme Trace-Abhängigkeit — ohne Speicher-Contention kann keine Policy gewinnen; und die Software-Unmöglichkeitsbehauptung ist Autoren-Framing, gemessen gegen LRU, nicht gegen eine starke Host-seitige Survival-Penalty-Baseline. Der RadixAttention-Gegenpol bleibt die Nullhypothese, die jede Produktions-Evaluation schlagen muss: Wenn Ihre Eviction LRU ist, sind Präfix-Reuse plus Survival-Penalties in Software vielleicht schon der größte Teil des Gewinns.

Wann das Muster in Produktion zählt? Multi-Tenant-Agenten-Flotten mit hohen Pause-Resume-Duty-Cycles — Idle-Window-DMA zahlt sich aus, wenn (a) Tool-Wait-Gaps häufig und lang genug für ein brauchbares Migrationsbudget sind, (b) das Working Set der pausierten Sessions an die Fast-Tier-Kapazität heranreicht (unsere 703-GB-Flotte — neun GPUs schlafender State — passt) und (c) Hits komplette Re-Prefills sparen statt Teilupdates. Sind Ihre Agenten gesprächig mit sub-Sekunden-Tool-Calls, sagt es UNISONs Trace-Klasse selbst: +0,3 %. Was unsere Meinung ändern würde: (1) ein Replay echter Produktions-Traces — etwa zehntausend Coding-Assist-Sessionen mit Per-Tenant-Contention —, das die AMAT-Deltareproduziert; (2) eine publizierte Host-seitige Survival-Penalty-Baseline in vLLM oder SGLang, damit die Nullhypothese gemessen statt behauptet wird; und (3) die Bestätigung eines Speicher-Vendors, dass der Block ohne eigenes ASIC-Programm neben einen CXL-Tier oder HBM-Controller integriert. Bis dahin die ehrliche Lesart: richtige Diagnose, billige und prüfbare Silizium-Geschichte, unbelegter Notwendigkeitsanspruch. UNISON als bestes Rechenblatt für die Paused-Fleet-Mathematik ablegen — und den Silizium-Endpunkt als vielversprechend, unbewiesen und günstiger als angenommen behandeln.