Vad LLM-tokens faktiskt kostar och hur man betalar för färre av dem

Varje API-räkning för en språkmodell är en räkning för tokens, och nästan ingen har en intuition för hur många tokens en given text är. Resultatet är samma överraskning två gånger i månaden: en funktion som kändes billig vid testning kostar fyrtio gånger mer i produktion, eller ett sammanhangsfönster som "borde passa" avvisar begäran. Båda är aritmetiska problem, och aritmetiken är värd att lära sig en gång.

En token är inte ett ord

Modeller läser inte tecken eller ord. De läser tokens - bitar producerade av en byte-par-kodare som under träning lärde sig vilka sekvenser som förekommer tillräckligt ofta för att förtjäna sin egen symbol. Vanliga engelska ord är en symbol. Sällsynta delas. Så token är en och tokenization är tre, medan en slumpmässig sträng som x7Qp2 kan kosta fem.

Tumregler värda att bära:

• Engelsk prosa: ungefär fyra tecken per token, eller ungefär 0,75 tokens per ord. En artikel på tusen ord är cirka 1 300 tokens.
• Koda: betydligt värre. Indrag, skiljetecken och camelCase-identifierare är alla fragment. Budgetera närmare tre tecken per token och behandla minifierad kod som sin egen katastrof - den tokeniserar dåligt just för att den är ovanlig.
• Icke-latinska skript: mycket värre igen. Kinesiska, japanska och koreanska landar vanligtvis nära en token per ett eller två tecken, så samma innehåll på japanska kan kosta flera gånger vad den engelska versionen gör. Kyrilliska och grekiska sitter emellan.
• JSON: skiljetecken är riktiga pengar. Varje citattecken, klammerparentes, kolon och kommatecken är åtminstone en del av en token, och djupt kapslade strukturer med långa nyckelnamn kan spendera mer på syntax än på värden.

Tumregler är för uppskattning. När det gäller, räkna: den LLM token och kostnadskalkylator tokeniserar det du klistrar in och skriver ut räkningen, och den kan också visa texten med tokengränserna markerade, vilket är det snabbaste sättet att förstå varför en av dina uppmaningar är oväntat dyr. Att se dina egna identifierarnamn splittras i fyra delar vardera förklarar mycket.

Output kostar flera gånger mer än input

Prisinformationen som folk missar: leverantörer tar separat betalt för tokens du skickar och tokens som modellen genererar, och utmatningen är vanligtvis fyra till åtta gånger inmatningshastigheten. En prompt med 10 000 tokens av sammanhang och ett 200-tokens svar domineras av input. En prompt med 500 tokens av instruktion som producerar en 4 000-token uppsats domineras - kraftigt - av output.

Detta inverterar många optimeringsinstinkter. Att trimma en systemuppmaning från 900 till 600 tokens sparar mycket lite om modellen skriver långa svar varje samtal. Att säga åt modellen att svara i tre meningar istället för tre stycken sparar mycket. Fråga vilken sida av transaktionen din arbetsbörda faktiskt lever på innan du optimerar fel.

Kalkylatorn prissätter samma text mot varje modell i sin tabell vid både inmatnings- och utmatningshastigheter, så du kan jämföra en billig modell som gör hela jobbet med en dyr modell som gör en del av det. Referenspriserna lagras lokalt och kontrolleras mot leverantörssidor med jämna mellanrum - behandla dem som ett planeringshjälp och bekräfta mot leverantörens egen prissättningssida innan du binder dig till en budget, eftersom priserna flyttas.

Chatten är kvadratisk, och det är där budgetar dör

Ett engångs-API-anrop kostar vad det kostar. En konversation skickar om hela historiken vid varje tur, så en tjugovarvs chatt kostar inte tjugo gånger ett varv – det kostar ungefär summan av en växande serie. Vänderna tjugo betalar för turerna ett till nitton igen.

Två konsekvenser. För det första är långvariga agentslingor den dyraste formen för LLM-användning och den som med största sannolikhet är prototyp utan mätning. För det andra är snabbcachning viktigare än någon formuleringsändring: leverantörer rabatterar tokens som upprepar ett prefix de redan har sett, vilket innebär att du placerar ditt stabila innehåll - systemprompten, schemat, exemplen - längst fram och den variabla delen i slutet. Ordna om samma prompt så att en ändrad tidsstämpel sitter högst upp och du har ogiltigförklarat cachen vid varje samtal samtidigt som du inte ändrar något annat.

Förminska en prompt innan du skickar den

De flesta överdimensionerade prompter är överdimensionerade av tråkiga skäl: någon klistrade in en hel fil när tre funktioner var relevanta, och filen är halva kommentarer och tomma rader. De LLM-kontextkompressor riktar in sig på exakt det - den tar bort kodkommentarer, kollapsar rader av tomma rader, bucklor och tar bort fyllnadsord från prosa, och rapporterar sedan hur många tokens trimmen sparat. På en riktig källfil som rutinmässigt kör 20–40 % utan att röra något som modellen behöver.

De manuella snitten som är värda att göra innan dess:

1. Skicka utdrag, inte filer. Modelluppmärksamhet är inte heller gratis; irrelevant kontext försämrar svaren mätbart och kostar pengar.
2. Ta bort loggar till den felaktiga regionen. Tio tusen rader av framgångsrik startoutput bidrar ingenting till en diagnos.
3. Släpp upprepade boilerplate. Licenshuvuden, genererade importer, samma ansvarsfriskrivning på varje post.
4. Sammanfatta istället för att skicka om. I en lång konversation är det den enskilt största besparingen som finns att ersätta år ett till femton med ett stycke om tillstånd.

När ingången verkligen inte passar

Kontextfönster är stora nu, men "stor" är fortfarande ändlig, och en bok, ett år med loggar eller en fullständig avskrift kommer att överstiga ett. Dela är standardsvaret, och var du delar upp spelar roll: skära mitten av mening eller mellanfunktion producerar bitar som modellen måste gissa sig till. De snabb splitter delar upp text i bitar i en storlek du väljer samtidigt som du respekterar gränserna, och numrerar delarna så att du kan mata dem i ordningsföljd med en konsekvent instruktion bifogad till varje.

En notering om enheter: tokens är inte byte. De UTF-8 byte räknare svarar på en annan fråga - hur mycket utrymme texten tar på tråden eller i en databaskolumn - och de två siffrorna skiljer sig kraftigt åt för icke-latinsk text, där byte per tecken stiger samtidigt som tecken per token faller. Använd bytes för lagringsgränser och tokens för modellgränser, och ersätt aldrig den ena med den andra.

Ett fungerande exempel

Anta att du svarar på tjugo frågor mot ett trettiosidigt dokument. Trettio sidor är cirka 15 000 ord, alltså ungefär 20 000 tokens. Naivt skickar du dokumentet med varje fråga: 20 × 20 000 = 400 000 inmatningstoken, plus kanske 20 × 300 utmatningstoken.

Sätt dokumentet först och håll det byte-identiskt över samtal, och de flesta leverantörer serverar det upprepade prefixet från cachen till en bråkdel av hastigheten. Klipp till dokumentet på pannplåten först och basen krymper också. Gruppera fem frågor per samtal istället för en och du skickar dokumentet fyra gånger istället för tjugo. Samma uppgift, samma modell och en storleksordning mellan den slarviga versionen och den försiktiga - vilket är hela poängen med att räkna innan du skickar.

Både räknaren och kompressorn körs helt och hållet i din webbläsare: uppmaningen du prissätter laddas inte upp någonstans för att mätas.