Omkostningsoptimering af inferens: promptcaching, routing og outputkontrol

I midten af 2026, ser vi overbetaling for inferens som den mest almindelige AI-arkitekturfejl i produktion. Teams lancerer LLM-funktioner, ser dem virke og modtager derefter månedlige regninger på fem cifre, som vokser med brugen. Nogle funktioner bliver urentable. Nogle virksomheder fjerner funktioner, som ville have været levedygtige med bedre omkostningsdisciplin.

De fleste LLM-regninger er væsentligt større end nødvendigt. Besparelsen kommer ikke fra én magisk teknik, men fra en række optimeringer, som hver især giver et moderat bidrag.

Denne artikel gennemgår teknikkerne, tallene og produktionsdisciplinen. Vi antager, at du allerede har indført grundlæggende modelrouting (dækket i en anden artikel); her går vi dybere.

Omkostningsstrukturen

LLM-omkostninger kommer fra:

• Inputtokens. Det, du sender til modellen. Omfatter systemprompt, kontekst og brugerforespørgsel.
• Outputtokens. Det, modellen returnerer. Typisk 4-6x dyrere end input (Anthropic 5x, OpenAI ~6x med aktuelle listepriser — se model- og prisreferencen, bekræftet 2026-07-07).
• Ræsonnementstokens. Interne »tænketokens« i ræsonnementsmodeller. Ofte lige så dyre som output.
• Værktøjskald. Ved brug af værktøjskald tæller hver værktøjsdefinition som inputtokens.
• Genforsøg. Mislykkede kald koster også.

Der kan optimeres i hvert lag.

Teknik 1: Promptcaching

Den største enkeltstående løftestang. De fleste moderne leverandører cacher gentagne inputpræfikser — du betaler fuld pris første gang og markant mindre for efterfølgende kald med samme præfiks.

Priser (typisk):

• Anthropic: cachet input ~10% af normal pris.
• OpenAI: automatisk ved matchende præfikser, ~50% af normal pris (afhænger af modellen).
• Google: eksplicit cachet indhold, varierer.

Sådan fungerer det: Det første kald til en model med et bestemt inputpræfiks koster normal pris. Efterfølgende kald inden for cachevinduet (typisk 5-60 minutter, afhængigt af leverandøren) genbruger den cachede repræsentation.

Praktisk implementering:

Strukturér prompts, så statisk indhold står først og dynamisk indhold sidst:

[CACHED: 10K tokens]
- System prompt
- Tool descriptions
- User's static profile
- Knowledge base snippets unlikely to change per call

[NOT CACHED: 1K tokens]
- Conversation history (changes each turn)
- Current user query

De første 10K tokens caches efter det første kald. Efterfølgende kald betaler ~10% for dem og fuld pris for 1K.

Eksempel på besparelse:

Uden caching:

• 11K inputtokens × €3/million = €0.033 pr. kald.
• 100K kald/dag = €3,300/dag.

Med caching (90% af inputtet er cachet):

• 1K til fuld pris + 10K cachet til 10%:
• 1K × €3/million + 10K × €0.30/million = €0.003 + €0.003 = €0.006 pr. kald.
• 100K kald/dag = €600/dag.

82% besparelse. Reelle tal fra reelle systemer.

Implementeringsdisciplin:

• Identificér statiske og dynamiske dele af prompts.
• Placér de statiske dele først.
• Brug cachemarkører til eksplicit kontrol, hvor leverandøren understøtter dem (Anthropic).
• Test cachetræffere — observerbarheden skal vise træfraten. Er den lav, er promptstrukturen forkert.

Det er optimeringen med højest ROI. Implementér den før alt andet.

Teknik 2: Modelrouting

Dækket i detaljer andetsteds. Kort sagt: Send forskellige forespørgsler til forskellige modeller ud fra kompleksiteten.

• 60% af forespørgslerne til små modeller.
• 30% til mellemklassen.
• 10% til flagskibsmodellen.

Typisk besparelse: 60-80% sammenlignet med at bruge flagskibsmodellen til alt.

Kombineret med caching når du 90%+ i besparelse i forhold til den naive baseline.

Teknik 3: Styring af outputlængde

Outputtokens dominerer omkostningen i de fleste brugsscenarier. De koster typisk 4-6x mere end input, bestemmes af modellen og prompten og er ofte længere end nødvendigt.

Strategier:

Eksplicitte længdeinstruktioner.

