Wat LLM-tokens daadwerkelijk kosten en hoe u voor minder tokens kunt betalen

Elke API-factuur voor een taalmodel is een factuur voor tokens, en bijna niemand heeft een idee hoeveel tokens een bepaald stuk tekst bevat. Het resultaat is twee keer per maand dezelfde verrassing: een functie die tijdens het testen goedkoop aanvoelde, kost veertig keer meer in productie, of een contextvenster dat "zou moeten passen" wijst het verzoek af. Beide zijn rekenproblemen, en de rekenkunde is de moeite waard om een keer te leren.

Een teken is geen woord

Modellen lezen geen karakters of woorden. Ze lezen tokens: stukjes die worden geproduceerd door een bytepaar-encoder die tijdens de training heeft geleerd welke reeksen vaak genoeg voorkomen om hun eigen symbool te verdienen. Gemeenschappelijke Engelse woorden zijn één teken. Zeldzame exemplaren splitsen. Dus token is één en tokenization is drie, terwijl het een willekeurige reeks is x7Qp2 kan vijf kosten.

De vuistregels die het waard zijn om te dragen:

• Engels proza: ongeveer vier tekens per token, of ongeveer 0,75 tokens per woord. Een artikel van duizend woorden bestaat uit ongeveer 1.300 tokens.
• Code: aanzienlijk erger. Inspringing, interpunctie en camelCase-ID's zijn allemaal fragmentarisch. Budgeteer dichter bij drie tekens per token, en behandel verkleinde code als zijn eigen ramp: het tokeniseert slecht, juist omdat het ongebruikelijk is.
• Niet-Latijnse schriften: weer veel erger. Chinees, Japans en Koreaans landen doorgaans in de buurt van één token per één of twee tekens, dus dezelfde inhoud in het Japans kan meerdere malen kosten wat de Engelse versie kost. Cyrillisch en Grieks zitten daar tussenin.
• JSON: de interpunctie is echt geld. Elk aanhalingsteken, accolade, dubbele punt en komma maakt op zijn minst deel uit van een token, en diep geneste structuren met lange sleutelnamen kunnen meer uitgeven aan syntaxis dan aan waarden.

Vuistregels zijn voor het schatten. Als het er toe doet, tel dan: de LLM-token en kostencalculator tokeniseert wat u plakt en drukt de telling af, en het kan ook de tekst weergeven met de tokengrenzen gemarkeerd, wat de snelste manier is om te begrijpen waarom een van uw prompts onverwacht duur is. Het zien van uw eigen identificatienamen die elk in vier stukken uiteenvallen, verklaart veel.

Output kost vele malen meer dan input

De prijsdetails die mensen missen: providers brengen afzonderlijk kosten in rekening voor tokens die u verzendt en tokens die het model genereert, en de output is doorgaans vier tot acht keer de invoersnelheid. Een prompt met 10.000 tokens context en een antwoord van 200 tokens wordt gedomineerd door de invoer. Een prompt met 500 instructietokens die een essay van 4.000 tokens oplevert, wordt – sterk – gedomineerd door de output.

Dit keert veel optimalisatie-instincten om. Het inkorten van een systeemprompt van 900 naar 600 tokens bespaart heel weinig als het model bij elke oproep lange antwoorden schrijft. Het bespaart veel als u het model in drie zinnen in plaats van in drie alinea's laat antwoorden. Vraag aan welke kant van de transactie uw werklast eigenlijk leeft voordat u de verkeerde optimaliseert.

De rekenmachine prijst dezelfde tekst voor elk model in de tabel, zowel met invoer- als uitvoersnelheden, zodat u een goedkoop model dat het hele werk doet, kunt vergelijken met een duur model dat een deel ervan doet. De referentieprijzen worden lokaal opgeslagen en periodiek vergeleken met de pagina's van de aanbieders. Beschouw ze als een planningshulpmiddel en controleer ze op de eigen prijspagina van de aanbieder voordat u een budget vastlegt, omdat de tarieven veranderen.

Chat is kwadratisch, en dat is waar budgetten sterven

Een eenmalige API-aanroep kost wat het kost. Bij een gesprek wordt de hele geschiedenis elke beurt opnieuw verzonden, dus een chat van twintig beurten kost niet twintig keer één beurt; het kost ongeveer de som van een groeiende reeks. Draai twintig betaalt opnieuw voor de beurten één tot en met negentien.

