Eenheid 2 / 11

Token- en prijslogica

Winst:

  • Leg het concept van token, het onderscheid tussen input/output-tokens en tokenisatie uit.
  • Kan de kosten van een verzoek en de maandelijkse werklast berekenen op basis van het aantal tokens en de eenheidsprijs
  • Kan de impact van modelselectie en promptlengte op de kosten vergelijken

U kunt geen oplossing op schaal bouwen zonder de economische aspecten van LLM API's te begrijpen. Een demo draait één keer; Het belangrijkste is om te kunnen voorspellen wat de rekening zal zijn als er duizenden oproepen per maand worden gedaan. In dit onderdeel hebben we de geldkant van de zaak besproken: wat is een token, waarom invoer en uitvoer verschillend geprijsd zijn, hoe de kosten van een verzoek berekend worden en hoe een maandelijkse werklast gebudgetteerd kan worden. Met deze informatie kunt u het rendement van optimalisatietechnieken (caching, modelselectie, batch) in volgende eenheden meten.

Wat is token?

Token is de kleinste eenheid waarin het model tekst verwerkt. Een woord is niet altijd een teken; token is meestal een deel van een woord. In het Engels is 1 token grofweg ≈ 4 tekens ≈ 0,75 woorden. In het Turks en codetaal varieert de verhouding: Turkse woorden zijn vaak verdeeld in meer tokens dan in het Engels vanwege de achtervoegselstructuur en het alfabet. Daarom is het noodzakelijk om het aantal tokens te meten met de tokenteltool van de aanbieder, in plaats van met het oog te raden.

Tokenisatie (het proces waarbij tekst in tokens wordt gesplitst) kan voor elk model anders zijn. Dit heeft twee praktische gevolgen: (1) Dezelfde tekst kan verschillende aantallen tokens opleveren in verschillende modellen; (2) Voorspellingen gemaakt met tokenizers van andere providers (bijvoorbeeld de tiktoken-bibliotheek van OpenAI) zullen onnauwkeurig zijn voor Claude - gebruik de tip voor het tellen van tokens voor het model dat u gebruikt.

Hint: "Hoeveel tokens ongeveer?" Beantwoord de vraag niet blindelings. Geef een representatieve tekst door via de tokentelling-API; Baseer budgetbeslissingen op metingen.

Invoer- en uitvoertokens

De factuur bestaat uit twee onderdelen:

  • Invoertokens: alles wat u naar het model verzendt: systeemprompt, eerdere rondleidingen, gebruikersbericht, eventuele documentatie. Deze worden in één keer verwerkt.
  • Uitvoertokens: het antwoord dat door het model wordt geproduceerd. Voor elk uitvoertoken voert het model de berekening stap voor stap uit.

Bij de meeste aanbieders is output vele malen duurder dan input. De reden is simpel: het in één keer lezen van de invoer is goedkoper dan het token voor token produceren van de uitvoer. Het kennen van deze asymmetrie verklaart waarom optimalisaties zoals “beknopte antwoorden vereisen” zo effectief zijn.

Voorbeeldprijzen (per 1 miljoen tokens, USD)

Onderstaande tabel is een referentie; Prijzen kunnen in de loop van de tijd veranderen. Controleer de huidige lijst van uw eigen provider.

model klasse

voorbeeldmodel

Invoer ($/1M)

Uitvoer ($/1M)

Typisch gebruik

snel/goedkoop

Haiku 4.5

1.00

5.00 uur

Classificatie, etikettering, eenvoudige samenvatting

evenwichtig

sonnet 5

3.00 uur

15.00 uur

Algemeen doel, codering, agentwerk

sterk

Opus 4.8

5.00 uur

25.00 uur

Complex redeneren, taken op lange termijn

In elke klasse is de output vijf keer de input; Bovendien is zelfs de input van het krachtige model vijf keer de input van het goedkope model. Deze twee assen (input↔output en modelklasse) vormen het raamwerk van uw kostenbeslissingen.

Hoe de kosten berekenen?

De formule is eenvoudig:

kosten = (input_token / 1.000.000) × input_price + (output_token / 1.000.000) × output_price

