🤖 AI

A Policy-Driven Runtime Layer for Agentic LLM Serving

Dieser Beitrag schlägt eine neue architektonische „Agent-Laufzeitschicht" vor, die die Lücke zwischen Multi-Agenten-Frameworks und LLM-Bedienungsmaschinen überbrückt, um policy-gesteuerte Optimierungen zu ermöglichen, und zeigt anhand des CacheSage-Systems, dass dieser Ansatz die Cache-Trefferquote, die Zeit bis zum ersten Token und den Durchsatz bei diversen Multi-Agenten-Workloads signifikant verbessert.

Ursprüngliche Autoren: Rui Zhang, Chaeeun Kim, Liting Hu

Veröffentlicht 2026-05-28

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Rui Zhang, Chaeeun Kim, Liting Hu

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 belebtes, gehobenes Restaurant.

Der aktuelle Aufbau: Eine Kommunikationsstörung
Derzeit verfügt Ihr Restaurant über zwei unterschiedliche Ebenen, die nicht gut miteinander kommunizieren:

Der Küchenchef (Das Agent-Framework): Diese Person kennt die Speisekarte, die Rollen der Kellner und die spezifischen Anweisungen für jeden Tisch. Sie weiß, wer bestellt und was sie benötigen. Allerdings sieht sie niemals den Küchenboden; sie weiß nicht, welche Töpfe gerade auf dem Herd stehen oder welche Zutaten knapp werden.
Das Küchenpersonal (Die Serving-Engine): Dieses Team sieht jeden einzelnen Auftrag, der hereinkommt. Sie wissen genau, wie viele Töpfe kochen und wie schnell sie kochen können. Aber sie haben keine Ahnung, wer die Kunden sind oder welche „Geschichte" das Essen hat. Für sie ist jeder Auftrag nur eine generische Anfrage.

Das Problem: Die „Naht", an der Dinge brechen
Da diese beiden Gruppen keine Informationen austauschen, trifft das Restaurant ineffiziente Entscheidungen.

Beispiel: Der Küchenchef weiß, dass Tisch 4 immer dieselbe Vorspeise vor dem Hauptgang bestellt. Aber das Küchenpersonal weiß das nicht. Also muss die Küche jedes Mal, wenn Tisch 4 bestellt, Zwiebeln von Grund auf schneiden, obwohl sie dies gerade vor fünf Minuten für denselben Tisch getan haben.
Das Papier nennt dies die „Naht". Derzeit, wenn Sie dies beheben wollen, müssen Sie die Notizen des Küchenchefs oder den Arbeitsablauf der Küche mit einer spezifischen, einmaligen Regel patchen. Es ist chaotisch und skaliert nicht.

Die Lösung: Die „Agent-Laufzeitschicht" (Der neue Gastraumleiter)
Die Autoren schlagen vor, eine dritte Schicht genau zwischen dem Küchenchef und der Küche zu bauen: einen Gastraumleiter.

Dieser Gastraumleiter hat einen besonderen Job. Er hört dem Küchenchef zu (um die Rollen und Identitäten zu kennen) und beobachtet die Küche (um die Kochvorgänge zu sehen). Er nutzt dieses kombinierte Wissen, um mit vier einfachen Werkzeugen intelligente Entscheidungen zu treffen:

Beobachten: „Ich sehe einen neuen Auftrag vom Kellner 'Planer' kommen."
Bewerten: „Basierend auf der Historie ist dieser 'Planer'-Auftrag sehr wichtig und wird wahrscheinlich von einem 'Coder'-Auftrag gefolgt. Geben Sie ihm hohe Priorität."
Vorhersagen: „Ich wette, der nächste Auftrag wird vom Kellner 'Coder' kommen. Lassen Sie uns ihre Zutaten jetzt vorbereiten."
Handeln: „Machen Sie weiter und heizen Sie den Herd für den 'Coder' vor, damit es keine Verzögerung gibt."

