LLM-kostnadsovervåking: Spor forbruket før det sprekker (2026)

LLM-kostnadsovervåking: Spor forbruket før det sprekker (2026)

LLM-kostnadsovervåking er forskjellen mellom en overraskelsesfaktura på $412 og en Slack-melding ved 80 % av budsjettet. Claude Sonnet 5 prises til $3,00 per million input-tokens denne måneden, og én enkelt løpsk agentløkke kan brenne gjennom det på en ettermiddag. De fleste team kobler opp sporingen på en dag; varselet er delen de hopper over.

Nøkkelpoeng:

• LLM-kostnadsovervåking knytter et tokenantall og et dollarestimat til hver forespørsel, og aggregerer deretter per modell og team.
• Spor fem metrikker: tokens per forespørsel, kostnad per funksjon/team/modell, cache-treffrate, kostnad per samtale og topprate.
• LiteLLM-budsjetter, Langfuse-tracer eller Datadog LLM Observability gir hver for seg innsyn i forbruket på under én dag.
• Dashbord viser estimater; priser på cachet input og batch-rabatter gjør at fakturaen som regel lander under dem.

Hva sporer egentlig LLM-kostnadsovervåking?

LLM-kostnadsovervåking går ut på å knytte et tokenantall og et dollarestimat til hver LLM-forespørsel, for så å aggregere estimatene per modell, funksjon og team slik at forbruket kan utløse varsel før fakturaen kommer. Estimatet beregnes per forespørsel ut fra publiserte tokenpriser, rulles opp etter taggene du setter på kallet, og sammenlignes mot et budsjett som er satt på forhånd.

Matematikken under er leverandørnøytral. Bruksresponsen fra hver leverandør bryter tokens ned i felter, og Datadogs kostnadsdokumentasjon dokumenterer sammenhengene eksplisitt. OpenTelemetry GenAI semantic conventions standardiserer de samme feltene på tvers av leverandører, så et dashbord bygget på dem er ikke låst til én leverandør.

Tre sammenhenger gjør mesteparten av jobben: totale tokens = input + output; input = ikke-cachet + cache_read + cache_write; og reasoning-tokens ligger inne i output, til output-pris. Få disse riktige, og estimatet per forespørsel holder seg nærme; ignorer dem, og dashbordet driver fra fakturaen hver måned. Kostnadsovervåking er én søyle i AI-observerbarhet; sporing og evaluering er de to andre, og de deler det samme feltvokabularet.

Dashbordet ditt viser et estimat; fakturaen er den eneste kostnadsmetrikken som aldri caches.

Hva koster 1 million tokens i LLM?

Det avhenger av modellen og retningen: 1 mill. tokens koster $0,14 som DeepSeek-V4-input og $15,00 som GPT-5.6 Terra-output, et sprik på 100x på samme enhet. Her er fire modeller fra prisundersøkelsen vår 14. juli 2026, verifisert mot de offisielle sidene:

Kilder: OpenAI-prising og Anthropic-prising. Én fotnote: Claude Sonnet 5 kjører introduksjonspriser på $2,00 input / $10,00 output til og med 31. august 2026, og går deretter tilbake til tallene over.

De 5 metrikkene som faktisk betyr noe

Fem metrikker dekker LLM-kostnadssporing, og de fleste team setter bare varsel på to av dem. Start med de to første radene: tokens per forespørsel fanger prompt-oppblåsing samme dag som den dukker opp, og kostnad per team er tallet økonomiavdelingen til slutt spør etter. De tre andre finjusterer bildet når disse er koblet opp.

Én merknad om granularitet: Datadog lagrer kostnad på forespørselsnivå i nanodollar (milliarddels dollar) ifølge kostnadsdokumentasjonen. Til $0,14 per million tokens kan en enkelt DeepSeek-V4-forespørsel koste mindre enn en tusendels cent, så aggreger før du avrunder, ellers forsvinner småmodelltrafikken fra rapporten.

Hvis du ikke sporer noe annet, spor rad én og to. Tokens per forespørsel er det tidligste varselet du får; kostnad per team er den som overlever møtet med en regnskapsavdeling.

Tre måter å koble opp LLM-kostnadsovervåking på

Ingen av toppsidene for dette søket leverer én eneste kjørbar kodelinje, så her er tre fungerende oppsett. Hvert av dem er i drift på under én dag, og de kan kombineres: vi kjører de to første sammen.