Respond in at most 100 words.

Modeller følger dette rimeligt godt. Det reducerer outputomkostningerne betydeligt.

Struktureret output.

Når det brugersynlige svar er korte strukturerede data (JSON med bestemte felter), er outputtet afgrænset. Ingen risiko for unødig omstændelighed.

Parameteren max_tokens.

Angiv den. Brug ikke standardværdien. Hvis 200 tokens er nok, så sæt maksimum til 250 (en lille buffer). Modellen kan ikke overskride grænsen.

Formatbegrænsninger.

»Kun punktopstilling« eller »ét afsnit« giver kortere output end fri tekst.

Punkter frem for prosa.

Punktopstillinger bruger typisk halvt så mange tokens som prosa med de samme oplysninger.

Ingen indledning.

»Spring indledende fraser over. Gå direkte til svaret.« Modeller starter ofte med »Godt spørgsmål …« eller »Lad mig forklare …« — spildte tokens.

Eksempel på besparelse:

Et workflow til sammenfatning. Standardoutput: 500 tokens. Begrænset: 200 tokens.

• 500 tokens × €10/million = €0.005 pr. kald.
• 200 tokens × €10/million = €0.002 pr. kald.

60% besparelse på output. Mindre imponerende end cachingens 90%, men på den største omkostningspost.

Teknik 4: Outputsampling og tidligt stop

I nogle brugsscenarier har du ikke brug for et fuldt LLM-output — du har brug for en beslutning eller klassifikation.

Logprobs til klassifikation.

# Use a small NON-reasoning model here: reasoning-family models
# (GPT-5.x thinking tiers and similar) reject 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
)
# Read logprobs of first token to determine likely category

Du beder modellen udsende ét token (kategorien). Omkostningen er én behandling af inputtet + 1 outputtoken. Hurtigere, billigere og ofte lige så godt som længere svar.

Logit bias.

Ved output fra et kendt sæt kan logits vægtes mod de gyldige muligheder.

import tiktoken

enc = tiktoken.encoding_for_model("gpt-4o-mini")
# logit_bias keys are token IDs (as strings), not words.
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 får modellen til at udsende den rigtige type output. Billigt og pålideligt til klassifikation.

Teknik 5: Batching

Behandl elementerne i batches, når der er mange.

Asynkron batching på API-niveau.

De fleste leverandører understøtter asynkrone eller batchbaserede API’er, som behandler flere forespørgsler til lavere pris.

• OpenAI Batch API: 50% rabat, 24-hour SLA.
• Anthropic Message Batches: 50% rabat, 24-hour SLA.

Har du køarbejde, som ikke kræver svar i realtid, bør det køres gennem batch. Halv pris.

Batching i prompten.

Behandl flere elementer i ét LLM-kald, når det er muligt.

I stedet for:

[10 separate calls, each classifying one ticket]

Gør:

[1 call, classifying 10 tickets in one prompt]

Det enkelte kald har mere input (10 elementer), men kun ét sæt fast overhead (systemprompt og værktøjsbeskrivelser). Det samlede tokenantal er lavere end ved 10 separate kald.

Forbehold: Kvaliteten kan falde med for mange elementer pr. prompt. Test det optimale punkt til dit brugsscenarie. Normalt fungerer 5-20 elementer pr. prompt fint.

Teknik 6: Mindre modeller til afgrænsede opgaver

Ud over almindelig routing bør du overveje, om opgaven reelt kræver en stor model.

Klassifikation: En model i den lille kategori er ofte lige så god som en flagskibsmodel til enkel klassifikation. Med aktuelle listepriser (bekræftet 2026-07-07): Claude Haiku 4.5 til $1/$5 pr. M mod Claude Opus 4.8 til $5/$25 giver en direkte besparelse på 5x; OpenAI’s lille kategori mod GPT-5.5 har en lignende forskel.

Udtræk: Modeller i mellemklassen fungerer til struktureret udtræk. Gem flagskibsmodellen til de tilfælde, der fejler.

Oversættelse: Specialiserede oversættelsesmodeller eller mindre LLM’er håndterer de fleste tilfælde.

Embeddings: Brug modeller specialiseret til embeddings, ikke generelle LLM’er.

Mønstret er: Identificér jeres »enkle, afgrænsede« arbejdsbelastninger. Send dem til den mindste model, der løser opgaven tilfredsstillende. Gem flagskibsmodellen til komplekst arbejde, som kræver dømmekraft.