Dieser Gastraumleiter fungiert als universeller Übersetzer. Jede neue Regel (wie „sei fair zu allen Tischen" oder „spare Energie") kann in diesen Manager eingesteckt werden, ohne den Küchenchef oder die Küche zu beschädigen.

Die Fallstudie: „CacheSage" (Der intelligente Vorratsschrank)
Um zu beweisen, dass dies funktioniert, bauten die Autoren einen spezifischen Gastraumleiter namens CacheSage, um den „Vorratsschrank" (den Arbeitsspeicher des Computers, oder KV-Cache) zu verwalten.

Der alte Weg: Die Küche wirft Zutaten (Speicher) basierend darauf, wie lange sie her sind, weg. Wenn der Kellner „Planer" nach einer Pause zurückkommt, muss die Küche alles neu schneiden, weil die Zutaten weggeworfen wurden.
Der CacheSage-Weg: Der Gastraumleiter lernt die Muster. Er bemerkt, dass „Planer" fast immer zu „Coder" führt.
- Wenn der „Planer" fertig ist, sagt der Gastraumleiter: „Ich prognostiziere, dass 'Coder' als Nächstes kommt."
- Sie halten die Zutaten des „Planers" sicher (damit sie nicht weggeworfen werden) und beginnen sogar, die Zutaten des „Coder" vor dem Eintreffen des Auftrags vorzubereiten.

Die Ergebnisse
Als sie dies an fünf verschiedenen realen „Restaurant"-Szenarien (komplexe KI-Aufgaben) testeten:

Weniger Verschwendung: Sie behielten die richtigen Zutaten 13 % bis 37 % öfter im Vorratsschrank als zuvor.
Schnellere Bedienung: Die Kunden bekamen ihr Essen 12 % bis 29 % schneller, weil die Küche nicht von Grund auf neu beginnen musste.
Mehr Kunden: Das Restaurant konnte 6 % bis 14 % mehr Tische pro Stunde bedienen.

Zusammenfassung
Das Papier argumentiert, dass wir, um KI-Agenten effizient laufen zu lassen, nicht nur die oberste Schicht (die Logik) oder die unterste Schicht (die Hardware) anpassen können. Wir brauchen einen dedizierten „Mittleren Manager", der sowohl die Identität der Agenten als auch die Ereignisse der Engine versteht und eine einfache Reihe von vier Regeln verwendet, um das gesamte System intelligenter und schneller zu machen.

Technische Zusammenfassung: Eine policy-gesteuerte Runtime-Schicht für das Serving agenter LLMs

1. Problemstellung

Multi-Agenten-Systeme mit Large Language Models (LLMs) haben sich zur dominanten Produktionslast entwickelt, doch der bestehende Serving-Stack ist architektonisch nicht auf ihre Anforderungen abgestimmt. Aktuelle Systeme arbeiten in einer zweistufigen Struktur:

Agenten-Framework (Oben): Systeme wie AutoGen, LangGraph oder MetaGPT, die Agenten-Identitäten, Rollenschemata und Dispatch-Logik verwalten. Sie emittieren LLM-API-Aufrufe, bleiben jedoch blind gegenüber Engine-Ereignissen auf niedriger Ebene (z. B. Token-Generierung, KV-Cache-Zustand).
Serving-Engine (Unten): Engines wie vLLM oder SGLang, die Prefilling, Batching und Token-Generierung übernehmen. Sie beobachten jedes Ereignis, besitzen jedoch kein Wissen über Agenten-Identitäten oder die semantische Struktur des Multi-Agenten-Workflows.

Diese „Nahtstelle" erzeugt eine kritische Lücke für übergreifende Policies. Viele Optimierungsstrategien – wie KV-Cache-Eviction, Batch-Formung, spekulative Ausführung, Fairness und Sicherheitsdurchsetzung – erfordern gleichzeitigen Zugriff auf Agenten-Identitäts-Metadaten (aus dem Framework) und Engine-Ereignisse auf niedriger Ebene (aus der Serving-Engine). Derzeit werden diese Policies als „One-off-Patches" entweder im Framework oder in der Engine implementiert. Dieser Ansatz ist brüchig, nicht modular und nutzt den für optimale Entscheidungsfindung erforderlichen vollständigen Kontext nicht aus.

