💬 NLP

AGENTSERVESIM: A Hardware-aware Simulator for Multi-Turn LLM Agent Serving

Dieses Paper stellt AGENTSERVESIM vor, einen hardware-bewussten Simulator, der die Dynamik des Multi-Turn-LLM-Agenten-Servings – einschließlich Programm-Orchestrierung, werkzeugbedingter Lücken und KV-Cache-Residenz – präzise modelliert, um eine skalierbare und kosteneffiziente Evaluierung von Serving-Policies auf handelsüblicher CPU-Hardware zu ermöglichen, ohne dass umfangreiche Deployments in echten Systemen erforderlich sind.

Ursprüngliche Autoren: Rakibul Hasan Rajib, Mengxin Zheng, Qian Lou

Veröffentlicht 2026-06-09

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Rakibul Hasan Rajib, Mengxin Zheng, Qian Lou

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 führen ein geschäftiges Restaurant.

Die alte Art (Standard-LLM-Serving):
Früher war das Servieren von KI-Modellen wie ein Fast-Food-Drive-In. Jedes Auto (Anfrage) kommt an, bestellt einen Burger (eine einzelne Frage), bekommt ihn und fährt wieder weg. Die Küche kümmert sich nicht darum, was das Auto vorher gemacht hat oder was es als Nächstes tun wird. Jede Bestellung ist unabhängig. Wenn das Auto später zurückkommt, wird es wie ein völlig neuer Kunde behandelt.

Die neue Art (Multi-Turn Agent Serving):
Jetzt stellt sich das Szenario so dar, dass das Restaurant einen komplexen Kochwettbewerb ausrichtet. Ein einzelnes Team (ein „Agent“) bleibt für eine lange Zeit am Tisch. Sie fragen nach einer Zutat, und dann muss der Koch warten, während das Team in die Speisekammer geht, um ein Gewürz zu finden (ein „Tool Call“), und kommt dann zurück, um nach dem nächsten Schritt zu fragen. Dies geschieht dutzend veces in einer Sitzung.

Das Problem: Der Koch (die KI) muss das gesamte Rezept bisher im Kopf behalten. Wenn das Team für 5 Minuten an den Tisch geht, um in die Speisekammer zu gehen, sollte der Koch die Notizen auf dem Tresen (den „KV Cache“) nicht wegwerfen, denn er wird sie brauchen, wenn das Team zurückkehrt. Wenn das Team zu einem anderen Tisch (einem anderen Server) geht, wenn es zurückkommt, muss der neue Koch das gesamte Rezept von Grund auf neu lesen, was Zeit verschwendet.
Die Herausforderung: Dies zu verwalten, ist schwierig. Man muss entscheiden: Behalten wir die Notizen auf dem teuren, schnellen Tresen? Schieben wir sie in ein langsameres Regal im Hintergrund? Werfen wir sie weg, wenn das Team zu lange weg ist? Und welcher Koch sollte die nächste Runde des Teams übernehmen?

Die Lösung: AGENTSERVESIM
Die Autoren haben einen virtuellen Restaurant-Simulator namens AGENTSERVESIM entwickelt.

Anstatt zu versuchen, diese komplexen Regeln auf echten, teuren Supercomputern zu testen (was ein Vermögen kostet und ewig dauert), haben sie einen digitalen Zwilling gebaut, der auf normalen, günstigen Computern läuft.

So funktioniert ihr Simulator unter Verwendung der Restaurant-Analogie:

