AI-kostnadsoptimering: Caching, batching och modellval som halverar fakturan

När en LLM-app väl tar fart brukar fakturan komma som en överraskning. En kostnad som var försumbar i pilotskede blir plötsligt en post som någon på ekonomi börjar fråga om. Den goda nyheten är att de flesta LLM-appar är rejält överoptimerade på kostnad - inte för att någon slarvat, utan för att man byggt för att få det att fungera först och inte hunnit titta på effektiviteten. Det går nästan alltid att få ner kostnaden påtagligt utan att kvaliteten sjunker, ofta i storleksordningen halva fakturan.

Jag har gjort kostnadsgenomgångar för svenska bolag där notan sprungit iväg, och nedan är greppen som ger mest, i ungefär den ordning jag brukar ta dem. En sak vill jag betona genom hela artikeln: kostnadsoptimering utan kvalitetskontroll är inte optimering, det är försämring. Det går alltid att göra en app billigare genom att göra den sämre. Konsten är att kapa kostnaden utan att användaren märker någon skillnad, och det kräver att man mäter både kronor och kvalitet samtidigt.

Mät först - annars optimerar du i blindo

Innan något annat tar jag reda på vart pengarna faktiskt går. Vilken funktion står för merparten av tokens? Är det indata eller utdata som dominerar? Ofta visar det sig att en enda funktion eller en onödigt lång systemprompt står för en oproportionerlig andel. Utan den mätningen riskerar man att lägga tid på att optimera det som inte spelar roll. Den här uppföljningen får man ofta på köpet om man kör en AI-gateway, vilket jag skriver om i en egen artikel.

Modellval: betala inte för mer än du behöver

Den enskilt största hävstången är oftast modellval. Många appar använder den dyraste, mest kapabla modellen för varje anrop, även för uppgifter en mycket billigare modell klarar lika bra. Jag kartlägger vilka anrop som verkligen kräver toppmodellen och vilka som kan gå till en billigare - klassificering, enkel extraktion och rutinsvar behöver sällan det dyraste. Att rangordna rätt anrop till rätt modell hänger ihop med routing i en gateway och förutsätter att man kan mäta kvaliteten, vilket jag beskriver i artikeln om evals.

Ett mönster som ofta lönar sig är att låta en billig modell göra grovjobbet och bara eskalera till en dyr när det verkligen behövs. En liten modell kan avgöra om en fråga är enkel eller svår, hantera de enkla själv, och skicka de svåra vidare. För många appar är majoriteten av frågorna enkla, vilket gör att en stor del av trafiken aldrig rör den dyra modellen. Det kräver lite mer logik och en eval som bekräftar att eskaleringen träffar rätt, men besparingen är ofta dramatisk just för att fördelningen mellan enkelt och svårt är så skev.

Caching: betala en gång, svara många

Mycket av det en LLM-app gör är repetitivt. Samma frågor ställs om och om igen, samma systemprompt skickas vid varje anrop. Caching angriper båda:

• Svarscache: identiska eller mycket lika förfrågningar kan returnera ett sparat svar istället för ett nytt anrop.
• Prompt-caching: flera leverantörer låter dig återanvända en stor, oförändrad kontextdel till kraftigt reducerat pris.

Prompt-caching är särskilt tacksamt i RAG-appar där samma instruktioner och ofta samma dokument återkommer - något jag berör i RAG i produktion. Det kräver att prompten är strukturerad så att den stabila delen ligger först, vilket knyter an till prompt-arkitektur.

Batching: samla upp där det går

För arbete som inte måste ske direkt - nattliga sammanfattningar, klassificering av stora mängder dokument, förbearbetning - erbjuder flera leverantörer ett batch-läge till lägre pris mot att svaret kommer senare. Allt som tål att vänta en stund bör jag överväga att batcha. Det passar inte interaktiva flöden, men för bakgrundsarbete är rabatten betydande.

Skicka färre tokens

Den mest underskattade besparingen är helt enkelt att skicka mindre. Uppblåsta systemprompter, onödigt många few-shot-exempel och hela dokument där ett utdrag räckt - allt kostar vid varje anrop. Jag går igenom prompterna och trimmar det som inte bär sin vikt, och i RAG-flöden ser jag till att bara de mest relevanta bitarna följer med istället för allt som hämtats. Ofta är det här de snabbaste vinsterna finns.

Att hitta den rätta balansen mellan kostnad och kvalitet - inte bara skära blint - är en av de mer tacksamma sakerna jag gör inom AI Engineering, eftersom resultatet syns direkt på fakturan.

Sätt tak och larm innan fakturan gör det

Optimering är inte en engångsinsats - kostnaden kryper tillbaka om ingen vaktar den. Jag sätter därför upp löpande uppföljning per funktion och larm som slår till när kostnaden avviker från det väntade, gärna med tak per app eller team så att en bugg eller en plötslig trafikökning inte tyst dränerar budgeten. Det vanligaste sättet att bli obehagligt överraskad är en oändlig loop eller ett retry-mönster som råkar mångdubbla anropen, och den sortens sak vill man upptäcka samma dag, inte på månadsfakturan. En gateway gör den här bevakningen enklare, men det går att komma långt med enkel loggning också.

Optimera inte bort kvaliteten

En varning på vägen: kostnadsoptimering utan mätning kan tyst försämra kvaliteten. Byter du till en billigare modell eller kortar prompten måste du verifiera att svaren fortfarande håller. Därför kör jag alltid kostnadsändringar mot en utvärderingssvit, så att besparingen inte sker på bekostnad av något användarna märker. Billigare och sämre är sällan en bra affär.

Relaterat

• Structured outputs med OpenAI och Anthropic: JSON-schema i LLM-svar
• Multi-agent systems: Orchestration, delegation och konfliktlösning
• AI-gatewayar: Kong AI Gateway, Portkey och LiteLLM i produktion

Ett exempel på en genomgång som halverade en LLM-faktura finns bland mina kundcase.

Vill du ta det vidare?

Har er LLM-faktura sprungit iväg och ni vill veta var de enkla vinsterna finns? Boka ett förutsättningslöst samtal så går vi igenom var pengarna tar vägen.