💻 computer science

Continuum: Efficient and Robust Multi-Turn LLM Agent Scheduling with KV Cache Time-to-Live

Das Papier stellt CacheTTL vor, ein neuartiges System zur Verwaltung von KV-Caches, das einen dynamischen Time-to-Live-Mechanismus einsetzt, um den Cache während von Tool-Aufruf-Pausen in mehrstufigen LLM-Agenten-Workflows selektiv zu erhalten, wodurch im Vergleich zu bestehenden Eviction-Richtlinien eine mehr als achtfache Verbesserung der Job-Abschlusszeit und ein gesteigerter Durchsatz erreicht werden.

Ursprüngliche Autoren: Hanchen Li, Runyuan He, Qiuyang Mang, Qizheng Zhang, Huanzhi Mao, Xiaokun Chen, Hangrui Zhou, Alvin Cheung, Joseph Gonzalez, Ion Stoica

Veröffentlicht 2026-05-06

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Hanchen Li, Runyuan He, Qiuyang Mang, Qizheng Zhang, Huanzhi Mao, Xiaokun Chen, Hangrui Zhou, Alvin Cheung, Joseph Gonzalez, Ion Stoica

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie betreiben eine hocheffiziente, superschnelle Küche, in der ein Meisterkoch (die KI) gleichzeitig komplexe Gerichte für viele Kunden zubereitet.

Das Problem: Die „Anhalten-und-Starten"-Küche

In einem normalen KI-Chatbot kocht der Koch ein Gericht, serviert es und beginnt sofort mit dem nächsten. Wird die Küche voll, wirft der Koch die halb vorbereiteten Zutaten für das aktuelle Gericht weg, um Platz für die Bestellung eines neuen Kunden zu machen. Das funktioniert für einfache Chats gut.

Moderne KI-„Agenten" sind jedoch anders. Sie chatten nicht nur; sie handeln. Sie denken, rufen dann ein Werkzeug auf (wie etwa die Wetterprüfung oder eine Websuche), warten auf das Ergebnis und dann erst setzen sie die Zubereitung desselben Gerichts fort.

Hier liegt der Fehler in aktuellen Systemen:

Der Koch beginnt, ein Gericht zuzubereiten.
Der Koch pausiert, um ein Werkzeug aufzurufen (z. B. „Wetter prüfen").
Da der Koch „pausiert", geht das Küchensystem davon aus, dass die Bestellung abgeschlossen ist. Es wirft die halb vorbereiteten Zutaten (den KV-Cache) weg, um Platz für andere Bestellungen zu schaffen.
Das Werkzeug ist in 2 Sekunden fertig. Der Koch ist bereit fortzufahren.
Katastrophe: Die Zutaten sind weg! Der Koch muss sie entweder bei einem entfernten Lagerhaus neu kaufen (CPU-Offloading) oder alles von Grund auf neu hacken (Neuberechnung).
Schlimmer noch: Da die Zutaten weggeworfen wurden, muss der Koch in der Schlange anderer Kunden warten, nur um wieder einen Platz am Schneidebrett zu bekommen.

Dies passiert immer wieder. Wenn ein Agent 20 Schritte benötigt, um ein Problem zu lösen, verschwendet er möglicherweise das 20-fache an Zeit durch Wiederholung von Arbeit und Warten in der Schlange.

Die Lösung: CacheTTL (Der „Bereithalten"-Timer)

Die Forscher entwickelten ein neues System namens CacheTTL. Stellen Sie es sich vor wie einen speziellen „Bereithalten"-Timer für jede Bestellung, den der Koch erhält.

Anstatt die Zutaten sofort wegzuwerfen, wenn der Koch pausiert, um ein Werkzeug aufzurufen, sagt das System: „Warte! Dieser Koch könnte in 2 Sekunden zurück sein. Halten wir die Zutaten für eine bestimmte Zeitspanne (Time-To-Live, oder TTL) auf der Theke bereit."

So funktioniert es einfach erklärt:

Intelligente Vorhersage: Das System schaut in die Vergangenheit. „Normalerweise dauert es etwa 2 Sekunden, wenn der Koch ‚Wetter prüfen' aufruft. Wenn sie ‚Web suchen' aufrufen, dauert es 5 Sekunden."
Der Timer: Es wird ein Timer basierend auf dieser Vorhersage gesetzt. Wenn der Werkzeugaufruf voraussichtlich 2 Sekunden dauert, bleiben die Zutaten 2,5 Sekunden auf der Theke.
Der Gewinn:
- Wenn der Koch rechtzeitig zurückkehrt: Die Zutaten sind noch da! Der Koch setzt genau dort fort, wo er aufgehört hat. Kein Neuhacken, kein Warten in der Schlange.
- Wenn der Koch zu spät ist: Wenn das Werkzeug statt 2 Sekunden 10 Sekunden dauert, läuft der Timer ab. Das System wirft die Zutaten sicher weg, um Platz für andere Kunden zu schaffen und verhindert, dass die Küche verstopft.

Warum ist das besser als das, was wir vorher hatten?

Frühere Systeme versuchten zu erraten, ob sie die Zutaten behalten sollten, betrachteten aber nur eine Sache: „Ist es teuer, die Zutaten neu zu kaufen?" Sie ignorierten das größere Problem: „Wie lange muss der Koch in der Schlange warten, um wieder arbeiten zu können?"

CacheTTL betrachtet beides:

Die Kosten für das Neuherstellen des Essens.
Die Kosten für das Warten in der Schlange (Warteschlangenverzögerung).

Es berechnet die perfekte Zeitspanne, um die Zutaten auf der Theke zu behalten, um insgesamt die meiste Zeit zu sparen.

Die Ergebnisse

Die Forscher testeten dies mit realen KI-Agenten, die Softwarefehler beheben, im Web suchen und Code schreiben. Sie stellten fest:

Geschwindigkeit: In einigen realen Tests schlossen die Agenten ihre Aufgaben bis zu 8-mal schneller ab.
Effizienz: Die Küche (GPU) konnte mehr Bestellungen gleichzeitig bearbeiten, ohne stecken zu bleiben.
Robustheit: Selbst wenn die Werkzeugaufrufe länger dauerten als erwartet, stürzte das System nicht ab oder blieb nicht stecken; es ließ den Timer einfach ablaufen und ging weiter.

Auf den Punkt gebracht

CacheTTL ist wie ein intelligenter Küchenmanager, der weiß, dass ein Koch, der pausiert, um einen Anruf zu tätigen, nicht mit dem Kochen fertig ist. Indem die Zutaten genau die richtige Zeit lang bereitgehalten werden, verhindert es, dass der Koch von vorne beginnen oder in der Schlange warten muss, was die gesamte Küche viel reibungsloser und schneller laufen lässt.

Technische Zusammenfassung: CacheTTL

Problemstellung

Inferenz-Engines für Large Language Models (LLM) verlassen sich derzeit auf „End-of-Turn"-Eviction-Richtlinien für das Management des Key-Value (KV)-Caches. In diesen Systemen wird der KV-Cache einer Anfrage, sobald die Decodierung abgeschlossen ist, aus dem GPU-Speicher entfernt, um die Auslastung für neue eingehende Anfragen zu maximieren. Obwohl diese Richtlinie für standardmäßige Multi-Turn-Chatbots effektiv ist, versagt sie bei agentic workloads (z. B. Software-Engineering-Agenten, Werkzeug-nutzende Agenten), die das ReAct-Paradigma befolgen.

In agentic Workflows sind Inferenzschritte mit externen Werkzeugaufrufen verflochten. Diese Werkzeugaufrufe führen zu Pausen, die oft kürzer sind als menschliche Tippgeschwindigkeiten, aber lang genug, um in Standard-Engines eine KV-Cache-Eviction auszulösen. Wenn der Agent von einem Werkzeugaufruf zurückkehrt, um den nächsten Inferenzschritt einzuleiten, muss das System entweder:

Das Präfix neu berechnen (Prefill), was erhebliche Latenz verursacht.
Den KV-Cache aus dem CPU-Speicher neu laden (falls Offloading aktiviert ist), was Warteschlangenverzögerungen pro Turn einführt. Selbst wenn der Neuladevorgang schnell ist, muss die Anfrage in der Warteschlange warten, bis GPU-Speicher durch andere aktive Anfragen freigegeben wird.

Bestehende Lösungen adressieren dies nicht ganzheitlich:

InferCept berücksichtigt Neuladekosten, ignoriert jedoch die sich akkumulierenden Warteschlangenverzögerungen pro Turn und fehlt an Robustheit gegenüber variablen Werkzeugdauern.
Autellix und Pie konzentrieren sich auf statische Workflows oder fehlen spezifische Beibehaltungsrichtlinien für dynamische Werkzeugaufrufe.
Statische Beibehaltungsstrategien riskieren, den GPU-Speicher zu blockieren, wenn Werkzeugaufrufe länger dauern als erwartet.

Die Kernherausforderung besteht darin, KV-Caches lange genug zu behalten, um Neuberechnungen und Warteschlangenverzögerungen zu vermeiden, ohne den GPU-Speicher während unvorhersehbarer Werkzeugausführungszeiten zu monopolisieren.

Methodik: CacheTTL

Die Autoren schlagen CacheTTL vor, ein Serving-System, das einen Time-to-Live (TTL)-Mechanismus für die KV-Cache-Beibehaltung einführt. Anstatt einer sofortigen Eviction selektiert CacheTTL KV-Caches im GPU-Speicher für eine berechnete Dauer und sperrt sie.

1. Kosten-Nutzen-Nutzungsmodell

CacheTTL bestimmt den optimalen TTL ( $\tau$ ), indem es den Trade-off zwischen den Kosten der Cache-Beibehaltung und dem Nutzen der Vermeidung einer Eviction modelliert.

Kosten ( $Cost(\tau, r)$ ): Die Opportunitätskosten der Belegung von GPU-Speicher, berechnet als Verhältnis des Speicherverbrauchs der Anfrage zum durchschnittlichen Speicherbedarf aktiver Anfragen, multipliziert mit der TTL-Dauer ( $\tau$ ). Dies repräsentiert die Latenz, die anderen Anfragen hinzugefügt wird, die durch den gesperrten Cache blockiert werden.
Nutzen ($Benefit(r)$): Die Summe zweier vermiedener Kosten:
1. CacheMissCost: Die Zeit, die zum Rekonstruieren des KV-Caches (Prefill) oder zum Neuladen aus dem CPU-Speicher erforderlich ist.
2. OutofOrderCost: Die Warteschlangenverzögerung pro Turn, die auftreten würde, wenn die Anfrage evicted würde und in der Warteschlange warten müsste, bis GPU-Speicher verfügbar wird. Dieser Term ist kritisch und unterscheidet CacheTTL von vorheriger Arbeit wie InferCept. Er wird mit einem Gedächtnisfaktor ( $\eta$ ) skaliert, der misst, wie die Anzahl der verbleibenden Schritte mit dem aktuellen Fortschritt korreliert (z. B. haben Programme mit fester Länge ein hohes Gedächtnis).

2. TTL-Berechnung

Das System berechnet den optimalen TTL ( $\tau^*$ ), indem es den erwarteten Nettovorteil maximiert:
$\tau^* = \arg\max_{\tau} \left( P(\tau, f) \times Benefit(r) - Cost(\tau, r) \right)$
Wobei $P(\tau, f)$ die Wahrscheinlichkeit ist, dass Werkzeugaufruf $f$ innerhalb der Zeit $\tau$ abgeschlossen wird, geschätzt mittels einer empirischen Kumulativen Verteilungsfunktion (CDF) aus historischen Werkzeugaufruf-Records.

Cold-Start-Handling: Wenn historische Daten knapp sind, verwendet CacheTTL standardmäßig einen festen TTL, der von einer Exponentialverteilungsannahme oder globalen Durchschnitten abgeleitet ist.
Robustheit: Wenn ein Werkzeugaufruf den TTL überschreitet, wird der KV-Cache automatisch evicted, um eine unbegrenzte Speicherbelegung und potenzielle Deadlocks zu verhindern.

3. Scheduling und Systemdesign

Program-Level FCFS: CacheTTL kombiniert TTL mit einer First-Come-First-Serve (FCFS)-Richtlinie auf Programmebene (nicht nur auf Anfragenebene). Dies stellt sicher, dass Anfragen desselben Agentenprogramms priorisiert werden, um Kontinuität zu gewährleisten.
TTL-bewusste Priorität: Der Scheduler weist ein mehrstufiges Prioritätstuple zu:
1. Unterbrochener Status.
2. TTL-Status: Anfragen mit aktiven TTLs (gesperrt) werden gegenüber ungesperrten priorisiert.
3. Ankunftszeit auf Programmebene.
Implementierung: Aufgebaut auf vLLM mit einem modularen Tool-Call-Handler. Dieser Handler analysiert LLM-Ausgaben, um Werkzeugaufrufe zu identifizieren, erfasst Intervalle zwischen Anfragen und kommuniziert TTL-Werte an den Scheduler. Das Design fügt einen minimalen Overhead hinzu (~1.000 Zeilen Python) und ist kompatibel mit CPU/SSD-Offloading.

Hauptbeiträge

Problemidentifikation: Die Arbeit identifiziert, dass bestehende KV-Cache-Eviction-Richtlinien die Leistung von Agenten verschlechtern, indem sie Warteschlangenverzögerungen pro Turn und die Variabilität der Dauer von Werkzeugaufrufen ignorieren.
CacheTTL-System: Ein neuartiges Serving-System, das einen TTL-Mechanismus zur dynamischen Beibehaltung von KV-Caches nutzt. Es balanciert Prefill-/Neuladekosten gegen Kosten durch Speicherkonkurrenz aus.
Neuartiges Kostenmodell: Die Einführung des OutofOrderCost-Terms, der die Warteschlangenverzögerungsstrafe einer Eviction quantifiziert, und des Gedächtnisfaktors, um sich an verschiedene Workload-Strukturen anzupassen.
Robustheit: Das System bewältigt unvorhersehbare Werkzeugdauern durch die Durchsetzung einer maximalen Beibehaltungszeit, wodurch Deadlocks und Speicherdruck verhindert werden.

Experimentelle Ergebnisse

Die Autoren bewerteten CacheTTL mit Llama-3.1 (8B/70B), Gemma-3 (12B) und GLM-4.5 (355B) über SWE-Bench, BFCL und OpenHands-Workloads auf verschiedener Hardware (A100, H100, B200).

Latenzreduktion: CacheTTL reduziert die durchschnittliche Job-Abschlusszeit um 1,12x bis 3,66x im Vergleich zu Baselines (vLLM, Autellix, InferCept). In realen SWE-Agent-Tests auf dem internen Testfeld von Unternehmen A wurde eine Verbesserung der Verzögerung um bis zu 8,18x erreicht.
Durchsatz: Der Durchsatz verbesserte sich um 1,10x bis 3,22x.
Robustheit: Das System behält eine stabile Leistung bei, wenn die Anzahl der Turns zunimmt, während Baselines aufgrund akkumulierter Warteschlangenverzögerungen signifikant nachlassen.
Kompatibilität: CacheTTL übertrifft Baselines selbst in Kombination mit CPU- und SSD-Offloading, was zeigt, dass seine Scheduling-Vorteile orthogonal zu Speicherauslagerungstechniken sind.
Overhead: Der Scheduling-Overhead ist vernachlässigbar (ein- bis zweistellige Millisekunden) und wird weitgehend durch die End-to-End-Latenzeinsparungen aufgewogen.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass CacheTTL die erste robuste, werkzeugbewusste KV-Cache-Managementstrategie bietet, die speziell für Multi-Turn-Agenten-Workloads entwickelt wurde. Durch den Wechsel von einer „End-of-Turn"-Eviction zu einer TTL-basierten Beibehaltungsrichtlinie überbrückt das System effektiv die Lücke zwischen LLM-Inferenz und der Ausführung externer Werkzeuge.

Die Autoren betonen, dass ihr Ansatz modular ist und mit minimalen Änderungen in bestehende Inferenz-Engines integriert werden kann. Sie argumentieren, dass eine prinzipielle, werkzeugbewusste KV-Verwaltung für die Zukunft des effizienten Agenten-Servings unerlässlich ist, insbesondere da agentic Workflows komplexer und multi-turn werden. Die Arbeit schließt mit der Open-Source-Veröffentlichung ihrer Traces, des Codes und des Testfelds ab, um weitere Forschung im Agenten-Serving zu fördern.