Der Programm-Orchestrator (Der Oberkellner):
In alten Simulatoren wurde jede Bestellung separat behandelt. Dieser Simulator hat einen Oberkellner, der den gesamten Kochwettbewerb als ein einziges „Programm“ verfolgt. Der Kellner weiß, dass Team A gerade auf die Speisekammer wartet, und lässt die nächste Bestellung erst starten, wenn der Gang zur Speisekammer abgeschlossen ist.
Der Tool-Simulator (Die Speisekammer-Uhr):
Manchmal muss das Team in die Speisekammer gehen (ein Tool wie grep oder pytest ausführen). Diese Wege können Millisekunden oder Minuten dauern. Der Simulator verfügt über einen speziellen Timer, der diese Verzögerungen genau nachbildet, sodass das System testen kann, ob es besser ist, die Rezeptnotizen auf dem Tresen zu behalten oder sie während des Wartens in das Regal zu legen.
Der Sitzungsbewusste Router (Der Tisch-Zuweiser):
Wenn das Restaurant mehrere Köche (Server) hat, versucht dieser Router, Team A zum gleichen Koch zurückzuschicken, mit dem sie begonnen haben. Dies hält die Rezeptnotizen genau dort, wo sie sind, was Zeit spart. Wenn dieser Koch zu beschäftigt ist, berechnet der Router die Kosten dafür, die Notizen zu einem neuen Koch zu bewegen, im Vergleich dazu, einfach von vorne zu beginnen.
Das KV-Residenzmodell (Der Notizschreiber):
Dies ist der intelligenteste Teil. Er entscheidet, wo die „Rezeptnotizen“ (KV Cache) gespeichert werden.
- HBM (Hochgeschwindigkeits-Tresen): Schnell, aber klein.
- DRAM/CXL (Hinteres Regal): Langsamer, aber größer.
- Das Modell fragt: „Kommt das Team in 10 Sekunden oder in 10 Minuten zurück?“ Wenn es 10 Sekunden sind, behalten wir die Notizen auf dem Tresen. Wenn es 10 Minuten sind, bewegen wir sie in das Regal, damit der Tresen für andere Teams frei bleibt.

Warum ist das wichtig?
Das Testen dieser Strategien auf echten Supercomputern ist so, als würde man versuchen, ein neues Restaurant-Layout zu testen, indem man tatsächlich das Restaurant baut, Personal einstellt und es wochenlang betreibt. Es ist teuer und langsam.

Das Ergebnis: Die Autoren haben ihren Simulator gegen echte Supercomputer getestet (mit echten KI-Modellen und echter Hardware). Sie fanden heraus, dass der Simulator vorhersagt, wie schnell der „Kochwettbewerb“ abgeschlossen sein wird, mit weniger als 6 % Fehler.
Der Nutzen: Ingenieure können nun tausende von „Was-wäre-wenn“-Szenarien auf einem normalen Laptop durchlaufen lassen, um die beste Art und Weise zu finden, wie sie diese KI-Agenten verwalten, ohne für jeden einzelnen Test teure Supercomputer mieten zu müssen.

Kurz gesagt: Sie haben einen hochpräzisen „Flugsimulator“ für KI-Agenten gebaut, der es Forschern ermöglicht, zu üben und zu optimieren, wie man komplee, mehrstufige KI-Aufgaben steuert, ohne das echte Flugzeug abzustürzen (oder ein Vermögen für den Treibstoff auszugeben).

Technisches Resümee: AGENTSERVESIM

Problemstellung

Moderne Bereitstellungen von Large Language Models (LLMs) bewegen sich weg von zustandslosen Single-Turn-Chat-Abfragen hin zu Multi-Turn-Agentic-Systemen. Im Gegensatz zum traditionellen Serving, bei dem jedes Prompt-Completion-Paar eine unabhängige Anfrage darstellt, führen agentische Systeme zustandsbehaftete Programme aus, die LLM-Aufrufe mit externen Tool-Aufrufen (z. B. Code-Ausführung, Websuche) verzahnen. Diese Tool-Aufrufe führen zu variablen Zeitlücken, die von Millisekunden bis zu Minuten reichen können.

Dieser Wandel verändert die Anforderungen an das Serving grundlegend:

Zustandsbehaftete Ausführung: Die vom Nutzer wahrgenommene Latenz ist die Job Completion Time (JCT) des gesamten Programms, nicht die Latenz einzelner Turns.
Cross-Turn-Abhängigkeiten: Spätere Turns erweitern oft denselben Kontext, wodurch die Cross-Turn-Präfix-Wiederverwendung systematisch wird.
KV-Cache-Dynamik: Der KV-Cache-Zustand muss die durch Tools induzierten Lücken überdauern, um kostspieliges Re-Prefilling zu vermeiden, doch das Beibehalten des Zustands während langer Pausen verschwendet knappe Ressourcen.
Routing-Komplexität: In Multi-Instanz-Bereitstellungen muss das Routing die Sitzungsaffinität wahren, um die Cache-Lokalität aufrechtzuerhalten, anstatt lediglich die Last zu verteilen.

