Welches LLM ist für Ihre Sprache am günstigsten? Tokenizer-Kosten gemessen

Ein einzelnes günstigstes LLM für mehrsprachigen Text gibt es nicht. Gemessen am selben Textabschnitt rechnet GPT-5.5 für europäische Sprachen, Hindi und Koreanisch die wenigsten Token ab, Kimi K2.5 ist am schlanksten bei Chinesisch und DeepSeek bei Japanisch. Claude Fable 5, Opus 4.8 und Sonnet 5 teilen sich einen Tokenizer (bei jedem gesendeten Sample identische Zahlen) und sind nie am schlanksten: derselbe englische Absatz kostet bei Claude 90 rohe Token gegenüber 55 bei DeepSeek, und der Netto-Aufschlag reicht von 1,3x bei Japanisch bis 2,2x bei Chinesisch. Der Token ist die Abrechnungseinheit, deshalb bestimmen zwei Dinge Ihre Input-Kosten, die auf einer Preisseite selten auftauchen: wie dicht eine Sprache Bedeutung in Zeichen packt und wie gut der Tokenizer jedes Modells dieses Schriftsystem komprimiert hat. Beides multipliziert sich, und das Produkt entspricht nicht dem, was die Betrachtung pro Zeichen vermuten lässt.

TL;DR

• Claude Fable 5, Opus 4.8 und Sonnet 5 teilen sich einen Tokenizer und sind nie am schlanksten: überall 1,2-2,3x der günstigsten Zahl.
• Der günstigste Tokenizer wechselt je nach Sprache: GPT-5.5 bei europäischen Sprachen, Hindi, Koreanisch; Kimi bei Chinesisch; DeepSeek bei Japanisch.
• Pro Zeichen sieht CJK 3x schlechter aus, aber pro Bedeutung liegt Chinesisch nahe an der Parität, während Japanisch und Koreanisch bei 1,5-2,4x liegen.
• Die Kosten sind Schriftdichte mal Tokenizer-Abdeckung; fehlende Abdeckung multipliziert sie (GLM rechnet Hindi mit dem 4,9-Fachen seines Englisch ab).
• Lokalisierung spart selten Geld; das Modell nach Token zur Sprache passen.

Die Zählungen wurden am 08.07.2026 über das Synthorai-Gateway gemessen, immer mit der eigenen Zählung des jeweiligen Anbieters, nie mit einem lokalen Tokenizer. Jede Zählung war über alle Wiederholungen hinweg identisch.

Der Token ist die Abrechnungseinheit, nicht der Text

Abgerechnet wird pro Token, aber ein Token ist weder ein Zeichen noch ein Wort. Jedes Modell bringt seinen eigenen Tokenizer mit eigenem Vokabular mit, und derselbe Satz ergibt bei jedem eine andere Tokenzahl. Diese Zahl multipliziert sich dann mit dem Preis pro Token, es variieren also zwei Dinge gleichzeitig: wie viele Token aus Ihrem Text werden und was jeder Token kostet.

Die meisten Preisseiten zeigen nur die zweite Zahl. Dieser Beitrag misst die erste. Wir haben drei semantisch abgestimmte Textabschnitte an sieben Modelle geschickt (claude-fable-5, claude-opus-4-8, claude-sonnet-5, deepseek-v4-flash, glm-5.2, gpt-5.5, kimi-k2.5) und ausgelesen, was jedes als Input abgerechnet hat.

Eine lockere Erzählung (eine Geschichte über einen Samstagsmarkt) existiert in neun Sprachen; eine technische Erklärung (Retry mit exponentiellem Backoff) und eine Nachrichtenmeldung (eine Abstimmung über den Stadthaushalt) existieren in Englisch, Chinesisch, Japanisch, Koreanisch, Deutsch und Hindi. Eine Python-Funktion und ein JSON-Tool-Call-Blob runden das Set ab. Die nicht-englischen Versionen sind maschinelle Übersetzungen, erstellt nach einer Anweisung zu treuer Übersetzung ohne Komprimierung und stichprobenartig von Hand geprüft; die Wortfülle der Übersetzung ist ein echter Störfaktor, und der Abschnitt zum Register unten grenzt sie auf etwa 20% ein.

