Inferenskostnaden beror på arbetsbelastningen: modell och region, ej cachelagrade och cachelagrade indata, genererade token och resonemangstoken, verktyg, omförsök, samtidiga anrop, lagring och mänsklig granskning spelar alla roll. Börja med fakturerad användning och mätspår i stället för branschens påståenden om besparingar.
Aktuella priser och cacheregler ändras ofta. Kontrollera de officiella prissidorna för OpenAI, Anthropic och Gemini innan du använder en kostnadsmodell.
Den här artikeln behandlar teknikerna, beräkningarna och produktionsdisciplinen. Vi utgår från att du redan har infört grundläggande modellrouting (som behandlas i Orkestrering av flera modeller); här går vi djupare.
Kostnadsstrukturen
LLM-kostnader kommer från:
- Indatatoken. Det du skickar till modellen, inklusive systemprompt, kontext och användarens förfrågan.
- Utdatatoken. Det modellen returnerar. Förhållandet mellan priserna för in- och utdata varierar beroende på leverantör, modell, batchläge och cachestatus.
- Kostnader för resonemang eller dold beräkning. Leverantörernas rapportering och fakturering varierar; använd fälten för fakturerad användning och den aktuella prislistan i stället för att anta att dold beräkning motsvarar synlig utdata.
- Verktygsdefinitioner och verktygsanvändning. Scheman kan lägga till indatatoken, medan leverantörshanterade verktyg och externa tjänster kan ha separata avgifter.
- Omförsök och misslyckat arbete. Vissa misslyckade eller avbrutna anrop medför användning; klassificera felpunkterna utifrån leverantörens fakturering och mätspår.
Du kan optimera på varje nivå.
Teknik 1: Promptcachning
Cachning kan ge betydande besparingar när anrop delar ett prefix som får cachelagras och arbetsbelastningen ger hög träffrekvens.
Läs varje leverantörs aktuella dokumentation om cachning för minsta prefixstorlek, skriv- och läsavgifter, giltighetstid, routingbegränsningar och observerbarhet.
I stora drag kan ett upprepat prefix som uppfyller kraven återanvändas inom ett fönster som leverantören definierar. De exakta reglerna kan inte överföras mellan leverantörer.
Praktisk implementering:
Strukturera dina prompter så att statiskt innehåll kommer först och dynamiskt innehåll sist:
[CACHED: 10K tokens]
- Systemprompt
- Verktygsbeskrivningar
- Användarens statiska profil
- Kunskapsbassnuttar som sannolikt inte ändras per anrop
[NOT CACHED: 1K tokens]
- Samtalshistorik (ändras vid varje vändning)
- Nuvarande användarförfrågan
Huruvida detta prefix är giltigt och hur det faktureras beror på den valda modellen och leverantören.
Kostnadsformel:
daily cost = calls × (uncached input × input rate + cache writes × write rate + cache reads × read rate + output × output rate + tool charges)
Fyll i formeln med fakturerade tokenantal och den aktuella prislistan. Jämför motsvarande tidsfönster och inkludera cachemissar.
Implementeringsdisciplin:
- Identifiera statiska respektive dynamiska delar av prompterna.
- Placera de statiska delarna först.
- Använd cachemarkörer där leverantören stödjer dem (Anthropic) för uttrycklig kontroll.
- Testa cacheträffar — observerbarheten bör visa träffrekvensen. Om den är låg är promptstrukturen fel.
Prioritera cachning endast när mätspåren visar att upprepade indata som får cachelagras är en dominerande kostnadspost.
Teknik 2: Modellrouting
Behandlas i detalj någon annanstans. Kort sagt: olika begäranden skickas till olika modeller baserat på komplexitet.
Bygg en etiketterad utvärderingsmängd för modellrouting, jämför kandidaternas kvalitet och kostnad och behåll en reservväg för osäkra eller misslyckade fall. Den resulterande routingen är specifik för arbetsbelastningen.
Teknik 3: Styrning av utdatalängd
Utdatatoken kan vara en dominerande kostnadspost. Bekräfta detta i användningsdata innan du optimerar svaret.
Strategier:
Explicita längdinstruktioner.
Svara på högst 100 ord.
Modeller kan fortfarande bryta mot en textbaserad längdinstruktion. Upprätthåll och utvärdera gränsen, och rapportera den uppmätta förändringen i tokenantal och kvalitet snarare än att lova betydande besparingar.
Strukturerade utdata.
När det önskade svaret är korta strukturerade data kan ett strikt schema minska mängden irrelevant text. Det eliminerar inte ogiltiga utdata, för stora fältvärden, omförsök eller risken för avkapning; validera varje resultat.
Leverantörens gräns för utdatatoken.
Ställ in API:ets aktuella gräns för utdatatoken utifrån uppmätta behov och lämna tillräcklig marginal för ett fullständigt, giltigt svar. Parameternamn och semantik skiljer sig mellan API:er och modeller; en alltför låg gräns kan kapa strukturerade utdata och orsaka fler anrop.
Formatbegränsningar.
“Endast punktlistor” eller “ett enda stycke” kan ge kortare utdata än ett fritt format.
Punktlistor framför löpande text.
Punkter kan minska sammanhängande text för vissa svar. Mät tokenantal; en långdragen punktlista kan vara längre än ett koncist stycke.
Ingen inledning.
“Hoppa över inledande fraser. Kom direkt till svaret.” Modeller börjar ofta med “Bra fråga…” eller “Låt mig förklara…” — slösade tokens.
Mätningsexempel:
Jämför standardutdata med begränsade utdata för samma dokument i ett sammanfattningsflöde. Rapportera fakturerade utdatatoken, täckning av relevanta fakta, läsbarhet, användarnas frekvens av följdfrågor och eventuell avkapning. Ett lägre tokenantal är ingen besparing om användarna måste göra ytterligare ett anrop.
Teknik 4: Sampling av utdata och tidigt stopp
För vissa användningsfall behöver du inte fullständiga LLM-svar — du behöver ett beslut eller en klassificering.
Logprobs för klassificering.
# Use only a model and API operation whose current documentation supports
# log probabilities; support varies by model and endpoint.
response = openai.chat.completions.create(
model=SMALL_NON_REASONING_MODEL,
messages=[{"role": "user", "content": prompt}],
logprobs=True,
top_logprobs=5,
max_tokens=1
)
# Read logprobs of first token to determine likely category
Detta ber en kompatibel modell att returnera en kort etikett. Bekräfta att det valda API:t stöder logprobs, att etiketterna motsvarar tydliga token och att klassificeringskvaliteten uppfyller målet.
Begränsade etiketter eller logit bias.
För kända uppsättningar av utdata bör du använda en dokumenterad enum- eller schemabegränsning där sådan finns. Logit bias påverkar valet av token men är specifik för tokeniseraren och modellen.
response = openai.chat.completions.create(
model=COMPATIBLE_MODEL,
messages=[...],
# If used, build logit_bias from every tokenization variant you intend
# to accept; do not assume a class label is exactly one token.
logit_bias=VALIDATED_TOKEN_BIAS,
max_tokens=1,
)
Logit bias påverkar valet av token; den framtvingar inte en giltig klass och bevisar inte att klassificeringen är tillförlitlig. Validera och avvisa oväntade utdata.
Teknik 5: Batchning
När du bearbetar många objekt ska du batcha dem.
Asynkron batchning på API-nivå.
Vissa leverantörer stödjer asynkrona eller batchprodukter, ibland med olika priser, slutförandefönster, gränser och villkor för datahantering.
- Både OpenAI och Anthropic dokumenterar sina asynkrona batchprodukter. Kontrollera aktuell rabatt, slutförandefönster, gränser och villkor för datahantering på deras officiella prissättnings- och batchesidor.
Om bakgrundsarbete inte kräver ett interaktivt svar ska du jämföra aktuell batchprissättning och aktuellt beteende med den synkrona vägen.
Batchning i prompten.
Bearbeta flera objekt i ett LLM-anrop när det är möjligt.
I stället för:
[10 separata anrop, vart och ett för klassificering av ett ärende]
Gör så här:
[1 anrop, klassificering av 10 ärenden i en prompt]
Det enskilda anropet innehåller indata för fler objekt men kan återanvända samma fasta promptkostnader. Det kan minska det totala antalet token för vissa arbetsbelastningar; avgränsare, längre utdata, omförsök och fel på batchnivå kan dock upphäva besparingen.
Varning: batchning kan påverka kvalitet, ordning, avkapning och felisolering. Testa olika batchstorlekar med representativa indata i stället för att anta ett universellt intervall.
Teknik 6: Mindre modeller för smala uppgifter
Utöver vanlig routning bör du överväga om en uppgift verkligen behöver en stor modell.
Klassificering: Utvärdera en mindre modellnivå mot den nuvarande produktionsmodellen med etiketterade exempel, inklusive sällsynta klasser och möjligheten att avstå. Använd aktuella leverantörspriser i kostnadsjämförelsen.
Extraktion: Jämför mindre modeller, mellannivåer samt deterministiska och hybrida extraherare utifrån noggrannhet på fältnivå, undantagshantering, latens och kostnad. Eskalera fall enligt testade regler.
Översättning: Utvärdera specialiserade översättningssystem och olika LLM-nivåer för de faktiska språkparen, terminologin, formateringen, säkerheten och kraven på mänsklig granskning. Dra inte slutsatser om täckningen från sammanvägda benchmarkresultat.
Inbäddningar: Använd modeller som är specialiserade på inbäddningar, inte generella LLM:er.
Mönstret är att identifiera de enkla och avgränsade arbetsbelastningarna och styra dem till den minsta modellen som klarar uppgiften tillräckligt bra. Använd flaggskeppsmodellen för komplext arbete som kräver omdöme.
Teknik 7: Finjusterade små modeller
Vid mycket hög volym för en specifik uppgift kan en finjusterad liten modell vara ett alternativ.
För en arbetsbelastning med hög klassificeringsvolym bör du jämföra en promptstyrd liten modell, en finjusterad modell, deterministiska regler och en hybrid. Inkludera tränings- och utvärderingsdata, inferensdrift, outnyttjad kapacitet, övervakning, behov av omträning och utvecklingskostnad. Finjustering är ekonomiskt försvarbar endast om den uppmätta kvalitets- och kostnadskurvan motiverar den.
Detta behandlas i Finjustering 2026. Principen är att finjustering kan bli en kostnadshävstång när hög skala sammanfaller med en snävt avgränsad uppgift.
Teknik 8: Förfiltrering
I LLM-arbetsflöden med flera steg kan billig förfiltrering fånga upp uppenbara fall före dyr bearbetning.
Exempel: klassificering av kundsupportfrågor + svar.
Billig förfiltrering:
- “Är detta en faktisk supportfråga eller spam/brus?” (klassificering med 1 token på en liten modell.)
- “Finns detta redan bland våra vanliga frågor?” (sökning med inbäddningar; billig.)
Endast förfrågningar som passerar filtret når den dyra svarsgenereringen.
Mät vilken andel av trafiken förfiltret kan hantera med den precision som krävs. Falska positiva resultat kan undertrycka giltiga förfrågningar, så kostnadsbesparingarna måste utvärderas tillsammans med kvaliteten och påverkan på eskaleringar.
Teknik 9: Cachning utöver promptcachning
Utöver modelleverantörens promptcachning finns cachning på applikationsnivå:
Svarscachning. Inom en godkänd omfattning och med en fullständig uppsättning indata som påverkar svaret kan ett tidigare svar återanvändas när dess aktualitet och semantik fortfarande är giltiga. Icke-determinism innebär att detta är ett produktbeslut, inte en matematisk identitet.
import hashlib
import json
def stable_sha256(value):
payload = json.dumps(value, sort_keys=True, separators=(",", ":"))
return "llm:" + hashlib.sha256(payload.encode("utf-8")).hexdigest()
def cached_call(scope, prompt_version, prompt, model, params, ttl=3600):
# Canonicalize all response-affecting inputs and include tenant/user scope
# where a shared answer is not explicitly safe. Use a stable cryptographic
# digest rather than the process-randomized built-in hash().
cache_key = stable_sha256({
"scope": scope,
"prompt_version": prompt_version,
"prompt": prompt,
"model": model,
"params": params,
})
cached = redis.get(cache_key)
if cached:
return json.loads(cached.decode("utf-8"))
response = call_llm(prompt, model, params)
redis.set(cache_key, json.dumps(response), ex=ttl)
return response
För förfrågningar som lämpar sig för detta och är tillräckligt deterministiska kan en cacheträff undvika upprepade anrop. Definiera aktualitet och ogiltigförklaring, isolera olika omfattningar, förhindra att samtidiga cachemissar överbelastar källan och cacha inte känsliga eller personaliserade utdata utan godkännande.
Cachning av inbäddningar. Cacha beräknade inbäddningar.
Cachning av hämtningsresultat. Cacha sökresultat för en fråga under korta perioder.
Cachning av verktygsresultat. Cacha resultat från verktygsanrop om underliggande data inte ändras ofta.
Cachelager kan kombineras. Varje lager kan spara anrop.
Teknik 10: Spekulativ exekvering (latensavvägning, ingen kostnadsbesparing)
För latenskänsliga flöden där nästa steg kan förutsägas kan du göra ett spekulativt förhandsanrop.
Exempel: kundsupportagent. Du vet att nästa steg vanligtvis är “sammanfatta problemet” efter att kunden beskrivit det. Starta den sammanfattningen parallellt med att visa bekräftelse till användaren.
Om förutsägelsen är rätt är svaret redo när det behövs. Om den är fel slösar du ett anrop.
Detta förbrukar avsiktligt resurser som kan behöva kasseras och kan därför öka kostnaden. Använd tekniken endast när den uppmätta latensvinsten motiverar kostnaden, avbrott och bieffekter är kontrollerade och den spekulativa förfrågan inte kan exponera eller ändra data som förfrågan saknar behörighet till.
Teknik 11: Jämförelse av leverantörer
Leverantörer skiljer sig i pris, kapacitet, regioner, kvoter, datavillkor, tillförlitlighet och modellimplementation. Jämför kandidater med likvärdig kvalitet under samma antaganden om arbetsbelastning och avtal.
Modeller med öppna vikter hos leverantörer av hanterad inferens.
Jämför aktuella leverantörspriser först när modellen har klarat utvärderingen för samma arbetsbelastning. Liknande parameterstorlek eller marknadsföringsnivå garanterar inte likvärdig kvalitet.
Samma modell hos olika leverantörer.
Vissa modeller med öppna vikter erbjuds av flera leverantörer. Genomför benchmarktester på exakt version, kvantisering, serverkonfiguration och API-beteende; samma modellnamn garanterar inte identiska utdata eller samma prestanda.
Egen drift i stor skala.
Egen drift kan bli billigare vid en arbetsbelastningsspecifik utnyttjandegrad. Räkna med GPU-timmar för modellen, repliker, reserv- och toppkapacitet, nätverk, observerbarhet, uppgraderingar, säkerhet, incidenthantering och utvecklingsansvar.
Routing mellan flera leverantörer ökar komplexiteten i integration, utvärdering, säkerhet, upphandling, observerbarhet och felhantering. Inför det endast när den uppmätta motståndskraften eller ekonomiska nyttan överstiger dessa ägandekostnader.
Teknik 12: Inferensacceleration
För egen drift: optimering av inferenslagret i sig.
vLLM, TGI, SGLang. Inferensservrar med olika modelltäckning och optimeringsvägar. Benchmarktesta de versioner som stöds på målhårdvaran.
Kvantisering. Lägre precision kan minska minnesbehovet eller förbättra genomströmningen, med kvalitetseffekter som beror på uppgift och metod. Benchmarktesta den exakta artefakten och konfigurationen för inferensservering.
Flash Attention, paged attention. Arkitektoniska optimeringar som aktiveras i moderna servrar.
Kontinuerlig batchning. Servrar som grupperar pågående förfrågningar för bättre GPU-utnyttjande.
För team som driver egen drift i skala spelar detta roll. För team som använder API:er hanterar leverantören det.
Teknik 13: Strömning
Strömning minskar inte antalet token men kan förbättra användarupplevelsen genom att minska den upplevda väntetiden.
För längre utdata ser användarna innehåll som visas omedelbart. De kan läsa med medan genereringen pågår. Det känns mycket snabbare än att vänta på hela svaret.
För agenter kan godkända förloppshändelser eller statussammanfattningar strömmas. Exponera inte privata resonemang, hemligheter, ogranskade verktygsargument eller data från andra klienter som “mellanliggande steg”.
Implementering: om det valda API:t och modellen stöder strömning ska den testas i de aktuella användarflödena. Strömning ändrar den upplevda latensen, inte nödvändigtvis den totala kostnaden eller slutförandetiden.
Teknik 14: Budgetgränser
Utöver optimering bör du införa fasta budgetgränser för att förhindra okontrollerade kostnader.
Budget per begäran. Maximalt antal tokens per begäran. Stoppa om gränsen överskrids.
Budget per användare. Daglig eller månatlig kostnadsgräns per användare. Begränsa flödet när du närmar dig gränsen.
Budget per funktion. Varje funktion har en tilldelad budget och ett testat svar när en tröskel som är anpassad till arbetsbelastningen överskrids.
Global budget. Total daglig eller månatlig gräns. Pausa icke nödvändig bearbetning när gränsen närmar sig.
Dessa kontroller garanterar inte besparingar. De begränsar eller omdirigerar utgifter och kan också minska tillgängligheten. Testa därför aviseringar, hastighetsbegränsning, nedgradering, köbildning och kretsbrytarens beteende för både nödvändiga och icke nödvändiga arbetsbelastningar.
En mall för experiment med kostnadsminskning
Presentera inte ett sammanvägt resultat som om det vore ett kundutfall. Fastställ en basperiod för faktureringen i ett produktionsflöde och tillämpa en ändring i taget:
Ändringarna:
-
Promptcachning. Registrera berättigade prefixtoken, träffrekvens, skrivningar till och läsningar från cachen, latens och fakturerad kostnad.
-
Modellrouting. Registrera fördelningen av rutter, kvalitet per rutt, reservvägar, latens och kostnad.
-
Kontroll av utdatalängd. Registrera utdatalängd, svarskvalitet, användarnas nya prompter och kostnad.
-
Förfiltrering. Registrera precision, täckning (recall), eskaleringar, undertryckta giltiga förfrågningar och undvikna anrop.
-
Svarscachning för vanliga frågor. Registrera regler för semantisk ekvivalens, aktualitet, ogiltigförklaring, träffrekvens och svarskvalitet.
Rapportera brutto- och nettobesparingar, utvärderingsresultat, ingenjörstid, nya driftkostnader och osäkerhetsintervall där data och metod stödjer det. Påstå inte oförändrad kvalitet om inte utvärderingsdesignen kan upptäcka meningsfulla regressioner.
Vanliga misstag
Mönster att leta efter i dina egna mätspår:
Misstag 1: Ingen kostnadsspårning. Teamet har ingen insyn i vad varje funktion, användare eller anrop kostar. Optimering är omöjlig utan mätning.
Misstag 2: Optimera fel sak. Teamet lägger veckor på att minska indatatoken med 5 % när utdatatoken står för 80 % av fakturan. Mät först och optimera de största kostnadsposterna.
Misstag 3: Kvalitetsregressioner. Kostnadsändringar driftsattes utan kvalitetsövervakning. Pengar sparades, men användare lämnade tjänsten. Para alltid kostnadsarbete med utvärderingsmängder.
Misstag 4: Överdriven routing. Aggressiv routing till små modeller för uppgifter som de egentligen inte klarar. Besparingen är falsk.
Misstag 5: Cacheförorening. Cachen fylls med sällsynta frågor. De flesta cacheposter används bara en gång och cachemissarna dominerar. En bättre cachestrategi behövs.
Misstag 6: Hoppa över batchutvärdering. Realtidsbearbetning används för arbete som skulle kunna tolerera leverantörens nuvarande batchfönster och begränsningar.
Misstag 7: Överkonstruerad lösning. Teamet bygger komplex kostnadsoptimering ovanpå funktioner som ändå inte är lönsamma. Ibland är det rätt att lägga ned funktionen.
Misstag 8: Inga budgetgränser. En enda bugg kan leda till okontrollerade kostnader. Följden blir en katastrof, inte bara ett mindre besvär.
Driftspraxis
Rekommenderade driftspraxis:
- Se kostnad som ett mätvärde, inte något man tänker på i efterhand.
- Tilldela en ägare med ansvar inom både teknik och ekonomi.
- Granska kostnader med intervall som är anpassade till kostnadsvariationer och affärsrisk.
- Prioritera kostnadstoppar utifrån definierade tröskelvärden och åtgärdsplaner.
- Ställ in budgetar per funktion; varna vid överskridande av trösklar.
- Gör avvägningar tydliga (kostnad kontra kvalitet kontra latens).
Kontrolluckor att leta efter:
- Ingen namngiven kostnadsägare.
- Fakturering upptäcks först när beslutsfönstret har passerat.
- Aviseringar utan ansvarig eller åtgärdsplan.
- Ingen godkänd budget eller prognosram.
- Avvägningarna diskuteras inte; en dimension optimeras i taget.
Detta är styrningsval som ska verifieras genom ägarregister, deltagande i granskningar, hanterade aviseringar och slutförda kostnadsåtgärder, inte ett påstående om teamkultur.
Förändringar i priser och kapacitet
En anmärkning om den bredare trenden.
Leverantörspriser, modellkapacitet, batchprodukter, cacheregler och avgifter för leverantörshanterade verktyg ändras enligt leverantörernas scheman. Artikeln fastställer ingen universell historisk trend eller prognos.
Kör kostnads- och kvalitetsmodellen på nytt efter väsentliga förändringar i pris, modell, avtal eller arbetsbelastning. Anta inte att ett arbetsflöde som för närvarande är olönsamt kommer att bli lönsamt, eller att framtida sänkningar av listpriser räddar en ineffektiv design.
En illustrativ sekvens för kostnadsoptimering under tolv veckor
För ett team som startar med utgångspunkten “vi har en AI-funktion, men kostnaderna är högre än väntat” är följande sekvens ett planeringsexempel. Justera varaktighet och stoppvillkor så att de matchar arbetsbelastning, underlag och operativ kapacitet.
Vecka 1–2: Mät.
- Instrumentera kostnader per anrop.
- Bygg instrumentpaneler per funktion och användare.
- Identifiera de största kostnadsposterna.
Vecka 3–4: Snabba vinster.
- Testa promptcachning endast där mätspår visar upprepade prefix som får cachelagras och leverantörens aktuella regler tillåter det.
- Strukturera om de dyraste giltiga prompterna och mät sedan cacheträffsfrekvens, latens, kvalitet och fakturerad kostnad.
- Ställ in varje API:s aktuella gräns för utdata endast där uppmätta behov motiverar det; testa avkapning och omförsök.
- Implementera budgetaviseringar.
Vecka 5–6: Routing.
- Identifiera enkla uppgifter som för närvarande körs på flaggskeppsmodeller.
- Bygg en router för de 3–5 mest anropade API-slutpunkterna.
- Testa för kvalitetsregression.
Vecka 7–8: Utdata och cachning.
- Begränsa utdatalängder där utdata inte visas för användaren.
- Lägg till svarscachning på applikationsnivå för vanliga frågor.
- Lägg till förfilter i flödena med högst volym.
Vecka 9–10: Avancerat.
- Batch-API för arbete som inte kräver realtid.
- Utvärdera alternativ bland leverantörer.
- Cachning av inbäddningar och hämtningsresultat.
Vecka 11–12: Stabilisering.
- Budgetgränser på varje funktion.
- Kostnadsinstrumentpaneler i regelbundna teamgenomgångar.
- Dokumentation av mönster för framtida funktioner.
I slutet av förbättringscykeln publicerar du den uppmätta kostnadsförändringen och underlaget för kvaliteten. En tidplan garanterar ingen viss besparingsprocent.
Mät först, kombinera sedan besparingarna
LLM-kostnader kan ofta minskas, men den procentuella effekten och kvalitetspåverkan är specifika för arbetsbelastningen. Möjliga tekniker är cachning, routing, kontroll av utdata, batchning, förfiltrering, svarscachning, modellval och budgetgränser.
Tillämpa ändringarna sekventiellt så att deras effekter går att härleda; samverkan mellan ändringarna kan förstärka, överlappa eller upphäva effekterna.
Använd nettobidraget efter inferens, verktyg, mänsklig granskning, infrastruktur, underhåll och support för att avgöra om funktionen är ekonomiskt hållbar.
Mät först. Optimera de största kostnadsdrivarna. Upprätthåll kvalitetsövervakning. Bygg in kostnadsdisciplin i teamets löpande arbete.
Resultatet är AI-funktioner som skalar ekonomiskt, inte bara tekniskt. Det är det som gör AI till en hållbar del av produkten, inte bara en nyhet vid lanseringen.