Teknik 7: Finjusterede små modeller

Til afgrænsede opgaver med meget høj volumen kan du finjustere en lille model.

Eksempel: 100K klassifikationsforespørgsler/dag.

• GPT-5 uden ændringer: €30/dag i API-omkostninger.
• Finjusteret 8B-model på dedikeret inferens: €5-10/dag i inferens plus en engangsomkostning til finjustering.

Ved tilstrækkelig volumen tjener finjusterede små modeller sig hurtigt hjem. Regnestykket afhænger af jeres volumen.

Vi dækkede det i artiklen om finjustering. Princippet er: Når skala og en afgrænset opgave passer sammen, er finjustering en omkostningsløftestang.

Teknik 8: Forfiltrering

I LLM-workflows med flere trin kan billig filtrering fange indlysende tilfælde før dyr behandling.

Eksempel: klassifikation og svar i kundesupport.

Billigt forfilter:

• »Er dette et reelt supportspørgsmål eller spam/støj?« (klassifikation med 1-token på en lille model.)
• »Er dette et kendt FAQ-spørgsmål?« (Embeddingsøgning; billigt.)

Kun forespørgsler, der passerer filteret, når den dyre svargenerering.

Besparelse: Hvis 30% af de indgående forespørgsler er støj eller kan besvares fra FAQ, fjernes 30% af de dyre kald.

Forfilteret er billigt (€0.0001 pr. kald) sammenlignet med svargenereringen (€0.05 pr. kald). Enkel ROI.

Teknik 9: Caching ud over promptcaching

Ud over modelleverandørens promptcaching kan applikationen cache:

Svarcaching. Samme forespørgsel, samme kontekst, samme svar. Cache og returnér uden at kalde modellen.

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

Ved idempotente forespørgsler eliminerer det gentagne kald helt.

Caching af embeddings. Beregnede embeddings caches.

Caching af hentningsresultater. Søgeresultater til en forespørgsel caches kortvarigt.

Caching af værktøjsresultater. Resultater af værktøjskald caches, hvis de underliggende data sjældent ændres.

Cachelagene kan kombineres. Hvert lag sparer kald.

Teknik 10: Spekulativ eksekvering

I latenstidsfølsomme flows, hvor du kan forudsige næste trin, kan du kalde på forhånd.

Eksempel: En kundesupportagent. Du ved, at næste trin som regel er at »sammenfatte problemet«, efter kunden har beskrevet det. Start sammenfatningen parallelt med, at en kvittering vises til brugeren.

Hvis forudsigelsen er rigtig, er svaret klar, når det skal bruges. Er den forkert, har du spildt ét kald.

Det er primært en latenstidsoptimering, ikke en omkostningsoptimering, men i nogle flows forbedrer den brugeroplevelsen væsentligt.

Teknik 11: Leverandørarbitrage

Forskellige leverandører tager forskellige priser for lignende modeller. Udnyt det.

Open source-modeller hos billige inferensleverandører.

Llama 3.3 70B hos Together AI: $0.88/M for input og output (listepris, bekræftet 2026-07-07). Den lukkede modelkategori, den konkurrerer med, Claude Sonnet 5: $3/M input, $15/M output (introduktionspris $2/$10 indtil 2026-08-31).

Til opgaver, hvor en åben 70B-model er tilstrækkelig, er forskellen ~3.4x på input og ~17x på output — samlet 3-17x afhængigt af fordelingen mellem input og output.

Samme model hos forskellige leverandører.

Nogle åbne modeller hostes af flere leverandører med forskellige priser. Sammenlign dem.

Selvhosting i stor skala.

Ved tilstrækkelig volumen (eksempelvis €10K+/month på en bestemt model) bliver selvhosting billigere end API-kald. Det kræver driftskapacitet.

Leverandørarbitrage skaber kompleksitet. Routing mellem flere leverandører med fallback. Kvalitetstest af hver leverandørs variant. Det er indsatsen værd i stor skala.

Teknik 12: Acceleration af inferens

Ved selvhosting kan selve inferenslaget optimeres.

vLLM, TGI, SGLang. Optimerede inferensservere. 2-10x kapacitet sammenlignet med naive implementeringer.

Kvantisering. Kør modeller med lavere præcision (4-bit, 8-bit). 2-4x kapacitet med en beskeden kvalitetsomkostning.

Flash Attention, paged attention. Arkitekturoptimeringer, som er aktiveret i moderne servere.

