🤖 AI

Parallel Context Compaction for Long-Horizon LLM Agent Serving

Dit artikel introduceert **parallelle contextcompactering**, een methode die verliesgevoelige en onvoorspelbare sequentiële samenvatting vervangt door een geparaaliseerde aanpak om fijnmazige controle over het samenvattingsvolume te bieden, terwijl tegelijkertijd de wandeltijd aanzienlijk wordt verkort en de doorvoer voor LLM-agenten met lange horizon wordt verbeterd.

Oorspronkelijke auteurs: Musa Cim, Burak Topcu, Chita Das, Mahmut Taylan Kandemir

Gepubliceerd 2026-05-25

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Musa Cim, Burak Topcu, Chita Das, Mahmut Taylan Kandemir

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

Stel je voor dat je een briljante detective bent (de AI-agent) die een enorm, meerdelig mysterie oplost. Elke keer als je een vraag stelt of een aanwijzing krijgt, schrijf je dit op in een gigantisch notitieboek. Naarmate de zaak vordert, wordt het notitieboek dikker en dikker.

Uiteindelijk wordt het notitieboek zo groot dat:

Het te zwaar is om te dragen: De detective raakt uitgeput door alleen al het begin van het boek te lezen voordat hij bij de nieuwe aanwijzingen komt (dit heet "contextrot").
Het niet in de aktetas past: Het notitieboek is groter dan de groottegrens van de aktetas die de detective mag gebruiken (het "contextvenster").

Om dit op te lossen, stopt de detective meestal en vraagt hij een schrijver (de LLM) het hele notitieboek samen te vatten tot een klein, één pagina tellend spiekbriefje. Maar het document dat je hebt aangeleverd, wijst drie grote problemen aan met deze traditionele methode en biedt vervolgens een slimme nieuwe oplossing genaamd Parallelle Compactering.

Hier is de uitleg in eenvoudige bewoordingen:

Het Probleem: De "Eén-maat-past-voor-iedereen" Samenvatting

De auteurs ontdekten dat de traditionele manier van samenvatten op drie specifieke manieren kapot is:

De "Black Box" van Lengte: Je kunt de schrijver misschien zeggen: "Maak deze samenvatting super gedetailleerd!" of "Maak het super kort!" Maar de schrijver negeert je. Ongeacht hoe lang het originele notitieboek is (2 pagina's of 200 pagina's), schrijft de schrijver altijd een samenvatting die ongeveer even groot is (ongeveer een halve pagina). Ze hebben een "mentale regel" uit hun training die zegt: "Een samenvatting is altijd zo lang", en ze veranderen dit niet.
De "Wachttijd"-Bottleneck: Omdat de schrijver het hele gigantische notitieboek moet lezen voordat hij één woord schrijft, moet de detective stilstaan en wachten. In een snelle opsporing loopt deze wachttijd op tot minuten of zelfs uren verloren productiviteit.
De "Gok met een dobbelsteen"-Instabiliteit: Als je de schrijver vraagt om hetzelfde notitieboek twee keer samen te vatten, kan het zijn dat je twee volledig verschillende samenvattingen krijgt. De ene keer houden ze de aanwijzing over de rode auto; de volgende keer vergeten ze die en houden ze de aanwijzing over de blauwe hoed. Dit maakt de prestaties van de detective onvoorspelbaar.

De Oplossing: De "Assemblagelijn" (Parallelle Compactering)

In plaats van één schrijver te vragen het hele boek te lezen en één samenvatting te schrijven, suggereren de auteurs een team van schrijvers in te huren en het werk te verdelen.

Stel je voor dat het gigantische notitieboek een lange trein is.

Oude manier: Iemand loopt de hele lengte van de trein af, leest elke wagon en schrijft één rapport.
Nieuwe manier (Parallelle Compactering): Je snijdt de trein in kleinere, gelijkmatige wagons (blokken). Je geeft één wagon aan Schrijver A, de volgende aan Schrijver B, en zo verder.

Hier is de slimme twist:
Wanneer Schrijver A zijn wagon samenvat, krijgt hij ook de vorige wagons (de geschiedenis) te zien, zodat hij de context begrijpt. Schrijver B ziet wagons 1 en 2, Schrijver C ziet wagons 1, 2 en 3, en zo verder. Ze werken allemaal tegelijk (parallel).

Waarom Dit Beter Werkt

Het document beweert dat deze "Assemblagelijn"-aanpak de drie bovenstaande problemen oplost:

Totale Controle (Het Volumeknopje): Omdat jij bepaalt in hoeveel wagons (blokken) je de trein snijdt, beheers je de uiteindelijke grootte. Als je een enorme samenvatting wilt, gebruik je kleine blokken (meer schrijvers, meer details). Als je een kleine samenvatting wilt, gebruik je grote blokken (minder schrijvers, minder details). Je hoeft de AI niet te smeken om instructies op te volgen; je verandert gewoon het aantal werknemers.
Snelheid (De File): Omdat alle schrijvers tegelijk werken, is de totale tijd om de samenvatting te voltooien veel korter. Het is alsof je 10 mensen hebt die tegelijk een auto wassen in plaats van één persoon die het alleen doet.
Stabiliteit (Het Consistente Recept): Omdat elke schrijver alleen verantwoordelijk is voor een klein, gefocust stukje van het verhaal, is de kans kleiner dat ze in de war raken of dingen vergeten. De samenvatting wordt veel consistenter, run na run.

