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: wo die 703 GB sitzen, ist eine Tiering-Entscheidung, kein Detail — Optionen sind (a) HBM/VRAM behalten, in Flottengröße unmöglich, weil das die aktuell dekodierenden Sessions brauchen; (b) wegwerfen und beim Resume re-prefillen — rund 7 GB Read-und-Recompute pro Resume, der Worst Case; oder (c) Host-Speicher-Spill und hierarchische Stores, genau dort, wo das Paper seine Idle-Window-Migration verankert. In absoluten Zahlen: CXL-angebundener DDR5 liefert effektiv wenige GB/s pro Device gegen die multiplen TB/s von HBM — drei Größenordnungen. Deshalb entscheidet wann man eine 7-GB-Session bewegt genauso viel wie ob: eine Migration im 10-s-Tool-Gap über ungenutzte DDR-Bandbreite ist gratis; dieselbe Migration, im Moment des Tool-Returns gestartet, konkurriert mit dem Resume-Prefill und ist reiner Verlust. Idle-Window-Scheduling ist keine Optimierung des Tierings — sie ist der Unterschied zwischen „Tiering funktioniert" und „Tiering ist ein Latenz-Bug". Zweitens: Die Policy-Frage — wer bleibt im Fast Tier, wer spillt, wer fliegt raus — produziert Residency-Kosten pro Fehlentscheidung; die Entscheidungen ereignisgetrieben, mit Loop-Mechanismus-Information (Tool-Call abgesetzt, Gap-Länge, Rundenindex) und in Silizium neben der Hierarchie zu treffen, ist UNISONs eigentlicher Anspruch.

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.