Gezählt wird immer über den Anbieter selbst: die Claude-Reihe über einen echten Messages-Aufruf, der usage.input_tokens ausliest (das Gateway leitet count_tokens derzeit nicht weiter), die OpenAI-kompatiblen Modelle über einen kleinen Aufruf, der usage.prompt_tokens ausliest. Ein lokaler Tokenizer, der von der Rechnung abweicht, ist genau der Fehler, den das vermeidet. Eine Kontrolle ist wichtig: jede Anfrage trägt einen festen Rahmen (Chat-Template, Rollen-Marker) im Wert von einer Handvoll Token, deshalb messen wir ein Baseline-Sample mit zwei Zeichen und ziehen es ab. Jedes Verhältnis in diesem Beitrag ist um diesen Rahmen bereinigt und vergleicht den Text, nicht den Rahmen.

Der gleiche Text, fünf Tokenizer

Hier die reine Input-Token-Zahl für die Erzählpassage, aufgeschlüsselt nach Sprache und Tokenizer. Die drei Claude-Modelle teilen sich eine Spalte, weil sie in jedem Sample identische Werte lieferten (dazu gleich mehr). Die beiden anderen Passagen zeigen dasselbe Muster und sind weiter unten eingearbeitet. Die Zeichen-Spalte gibt die Länge der jeweiligen Sprachversion an; Schriftsysteme packen Bedeutung unterschiedlich dicht, deshalb sagt Chinesisch mit 77 Zeichen dasselbe, wofür Englisch 254 braucht.

Zwei Dinge stechen heraus. Die Claude-Spalte enthält eine Zahl für drei Modelle, weil Claude Fable 5, Opus 4.8 und Sonnet 5 in jedem Sample identische Werte lieferten, für Sprachen, Code und JSON gleichermaßen: Alle drei verwenden den mit Opus 4.7 eingeführten Tokenizer, ein Zählwert für eines gilt also für alle. Und diese Spalte ist in jeder Zeile die höchste, außer bei Hindi, wo GLM mit 192 schlechter abschneidet. Normalisiert auf Netto-Werte, sodass das schlankste Modell je Sprache 1,00 ergibt (der Envelope wird zuerst abgezogen, deshalb passen diese Verhältnisse nicht zu einer Division der Rohwerte oben):

Der Vierfach-Gleichstand in der englischen Zeile ist keine Rundung: DeepSeek, GLM, GPT-5.5 und Kimi landen für diese Passage alle auf exakt 50 Netto-Tokens. Claude liegt bei dieser Passage beim 1,3- bis 2,2-Fachen des schlanksten Tokenizers, über alle drei hinweg beim 1,2- bis 2,3-Fachen. Das ist eine Eigenschaft des Vokabulars und gilt für jeden Call über die gesamte Lebensdauer des Modells. Die Technik- und News-Passagen bestätigen die Rangfolge: In der Summe beider berechnet Claude Chinesisch mit 212 Netto-Tokens gegen Kimis 114 (1,9x) und Hindi mit 477 gegen GPT-5.5s 210 (2,3x). Aber darunter gibt es keinen einzelnen Sieger. Die schlankste Spalte wechselt mit der Sprache:

• GPT-5.5 ist am schlanksten bei Deutsch, Französisch, Spanisch, Italienisch, Hindi und Koreanisch und teilt sich den ersten Platz bei Englisch (der Gleichstand und fr/es/it gelten nur für die Erzählpassage). Sein Vokabular ist auf lateinische Schrift ausgelegt und hält sich auch bei Devanagari und Hangul gut.
• Kimi K2.5 ist am schlanksten bei Chinesisch und über CJK hinweg konkurrenzfähig.
• DeepSeek-v4 ist am schlanksten bei Japanisch und liegt bei Chinesisch knapp dahinter.
• GLM 5.2 liegt bei den meisten Sprachen im Mittelfeld, produziert aber bei Hindi die schlechtesten Werte der ganzen Matrix: 2,59x des schlanksten Modells bei der Erzählpassage (179 Netto-Tokens, wo GPT-5.5 nur 69 braucht), noch schlechter bei den formellen Passagen, und die einzige Spalte, die sogar Claude übertrifft.