Voorbeeldrekening. Een verzoek met Sonnet 5: 1.500 invoertokens, 400 uitvoertokens.

input = 1.500 / 1.000.000 × 3,00 = $0,0045 output = 400 / 1.000.000 × 15,00 = $0,0060 totaal = $0,0105 (ongeveer 1 cent)

Eén telefoontje lijkt goedkoop. Maar vermenigvuldig met volume: 20.000 oproepen per dag → $210 per dag, ~$6.300 per maand. Dit is waar schaalgrootte een rol speelt.

Maandelijkse budgetsjabloon

Gebruik deze sjabloon om de maandelijkse kosten van een werkbelasting te berekenen:

1) Gemiddelde inputtoken per verzoek: ......2) Gemiddelde outputtoken per verzoek: ......3) Aantal verzoeken per dag: ......4) Gewerkte dagen per maand: ......5) Kosten per verzoek = (1)/1M×input_price + (2)/1M×output_price6) Maandelijkse kosten = (5) × (3) × (4)

Door dit patroon in een spreadsheet te gieten en te zien hoe de som zich afspeelt wanneer u het model wijzigt, worden de beslissingen over modelselectie (eenheid 5) en cache (eenheid 6) belichaamd.

De prompt verkorten met kopieerbare sjablonen

Het grootste deel van de kosten komt voort uit onnodig lange prompts en verspilde output. Onderstaande sjablonen zorgen voor directe besparingen.

# Beperk de uitvoerlengte. Antwoord met maximaal 3 items. Voeg een reden of inleidende zin toe.

# Retourneer alleen het gevraagde veld Retourneer alleen de volgende JSON, voeg geen andere tekst toe:{"category": "...", "urgency": "low|medium|high"}

# Verwijder onnodige contextVerwijder alleen de datum en het bedrag uit de volgende tekst. Herhaal niet de hele tekst.Tekst: """{{text}}"""

# Vat de lange toespraak samen (invoerbesparing) Vat deze toespraak samen in 5 items. Deze samenvatting zal ik in volgende rondes gebruiken in plaats van het volledige verleden. Toespraak: """{{verleden}}"""

Zwakke prompt/sterke prompt (in termen van kosten)

# ZWAK (geeft uitvoer vrij, duur)Analyseer dit ondersteuningsverzoek en schrijf mij een uitgebreide recensie.

# STERK (beperkt output, goedkoop en voorspelbaar) Classificeer dit ondersteuningsverzoek. U hoeft alleen maar de volgende JSON terug te sturen:{"category: "factuur|technisch|restitutie|ander", "urgency":laag|medium|hoog"}Schrijf geen beschrijving.

De zwakke versie produceert misschien 500 uitvoertokens; sterke versie ~15. Omdat output duur is, is dit een aanzienlijk verschil per gesprek en vermenigvuldigt het zich met het volume.

Drie mini-hoesjes

Geval 1 – De verborgen kosten van de lange prompt. Terwijl een boekhoudautomatisering elke factuur sorteerde, werd een ‘regelboek’ van 40 pagina’s toegevoegd als invoer voor elk verzoek: ~12.000 invoertokens per verzoek. Met Sonnet 5 is zojuist 12.000/1M×3 = $0,036 ingevoerd. 5.000 rekeningen per dag → $ 180 per dag. Door het rulebook (eenheid 6) in de cache op te slaan, daalden de inputkosten met ~90%.

Geval 2 – De beloning van het inkrimpen van het model. Eén team deed eenvoudige “positieve/negatieve” sentimenttagging met Opus 4.8: 300 invoer- + 10 uitvoertokens. Opuskosten 300/1M×5 + 10/1M×25 = $0,00175. Overstappen naar Haiku, 300/1M×1 + 10/1M×5 = $0,00035 – 5x goedkoper, het verschil in nauwkeurigheid was onmeetbaar. Bij 3 miljoen oproepen per maand is het verschil $5.250 → $1.050.

Geval 3 — Het vrijgeven van de uitvoer. Wanneer een marketingteam een ​​productbeschrijving maakte, stelde het geen grenzen aan de output; het model zei soms 1.500 tokens. Toen ik de instructie "maximaal 60 woorden" toevoegde, daalde de gemiddelde output van 900 naar 90 tokens. Omdat printen duur was, werd de maandelijkse factuur met een derde verlaagd en werden teksten nuttiger.

