Die LLM-Tokenizer-Steuer: Wie Sprache die Kosten und den Kontext von KI verändert

Die LLM-Tokenizer-Steuer ist eine messbare Kosten- und Kontextstrafe. Zwei Eingaben können die gleiche Bedeutung haben und dennoch sehr unterschiedliche Tokenanzahlen verbrauchen, weil sie unterschiedliche Sprachen verwenden.

Eine Studie aus dem Juli 2026 testete 997 ausgerichtete Sätze über sechs Tokenizer. Mit OpenAI's älterem `cl100k_base`-Encoding hatten zehn indische Sprachen eine durchschnittliche Wortfruchtbarkeitssteuer von 8,0 im Vergleich zu Englisch. Malayalam erreichte 13,04. Das neuere `o200k_base` senkte den Durchschnitt auf 2,1. Die Studie beweist nicht, dass die Tokenisierung allein schlechtere Antworten verursacht. Sie zeigt jedoch, dass Preis und nutzbarer Kontext divergieren können, bevor ein Modell zu schlussfolgern beginnt.

Zielgruppe: Fortgeschrittene

Direkte Antwort: Schätzen Sie ein mehrsprachiges KI-Produkt nicht anhand der englischen Tokenanzahlen. Testen Sie den genauen Tokenizer an ausgerichtetem Produktionstext, messen Sie die gesamte Anfrage, bewerten Sie die Qualität separat und wiederholen Sie den Test, wann immer sich das Modell oder der Tokenizer ändert.

Was die LLM-Tokenizer-Steuer misst

Sprachmodelle erhalten Token-IDs, keine Wörter oder Zeichen. Ein Tokenizer zerlegt Text in Token-Einheiten und ordnet sie IDs zu; einige Tokenizer normalisieren den Text zuerst. Häufige Fragmente können in ein Token passen. Weniger vertretene Schriften oder Wortformen können in mehrere Tokens oder Bytes zerlegt werden.

Die Hauptmetrik der Arbeit ist Wortfruchtbarkeit: Tokens pro durch Leerzeichen getrenntem Wort. Ihre Tokensteuer ist die Wortfruchtbarkeit einer Sprache geteilt durch die Wortfruchtbarkeit des Englischen unter demselben Tokenizer.

Für einen Produktionsbildschirm ist ein ausgerichtetes Tokenanzahlverhältnis oft einfacher zu verwenden:

text aligned token-count ratio for language L = tokens for aligned content in language L ÷ tokens for the English version

Diese Metriken beantworten verwandte Fragen, sind jedoch nicht austauschbar. Nennen Sie die Metrik, die Sie berichten. Beide Vergleiche benötigen semantisch ausgerichteten Text. Das Zählen von nicht verwandten Sätzen oder einer Liste von häufigen Wörtern kann eine attraktive Zahl produzieren, die wenig über eine reale Anwendung aussagt.

Forscher verwenden auch Fruchtbarkeit, oft definiert als Tokens pro Wort. Wortfruchtbarkeit ist intuitiv, aber Wortgrenzen sind nicht in allen Sprachen gleich klar. Fügen Sie die Zeichenfruchtbarkeit, Bytes pro Token und den Anteil unverbundener Bytes hinzu, wenn Sie diagnostizieren müssen, warum eine Lücke besteht.

Diese Unterscheidung ist wichtig, da die Tokenanzahl mehrere unterschiedliche Konsequenzen hat:

Die letzte Zeile ist die einfachste, um übertrieben zu behaupten.

Was die Forschung von 2026 ergab

Die neue Tokenizer Tax-Studie verwendete ausgerichtete Sätze aus FLORES-200. Sie verglich zehn indische Sprachen mit Englisch, Arabisch, Spanisch und Französisch über sechs Tokenizer. Die Autoren maßen Wort- und Zeichenfruchtbarkeit, Bytes pro Token, unverbundene Einzelbyte-Tokens und die Menge an Quelltext, die ein festes Kontextbudget überlebte.

Drei Ergebnisse sind für Ingenieurentscheidungen wichtig:

Hochsteuer-Sprachen produzierten unverbundene Einzelbyte-Tokens für 27–43% ihrer Tokens. Über die beprobten Sprachen mit gültigen Wortgrenzen korrelierte diese Rate mit der Wortfruchtbarkeitssteuer bei `r = 0.89`. Die Autoren führen die Lücke auf unzureichende Wortschatzabdeckung für diese Schriften zurück.

Eine 2023 NeurIPS-Publikation fand Tokenisierungs-Längenunterschiede von bis zu 15 Mal zwischen den Sprachen. Eine EMNLP 2023-Studie maß Kosten und Nutzen über 22 Sprachen und stellte fest, dass die tokenbasierte API-Preisgestaltung einige Sprachgemeinschaften mehr für vergleichbare Inhalte berechnen kann.

Jüngste Arbeiten zeigen auch, dass die Lücke eine Designentscheidung ist, kein unvermeidliches Merkmal einer Schrift. Parity-aware Byte-Pair Encoding (BPE) ändert das Zusammenführungsziel, um der derzeit am schlechtesten komprimierten Sprache zu helfen. Ihre Autoren berichten von einer Reduzierung der Token-Kostenungleichheit um bis zu 89%, gemessen mit einem sprachübergreifenden Gini-Koeffizienten, bei nur geringfügigen Änderungen in der globalen Kompression. Eine separate kontrollierte Studie über 11 südostasiatische Sprachen platzierte das parity-aware BPE an der Effizienz-Gerechtigkeits-Pareto-Grenze für vergleichbare 1,5-Milliarden-Parameter-Basismodelle. Dieses Ergebnis stellt nicht den gleichen Kompromiss im Grenzbereich oder nach der Ausrichtung fest.

Die Genauigkeitsbehauptung benötigt Zurückhaltung

Die Juli-Studie fand eine rohe Korrelation von `r = -0.61` zwischen Fruchtbarkeit und Leseverständnisgenauigkeit für 13 Sprachpunkte. Nach Kontrolle des Sprachressourcenniveaus wurde die partielle Korrelation zu `r = 0.25`.

Es gibt mehr Gründe, eine kausale Überschrift zu vermeiden: Die Fruchtbarkeitszahlen und Genauigkeitswerte stammen aus unterschiedlichen Tokenizer-/Modellkonfigurationen, die Stichprobe war klein, und übersetzte Benchmark-Sätze sind keine Produktionslast. Die Arbeit unterstützt starke Behauptungen über Tokenanzahlen, Kontext und tokenpreisbasierte Kosten. Sie isoliert jedoch nicht die Tokenizer-Fruchtbarkeit als Ursache für eine niedrigere Antwortqualität.

Messen Sie Ihre eigenen mehrsprachigen Tokenkosten

Die Forschung gibt eine Warnung, nicht Ihr Produktionsverhältnis. Ein Support-Assistent, ein Abrufsystem oder ein Codierungsagent hat seine eigene Sprachmischung und Eingabestruktur.

Verwenden Sie diesen Workflow vor dem Start und nach jeder Modelländerung.

1. Erstellen Sie eine ausgerichtete Probe

Für einen ersten Bildschirm sammeln Sie 100–1.000 Beispiele aus der Arbeitslast, die Sie erwarten:

Verwenden Sie überprüfte Übersetzungen mit derselben Bedeutung. Behalten Sie eine ID, die jede Sprachvariante verbindet. Vergleichen Sie keinen zufälligen Text, der aus separaten Sprachkorpora gezogen wurde. Dieser Screening-Bereich ist kein statistisches Minimum: Die erforderliche Stichprobe hängt von der Anzahl der Sprachen, der Variabilität der Arbeitslast und davon ab, wie genau Sie das Verhalten am Ende schätzen müssen.

Speichern Sie die Probe als JSON Lines:

{"id":"support-001","language":"en","text":"Reviewed English text"} {"id":"support-001","language":"sv","text":"Reviewed Swedish translation"} {"id":"support-001","language":"tr","text":"Reviewed Turkish translation"}

2. Fixieren Sie den Tokenizer