Kontinuerlig batching. Servere, der batcher aktive forespørgsler for bedre GPU-udnyttelse.

Det betyder meget for teams, der selvhoster i stor skala. Ved brug af API’er håndterer leverandøren det.

Teknik 13: Streaming

Streaming reducerer ikke tokenantallet, men forbedrer brugeroplevelsen og dermed oplevelsen af omkostningseffektivitet.

Ved lange output ser brugeren indholdet dukke op med det samme og kan læse med, mens genereringen bliver færdig. Det føles meget hurtigere end at vente på hele svaret.

Ved agenter giver streaming af mellemtrin brugeren indblik i fremskridtet.

Implementering: Alle moderne API’er understøtter streaming. Brug det i brugervendte flows.

Teknik 14: Budgetværn

Ud over optimering skal hårde budgetter håndhæves for at forhindre løbske omkostninger.

Budget pr. forespørgsel. Maksimalt antal tokens pr. forespørgsel. Stop ved overskridelse.

Budget pr. bruger. Dagligt eller månedligt omkostningsloft pr. bruger. Begræns ved tilnærmelse.

Budget pr. funktion. Hver funktion har et budget. Automatisk stop ved 10x det daglige gennemsnit.

Globalt budget. Samlet daglig eller månedlig grænse. Sæt ikke-kritisk arbejde på pause nær grænsen.

De sparer ikke direkte penge, men forhindrer katastrofer. En enkelt fejl eller et angreb kan hurtigt få omkostningerne til at eksplodere uden værn.

Et gennemarbejdet eksempel: en reel omkostningsreduktion

Et team, der drev en AI til kundesupport, havde en regning på €12,000/month. Seks måneder senere var den €1,800/month efter indførelsen af teknikkerne — en reduktion på 85% i alt.

Ændringerne:

1. Promptcaching. Prompts blev omstruktureret for at maksimere det statiske præfiks. ~70% af inputtet caches nu. Sparede ~30%.

2. Modelrouting. Klassifikation og sagstriage blev flyttet fra Claude Sonnet til Claude Haiku. Sparede ~15%.

3. Styring af outputlængde. Svar blev begrænset til 250 ord mod tidligere 800-1500. Sparede ~25%.

4. Forfiltrering. Billig klassifikation fanger FAQ-spørgsmål, som besvares fra cache. ~20% af sagerne blev fjernet fra det dyre flow. Sparede ~10%.

5. Svarcaching til FAQ. Identiske spørgsmål returnerer cachede svar. Sparede ~5%.

De anførte procenter er hver tekniks andel af den endelige reduktion — tilsammen giver de den samlede reduktion på ~85%, og hver blev målt i forhold til den regning, der var tilbage efter den foregående ændring. De er ikke uafhængige multiplikatorer, som kan anvendes på jeres egen regning.

Kvalitet: På alle målte parametre (kundetilfredshed, svarenes korrekthed og løsningsgrad) var kvaliteten uændret eller lidt bedre.

Driftsomkostning: ~80 timers udviklingsarbejde over 3 måneder. ROI: tjent hjem på 2 uger.

Almindelige fejl

Nogle mønstre, vi ser:

Fejl 1: Ingen omkostningssporing. Teamet har ingen indsigt i omkostningen for hver funktion, bruger eller hvert kald. Optimering er umulig uden måling.

Fejl 2: Optimering af det forkerte. Der bruges uger på at reducere inputtokens med 5% selv om outputtokens udgør 80% af regningen. Mål først; optimér de største bidrag.

Fejl 3: Kvalitetsregressioner. Besparelser lanceres uden kvalitetsovervågning. Penge spares, brugere mistes. Kombinér altid omkostningsarbejdet med evalueringspakker.

Fejl 4: Overdreven routing. Aggressiv routing til små modeller ved opgaver, de reelt ikke kan håndtere. Falske besparelser.

Fejl 5: Cacheforurening. Cachen fyldes med sjældne forespørgsler. De fleste cacheposter bruges én gang. Cachemissere dominerer. Der kræves en bedre cachestrategi.

Fejl 6: Batch-API springes over. Realtid bruges, selv om batch er tilstrækkeligt. Halv pris blev efterladt på bordet.

Fejl 7: Overengineering. Der bygges omfattende omkostningsoptimering oven på funktioner, som alligevel ikke er rentable. Nogle gange er det rigtige svar at »fjerne funktionen«.

