Cortex: Workflow-Aware Resource Pooling and Scheduling for Agentic Serving

Grundinformationen

• Paper-ID: 2510.14126
• Titel: Cortex: Workflow-Aware Resource Pooling and Scheduling for Agentic Serving
• Autoren: Nikos Pagonas (Columbia University), Yeounoh Chung (Google), Kostis Kaffes (Columbia University), Arvind Krishnamurthy (Google & University of Washington)
• Klassifizierung: cs.DC (Distributed, Parallel, and Cluster Computing)
• Veröffentlichungsdatum: 15. Oktober 2025 (arXiv-Preprint)
• Paper-Link: https://arxiv.org/abs/2510.14126

Zusammenfassung

Dieser Artikel stellt Cortex vor, einen Workflow-bewussten Serving-Plattform-Prototyp für Agent-Workloads. Das Kernprinzip von Cortex ist die Phasenisolation: Bereitstellung dedizierter Ressourcenpools für jede unterschiedliche Phase eines Agent-Workflows. Diese einfache, aber leistungsstarke Strategie mindert phasenübergreifende Interferenzen bei Berechnung und Speicher, was zu besserer KV-Cache-Auslastung, höherem Durchsatz und vorhersagbarerer Leistung führt. Durch die Anpassung der Ressourcenallokation und Planung innerhalb jeder unterschiedlichen Phase des Agent-Workflows legt Cortex den Grundstein für fortgeschrittenere Agent-native Serving-Paradigmen, einschließlich plastischer Ressourcenverwaltung, spekulativer Ausführung von Workflow-Verzweigungen und gemeinsamen mehrschichtigen Caches für „Agent-Status".

Forschungshintergrund und Motivation

Problemdefinition

Agent-Workflows kombinieren die Inferenz großer Sprachmodelle (LLMs) mit iterativer Werkzeugnutzung: Das Modell beobachtet Zwischenergebnisse, denkt nach, ruft ein anderes Werkzeug auf und wiederholt dies, bis die Aufgabe gelöst oder das Budget aufgebraucht ist. Dieses geschlossene Schleifenmuster wird in produktiven Anwendungen zunehmend wichtig, wie beispielsweise Natural Language to SQL (NL2SQL) Agenten.

Einschränkungen bestehender Ansätze

Aktuelle LLM-Serving-Plattformen weisen folgende Probleme auf:

1. Workflow-Unempfindlichkeit: Beliebte LLM-Serving-Frameworks (wie vLLM) behandeln jede Phase als unabhängigen LLM-Aufruf mit First-Come-First-Served (FCFS)-Planung
2. Fehlende Strukturbewusstsein: Bestehende Agent-Serving-Plattformen (wie Autellix) verwenden komplexe Prioritätsstrategien, verstehen aber nicht die interne Workflow-Struktur
3. Verschwendete Cache-Möglichkeiten: Fünf Verbesserungsversuche für dasselbe Muster erzeugen fünf identische Prompt-Konstruktionen und fünf identische Hot-Cache-SQL-Ausführungen
4. Blinde Planung: Planung von LLM-Aufrufen ohne Kenntnis des verbleibenden Workflows, Ignorieren von Downstream-Kosten

Forschungsmotivation

Die Autoren beobachten, dass ein einzelner gemeinsamer „universeller" LLM-Engine-Pool nicht für Agent-Workflows mit heterogenen Phasen geeignet ist. Jede Phase (SQL-Generierung, Ausführung, Fehlerkorrektur) hat unterschiedliche Latenzprofile, Speicheranforderungen und Cache-Möglichkeiten.

Kernbeiträge

1. Vorschlag der Cortex-Architektur: Erste Workflow-bewusste Serving-Plattform basierend auf Phasenisolation mit dedizierten Engine-Pools für jede Workflow-Phase
2. Realisierung erheblicher KV-Cache-Optimierungen: Signifikante Reduzierung des KV-Cache-Speicherverbrauchs durch Phasenisolation und verbesserte GPU-Speicherauslastung
3. Beseitigung phasenübergreifender Interferenzen: Wiederherstellung stabiler phasenlokal begrenzter Latenzmodelle und verbesserte Leistungsvorhersagbarkeit
4. Gestaltung eines Agent-nativen Serving-Frameworks: Grundlagen für plastische Workflows, spekulative Ausführung und Agent-Status-Verwaltung

Methodische Details

Aufgabendefinition