Twee gevolgen. Ten eerste zijn langlopende agentlussen de duurste vorm van LLM-gebruik en is het waarschijnlijk dat er zonder meting een prototype van zal worden gemaakt. Ten tweede is prompt caching belangrijker dan welke formulering dan ook: providers geven korting op tokens die een voorvoegsel herhalen dat ze al hebben gezien, wat betekent dat je je stabiele inhoud (de systeemprompt, het schema, de voorbeelden) helemaal vooraan moet zetten en het variabele deel helemaal aan het einde. Herschik dezelfde prompt opnieuw, zodat een veranderende tijdstempel bovenaan staat en u de cache bij elke oproep ongeldig hebt gemaakt terwijl u niets anders hebt gewijzigd.

Een prompt verkleinen voordat u deze verzendt

De meeste te grote prompts zijn om saaie redenen te groot: iemand heeft een heel bestand geplakt terwijl er drie functies relevant waren, en het bestand bestaat uit half commentaar en lege regels. De LLM-contextcompressor is precies dat doel: het verwijdert codecommentaar, vouwt reeksen lege regels samen, verwijdert inkepingen en verwijdert opvulwoorden uit proza, en rapporteert vervolgens hoeveel tokens de trim heeft bespaard. Op een echt bronbestand dat routinematig 20-40% draait zonder iets aan te raken dat het model nodig heeft.

De handmatige bezuinigingen die daarvoor de moeite waard zijn:

1. Stuur fragmenten, geen bestanden. Modelaandacht is ook niet gratis; irrelevante context verslechtert de antwoorden meetbaar en kost ook geld.
2. Strip logboeken naar de falende regio. Tienduizend regels met succesvolle opstartresultaten dragen niets bij aan een diagnose.
3. Laat herhaalde boilerplate vallen. Licentieheaders, gegenereerde imports, dezelfde disclaimer op elk record.
4. Samenvatten in plaats van opnieuw verzenden. In een lang gesprek is het vervangen van de beurten één tot en met vijftien door een staatsparagraaf de grootste besparing die mogelijk is.

Wanneer de input echt niet past

Contextvensters zijn nu groot, maar 'groot' is nog steeds eindig, en een boek, een jaar aan logboeken of een volledig transcript zal groter zijn dan één. Splitsen is het standaardantwoord, en als je splitst, is het van belang: als je midden in de zin of middenfunctie snijdt, krijg je stukjes waar het model naar moet raden. De snelle splitter verdeelt de tekst in stukken met een door u gekozen grootte, waarbij de grenzen worden gerespecteerd, en nummert de delen zodat u ze op volgorde kunt invoeren, met aan elk een consistente instructie.

Een opmerking over eenheden: tokens zijn geen bytes. De UTF-8 byteteller beantwoordt een andere vraag – hoeveel ruimte de tekst inneemt op de draad of in een databasekolom – en de twee cijfers lopen sterk uiteen voor niet-Latijnse tekst, waar bytes per teken stijgen en tegelijkertijd tekens per token dalen. Gebruik bytes voor opslaglimieten en tokens voor modellimieten, en vervang nooit de een door de ander.

Een uitgewerkt voorbeeld

Stel dat u twintig vragen beantwoordt op een document van dertig pagina's. Dertig pagina's zijn ongeveer 15.000 woorden, dus ongeveer 20.000 tokens. Naïef stuur je het document bij elke vraag: 20 × 20.000 = 400.000 invoertokens, plus misschien 20 × 300 uitvoertokens.

Zet het document op de eerste plaats en houd het byte-identiek bij alle oproepen, en de meeste providers serveren het herhaalde voorvoegsel uit de cache tegen een fractie van de snelheid. Snijd eerst het document van de standaardplaat af en de basis krimpt ook. Verzamel vijf vragen per oproep in plaats van één en u verzendt het document vier keer in plaats van twintig. Dezelfde taak, hetzelfde model en een orde van grootte tussen de onzorgvuldige en de zorgvuldige versie – en dat is het hele punt van tellen voordat je verzendt.

Zowel de teller als de compressor draaien volledig in uw browser: de prompt die u prijst, wordt nergens geüpload om te worden gemeten.