Fejl 8: Ingen budgetværn. Én fejl skaber en løbsk omkostning. En katastrofe frem for en mindre gene.

Den kulturelle del

Omkostningsdisciplin er delvist kulturel. Teams, der lykkes:

• Behandler omkostning som et målepunkt, ikke en eftertanke.
• Har en ansvarlig (ofte nogen i grænsefladen mellem udvikling og økonomi).
• Gennemgår omkostninger i de ugentlige målinger.
• Undersøger udsving straks.
• Sætter budgetter pr. funktion og alarmerer ved overskridelse.
• Træffer afvejninger eksplicit (omkostning kontra kvalitet kontra latenstid).

Teams, der ikke lykkes:

• Behandler omkostning som en andens problem.
• Opdager regningen ved månedens udgang.
• Reagerer på stigninger bagefter.
• Har intet budgetbegreb.
• Springer samtalen om afvejninger over og optimerer én dimension ad gangen.

Kulturel forandring er sværere end teknisk forandring. Men den får de tekniske ændringer til at holde.

Prisudviklingen

En bemærkning om den overordnede tendens.

Omkostningen pr. enhed kapacitet er faldet kraftigt år for år — primært fordi mindre modeller fortsat matcher gårsdagens flagskibsmodeller, ikke fordi flagskibenes listepriser kollapser. Betragt ethvert tal for »prisen om et år« som en modelleret antagelse, og kontrollér model- og prisreferencen igen, før du citerer det.

Det betyder:

• Nogle optimeringer betyder mindre over tid (den absolutte omkostning falder alligevel).
• Nogle arbejdsbelastninger, som i dag er urentable, bliver rentable.
• Byg til lang sigt: ren arkitektur > at presse hver cent ud nu.

Når det er sagt, betyder optimering stadig noget. Ineffektive systemer spilder penge ved ethvert prisniveau. Og konkurrencefordelen går ofte til teams, der driver effektive systemer til lavere pris.

En 90-dages plan for omkostningsoptimering

Til et team, der starter med »vi har en AI-funktion, og omkostningerne er højere end forventet«:

Uge 1-2: Mål.

• Instrumentér omkostninger pr. kald.
• Byg dashboards pr. funktion og bruger.
• Identificér de største omkostningsposter.

Uge 3-4: Hurtige gevinster.

• Aktivér promptcaching, hvor det understøttes.
• Omstrukturér de 3 vigtigste prompts for at maksimere cachetræfraten.
• Angiv max_tokens på alle kald.
• Implementér budgetalarmer.

Uge 5-6: Routing.

• Identificér enkle opgaver, der nu bruger flagskibsmodellen.
• Byg routing til de 3-5 mest kaldte endpoints.
• Test for kvalitetsregression.

Uge 7-8: Output og caching.

• Begræns outputlængder, hvor outputtet ikke er brugersynligt.
• Tilføj svarcache på applikationsniveau til almindelige forespørgsler.
• Tilføj forfiltre til flows med højest volumen.

Uge 9-10: Avanceret.

• Batch-API til arbejde, der ikke kræver realtid.
• Evaluér alternative leverandører.
• Cache embeddings og hentningsresultater.

Uge 11-12: Hærdning.

• Budgetværn på alle funktioner.
• Omkostningsdashboards i teamets faste gennemgang.
• Dokumentér mønstrene til fremtidige funktioner.

Ved udgangen af 90 dage er en omkostningsreduktion på 50-80% realistisk. Kvaliteten overvåges. Disciplinen er indarbejdet.

Mål først, og kombinér derefter besparelserne

LLM-omkostninger kan reduceres — normalt med 60-90% — uden kvalitetstab. Teknikkerne er velkendte: caching, routing, outputkontrol, batching, forfiltrering, svarcaching, modelvalg og budgetværn.

Hver teknik giver en moderat besparelse alene. Sammen skaber de en markant samlet besparelse.

De teams, der gør det rigtigt, forvandler urentable AI-funktioner til rentable. Teams, der ikke gør, må med tiden fjerne funktioner, som burde have været levedygtige.

Mål først. Optimér de største omkostningsposter. Bevar kvalitetsovervågningen. Gør omkostningsdisciplin til en fast del af teamets arbejde.

Resultatet er AI-funktioner, der skalerer økonomisk og ikke kun teknisk. Det gør AI til en bæredygtig del af et produkt frem for blot en overskrift ved lanceringen.