🤖 AI

A Policy-Driven Runtime Layer for Agentic LLM Serving

Dit artikel stelt een nieuwe architecturale "agent runtime layer" voor die de kloof tussen multi-agent frameworks en LLM-serving engines overbrugt om beleidsgestuurde optimalisaties mogelijk te maken, en demonstreert via het CacheSage-systeem dat deze aanpak de cache-hitratio, de time-to-first-token en de doorvoer aanzienlijk verbetert bij diverse multi-agent workloads.

Oorspronkelijke auteurs: Rui Zhang, Chaeeun Kim, Liting Hu

Gepubliceerd 2026-05-28

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Rui Zhang, Chaeeun Kim, Liting Hu

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 drukke, hoogwaardig restaurant runt.

De Huidige Opzet: Een Communicatiebreuk
Op dit moment heeft je restaurant twee distincte lagen die niet goed met elkaar communiceren:

De Hoofdchef (Het Agent Framework): Deze persoon kent het menu, de rollen van de kelners en de specifieke instructies voor elke tafel. Ze weten wie bestelt en wat ze nodig hebben. Echter, ze zien nooit de keukenvloer; ze weten niet welke potten momenteel op het fornuis staan of welke ingrediënten op zijn.
Het Keukenpersoneel (De Serving Engine): Dit team ziet elke bestelling die binnenkomt. Ze weten precies hoeveel potten koken en hoe snel ze kunnen koken. Maar ze hebben geen idee wie de klanten zijn of wat het "verhaal" van de maaltijd is. Voor hen is elke bestelling slechts een generiek verzoek.

Het Probleem: De "Naad" Waar Dingen Breken
Omdat deze twee groepen geen informatie delen, maakt het restaurant inefficiënte beslissingen.

Voorbeeld: De Hoofdchef weet dat Tafel 4 altijd hetzelfde voorgerecht bestelt voor hun hoofdgerecht. Maar het Keukenpersoneel weet dit niet. Dus, elke keer dat Tafel 4 bestelt, moet de keuken uien vanaf nul hakken, zelfs al hebben ze dat vijf minuten geleden gedaan voor dezelfde tafel.
Het paper noemt dit de "naad". Momenteel, als je dit wilt oplossen, moet je de notities van de Hoofdchef of de workflow van de Keuken patchen met een specifieke, eenmalige regel. Het is rommelig en schaalt niet.

De Oplossing: De "Agent Runtime Layer" (De Nieuwe Zaalmanager)
De auteurs stellen voor een derde laag te bouwen precies tussen de Chef en de Keuken: een Zaalmanager.

Deze Zaalmanager heeft een speciale baan. Ze luistert naar de Chef (om de rollen en identiteiten te kennen) en observeert de Keuken (om de kookgebeurtenissen te zien). Ze gebruiken deze gecombineerde kennis om slimme beslissingen te nemen met behulp van vier eenvoudige tools:

Observeren: "Ik zie een nieuwe bestelling binnenkomen van de kelner 'Planner'."
Scoren: "Op basis van de geschiedenis is deze 'Planner'-bestelling zeer belangrijk en waarschijnlijk gevolgd door een 'Coder'-bestelling. Geef het hoge prioriteit."
Voorspellen: "Ik wed dat de volgende bestelling van de kelner 'Coder' komt. Laten we hun ingrediënten nu klaarzetten."
Handelen: "Ga vooruit en voorverwarm het fornuis voor de 'Coder' zodat er geen vertraging is."

Deze Zaalmanager fungeert als een universele vertaler. Elke nieuwe regel (zoals "wees eerlijk voor alle tafels" of "bespaar energie") kan in deze manager worden aangesloten zonder de Chef of de Keuken te breken.

De Casestudy: "CacheSage" (De Slimme Voorraadkast)
Om te bewijzen dat dit werkt, bouwden de auteurs een specifieke Zaalmanager genaamd CacheSage om de "voorraadkast" (het geheugen van de computer, of KV-cache) te beheren.

De Oude Manier: De keuken gooit ingrediënten (geheugen) weg op basis van hoe lang geleden ze werden gebruikt. Als de kelner "Planner" na een pauze terugkomt, moet de keuken alles opnieuw hakken omdat de ingrediënten waren weggegooid.
De CacheSage Manier: De Zaalmanager leert de patronen. Ze merken op dat "Planner" bijna altijd leidt tot "Coder".
- Wanneer de "Planner" klaar is, zegt de Zaalmanager: "Ik voorspel dat 'Coder' als volgende komt."
- Ze houden de ingrediënten van de "Planner" veilig (zodat ze niet worden weggegooid) en beginnen zelfs met het voorbereiden van de ingrediënten van de "Coder" voordat de bestelling zelfs maar binnenkomt.