Die Evaluierung von Scheduling-, Routing- und KV-Cache-Management-Policies für diese Workloads auf echter Hardware ist prohibitiv teuer. Jeder Designpunkt erfordert dedizierte Beschleunigerzeit, und der Konfigurationsraum (Ankunftsraten, Modellskalierungen, Speicherhierarchien) ist zu groß für erschöpfende reale Messreihen. Bestehende Simulatoren (z. B. Vidur, APEX, LLMServingSim) zielen auf zustandslose Workloads ab und versäumen es, Programmautonomie, Tool-Lücken oder Cross-Turn-KV-Residenz zu erfassen.

Methodik

Die Autoren präsentieren AGENTSERVESIM, einen hardware-bewussten Simulator, der speziell für das Multi-Turn-LLM-Agent-Serving entwickelt wurde. Der Simulator behandelt das Agent-Programm als die Ausführungseinheit statt einzelner LLM-Aufrufe. Er basiert auf einer modularen Architektur, die aus fünf Kernkomponenten besteht:

Program Orchestrator: Verwaltet einen pro-Programm-Zustandsautomaten, der die Turn-Reihenfolge und ausstehende Tool-Zustände verfolgt. Er stellt sicher, dass Turn $t+1$ erst nach Ablauf von Turn $t$ und der zugehörigen Tool-Lücke in der simulierten Zeit freigegeben wird, wodurch Programmautonomie und Abhängigkeiten gewahrt bleiben.
Tool Simulator: Materialisiert durch Tools induzierte Lücken. Er arbeitet in zwei Modi:
- Replay Mode: Verwendet erfasste Wandzeit-Dauern aus realen Traces zur Validierung.
- Generative Mode: Stichprobenartige Auswahl von Dauern aus angepassten Verteilungen für kontrafaktische Explorationen.
Session-Aware Router: Verwaltet Multi-Instanz-Bereitstellungen. Er pflegt eine Programm-zu-Instanz-Affinitätstabelle, um nachfolgende Turns an dieselbe „Heimat“-Engine zu routen und so die Präfix-Cache-Lokalität zu bewahren. Wenn die Heimat-Engine überlastet ist, berechnet er die Kosten für Migration oder Re-Prefilling.
Program-Aware Batch Scheduler: Erweitert den Scheduler um die Berücksichtigung der Programmautonomie. Er stellt programmbezogene Zustände (z. B. erreichte Service-Stufe) über austauschbare Policy-Hooks bereit, was programmbasierte FCFS- oder Attained-Service-Priorisierung ermöglicht, während die Standard-Admission- und Continuous-Batching-Logik beibehalten wird.
KV Residency Model: Verfolgt die Platzierung des KV-Caches über Speicherebenen hinweg (HBM, Host-DRAM, CXL). Es weist KV-Blöcken basierend auf der Tool-Gap-Dauer und den Recompute-Kosten definierte Deadlines zu. Es modellelt explizit Eviction, Swapping in den Host-Speicher und Retention-Entscheidungen während Tool-Lücken.

Der Simulator integriert diese Module mit einer Operator-Graph-Execution-Engine (basierend auf LLMServingSim 2.0 und ASTRA-sim), um heterogene Hardware, Interconnects und Multi-Tier-Speicherzugriffe zu modellieren.

Wesentliche Beiträge

