🤖 AI

Towards Understanding, Analyzing, and Optimizing Agentic AI Execution: A CPU-Centric Perspective

Diese Arbeit analysiert Agentic-AI-Workloads aus einer CPU-zentrischen Perspektive, identifiziert Systemengpässe und stellt zwei Scheduling-Optimierungen (COMB und MAS) vor, die durch verbesserte CPU-GPU-Nutzung die Latenz und den Durchsatz signifikant steigern.

Ursprüngliche Autoren: Ritik Raj, Souvik Kundu, Ishita Vohra, Hong Wang, Tushar Krishna

Veröffentlicht 2026-04-20

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Ritik Raj, Souvik Kundu, Ishita Vohra, Hong Wang, Tushar Krishna

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

Das große Missverständnis: Der Chefkoch vs. der Kellner

Stellen Sie sich vor, Sie haben ein hochmodernes Restaurant.

Der KI-Modell (LLM) ist der Genie-Koch in der Küche. Er kann unglaublich schnell und kreativ Gerichte (Antworten) zubereiten.
Die CPU (der Prozessor im Computer) ist der Kellner, der die Bestellungen annimmt, Zutaten besorgt, Tische räumt und mit dem Kunden spricht.

Bis vor kurzem dachten alle, das Restaurant sei nur so schnell wie der Koch. Wenn der Koch langsam ist, ist das Essen langsam. Also haben sie riesige, teure Öfen (GPUs) gekauft, um den Koch noch schneller zu machen.

Aber dieses Papier sagt: "Moment mal! Der Koch ist eigentlich super schnell. Das Problem ist der Kellner!"

Bei neuen KI-Systemen ("Agentic AI") muss der Koch nicht nur kochen, sondern auch Dinge tun wie: "Rufe die Wetter-App ab", "Suche im Internet nach Rezepten" oder "Schreibe einen Code". Diese Aufgaben macht der Kellner (CPU). Und genau hier liegt das Problem: Der Kellner ist überlastet, während der Koch oft nur herumsteht und auf den Kellner wartet.

Was haben die Forscher herausgefunden?

Die Forscher haben zwei verschiedene Restaurants untersucht:

Restaurant A: Ein sehr schneller Koch, aber ein langsamer, müder Kellner.
Restaurant B: Ein sehr schneller Koch und ein sehr schneller, starker Kellner.

Das Ergebnis:
Selbst wenn der Koch (GPU) extrem schnell ist, wartet er oft 80–90 % der Zeit nur darauf, dass der Kellner (CPU) die Zutaten (Daten aus dem Internet oder Dateien) besorgt hat.

Beispiel: Wenn der Koch ein Gericht in 1 Sekunde zubereitet, aber der Kellner 10 Sekunden braucht, um die Tomaten zu holen, dauert das ganze Essen 11 Sekunden. Es bringt nichts, den Koch noch schneller zu machen, wenn der Kellner immer noch langsam ist.

Außerdem haben sie gesehen: Wenn man zu viele Bestellungen gleichzeitig auf einmal gibt (eine große "Batch"), wird der Kellner chaotisch. Er stolpert über sich selbst, weil er versucht, alles gleichzeitig zu erledigen. Das verlangsamt das ganze System, und der teure Koch steht untätig herum.

Die Lösung: Zwei neue Strategien

Um dieses Chaos zu lösen, haben die Forscher zwei neue Methoden entwickelt, wie man die Bestellungen im Restaurant besser organisiert.

1. COMB: "Die kleine, aber regelmäßige Bestellung"

(CPU-Aware Overlapped Micro-Batching)

Das Problem: Wenn der Kellner versucht, 100 Teller gleichzeitig zu tragen, bricht er unter der Last zusammen.
Die Lösung: Statt 100 Teller auf einmal zu tragen, trägt der Kellner nur 64 Teller. Aber er macht das nicht nacheinander, sondern überlappt es.

Sobald der Kellner die ersten 64 Teller zur Küche gebracht hat, geht er sofort los, um die nächsten 64 Teller zu holen, während der Koch bereits mit den ersten 64 Tellen beschäftigt ist.
Der Vorteil: Der Koch (GPU) muss nie warten, und der Kellner (CPU) wird nicht überlastet. Das Essen kommt viel schneller auf den Tisch.

2. MAS: "Die getrennten Wartezonen"

(Mixed Agentic Scheduling)

Das Problem: Manchmal kommen Bestellungen, bei denen der Koch viel arbeiten muss (nur Text schreiben), und manchmal Bestellungen, bei denen der Kellner viel arbeiten muss (Internet-Recherche). Wenn alle in einer einzigen Schlange stehen, blockieren die "Koch-lastigen" Bestellungen die "Kellner-lastigen" und umgekehrt.
Die Lösung: Man baut zwei getrennte Wartezonen.