Dette kjører vi faktisk i produksjon: i oppsettet vårt snakker hver klientagent med LiteLLM-proxyen gjennom sin egen virtuelle nøkkel, med et månedlig budsjett på hver nøkkel og Langfuse som tracer hver forespørsel bak proxyen. Da vi deployet de to sammen, var arbeidsdelingen poenget: proxyen håndhever takene, og tracene forklarer hva som brukte dem. Hver av klientnøklene våre har også en tpm_limit på 100 000 tokens per minutt som en andre sikring; basert på LiteLLMs dokumentasjon avviser proxyen forespørsler når en grense er nådd, og det er den dokumenterte oppførselen vi støtter oss på, ikke en benchmark vi har målt selv. Konfigurasjonen vår hopper helt over LiteLLM 1.82.7 og 1.82.8, de to versjonene som ble rammet av supply chain-hendelsen i mars 2026, og piner image-taggen i stedet for å flyte på latest.

LiteLLM-proxy: virtuelle nøkler + budsjetter

Techsy kjører et LiteLLM-proxy-oppsett i produksjon med én virtuell nøkkel per klient og et månedlig budsjett på hver nøkkel. Forespørselen under er den dokumenterte formen fra LiteLLMs virtual_keys-dokumentasjon: basert på den dokumentasjonen, når kumulativt forbruk på denne nøkkelen passerer $50 i løpet av en måned, avviser proxyen flere forespørsler med en budsjett-overskredet-feil i stedet for å logge en advarsel i etterkant.

curl -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "key_alias": "client-acme-search",
    "max_budget": 50.0,
    "budget_duration": "monthly",
    "tpm_limit": 100000,
    "models": ["anthropic/claude-sonnet-4-5"]
  }'

Gjør regnestykket mot publiserte priser: til Claude Sonnet 5s $3,00 / $15,00 per million tokens kjøper $50 omtrent 16,7 mill. input-tokens eller 3,3 mill. output-tokens, omtrent en uke med trafikk for én av de lettere klientagentene våre. Det er nøyaktig det skadeomfanget vi ønsker. tpm_limit er den andre sikringen: en løpsk løkke utløser 100K tokens-per-minutt lenge før den utløser det månedlige budsjettet. Per-bruker-attribusjon fungerer på samme måte gjennom users-endepunktet, og guiden vår til de beste LLM-gateway-verktøyene dekker når en proxy fortjener plassen sin, og når den bare er enda et hopp.

Langfuse: kostnadssporing med @observe

Google autofullfør kobler «langfuse monitoring» med dette søket, og det med god grunn: Langfuse er standardvalget for open source-sporing. Python-SDK-en wrapper leverandørklienten din slik at hvert kall blir en trace som bærer tokenantall og en beregnet kostnad, ifølge Langfuse sin sporingsdokumentasjon:

# pip install langfuse openai
from langfuse import observe
from langfuse.openai import openai  # drop-in wrapper, auto-traces

@observe()
def answer(question: str):
    return openai.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": question}],
    )

answer("what is llm cost monitoring")
# the trace now carries usage.total_tokens and total_cost,
# priced from Langfuse's model price cards

Kostnaden lander på tracen uten at du trenger å regne på tokens selv; grupper tracer per sesjon eller bruker-id for opprullering per funksjon, og selvhost hvis dataene ikke kan forlate nettverket ditt.

Datadog LLM Observability: hvis du allerede er der

Hvis teamet ditt allerede kjører Datadog-agenter, er LLM-kostnadsdokumentasjonen den dypeste enkeltreferansen på denne siden: kostnad på forespørselsnivå i nanodollar, egendefinerte cost_tags for team- og funksjonsfordeling, og en reell feilsøkingsseksjon for hull i delvise kostnader. Den ærlige begrensningen: det er bare Datadog. Metrikkene forlater ikke plattformen, og det finnes ingen open source-reserve hvis prisingen slutter å passe. Velg det for konsolidering, ikke for fleksibilitet.

Hvordan kobler du opp budsjetter, varsler og chargeback?

Du kobler det opp i tre lag: et budsjettak som avviser forespørsler ved grensen, et webhook-varsel som fyres av ved en prosentterskel før taket, og virtuelle nøkler per team som gjør showback og chargeback om til en spørring i stedet for en krangel. LiteLLM leverer alle tre innebygd; mønstrene overføres til enhver gateway med budsjetter på nøkkelnivå.

Et budsjett som bare teller, er en rapport; et budsjett som avviser forespørsler ved taket, er en kontroll.

Varsler som fyres før toppen

Sett varselet til 80 % av taket, ikke 100 %. LiteLLM har Slack-varsling innebygd: sett alerting: ["slack"] og alerting_threshold: 80 i general_settings, pek miljøvariabelen SLACK_WEBHOOK_URL til en kanal, og en melding som denne lander når en nøkkel passerer terskelen:

{
  "text": "LLM budget alert: client-acme-search spent $40.18 of its $50.00 monthly cap (80.4%). Top model: anthropic/claude-sonnet-4-5."
}

