🤖 AI

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

Dit paper introduceert Eager, een systeem dat de latentie bij LLM-codegeneratie aanzienlijk vermindert door code direct tijdens het genereren uit te voeren in plaats van te wachten op voltooiing, wat leidt tot een tot 55% snellere eind-tot-eind-latentie.

Oorspronkelijke auteurs: Zhensu Sun, Zhihao Lin, Zhi Chen, Chengran Yang, Mingyi Zhou, Li Li, David Lo

Gepubliceerd 2026-04-02

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Zhensu Sun, Zhihao Lin, Zhi Chen, Chengran Yang, Mingyi Zhou, Li Li, David Lo

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Titel: "Eager": De Kunst van het Koken terwijl je nog aan het Recept schrijft

Stel je voor dat je een kok bent die een heel complex recept moet schrijven en tegelijkertijd het gerecht moet bereiden.

De Oude Manier (De "Seriele" Methode):
Vandaag de dag werken AI-programma's (zoals chatbots die code schrijven) net als een kok die eerst het hele recept op een vel papier schrijft. Pas als het laatste woord op papier staat, loopt de kok naar de keuken, pakt de ingrediënten en begint te koken.

Het probleem: Terwijl de kok schrijft, staat de keuken leeg en doet er niets. En terwijl de kok kookt, staat hij stil en schrijft hij niets. Het is een lange, saaie wachttijd voor de klant.

De Nieuwe Manier (De "Eager" Methode):
De onderzoekers van dit paper hebben een slimme nieuwe manier bedacht, genaamd Eager. Stel je voor dat deze kok niet wacht tot het hele recept klaar is. In plaats daarvan:

Hij schrijft de eerste zin van het recept ("Neem een ei").
Direct roept hij de keuken op om dat ei te breken en te kloppen.
Terwijl de keuken het ei klopt, schrijft de kok de volgende zin ("Voeg melk toe").
Direct roept hij de keuken op om de melk toe te voegen.

De kok (het schrijven) en de keuken (het uitvoeren) werken tegelijkertijd. De klant hoeft niet te wachten tot het hele recept klaar is om te zien of het gerecht lukt.

Waarom is dit zo slim? (De Analogieën)

1. Het "Verborgen" Wachtgedeelte
In de oude manier is de totale tijd = Schrijftijd + Kooktijd.
Bij Eager is de totale tijd bijna gelijk aan alleen de Schrijftijd, omdat de Kooktijd zich "versteekt" achter het schrijven. Het is alsof je een treinreis maakt: in plaats van eerst te wachten tot de trein helemaal is aangekomen en dan pas in te stappen, stap je in terwijl de trein nog langzaam binnenrijdt. Je bent al onderweg terwijl de trein nog wordt opgestart.

2. De "Stopknop" bij Fouten
Stel je voor dat je een ei breekt en het blijkt rot te zijn.

Oude manier: De kok schrijft het hele recept af (inclusief "bak het ei in de pan"), loopt naar de keuken, breekt het ei, merkt dat het rot is, en zegt: "Oeps, het hele recept was verkeerd." De klant heeft lang gewacht voor niets.
Eager: De kok schrijft "Breek een ei", de keuken breekt het, en roept direct: "Dit ei is rot!" De kok stopt direct met schrijven. Hij hoeft geen zin te verspillen aan het beschrijven van hoe je een rot ei in de pan moet bakken. Dit bespaart enorm veel tijd.

3. Beter Herstellen van Fouten
Interessant genoeg helpt deze snelle stop ook bij het oplossen van fouten. Als de AI halverwege stopt bij een fout, heeft hij geen "verkeerde" zinnen meer geschreven die de rest van het recept verpesten. De AI kan zich dan beter focussen op het corrigeren van het ei, in plaats van proberen een heel compleet (maar foutief) recept te redden. Het is alsof je een fout in een zin direct corrigeert, in plaats van de hele paragraaf te herschrijven omdat je halverwege een fout zag.

Wat hebben ze bewezen?

De onderzoekers hebben dit getest met verschillende "koks" (AI-modellen) en in verschillende "keukens" (computersystemen).

