Agentbasert KI møter en infrastrukturvegg før den møter en intelligensvegg

Modellene blir bedre raskere enn vi klarer å levere det de blir bedt om.

Mye av diskusjonen om hvor KI-agenter er på vei, handler om hva de er i stand til. Kan modellen planlegge pålitelig? Kan den rette opp sine egne feil? Kan den få ansvar for handlinger som får konsekvenser?

Dette er reelle spørsmål. Men det er ikke disse spørsmålene som vil avgjøre om agenter tas i bruk i stor skala de neste årene, for det finnes en mer nærliggende begrensning, og den melder seg raskere. Det er kostnadskrevende å drifte agenter, og kostnadene øker i takt med nettopp de funksjonene alle ønsker å legge til.

En chatbot og en agent er ulike arbeidsbelastninger

En forespørsel i en samtale består av én rundtur. Spørsmål inn, tokener ut, forbindelsen lukkes. Den kan behandles i grupper, prefikset kan hurtigbufres, og gjennomstrømningen kan beskrives med ett enkelt tall.

En forespørsel til en agent er en økt. Den kaller et verktøy, venter, leser resultatet, bestemmer hva den skal gjøre videre, kaller et nytt verktøy og svarer til slutt. En forholdsvis enkel oppgave kan innebære seks eller åtte modellkall, med ventetid mellom hvert.

Denne forskjellen har betydning av en grunn som ikke har noe med intelligens å gjøre. Mellom trinnene holder agenten på tilstanden – samtalen, verktøyresultatene og resonnementet den har bygget opp. På driftssiden ligger denne tilstanden i GPU-minnet som KV-hurtigbuffer, og den opptar minne gjennom hele økten, også i sekundene agenten venter på et API som ikke er ditt.

Dermed er ikke lenger «forespørsler per sekund» måleenheten for kapasitet; den blir «samtidige økter som ligger i minnet». Et system som uten problemer håndterte tusen samtaleforspørsler i sekundet, kan kanskje bare håndtere noen titalls samtidige agentøkter på samme maskinvare.

Ventingen er den kostbare delen

Her er den ubehagelige egenskapen: Mens et verktøykall pågår, gjør agenten ingenting. Ingen tokener genereres. Ingen beregningsressurser brukes. GPU-minnet er likevel fortsatt opptatt, fordi det ville koste mer å frigjøre det og beregne konteksten på nytt enn å la den bli liggende.

Den dyreste maskinvaren din er reservert for en forespørsel som akkurat da venter på et databasesøk.

I tradisjonelle distribuerte systemer løste vi dette for lenge siden: Vi frigjør ressursen og fortsetter arbeidet når svaret kommer. Å gjøre det samme for modellkjøring innebærer å flytte KV-hurtigbufferen til vertsminnet eller disken og hente den tilbake igjen. Overføringen er så kostbar at de fleste systemer ikke gjør det. Forskning på akkurat dette pågår, og det gjør den fordi problemet er kostbart.

Sekvensiell kjøring gjør problemet større enn nødvendig

Nesten alle agentrammeverk utfører verktøykall etter hverandre. Modellen ber om et værsøk, får resultatet, ber om en kalendersjekk, får resultatet, og ber om et flysøk og får resultatet.

Ofte er disse tre kallene ikke avhengige av hverandre. De kunne ha blitt kjørt samtidig. Kjøres de etter hverandre, er forsinkelsen summen av dem. Kjøres de parallelt, tilsvarer den forsinkelsen til det tregeste kallet.

Dette er ikke en ny observasjon om agenter – det er det samme strukturelle poenget som gjelder for alle systemer som kjører flere modeller eller tjenester innenfor én og samme tidsramme for forsinkelse. Den totale forsinkelsen bør tilsvare den lengste veien gjennom avhengighetsgrafen, ikke summen av hvert trinn. Dette er viktigere for agenter fordi økten ligger i GPU-minnet hele tiden. Å redusere den faktiske tidsbruken forbedrer derfor ikke bare brukeropplevelsen, men øker direkte hvor mange økter maskinvaren kan håndtere.

