Vinster:
- Förklara begreppet token, input/output token distinktion och tokenization.
- Kan beräkna kostnaden för en förfrågan och en månatlig arbetsbelastning utifrån antalet polletter och enhetspris
- Kan jämföra effekten av modellval och snabb längd på kostnaden
Du kan inte bygga en lösning i stor skala utan att förstå ekonomin med LLM API:er. En demo körs en gång; Huvudsaken är att kunna förutse vad notan blir när tusentals samtal rings per månad. I den här enheten ställer vi upp pengarna: vad är en token, varför in- och utdata prissätts olika, hur man beräknar kostnaden för en förfrågan och hur man budgeterar en månatlig arbetsbelastning. Denna information låter dig mäta avkastningen av optimeringstekniker (cachelagring, modellval, batch) i efterföljande enheter.
Vad är Token?
Token är den minsta enhet där modellen bearbetar text. Ett ord är inte alltid ett tecken; token är vanligtvis en del av ett ord. Grovt sett, på engelska, är 1 token ≈ 4 tecken ≈ 0,75 ord. På turkiska och kod varierar förhållandet: turkiska ord delas ofta in i fler tokens än på engelska på grund av dess suffixstruktur och alfabet. Därför är det nödvändigt att mäta antalet tokens med leverantörens token-räkneverktyg snarare än att gissa med ögat.
Tokenisering (processen att dela upp text i tokens) kan vara olika för varje modell. Detta har två praktiska konsekvenser: (1) Samma text kan ge olika antal tokens i olika modeller; (2) Förutsägelser gjorda med tokenizers från andra leverantörer (t.ex. OpenAIs tiktoken-bibliotek) kommer att vara felaktiga för Claude – använd tokenräkningstipset för modellen du använder.
Tips: "Om hur många tokens?" Svara inte blint på frågan. Skicka en representativ text genom API:et för tokenräkning; Basera budgetbeslut på mätning.
Ingångs- och utgångstokens
Fakturan består av två poster:
- Inmatningstokens: Allt du skickar till modellen — systemuppmaning, tidigare turer, användarmeddelande, eventuell dokumentation. Dessa behandlas på en gång.
- Output tokens: Svaret som produceras av modellen. För varje utdatatoken utför modellen beräkningen steg för steg.
Hos de flesta leverantörer är utdata flera gånger dyrare än input. Anledningen är enkel: att läsa indata på en gång är billigare än att producera utdata-token-för-token. Att känna till denna asymmetri förklarar varför optimeringar som "kräver kortfattade svar" är så effektiva.
Provpriser (per 1 miljon tokens, USD)
Tabellen nedan är en referens; Priserna kan ändras med tiden, bekräfta din egen leverantörs aktuella lista.
modellklass
exempelmodell
Indata ($/1M)
Output ($/1M)
Typisk användning
snabbt/billigt
Haiku 4.5
1.00
5.00
Klassificering, märkning, enkel sammanfattning
balanserad
sonett 5
3.00
15.00
Allmänt bruk, kodning, agentarbete
stark
Opus 4.8
5.00
25.00
Komplexa resonemang, långsiktiga uppgifter
I varje klass är utgången 5 gånger ingången; Dessutom är till och med ingången från den kraftfulla modellen 5 gånger ingången från den billiga modellen. Dessa två axlar (input↔utgång och modellklass) utgör ramen för dina kostnadsbeslut.
Hur beräknar man kostnad?
Formeln är enkel:
kostnad = (input_token / 1 000 000) × input_price + (output_token / 1 000 000) × output_price
Exempelkonto. En förfrågan med Sonnet 5: 1 500 inmatade tokens, 400 output-tokens.
input = 1 500 / 1 000 000 × 3,00 = 0,0045 USD utdata = 400 / 1 000 000 × 15,00 = 0,0060 USD totalt = 0,0105 USD (cirka 1 cent)
Ett samtal ser billigt ut. Men multiplicera med volym: 20 000 samtal per dag → 210 USD per dag, ~6 300 USD per månad. Det är här skalan spelar in.
Månadsbudgetmall
För att extrahera månadskostnaden för en arbetsbelastning, använd den här mallen:
1) Genomsnittlig indatatoken per begäran: ......2) Genomsnittlig utdatatoken per begäran: ......3) Antal förfrågningar per dag: ......4) Arbetade dagar per månad: ......5) Kostnad per förfrågan = (1)/1M×input_pris + (2)/1M×output_price6) Månadskostnad = (5)) × (3) × (4)
Att hälla det här mönstret i ett kalkylblad och se hur summan blir när du ändrar modellen förkroppsligar valet av modell (enhet 5) och cache (enhet 6).
Förkorta prompten med kopierbara mallar
Merparten av kostnaderna kommer från onödigt långa uppmaningar och bortkastad produktion. Mallarna nedan ger direkta besparingar.
# Begränsa utgångslängden. Svara med max 3 objekt. Lägg till en motivering eller inledande mening.
# Returnera endast det begärda fältet Returnera endast följande JSON, lägg inte till någon annan text:{"category": "...", "urgency": "low|medium|high"}
# Ta bort onödigt sammanhang Ta bort endast datum och belopp från följande text. Upprepa inte hela texten.Text: """{{text}}"""
# Sammanfatta det långa talet (spara indata) Sammanfatta det här talet i 5 punkter. Jag kommer att använda denna sammanfattning istället för hela det förflutna i efterföljande omgångar. Tal: """{{förbi}}"""
Svag prompt / Stark prompt (kostnadsmässigt)
# SVAG (släpper utdata, dyrt) Analysera denna supportförfrågan och skriv en omfattande recension till mig.
# STARK (begränsar produktionen, billig och förutsägbar) Klassificera denna supportförfrågan. Returnera bara följande JSON:{"category":"invoice|technical|refund|other","urgency":"low|medium|high"}Skriv inte en beskrivning.
Den svaga versionen producerar kanske 500 output-tokens; stark version ~15. Eftersom produktionen är dyr är detta en betydande skillnad per samtal och multipliceras med volymen.
Tre minifodral
Fall 1 — Den dolda kostnaden för den långa uppmaningen. När en bokföringsautomatisering sorterade varje faktura, lade den till en 40-sidig "regelbok" som indata till varje begäran: ~12 000 inmatningstoken per begäran. Med Sonnet 5 12 000/1M×3 = $0,036 just in. 5 000 räkningar per dag → 180 USD per dag. Genom att cachelagra regelboken (enhet 6) sjönk indatakostnaden med ~90 %.
Fall 2 — Utdelningen av att minska modellen. Ett team gjorde enkel "positiv/negativ" sentimenttaggning med Opus 4.8: 300 input + 10 output tokens. Opus kostar 300/1M×5 + 10/1M×25 = $0,00175. Byte till Haiku, 300/1M×1 + 10/1M×5 = $0,00035 — 5 gånger billigare, skillnaden i noggrannhet var omätbar. På 3 miljoner samtal per månad är skillnaden 5 250 $ → 1 050 $.
Fall 3 — Släpp utgången. När ett marknadsföringsteam tog fram en produktbeskrivning satte det inga gränser för produktionen; modellen sa ibland 1 500 polletter. När jag lade till instruktionen "max 60 ord" sjönk den genomsnittliga produktionen från 900 till 90 tokens. Eftersom utskriften var dyr sänktes månadsräkningen med en tredjedel och texter blev mer användbara.
Vanliga misstag
- Gissa symbolen med ögat: Du kan ha fel, särskilt på turkiska och kod. Mäta.
- Förutsatt att input och output är samma: Output är vanligtvis mycket dyrare; Det mesta av optimeringen kommer från att förkorta produktionen.
- Låt dig inte luras av det billiga med ett enda samtal: Beslutet fattas efter volym. 0,01 USD × miljoner = 10 000 USD.
- Förutsägelse med en annan leverantörs tokenizer: Ger felaktiga resultat; Använd modellens verktyg för tokenräkning.
- Obegränsad förstoring av konversationshistorik: Varje omgång läggs till inlägget; sammanfatta i långa samtal.
- Att hålla `max_tokens` onödigt högt: Döljer budgetplanen och risken att skäras ned; Ge ett realistiskt värde.
Djupare: Kontextfönster och lång ingångskostnad
Det är viktigt att se hur priset ligger "över hela konversationen" och inte bara "per begäran". Den totala mängden text som modellen kan bearbeta kallas kontextfönstret; Summan av input och output måste passa in i detta fönster. Moderna modeller erbjuder mycket stora fönster (hundratusentals, till och med miljontals tokens), men det betyder inte att du kan "fylla det oändligt" - vad du än stoppar i fönstret faktureras som indata.
Fällan i långa samtal är denna: med varje ny omgång skickar du hela historien igen (statslöshet i enhet 1). I en konversation på 20 omgångar har den 20:e begäran de första 19 omgångarna som input. Allteftersom samtalet blir längre, växer kostnaden per förfrågan kumulativt snarare än linjärt. Ett 50-tals samtal med en agentassistent kan ge insatskostnader dussintals gånger den första omgången.
Det finns två sätt att hantera detta. Den första är en sammanfattning: att komprimera äldre omgångar till ett enda sammanfattningsblock, så att endast de sista rundorna hålls råa. Det andra är prompt caching (enhet 6): läser det fasta sammanhanget till en tiondel av priset istället för att upprepade gånger bearbeta det till fullt pris. Tillsammans minskar de avsevärt räkningen på långa, kontextintensiva arbetsbelastningar. Så symbolekonomi handlar om utformningen av hela sessionen, inte en enda begäran.
Sammanfattningsvis
Token är den minsta enhet där text bearbetas; input och output prissätts separat, och output är ofta mycket dyrare. Kostnaden är antalet tokens multiplicerat med enhetspriset, och det verkliga beslutet fattas efter volym. Att förkorta prompten, begränsa produktionen och välja den lättaste modellen som klarar uppgiften är de mest direkta spakarna som reducerar kostnaden många gånger om.
Applikationsuppgift
Välj en egen uppgift. (1) Bestäm antalet indata och uppskattade utdata för en representativ prompt (mät med ett token-räkneverktyg om möjligt). (2) Beräkna kostnaden per förfrågan för de tre modellklasserna. (3) Uppskatta ditt dagliga antal förfrågningar och härled månadsbudgeten för de tre modellerna. (4) Lägg till en instruktion för att förkorta produktionen och notera de förväntade besparingarna.
checklista
- [ ] Jag kan förklara begreppet tokens och att tokeniseringen varierar beroende på modell.
- [ ] Jag vet varför input- och output-tokens prissätts olika.
- [ ] Jag kan beräkna kostnaden för en förfrågan med formeln.
- [ ] Jag kan skapa en månadsbudget för en arbetsbelastning med hjälp av en mall.
- [ ] Jag kan med ett exempel visa fördelen med att förkorta produktionen och modellreduktion.