Prefix-aware routing sænker LLM-latenstid

Når en LLM behandler tekst, opbygger den undervejs en såkaldt KV-cache, en mellemregning af nøgle- og værdivektorer for alle de tokens, modellen allerede har set. Den cache er guld værd, fordi den betyder, at modellen ikke skal genberegne konteksten fra scratch, hvis den næste forespørgsel deler en indledende tekststump, en prefix, med en tidligere. Problemet i klassiske load balancere er, at de fordeler trafik rundt efter simpel belastning eller round robin, uden hensyn til hvor den varme cache faktisk ligger. Resultatet er, at to forespørgsler med identisk systemprompt eller identisk samtalehistorik ender på to forskellige GPU-instanser, og cachen skal bygges op igen fra bunden på den ene af dem.

Den nye routing-mekanisme på SageMaker Inference vender det om. Den kigger på selve prefixet i den indkommende forespørgsel og sender den til den instans, der allerede har den mest matchende KV-cache liggende i hukommelsen. For arbejdsflows med gentagne systemprompter, faste few-shot-eksempler eller lange samtaletråde, som er kernen i det meste agentiske AI, betyder det, at store dele af konteksten aldrig skal genberegnes.

Det konkrete resultat er en markant reduktion i time-to-first-token, altså den tid brugeren venter, før modellen begynder at svare. Ifølge AWS Machine Learning Blog viser interne benchmarks reduktioner på op til 77 procent i time-to-first-token for arbejdsbelastninger med høj cache-genbrugsgrad, primært drevet af, at cache-hit-raten stiger markant, når routing-laget bevidst holder relaterede forespørgsler samlet på samme instans.

Det er ikke en marginal optimering. For en samtale-agent eller en kundeserviceassistent, der venter flere sekunder på det første ord i svaret, er forskellen mellem en tung, træg oplevelse og en, der føles øjeblikkelig. Og fordi genberegning af KV-cachen også koster GPU-cyklusser, følger der typisk en besparelse i beregningsomkostninger med, ikke kun en oplevet hastighedsgevinst. Valget af inferensinfrastruktur, som SageMaker HyperPod og EKS, spiller også ind på, hvor godt den type gevinster kan realiseres i drift.

Agentisk AI adskiller sig fra en enkeltstående chatbot ved, at den ofte kalder den samme model igen og igen inden for én opgave, med voksende kontekst for hvert kald: et værktøjskald, en observation, en ny beslutning, endnu et værktøjskald. Hver af de kald deler typisk en stor, uændret prefix, systemprompten, værktøjsdefinitionerne, samtalehistorikken, og kun den sidste bid er ny. Uden prefix-aware routing bliver den delte kontekst spredt ud over flere GPU-instanser, og cache-hit-raten falder drastisk, jo flere trin agenten tager.

Det er derfor, denne optimering rammer agentiske arbejdsflows særligt hårdt, i positiv forstand. Jo mere kompleks og trinvis en agent-arkitektur er, desto større er gevinsten ved at holde relaterede kald samlet. En agent, der laver ti værktøjskald i træk, kan gå fra ti fulde genberegninger til reelt kun én, fordi ni ud af ti kald rammer en varm cache.

For virksomheder, der allerede kører produktionsagenter på SageMaker eller overvejer at flytte dertil, er den her type infrastrukturforbedring interessant, fordi den kræver nul ændringer i selve agent-koden.

Vi arbejder med større AI-projekter for danske virksomheder, fra problemafklaring til drift, og et af de tilbagevendende temaer er, at latenstid og driftsomkostninger ofte først bliver et reelt problem, når en agent går fra proof of concept til produktion med rigtig trafik. Optimeringer som prefix-aware routing er præcis den slags, der ikke kræver, at man bygger om, men som kan gøre forskellen på, om en agentisk løsning føles brugbar i praksis eller for langsom til at blive brugt dagligt. For virksomheder, der allerede investerer i produktionsklar AI-agent på AWS, er det værd at holde øje med, om deres nuværende inferensopsætning udnytter den type routing, eller om de reelt betaler for gentagne genberegninger, de ikke behøver.