De Conclusie

Het document toont aan dat je voor lange, complexe AI-taken niet moet vertrouwen op één AI om een enorme geschiedenis samen te vatten. In plaats daarvan moet je die geschiedenis in kleine stukjes hakken, ze allemaal tegelijk samenvatten met een slimme lay-out die de context verbonden houdt, en de resultaten aan elkaar naaien.

Dit geeft de operator (de mens die de leiding heeft) een nauwkeurig "volumeknopje" om precies te beslissen hoeveel informatie bewaard moet worden, terwijl het hele proces sneller en betrouwbaarder wordt.

Technische Samenvatting: Parallelle Contextcompactering voor het Serveren van LLM-agenten met Lange Horizont

1. Probleemstelling

LLM-agenten (Large Language Model) met een lange horizont opereren in sessies waarbij conversatiegeschiedenissen continu groeien, wat uiteindelijk leidt tot het overschrijden van de contextvensters van het model. Hoewel contextcompactering via samenvattingen gegenereerd door een LLM de standaardoplossing is, identificeren de auteurs drie kritieke beperkingen in de huidige sequentiële synchrone aanpak:

Verliesrijke en Onvoorspelbare Output: Samenvatting is inherent verliesrijk. Cruciaal is dat het volume van de samenvatting grotendeels invariant is ten opzichte van de invoerlengte en promptinstructies. Naarmate de invoercontext groeit van 2k naar 96k tokens, begrenst het model zijn output zelf, waarbij slechts een tiny fractie van de oorspronkelijke informatie behouden blijft (een daling van ongeveer 48% naar ongeveer 3% van de tokens).
Instabiliteit tussen Runs: Zelfs met identieke invoer en prompts fluctueren de lengte en semantische inhoud van samenvattingen aanzienlijk tussen verschillende runs. Deze instabiliteit maakt het gedrag van agenten niet-reproduceerbaar en bemoeilijkt het budgetteren van het geheugen.
Latentie-bottlenecks: Sequentiële compactering vereist een blokkerende aanroep die de inferentie van de agent stopt. In flows met een lange horizont kan deze overhead tot 62% van de totale end-to-end (E2E) wandtijd in beslag nemen, vooral wanneer compactering frequent wordt geactiveerd bij lagere drempels.

Bovendien merkt het artikel op dat prompt-engineering (bijvoorbeeld vragen om "beknopte" versus "gedetailleerde" samenvattingen) geen fijnmazige controle over het samenvattingsvolume biedt, omdat modellen de neiging hebben terug te vallen op geïnternaliseerde priors over de lengte van samenvattingen die zijn afgeleid van trainingsdata.

2. Methodologie

Experimentele Opstelling

De auteurs evalueerden hun aanpak over vier backbones die verschillende schalen en architecturen bestrijken:

Llama-3.1-8B (Klein, Dicht)
gpt-oss-20B (Middelgroot, MoE, Redenering)
Llama-3.3-70B (Groot, Dicht)
gpt-oss-120B (Groot, MoE, Redenering)

De evaluatie werd uitgevoerd op twee benchmarks:

HotpotQA: Multi-hop vragen beantwoorden over geaccumuleerd bewijs.
LoCoMo: Lange-context multi-sessie dialoog met meerdere vragen en antwoorden per sessie.

Voorgestelde Oplossing: Parallelle Compactering

Het artikel introduceert Parallelle Compactering, een op blokken gebaseerd ontwerp dat de enkele blokkerende samenvattingsaanroep vervangt door gelijktijdige verwerking. De workflow bestaat uit drie fasen:

Snapshot & Partitionering: De conversatiegeschiedenis wordt gekopieerd en opgedeeld in $N$ aaneengesloten blokken van grootte $B$ tokens.
Dispatch: Elk blok $k$ $k$ wordt verwerkt door een aparte worker. Cruciaal is dat de prompt voor worker $k$ $k$ de volledige conversatiegeschiedenis tot aan blok $k$ bevat, waarbij blok $k$ $k$ zelf is ingekapseld in een <TARGET_BLOCK>-marker.
- Prefix-bewuste Target-at-End-indeling: Dit ontwerp zorgt ervoor dat elke worker de causale geschiedenis voorafgaand aan zijn doelblok ziet (wat de context tussen blokken behoudt), terwijl het doelblok zich aan het einde van de prompt bevindt waar de aandacht het sterkst is. Deze indeling maakt ook prefix-cachehergebruik mogelijk tussen workers in de vLLM-server.
Samenvoegen: Zodra alle workers klaar zijn, worden de $N$ per-blok samenvattingen samengevoegd om de gecompacterde geschiedenis te vormen.

