Kostnadsoptimera inferens: promptcache, styrning och kontroll av utdata

I mitten av 2026 är det vanligaste arkitekturmisstaget vi ser i produktion att team betalar för mycket för inferens. De lanserar LLM-funktioner, ser att de fungerar och möts sedan av femsiffriga månadsfakturor som växer med användningen. Vissa funktioner blir olönsamma. Vissa företag tar bort funktioner som hade varit livskraftiga med bättre kostnadsdisciplin.

De flesta LLM-fakturor är betydligt större än nödvändigt. Besparingen kommer inte från en magisk metod, utan från en uppsättning optimeringar som var och en är måttlig.

Den här artikeln behandlar metoderna, siffrorna och produktionsdisciplinen. Vi utgår från att grundläggande modellstyrning redan finns; den behandlas i en annan artikel. Här går vi djupare.

Kostnadslagren

LLM-kostnader kommer från:

• Indatatoken. Det som skickas till modellen: systemprompt, kontext och användarfråga.
• Utdatatoken. Det modellen returnerar. Vanligtvis 4–6 gånger dyrare än indata (Anthropic 5×, OpenAI cirka 6× enligt aktuella listpriser; se modell- och prisreferensen, kontrollerad 2026-07-07).
• Resonemangstoken. Resonemangsmodellernas interna ”tanke”-token. Ofta lika dyra som utdata.
• Verktygsanrop. Vid verktygsanrop räknas varje verktygsdefinition som indatatoken.
• Omförsök. Misslyckade anrop kostar också.

Optimering fungerar i varje lager.

Metod 1: promptcache

Den enskilt största hävstången. De flesta moderna leverantörer cachelagrar upprepade indataprefix. Första gången betalar du fullt pris och vid senare anrop med samma prefix betydligt mindre.

Typisk prissättning:

• Anthropic: cachelagrad indata cirka 10 % av normal kostnad.
• OpenAI: automatiskt vid matchande prefix, cirka 50 % av normal kostnad, beroende på modell.
• Google: explicit cachelagrat innehåll, varierande pris.

Det första anropet med ett visst indataprefix har normal kostnad. Senare anrop inom cachefönstret, vanligtvis 5–60 minuter beroende på leverantör, återanvänder den cachelagrade representationen.

Praktisk implementering:

Strukturera prompterna med statiskt innehåll först och dynamiskt sist:

[CACHELAGRAT: 10 000 token]
- Systemprompt
- Verktygsbeskrivningar
- Användarens statiska profil
- Kunskapsbasutdrag som sannolikt inte ändras per anrop

[INTE CACHELAGRAT: 1 000 token]
- Samtalshistorik (ändras varje tur)
- Aktuell användarfråga

De första 10 000 token cachelagras efter första anropet. Senare anrop debiteras cirka 10 % för dem och fullt pris för 1 000 token.

Besparingsexempel:

Utan cache:

• 11 000 indatatoken × 3 euro/miljon = 0,033 euro per anrop.
• 100 000 anrop/dag = 3 300 euro/dag.

Med cache (90 % cachelagrad indata):

• 1 000 till fullt pris + 10 000 cachelagrade till 10 %:
• 1 000 × 3 euro/miljon + 10 000 × 0,30 euro/miljon = 0,003 + 0,003 = 0,006 euro per anrop.
• 100 000 anrop/dag = 600 euro/dag.

82 % besparing. Verkliga siffror från verkliga system.

Implementeringsdisciplin:

• Identifiera statiska och dynamiska delar.
• Lägg statiska delar först.
• Använd cachemarkörer där leverantören stöder explicit kontroll, exempelvis Anthropic.
• Mät cacheträffar. Observerbarheten ska visa träffkvoten. Om den är låg är promptstrukturen fel.

Detta ger högst avkastning. Implementera det först.

Metod 2: modellstyrning

Behandlas utförligt på annan plats. Kortfattat skickas olika begäranden till olika modeller beroende på komplexitet:

• 60 % till små modeller.
• 30 % till mellannivån.
• 10 % till frontlinjen.

Typisk besparing: 60–80 % jämfört med frontlinjemodell för allt.

Tillsammans med cachelagring blir besparingen mer än 90 % mot den naiva baslinjen.

