EN agent for kunstig intelligens den bruker ikke all sin tid på å generere svar. Den kan starte et program, konsultere en ekstern tjeneste, kjøre en test eller slutte å vente på brukertillatelse. Under disse pausene er det imidlertid en risiko for å miste en snarvei som lar de språklige modellene fungere raskere og med mindre kostnader: hurtigbuffer.
En studie publisert på arXiv foreslår å holde den aktiv gjennom korte periodiske signaler, kalt holde i live. I tester utført med tjenestene til Anthropic, OpenAI, Google og DeepSeek, tillot denne teknikken at en stor del av det allerede behandlede prefikset ble oppbevart i chatbot-cachen selv under pauser som er lange nok til å normalt føre til at det ble fjernet. I det gunstigste tilfellet kan kostnaden for enkeltforespørselen som sendes etter pausen reduseres med en maksimal faktor på 12,5. Den generelle bekvemmeligheten avhenger imidlertid av tidsbruken, plattformen som brukes og hyppigheten som keepalives utføres med.
Hva er hurtigbufring og hvorfor gjør det AI mer effektiv
Når en forespørsel sendes til en stor språkmodell, må systemet først analysere den mottatte teksten. Instruksjonene, tidligere meldinger og eventuelle dokumenter er delt inn i tokens, dvs. små enheter, og transformert til en intern tilstand som kan brukes til å produsere svaret. Denne innledende fasen kalles forhåndsfyll.
I lange samtaler forblir mye av innholdet det samme fra en samtale til den neste. For å unngå å gjenta de samme beregningene hver gang, kan leverandører midlertidig lagre prefikset allerede behandletdet vil si den første delen av ledeteksten som forblir den samme mellom én forespørsel og den følgende. Modellen må dermed kun forholde seg til den tilsatte delen.
Dette er ikke langtidsminnet som en chatbot kan huske preferanser eller informasjon om brukeren med. Det er en teknisk mekanisme som kan sammenlignes med å legge igjen dokumenter på skrivebordet som fortsatt vil være nødvendig, og så lenge de forblir tilgjengelige er det ikke nødvendig å forberede dem på nytt.
I tjenestene som er undersøkt i studien, kan tokens hentet fra cache koste mye mindre enn de som behandles fra bunnen av i noen tilfeller omtrent en tiendedel. Det tar også kortere tid før systemet begynner å generere responsen.
Hvorfor AI-agent pauser kan øke kostnadene
Problemet dukker først og fremst opp i agentsystemer, hvis arbeidssyklus kan oppsummeres i tre faser: tenke, handle og vente. Etter å ha bestemt hvilken handling som skal utføres, bruker agenten et eksternt verktøy. Det kan for eksempel kompilere noe kode, starte en serie tester, spørre etter en database eller be om bekreftelse før du sender en e-post.
Disse oppgavene kan ta flere minutter. I mellomtiden forblir den midlertidige lagringen knyttet til prefikset ubrukt, og leverandøren kan fjerne den for å frigjøre ressurser.
Hvis kopien har blitt fjernet i mellomtiden, når følgende forespørsel kommer systemet han er ikke lenger i stand til å gjenopprette de allerede utførte beregningeneselv om tidslinjen for samtalen forble nesten identisk. Konteksten er fortsatt tilstede og agenten har ikke glemt oppgaven som skal fullføres, men forhåndsutfyllingen må kjøres på nytt.
Konsekvensen blir relevant når historien inkluderer titusenvis av tokens og den samme dynamikken gjentas flere ganger. Hver fjerning av prefikset fra hurtigbufferen resulterer i en ny forfyllingsfasemed en økning i utgifter og tid som kreves for at svaret skal begynne å vises.
Hvordan keepalive fungerer og hva studien viste
Den analyserte løsningen består av send samme prefiks på nytt mens du venterog ber modellen generere minst mulig nytt innhold. Hvert signal fornyer varigheten av dataene i hurtigbufferen, og forhindrer plattformen i å eliminere den interne tilstanden som produseres under behandlingen av ledeteksten. Prinsippet minner om keepalive-meldinger som brukes i nettverksforbindelser for å kommunisere at en økt fortsatt er aktiv.
For å teste effektiviteten til teknikken ble de brukt 40 000 og 100 000 token-konteksterintroduserer pauser på 1, 5 og 10 minutter. I en del av testene ble det ikke sendt signal i intervallet, mens i de andre ble prefikset presentert på nytt hvert 30. sekund.
Det ble også utført målinger i opptil 40 minutter, med sikte på å identifisere øyeblikket der hver tjeneste hadde en tendens til å slette de lagrede dataene.
Med keepalives aktivert, en median andel av minst 98 % av ledetekstene.
I tester ble prefikset fullstendig kastet ut av Anthropics cache etter ca 6 minutter, mens på DeepSeek skjedde dette innen 10 minutter. I tilfellet med OpenAI ble det helt «kaldt» rundt halvtimesmerket.
Resultatene for Google var mindre enkle. Plattformen viste ikke et stabilt utløpspunkt, sannsynligvis fordi forespørsler kunne rutes til forskjellige maskiner. Pings økte sannsynligheten for å finne data, men et vindu med økonomisk bekvemmelighet kunne ikke identifiseres så nøyaktig.
Når du holder cachen «varm» lønner det seg virkelig
Å holde prefikset aktivt er ikke alltid fordelaktig. Faktisk forbruker hvert signal ressurser, og hvis det sendes for ofte, kan tilleggsutgiften overstige besparelsene som oppnås ved å unngå ny behandling.
Studien viser at 30 sekunders intervallet som ble brukt i testene var omtrent åtte ganger dyrere enn nødvendig for Anthropic. For å redusere avfall må du vente så lenge som mulig uten å overskride perioden hvor leverandøren oppbevarer dataene med tilstrekkelig sikkerhet.
Basert på målinger, hvis du velger å bruke keepalive, vil det mest effektive intervallet være ca. 4 minutter for Anthropic og DeepSeek og 8 minutter for OpenAI. Disse verdiene inkluderer en sikkerhetsmargin i forhold til den observerte fristen.
Den totale varigheten av pausen spiller også en avgjørende rolle. Hvis pausen er veldig kort, forblir innholdet fortsatt tilgjengelig og keepalive representerer kun en ekstra kostnad. Hvis ventetiden forlenges for mye, kan imidlertid summen av signalene bli dyrere enn en enkelt ny prefill.
Det er derfor et mellomområde der det er veldig praktisk å holde cachen «varm». I løpet av en 30-minutters pause med en 100 000 token-kontekst, med tanke på ping og oppfølgingsforespørselen, reduserte teknikken utgiftene med en faktor på 1,56 på Anthropic og opptil 2,45 på OpenAIved å bruke det mest passende intervallet for hver plattform.
På DeepSeek var prisen på ny prosessering allerede så lav at serien med ping var upraktisk. For Google tillot imidlertid ikke fraværet av en forutsigbar frist det å beregne en like presis strategi.
Den maksimale verdien på 12,5 ganger gjelder kostnaden for neste forespørsel og stammer fra sammenligningen mellom tilfellet der prefikset fortsatt er tilgjengelig og det der hele konteksten må behandles fra bunnen av. Også med tanke på signalene som sendes under ventetiden, er den økonomiske fordelen med hele operasjonen mer begrenset.
Teknikken gir imidlertid en ekstra fordel: i tjenester der den hurtigbufrede kopien hadde blitt eliminert, reduserte keepalive tiden det tok for å begynne å generere responsen betydelig.
Fordi denne løsningen kanskje ikke varer evig
Å bevare intern tilstand kan være praktisk for den enkelte utvikler, men kan bli mer problematisk hvis teknikken blir utbredt. De tilgjengelige hurtigbufferplassene deles, og hvis hver agent kontinuerlig sendte signaler, vil mange prefikser alltid vises som nye og må derfor bevares, noe som øker presset på plattformenes infrastruktur.
For dette kunne leverandører introdusere absolutte tidsbegrensninger, kvoter for hver konto eller spesifikke avgifter basert på antall tokens lagret i minnet per time.
Verket er også en forpublisering og har noen begrensninger. Målingene beskriver forholdene observert med et enkelt testsystem. Testene på Google ble redusert med de tilgjengelige kvotene, mens DeepSeek ble undersøkt gjennom en spesifikk mellomtjeneste.
Resultatene viser imidlertid at i aktiviteter som består av handlinger og dødtid, kan man unngå gjentatte beregninger ved å opprettholde den allerede utarbeidede konteksten. For å oppnå reelle besparelser må imidlertid frekvensen av keepalives tilpasses oppførselen og prisene til den enkelte plattform.
