Warum indische Sprachen in LLMs mehr Token kosten und wie man Tokenizer repariert

Sag denselben kurzen Satz in fünf Sprachen und zähl, was ein LLM verarbeiten muss. Die Ergebnisse liegen nicht einmal in der Nähe voneinander, und mit der Schwierigkeit einer Sprache hat das wenig zu tun.

Ein Satz, fünf Preisschilder

Die Messwerte für einen einzigen kurzen Satz:

Sprache	Zeichen	Bytes	Wörter	Token
Englisch	18	18	4	5
Hindi	12	30	3	13
Telugu	17	45	3	20
Kannada	16	44	2	22
Tamil	30	84	3	34

Die Bedeutung ist identisch. Entscheidend ist die letzte Spalte. Token sind die kleinen Stücke, die ein Modell tatsächlich liest, mal ein ganzes Wort, mal ein Fragment, mal nur ein paar Zeichen. Englisch brauchte ungefähr ein Token pro Wort. Tamil fast elf.

Das liegt nicht daran, dass Tamil schwerer zu verstehen wäre. Die Lücke stammt aus einer Entscheidung, die lange vor dem ersten Prompt getroffen wurde: wie der Tokenizer des Modells gebaut wurde. Und die Folgen sind real. Unterhaltungen in indischen Sprachen füllen das Kontextfenster schneller, kosten mehr und kommen langsamer zurück, selbst wenn sie genau das sagen, was jemand auf Englisch günstiger sagt.

Im Folgenden geht es darum, warum es die Lücke gibt, was ein kleines Experiment über ihre Verringerung zeigt und was nötig ist, um den Tokenizer eines bereits trainierten Modells zu reparieren.

Was ein Tokenizer macht

Bevor ein Modell einen Satz verarbeitet, zerlegt ein Tokenizer ihn in Token, die Grundbausteine, ein bisschen wie Lego-Steine. Alles danach, auch das Gedächtnis des Modells für den Chat, der Rechenaufwand und die Antwortgeschwindigkeit, wird in Token gezählt, nicht in Wörtern oder Buchstaben. Die Tabelle oben ist also eine direkte Messung, wie effizient jede Sprache zerlegt wurde.

Niemand entwirft diese Zerlegung von Hand. Sie wird aus einem riesigen Textberg per Byte-Level-BPE gelernt, kurz für Byte Pair Encoding. Das Rezept ist einfach: mit rohen Bytes beginnen, das Paar finden, das im Trainingstext am häufigsten nebeneinander vorkommt, und es zu einem neuen Token verschmelzen. Wiederholen. Die ersten Schritte sehen so aus:

t h  →  th
th e →  the

Nach Tausenden Runden entsteht ein Vokabular, in dem sich jeder Eintrag seinen Platz durch Häufigkeit verdient hat. Teile wie „the“, „-ing“ und „-tion“ werden in einem englischlastigen Korpus zu einzelnen günstigen Token, weil sie ständig vorkommen.

Warum Bytes eine falsche Fährte sind

Englische Buchstaben belegen je ein Byte. Die meisten indischen Schriften wie Devanagari, Telugu, Tamil und Kannada belegen drei Bytes pro Zeichen, weil ihre Zeichensätze viel größer sind. Man ist versucht zu folgern, drei Bytes bedeuteten drei Token, aber das stimmt nicht. Ein Byte-Level-Tokenizer kann mehrere Bytes zu einem Token verschmelzen, ein Drei-Byte-Zeichen kostet also nicht automatisch drei. Was es kostet, hängt davon ab, ob der Tokenizer für diese Bytefolge eine gute Verschmelzung gelernt hat, und das wiederum davon, wie viel Text in dieser Sprache er gesehen hat.

Die eigentliche Erklärung sind also die Trainingsdaten, nicht die Komplexität der Schrift. Trainiert man mit 90% Englisch und 10% allem anderen, bekommen englische Muster Tausende Gelegenheiten, sich effiziente Ein-Token-Verschmelzungen zu verdienen. Indische Muster bekommen viel weniger und bleiben in kleinen, teuren Stücken. Der Algorithmus ist in keinem moralischen Sinn voreingenommen. Häufigkeit ist schlicht das Einzige, was BPE optimiert.

Ein Experiment: Hilft es, die Daten neu zu gewichten?

Um das zu testen, wurden drei kleine Tokenizer von Grund auf trainiert, wobei sich nur die Sprachmischung unterschied:

• Tokenizer A: 90% Englisch und 10% indische Sprachen, so wie viele echte Tokenizer entstehen, weil der Großteil des Webtexts englisch ist
• Tokenizer B: eine gleichmäßige Aufteilung 50/50 zwischen englischem und indischem Text
• Tokenizer C: gleiche Anteile Englisch, Hindi, Telugu, Tamil und Kannada

Eine Einschränkung gilt. Der Korpus war klein und selbst zusammengestellt, um eine einzige Variable zu isolieren. Das ist kein Produktionsmaßstab, daher zählen Richtung und relative Größe der Verschiebungen mehr als die absoluten Zahlen.

Token pro Wort auf zurückgehaltenen Testsätzen:

Sprache	A (90% Englisch)	B (50/50)	C (ausgewogen)
Englisch	3.05	3.08	3.60
Hindi	5.34	4.32	4.34
Telugu	7.79	6.36	6.36
Tamil	10.75	8.47	7.84
Kannada	8.86	7.34	7.07

Der Schritt von A zu B, der indischen Sprachen einen faireren Anteil gibt, senkte die Kosten für Hindi um etwa 19%, für Telugu um etwa 18% und für Tamil um etwa 21%, während sich Englisch kaum bewegte. Eine Zeit lang bringt Neugewichtung einen sehr guten Ertrag.

Der weitere Schritt zur völlig ausgewogenen Mischung brachte für die indischen Sprachen abnehmende Erträge und biss ein Stück aus dem Englischen heraus (von 3.08 auf 3.60). Mehr Ausgewogenheit ist also nicht immer besser. Es gibt einen Sweet Spot, keine gerade Linie.

Würde ein größeres Vokabular helfen?

Mit demselben ausgewogenen Korpus wurde die Vokabulargröße variiert. Token pro Wort:

Sprache	300	800	1,500	3,000
Englisch	5.28	3.70	3.70	3.70
Hindi	6.75	3.55	3.55	3.55
Telugu	9.64	6.42	6.42	6.42
Tamil	10.72	7.78	7.78	7.78
Kannada	10.17	7.17	7.17	7.17

Der Schritt von 300 auf 800 half jeder Sprache stark. Danach änderte sich nichts mehr, weil dem winzigen Korpus die häufigen Muster ausgegangen waren, die sich als neue Token gelohnt hätten. Im Produktionsmaßstab ist aus einem verwandten Grund eine Kurve derselben Form zu erwarten: Jeder zusätzliche Platz erfasst immer seltenere Muster, also schrumpfen die Gewinne. So oder so ist ein größeres Vokabular nicht automatisch besser. Es vergrößert die Embedding-Tabelle und die Ausgabeschicht, ist also echter Aufwand und kein kostenloses Upgrade.

Keiner der beiden Hebel, weder Neugewichtung noch ein wachsendes Vokabular, ist für sich genommen eine saubere Lösung. Das führt zur schwierigeren Frage, was man mit einem bereits trainierten Modell mit schlechtem, englischlastigem Tokenizer macht, wenn ein Neuanfang keine Option ist.

Warum man den Tokenizer nicht einfach austauschen kann

Den alten Tokenizer durch einen besseren mehrsprachigen zu ersetzen, ist die naheliegende Idee, und sie scheitert, weil der Tokenizer tief im Modell verdrahtet ist.

Durch das Training bekommt jedes Token ein eigenes Embedding, einen Vektor, der für die Bedeutung dieses Tokens steht, und die übrigen Schichten arbeiten mit diesen Vektoren. Angenommen, ID 1234 gehört zum Embedding für „hello“. Weist ein neuer Tokenizer 1234 stattdessen einer Begrüßung auf Hindi zu, bedeutet das Embedding an dieser Stelle immer noch „hello“. Nichts sagt dem Transformer, dass sich die Bedeutung geändert hat. Die Ausgabe wird unzusammenhängend, weil das gelernte Wissen des Modells noch an den alten IDs hängt und diese Verbindung still gerissen ist.

Wie Teams Sprachen nachrüsten: Vokabular erweitern, Gewichte einfrieren

Die branchenweit genutzte Technik ist die Vokabularerweiterung, und sie wird sorgfältig durchgeführt, um genau diesen Bruch zu vermeiden. In Grundzügen:

1. Das bestehende Vokabular unangetastet lassen. Keine aktuelle Token-ID wird neu vergeben, denn genau die Neuvergabe verursacht die Fehlzuordnung.
2. Neue Token für die Zielsprachen anhängen. Ein frischer Satz an Verschmelzungen, oft auf einem mehrsprachigen oder sprachspezifischen Korpus trainiert, wird als neue IDs hinter den bestehenden ergänzt, sodass nichts ersetzt wird. Ein Vokabular von 32K kann auf über 100K wachsen.
3. Die neuen Embeddings initialisieren. Zufallswerte funktionieren, aber das Mitteln verwandter Embeddings sorgt für einen wärmeren Start, weil ein rein zufälliger Vektor einem brandneuen Token nichts sagt.
4. Die ursprünglichen Gewichte sperren und zunächst nur die neuen Embeddings trainieren. Auf diesem Schritt ruht der ganze Ansatz. Alles, was das Modell schon über Englisch, Schlussfolgern und Code weiß, bleibt gesperrt. Nur die neuen Embedding-Zeilen und oft die neuen Zeilen der Ausgabeschicht dürfen sich ändern. Das Modell lernt, was die neuen Token bedeuten, ohne katastrophales Vergessen zu riskieren, den bekannten Fehler, bei dem neues Lernen altes Wissen überschreibt.
5. Das Pretraining mit Text in den neuen Sprachen fortsetzen, während der Großteil des Modells gesperrt bleibt, bis die neuen Embeddings genug Bedeutung tragen, dass die eingefrorenen Schichten sie nutzen können.
6. Schrittweise auftauen. Mal kommen zuerst die oberen Schichten, mal alles, und das Training läuft weiter, damit sich das ganze Netz an das größere Vokabular anpassen kann.

Man kann es sich vorstellen, als würde man an ein Haus neue Zimmer anbauen, statt es abzureißen und neu zu bauen. Das vorhandene Wissen bleibt in den frühen Phasen unberührt, während die neuen Zimmer getrennt eingerichtet werden, und erst danach ordnet sich das ganze Haus um sie herum neu.

Das zeigt auch, warum Vokabularänderungen nicht nur die Eingabeseite betreffen. Das Modell muss die neuen Token lesen, das ist Aufgabe der Eingabe-Embeddings, und sie in Antworten auch erzeugen. Das übernimmt die Ausgabeschicht, manchmal LM Head genannt, die jeden Eintrag im Vokabular als mögliches nächstes Token bewertet. Das Training muss beide Enden abdecken, und ob die beiden Schichten Gewichte teilen, hängt von der Architektur ab.

Ein Hinweis zur Genauigkeit: Die genauen Produktionsrezepte, also Einfrierpläne, gewählte Vokabulargrößen und die Dauer jeder Phase, sind proprietär und teamspezifisch, daher sollte man keines davon ohne öffentliche Quelle einer bestimmten Firma zuschreiben. Das gestufte Muster aus Erweitern, Aufwärmen und schrittweisem Auftauen ist der allgemeine, dokumentierte Ansatz, die konkreten Zahlen sind nicht öffentlich.

Was das nicht beweist

Token-Effizienz ist nicht dasselbe wie Modellqualität. Eine niedrige Zahl an Token pro Wort zeigt nicht, dass ein Modell die Sprache versteht, klar in ihr denkt oder gut aus ihr übersetzt. Günstige Tokenisierung kann mit schwacher Modellierung einhergehen und teure mit starkem Verständnis. All das betrifft die ökonomische Ebene, also Kosten, Latenz und Kontextverbrauch, nicht das Verständnis.

Die Kette von Anfang bis Ende

Verschiedene Schriften bekommen verschiedene Byte-Darstellungen. BPE lernt Verschmelzungen nach Häufigkeit in den Trainingsdaten. Unterrepräsentierte Sprachen bekommen weniger effiziente Verschmelzungen. Diese Sprachen brauchen daher mehr Token, um dasselbe zu sagen, was weniger nutzbaren Kontext, langsamere Antworten und höhere Rechnungen für identische Unterhaltungen bedeutet.

Neugewichtung der Daten und ein größeres Vokabular helfen beide, erreichen aber beide ein Plateau und haben beide echte Kosten. Vokabularerweiterung mit eingefrorenen Gewichten, sorgfältig umgesetzt, um katastrophales Vergessen zu vermeiden, ist aufwendiger als jeder der beiden Hebel allein. Genau deshalb greifen Teams dazu, statt einen größeren, ausgewogeneren Tokenizer von Grund auf neu zu trainieren.

Bei mehrsprachigen LLMs ist der Tokenizer kein nachrangiger Vorverarbeitungsschritt. Er ist Teil der Ökonomie der Sprache, und ihn nach dem Training richtig zu reparieren, erfordert echtes Engineering, nicht nur bessere Daten. Dabei gilt: Die Zahlen oben stammen aus einem Spielzeug-BPE-Setup, das jeweils nur eine Sache variiert, und sagen nichts darüber, wie ein ausgelieferter Tokenizer abschneidet.