Agentbaserad AI kommer att stöta på en infrastrukturvägg innan den stöter på en intelligensvägg

Modellerna förbättras snabbare än vår förmåga att leverera det de ombeds göra.

Det mesta av diskussionen om vart AI-agenter är på väg handlar om deras förmåga. Kan modellen planera på ett tillförlitligt sätt? Kan den rätta till sina egna misstag? Kan man lita på att den utför handlingar som får konsekvenser?

Det är verkliga frågor. Men det är inte de frågor som kommer att avgöra om agenter tas i bruk i stor skala under de närmaste åren, eftersom det finns en mer närliggande begränsning som närmar sig snabbare. Det är ekonomiskt kostsamt att tillhandahålla agenter, och kostnaden ökar med just de förmågor som alla vill lägga till.

En chattbot och en agent innebär olika arbetsbelastningar

En konversationsförfrågan består av en enda tur och retur. Skicka in en prompt, få ut token och stäng anslutningen. Du kan batcha förfrågningarna, cachelagra prefixet och bedöma genomströmningen med ett enda tal.

En agentförfrågan är en session. Agenten anropar ett verktyg, väntar, läser resultatet, bestämmer vad den ska göra härnäst, anropar ett annat verktyg och svarar till slut. En måttligt omfattande uppgift kan innebära sex eller åtta modellkörningar med väntetid emellan.

Den skillnaden spelar roll av en anledning som inte har något med intelligens att göra. Mellan stegen håller agenten kvar tillståndet – konversationen, verktygens utdata och de samlade resonemangen. På serversidan lagras det tillståndet i GPU-minnet som KV-cache, och det upptar minne under hela sessionen, även de sekunder då agenten väntar på ett API som inte är ditt.

Därmed blir kapaciteten inte längre ett mått på ”förfrågningar per sekund”, utan på ”samtidiga sessioner som ligger kvar i minnet”. Ett system som utan problem hanterade tusen konversationsförfrågningar per sekund kanske bara klarar några tiotal samtidiga agentsessioner på samma hårdvara.

Väntan är den dyra delen

Här är den obekväma egenskapen: under ett verktygsanrop gör agenten ingenting. Inga token genereras. Ingen beräkningskapacitet används. GPU-minnet är däremot fortfarande upptaget, eftersom det skulle kosta mer att kasta ut kontexten och beräkna om den än att låta den ligga kvar.

Din dyraste hårdvara är reserverad för en förfrågan som just då väntar på en databasfråga.

I konventionella distribuerade system löste vi det här för länge sedan – man frigör resursen och återupptar arbetet när svaret kommer. Att göra samma sak för modellkörning innebär att flytta KV-cachen till värdminnet eller disken och sedan återställa den, och överföringskostnaden är så hög att de flesta system inte bryr sig. Forskning om just detta pågår aktivt, eftersom problemet är kostsamt.

Sekventiell körning gör problemet värre än nödvändigt

Nästan alla agentramverk kör verktygsanrop ett i taget. Modellen ber om en väderprognos, får den, ber om en kalenderkontroll, får resultatet, ber om en flygsökning och får resultatet.

Ofta är de här tre anropen inte beroende av varandra. De hade kunnat köras samtidigt. Körs de sekventiellt blir fördröjningen summan av tiderna. Körs de parallellt blir den lika lång som det långsammaste anropet.

Det här är ingen ny iakttagelse om agenter – det är samma strukturella princip som gäller för alla system som kör flera modeller eller tjänster inom en och samma latensbudget. Den totala fördröjningen bör motsvara den längsta vägen genom beroendegrafen, inte summan av varje steg. Det här spelar större roll för agenter eftersom sessionen ligger kvar i GPU-minnet under hela sin varaktighet. Att korta den faktiska tiden förbättrar därför inte bara användarupplevelsen, utan ökar direkt antalet sessioner som får plats på hårdvaran.

Halverar du sessionens varaktighet fördubblar du ungefär den samtidiga kapaciteten – med samma GPU:er och utan att ändra modellen.

Återförsök staplas på varandra på ett sätt som ingen har planerat för

Agentramverk ärver standardinställningarna för återförsök från de HTTP-bibliotek som ligger under dem. Vanligtvis innebär det tre försök.

Modellen försöker också igen, fast på sitt eget sätt. När ett verktyg returnerar något oanvändbart provar en resonemangsmodell ofta en annan metod – vilket är ett återförsök, bara ett som ingen har konfigurerat.

Staplar man ihop de här mekanismerna blir en policy med tre försök, kombinerad med en modell som på egen hand resonerar sig fram till ytterligare tre metoder, en policy med nio försök som ingen har dokumenterat. Varje försök innebär en fullständig modellkörning med egna token och egna sekunder av GPU-tid.

När en beroendekomponent blir långsammare är det den här förstärkningseffekten som förvandlar en försämring till ett avbrott. Kostnaden per försök är dessutom flera storleksordningar högre än för ett nytt försök med ett REST-anrop.

Så här ser väggen faktiskt ut

Inte ett tak för modellens förmåga. Något mer vardagligt: ett problem med enhetsekonomin som stoppar projekt i övergången från pilot till produktion.

Pilotprojektet fungerar. Det omfattar tio användare, fördröjningen är acceptabel och kostnaden är försumbar. Sedan räknar någon på tiotusen användare och ser att GPU-behovet är orimligt – inte för att modellen är långsam, utan för att varje samtidig session upptar minne under hela sin livstid, och den tiden omfattar även väntan.

Det är här många lovande interna demonstrationer tyst och stilla stannar av.

Vad flyttar väggen

Inget märkvärdigt, och allt handlar om infrastruktur snarare än modellering:

Kör oberoende verktygsanrop parallellt. Den största enskilda förbättringen som finns tillgänglig i dag och som inte kräver någon ny hårdvara.

Använd sessionens varaktighet som kapacitetsmått. Inte token per sekund. Inte GPU-utnyttjande. Utan hur länge tillståndet hålls i minnet och hur många sessioner som får plats.

Fördela omförsök över hela systemet i stället för per anrop. Ett globalt tak – där omförsök utgör en liten andel av den totala trafiken – förhindrar den kumulativa effekt som beskrivs ovan. Googles SRE-praxis för att hantera överbelastning och Envoys omförsöksbudgetar tillämpar båda den här principen utanför AI-stacken.

Skilj resonemang från utförande. Använd en stor modell för planeringen och en betydligt mindre för de mekaniska stegen. Det mesta en agent gör kräver ingen spetsmodell.

Gör det billigt att frigöra kontext. KV-cache med kvantisering, sidindelad attention och avlastningsvägar för inaktiva sessioner. Det är här det mest intressanta arbetet med inferenshantering pågår just nu.

Modellerna kommer att fortsätta bli bättre. Den delen verkar säker. Om agenter blir infrastruktur eller förblir demonstrationer beror på något mindre glamoröst – om vi kan hantera en arbetsbelastning som håller dyrt minne upptaget medan den väntar, och om vi slutar betala för summan av en sekvens när vi i stället skulle kunna betala för dess längsta väg.

Jag publicerade exekveringsmodellen bakom den sista poängen – samtidig exekvering av beroende modellanrop inom en och samma latensbudget – i ”Asynkron exekvering av inferensgrafer för modellroutning i maskininlärningssystem”, International Journal of Computer Trends and Technology 72(10), oktober 2024. Läs ”LLM-förstärkta handels- och beslutsplattformar: att förena generativ intelligens med finansiella beslutssystem”, Journal of Information Systems Engineering and Management 11(1s), 2026, om hur generativa modeller integreras specifikt i beslutssystem med strikta latenskrav.