Zone A: Nur für Bestellungen, die viel Kellner-Arbeit brauchen.
Zone B: Nur für Bestellungen, die viel Koch-Arbeit brauchen.
Eine kleine "Notfall-Zone" sorgt dafür, dass keine Gruppe die andere komplett verdrängt.
Der Vorteil: Selbst wenn plötzlich 90 % der Kunden nur "Koch-Bestellungen" haben, warten die wenigen "Kellner-Bestellungen" nicht ewig. Niemand wird benachteiligt, und das Restaurant läuft fairer und effizienter.

Warum ist das wichtig?

Bisher haben sich alle nur darum gekümmert, den Koch (die KI) schneller und teurer zu machen. Dieses Papier zeigt uns, dass wir oft den Kellner (die CPU) optimieren müssen, um das ganze System schneller zu machen.

Die Ergebnisse:

Durch diese neuen Methoden wurde die Wartezeit für die Hälfte der Kunden (P50) bis zu 1,7-mal kürzer.
In schwierigen Situationen (wenn viele Kunden gleichzeitig kommen) konnte die Wartezeit sogar bis zu 3,9-mal verkürzt werden.
Das ist wie ein Wunder: Man muss nicht unbedingt teureres Equipment kaufen, sondern nur die Organisation im Restaurant verbessern.

Fazit

Die Zukunft der KI liegt nicht nur in noch stärkeren Grafikkarten, sondern darin, wie wir die Zusammenarbeit zwischen dem "Denker" (GPU) und dem "Macher" (CPU) organisieren. Wenn wir dem Kellner helfen, effizienter zu arbeiten, kann der Genie-Koch endlich sein volles Potenzial entfalten.

1. Problemstellung

Agentic AI (Agenten-KI) wandelt monolithische LLM-Inferenz in autonome Problemlöser um, die planen, Werkzeuge aufrufen, reasoning (Schlussfolgern) durchführen und sich anpassen können. Während die Inferenz von Large Language Models (LLMs) traditionell auf GPUs läuft, übernehmen die für die Agentic-Fähigkeiten notwendigen externen Werkzeuge (z. B. Bash-Skripte, Web-Suche, Datenbanken, chemische Simulationen) oft die CPU.

Das Paper identifiziert ein kritisches, bisher übersehenes Problem: Die CPU wird zum systemischen Flaschenhals.

Dominanz der CPU: In vielen Workloads (z. B. RAG mit Exact Nearest Neighbor Search, Code-Generierung) entfallen bis zu 88 % der End-to-End-Latenz auf die CPU-Verarbeitung der Tools.
Ineffiziente Parallelisierung: CPU-Parallelisierungsstrategien (Multi-Threading/Multi-Processing) sind weniger effizient als GPU-Parallelisierung. Sie führen oft zu einer vorzeitigen Sättigung des Durchsatzes, bevor alle CPU-Kerne ausgelastet sind, was wiederum die teuren GPU-Ressourcen unterauslastet.
Heterogenität: Bestehende Scheduler (wie vLLM) sind auf homogene GPU-Inferenz optimiert und berücksichtigen nicht die gemischten Anforderungen von CPU-lastigen (Tool-Aufrufe) und GPU-lastigen (reine Inferenz) Anfragen in einem gemischten Betrieb.

2. Methodik

Die Autoren verfolgen einen zweistufigen Ansatz: Charakterisierung und Optimierung.

A. Charakterisierung (Compile-time & Runtime)

Taxonomie: Es wird eine neue Klassifikation für Agentic AI eingeführt, basierend auf drei orthogonalen Dimensionen:
- Orchestrator: LLM-gesteuert vs. Host-Code (Python) gesteuert.
- Pfad: Statisch (vordefiniert) vs. Dynamisch (laufzeitentscheidend).
- Wiederholbarkeit: Single-Step vs. Multi-Step.
Workload-Auswahl: Fünf repräsentative Workloads wurden ausgewählt (Toolformer, SWE-Agent, RAG/Haystack, ChemCrow, Web-Augmented Agent), um algorithmische Vielfalt und verschiedene Tool-Typen (I/O, Compute, File-I/O) abzudecken.
Hardware-Setup: Experimente wurden auf zwei Systemen durchgeführt, um Architekturbottlenecks zu isolieren:
- Sys 1: High-Performance (HP) CPU (Intel 64-Core) + Low-Performance (LP) GPU (RTX-Pro 6000).
- Sys 2: HP CPU (Nvidia Grace 72-Core) + HP GPU (H200).
Analyse: Messung von End-to-End-Latenz, Durchsatz (Throughput) und Energieverbrauch. Es wurde festgestellt, dass bei leistungsstarken GPUs der Flaschenhals schnell von der GPU zur CPU wandert.