Der Tokenizer gehört zu einer Modellversion. Zeichnen Sie beides auf. OpenAI's offizielles `tiktoken`-Repository zeigt `cl100k_base` und `o200k_base`; seine Modellzuordnung zeigt auch, dass Modellfamilien unterschiedliche Codierungen verwenden können. Für ein geschlossenes Modell ziehen Sie den offiziellen Zähler des Anbieters vor, wenn einer existiert. Die Gemini-API von Google beispielsweise bietet eine `countTokens`-Methode. Für ein offenes Modell laden Sie das genaue Artefakt mit der dokumentierten Tokenizer-Pipeline des Modells, wie sie in der Hugging Face Tokenizers API beschrieben ist.

Gehen Sie nicht davon aus, dass zwei Modelle desselben Anbieters einen Tokenizer teilen. Gehen Sie nicht davon aus, dass eine lokale Bibliothek bereits ein Modell kennt, das gestern veröffentlicht wurde.

3. Berechnen Sie eine Verteilung, nicht ein Verhältnis

Installieren und fixieren Sie den Zähler:

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

Führen Sie dann aus:

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", )

Der Durchschnitt kann einige lange Anfragen verbergen, die das Kontextfenster überlaufen. Überprüfen Sie p50 (den Median), p95 (das 95. Perzentil) und das Maximum, bevor Sie das Ergebnis in einem Kapazitätsplan verwenden.

*Messen Sie ausgerichteten Produktionstext mit dem bereitgestellten Tokenizer und verwenden Sie dann die Verteilung, um Kosten- und Kontextgrenzen festzulegen. Qualität bleibt eine separate Bewertung.*

4. Messen Sie die gesamte Anfrage

Die sichtbare Benutzeranfrage ist nur ein Teil eines API-Aufrufs. Einschließen:

Dies ist besonders wichtig für Agenten. Ein großes JSON-Tool-Schema kann eine kurze Benutzeranfrage dominieren. Eine lokalisierte RAG-Passage kann eine englische Systemaufforderung dominieren. Messen Sie die endgültige serialisierte Anfrage, wann immer der Anbieter diese Darstellung bereitstellt.

5. Konvertieren Sie Tokens in Betriebslimits

Für eine einfache tokenpreisbasierte API:

text monthly input cost = monthly calls × mean input tokens × price per million tokens ÷ 1,000,000

Angenommen, eine hypothetische API berechnet 1 $ pro Million Eingabetokens. Eine Million Anfragen mit 1.000 Eingabetokens kosten 1.000 $. Wenn ausgerichtete Anfragen in einer anderen Sprache im Durchschnitt 2.500 Tokens haben, wird der Eingabeteil auf 2.500 $ vor Caching oder Rabatten.

Der Kontext benötigt eine separate Berechnung:

text usable input budget = context window

Wenden Sie das beobachtete Sprachverhältnis auf den Inhaltsanteil an, nicht blind auf die gesamte Anfrage.

Der AI reasoning-token cost guide erklärt, warum Tokenbudgets eine Produktgrenze benötigen, nicht nur eine Modellgrenze. Für RAG- und Codierungssysteme zeigt das cross-repository context design, warum das Senden von mehr Kontext nicht automatisch nützlich ist. Wenn die API-Wahl noch offen ist, bietet die bestehende free AI API case study einen breiteren Vergleichsrahmen.

Setzen Sie ein mehrsprachiges Akzeptanztor

Ein niedrigeres Tokenverhältnis ist nur dann nützlich, wenn das Modell weiterhin die Produktanforderung erfüllt. Verwenden Sie vier separate Tore:

Für ein mehrsprachiges RAG-System chunkieren Sie nach dem bereitgestellten Tokenizer und nicht nach einer gemeinsamen Zeichenanzahl. Für einen Agenten messen Sie Tool-Spuren und Wiederholungen sowie die erste Anfrage. Für ein Supportprodukt verfolgen Sie die Kosten pro gelöstem Fall, nicht die Kosten pro Anruf. Diese Entscheidungen verhindern, dass die Tokenmetrik zu einem Schönheitsbenchmark wird.

Verwenden Sie einen sprachspezifischen Weg nur, wenn er die gesamte Punktzahl verbessert. Ein günstigerer Tokenizer in Kombination mit einem schwächeren Modell kann Eingabetokens sparen und die Wiederholungen erhöhen. Ein größeres Kontextfenster kann schlechtes Chunking verbergen, bis die Rechnung steigt. Die korrekte Einheit ist die abgeschlossene Benutzeraufgabe.