Ved 80 % har et menneske fortsatt dager på seg til å handle: nedgradere modellen, stramme inn prompten eller heve taket med et navn på godkjenningen. Et varsel ved 100 % er en obduksjon.

Fra showback til chargeback

Showback betyr at hvert team ser sitt eget forbruk; chargeback betyr at det trekkes fra budsjettet deres. Begge lever på én ingrediens: en virtuell nøkkel per team, tagget ved opprettelse. Månedsrapporten blir da en group-by over forbrukstabellen:

Eksempelformat, ikke klientdata. evals-batch-raden er mønsteret som fungerer som tiltenkt: batch-jobben løp til taket og stoppet, i stedet for å blø stille inn i fakturaen. Håndhevingsoppførselen er dokumentert i LiteLLMs virtual_keys-dokumentasjon, inkludert hvordan budsjettperioden nullstilles.

Hvorfor er dashbordet uenig med fakturaen?

Fordi dashbord fakturerer til listepris, mens fakturaene bruker rabatter som overvåkingen din aldri ser. Cachet input lander på 0,1x til 0,25x av grunnprisen, batch kjører til halv pris, og reasoning-tokens faktureres til output-pris innenfra output-antallet. Når de to tallene spriker, er fakturaen som regel det laveste, og gapet er nesten alltid én av fire modifikatorer.

Den åpne pydantic/genai-prices-katalogen viser hvorfor disse multiplikatorene varierer per modell: hver leverandør setter sine egne cache- og batch-faktorer, så én hardkodet pristabell driver fra virkeligheten den dagen en leverandør reviderer priskortene sine. Datadogs kostnadsdokumentasjon dokumenterer den andre halvparten av problemet, hull i delvise kostnader der et manglende tokenfelt returnerer COST UNAVAILABLE for en forespørsel. Sjekk der når dashbordet viser lavere enn fakturaen; sjekk rabattabellen når det viser høyere. Mekanismen bak den største multiplikatoren er LLM-prompt-caching, og en høy cache-treffrate er den vanligste grunnen til at et sporet estimat skyter over den reelle fakturaen.

Et kostnadsestimat uten cache-treff- og batch-rabatter er et tak, ikke en prognose.

Hvilke verktøy driver egentlig med LLM-kostnadssporing?

Seks verktøy dekker de fleste produksjonsoppsett: Langfuse, LiteLLM, Helicone og Portkey på open source- og gateway-siden, Datadog og Braintrust på den kommersielle siden. Det ærlige skillet er håndheving mot observerbarhet: en proxy kan avvise forespørsler ved et budsjett, mens et sporingsverktøy måler forbruket i etterkant. De fleste modne stacker ender med én av hver.

Én advarsel om leverandørinnhold i denne bransjen: Braintrusts egen 2026-sammenligning av kostnadssporingsverktøy rangerer seg selv på førsteplass og utelater alle open source-alternativene i tabellen over. Les leverandør-listikler for dataenes skyld, ikke rangeringens.

For et team som starter fra null, ville vi kjørt LiteLLM foran og Langfuse bak: proxyen håndhever budsjetter, tracene forklarer dem, og kombinasjonen koster ingenting før du går over til hostede planer. Hvis du veier de to sporingsstandardvalgene mot hverandre, går Langfuse vs Langsmith-gjennomgangen vår i dybden på det valget, og beste AI-observerbarhetsplattformer-runden dekker hele feltet.

Fra overvåking til kostnadskutt

Overvåking viser hvor pengene tar veien; neste steg er å bestemme hvor mye som skal dit. De tre spakene, i rekkefølge etter gevinst: cache gjentatt input, rut enkle forespørsler til billigere modeller og nedskaler modellen der kvaliteten fortsatt holder. Guiden vår om å redusere LLM-API-kostnader dekker hver spak, og LLM-API-prissammenligningen er inputen til hele regnestykket over.

Vårt perspektiv: når en klients LLM-forbruk overrasker dem, overvåker vi først og kutter etterpå, aldri omvendt. Team som cacher før de måler, ender som regel med å cache feil prompter. Overvåking forteller deg hvor pengene tar veien; caching og ruting bestemmer hvor mye som skal dit. Hvis fakturaen allerede svir, ta en gratis konsultasjon, så ser vi på tallene sammen med deg.

Ofte stilte spørsmål

Hva koster 1 million tokens i LLM?

Til listepris, alt fra $0,14 til $15 per million avhengig av modell og retning: DeepSeek-V4-input koster $0,14 per million, mens GPT-5.6 Terra-output koster $15. Output-tokens ligger på 3 til 6 ganger input-prisen hos alle store leverandører. Tabellen i den første seksjonen har fire modeller, og LLM-API-prissammenligningen vår priser alle sytten, verifisert mot OpenAI- og Anthropic-sidene i juli 2026.