Der Aufschlag beschränkt sich nicht auf Fließtext. Bei der Python-Funktion liegt Claude beim 1,61-Fachen des schlanksten Modells, beim JSON-Tool-Call beim 1,29-Fachen. Der JSON-Abstand fällt geringer aus, weil strukturierter Text größtenteils aus Interpunktion und kurzen ASCII-Keys besteht, die jeder Tokenizer ähnlich behandelt. Bei einem langlaufenden Agenten, der jede Runde ein großes Tool-Schema erneut mitschickt, summiert sich diese Steuer pro Runde, und genau hier zahlt sich Caching aus. Die Serie zum Prompt-Caching behandelt diese Mechanik.

Die Pro-Zeichen-Falle: CJK sieht schlimmer aus, als es abrechnet

Die obigen Tabellen haben Modelle verglichen. Hält man stattdessen das Modell fest, verschiebt die Sprache die Zahl trotzdem – aber nicht so, wie es die reine Zeichen-Betrachtung nahelegt. Die am häufigsten zitierte Tokenizer-Zahl ist Tokens pro Zeichen, und hier dominiert CJK: Bei Claude kommt Chinesisch auf rund 114 Netto-Tokens pro 100 Zeichen, Koreanisch auf 106, Japanisch auf 94 – gegenüber 32 für Englisch. Liest man nur diese Spalte, sieht CJK nach einem 3x-Aufschlag aus. Es ist aber die falsche Spalte: Bezahlt wird für Bedeutung, nicht für Zeichen, und der ausgerichtete Textabschnitt trägt in jeder Sprache dieselbe Bedeutung. Hier beide Sichtweisen auf Claude für den narrativen Abschnitt:

Die beiden rechten Spalten widersprechen sich, und Chinesisch ist der deutlichste Fall: die höchste Dichte pro Zeichen im Datensatz, aber ein Aufschlag pro Bedeutung von nur 1,07x gegenüber Englisch in diesem Abschnitt. 77 Zeichen tragen das, wofür Englisch 254 braucht. Eine hohe Rate pro Zeichen multipliziert sich also mit einer winzigen Zeichenzahl und hebt sich fast auf. Über alle drei Abschnitte hält diese Aufhebung, aber sie ist kein Zauberwerk: Chinesisch liegt im Schnitt bei 1,17x gegenüber Claudes eigenem Englisch und je nach Modell zwischen 0,95x und 1,32x – nahe an der Parität statt der 3x, die die Pro-Zeichen-Spalte androht.

Japanisch und Koreanisch beantworten die naheliegende nächste Frage: dieselbe Illusion, schwächere Aufhebung. Beide teilen die hohe Dichte pro Zeichen, denn Hangul und die japanischen Kana bilden Laute in etwa ein Glyph pro Silbe ab, statt ein ganzes Wort in ein Zeichen zu packen, wie es die chinesischen Hanzi tun. Koreanisch braucht deshalb 143 Zeichen und Japanisch 136 für den Abschnitt, den Chinesisch in 77 sagt. Mehr Zeichen mal einer hohen Rate pro Zeichen hebt sich nicht auf, sondern summiert sich: Bei Claude liegt Koreanisch im Schnitt der drei Abschnitte bei 1,96x pro Bedeutung gegenüber Englisch und Japanisch bei 1,56x – beide wirklich teuer, obwohl ihre Pro-Zeichen-Spalte stark der von Chinesisch ähnelt.

Deutsch ist das Spiegelbild von Chinesisch: eine niedrige Rate pro Zeichen (48, nahe Englisch), aber die meisten Zeichen aller Sprachen hier (289, wegen der Komposita), was in Summe trotzdem 1,68x ergibt. Kosten sind das Produkt der beiden Achsen, und jede allein gelesen führt in die Irre.

Warum sich die Zahlen bewegen: zwei Faktoren, multipliziert

Hinter jeder Tabelle oben steckt eine einzige Gleichung:

Tokens für eine Passage = (Zeichen zur Ausdrucksweise der Bedeutung) x (Tokens pro Zeichen)

