LLM-tokeniser skatten: Hur språk förändrar AI-kostnad och kontext

Den LLM-tokeniser skatten är en mätbar kostnad och kontextstraff. Två uppmaningar kan ha samma betydelse men konsumera mycket olika antal tokens eftersom de använder olika språk.

En studie från juli 2026 testade 997 anpassade meningar över sex tokenizers. Med OpenAI:s äldre `cl100k_base` kodning hade tio indiska språk en genomsnittlig ordfruktbarhetsskatt på 8,0 gånger i förhållande till engelska. Malayalam nådde 13,04 gånger. Den nyare `o200k_base` sänkte medelvärdet till 2,1 gånger. Studien bevisar inte att tokenisering ensam orsakar sämre svar. Den visar att pris och användbar kontext kan avvika innan en modell börjar resonera.

Målgrupp: Medelnivå

Direkt svar: Undvik att uppskatta en flerspråkig AI-produkt utifrån engelska tokenantal. Testa den exakta tokenizern på anpassad produktionstext, mät hela begäran, utvärdera kvaliteten separat och kör om testet när modellen eller tokenizern ändras.

Vad LLM-tokeniser skatten mäter

Språkmodeller får token-ID:n, inte ord eller tecken. En tokenizer delar text i token-enheter och mappar dem till ID:n; vissa tokenizers normaliserar texten först. Vanliga fragment kan passa in i en token. Mindre representerade skript eller ordformer kan brytas ner i flera tokens eller byte.

Papperets huvudmetrik är ordfruktbarhet: tokens per mellanslag-avgränsat ord. Dess tokeniser skatt är ordfruktbarheten för ett språk dividerat med engelsk ordfruktbarhet under samma tokenizer.

För en produktionsskärm är ett anpassat tokenantalförhållande ofta lättare att använda:

text anpassat tokenantalförhållande för språk L = tokens för anpassat innehåll på språk L ÷ tokens för den engelska versionen

Dessa metrik svarar på relaterade frågor, men de är inte utbytbara. Namnge den metrik du rapporterar. Båda jämförelserna behöver semantiskt anpassad text. Att räkna orelaterade meningar, eller en lista med vanliga ord, kan ge ett attraktivt nummer som säger lite om en verklig tillämpning.

Forskare använder också fruktbarhet, ofta definierad som tokens per ord. Ordfruktbarhet är intuitiv, men ordgränser är inte lika tydliga över språk. Lägg till teckenfruktbarhet, byte per token, och andelen oihopslagna byte när du behöver diagnostisera varför en skillnad finns.

Denna distinktion är viktig eftersom tokenantal har flera olika konsekvenser:

Den sista raden är den lättaste att överdriva.

Vad forskningen 2026 fann

Den nya Tokenizer Tax-studien använde anpassade meningar från FLORES-200. Den jämförde tio indiska språk med engelska, arabiska, spanska och franska över sex tokenizers. Författarna mätte ord- och teckenfruktbarhet, byte per token, oihopslagna en-byte tokens, och mängden källtext som överlevde en fast kontextbudget.

Tre resultat är viktiga för ingenjörsbeslut:

Språk med hög skatt producerade oihopslagna en-byte tokens för 27–43% av sina tokens. Bland de provade språken med giltiga ordgränser korrelerade den hastigheten med ordfruktbarhetsskatten vid `r = 0.89`. Författarna tillskriver skillnaden otillräcklig vokabulärtäckning för dessa skript.

En 2023 NeurIPS-papper fann skillnader i tokenlängd på upp till 15 gånger mellan språk. En EMNLP 2023-studie mätte kostnad och nytta över 22 språk och fann att token-baserad API-prissättning kan ta mer betalt från vissa språksamhällen för jämförbart innehåll.

Senaste arbetet visar också att skillnaden är ett designval, inte en oundviklig egenskap hos ett skript. Paritet-medveten byte-par kodning (BPE) ändrar sammanslagningsmålet för att hjälpa det för närvarande sämst komprimerade språket. Dess författare rapporterar upp till en 89% minskning av token-kostnads ojämlikhet, mätt med en tvärspråklig Gini-koefficient, med liten förändring i global kompression. En separat kontrollerad studie över 11 sydostasiatiska språk placerade paritet-medveten BPE på effektivitet–rättvisa Pareto-gränsen för jämförbara 1,5 miljarder parameter basmodeller. Det resultatet fastställer inte samma avvägning i gränssnittsskala eller efter anpassning.

Påståendet om noggrannhet behöver återhållsamhet

Studien från juli fann en rå korrelation av `r = -0.61` mellan fruktbarhet och läsförståelse noggrannhet för 13 språkpoänger. Efter att ha kontrollerat för språkresursnivå blev den partiella korrelationen `r = 0.25`.