Was Teams ändern können

Anwendungsteams können den Tokenizer eines kommerziellen Modells nicht neu trainieren, aber sie haben dennoch Optionen:

Teams, die ihre eigenen Modelle trainieren, haben eine tiefere Wahl. Die Ergebnisse des parity-aware BPE deuten darauf hin, dass ein Tokenizer-Ziel die sprachübergreifende Ungleichheit verringern kann, ohne viel globale Kompression zu opfern. Die Studie über Südostasien fügt kontrollierte Beweise hinzu, dass Fairness und Effizienz nicht in entgegengesetzte Richtungen gehen müssen.

Betrachten Sie den Tokenizer als Teil des Modellvertrags. Versionieren Sie ihn, benchmarken Sie ihn und beziehen Sie ihn in Migrationsüberprüfungen ein.

Grenzen der Beweise

Die neueste Studie ist ein Preprint. Sie verwendet übersetzte FLORES-200-Sätze, eine bescheidene Anzahl von Sprachen und eine auf Leerzeichen basierende Wortmetrik, die nicht für jedes Schriftsystem gleich gut geeignet ist. Ihre Byte-Erkennungsmethode ist tokenizerspezifisch.

Die stärkste Schlussfolgerung ist modellunabhängig: Wenn eine ausgerichtete Sprache mehr Tokens produziert, gelangt weniger Text in ein festes Tokenfenster. Die Kostenannahme gilt, wenn ein Anbieter diese zusätzlichen Tokens zum gleichen Einheitspreis berechnet. Cache-Richtlinien und Mengenrabatte können die endgültige Rechnung ändern.

Die Genauigkeit benötigt ihren eigenen Test. Die Abdeckung der Trainingsdaten, die Modellarchitektur, das Post-Training, das Evaluationsdesign und der kulturelle Kontext beeinflussen alle die Ergebnisse. Die Tokenfruchtbarkeit kann zu einer Lücke beitragen, aber das Juli-Papier isoliert diesen kausalen Effekt nicht.

Mehrsprachige Tokenizer-Checkliste

Häufig gestellte Fragen

Warum verwenden einige Sprachen mehr LLM-Tokens?

Subwort-Wortschätze spiegeln ihre Trainingsdaten und Zusammenführungsregeln wider. Häufige englische Fragmente werden oft effizient dargestellt, während weniger vertretene Schriften in kleinere Stücke oder Bytes zerlegt werden können. Die Größe der Lücke hängt vom genauen Tokenizer und dem Text ab.

Bedeutet eine höhere Tokenanzahl eine schlechtere Antwort?

Nein. Sie beeinflusst direkt die tokenpreisbasierte Kosten und die Menge an Text, die in ein Tokenfenster passt. Sie beweist nicht eine niedrigere Antwortqualität. Testen Sie die Qualität separat an überprüften Beispielen in jeder Sprache.

Wie kann ich Tokens vor einem API-Aufruf zählen?

Verwenden Sie den offiziellen Zählerendpunkt des Anbieters, wenn verfügbar. Für OpenAI-Codierungen kann `tiktoken` lokal zählen. Für offene Modelle laden Sie das genaue Tokenizer-Artefakt, das mit dem Modell geliefert wird. Versionen fixieren, damit ein späteres Update die Messung nicht stillschweigend ändert.

Kann der Wechsel von Modellen die Tokensteuer entfernen?

Es kann die Lücke verringern. Die Juli-Studie fand eine große Verbesserung zwischen `cl100k_base` und `o200k_base`. Ein Modellwechsel ändert auch die Qualität, die Ausgabekosten, das Caching, die Latenz und das Betriebsverhalten, daher vergleichen Sie die gesamte Arbeitslast und nicht nur die Tokenanzahlen.

Quellen

Anspruchsprüfungen

| Eine höhere Tokensteuer verursacht eine niedrigere Antwortgenauigkeit | Nicht festgestellt | Die angepasste Analyse des Juli-Papiers unterstützte keine einfache kausale Lesart.