LLM-omkostningsovervågning: Se forbruget, før det stikker af (2026)

LLM-omkostningsovervågning: Se forbruget, før det stikker af (2026)

LLM-omkostningsovervågning er forskellen på en overraskelsesregning på 412 $ og en Slack-ping ved 80 % af budgettet. Claude Sonnet 5 koster 3,00 $ pr. million input-tokens i denne måned, og ét løbsk agent-loop kan brænde det af på en eftermiddag. De fleste team kobler sporingen op på en dag. Alarmen er den del, de springer over.

Nøglepointer:

• LLM-omkostningsovervågning knytter et tokental og et dollar-estimat til hvert request og aggregerer derefter efter model og team.
• Følg fem måletal: tokens pr. request, omkostninger pr. funktion/team/model, cache-hit-ratio, omkostninger pr. samtale og spike-rate.
• LiteLLM-budgetter, Langfuse-traces eller Datadog LLM Observability giver hver især indsigt i forbruget på under en dag.
• Dashboards viser estimater. Cache-input-priser og batch-rabatter betyder, at regningen som regel lander under dem.

Hvad sporer LLM-omkostningsovervågning egentlig?

LLM-omkostningsovervågning er praksissen med at knytte et tokental og et dollar-estimat til hvert LLM-request og derefter aggregere estimaterne efter model, funktion og team, så forbruget kan udløse alarm, før regningen ankommer. Estimatet beregnes pr. request ud fra offentliggjorte tokenpriser, rulles op efter de tags, man sætter på kaldet, og sammenlignes med et budget, der er sat på forhånd.

Matematikken bag er leverandørneutral. Enhver leverandørs usage-svar fordeler tokens i felter, og Datadogs omkostningsdokumentation beskriver sammenhængene eksplicit. OpenTelemetry GenAI-semantikkonventionerne standardiserer de samme felter på tværs af leverandører, så et dashboard bygget på dem ikke er låst til én leverandør.

Tre sammenhænge udgør det meste af arbejdet: totale tokens = input + output; input = ikke-cachet + cache_read + cache_write; og reasoning-tokens ligger inde i output til outputtaksten. Få de tre på plads, og estimatet pr. request bliver tæt. Ignorer dem, og dashboardet driver fra regningen hver måned. Omkostningsovervågning er én søjle i AI-observability; tracing og evals er de to andre, og de deler det samme feltordforråd.

Dit dashboard viser et estimat. Regningen er det eneste omkostningstal, der aldrig er cachet.

Hvor meget er 1 million tokens i LLM?

Det afhænger af modellen og retningen: 1M tokens koster 0,14 $ som DeepSeek-V4-input og 15,00 $ som GPT-5.6 Terra-output, en spredning på 100x for samme enhed. Her er fire modeller fra vores prisundersøgelse af 14. juli 2026, verificeret mod de officielle sider:

Kilder: OpenAI-priser og Anthropic-priser. Én fodnote: Claude Sonnet 5 kører introduktionspriser på 2,00 $ input / 10,00 $ output frem til 31. august 2026 og vender derefter tilbage til tallene ovenfor.

De 5 måletal, der faktisk betyder noget

Fem måletal dækker LLM-omkostningsregistrering, og de fleste team når kun at sætte alarm på to af dem. Start med de to første rækker: tokens pr. request fanger prompt-opblæsning den dag, den opstår, og omkostninger pr. team er det tal, økonomiafdelingen før eller siden beder om. De tre andre finjusterer billedet, når de to første er på plads.

Én note om granularitet: Datadog gemmer request-niveau-omkostninger i nanodollars (milliarddele af en dollar) ifølge deres omkostningsdokumentation. Ved 0,14 $ pr. million tokens kan et enkelt DeepSeek-V4-request koste mindre end en tusindedel af en cent, så aggreger, før du afrunder, ellers forsvinder trafik fra små modeller ud af rapporten.

Hvis du ikke sporer andet, så spor række et og to. Tokens pr. request er det tidligste varsel, du får. Omkostninger pr. team er det tal, der overlever mødet med en bogholderiafdeling.

Tre måder at koble LLM-omkostningsovervågning op på

Ingen af de øverste søgeresultater for denne forespørgsel leverer én eneste kørbar kodelinje, så her er tre opsætninger, der virker. Hver af dem er klar på under en dag, og de kan kombineres: vi kører de to første sammen.