Det finns fler skäl att undvika en kausal rubrik: fruktbarhetssiffrorna och noggrannhetspoängen kom från olika tokenizer/modellinställningar, urvalet var litet, och översatta benchmarkmeningar är inte en produktionsarbetsbelastning. Papperet stöder starka påståenden om tokenantal, kontext och token-prissatta kostnader. Det isolerar inte tokenizerfruktbarhet som orsaken till lägre svarskvalitet.

Mät din egen flerspråkiga tokenkostnad

Forskningen ger en varning, inte ditt produktionsförhållande. En supportassistent, hämtning system eller kodningsagent har sin egen språkblandning och uppmaningsstruktur.

Använd detta arbetsflöde före lansering och efter varje modelländring.

1. Bygg ett anpassat prov

För en initial skärm, samla 100–1 000 exempel från den arbetsbelastning du förväntar dig:

Använd granskade översättningar av samma betydelse. Håll ett ID som kopplar varje språkvariant. Jämför inte slumpmässig text hämtad från separata språkcorpora. Detta screeningsintervall är inte ett statistiskt minimum: det erforderliga urvalet beror på antalet språk, arbetsbelastningsvariation och hur exakt du behöver uppskatta svansbeteende.

Lagra provet som JSON Lines:

{"id":"support-001","language":"en","text":"Granskad engelsk text"} {"id":"support-001","language":"sv","text":"Granskad svensk översättning"} {"id":"support-001","language":"tr","text":"Granskad turkisk översättning"}

2. Fäst tokenizern

Tokenizern tillhör en modellversion. Registrera båda. OpenAI:s officiella `tiktoken`-repository exponerar `cl100k_base` och `o200k_base`; dess modellkartläggning visar också att modellfamiljer kan använda olika kodningar. För en stängd modell, föredra leverantörens officiella räknare när en sådan finns. Googles Gemini API, till exempel, exponerar en `countTokens`-metod. För en öppen modell, ladda den exakta artefakten med modellens dokumenterade tokenizer-pipeline, som den som beskrivs i Hugging Face Tokenizers API.

Anta inte att två modeller från samma leverantör delar en tokenizer. Anta inte att ett lokalt bibliotek redan känner till en modell som släpptes igår.

3. Beräkna en fördelning, inte ett förhållande

Installera och fäst räknaren:

bash python -m pip install "tiktoken==0.13.0"

Kör sedan:

python import json from collections import defaultdict from math import ceil from statistics import mean, median

import tiktoken

BASELINE = "en" ENCODINGS = ("cl100k_base", "o200k_base")

groups = defaultdict(dict) with open("aligned-samples.jsonl", encoding="utf-8") as source: for line in source: row = json.loads(line) groups[row["id"]][row["language"]] = row["text"]

def percentile(values, probability): ordered = sorted(values) index = max(0, ceil(len(ordered) * probability) - 1) return ordered[index]

for encoding_name in ENCODINGS: encoding = tiktoken.get_encoding(encoding_name) counts = defaultdict(list) ratios = defaultdict(list)

for sample_id, variants in groups.items(): if BASELINE not in variants: raise ValueError(f"{sample_id} has no {BASELINE} baseline")

baseline_tokens = len(encoding.encode(variants[BASELINE])) if baseline_tokens == 0: raise ValueError(f"{sample_id} has an empty baseline")

for language, text in variants.items(): token_count = len(encoding.encode(text)) counts[language].append(token_count) ratios[language].append(token_count / baseline_tokens)

for language in sorted(counts): print( encoding_name, language, f"mean_tokens={mean(counts[language]):.1f}", f"mean_ratio={mean(ratios[language]):.2f}x", f"median_ratio={median(ratios[language]):.2f}x", f"p95_ratio={percentile(ratios[language], 0.95):.2f}x", f"max_ratio={max(ratios[language]):.2f}x", sep="\t", )

Medelvärdet kan dölja några långa begärningar som överskrider kontextfönstret. Inspektera p50 (median), p95 (95:e percentilen) och maximum innan du använder resultatet i en kapacitetsplan.

*Mät anpassad produktionstext med den distribuerade tokenizern, använd sedan fördelningen för att ställa in kostnads- och kontextgränser. Kvalitet förblir en separat utvärdering.*

4. Mät den kompletta begäran

Det synliga användarmeddelandet är bara en del av ett API-anrop. Inkludera:

Detta är särskilt viktigt för agenter. Ett stort JSON-verktygsschema kan dominera en kort användarbegäran. Ett lokaliserat RAG-avsnitt kan dominera en engelsk systemprompt. Mät den slutliga serialiserade begäran när leverantören exponerar den representationen.

5. Konvertera tokens till driftgränser

För ett enkelt token-prissatt API:

text månatlig inmatningskostnad = månatliga samtal × medel inmatning tokens × pris per miljon tokens ÷ 1 000 000

