Executing as You Generate: Hiding Execution Latency in LLM Code Generation

1. Problemstellung

Aktuelle LLM-basierte Coding-Agenten folgen einem seriellen Ausführungsparadigma: Das Modell generiert zunächst den vollständigen Code-Block, bevor ein Interpreter diesen ausführt. Dieser sequenzielle Workflow führt zu unnötiger Gesamtlatenz, da der Executor während der Generierung und der Generator während der Ausführung untätig (idle) bleibt.

Im Gegensatz zu menschlichen Entwicklern, die Code oft nicht-linear schreiben und überarbeiten, generieren moderne tokenbasierte Sprachmodelle Token sequenziell ohne nachträgliche Änderungen. Das Paper identifiziert die Lücke, dass diese Eigenschaft bisher nicht genutzt wurde, um Code während der Generierung auszuführen. Bisherige Ansätze (z. B. Open Interpreter, EG-CFG) nutzen zwar Ausführungsrückmeldungen zur Qualitätsverbesserung, bleiben aber latenztechnisch seriell, da das Modell auf das Ergebnis jeder Ausführung warten muss, bevor es weiter generiert.

2. Methodik und Architektur (Eager)

Die Autoren stellen Eager (Executing As you GEneRate) vor, ein Framework, das ein paralleles Ausführungsparadigma implementiert. Das System modelliert den Prozess als eine Pipeline aus drei Stufen: Generierung, Detektion und Ausführung.

Kernkomponenten von Eager:

• AST-basiertes Chunking (Produzent): Ein Chunker verarbeitet den Token-Stream des LLMs in Echtzeit. Er nutzt die AST-Parsing-Struktur (Abstract Syntax Tree) von Python, um vollständige, ausführbare Anweisungen (Chunks) zu identifizieren. Um syntaktische Mehrdeutigkeiten zu lösen (z. B. bei unvollständigen Funktionsdefinitionen), wird eine Lookahead-Strategie eingesetzt, die auf ein zusätzliches Token wartet, bevor ein Chunk als abgeschlossen gilt.
• Dynamisches Batching mit Gating (Konsumeur): Ein Executor entnimmt die Chunks aus einer Warteschlange. Anstatt jeden Chunk sofort einzeln auszuführen, werden mehrere Chunks zu einem Batch zusammengefasst, um den Overhead pro Aufruf (Setup-Kosten) zu amortisieren. Zudem werden Chunks, die nur Deklarationen enthalten und keine messbare Rechenzeit benötigen (z. B. Funktionsdefinitionen), zurückgestellt (gated), bis sie für nachfolgenden Code benötigt werden.
• Persistente Sitzung: Die Ausführung erfolgt in einer persistenten Interpreter-Sitzung (z. B. lokaler Prozess, Docker-Container oder Jupyter-Kernel), um Variablenbindungen und Importe über die Chunk-Grenzen hinweg beizubehalten.
• Frühe Fehlerunterbrechung (Early Error Interruption): Da Chunks sofort ausgeführt werden, wird ein Laufzeitfehler sofort erkannt. Eager unterbricht die Generierung des LLMs sofort und gibt den Fehler zusammen mit dem bis dahin generierten Code zurück. Dies verhindert, dass Zeit mit der Generierung von Code verschwendet wird, der auf einem bereits fehlgeschlagenen Zustand aufbaut.

Theoretische Modellierung:
Das Paper leitet geschlossene Formeln für die Latenz her. Es zeigt, dass die Gesamtlatenz im parallelen Modus durch die kritische Pfadlänge bestimmt wird. Unter idealen Bedingungen (wenn die Generierungszeit die Ausführungszeit dominiert) reduziert sich die Gesamtzeit von $T_{gen} + T_{exec}$ auf ca. $T_{gen} + T_{tail}$ (Ausführungszeit des letzten Chunks).

3. Wichtige Beiträge

1. Formalisierung des parallelen Paradigmas: Theoretische Analyse der Latenzgrenzen, Geschwindigkeitspotenziale und Betriebsregime (generierungsdominiert vs. ausführungdominiert).
2. Implementierung von Eager: Ein konkretes System mit AST-basiertem Chunking, dynamischem Batching und einer Mechanik zur sofortigen Fehlerunterbrechung.
3. Umfassende Evaluation: Evaluation über vier Benchmarks, sieben verschiedene LLMs (Open-Weight und proprietär) und drei Ausführungsumgebungen (lokal, Docker, Open Interpreter).

4. Ergebnisse

Die Evaluation ergab signifikante Verbesserungen gegenüber der seriellen Ausführung:

• Versteckte Ausführungszeit: Eager kann 83 % bis 100 % der Ausführungszeit hinter der Generierungszeit verstecken (gemessen als Non-overlapped Execution Latency - NEL).
• End-to-End Latenz (E2EL):
  • Bei fehlerfreier Ausführung wurde die Gesamtlatenz um bis zu 37 % reduziert.
  • Bei fehlerbehafteter Ausführung (durch die frühe Unterbrechung) sank die Latenz um bis zu 55 %, da die Generierung sofort gestoppt wurde, sobald ein Fehler auftrat.
• Verbesserung der Code-Reparatur: Ein unerwarteter positiver Effekt der frühen Unterbrechung ist die Steigerung der Erfolgsrate bei der Fehlerbehebung. Wenn das Modell nur den fehlerhaften Code-Teil sieht (statt des kompletten, fehlerhaften Programms), kann es die Lösung effektiver korrigieren. Auf datenzentrischen Benchmarks stieg die Reparaturrate um bis zu 44 Prozentpunkte im Vergleich zur Reparatur basierend auf dem vollständigen Code.
• Robustheit: Die Ergebnisse waren über verschiedene LLMs, Geschwindigkeiten (20–200 Tokens/Sekunde) und Umgebungen hinweg konsistent.

5. Bedeutung und Implikationen

• Systemdesign: Das Paper zeigt, dass die Trennung von Generierung und Ausführung in LLM-Agenten unnötig ist und durch eine Streaming-Architektur ersetzt werden kann, um die wahrgenommene Latenz drastisch zu senken.
• Programmiersprachen-Design: Es wird argumentiert, dass zukünftige Programmiersprachen (oder zumindest deren Interpreter) „Streamability" als First-Class-Feature betrachten sollten, um die Komplexität der Chunk-Erkennung zu reduzieren.
• Agenten-Frameworks: Bestehende Agenten-Frameworks, die Code erst in Dateien schreiben und dann ausführen, sollten ihre Schnittstellen überarbeiten, um inkrementelle Code-Verarbeitung zu unterstützen.
• Skalierbarkeit: Der Ansatz funktioniert besonders gut bei generierungsdominierten Workloads (typisch für LLMs), bei denen die Generierung langsamer ist als die Ausführung von Skripten.

Zusammenfassend beweist das Paper, dass die parallele Ausführung von generiertem Code nicht nur technisch machbar, sondern auch ein effektiver Weg ist, um Latenz zu minimieren und die Qualität der Code-Reparatur durch frühes Feedback zu verbessern.