Det, vi faktisk kører i produktion: i vores opsætning taler hver klientagent med LiteLLM-proxyen gennem sin egen virtuelle nøgle med et månedligt budget på hver nøgle, og Langfuse tracer hvert request bag proxyen. Da vi rullede de to ud sammen, var arbejdsdelingen pointen: proxyen håndhæver lofterne, og traces forklarer, hvad der brugte dem. Hver af vores klientnøgler bærer også en tpm_limit på 100.000 tokens i minuttet som en ekstra sikring. Ifølge LiteLLMs dokumentation afviser proxyen requests, når en grænse er nået, og det er den dokumenterede adfærd, vi stoler på, ikke et benchmark, vi selv har målt. Vores konfiguration springer LiteLLM 1.82.7 og 1.82.8 helt over, de to versioner, der var ramt af supply chain-hændelsen i marts 2026, og fastgør image-tagget i stedet for at flyde med på latest.

LiteLLM-proxy: virtuelle nøgler + budgetter

Techsy kører en LiteLLM-proxyopsætning i produktion med én virtuel nøgle pr. klient og et månedligt budget på hver nøgle. Requestet nedenfor er den dokumenterede form fra LiteLLMs virtual_keys-dokumentation: ifølge den dokumentation afviser proxyen yderligere requests med en budget-overskredet-fejl, når det akkumulerede forbrug på denne nøgle passerer 50 $ på en måned, i stedet for at logge en advarsel bagefter.

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"]
  }'

Tag regnestykket mod de offentliggjorte priser: med Claude Sonnet 5's 3,00 $ / 15,00 $ pr. million tokens køber 50 $ cirka 16,7M input-tokens eller 3,3M output-tokens, omkring en uges trafik for en af vores lettere klientagenter. Det er præcis den sprængradus, vi vil have. tpm_limit er den anden sikring: et løbsk loop udløser 100K tokens-i-minuttet længe før, det udløser månedens budget. Pr.-bruger-attribution virker på samme måde via users-endepunktet, og vores guide til de bedste LLM-gateway-værktøjer dækker, hvornår en proxy fortjener sin plads, og hvornår den bare er endnu et hop.

Langfuse: @observe-omkostningstracing

Googles autofuldførelse parrer "langfuse monitoring" med denne forespørgsel, og det er der en god grund til: Langfuse er open source-standardvalget til tracing. Dets Python-SDK wrapper din leverandørklient, så hvert kald bliver en trace, der bærer tokental og en beregnet omkostning, ifølge Langfuse-tracing-dokumentationen:

# 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

Omkostningen lander på tracen uden token-matematik på din side. Gruppér traces efter session eller bruger-id for pr.-funktion-opruling, og selv-host, hvis dataene ikke må forlade dit netværk.

Datadog LLM Observability: hvis du allerede er i det

Hvis dit team allerede sender Datadog-agenter ud, er deres LLM-omkostningsdokumentation den dybeste enkeltreference på denne side: request-niveau-omkostninger i nanodollars, brugerdefinerede cost_tags til team- og funktionsfordeling og en reel fejlfindingssektion om huller i delvise omkostninger. Den ærlige begrænsning: det er kun Datadog. Måletallene forlader ikke platformen, og der er intet open source-alternativ, hvis prisen ikke længere passer. Vælg det til konsolidering, ikke til fleksibilitet.

Hvordan kobler du budgetter, alarmer og chargeback op?

Du kobler det op i tre lag: et budgetloft, der afviser requests ved grænsen, en webhook-alarm, der fyres af ved en procentsats før loftet, og virtuelle nøgler pr. team, der gør showback og chargeback til en forespørgsel i stedet for en diskussion. LiteLLM leverer alle tre fra starten. Mønstrene overføres til enhver gateway med nøgleniveau-budgetter.

Et budget, der kun tæller, er en rapport. Et budget, der afviser requests ved loftet, er en kontrol.

Alarmer, der fyres før spiken

Sæt alarmen til 80 % af loftet, ikke til 100 %. LiteLLM leverer Slack-alarming indbygget: sæt alerting: ["slack"] og alerting_threshold: 80 i general_settings, peg miljøvariablen SLACK_WEBHOOK_URL mod en kanal, og en besked som denne lander, når en nøgle passerer grænsen:

{
  "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 stadig dage til at handle: nedgradér modellen, stram prompten, eller hæv loftet med et navn på godkendelsen. En alarm ved 100 % er en obduktion.

Fra showback til chargeback

Showback betyder, at hvert team ser sit eget forbrug. Chargeback betyder, at det trækkes fra deres budget. Begge kører på én ingrediens: en virtuel nøgle pr. team, tagget ved oprettelsen. Månedsrapporten er derefter en group-by over forbrugstabellen:

Eksempelformat, ikke klientdata. evals-batch-rækken er mønsteret, der virker efter hensigten: batch-arbejdet løb til sit loft og stoppede i stedet for at bløde stille ud i regningen. Håndhævelsesadfærden er dokumenteret i LiteLLMs virtual_keys-dokumentation, inklusive hvordan budgetperioden nulstilles.

Hvorfor er dit dashboard uenigt med regningen?

Fordi dashboards fakturerer til listepris, mens regninger anvender rabatter, din overvågning aldrig ser. Cachet input lander på 0,1x til 0,25x af basisprisen, batch kører til det halve, og reasoning-tokens faktureres til outputtaksten inde i outputtallet. Når de to tal divergerer, er regningen som regel det laveste, og gabet er næsten altid én af fire modifikatorer.

Det åbne pydantic/genai-prices-katalog viser, hvorfor disse multiplikatorer varierer pr. model: hver leverandør sætter sine egne cache- og batch-faktorer, så en enkelt hårdkodet pristabel driver, den dag en leverandør reviderer sine kort. Datadogs omkostningsdokumentation dokumenterer den anden halvdel af problemet, huller i delvise omkostninger, hvor et manglende tokenfelt returnerer COST UNAVAILABLE for et request. Tjek der, når dashboardet læser lavere end regningen, og tjek rabattabellen, når det læser højere. Mekanismen bag den største multiplikator er LLM-prompt-caching, og en høj cache-hit-ratio er den hyppigste grund til, at et sporet estimat overskrider den reelle regning.

Et omkostningsestimat uden cache-hit- og batch-rabatter er et loft, ikke en prognose.

Hvilke værktøjer laver faktisk LLM-omkostningsregistrering?

Seks værktøjer dækker de fleste produktionopsætninger: Langfuse, LiteLLM, Helicone og Portkey på open source- og gateway-siden, Datadog og Braintrust på den kommercielle side. Den ærlige opdeling er håndhævelse versus observability: en proxy kan afvise requests ved et budget, mens et tracing-værktøj måler forbruget bagefter. De fleste modne stakke ender med én af hver.

Én advarsel om leverandørindhold i dette område: Braintrusts egen 2026-sammenligning af omkostningsregistreringsværktøjer placerer sig selv på førstepladsen og udelader alle open source-mulighederne i tabellen ovenfor. Læs leverandør-listicles for deres data, ikke deres placeringer.

For et team, der starter fra nul, ville vi køre LiteLLM foran og Langfuse bagved: proxyen håndhæver budgetter, traces forklarer dem, og kombinationen koster intet, indtil du krydser over i hostede planer. Hvis du vejer de to tracing-standardvalg mod hinanden, sammenligner vores Langfuse vs Langsmith-gennemgang de to valg i detaljer, og bedste AI-observability-platforme-rundskuet dækker hele feltet.

Fra overvågning til at skære omkostninger

Overvågning viser, hvor pengene ryger. Næste skridt er at bestemme, hvor meget der ryger derhen. De tre håndtag i rækkefølge efter gevinst: cach gentaget input, rut lette requests til billigere modeller, og nedskalér modellen, hvor kvaliteten stadig holder. Vores guide til at reducere LLM-API-omkostninger dækker hvert håndtag, og LLM-API-prissammenligningen er input til al matematikken ovenover.

Vores perspektiv: når en klients LLM-forbrug overrasker dem, overvåger vi først og skærer derefter, aldrig omvendt. Teams, der cacher, før de måler, ender som regel med at cache de forkerte prompts. Overvågning fortæller dig, hvor pengene ryger. Caching og routing bestemmer, hvor meget der ryger derhen. Hvis din regning allerede svier, så få en gratis konsultation, og vi ser på tallene sammen med dig.

Ofte stillede spørgsmål

Hvor meget er 1 million tokens i LLM?

Til listepris hvor som helst fra 0,14 $ til 15 $ pr. million afhængigt af modellen og retningen: DeepSeek-V4-input koster 0,14 $ pr. million, mens GPT-5.6 Terra-output koster 15 $. Output-tokens kører 3 til 6 gange inputtaksten hos alle store leverandører. Tabellen i det første afsnit har fire modeller, og vores LLM-API-prissammenligning prissætter alle sytten, verificeret mod OpenAI- og Anthropic-siderne i juli 2026.

Hvad er LLM-omkostningsoptimering?

Praksissen med at sænke omkostninger pr. request uden at tabe kvalitet: prompt-caching af gentaget input, routing af lette opgaver til billigere modeller, batch-API'er til asynkront arbejde og ret dimensionering af modellen pr. funktion. LLM-omkostningsovervågning er forudsætningen, for du kan ikke optimere det, du ikke har attribueret. Cache-hit-ratio og omkostninger pr. funktion er de to måletal, der først peger på de største håndtag.

Hvorfor er LLM'er så dyre?

Inferens er compute-bundet: hvert genereret token kører en fuld forward pass af modellen på GPU'er, og reasoning-modeller bruger ekstra tokens på at tænke, før de svarer, faktureret til outputtakster. Lange systemprompts ganger den omkostning op på tværs af hvert eneste request. Regningen vokser med ordmængden på begge sider af kaldet, og det er derfor, tokens pr. request er det første måletal, der er værd at holde øje med.

Hvor meget koster en LLM i USA?

API-priser er USD-denominerede og globale: OpenAI, Anthropic og Google opkræver den samme listepris pr. million tokens, uanset om requestet kommer fra Ohio eller Osaka. Regionale forskelle viser sig i selv-hosting, hvor GPU-timer varierer efter cloud-region, og i hostede platforme, der lægger et tillæg til. For API-arbejde ændrer placering latenstid, ikke pris.

Hvordan sporer jeg LLM-omkostninger pr. team?

Udsted én virtuel nøgle pr. team gennem en proxy som LiteLLM, tag hver nøgle med teamnavnet ved oprettelsen, og aggreger forbruget efter det tag. Hvert request bærer derefter attribution fra det øjeblik, det er lavet, uden log-parsing. Showback-tabellen i budgetafsnittet ovenfor er slutproduktet: team, månedligt budget, forbrug til dato, status.

Langfuse vs Datadog til LLM-omkostningsregistrering: hvilken skal jeg vælge?

Vælg Langfuse, hvis du vil have open source, selv-hosting og data, du kontrollerer. Det er gratis at køre og tracer omkostninger pr. request fra starten. Vælg kun Datadog, hvis dit team allerede kører det til infrastruktur, for dets LLM-omkostningsfunktioner forlader ikke platformen. For de fleste teams, der starter fra bunden, slår Langfuse plus en LiteLLM-proxy begge valg alene.

Matcher estimerede LLM-omkostninger den faktiske regning?

Nej, og som regel er regningen lavere. Dashboards fakturerer til listepris, mens cachet input lander på 0,1x til 0,25x og batch-jobs på 0,5x, så en workload med meget cache ser den reelle regning komme godt under det sporede estimat. Manglende tokenfelter skubber fejlen den anden vej. Drivtabellen ovenfor viser hver multiplikator, og hvor du skal lede.

Hvordan slår jeg alarm ved spikes i LLM-forbrug?

Sæt en grænsealarm ved 80 % af hvert teams månedlige budget, leveret til Slack via webhook, plus en dag-til-dag-anomali-alarm på +50 % for loops, der brænder hurtigt af. LiteLLM leverer grænsemønstret fra starten via dets alerting_threshold-indstilling. En alarm ved 80 % giver dage til at reagere. En alarm ved 100 % bekræfter bare, at loftet gjorde sit arbejde.

Findes der en gratis LLM-omkostningstracker?

Ja, tre troværdige. Selv-hostet Langfuse er gratis og open source med et gratis hobby-niveau i cloud ifølge Langfuse-prissiden. LiteLLMs indbyggede nøglebudgetter koster intet på open source-proxyen. Helicones gratis niveau dækker proxy-niveau-omkostningslogs med rate limits. Gratis niveauer dækker overvågning. Håndhævelse og alarming i skala er der, de betalte planer starter.

Konklusion

Vælg en opsætningsvej i dag, for den alarm, du vil ønske dig om seks uger, tager en eftermiddag at koble op nu. Den korte version:

• Spor tokens pr. request og omkostninger pr. team først, og tilføj de tre andre måletal, når de virker.
• Et budget, der afviser requests, er en kontrol. Ét, der kun tæller, er en rapport.
• Sæt alarmen til 80 %, i Slack, før regningen kan overraske nogen.
• Dit dashboard er et estimat. Cache-input- og batch-priser betyder, at regningen som regel lander under det.

Hvis du hellere vil have nogen til at se på dine tal sammen med dig, så få en gratis konsultation.