Anta att ett hypotetiskt API tar $1 per miljon inmatning tokens. En miljon begärningar med 1 000 inmatning tokens kostar $1 000. Om anpassade begärningar på ett annat språk i genomsnitt är 2 500 tokens, blir inmatningsdelen $2 500 innan caching eller rabatter.

Kontext behöver en separat beräkning:

text användbar inmatningsbudget = kontextfönster

Tillämpa det observerade språkförhållandet på innehållsdelen, inte blint på hela begäran.

Guiden AI reasoning-token cost guide förklarar varför tokenbudgetar behöver en produktgräns, inte bara en modellgräns. För RAG- och kodningssystem visar cross-repository context design varför det inte automatiskt är användbart att skicka mer kontext. Om API-valet fortfarande är öppet, ger den befintliga gratis AI API-fallstudien en bredare jämförelse ramverk.

Sätt en flerspråkig acceptansport

Ett lägre tokenförhållande är användbart endast om modellen fortfarande uppfyller produktkravet. Använd fyra separata portar:

För ett flerspråkigt RAG-system, chunk efter den distribuerade tokenizern snarare än en delad teckenantal. För en agent, mät verktygs spår och omförsök såväl som den första begäran. För en supportprodukt, spåra kostnad per löst ärende, inte kostnad per samtal. Dessa val hindrar tokenmetrik från att bli en fåfänga benchmark.

Använd en språk-specifik väg endast när det förbättrar hela poängkortet. En billigare tokenizer i kombination med en svagare modell kan spara inmatning tokens och öka omförsök. Ett större kontextfönster kan dölja dålig chunking tills fakturan växer. Den korrekta enheten är den avslutade användaruppgiften.

Vad team kan förändra

Applikationsteam kan inte återträna en kommersiell modells tokenizer, men de har fortfarande alternativ:

Team som tränar sina egna modeller har ett djupare val. Resultaten från den paritet-medvetna BPE tyder på att ett tokenizer-mål kan minska tvärspråklig ojämlikhet utan att offra mycket av den totala kompressionen. Den sydostasiatiska studien lägger till kontrollerad bevisning att rättvisa och effektivitet inte behöver röra sig i motsatta riktningar.

Behandla tokenizern som en del av modellkontraktet. Versionera den, benchmarka den och inkludera den i migrationsgranskningar.

Bevisens begränsningar

Den senaste studien är en preprint. Den använder översatta FLORES-200 meningar, en blygsam uppsättning språk och en mellanslag-baserad ordmetrik som inte passar varje skriftsystem lika bra. Dess byte-detekteringsmetod är tokenizer-specifik.

Den starkaste slutsatsen är modelloberoende: när ett anpassat språk producerar fler tokens, får det mindre text i ett fast tokenfönster. Kostnadsslutet gäller när en leverantör fakturerar dessa extra tokens till samma enhetspris. Cachepolicyer och volymrabatter kan ändra den slutliga fakturan.

Noggrannhet behöver sitt eget test. Träningsdatatäckning, modellarkitektur, efterträning, utvärderingsdesign och kulturell kontext påverkar alla resultat. Tokenfruktbarhet kan bidra till en lucka, men juli-papperet isolerar inte den kausala effekten.

Flerspråkig tokeniseringschecklista

Vanliga frågor

Varför använder vissa språk fler LLM-tokens?

Subordvokabulärer återspeglar deras träningsdata och sammanslagningsregler. Vanliga engelska fragment representeras ofta effektivt, medan mindre representerade skript kan delas upp i mindre bitar eller byte. Storleken på skillnaden beror på den exakta tokenizern och texten.

Betyder ett högre tokenantal ett sämre svar?

Nej. Det påverkar direkt token-prissatt kostnad och mängden text som får plats i ett tokenfönster. Det bevisar inte lägre svarskvalitet. Testa kvaliteten separat på granskade exempel på varje språk.

Hur kan jag räkna tokens innan ett API-anrop?

Använd leverantörens officiella räknepunkt när den är tillgänglig. För OpenAI-kodningar kan `tiktoken` räkna lokalt. För öppna modeller, ladda den exakta tokenizer-artefakten som skickas med modellen. Fäst versioner så att en senare uppdatering inte tyst ändrar mätningen.

Kan byte av modeller ta bort tokeniser skatten?

Det kan minska skillnaden. Juli-studien fann en stor förbättring mellan `cl100k_base` och `o200k_base`. Ett modellbyte ändrar också kvalitet, utdata kostnad, caching, latens och operationellt beteende, så jämför den kompletta arbetsbelastningen snarare än tokenantal ensam.

Källor

Påståendekontroller

| En högre tokenizer skatt orsakar lägre svar noggrannhet | Inte fastställt | Juli-papperets justerade analys stödde inte en enkel kausal läsning