Agentisk AI rammer en mur i infrastrukturen, før den rammer en mur i intelligensen

Modellerne bliver bedre, hurtigere end vi bliver i stand til at levere det, de bliver bedt om.

Det meste af debatten om, hvor AI-agenter er på vej hen, handler om deres evner. Kan modellen planlægge pålideligt? Kan den rette op på sine egne fejl? Kan man betro den en handling, der får konsekvenser?

Det er reelle spørgsmål. Men det er heller ikke dem, der afgør, om agenter bliver taget i brug i stor skala de næste par år, for der er en mere nærliggende begrænsning, og den melder sig hurtigere. Det er økonomisk uhensigtsmæssigt at betjene agenter, og det bliver endnu mere uhensigtsmæssigt, jo flere af de funktioner, alle gerne vil tilføje, de får.

En chatbot og en agent er forskellige arbejdsbelastninger

En samtaleforespørgsel består af én tur-retur. Prompt ind, tokens ud, forbindelsen lukket. Den kan behandles i batches, præfikset kan caches, og kapaciteten kan vurderes ud fra ét enkelt tal.

En agentforespørgsel er en session. Den kalder et værktøj, venter, læser resultatet, beslutter, hvad den skal gøre derefter, kalder et nyt værktøj og svarer til sidst. En forholdsvis enkel opgave kan kræve seks eller otte modelkørsler med ventetid imellem.

Den forskel er vigtig af en grund, der ikke har noget med intelligens at gøre. Mellem trinnene bevarer agenten sin tilstand — samtalen, værktøjsresultaterne og de ræsonnementer, der er samlet op undervejs. Når modellen betjenes, ligger denne tilstand i GPU-hukommelsen som KV-cache, og den optager hukommelse under hele sessionen, også i de sekunder, hvor agenten venter på et API, der ikke er dit eget.

Kapacitet måles derfor ikke længere i »forespørgsler pr. sekund«, men i »samtidige sessioner i hukommelsen«. Et system, der uden problemer håndterede tusind samtaleforespørgsler i sekundet, kan måske kun håndtere nogle få dusin samtidige agentsessioner på den samme hardware.

Det er ventetiden, der koster

Her er den ubehagelige egenskab: Under et værktøjskald foretager agenten sig intet. Der genereres ingen tokens. Der bruges ingen regnekraft. GPU-hukommelsen er dog stadig optaget, fordi det ville koste mere at smide konteksten ud og beregne den igen end at beholde den.

Din dyreste hardware er reserveret til en forespørgsel, der lige nu venter på et databaseopslag.

I konventionelle distribuerede systemer løste vi det for længe siden: Man frigiver ressourcen og genoptager arbejdet, når svaret kommer. Hvis man gør det samme, når man betjener modeller, skal KV-cachen flyttes til værtsmaskinens hukommelse eller en disk og derefter gendannes. Overførslen er så omkostningsfuld, at de fleste systemer ikke gør sig ulejligheden. Der forskes aktivt i netop dette, fordi problemet er dyrt.

Sekventiel afvikling gør det værre end nødvendigt

Næsten alle agentrammer afvikler værktøjskald ét ad gangen. Modellen beder om et vejropkald, får svaret, beder om et tjek af kalenderen, får svaret, beder om en flysøgning og får svaret.

Ofte afhænger de tre kald ikke af hinanden. De kunne være kørt samtidig. Afvikles de sekventielt, er svartiden summen af dem. Afvikles de parallelt, svarer svartiden til det længste kald.

Det er ikke en ny iagttagelse om agenter — det er det samme strukturelle forhold, som gælder for ethvert system, der afvikler flere modeller eller tjenester inden for ét samlet tidsbudget. Den samlede svartid bør svare til den længste vej gennem afhængighedsgrafen, ikke summen af hvert trin. Det er vigtigere for agenter, fordi sessionen ligger i GPU-hukommelsen under hele forløbet. Derfor forbedrer en kortere samlet køretid ikke blot brugeroplevelsen; den øger direkte antallet af sessioner, der kan være på hardwaren samtidig.