2. Methodik: Die Agenten-Runtime-Schicht

Die Autoren schlagen eine architektonische Intervention vor: das Einfügen einer dritten Ebene, der Agenten-Runtime-Schicht, zwischen Framework und Serving-Engine. Diese Schicht fungiert als Substrat, das die übergreifenden Agenten-Metadaten verwaltet und eine stabile, policy-agnostische Schnittstelle bereitstellt.

Die vier Primitiven

Die Schicht definiert vier generische Primitiven, über die jede agentenbewusste Policy einstecken kann. Diese Primitiven bilden eine observe → score → predict → act-Feedback-Schleife, die durch die Agenten-Identität als gemeinsame Koordinate vereinheitlicht wird:

observe(event): Die Runtime empfängt policy-relevante Ereignisse von Nachbarn (z. B. Block-Touches, Request-Eingänge, Tool-Rückgaben). Sie aktualisiert einen internen Zustand, der mit der Agenten-Identität getaggt ist.
score(item): Die Runtime gibt eine pro-Element-Priorität zurück, die von einem Nachbarn zur Rangfolge von Entscheidungen verwendet wird (z. B. welcher KV-Block evicted werden soll, welcher Request zugelassen werden soll).
predict(horizon): Die Runtime gibt eine probabilistische Vorhersage zukünftiger Agenten-Aktivitäten zurück (z. B. die nächste Agenten-Rolle, der nächste Tool-Aufruf).
act(side_effect): Die Runtime löst Nebeneffekte außerhalb des kritischen Pfads bei einem Nachbarn aus (z. B. Warmup eines Caches, Vorladen von Gewichten, Hedging eines spekulativen Aufrufs). Dies ist das einzige Primitive, das den Zustand des Nachbarn verändert.

Fallstudie: CacheSage

Um diese Abstraktion zu validieren, instanziieren die Autoren die Schicht für KV-Caching, die Policy mit dem größten unmittelbaren Einfluss auf die Serving-Kosten. Sie stellen CacheSage vor, das das Problem adressiert, dass reaktive Prefix-Caches „Agenten-Anker" (System-Prompts und Tool-Definitionen) vor dem Eintreffen der nächsten Sitzung verwerfen.

CacheSage implementiert die vier Primitiven über drei Komponenten:

Transition Learner (observe): Führt ein gleitendes Fenster von paarweisen Agenten-Übergangszählungen ( $n(a', a)$ ), um eine Markov-Übergangsmatrix erster Ordnung online zu berechnen. Er identifiziert den „Agenten-Anker" (System + Tools) via Content-Hashing.
Survival-Probability Scorer (score): Approximiert die Wahrscheinlichkeit, dass ein Agent innerhalb der nächsten $K$ Schritte feuert. Anstelle teurer exakter Berechnungen verwendet er einen thresholded Directed Acyclic Graph (DAG) und Breadth-First Search (BFS), um einen „Hop-Count"-Proxy zu berechnen. Dieser Score wird mit der bestehenden Recency-Uhr der Engine kombiniert, um die Eviction-Priorität zu bestimmen.
Cross-Session Prefetch (predict + act): Zwischen Scheduler-Schritten sagt die Runtime den nächsten Agenten ( $a^*$ ) voraus und löst einen „Warmup"-Request aus. Dieser Request enthält nur den System-Prompt und eine minimale User-Nachricht, um den KV-Cache für den Anker des vorhergesagten Agenten zu füllen, ohne vollständigen sitzungsspezifischen Inhalt einzuspeisen.

3. Hauptbeiträge

Die Agenten-Runtime-Schicht: Eine vorgeschlagene dritte Ebene für den Serving-Stack, die eine Schnittstelle mit vier Primitiven (observe, score, predict, act) bereitstellt. Die Autoren ordnen neun verschiedene agentenbewusste Policies (einschließlich KV-Caching, Tool-Ergebnis-Memoisierung, Batch-Formung und Fairness) dieser Schnittstelle zu und argumentieren, dass sie alle denselben architektonischen Bedarf an mit Agenten-Identität getaggten Ereignissen teilen.
CacheSage: Eine konkrete Implementierung der Schicht für KV-Caching. Sie lernt pro-Workload Agenten-Übergangsmatrizen online und nutzt diese für eine überlebensbasierte Eviction und Prefetching zwischen den Schritten. Sie arbeitet mit begrenztem Zustand ( $\le$ 20 KB pro Workload) und beinhaltet einen graceful Fallback auf Standard-LRU, falls keine Struktur gelernt wird.
Empirische Validierung: Vorläufige Ergebnisse an fünf realen Multi-Agenten-Workloads (MMLU, MT-Bench, GAIA, GSM8K, HumanEval), die die Wirksamkeit des Ansatzes demonstrieren.

4. Ergebnisse

Experimente wurden auf NVIDIA H100 GPUs mit Llama-3.1-8B-Instruct durchgeführt und verglichen CacheSage mit vLLM und Continuum.

Cache-Hit-Rate: CacheSage erzielte eine Steigerung der Cache-Hit-Rate um +13 bis +37 Prozentpunkte (pp) im Vergleich zu vLLM über alle fünf Workloads hinweg. Dies wird auf die Beibehaltung von Agenten-Ankern über Sitzungsgrenzen hinweg zurückgeführt, die reaktive Caches typischerweise evicten.
Latenz: Die mittlere Zeit bis zum ersten Token (TTFT) und die End-to-End-Latenz pro Turn wurden um 12 % bis 29 % reduziert.
Durchsatz: Der Systemdurchsatz stieg um 6 % bis 14 %.
Overhead: Der Overhead im Hot-Pfad ist vernachlässigbar. Die observe-Funktion läuft bei $\sim1 \mu s$ pro Block-Touch, und der Scorer läuft in einstelligen Mikrosekunden. Der Koordinator-Zustand bleibt unter 25 KB.

Bemerkenswert ist, dass das Baseline-Continuum-System, das TTL-Pins verwendet, die Hit-Raten bei drei realen Task-Workloads tatsächlich um 9–23 pp reduzierte, was die Trade-offs statischer Policies gegenüber der adaptiven Natur der Runtime-Schicht unterstreicht.

5. Bedeutung und Behauptungen

Die Arbeit behauptet, dass die „Nahtstelle" zwischen Agenten-Framework und Serving-Engine am besten durch eine architektonische Änderung und nicht durch inkrementelle Punktfixes adressiert wird.

Modularität: Die Schnittstelle mit vier Primitiven ermöglicht es, dass verschiedene Policies denselben Beobachtungsstrom teilen und sich gegen dieselben Primitiven zusammensetzen, ohne dass für jede Policy neue Eingriffe in die Engine erforderlich sind.
Allgemeingültigkeit: Die Schicht ist framework-agnostisch (unterstützt AutoGen, LangGraph usw.) und engine-portabel und erfordert nur spezifische Hooks statt tiefgreifender interner Modifikationen.
Validierung der Lücke: Durch die Demonstration signifikanter Leistungssteigerungen beim KV-Caching argumentieren die Autoren, dass die architektonische Lücke real ist und eine Agenten-Runtime-Schicht eine notwendige Komponente für effizientes Serving agenter LLMs darstellt.

Die Autoren bleiben bezüglich des Umfangs ihrer aktuellen Arbeit bescheiden und stellen fest, dass, obwohl CacheSage die Abstraktion validiert, die anderen acht auf die Schicht abgebildeten Policies (z. B. Tool-Ergebnis-Memoisierung, spekulative Agenten-Ausführung, Fairness) offene Herausforderungen für zukünftige Arbeiten bleiben. Der Hauptbeitrag ist die Schnittstelle und das architektonische Argument, nicht die Vollendung jeder Policy-Implementierung.