Snelheid: Ze hebben laten zien dat de totale wachttijd voor de gebruiker met wel 55% kan dalen.
Betrouwbaarheid: Het systeem werkt perfect; de stukjes code die worden uitgevoerd, zijn exact hetzelfde als de code die de AI had geschreven als hij had gewacht.
Fouten: Het helpt de AI om sneller fouten te vinden en te repareren, omdat hij niet vastloopt in een lange, foutieve keten van instructies.

Conclusie

Dit paper introduceert Eager, een slimme manier om AI-code te laten werken. In plaats van "eerst schrijven, dan doen", doen ze het terwijl je schrijft.

Het is als het verschil tussen een film kijken waarbij je eerst de hele film moet downloaden voordat je hem kunt afspelen, versus streaming: je begint te kijken terwijl de rest nog wordt geladen. Voor de gebruiker voelt het alsof de AI veel sneller en slimmer is, terwijl de computer eigenlijk gewoon efficiënter werkt door twee taken tegelijk te doen.

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

Auteurs: Zhensu Sun, Zhihao Lin, Zhi Chen, Chengran Yang, Mingyi Zhou, Li Li, David Lo (Singapore Management University & Beihang University)

1. Het Probleem: Serialiteit en Latentie

Huidige LLM-gebaseerde coderingsagenten volgen een seriële uitvoeringsparadigma:

Het model genereert de volledige code.
De generator stopt en wacht.
Een interpreter voert de code uit.
Het resultaat wordt teruggevoerd (indien nodig voor herstel).

Deze aanpak leidt tot onnodige end-to-end latentie (totale wachttijd voor de gebruiker). Tijdens het genereren is de uitvoerder (executor) inactief, en tijdens het uitvoeren is de generator inactief. In tegenstelling tot menselijke ontwikkelaars, die code vaak herschrijven en reviseren, genereren LLMs tokens sequentieel zonder revisie. Dit betekent dat de code, zodra een token is gegenereerd, "vaststaat" en potentieel direct uitgevoerd kan worden, in plaats van te wachten tot het volledige blok compleet is.

2. Methodologie: Het Parallelle Uitvoeringsparadigma

De auteurs introduceren een nieuw paradigma: Parallelle Uitvoering. Hierbij wordt code direct naar de interpreter gestuurd zodra een uitvoerbaar stukje (chunk) is gegenereerd, waardoor generatie en uitvoering in de tijd overlappen.

Het Eager Framework

De auteurs presenteren Eager (Executing As you GEneRate), een implementatie van dit paradigma voor Python (en in theorie andere geïnterpreteerde talen). De architectuur bestaat uit drie hoofdstadia:

Generatie (Producer): De LLM stuurt een tokenstream.
Detectie (Chunking): Een module analyseert de tokenstream in real-time.
- AST-based Chunking: De chunker parseert de stream naar een Abstract Syntax Tree (AST) om te bepalen wanneer een volledige, syntactisch correcte Python-statement (bijv. een toewijzing, lus of functieaanroep) compleet is.
- Lookahead: Om ambiguïteit te voorkomen (bijv. bij een functie-definitie die nog niet compleet is), wacht de chunker soms op één extra token voordat hij de chunk als compleet beschouwt.
Uitvoering (Consumer): De gevonden chunks worden in een wachtrij geplaatst en uitgevoerd binnen een persistente sessie (bijv. een Python REPL of Docker-container) om variabele bindingen te behouden.
- Dynamic Batching: Als meerdere chunks in de wachtrij staan, worden deze samengevoegd tot één batch om de overhead van het opstarten van uitvoering per chunk te verminderen.
- Gated Execution: Chunks die alleen declaraties bevatten (zoals def of class) en geen directe berekening vereisen, worden uitgesteld (gegate) en samengevoegd met de volgende uitvoerbare chunk om onnodige overhead te voorkomen.
- Early Error Interruption: Als een chunk een runtime-fout veroorzaakt, wordt de generatie van de LLM onmiddellijk gestopt. De foutmelding en de tot dat punt gegenereerde code worden teruggegeven. Dit voorkomt dat de LLM tijd verspilt aan het genereren van code die afhankelijk is van een gefaalde staat.