Hva er LLM-kostnadsoptimalisering?

Praksisen med å senke kostnad per forespørsel uten å senke kvaliteten: prompt-caching for gjentatt input, ruting av enkle oppgaver til billigere modeller, batch-API-er for asynkront arbeid og riktig dimensjonering av modellen per funksjon. LLM-kostnadsovervåking er forutsetningen, siden du ikke kan optimalisere det du ikke har attribuert. Cache-treffrate og kostnad per funksjon er de to metrikkene som peker på de største spakene først.

Hvorfor er LLM-er så dyre?

Inferens er beregningsbundet: hvert genererte token kjører en full forward pass av modellen på GPU-er, og reasoning-modeller bruker ekstra tokens på å tenke før de svarer, fakturert til output-priser. Lange systemprompter multipliserer den kostnaden på tvers av hver eneste forespørsel. Fakturaen vokser med ordrikheten på begge sider av kallet, og det er derfor tokens per forespørsel er den første metrikken det er verdt å følge med på.

Hva koster en LLM i USA?

API-prising er USD-denominert og global: OpenAI, Anthropic og Google tar samme listepris per million tokens enten forespørselen kommer fra Ohio eller Osaka. Regionale forskjeller viser seg ved selvhosting, der GPU-timer varierer per cloud-region, og i hostede plattformer som legger på et påslag. For API-arbeid endrer lokasjonen latensen, ikke prisen.

Hvordan sporer jeg LLM-kostnader per team?

Utsted én virtuell nøkkel per team gjennom en proxy som LiteLLM, tag hver nøkkel med teamnavnet ved opprettelse, og aggreger forbruket per den taggen. Da bærer hver forespørsel attribusjon fra øyeblikket den gjøres, uten loggparsing. Showback-tabellen i budsjettseksjonen over er sluttproduktet: team, månedlig budsjett, forbruk til nå, status.

Langfuse vs Datadog for LLM-kostnadssporing: hvilken skal jeg velge?

Velg Langfuse hvis du vil ha open source, selvhosting og data du kontrollerer selv; det er gratis å kjøre og sporer kostnad per forespørsel rett ut av boksen. Velg Datadog bare hvis teamet ditt allerede kjører det for infrastruktur, siden LLM-kostnadsfunksjonene ikke forlater plattformen. For de fleste team som starter friskt, slår Langfuse pluss en LiteLLM-proxy begge alternativene alene.

Stemmer estimerte LLM-kostnader overens med den faktiske fakturaen?

Nei, og som regel er fakturaen lavere. Dashbord fakturerer til listepris, mens cachet input lander på 0,1x til 0,25x og batch-jobber på 0,5x, så en arbeidsbelastning med mye cache ser den reelle fakturaen komme godt under det sporede estimatet. Manglende tokenfelt dytter feilen andre veien. Avvikstabellen over lister hver multiplikator og hvor du skal se.

Hvordan varsler jeg på topp i LLM-forbruket?

Sett et terskelvarsel på 80 % av hvert teams månedlige budsjett, levert til Slack via webhook, pluss et dag-til-dag-anomalivarsel på +50 % for løkker som brenner raskt. LiteLLM leverer terskelmønsteret innebygd gjennom alerting_threshold-innstillingen. Et varsel ved 80 % gir dager å reagere på; et varsel ved 100 % bekrefter bare at taket gjorde jobben sin.

Finnes det en gratis LLM-kostnadssporer?

Ja, tre troverdige. Langfuse selvhostet er gratis og open source, med et gratis hobby-nivå på cloud ifølge Langfuse sin prisside. LiteLLMs innebygde nøkkelbudsjetter koster ingenting på open source-proxyen. Helicones gratisnivå dekker kostnadslogger på proxy-nivå med ratebegrensninger. Gratisnivåer dekker overvåking; håndheving og varsling i skala er der betalte planer begynner.

Konklusjon

Velg en oppsettsvei i dag, for varselet du kommer til å ønske deg om seks uker, tar en ettermiddag å koble opp nå. Kortversjonen:

• Spor tokens per forespørsel og kostnad per team først; legg til de tre andre metrikkene når disse fungerer.
• Et budsjett som avviser forespørsler, er en kontroll; et som bare teller, er en rapport.
• Sett varselet til 80 %, i Slack, før fakturaen kan overraske noen.
• Dashbordet ditt er et estimat; priser på cachet input og batch betyr at fakturaen som regel lander under det.

Hvis du heller vil ha noen til å se på tallene sammen med deg, ta en gratis konsultasjon.