Der erste Faktor ist die Dichte des Schriftsystems, eine Eigenschaft der Sprache, nicht des Modells. Das ist ein Spektrum, keine chinesische Ausnahme. Das logografische Chinesisch packt in jedes Zeichen ein Morphem und liegt am dichten Ende. Japanische Kana und koreanisches Hangul buchstabieren Laute aus, sind also weniger dicht und brauchen mehr Zeichen. Devanagari und die lateinischen Alphabete sind noch weniger dicht. Von Chinesisch zu Englisch nimmt die Bedeutung pro Zeichen stetig ab.

Der zweite Faktor ist, wie viele Tokens das Vokabular des Modells pro Zeichen dieser Schrift aufwendet, und der ist komplett modellspezifisch. Ein BPE-Tokenizer lernt aus seinem Trainingskorpus, mehrere Zeichen zu einem Token zusammenzufassen: Schriften, die er oft gesehen hat, bekommen kompakte Tokens; Schriften, die selten vorkamen, landen wieder bei Zeichen-für-Zeichen- oder sogar Byte-Level-Kodierung, wo ein Zeichen zu zwei oder drei Tokens wird. Dieselben drei Sprachen, Netto-Tokens pro Zeichen:

Die Tabelle erklärt drei Dinge. Chinesisch wirkt in den Summen besonders, weil es beim ersten Faktor extrem liegt: Selbst Claudes schwache Chinesisch-Kompression (1.14 Tokens pro Zeichen, teilt manche Hanzi immer noch in zwei) kann die Summe nicht groß machen, wenn es nur 77 Zeichen sind, und die in China trainierten Modelle komprimieren gut genug (0.52 bis 0.58), um nahe an ihr eigenes Englisch heranzukommen. Der Aufschlag bei Hindi ist der zweite Faktor, nicht die Dichte: GLM wendet 0.91 Tokens pro Devanagari-Zeichen auf, also fast ein Token pro Zeichen, weil sein Vokabular kaum Devanagari-Merges über mehrere Zeichen kennt, während GPT-5.5 mit 0.35 auskommt, indem es ganze Silbencluster abdeckt, eine Abdeckungslücke bei derselben Schrift. Und Claude ist überall hoch, weil seine Rate pro Zeichen sogar bei Englisch hoch ist (0.32 gegenüber 0.20 bei DeepSeek), eine Baseline auf Modellebene, die zu allem hinzukommt, was die Sprache selbst beisteuert.

Nichts davon ist eine Eigenart unserer sieben Modelle. In der Forschungsliteratur heißt das Phänomen Token Premium, und Petrov et al. (NeurIPS 2023) haben es über hunderte Sprachpaare gemessen. Sie fanden dieselben zwei Ursachen (die Zeichenzahl pro Bedeutung unterscheidet sich, und die Tokenizer-Abdeckung pro Schrift unterscheidet sich) und Aufschläge von bis zu 15x bei ressourcenarmen Sprachen, mit denselben Folgen: höhere Kosten, höhere Latenz und weniger nutzbares Context-Window, denn eine Sprache mit hohem Premium füllt dasselbe Context-Budget mit weniger Bedeutung. Die Lücke wird auch kleiner, je mehr die Anbieter investieren: Unabhängige Messungen beziffern Chinesisch auf +182% Tokens gegenüber Englisch bei Vokabularen aus der GPT-3-Ära und +24% bei GPT-4o, nahe an den +32%, die wir bei GPT-5.5 messen, und an der Parität, die wir bei den in China trainierten Modellen messen. Abdeckung wird mit Vokabular-Slots bezahlt, und die Anbieter kaufen weiter zu.

Spart Lokalisierung überhaupt jemals Geld?

Man ist versucht, den Abschnitt über die Fallstricke so zu lesen: “Claude ist über alle Sprachen hinweg gleich, also ignoriert man Lokalisierung” und “China-Modelle sind bei Chinesisch günstig, also spart Lokalisierung Geld.” Beides ist falsch. Hier steht jede Sprache dem englischen Text desselben Modells gegenüber, gemittelt über die drei Passagen, für die fünf Sprachen, bei denen alle drei vorliegen:

Claude ist nicht gleich: Koreanisch kostet das 1,96-Fache seines Englisch, Hindi das 2,40-Fache. Dass Chinesisch bei rund 1,17x liegt, ist ein Zufall bei einer einzigen Sprache, keine Eigenschaft des Modells. Und die China-Modelle schlagen bei Chinesisch die Parität nicht, sie erreichen sie bestenfalls: die beste Zelle der ganzen Tabelle ist Kimis 0,95x, fünf Prozent unter seinem eigenen Englisch, und jede andere Zelle kostet gleich viel oder mehr. Bei Hindi, Japanisch und Koreanisch tragen dieselben Modelle einen größeren Aufschlag als Claude, keinen kleineren, weil diese Schriften weiter von ihrem Trainingsschwerpunkt entfernt sind. Das Muster lautet nicht “Anbieter X ist günstig”; es lautet, dass jedes Modell relativ zu seinem eigenen Englisch bei den Sprachen am schlanksten ist, die seinen Trainingsdaten am nächsten liegen.

Auch das Register verschiebt diese Zahlen. Die lockere Erzählpassage ist der günstigste Fall; die technische Passage und die Nachrichtenpassage treiben fast jeden Multiplikator hoch, weil Fachbegriffe und Lehnwörter genau das sind, wofür nicht-lateinische Vokabulare keine Merges haben. Deutsch geht bei Claude von 1,68x (locker) auf 2,29x (technisch), und GLMs Hindi erreicht bei der Nachrichtenpassage das 5,98-Fache seines Englisch. Ein Benchmark mit nur einer Passage schmeichelt derjenigen Sprache, die die günstigste Übersetzung abbekommen hat, weshalb die einzelne Erzählpassage Chinesisch bei Kimi auf 0,80x brachte und drei Passagen es auf 0,95x setzen.

Relativ zum eigenen Englisch ist ohnehin die falsche Sichtweise. Bezahlt werden absolute Token, und dort ist Claude in acht der neun Sprachen das teuerste Modell, wobei GLMs Hindi die einzige Spalte ist, die schlechter abschneidet. Chinesischer Inhalt, der “relativ zu Claudes Englisch günstig” ist, sind bei der Erzählpassage immer noch 88 Netto-Token auf Claude gegen 40 auf Kimi. Der richtige Schritt ist also nicht, zum Sparen zu lokalisieren, sondern Modell und Sprache aufeinander abzustimmen: Chinesisch zu Kimi oder DeepSeek, Hindi und Koreanisch zu GPT-5.5, Japanisch zu DeepSeek. Claude gewinnt bei den Token-Kosten in keiner Sprache, kann aber bei der Qualität trotzdem vorn liegen.

Zahlen sind nur die halbe Rechnung

Ein Token-Multiplikator sagt nur etwas aus, wenn man ihn neben den Preis pro Token stellt, und beide verstärken sich gegenseitig. Claude Fable 5 kostet $10 pro Million Input-Tokens, Opus 4.8 kostet $5, Sonnet 5 nach Ablauf des Einführungspreises $3. Bei Chinesisch zählt ihr gemeinsamer Tokenizer den Text zudem mit dem 2,2-Fachen des schlanksten Modells, sodass der Zählaufschlag den ohnehin bestehenden Preisunterschied gegenüber der Alternative, auf die du routen würdest, noch weiter vergrößert. Der umgekehrte Fall ist ebenfalls möglich: Ein Modell kann schlank zählen und pro Aufruf trotzdem teurer sein, weil sein Preis hoch ist. Keine der beiden Zahlen allein verrät dir die Rechnung. Die Preise der anderen Anbieter drucken wir hier nicht ab, weil sie sich schneller ändern als Tokenizer; die Zahlen oben sind der beständige Teil der Rechnung.

Praktisch heißt das: Hör auf, Listenpreise zu vergleichen, und vergleiche die effektiven Input-Kosten. Nimm deinen realen Traffic-Mix, zähle ihn auf jedem Kandidatenmodell und multipliziere ihn mit dem Input-Preis dieses Modells. Bei einem Produkt mit viel Chinesisch oder Koreanisch kann diese Umrechnung kippen, welches Modell am günstigsten ist, und der Unterschied ist beständige 1,5- bis 2-fach, kein Rundungsfehler. Aus demselben Grund zählt beim Caching die effektive, mit der Trefferquote gewichtete Kostenzahl statt des Listenpreises, was der Anbietervergleich durchrechnet. Warum Sonnet 5 bei gleichem Englisch 41 % mehr zählt als Sonnet 4.6, also die Version-zu-Version-Sicht dieser Geschichte, steht im Sonnet-5-Tokenizer-Beitrag.