Metod 3: kontrollera utdatalängden

Utdatatoken dominerar kostnaden i de flesta användningsfall. De kostar typiskt 4–6 gånger mer än indata, bestäms av modellen och prompten och är ofta fler än nödvändigt.

Strategier:

Explicita längdinstruktioner.

Svara med högst 100 ord.

Modeller följer detta relativt väl och utdatakostnaden sjunker betydligt.

Strukturerade utdata.

När svaret är korta strukturerade data, exempelvis JSON med bestämda fält, är mängden avgränsad och onödig utförlighet undviks.

Parametern max_tokens.

Ange den. Lämna inte standardvärdet. Om 200 token räcker, sätt max till 250 för liten marginal.

Formatbegränsningar.

”Endast punktlista” eller ”ett enda stycke” ger kortare svar än fri form.

Punkter i stället för prosa.

Punkter använder normalt hälften så många token för samma information.

Ingen inledning.

”Hoppa över inledningsfraser. Gå direkt till svaret.” Modeller börjar annars ofta med artigheter som slösar token.

Besparingsexempel:

Ett sammanfattningsflöde. Standardutdata: 500 token. Begränsat: 200 token.

• 500 token × 10 euro/miljon = 0,005 euro per anrop.
• 200 token × 10 euro/miljon = 0,002 euro per anrop.

60 % besparing på utdata. Mindre än cachens 90 %, men på den största kostnadsposten.

Metod 4: utdatasampling och tidigt stopp

I vissa fall behövs inte fullständiga LLM-utdata, bara ett beslut eller en klassificering.

Logprobs för klassificering.

# Använd en liten modell UTAN resonemang här: modeller i resonemangsfamiljer
# (GPT-5.x-tankenivåer och liknande) avvisar logprobs/logit_bias.
response = openai.chat.completions.create(
    model=SMALL_NON_REASONING_MODEL,
    messages=[{"role": "user", "content": prompt}],
    logprobs=True,
    top_logprobs=5,
    max_tokens=1
)
# Läs logprobs för första token för att fastställa sannolik kategori

Modellen ombeds avge en token, kategorin. Kostnaden är en indatapassering + 1 utdatatoken. Snabbare, billigare och ofta lika bra som längre svar.

Logitbias.

För utdata från en känd mängd kan logits viktas mot giltiga alternativ.

import tiktoken

enc = tiktoken.encoding_for_model("gpt-4o-mini")
# Nycklarna i logit_bias är token-ID:n (som strängar), inte ord.
bias = {str(enc.encode(w)[0]): 100 for w in (" yes", " no", " maybe")}

response = openai.chat.completions.create(
    model="gpt-4o-mini",
    messages=[...],
    logit_bias=bias,
    max_tokens=1,
)

Det styr modellen till rätt slags utdata och är billigt och tillförlitligt för klassificering.

Metod 5: batchning

Batcha när många poster ska bearbetas.

Asynkron batchning på API-nivå.

De flesta leverantörer har asynkrona eller batch-API:er som bearbetar flera begäranden billigare:

• OpenAI Batch API: 50 % rabatt, serviceåtagande på 24 timmar.
• Anthropic Message Batches: 50 % rabatt, serviceåtagande på 24 timmar.

Kör köarbete utan realtidskrav som batch. Halva kostnaden.

Batchning i prompten.

Bearbeta flera poster i ett LLM-anrop när det går.

I stället för:

[10 separata anrop som klassificerar ett ärende vardera]

Gör:

[1 anrop som klassificerar 10 ärenden i en prompt]

Det enskilda anropet har mer indata men bara en uppsättning fast overhead. Totalt används färre token än vid tio separata anrop.

Kvaliteten kan sjunka med för många poster. Testa optimal punkt; vanligtvis fungerar 5–20 poster per prompt.

Metod 6: mindre modeller för smala uppgifter

Överväg utöver normal styrning om uppgiften verkligen kräver en stor modell.

Klassificering: en liten modell är ofta lika bra som en frontlinjemodell för enkel klassificering. Enligt aktuella listpriser, kontrollerade 2026-07-07, kostar Claude Haiku 4.5 1/5 dollar per miljon in-/utdatatoken mot Claude Opus 4.8 på 5/25 dollar: en rak femfaldig besparing. OpenAI:s lilla nivå mot GPT-5.5 ger en liknande multipel.