Halverer du varigheten på økten, dobler du omtrent kapasiteten for samtidige økter på de samme GPU-ene, uten å endre modellen.

Nye forsøk hoper seg opp på en måte ingen har planlagt for

Agentrammeverk overtar standardinnstillingene for nye forsøk fra HTTP-bibliotekene de bygger på. Vanligvis er det tre forsøk.

Modellen prøver også på nytt, på sin egen måte. Når et verktøy returnerer et lite nyttig resultat, vil en resonnerende modell ofte prøve en annen framgangsmåte – det er også et nytt forsøk, bare et forsøk ingen har konfigurert.

Kombinerer man disse, blir en policy med tre forsøk, lagt rundt en modell som på egen hånd resonnerer seg fram til tre nye framgangsmåter, til en policy med ni forsøk som ingen har skrevet ned. Hvert av disse forsøkene er et fullstendig modellkall med egne tokener og egne GPU-sekunder.

Når en avhengighet blir tregere, er det denne forsterkningen som gjør en forringelse til et driftsavbrudd. Kostnaden per forsøk er dessuten flere størrelsesordener høyere enn for et REST-kall som prøves på nytt.

Slik ser veggen faktisk ut

Ikke et tak for hva teknologien kan få til, men noe langt mer prosaisk: et problem med økonomien per enhet som stanser prosjekter i overgangen fra pilot til produksjon.

Pilotprosjektet fungerer. Det har ti brukere, forsinkelsen er akseptabel, og regningen er en avrundingsfeil. Så lager noen en prognose for ti tusen brukere, og GPU-behovet framstår som urealistisk – ikke fordi modellen er treg, men fordi hver samtidige økt opptar minne hele levetiden sin, og levetiden omfatter også ventetid.

Dette er stadiet der mange lovende interne demoer stilletiende stopper opp.

Hva flytter grensen

Ikke noe eksotisk, og alt handler om infrastruktur snarere enn modellering:

Utfør uavhengige verktøykall samtidig. Den største enkeltgevinsten som er tilgjengelig i dag, og som ikke krever ny maskinvare.

Bruk øktens varighet som kapasitetsmål. Ikke antall tokener per sekund. Ikke GPU-utnyttelse. Hvor lenge tilstanden holdes i minnet, og hvor mange økter det er plass til.

Fordel nye forsøk på tvers av systemet, ikke per kall. En global grense – nye forsøk som en liten andel av den samlede trafikken – hindrer opphopningen som er beskrevet ovenfor. Googles SRE-praksis for håndtering av overbelastning og Envoys budsjetter for nye forsøk gjennomfører begge denne ideen utenfor AI-stakken.

Skill resonnering fra utførelse. En stor modell til planlegging, en mye mindre til de mekaniske trinnene. Det meste av det en agent gjør, krever ikke en av de mest avanserte modellene.

Gjør det billig å fjerne kontekst. Kvantisert KV-hurtigbuffer, sideinndelt oppmerksomhet og avlastingsbaner for inaktive økter. Det er her det mest interessante arbeidet med inferensservering foregår akkurat nå.

Modellene vil fortsette å bli bedre. Den delen virker pålitelig. Om agenter blir infrastruktur eller forblir demoer, avhenger av noe mindre glamorøst – om vi kan betjene en arbeidsbelastning som holder på dyrt minne mens den venter, og om vi slutter å betale for summen av en sekvens når vi kunne betalt for den lengste banen.

Jeg publiserte utførelsesmodellen som ligger til grunn for det siste poenget – samtidig kjøring av avhengige modellkall innenfor ett enkelt latensbudsjett – i «Asynkron kjøring av inferensgrafer for modellruting i maskinlæringssystemer», International Journal of Computer Trends and Technology 72(10), oktober 2024. Når det gjelder integrering av generative modeller i beslutningssystemer med strenge latenskrav spesielt, se «LLM-forsterkede handels- og beslutningsplattformer: Brobygging mellom generativ intelligens og finansielle beslutningssystemer», Journal of Information Systems Engineering and Management 11(1s), 2026.