Gevinster:
- Forklar begrepet token, input/output token distinktion og tokenization.
- Kan beregne kostnaden for en forespørsel og en månedlig arbeidsbelastning fra antall tokens og enhetspris
- Kan sammenligne innvirkningen av modellvalg og promptlengde på kostnadene
Du kan ikke bygge en løsning i stor skala uten å forstå økonomien til LLM APIer. En demo kjører én gang; Hovedsaken er å kunne forutsi hva regningen blir når det foretas tusenvis av samtaler per måned. I denne enheten setter vi opp pengesiden av ting: hva er en token, hvorfor input og output prises forskjellig, hvordan beregne kostnadene for en forespørsel, og hvordan budsjettere en månedlig arbeidsmengde. Denne informasjonen lar deg måle avkastningen av optimaliseringsteknikker (caching, modellvalg, batch) i påfølgende enheter.
Hva er Token?
Token er den minste enheten der modellen behandler tekst. Et ord er ikke alltid et symbol; token er vanligvis en del av et ord. Grovt sett, på engelsk, er 1 token ≈ 4 tegn ≈ 0,75 ord. På tyrkisk og kode varierer forholdet: Tyrkiske ord er ofte delt inn i flere tokens enn på engelsk på grunn av suffikset struktur og alfabet. Derfor er det nødvendig å måle antall tokens med leverandørens token-telleverktøy i stedet for å gjette med øyet.
Tokenisering (prosessen med å dele opp tekst i tokens) kan være forskjellig for hver modell. Dette har to praktiske konsekvenser: (1) Den samme teksten kan gi ulikt antall tokens i forskjellige modeller; (2) Spådommer laget med tokenizere fra andre leverandører (f.eks. OpenAIs tiktoken-bibliotek) vil være unøyaktige for Claude – bruk token-telletipset for modellen du bruker.
Hint: "Omtrent hvor mange tokens?" Ikke svar blindt på spørsmålet. Send en representativ tekst gjennom token counting API; Baser budsjettbeslutninger på måling.
Input og Output Tokens
Fakturaen består av to poster:
- Input tokens: Alt du sender til modellen - systemmelding, tidligere turer, brukermelding, dokumentasjon hvis noen. Disse behandles på en gang.
- Output tokens: Responsen produsert av modellen. For hvert utdatatoken utfører modellen beregningen trinn for trinn.
Hos de fleste tilbydere er utdata flere ganger dyrere enn input. Årsaken er enkel: å lese inndataene på en gang er billigere enn å produsere utdata-token-for-token. Å kjenne denne asymmetrien forklarer hvorfor optimaliseringer som "krever konsise svar" er så effektive.
Prøvepriser (per 1 million tokens, USD)
Tabellen nedenfor er en referanse; Prisene kan endre seg over tid, vennligst bekreft din egen leverandørs gjeldende liste.
modellklasse
eksempelmodell
Inndata ($/1 mill.)
Utgang ($/1 mill.)
Typisk bruk
rask/billig
Haiku 4.5
1.00
5.00
Klassifisering, merking, enkel oppsummering
balansert
sonett 5
3.00
15.00
Generelle formål, koding, agentarbeid
sterk
Opus 4.8
5.00
25.00
Kompleks resonnement, langsiktige oppgaver
I hver klasse er utgangen 5 ganger inngangen; Dessuten er selv inngangen til den kraftige modellen 5 ganger inngangen til den billige modellen. Disse to aksene (input↔output og modellklasse) danner rammen for kostnadsbeslutningene dine.
Hvordan beregne kostnad?
Formelen er enkel:
kostnad = (input_token / 1 000 000) × input_price + (output_token / 1 000 000) × output_price
Eksempelkonto. En forespørsel med Sonnet 5: 1500 input tokens, 400 output tokens.
input = 1 500 / 1 000 000 × 3,00 = $ 0,0045 output = 400 / 1 000 000 × 15,00 = $ 0,0060 totalt = $ 0,0105 (ca. 1 cent)
En samtale ser billig ut. Men multipliser med volum: 20 000 anrop per dag → $210 per dag, ~$6300 per måned. Det er her skala spiller inn.
Månedlig budsjettmal
For å trekke ut den månedlige kostnaden for en arbeidsbelastning, bruk denne malen:
1) Gjennomsnittlig input-token per forespørsel: ......2) Gjennomsnittlig output-token per forespørsel: ......3) Antall forespørsler per dag: ......4) Arbeidsdager per måned: ......5) Kostnad per forespørsel = (1)/1M×input_price + (2)/1M×output_price6) Månedlig kostnad = (5) × (3) × (4)
Å helle dette mønsteret inn i et regneark og se hvordan summen blir når du endrer modellen, legemliggjør valg av modell (enhet 5) og hurtigbuffer (enhet 6).
Forkorte ledeteksten med kopierbare maler
Mesteparten av kostnadene kommer fra unødvendig lange oppfordringer og bortkastet produksjon. Malene nedenfor gir direkte besparelser.
# Begrens utgangslengden. Svar med maks 3 punkter. Legg til en begrunnelse eller innledende setning.
# Returner kun det forespurte feltet Returner kun følgende JSON, ikke legg til noen annen tekst:{"category": "...", "urgency": "low|medium|high"}
# Fjern unødvendig kontekstFjern kun dato og beløp fra følgende tekst. Ikke gjenta hele teksten.Tekst: """{{text}}"""
# Oppsummer den lange talen (lagring av input) Oppsummer denne talen i 5 punkter. Jeg vil bruke denne oppsummeringen i stedet for hele fortiden i påfølgende runder. Tale: """{{past}}"""
Svak forespørsel / sterk forespørsel (med tanke på kostnad)
# SVAK (utgir utgang, dyrt) Analyser denne støtteforespørselen og skriv meg en omfattende anmeldelse.
# STERK (begrenser produksjon, billig og forutsigbar) Klassifiser denne støtteforespørselen. Bare returner følgende JSON:{"category":"invoice|technical|refund|other","urgency":"low|medium|high"}Ikke skriv en beskrivelse.
Den svake versjonen produserer kanskje 500 output-tokens; sterk versjon ~15. Fordi produksjonen er dyr, er dette en betydelig forskjell per samtale og multipliseres med volumet.
Tre minivesker
Tilfelle 1 - Den skjulte kostnaden ved den lange forespørselen. Ettersom en regnskapsautomatisering sorterte hver faktura, la den til en 40-siders "regelbok" som input til hver forespørsel: ~12 000 input-tokens per forespørsel. Med Sonnet 5 12,000/1M×3 = $0,036 nettopp lagt inn. 5000 regninger per dag → $180 per dag. Ved å bufre regelboken (enhet 6) falt inndatakostnadene med ~90 %.
Case 2 — Gevinsten ved å redusere modellen. Ett team gjorde enkel "positiv/negativ" sentimenttagging med Opus 4.8: 300 input + 10 output tokens. Opus koster 300/1M×5 + 10/1M×25 = $0,00175. Bytte til Haiku, 300/1M×1 + 10/1M×5 = $0,00035 — 5 ganger billigere, forskjellen i nøyaktighet var umålelig. På 3 millioner samtaler per måned er forskjellen $5250 → $1050.
Tilfelle 3 — Frigjøring av utgangen. Når et markedsføringsteam produserte en produktbeskrivelse, satte det ingen begrensninger på produksjonen; modellen sa noen ganger 1500 tokens. Da jeg la til "60 ord maksimum"-instruksjonen, falt den gjennomsnittlige produksjonen fra 900 til 90 tokens. Siden utskriften var dyr, ble den månedlige regningen redusert med en tredjedel, og tekstene ble mer nyttige.
Vanlige feil
- Gjett symbolet med øyet: Du kan ta feil, spesielt på tyrkisk og kode. Måle.
- Forutsatt at input og output er det samme: Output er vanligvis mye dyrere; Mesteparten av optimaliseringen kommer fra å forkorte produksjonen.
- Ikke la deg lure av det billige ved en enkelt samtale: Avgjørelsen tas etter volum. $0,01 × millioner = $10 000.
- Prediksjon med en annen leverandørs tokenizer: Gir feil resultater; Bruk modellens token-telleverktøy.
- Ubegrenset utvidelse av samtalehistorikk: Hver runde legges til oppføringen; oppsummere i lange samtaler.
- Holde `max_tokens` unødvendig høyt: Skjuler budsjettplanen og risikoen for å bli kuttet; Gi en realistisk verdi.
Dypere: kontekstvindu og lange inndatakostnader
Det er viktig å se hvordan prisen henger sammen «på tvers av samtalen» og ikke bare «per forespørsel». Den totale tekstmengden som modellen kan behandle kalles kontekstvinduet; Summen av input og output må passe inn i dette vinduet. Moderne modeller tilbyr veldig store vinduer (hundretusenvis, til og med millioner av tokens), men det betyr ikke at du kan "fylle det i det uendelige" - uansett hva du legger inn i vinduet faktureres som input.
Fellen i lange samtaler er denne: For hver ny runde sender du hele historien på nytt (statsløshet i enhet 1). I en samtale på 20 runder har den 20. forespørselen hele de første 19 rundene som input. Dermed, ettersom samtalen blir lengre, vokser kostnaden per forespørsel kumulativt i stedet for lineært. En samtale på 50 runder med en agentassistent kan gi inngangskostnader dusinvis av ganger den første runden.
Det er to måter å håndtere dette på. Den første er oppsummering: å komprimere eldre runder til en enkelt oppsummeringsblokk, og bare holde de siste rundene rå. Den andre er hurtigbufring (enhet 6): lesing av den faste konteksten til en tiendedel av prisen i stedet for gjentatte ganger å behandle den til full pris. Sammen reduserer de regningen på lange, kontekstkrevende arbeidsmengder betydelig. Så symbolsk økonomi handler om utformingen av hele økten, ikke en enkelt forespørsel.
Oppsummert
Token er den minste enheten som tekst behandles i; input og output prises separat, og output er ofte mye dyrere. Kostnaden er antall tokens multiplisert med enhetsprisen, og den virkelige avgjørelsen tas etter volum. Å forkorte forespørselen, begrense produksjonen og velge den letteste modellen som utfører oppgaven er de mest direkte spakene som reduserer kostnadene mange ganger.
Søknadsoppgave
Velg en egen oppgave. (1) Bestem antall input- og estimerte utdata-tokens for en representativ ledetekst (mål med et token-telleverktøy hvis mulig). (2) Beregn kostnaden per forespørsel for de tre modellklassene. (3) Estimer ditt daglige antall forespørsler og utled det månedlige budsjettet for de tre modellene. (4) Legg til en instruksjon for å forkorte produksjonen og legg merke til de forventede besparelsene.
sjekkliste
- [ ] Jeg kan forklare begrepet tokens og at tokenisering varierer avhengig av modellen.
- [ ] Jeg vet hvorfor input- og output-tokens er priset forskjellig.
- [ ] Jeg kan beregne kostnadene for en forespørsel med formelen.
- [ ] Jeg kan opprette et månedlig budsjett for en arbeidsmengde ved å bruke en mal.
- [ ] Jeg kan med et eksempel vise fordelen ved å forkorte produksjonen og modellreduksjon.