3. Belangrijkste Bijdragen en Karakterisering

Karakterisering van Sequentiële Compactering

De auteurs hebben empirisch aangetoond dat sequentiële compactering lijdt aan:

Invoer/Prompt-invariantie: Het aantal output-tokens blijft bijna vlak (groeit slechts ongeveer 3x) ondanks een toename van de invoerlengte met 48x. Promptinstructies met betrekking tot lengte hebben een verwaarloosbaar effect.
Instabiliteit: Naarmate de contextlengte toeneemt, nemen de Variatiecoëfficiënt (CV) in outputlengte en de daling in cosinusgelijkenis (semantische consistentie) toe, waardoor uitkomsten onvoorspelbaar worden.
Optimale Bloksgrootte: Analyse toonde aan dat 4k tokens de meest stabiele invoergrootte is voor samenvatting, wat de beste afweging biedt tussen contextbehoud en outputconsistentie.

Karakterisering van Parallelle Compactering

Parallelle compactering adresseert de beperkingen van de sequentiële baseline door middel van:

Fijnmazige Controle: De operator krijgt directe controle over het samenvattingsvolume via bloksgrootte ( $B$ ). Kleinere blokken resulteren in meer parallelle workers en een hoger totaal aantal output-tokens, waardoor meer context wordt behouden.
Herstelde Promptgevoeligheid: In tegenstelling tot de sequentiële baseline, staat parallelle compactering toe dat promptinstructies (bijvoorbeeld "zeer gedetailleerd") het outputvolume effectief afstemmen binnen elk blok, waardoor een besturingmechanisme met twee assen ontstaat (bloksgrootte + promptdetail).
Verbeteringen in Doorvoer: Door de werklast te paralleliseren en gebruik te maken van prefix-caching, bereikt het systeem een hogere compacteringsdoorvoer.

4. Resultaten

Nauwkeurigheid en Informatiebehoud

Toename in Nauwkeurigheid: Zowel op HotpotQA als LoCoMo leidde het verkleinen van de bloksgrootte (verhogen van parallelisme) tot een monotoon toename in de nauwkeurigheid van downstream QA. De bloksgrootte van 16k (minst workers) produceerde de minste tokens en de laagste nauwkeurigheid, terwijl kleinere blokken (bijvoorbeeld 2k) meer context behielden en de nauwkeurigheid verbeterden.
Behoud van Context: Parallelle compactering stelt het systeem in staat om een aanzienlijk hoger percentage van de oorspronkelijke context te behouden (tot ongeveer 50% met kleine blokken en gedetailleerde prompts) in vergelijking met de sequentiële baseline (~3%).

Systeemprestaties (Wandtijd en Doorvoer)

End-to-End Snelheidswinst: Parallelle compactering verkortte de E2E-wandtijd in de meeste configuraties. Bijvoorbeeld, op het 120B-model met HotpotQA behaalde parallelle compactering (blokken van 2k) een snelheidswinst van 1,28x ten opzichte van sequentieel.
Doorvoer: Bij gelijkgestelde decode-volumes voor compactering presteerde parallelle compactering consequent beter dan de sequentiële baseline. Bijvoorbeeld, het 70B-model toonde een verbetering in doorvoer van 2,13x bij gelijkgestelde tokenaantallen.
Prefill-overhead: Het artikel merkt op dat zeer grote bloksgroottes (bijvoorbeeld 16k) kunnen lijden aan prefill-overhead omdat het unieke deel van de prompt per worker groot en niet-gecacheerd is, wat sommige winsten in parallelisme tenietdoet. Kleinere blokken (2k–4k) optimaliseren deze balans.

5. Betekenis en Claims

Het artikel beweert dat Parallelle Compactering een praktische, infrastructuur-onafhankelijke oplossing biedt voor het serveren van agenten met een lange horizont, zonder dat offline training, ophaalinfrastructuur of toegang tot witte-doosmodellen vereist zijn.

Voorspelbaarheid: Het transformeert contextcompactering van een onvoorspelbaar, verliesrijk proces in een instelbaar systeem waarbij operators de afweging tussen contextbehoud en samenvattingsvolume precies kunnen regelen via het aantal blokken en prompt-engineering.
Efficiëntie: Het mitigeert de latentie-bottleneck van synchrone compactering, waardoor een hogere doorvoer en snellere inferentiecycli voor agenten mogelijk worden.
Stabiliteit: Door te opereren op kleinere, stabiele blokken van 4k, vermindert het de variatie tussen runs die inherent is aan het samenvatten van enorme contexten, wat leidt tot meer reproduceerbaar gedrag van agenten.

De auteurs concluderen dat het optimale operationele punt niet noodzakelijk het maximale behoud van context is, maar de "minimale voldoende" set van hoog-signaal tokens die vereist is voor de taak; een doelwit dat parallelle compactering operators toelaat met precisie te raken.