Programmzentrierte Simulationsarchitektur: Ein neuartiges Framework, das das Agent-Programm als Ausführungseinheit abstrahiert und so die Untersuchung von Turn-Abhängigkeiten, tool-induzierten Leerintervallen und Cross-Turn-KV-Residenz innerhalb eines einzigen hardware-bewussten Frameworks ermöglicht.
Validierung gegen reale Bereitstellungen: Die Autoren validierten AGENTSERVESIM gegen reale Systemläufe auf drei Hardware-Plattformen (RTX 3090, H100-SXM, B200) unter Verwendung des SWE-Bench Verified Workloads. Der Simulator reproduziert das Verhalten realer Systeme mit einem Fehler von weniger als 6 % über Schlüsselmetriken (JCT und Durchsatz), während er vollständig auf handelsüblichen CPUs läuft.
Hardware-bewusste Design-Space-Analyse: Das Paper nutzt den Simulator, um das Zusammenspiel von Prefix-Caching, Scheduling, Routing und KV-Management systematisch zu untersuchen. Es identifiziert spezifische Bedingungen, unter denen agenten-bewusste Policies Vorteile bieten, wie etwa den Einfluss von Präfix-Wiederverwendungsraten und Tool-Latenzverteilungen.

Ergebnisse

Genauigkeit: Über 80 Konfigurationszellen hinweg (variierende Hardware, Modellgröße und Policies) entsprach AGENTSERVESIM der realen System-JCT mit einem mittleren relativen Fehler von <5 %. Die Durchsatzfehler waren ähnlich gering (<2 %).
Routing-Impact: In Multi-Instanz-Clustern hielt das sessions-bewusste Routing die Präfix-Cache-Hit-Rate nahe am Single-Instance-Maximum (96,26 %), während Round-Robin- und Least-Loaded-Routing die Hit-Raten um 3,3–3,6 Prozentpunkte senkten, was die JCT signifikant erhöhte.
Policy-Sensitivität: Der Vorteil von agenten-bewusstem Scheduling (z. B. Autellix, InferCept) gegenüber Request-Level-Baselines (vLLM-FCFS) hängt stark von der Präfix-Wiederverwendungsrate ( $\eta$ ) ab. Wenn $\eta < 0,3$ , dominieren Recompute-Kosten und die Unterschiede zwischen den Policies sind vernachlässigbar. Wenn $\eta \ge 0,5$ , kann eine falsche Wahl der Policy zu einer multiplikativen Erhöhung der JCT führen.
Tool-Latenz: Mit skalierender Tool-Latenz übertreffen agenten-bewusste Policies (insbesondere solche mit adaptiver oder statischer TTL-Retention) den FCFS-Ansatz deutlich. Bei bimodalen Tool-Traces war eine Regel mit statischem Schwellenwert für die Retention oft ausreichend, um den Großteil der Gewinne zu erzielen.
Memory Tiering: Das Hinzufügen einer zweiten Speicherebene (CPU-DRAM oder CXL) mildert den Leistungsabfall von HBM-only-Systemen unter hoher Last ab. Die CXL-Bandbreite bietet einen messbaren Vorteil (bis zu ~10 % JCT-Reduktion) an spezifischen Sättigungspunkten, was primär die Tail-Latenz begünstigt.

Bedeutung

Das Paper behauptet, dass AGENTSERVESIM eine kontrollierte, reproduzierbare Exploration von Agent-Serving-Policies ermöglicht, ohne die Notwendigkeit einer erschöpfenden Bereitstellung auf teuren Beschleunigern. Durch die getreue Modellierung der zustandsbehafteten Natur der Agent-Ausführung erlaubt der Simulator es Forschern:

Die Interaktion von Policies (Scheduling, Routing, KV-Management) zu evaluieren, die eng gekoppelt und in realen Systemen schwer zu isolieren sind.
Konfigurationen zu untersuchen, die physisch zu teuer oder nicht verfügbar sind (z. B. größere Cluster, hypothetische Speicherebenen wie CXL oder spezifische Tool-Latenzverteilungen).
Über Request-Level-Metriken hinauszugehen, um auf Programmbasis optimierte Ziele wie die Job Completion Time zu erreichen.

Die Arbeit etabliert ein Fundament für das Design der nächsten Generation von LLM-Serving-Stacks, die in der Lage sind, die komplexen, zustandsbehafteten Workloads moderner agentischer KI zu bewältigen.