Fazit

• Token-Kosten sind Schriftdichte mal Tokenizer-Abdeckung. Die Sprache bestimmt den ersten Faktor, das Modell den zweiten, und jeder für sich gelesen führt in die Irre.
• Claude Fable 5, Opus 4.8 und Sonnet 5 liegen in jeder Sprache beim 1,2- bis 2,3-Fachen des schlanksten Modells, weil ihr Preis pro Zeichen selbst bei Englisch hoch ist.
• Das schlankste Modell hängt von der Sprache ab: GPT-5.5 für europäische Sprachen, Hindi und Koreanisch, Kimi für Chinesisch, DeepSeek für Japanisch. GLM ist bei Hindi am schwächsten, mit fast einem Token pro Zeichen.
• Formales und technisches Register erhöht den Multiplikator in fast jeder Sprache; benchmarke im Register, das du tatsächlich ausrollst.
• Lokalisiere nicht, um zu sparen; wähle das Modell nach absoluten Tokens für die jeweilige Sprache und multipliziere dann mit dem Preis jedes Modells, um die effektiven Kosten zu vergleichen.

FAQ

Welcher LLM-Tokenizer ist am günstigsten? Das hängt von der Sprache ab. Über sieben Modelle hinweg, angewandt auf dieselben aufeinander abgestimmten Textpassagen, war GPT-5.5 bei den europäischen Sprachen sowie bei Hindi und Koreanisch am sparsamsten (Gleichstand bei Englisch), Kimi K2.5 bei Chinesisch und DeepSeek-v4 bei Japanisch. Die Claude-Familie (Fable 5, Opus 4.8, Sonnet 5) lag nie an der Spitze und produzierte in jeder Sprache und jedem Register das 1,2- bis 2,3-Fache der günstigsten Tokenzahl.

Nutzen Claude Fable 5, Opus 4.8 und Sonnet 5 denselben Tokenizer? Ja. Alle drei lieferten bei jedem Sample identische Tokenzahlen, in jeder Sprache, bei Code und bei JSON. Sie verwenden den mit Opus 4.7 eingeführten Tokenizer, eine Zählung auf einem Modell überträgt sich also auf die anderen. Die höhere Rechnung von Fable 5 kommt allein vom Preis pro Token.

Ist Chinesisch bei Claude teurer als Englisch? Leicht: 1,17x pro Bedeutungseinheit, gemittelt über drei Passagen (und ungefähr gleichauf bei den in China trainierten Modellen). Pro Zeichen sieht es deutlich schlechter aus (etwa 114 Netto-Tokens pro 100 chinesische Zeichen gegenüber 32 bei Englisch), aber Chinesisch transportiert dieselbe Bedeutung mit etwa einem Drittel der Zeichen, sodass sich die Summen nahezu ausgleichen.

Verhalten sich Japanisch und Koreanisch wie Chinesisch? Nur zur Hälfte. Sie teilen die hohe Dichte pro Zeichen mit Chinesisch, aber Hangul und Kana schreiben Laute aus, weshalb sie für dieselbe Passage weit mehr Zeichen brauchen (Japanisch 136, Koreanisch 143 gegenüber 77 bei Chinesisch). Die hohe Rate pro Zeichen gleicht sich damit nicht mehr aus. Pro Bedeutungseinheit liegt Japanisch bei Claude etwa beim 1,6-Fachen von Englisch und Koreanisch beim 2-Fachen, über die sieben Modelle hinweg beim 1,5- bis 2,4-Fachen.

Wie messe ich das für meine eigenen Prompts? Schick ein paar echte Prompts im tatsächlich eingesetzten Register an jedes Kandidatenmodell und lies die Input-Tokenzahl des Anbieters aus den usage-Feldern, statt dich auf einen lokalen Tokenizer zu verlassen. Eine einzelne günstige Passage kann eine Sprache um etwa 20 % besser dastehen lassen, nimm also mehrere. Multipliziere dann jede Zählung mit dem Input-Preis des Modells, um die effektiven Kosten für deinen Traffic zu erhalten.

← Zurück zum Blog