B. Optimierungsvorschläge

Basierend auf den Erkenntnissen zur Durchsatzsättigung wurden zwei Scheduling-Optimierungen entwickelt:

COMB (CPU-Aware Overlapped Micro-Batching):
- Ziel: Optimierung für homogene Workloads (gleicher Typ).
- Mechanismus: Statt großer Batches, die die CPU überlasten, werden eingehende Anfragen in kleine „Micro-Batches" (bis zu einer Kapazitätsgrenze $B_{cap}$ ) unterteilt.
- Überlappung: Die CPU-Verarbeitung eines Micro-Batches wird mit der GPU-Inferenz des nächsten Micro-Batches überlappt (Pipeline).
- Effekt: Vermeidet CPU-Over-Subscription, hält die GPU ausgelastet und verbessert die Latenzverteilung.
MAS (Mixed Agentic Scheduling):
- Ziel: Optimierung für heterogene Workloads (Mix aus CPU-lastigen und GPU-lastigen Anfragen).
- Mechanismus: Einführung getrennter Warteschlangen und Kapazitätsgrenzen ( $E_{cap,CPU}$ und $E_{cap,GPU}$ ) für die beiden Anfrage-Typen.
- Fairness: Verhindert, dass eine dominante Anfrageart (z. B. reine GPU-Inferenz) die Ressourcen monopolisiert und die andere Art (CPU-lastig) in die Warteschlange drängt. Eine gemeinsame Reserve-Warteschlange sorgt für Elastizität.

3. Wichtige Ergebnisse

Charakterisierungsergebnisse

CPU-Bottleneck: Tool-Verarbeitung auf der CPU kann bis zu 88 % der Gesamtlatenz ausmachen.
Hardware-Paradoxon: Ein System mit einer schwächeren GPU kann bei tool-dominierten Workloads eine ähnliche End-to-End-Latenz erreichen wie ein System mit einer sehr starken GPU, da die CPU der limitierende Faktor bleibt.
Parallelisierung: CPU-Multi-Processing ist ineffizienter als GPU-Parallelisierung und führt bei Batch-Größen > 64–128 zu einer Sättigung des Durchsatzes, während die GPU-Ressourcen ungenutzt bleiben.

Leistungsverbesserungen (Evaluation)

COMB (Homogene Workloads):
- Reduzierung der P50-Latenz um bis zu 1,7× bei eigenständiger Ausführung.
- Unter Open-Loop-Last (simulierter Server-Betrieb): Bis zu 3,9× niedrigere Service-Latenz und 1,8× niedrigere Gesamtlatenz.
- Durchsatzsteigerung um 1,7×.
MAS (Heterogene Workloads):
- Schützt Minderheiten-Anfrage-Typen (z. B. wenn nur 25 % der Anfragen CPU-lastig sind).
- Reduzierung der Gesamtlatenz für die Minderheit um bis zu 2,37× (P50) und 2,49× (P90) im Vergleich zu einem First-Come-First-Served (FCFS) Ansatz.
- Verhindert die Verdrängung kleinerer Anfrage-Typen durch dominante Ströme.
Energieprofilierung:
- Bei CPU-zentrischen Workloads (z. B. RAG) entfallen bis zu 61 % der dynamischen Systemenergie auf die CPU. Dies unterstreicht die Notwendigkeit von CPU-Optimierungen für Energieeffizienz in Rechenzentren.

4. Signifikanz und Beitrag

Dieses Paper leistet einen bahnbrechenden Beitrag zur Systemarchitektur von Agentic AI:

Paradigmenwechsel: Es verschiebt den Fokus von der reinen GPU-Optimierung (KV-Cache, Kernel-Optimierung) hin zu einer CPU-zentrischen Perspektive, die für reale Agenten-Anwendungen entscheidend ist.
Erste umfassende Analyse: Es ist die erste Arbeit, die End-to-End-Latenz, Durchsatz und Energieverbrauch von Agentic AI in heterogenen CPU-GPU-Systemen quantitativ analysiert.
Praktische Lösungen: Die vorgestellten Algorithmen (COMB und MAS) sind direkt in bestehende Serving-Systeme integrierbar und lösen reale Probleme wie Ressourcen-Verdrängung und vorzeitige Durchsatzsättigung.
Design-Prinzip: Das Paper etabliert die „optimale gleichzeitige CPU-GPU-Nutzung" als neues Schlüssel-Designprinzip für die nächste Generation von KI-Serving-Systemen.

Zusammenfassend zeigt die Arbeit, dass die Effizienz von Agentic AI nicht durch schnellere GPUs allein, sondern durch intelligentes Scheduling und die Vermeidung von CPU-Engpässen erreicht werden kann.