Halverer man sessionens varighed, fordobles den samtidige kapacitet omtrent på de samme GPU’er uden at ændre modellen.

Genforsøg hober sig op på en måde, ingen har planlagt

Agentrammer overtager standardindstillingerne for genforsøg fra de HTTP-biblioteker, de bygger på. Som regel er der tale om tre forsøg.

Modellen prøver også igen, bare på sin egen måde. Når et værktøj returnerer noget, der ikke hjælper, vil en ræsonnerende model ofte prøve en anden tilgang — hvilket også er et genforsøg, blot et, ingen har konfigureret.

Lægger man de to ting sammen, bliver en politik med tre forsøg, der omslutter en model, som på egen hånd ræsonnerer sig frem til tre yderligere tilgange, til en politik med ni forsøg, som ingen har skrevet ned. Hvert forsøg er en fuld modelkørsel med sine egne tokens og sekunder på GPU’en.

Når en afhængighed bliver langsommere, er det denne forstærkning, der gør en forringelse til et nedbrud, og prisen pr. forsøg er flere størrelsesordener højere end for et gentaget REST-kald.

Sådan ser muren faktisk ud

Ikke et loft for, hvad teknologien kan. Noget mere jordnært: et problem med enhedsøkonomien, der standser projekter på grænsen mellem pilotfasen og produktionsdrift.

Pilotprojektet fungerer. Der er ti brugere, svartiden er acceptabel, og regningen er en afrundingsfejl. Så modellerer nogen løsningen med ti tusind brugere, og GPU-behovet viser sig at være urealistisk — ikke fordi modellen er langsom, men fordi hver samtidig session optager hukommelse i hele sin levetid, og levetiden omfatter ventetid.

Det er på dette stadie, at mange lovende interne demoer stille og roligt går i stå.

Hvad flytter grænsen

Intet eksotisk, og det hele handler om infrastruktur snarere end modellering:

Udfør uafhængige værktøjskald samtidigt. Den største enkeltstående gevinst, der er tilgængelig i dag, og som ikke kræver ny hardware.

Brug sessionsvarighed som kapacitetsmål. Ikke tokens pr. sekund. Ikke GPU-udnyttelse. Hvor længe tilstanden forbliver i hukommelsen, og hvor mange sessioner der er plads til.

Fordel genforsøg på tværs af systemet i stedet for pr. kald. Et globalt loft — hvor genforsøg begrænses til en lille procentdel af den samlede trafik — forhindrer den forstærkende effekt, der er beskrevet ovenfor. Googles SRE-praksis for håndtering af overbelastning og Envoys genforsøgsbudgetter implementerer begge denne idé uden for AI-stakken.

Adskil ræsonnering fra udførelse. Brug en stor model til planlægning og en meget mindre model til de mekaniske trin. Det meste af det, en agent gør, kræver ikke en førende model.

Gør det billigt at fjerne kontekst. Kvantiseret KV-cache, sideskiftet opmærksomhed og metoder til at flytte inaktive sessioner ud af hukommelsen. Det er her, det mest interessante arbejde med inferensafvikling foregår lige nu.

Modellerne bliver ved med at blive bedre. Det virker sikkert. Om agenter bliver en del af infrastrukturen eller forbliver demoer, afhænger af noget mindre glamourøst — om vi kan afvikle en arbejdsbelastning, der optager dyr hukommelse, mens den venter, og om vi holder op med at betale summen af en sekvens, når vi i stedet kunne betale for dens længste sti.

Jeg publicerede den afviklingsmodel, der ligger til grund for den sidste pointe — samtidig afvikling af afhængige modelkald inden for et enkelt latensbudget — i “Asynkron afvikling af inferensgrafer til modelrouting i maskinlæringssystemer”, International Journal of Computer Trends and Technology 72(10), oktober 2024. Om integrationen af generative modeller i latensbegrænsede beslutningssystemer specifikt kan du læse “Handels- og beslutningsplatforme udvidet med LLM’er: Bro mellem generativ intelligens og finansielle beslutningssystemer”, Journal of Information Systems Engineering and Management 11(1s), 2026.