Veel voorkomende fouten

  • Het token met het oog raden: je kunt het mis hebben, vooral in het Turks en code. Meeteenheid.
  • Ervan uitgaande dat input en output hetzelfde zijn: output is meestal veel duurder; Het grootste deel van de optimalisatie komt voort uit het verkorten van de output.
  • Laat u niet misleiden door de lage prijs van een enkel gesprek: de beslissing wordt genomen op basis van het volume. $0,01 × miljoen = $10.000.
  • Voorspelling met de tokenizer van een andere aanbieder: Geeft onjuiste resultaten; Gebruik de tokenteltool van het model.
  • Onbeperkte uitbreiding van de gespreksgeschiedenis: elke ronde wordt aan de invoer toegevoegd; samenvatten in lange gesprekken.
  • `max_tokens` onnodig hoog houden: verbergt het budgetplan en het risico op bezuinigingen; Geef een realistische waarde.

Dieper: contextvenster en lange inputkosten

Het is van cruciaal belang om te zien hoe de prijs zich opstapelt ‘over het hele gesprek’ en niet alleen ‘per verzoek’. De totale hoeveelheid tekst die het model kan verwerken wordt het contextvenster genoemd; De som van invoer en uitvoer moet in dit venster passen. Moderne modellen bieden zeer grote vensters (honderdduizenden, zelfs miljoenen tokens), maar dat betekent niet dat je het ‘oneindig kunt vullen’; alles wat je in het venster stopt, wordt als invoer gefactureerd.

De valkuil bij lange gesprekken is deze: bij elke nieuwe ronde stuur je de hele geschiedenis opnieuw (staatloosheid in unit 1). In een gesprek van 20 ronden heeft het 20e verzoek de volledige eerste 19 ronden als input. Naarmate het gesprek langer wordt, stijgen de kosten per verzoek dus cumulatief in plaats van lineair. Een gesprek van 50 ronden met een agent-assistent kan de eerste ronde tientallen keren inputkosten opleveren.

Er zijn twee manieren om dit te beheren. De eerste is een samenvatting: het comprimeren van oudere rondes in één samenvattingsblok, waarbij alleen de laatste paar rondes rauw blijven. De tweede is prompt caching (eenheid 6): het lezen van de vaste context tegen een tiende van de prijs in plaats van deze herhaaldelijk tegen de volledige prijs te verwerken. Samen verlagen ze de rekening voor lange, contextintensieve werklasten aanzienlijk. Tokeneconomie gaat dus over het ontwerp van de hele sessie, niet over één enkel verzoek.

Samengevat

Token is de kleinste eenheid waarin tekst wordt verwerkt; input en output worden afzonderlijk geprijsd, en output is vaak veel duurder. De kosten zijn het aantal tokens vermenigvuldigd met de eenheidsprijs, en de echte beslissing wordt genomen op basis van het volume. Het verkorten van de prompt, het beperken van de output en het kiezen van het lichtste model dat de taak volbrengt, zijn de meest directe hefbomen die de kosten vele malen verlagen.

Applicatie taak

Kies zelf een taak. (1) Bepaal het aantal invoer- en geschatte uitvoertokens voor een representatieve prompt (meet indien mogelijk met een hulpmiddel voor het tellen van tokens). (2) Bereken de kosten per aanvraag voor de drie modelklassen. (3) Schat uw dagelijkse aantal verzoeken en leid het maandbudget af voor de drie modellen. (4) Voeg een instructie toe om de output te verkorten en noteer de verwachte besparingen.

controlelijst

  • [ ] Ik kan het concept van tokens uitleggen en dat tokenisatie varieert afhankelijk van het model.
  • [ ] Ik weet waarom input- en outputtokens verschillend geprijsd zijn.
  • [ ] Met de formule kan ik de kosten van een aanvraag berekenen.
  • [ ] Ik kan een maandbudget voor een werklast maken met behulp van een sjabloon.
  • [ ] Ik kan met een voorbeeld het voordeel van het verkorten van de output en modelreductie laten zien.