Extraktion: modeller på mellannivån fungerar för strukturerad extraktion. Spara frontlinjen för fall som misslyckas.

Översättning: specialiserade översättningsmodeller eller mindre LLM:er hanterar de flesta fall.

Inbäddning: använd specialiserade inbäddningsmodeller, inte generella LLM:er.

Identifiera enkla, smala arbetslaster och styr dem till minsta modell som klarar uppgiften tillräckligt bra. Spara frontlinjen för komplext arbete med stora bedömningskrav.

Metod 7: finjusterade små modeller

Finjustera en liten modell för smala uppgifter med mycket hög volym.

Exempel: 100 000 klassificeringsbegäranden/dag.

• Omodifierad GPT-5: 30 euro/dag i API-kostnad.
• Finjusterad 8B-modell på dedikerad inferens: 5–10 euro/dag plus engångskostnad för finjustering.

Vid tillräcklig volym betalar små finjusterade modeller snabbt tillbaka sig. Kalkylen beror på volymen.

Principen från artikeln om finjustering är att finjustering blir en kostnadshävstång när skala och smalt omfång sammanfaller.

Metod 8: förfiltrering

I LLM-flöden med flera steg fångar billig filtrering upp uppenbara fall före dyr bearbetning.

Exempel: klassificering och svar i kundsupport.

Billigt förfilter:

• ”Är detta en verklig supportfråga eller skräppost/brus?” (klassificering med en token på liten modell.)
• ”Är detta en känd vanlig fråga?” (billig inbäddningssökning.)

Endast begäranden som passerar filtret når den dyra svarsgenereringen.

Om 30 % är brus eller kan besvaras med vanliga frågor elimineras 30 % av de dyra anropen. Förfiltret kostar 0,0001 euro per anrop mot svarsgenereringens 0,05 euro. Enkel avkastning.

Metod 9: cachelagring utöver promptcache

Cachelagring på applikationsnivå:

Svarscache. Samma fråga, kontext och svar returneras utan modellanrop.

def cached_call(prompt, model, ttl=3600):
    cache_key = hash(prompt + model)
    cached = redis.get(cache_key)
    if cached:
        return cached
    response = call_llm(prompt, model)
    redis.set(cache_key, response, ttl=ttl)
    return response

För idempotenta frågor elimineras dubblettanrop helt.

Inbäddningscache. Beräknade inbäddningar cachelagras.

Cache för hämtningsresultat. Sökresultat cachelagras kortvarigt.

Cache för verktygsresultat. Verktygsresultat cachelagras om underliggande data sällan ändras.

Cachelagren staplas och sparar anrop på varje nivå.

Metod 10: spekulativ exekvering

För latenskänsliga flöden där nästa steg kan förutses kan anrop göras spekulativt.

Exempel: i en kundsupportagent är nästa steg efter kundens beskrivning vanligtvis att sammanfatta problemet. Starta sammanfattningen parallellt med att kunden får en bekräftelse.

Vid rätt förutsägelse är svaret klart när det behövs. Vid fel förutsägelse slösas ett anrop.

Detta optimerar främst latens, inte kostnad, men förbättrar användarupplevelsen avsevärt i vissa flöden.

Metod 11: arbitrage mellan leverantörer

Olika leverantörer tar olika pris för likvärdiga modeller. Utnyttja det.

Öppna modeller hos billiga inferensleverantörer.

Llama 3.3 70B hos Together AI: 0,88 dollar/miljon in- och utdatatoken (listpris, kontrollerat 2026-07-07). Den slutna nivå den konkurrerar med, Claude Sonnet 5: 3/15 dollar per miljon (introduktionspris 2/10 dollar till 2026-08-31).

När en öppen 70B räcker är det cirka 3,4 gånger billigare för indata och 17 gånger för utdata, alltså 3–17 gånger beroende på blandningen.

Samma modell hos olika leverantörer.

Vissa öppna modeller finns hos flera leverantörer till olika pris. Jämför.

Egen drift i skala.

Vid tillräcklig volym, säg över 10 000 euro/månad för en viss modell, blir egen drift billigare än API-anrop. Det kräver operativ kapacitet.