Theoretische Modellering

De auteurs modelleren het systeem als een drie-traps pijplijn (Generatie, Detectie, Uitvoering) en leiden gesloten-vorm formules af voor de latentie.

Seriële Latentie: $T_{serial} = T_{gen} + T_{exec}$
Parallelle Latentie: $T_{parallel} \approx T_{gen} + T_{tail}$ (waarbij $T_{tail}$ de uitvoeringstijd van de laatste chunk is).
Regimes: De snelheidswinst hangt af van de verhouding tussen generatiesnelheid en uitvoeringstijd. In het "generatie-gedomineerde regime" (langzame generatie, snelle uitvoering) is de winst maximaal omdat bijna alle uitvoeringstijd wordt "verborgen" achter de generatietijd.

3. Belangrijkste Bijdragen

Formalisatie: Het definiëren van het parallelle uitvoeringsparadigma voor LLM-code, inclusief theoretische grenzen voor latentie en snelheidswinst.
Implementatie (Eager): Een werkend framework met AST-based chunking, dynamische batching en vroegtijdige foutinteruptie.
Empirische Validatie: Een uitgebreide evaluatie over vier benchmarks, zeven LLMs en drie uitvoeringsomgevingen (lokaal, Docker, Open Interpreter).

4. Resultaten

De evaluatie toont aanzienlijke verbeteringen in zowel latentie als codeherstel:

Latentievermindering:
- Non-overlapped Execution Latency (NEL): Eager vermindert de uitvoeringstijd die niet overlapt met generatie met 83% tot 100%. In veel gevallen is de uitvoering volledig verborgen achter de generatie.
- End-to-End Latency (E2EL): De totale wachttijd voor de gebruiker wordt met tot 55% verkort.
  - Bij foutloze uitvoeringen: tot 37% reductie.
  - Bij uitvoeringen met fouten: tot 55% reductie (voornamelijk door de early interruption).
- De resultaten zijn consistent over verschillende generatiesnelheden (20-200 tokens/sec) en omgevingen.
Invloed op Codeherstel (RQ3):
- Verrassend genoeg leidt het stoppen van de generatie bij een fout (in plaats van wachten tot de volledige code is gegenereerd) tot beter herstel.
- Op data-centric benchmarks (zoals DABench en DSBench) stijgt het succespercentage van foutoplossing met 2,1 tot 44,3 procentpunten wanneer de LLM werkt met de gedeeltelijke code (met de foutmelding) in plaats van de volledige, gefaalde code.
- Reden: Bij volledige code is de LLM "geankerd" in de foutieve logica die na de fout is gegenereerd. Bij gedeeltelijke code heeft het model meer vrijheid om een nieuwe oplossing te bedenken vanaf het punt van falen.

5. Betekenis en Toekomstperspectief

Systeemontwerp: Dit werk toont aan dat de traditionele "schrijf-then-voer uit"-paradigma niet optimaal is voor LLM's. Door de uitvoering te versnellen en te overlappen, kan de gebruikerservaring aanzienlijk worden verbeterd.
Programmeertalen: Het paper suggereert dat programmeertalen in de toekomst mogelijk moeten worden ontworpen met "streamability" als eerste-class doel (bijv. expliciete statement-delimiteurs) om incrementele uitvoering makkelijker te maken.
Agent Frameworks: Bestaande agent-frameworks die code eerst naar een bestand schrijven voordat uitvoering begint, missen deze potentie. Het paper adviseert om interfaces aan te passen die incrementele code-ontvangst toestaan.
Toepassingsgebied: De methode werkt het beste bij LLM-taken waar de uitvoeringstijd kort is (milliseconden) ten opzichte van de generatietijd (seconden), wat typisch is voor data-analyse en API-interacties.

Conclusie: "Executing as You Generate" is een krachtige techniek die de latentie van LLM-codering drastisch verlaagt en tegelijkertijd de kwaliteit van foutoplossing verbetert door vroegtijdige feedback, zonder de gegenereerde code zelf te hoeven veranderen.