Am Beispiel eines NL2SQL-Workflows ist die Eingabe eine natürlichsprachige Abfrage (z. B. „Wie hoch waren die Verkäufe in Europa im letzten Quartal?"), die Ausgabe ist ein erfolgreich ausgeführtes SQL-Abfrageergebnis. Der Workflow umfasst:

1. Abruf des Zielschemas
2. Autoregressive Generierung von Kandidatenabfragen
3. Abfrageausführung
4. Validierung des Ergebnissatzes
5. Bei Abfragefehler: Korrektur und Wiederholung

Zentrale Architektur-Gestaltung

Phasenisolationsprinzip

Cortex stellt für jede Workflow-Phase einen dedizierten Engine-Pool bereit. Ein Engine-Pool ist eine Gruppe homogener Worker (z. B. GPUs für LLM-Dekodierung oder CPU-Executoren für SQL), verwaltet durch einen phasenlokal begrenzten Scheduler mit eigener Warteschlange, Cache und Skalierungsstrategie.

Systemkomponenten

1. Orchestrator:
   • Workflow-bewusst, verfolgt die Position jeder Anfrage im Graphen
   • Prognostiziert die nächste Gruppe berechtigter Operatoren
   • Fügt Prioritätsschlüssel basierend auf SLO-Spielraum, Phasenselektivität und erwarteter Servicezeit an
2. Engine-Allokationsschicht:
   • Leitet Unteraufrufe zu konkreten Pool-Instanzen weiter, die Lokalität maximieren
   • Balanciert Last zwischen Replikationen
   • Ordnet Anfragen basierend auf Priorität neu
   • Führt Zulassungskontrolle durch, wenn eine Phase zum Engpass wird
3. Ressourcen-Borrowing-Mechanismus: Wenn Last und Speicherdruck ausreichend niedrig sind, kann der Orchestrator opportunistisch kompatible Phasen ermöglichen, untätige Engines zu borgen, um Fragmentierung zu reduzieren und Auslastung zu verbessern.

Technische Innovationen

KV-Cache-Optimierung

Durch Phasenisolation behält jede Engine nur ihren phasenspezifischen Kontext, während gemeinsame Engines zwei Phasen-Kontexte auf jedem Replikat im Hot-Cache halten müssen, was den KV-Cache-Speicherverbrauch effektiv verdoppelt. Der zurückgewonnene GPU-Speicher erhöht die effektive Batch-Größe, was sich direkt in höherem Durchsatz und strafferer Tail-Latenz übersetzt.

Leistungsvorhersagbarkeit

Phasenisolation beseitigt phasenübergreifende Interferenzen, die Vorhersagbarkeit beeinträchtigen. Wenn heterogene Aufrufe Engines teilen, koppeln Batches ihre Laufzeiten, verzögern Token-Emission und machen die Latenz von LLM-Aufrufen von ihren Batch-Partnern abhängig.

Unabhängige Skalierung

Ermöglicht unabhängige Skalierung und Konfiguration: Schnelle Monitore skalieren nur Pools, die SLOs gefährden, ermöglichen leichte Konfiguration für einmalige Laufzeit-Phasen, während kritische Pfad-Pools mehr Gewicht erhalten.

Experimentelle Einrichtung

Experimentelle Szenarien

Das Paper verwendet hauptsächlich NL2SQL-Workflows als primäres Experimentalszenario mit zwei LLM-Phasen:

• SQL-Generator
• SQL-Fehlerkorrektur
• SQL-Executor (nicht-LLM-Phase)

Bewertungsmetriken

• KV-Cache-Speicherverbrauch
• Gesamter Speicherverbrauch
• System-Durchsatz
• Tail-Latenz

Vergleichsmaßstäbe

• Gemeinsamer Engine-Pool-Ansatz: Alle Phasen teilen denselben LLM-Engine-Satz
• Cortex-Phasenisolations-Ansatz: Jede Phase verwendet einen dedizierten Engine-Pool

Experimentelle Ergebnisse

Hauptergebnisse

KV-Cache-Optimierungseffekte

Experimentelle Ergebnisse zeigen, dass der gesamte KV-Speicherverbrauch beim Ausführen von NL2SQL-Workflow-LLM-Phasen in Cortex signifikant reduziert wird. Wenn jede Phase in ihrem eigenen Cortex-Pool läuft, ist der gesamte KV-Fußabdruck deutlich niedriger: Jede Engine behält nur ihren phasenspezifischen Kontext.

Leistungssteigerung

1. Speichereffizienz: Durch Phasenisolation wird KV-Cache-Verdopplung vermieden und wertvollen GPU-Speicher freigegeben
2. Durchsatzsteigerung: Zurückgewonnener GPU-Speicher übersetzt sich direkt in höhere effektive Batch-Größen
3. Latenzverbesserung: Straffere Tail-Latenz und vorhersagbarere Leistung

Systemvorteil-Validierung

Experimente validieren drei Hauptvorteile von Cortex:

1. Verbesserte KV-Cache-Auslastung: Signifikante Speicherreduktion
2. Beseitigung phasenübergreifender Interferenzen: Wiederherstellung stabiler phasenlokal begrenzter Latenzmodelle
3. Unabhängige Skalierungsfähigkeit: Unterstützung feingranularer Ressourcenverwaltung

Verwandte Arbeiten

LLM-Serving-Frameworks

• vLLM: Effizientes Large Language Model Serving mit PagedAttention für Speicherverwaltung
• SGLang: Effiziente Ausführung strukturierter Sprachmodell-Programme

Agent-Serving-Plattformen

• Autellix: Effiziente Serving-Engine für LLM-Agenten mit komplexen Prioritätsstrategien
• HEXGEN-TEXT2SQL: NL2SQL-Workflow-Request-Planung basierend auf verbleibender Deadline-Spielraum und geschätzter Ausführungszeit

Technische Unterschiede

Bestehende Plattformen fehlt das Bewusstsein für interne Workflow-Struktur; Cortex schließt diese Lücke durch Phasenisolation.

Fazit und Diskussion

Hauptschlussfolgerungen

Cortex verbessert die Serving-Leistung von Agent-Workloads durch eine einfache, aber effektive Phasenisolations-Strategie erheblich. Der Ansatz verbessert nicht nur die Ressourcennutzungseffizienz, sondern legt auch den Grundstein für fortgeschrittenere Agent-native Serving-Paradigmen.

Zukünftige Richtungen

Plastische Workflows und Ressourcen

1. Rechnerische Adaptivität: Ersetzen schwerer Modelle durch leichte Varianten, wenn Latenz sich SLO-Grenzen nähert
2. Ressourcen-Elastizität: Verwendung stärkerer Engines zur Beschleunigung von Nachzüglern in Fan-Out-Mustern

Spekulative Ausführung

• Spekulation über wahrscheinlichste Workflow-Verzweigungen
• Vorwärmung relevanter Engines oder Vorausführung nächster Schritte
• Parallele Generierung und Bewertung mehrerer Kandidatenabfragen

Agent-Status-Verwaltung

• Mehrschichtige „Agent-Status"-Caches mit Zwischendaten als First-Class-Citizen
• Workflow-umfassende gemeinsame Schichten als Publish/Subscribe-Struktur
• Umwandlung wiederholter Werkzeug- und LLM-Aufrufe in Zero-Cost-Hits

Einschränkungen

1. Prototyp-Phase: Derzeit noch Proof-of-Concept, benötigt umfassendere Implementierung und Bewertung
2. Szenario-Beschränkung: Hauptsächlich NL2SQL-Beispiel, Validierung auf mehr Agent-Workflows erforderlich
3. Komplexitätsverwaltung: Wie man Schnittstellen entwirft, damit Workflows ihre Plastizität deklarieren können, bleibt eine offene Frage

Tiefgehende Bewertung

Stärken

1. Hohe Innovativität: Erste Vorschlag einer Workflow-bewussten Agent-Serving-Architektur
2. Präzise Problemidentifikation: Genaue Erkennung kritischer Probleme bestehender LLM-Serving-Plattformen
3. Einfache und effektive Lösung: Phasenisolations-Strategie ist einfach, aber wirkungsvoll
4. Zukunftsorientiert: Bietet klare Entwicklungspfade für zukünftige Agent-native Serving

Schwächen

1. Begrenzte experimentelle Validierung: Hauptsächlich auf ein NL2SQL-Szenario basiert, fehlen großflächig diversifizierte Experimente
2. Unzureichende quantitative Ergebnisse: Diagramme zeigen Trends, aber konkrete Leistungssteigerungszahlen fehlen
3. Unzureichende Implementierungsdetails: Weniger detaillierte Beschreibung spezifischer Implementierung von Planungsalgorithmen und Ressourcenallokationsstrategien
4. Unzureichende Vergleichsexperimente: Hauptsächlich Vergleich mit einfachen gemeinsamen Pool-Ansätzen, fehlt Vergleich mit anderen fortgeschrittenen Methoden

Auswirkungen

1. Akademischer Wert: Bietet neue Forschungsrichtung für Agent-Serving-Bereich
2. Praktischer Wert: Löst wichtige Probleme in realen Produktionsumgebungen
3. Inspirationswert: Bietet wertvolle Ideen für nachfolgende verwandte Forschung

Anwendungsszenarien

1. Mehrstufige Agent-Workflows: Besonders geeignet für Agent-Anwendungen mit klarer Phasenunterteilung
2. Ressourcen-sensitive Umgebungen: Signifikante Effekte in Umgebungen mit begrenzten Ressourcen wie GPU-Speicher
3. Hochleistungs-Anforderungsszenarien: Produktionsumgebungen mit strengeren Anforderungen an Latenz und Durchsatz

Literaturverzeichnis

Das Paper zitiert folgende Schlüsselliteratur:

1. vLLM: PagedAttention-Speicherverwaltungsmechanismus
2. SGLang: Strukturierte Sprachmodell-Programm-Ausführung
3. Autellix: LLM-Agent-Serving-Engine
4. HEXGEN-TEXT2SQL: Agent-Workflow-Planung
5. Verwandte NL2SQL- und Cloud-Service-Literatur

Gesamtbewertung: Dies ist ein innovatives und zukunftsorientiertes Paper, das wichtige Probleme im Agent-Serving-Bereich aufwirft und effektive Lösungen bietet. Obwohl es sich derzeit noch in der Prototyp-Phase befindet, zeigt es die Entwicklungsrichtung des Bereichs auf und hat wichtigen akademischen und praktischen Wert.