Arbitrage medför komplexitet: styrning och reserv mellan leverantörer samt kvalitetstest av varje variant. Värt det i skala.

Metod 12: inferensacceleration

För egen drift kan själva inferenslagret optimeras:

vLLM, TGI, SGLang. Optimerade inferensservrar med 2–10 gånger högre genomströmning än naiva implementationer.

Kvantisering. Modeller körs med lägre precision, 4 eller 8 bitar. 2–4 gånger högre genomströmning med måttlig kvalitetskostnad.

Flash Attention, paged attention. Arkitekturoptimeringar i moderna servrar.

Kontinuerlig batchning. Servrar batchar pågående begäranden för bättre GPU-utnyttjande.

Detta är relevant för egen drift i skala. API-leverantören sköter det annars.

Metod 13: strömning

Strömning minskar inte antalet token men förbättrar användarupplevelsen och därmed uppfattningen av kostnadseffektivitet.

Vid långa svar ser användaren innehållet omedelbart och kan läsa medan genereringen fortsätter. Det känns mycket snabbare än att vänta på hela svaret.

För agenter ger strömmade mellansteg insyn i förloppet.

Alla moderna API:er stöder strömning. Använd den i användarflöden.

Metod 14: budgetspärrar

Inför hårda budgetar för att förhindra skenande kostnader:

Per begäran. Högsta antal token; stoppa vid gränsen.

Per användare. Dagligt eller månatligt kostnadstak; begränsa nära gränsen.

Per funktion. Varje funktion har en budget och stängs automatiskt av vid tio gånger dagsgenomsnittet.

Global budget. Total dags- eller månadsgräns; pausa oväsentligt arbete nära gränsen.

De sparar inte pengar direkt men förebygger katastrofer. En enda bugg eller attack kan snabbt blåsa upp kostnaden.

Exempel: en verklig kostnadsminskning

Ett team med AI-kundsupport hade en faktura på 12 000 euro/månad. Sex månader senare var den 1 800 euro/månad, en minskning med 85 %.

Ändringarna:

1. Promptcache. Prompterna omstrukturerades för största möjliga statiska prefix. Cirka 70 % av indata cachelagras. Besparing cirka 30 %.
2. Modellstyrning. Klassificering och ärendetriage flyttades från Claude Sonnet till Claude Haiku. Besparing cirka 15 %.
3. Kontroll av utdatalängd. Svaren begränsades till 250 ord från tidigare 800–1 500. Besparing cirka 25 %.
4. Förfiltrering. Billig klassificering hittar ärenden som kan besvaras från cache för vanliga frågor. Cirka 20 % försvann ur det dyra flödet. Besparing cirka 10 %.
5. Svarscache för vanliga frågor. Identiska frågor returnerar cachelagrade svar. Besparing cirka 5 %.

Procentsatserna är varje metods andel av den slutliga minskningen. De summerar till cirka 85 % och mättes var och en mot fakturan som återstod efter föregående ändring; de är inte oberoende multiplikatorer som kan appliceras på en annan faktura.

Kvaliteten var oförändrad eller något bättre enligt kundnöjdhet, svarskorrekthet och lösningsgrad.

Driftskostnad: cirka 80 ingenjörstimmar under tre månader. Investeringen betalade sig på två veckor.

Vanliga misstag

Några mönster vi ser:

Misstag 1: ingen kostnadsmätning. Ingen insyn i vad varje funktion, användare eller anrop kostar. Optimering är omöjlig utan mätning.

Misstag 2: fel sak optimeras. Veckor läggs på 5 % färre indatatoken när utdata står för 80 % av fakturan. Mät först och optimera största bidraget.

Misstag 3: kvalitetsregressioner. Kostnadssänkningar lanseras utan kvalitetsövervakning. Pengar sparas, användare förloras. Para alltid kostnadsarbete med utvärderingssviter.

Misstag 4: överdriven styrning. Små modeller får uppgifter de inte klarar. Skenbesparing.

Misstag 5: cacheförorening. Cachen fylls med sällsynta frågor som bara används en gång. Missar dominerar. En bättre strategi behövs.

Misstag 6: batch-API hoppas över. Realtid används när batch räcker. Halva priset lämnas på bordet.

