Hvorfor output-tokens i LLM-API-er koster 4-8x mer enn input-tokens

Se på prissiden til ethvert stort LLM-API — OpenAI, Anthropic, Google, det spiller ingen rolle — og du vil legge merke til samme form hver gang: output-tokens koster flere ganger mer enn input-tokens. Ikke en liten prispåslag heller. På tvers av dagens modeller ligger forholdet konsekvent mellom 4x og 8x. Dette er ikke en pris-quirk spesifikk for én leverandør; det er en direkte konsekvens av hvordan disse modellene faktisk kjører.

Den virkelige grunnen: input er parallelt, output er sekvensielt

Å behandle input-tokens — prompten din, systemmeldingen, samtalehistorikken — skjer i én enkelt fremoverpassering. Modellen leser hele inputen på én gang og beregner oppmerksomhet (attention) over alt sammen parallelt. Moderne GPU-er er ekstremt gode på denne typen batchet, parallell beregning, så en prompt på 3000 tokens og en på 300 tokens koster ikke proporsjonalt så mye beregningstid som antall tokens skulle tilsi — overheaden ved å kjøre modellen én gang er den dominerende kostnaden, ikke lengden på det den leser.

Å generere output-tokens er fundamentalt annerledes. Hver nye token avhenger av hver token som kom før den, inkludert de modellen nettopp genererte — så token 500 i et svar kan ikke beregnes før token 499 finnes. Det tvinger frem en sekvensiell løkke: én fremoverpassering per output-token, kjørt etter hverandre, uten noen måte å parallellisere på tvers av sekvensen. Å produsere 500 output-tokens betyr å kjøre modellen 500 ganger på rad, ikke én gang.

Denne asymmetrien i beregning — én parallell passering for input, N sekvensielle passeringer for N output-tokens — er hvorfor prisingen til alle store leverandører ser lik ut uansett selskap, modellarkitektur eller region. Det er ikke så mye en forretningsbeslutning som en direkte videreføring av den underliggende beregningskostnaden.

Hva dette betyr for prompter dine

Den praktiske lærdommen er rett frem: et ordrikt modellsvar koster uforholdsmessig mer enn en lang prompt med et kort svar, selv når det totale antallet tokens ser likt ut. Hvis du prøver å redusere API-forbruket, sparer det å kutte output-lengde vanligvis mer per token enn å kutte input-lengde.

Noen konkrete håndtak:

• Sett en eksplisitt grense for svarlengde. En systemprompt-instruksjon som «svar i ett avsnitt» eller en max_tokens-grense gjør mer for kostnaden enn å forkorte din egen prompt.
• Be om strukturert output i stedet for løpende tekst. Et JSON-objekt med tre felt er ofte langt kortere enn det tilsvarende forklart i setninger, og like nyttig videre i kjeden.
• Ikke overforklar i systemprompten for å spare på output. En lengre, mer presis systemprompt (input, billig) som pålitelig gir et kort, korrekt svar (output, dyrt) er som regel en bedre avveining enn en kort, vag prompt som får modellen til å sikre seg med et langt svar.
• Bruk en billigere modell for høyt volum, lav kompleksitet. Hvis en oppgave ikke trenger frontlinje-modell-resonnering — klassifisering, ekstraksjon, korte svar — er ofte prisingen for output hos en budsjettmodell en størrelsesorden lavere.

Å regne ut det faktiske dollarbeløpet

Forholdstallet forklarer hvorfor output koster mer, men det eksakte dollarbeløpet avhenger av hvilken modell du bruker og hvor mange tokens hver side av en forespørsel faktisk forbruker. Siden input/output-fordelingen — og multiplikatoren mellom dem — faktisk varierer fra modell til modell (en budsjettmodell og en flaggskipmodell bruker ikke samme forhold), er den eneste pålitelige måten å kjenne din reelle kostnad på å legge inn dine faktiske tall per modell.

CodeKitHubs LLM API Pricing Calculator gjør nettopp det: velg modellen din, angi antall input- og output-tokens, og den viser inputkostnad, outputkostnad og totalt — pluss et månedlig estimat hvis du vet omtrent hvor mange forespørsler du kommer til å gjøre. Hvis du ikke er sikker på hvor mange tokens din faktiske prompt bruker, gir Token Counter-verktøyet deg det eksakte antallet ved hjelp av den ekte tokenizeren, i stedet for en grov, tegnbasert gjetning.

Begge kjører helt i nettleseren din — ingen API-nøkkel, ingen konto, ingenting sendes noe sted.