De Resultaten
Toen ze dit testten op vijf verschillende real-world "restaurant" scenario's (complexe AI-taken):

Minder Afval: Ze hielden de juiste ingrediënten in de voorraadkast 13% tot 37% vaker dan daarvoor.
Snellere Service: Klanten kregen hun eten 12% tot 29% sneller omdat de keuken niet vanaf nul hoefde te beginnen.
Meer Klanten: Het restaurant kon 6% tot 14% meer tafels per uur bedienen.

Samenvattend
Het paper betoogt dat we, om AI-agents efficiënt te laten draaien, niet alleen de bovenste laag (de logica) of de onderste laag (de hardware) kunnen aanpassen. We hebben een dedicated "middenmanager" nodig die zowel de identiteit van de agents als de gebeurtenissen van de engine begrijpt, en die een eenvoudige set van vier regels gebruikt om het hele systeem slimmer en sneller te maken.

Technische Samenvatting: Een Beleidsgedreven Runtime-Layer voor Agentic LLM-diensten

1. Probleemstelling

Multi-agent Large Language Model (LLM)-systemen zijn de dominante productieworkload geworden, maar de bestaande dienstack is architectonisch niet in lijn met hun vereisten. Huidige systemen werken volgens een tweelaagsstructuur:

Agent Framework (Boven): Systemen zoals AutoGen, LangGraph of MetaGPT die agentidentiteiten, rollenschema's en dispatchlogica beheren. Ze genereren LLM-API-aanroepen, maar blijven blind voor engine-niveau gebeurtenissen (bijv. token-generatie, KV-cache-status).
Serving Engine (Onder): Engines zoals vLLM of SGLang die prefilling, batching en token-generatie verwerken. Ze observeren elke gebeurtenis, maar hebben geen kennis van agentidentiteiten of de semantische structuur van de multi-agent workflow.

Deze "naad" creëert een kritieke kloof voor doorsnijdende beleidsregels. Veel optimalisatiestrategieën – zoals KV-cache-verwijdering, batchvorming, speculatieve uitvoering, eerlijkheid en handhaving van veiligheid – vereisen gelijktijdige toegang tot metagegevens over agentidentiteit (van het framework) en engine-niveau gebeurtenissen (van de serving engine). Momenteel worden deze beleidsregels geïmplementeerd als "eenmalige patches" in het framework of de engine. Deze aanpak is breekbaar, niet-modulair en faalt in het benutten van de volledige context die nodig is voor optimale besluitvorming.

2. Methodologie: De Agent Runtime Layer

De auteurs stellen een architecturale interventie voor: het invoegen van een derde laag, de Agent Runtime Layer, tussen het framework en de serving engine. Deze laag fungeert als een substraat dat de doorsnijdende agentmetagegegegevens bezit en een stabiele, beleidsonafhankelijke interface blootlegt.

De Vier Primitieven

De laag definieert vier generieke primitieven waarmee elk agentbewust beleid kan aansluiten. Deze primitieven vormen een observe → score → predict → act feedbacklus, geünificeerd door agentidentiteit als de gedeelde coördinaat:

observe(event): De runtime ontvangt beleidsrelevante gebeurtenissen van buren (bijv. blokaanrakingen, verzoekaankomsten, tool-returns). Het werkt interne status bij die is getagd met agentidentiteit.
score(item): De runtime retourneert een per-item prioriteit die door een buur wordt gebruikt om beslissingen te rangschikken (bijv. welk KV-blok te verwijderen, welk verzoek toe te staan).
predict(horizon): De runtime retourneert een probabilistische voorspelling van toekomstige agentactiviteit (bijv. de volgende agentrol, volgende tool-aanroep).
act(side_effect): De runtime geeft zij-effecten buiten het kritieke pad uit aan een buur (bijv. het opwarmen van een cache, vooraf laden van gewichten, hedgen van een speculatieve aanroep). Dit is de enige primitief die de status van de buur wijzigt.

Casestudie: CacheSage

Om deze abstractie te valideren, instantiëren de auteurs de laag voor KV-caching, het beleid met de grootste directe impact op dienstkosten. Ze introduceren CacheSage, dat het probleem aanpakt van reactieve prefix-caches die "agent-ankers" (systeemprompts en tooldefinities) laten vallen voordat de volgende sessie arriveert.

CacheSage implementeert de vier primitieven via drie componenten:

Transition Learner (observe): Houdt een schuifend venster bij van paarsgewijze agentovergangstellingen ( $n(a', a)$ ) om online een Markov-overgangsmatrix van de eerste orde te berekenen. Het identificeert het "agent-anker" (systeem + tools) via content-hashing.
Survival-Probability Scorer (score): Benadert de waarschijnlijkheid dat een agent binnen de volgende $K$ stappen zal vuren. In plaats van dure exacte berekeningen, gebruikt het een gethreshold Directed Acyclic Graph (DAG) en Breadth-First Search (BFS) om een "hop-count" proxy te berekenen. Deze score wordt gecombineerd met de bestaande recency-klok van de engine om verwijderingsprioriteit te bepalen.
Cross-Session Prefetch (predict + act): Tussen scheduler-stappen voorspelt de runtime de volgende agent ( $a^*$ ) en geeft een "warmup"-verzoek uit. Dit verzoek bevat alleen de systeemprompt en een minimaal gebruikersbericht om de KV-cache voor het anker van de voorspelde agent te vullen zonder volledige sessiespecifieke inhoud in te brengen.

3. Belangrijkste Bijdragen

De Agent Runtime Layer: Een voorgestelde derde laag voor de dienstack die een interface met vier primitieven blootlegt (observe, score, predict, act). De auteurs mapping negen verschillende agentbewuste beleidsregels (waaronder KV-caching, tool-resultaatmemoïsatie, batchvorming en eerlijkheid) naar deze interface, en betogen dat ze allemaal dezelfde architecturale behoefte delen aan met agentidentiteit getagde gebeurtenissen.
CacheSage: Een concrete implementatie van de laag voor KV-caching. Het leert per-workload agentovergangsmatrices online en gebruikt deze voor verwijdering op basis van overleving en prefetching tussen stappen. Het werkt met een gebonden status ( $\le$ 20 KB per workload) en omvat een elegante fallback naar standaard LRU als er geen structuur wordt geleerd.
Empirische Validatie: Voorlopige resultaten op vijf real-world multi-agent workloads (MMLU, MT-Bench, GAIA, GSM8K, HumanEval) die de effectiviteit van de aanpak aantonen.

4. Resultaten

Experimenten werden uitgevoerd op NVIDIA H100 GPU's met Llama-3.1-8B-Instruct, waarbij CacheSage werd vergeleken met vLLM en Continuum.

Cache Hit Rate: CacheSage behaalde een stijging van +13 tot +37 procentpunten (pp) in cache-hit rates ten opzichte van vLLM over alle vijf workloads. Dit wordt toegeschreven aan het behouden van agent-ankers over sessiegrenzen heen die reactieve caches doorgaans verwijderen.
Latentie: De gemiddelde tijd tot eerste token (TTFT) en de end-to-end latentie per beurt werden met 12% tot 29% gereduceerd.
Throughput: De systeemthroughput steeg met 6% tot 14%.
Overhead: De overhead op het hete pad is verwaarloosbaar. De observe-functie draait in $\sim1 \mu s$ per blokaanraking, en de scorer draait in enkele microseconden. De coördinatorstatus blijft onder de 25 KB.

Opmerkelijk is dat het basissysteem Continuum, dat TTL-pins gebruikt, de hit rates daadwerkelijk met 9–23 pp verlaagde op drie real-task workloads, wat de trade-offs van statische beleidsregels versus het adaptieve karakter van de runtime-layer benadrukt.

5. Betekenis en Claims

Het artikel stelt dat de "naad" tussen het agentframework en de serving engine het beste wordt aangepakt door een architecturale wijziging in plaats van incrementele puntreparaties.

Modulariteit: De interface met vier primitieven maakt het mogelijk dat verschillende beleidsregels dezelfde observatiestroom delen en tegen dezelfde primitieven kunnen compositeren zonder dat voor elk beleid nieuwe ingrepen in de engine nodig zijn.
Generaliteit: De laag is framework-agnostisch (ondersteuning voor AutoGen, LangGraph, enz.) en engine-portabel, en vereist alleen specifieke hooks in plaats van diepe interne modificaties.
Validatie van de Kloof: Door aanzienlijke prestatiewinsten op KV-caching aan te tonen, betogen de auteurs dat de architecturale kloof reëel is en dat een agent runtime-layer een noodzakelijk onderdeel is voor efficiënte agentic LLM-diensten.

De auteurs blijven bescheiden wat betreft de reikwijdte van hun huidige werk, en merken op dat hoewel CacheSage de abstractie valideert, de andere acht beleidsregels die op de laag zijn gemapped (bijv. tool-resultaatmemoïsatie, speculatieve agentuitvoering, eerlijkheid) open uitdagingen blijven voor toekomstig werk. De primaire bijdrage is de interface en het architecturale argument, niet de voltooiing van elke beleidsimplementatie.