Misstag 7: överkonstruktion. Avancerad kostnadsoptimering byggs för funktioner som ändå inte är lönsamma. Ibland ska funktionen avvecklas.

Misstag 8: inga budgetspärrar. En bugg skenar och blir katastrof i stället för mindre olägenhet.

Den kulturella delen

Kostnadsdisciplin är delvis kulturell. Framgångsrika team:

• Behandlar kostnad som mätetal, inte eftertanke.
• Har en ansvarig, ofta i gränssnittet mellan teknik och ekonomi.
• Granskar kostnaden bland veckomåtten.
• Utreder toppar omedelbart.
• Sätter budget per funktion och larmar vid gränser.
• Gör avvägningar mellan kostnad, kvalitet och latens explicita.

Övriga team:

• Ser kostnaden som någon annans problem.
• Upptäcker fakturan i slutet av månaden.
• Reagerar på toppar i efterhand.
• Saknar budgetbegrepp.
• Hoppar över avvägningen och optimerar en dimension i taget.

Kulturell förändring är svårare än teknisk, men får de tekniska ändringarna att bestå.

Prisutvecklingen

En notering om den bredare trenden.

Kostnaden per enhet kapacitet har fallit kraftigt år för år, främst eftersom mindre modeller når gårdagens frontlinjenivå, inte för att frontlinjens listpriser rasar. Behandla alla prognoser för ”priset om ett år” som modellerade antaganden och kontrollera modell- och prisreferensen igen innan de citeras.

Det innebär:

• Vissa optimeringar får mindre betydelse med tiden när den absoluta kostnaden ändå sjunker.
• Vissa i dag olönsamma arbetslaster blir lönsamma.
• Bygg långsiktigt: ren arkitektur är viktigare än att pressa varje cent nu.

Optimering spelar ändå roll. Ineffektiva system slösar vid alla prisnivåer, och konkurrensfördelen går ofta till team med effektivare drift och lägre kostnad.

En 90-dagarsplan för kostnadsoptimering

För ett team vars AI-funktion kostar mer än väntat:

Vecka 1–2: Mät.

• Instrumentera kostnad per anrop.
• Bygg instrumentpaneler per funktion och användare.
• Identifiera största kostnadsbidragen.

Vecka 3–4: Snabba vinster.

• Aktivera promptcache där den stöds.
• Strukturera om de tre främsta prompterna för högsta träffkvot.
• Ange max_tokens för alla anrop.
• Inför budgetlarm.

Vecka 5–6: Styrning.

• Hitta enkla uppgifter som körs på frontlinjemodell.
• Bygg styrning för de 3–5 mest anropade slutpunkterna.
• Testa kvalitetsregression.

Vecka 7–8: Utdata och cache.

• Begränsa utdatalängden där den inte visas för användaren.
• Lägg till svarscache för vanliga frågor.
• Lägg till förfilter för flöden med högst volym.

Vecka 9–10: Avancerat.

• Batch-API för arbete utan realtidskrav.
• Utvärdera alternativa leverantörer.
• Cache för inbäddning och hämtning.

Vecka 11–12: Härdning.

• Budgetspärrar för varje funktion.
• Kostnadsinstrumentpaneler i ordinarie teamgranskning.
• Dokumentera mönstren för framtida funktioner.

Efter 90 dagar är en kostnadsminskning på 50–80 % realistisk, med övervakad kvalitet och inbyggd disciplin.

Mät först och multiplicera sedan besparingarna

LLM-kostnader kan vanligtvis minskas med 60–90 % utan kvalitetsförlust. Metoderna är välkända: cachelagring, styrning, kontroll av utdata, batchning, förfiltrering, svarscache, modellval och budgetspärrar.

Var för sig sparar de måttligt. Tillsammans ger de dramatiska besparingar.

Team som gör rätt omvandlar olönsamma AI-funktioner till lönsamma. De som inte gör det tvingas till slut avveckla funktioner som borde ha varit livskraftiga.

Mät först. Optimera de största bidragen. Behåll kvalitetsövervakningen. Bygg in kostnadsdisciplin i teamets ordinarie arbete.

Resultatet är AI-funktioner som skalar ekonomiskt, inte bara tekniskt. Det gör AI till en hållbar del av produkten och inte bara en lanseringsrubrik.