Welches LLM ist für deine Sprache am günstigsten? Tokenizer-Kosten im Vergleich

Für mehrsprachige Texte gibt es nicht das eine günstigste LLM. Beim selben Text berechnet GPT-5.5 für europäische Sprachen, Hindi und Koreanisch die wenigsten Tokens. Bei Chinesisch liegt Kimi K2.5 vorn, bei Japanisch DeepSeek. Claude Fable 5, Opus 4.8 und Sonnet 5 verwenden denselben Tokenizer und lieferten für alle unsere Samples identische Werte. Am effizientesten waren sie nie: Derselbe englische Absatz wird bei Claude mit 90 Tokens abgerechnet, bei DeepSeek mit 55. Bereinigt liegt der Aufschlag zwischen 1.3x für Japanisch und 2.2x für Chinesisch. Da Tokens die Abrechnungseinheit sind, bestimmen zwei Faktoren die Input-Kosten, die auf Preisübersichten kaum auftauchen: wie viel Bedeutung eine Sprache pro Zeichen transportiert und wie gut der Tokenizer des jeweiligen Modells die Schrift komprimiert. Beide Faktoren werden miteinander multipliziert. Das Ergebnis lässt sich nicht an den Kosten pro Zeichen ablesen.

TL;DR

• Claude Fable 5, Opus 4.8 und Sonnet 5 verwenden denselben Tokenizer und sind nie am effizientesten: Die Token-Anzahl liegt durchgehend beim 1.2- bis 2.3-Fachen des jeweiligen Bestwerts.
• Welcher Tokenizer am günstigsten ist, hängt von der Sprache ab: GPT-5.5 bei europäischen Sprachen, Hindi und Koreanisch, Kimi bei Chinesisch, DeepSeek bei Japanisch.
• Pro Zeichen wirkt CJK 3x teurer. Bezogen auf denselben Inhalt liegt Chinesisch aber fast gleichauf, während Japanisch und Koreanisch beim 1.5- bis 2.4-Fachen liegen.
• Die Kosten ergeben sich aus der Schriftdichte multipliziert mit der Tokenizer-Abdeckung. Schlechte Abdeckung vervielfacht sie: GLM berechnet für Hindi 4.9x so viele Tokens wie für Englisch.
• Lokalisierung spart selten Geld. Entscheidend ist, Modell und Sprache anhand der Token-Anzahl aufeinander abzustimmen.

Die Werte wurden am 2026-07-08 über das Synthorai-Gateway gemessen. Wir haben immer die Zählung des jeweiligen Providers verwendet, nie einen lokalen Tokenizer. Bei allen Wiederholungen waren die Werte identisch.

Abgerechnet werden Tokens, nicht Text

Abgerechnet wird pro Token. Ein Token ist aber weder ein Zeichen noch ein Wort. Jedes Modell bringt einen eigenen Tokenizer mit eigenem Vokabular mit. Deshalb zerfällt derselbe Satz je nach Modell in unterschiedlich viele Tokens. Diese Anzahl wird anschließend mit dem Token-Preis multipliziert. Es ändern sich also zwei Größen gleichzeitig: die Token-Anzahl des Textes und der Preis pro Token.

Die meisten Preisübersichten zeigen nur die zweite Zahl. Dieser Beitrag misst die erste. Wir haben drei inhaltlich aufeinander abgestimmte Texte an sieben Modelle gesendet (claude-fable-5, claude-opus-4-8, claude-sonnet-5, deepseek-v4-flash, glm-5.2, gpt-5.5, kimi-k2.5) und jeweils ausgelesen, wie viele Input-Tokens berechnet wurden.

Ein lockerer Erzähltext über einen Samstagsmarkt liegt in neun Sprachen vor. Eine technische Erklärung zu Retries mit exponentiellem Backoff und eine kurze Nachricht über die Abstimmung zu einem städtischen Haushalt gibt es jeweils auf Englisch, Chinesisch, Japanisch, Koreanisch, Deutsch und Hindi. Ergänzt wird der Datensatz durch eine Python-Funktion und ein JSON-Objekt für einen Tool-Call. Die nicht englischen Fassungen wurden per maschineller Übersetzung erstellt. Die Vorgabe verlangte eine originalgetreue Übersetzung ohne Kürzungen; anschließend wurden die Texte manuell stichprobenartig geprüft. Unterschiedliche Ausführlichkeit bei Übersetzungen bleibt ein echter Störfaktor. Der Abschnitt zum Sprachregister grenzt diesen Effekt auf ungefähr 20% ein.

Gezählt wird immer durch den Provider selbst: bei Claude über einen echten Messages-Call und usage.input_tokens, weil das Gateway count_tokens derzeit nicht weiterleitet; bei OpenAI-kompatiblen Modellen über einen kleinen Call und usage.prompt_tokens. Damit vermeiden wir genau den Fehlerfall, bei dem ein lokaler Tokenizer andere Werte liefert als die Rechnung. Eine Kontrollgröße ist entscheidend: Jede Anfrage enthält ein festes Framing aus Chat-Template und Rollenmarkern, das einige Tokens ausmacht. Deshalb messen wir ein Baseline-Sample mit zwei Zeichen und ziehen dessen Wert ab. Alle Verhältnisse in diesem Beitrag sind um diesen Overhead bereinigt und vergleichen den eigentlichen Text, nicht das Framing.

Derselbe Text, fünf Tokenizer

Die folgende Tabelle zeigt die rohe Anzahl der Input-Tokens für den Erzähltext, aufgeschlüsselt nach Sprache und Tokenizer. Die drei Claude-Modelle teilen sich eine Spalte, weil sie für jedes Sample identische Werte geliefert haben. Dazu weiter unten mehr. Die beiden anderen Texte zeigen dasselbe Muster und fließen später in die Auswertung ein. Die Zeichenspalte gibt die Länge der jeweiligen Sprachfassung an. Schriftsysteme transportieren unterschiedlich viel Bedeutung pro Zeichen: Chinesisch drückt denselben Inhalt in 77 Zeichen aus, für den Englisch 254 benötigt.

Zwei Ergebnisse fallen sofort auf. Für Claude gibt es nur eine Spalte, weil Claude Fable 5, Opus 4.8 und Sonnet 5 bei allen Samples identische Werte zurückgegeben haben, unabhängig von Sprache, Code oder JSON. Alle drei verwenden den mit Opus 4.7 eingeführten Tokenizer. Eine Messung für eines dieser Modelle gilt deshalb auch für die anderen. Außerdem enthält diese Spalte in jeder Zeile den höchsten Wert, außer bei Hindi, wo GLM mit 192 noch schlechter abschneidet. Die folgende Tabelle ist anhand der bereinigten Werte normalisiert. Das jeweils effizienteste Modell einer Sprache erhält den Wert 1.00. Da der Request-Overhead vorher abgezogen wird, entsprechen die Verhältnisse nicht der direkten Division der Rohwerte aus der Tabelle oben:

Der Gleichstand von vier Modellen in der englischen Zeile ist kein Rundungseffekt: DeepSeek, GLM, GPT-5.5 und Kimi kommen bei diesem Text alle auf exakt 50 bereinigte Tokens. Claude liegt bei diesem Text beim 1.3- bis 2.2-Fachen des effizientesten Tokenizers, über alle drei Texte hinweg beim 1.2- bis 2.3-Fachen. Ursache ist das Vokabular. Dieser Effekt betrifft während der gesamten Lebensdauer des Modells jeden Call. Der technische Text und die Nachricht bestätigen die Rangfolge. Zusammengerechnet berechnet Claude für beide chinesischen Texte 212 bereinigte Tokens, Kimi dagegen 114 (1.9x). Bei Hindi sind es 477 gegenüber 210 bei GPT-5.5 (2.3x). Einen universellen Sieger gibt es trotzdem nicht. Die effizienteste Spalte wechselt mit der Sprache:

• GPT-5.5 ist bei Deutsch, Französisch, Spanisch, Italienisch, Hindi und Koreanisch am effizientesten und teilt sich bei Englisch den Bestwert. Der Gleichstand sowie die Ergebnisse für fr/es/it gelten nur für den Erzähltext. Das Vokabular ist auf lateinische Schriften optimiert und funktioniert auch bei Devanagari und Hangul gut.
• Kimi K2.5 ist bei Chinesisch am effizientesten und schneidet im gesamten CJK-Bereich gut ab.
• DeepSeek-v4 ist bei Japanisch am effizientesten und liegt bei Chinesisch knapp dahinter.
• GLM 5.2 liegt bei den meisten Sprachen im Mittelfeld, liefert bei Hindi aber die schlechtesten Werte der gesamten Matrix: beim Erzähltext 2.59x so viele Tokens wie das effizienteste Modell, also 179 bereinigte Tokens gegenüber 69 bei GPT-5.5. Bei den formelleren Texten fällt das Ergebnis noch schlechter aus. GLM ist hier das einzige Modell, das sogar Claude übertrifft.

Der Aufschlag betrifft nicht nur Fließtext. Bei der Python-Funktion liegt Claude beim 1.61-Fachen des Bestwerts, beim JSON-Tool-Call beim 1.29-Fachen. Bei JSON ist der Abstand kleiner, weil strukturierte Daten hauptsächlich aus Satzzeichen und kurzen ASCII-Keys bestehen, mit denen alle Tokenizer ähnlich umgehen. Bei einem langlebigen Agenten, der in jedem Turn ein großes Tool-Schema erneut sendet, summiert sich dieser Aufschlag. Genau dort lohnt sich Caching. Die Artikelreihe zu Prompt-Caching erklärt die Mechanik.

Die Falle beim Zeichenvergleich: CJK sieht teurer aus, als es abgerechnet wird

Die bisherigen Tabellen vergleichen Modelle. Hält man stattdessen das Modell konstant, ändert die Sprache ebenfalls die Token-Anzahl, aber anders, als der reine Zeichenvergleich vermuten lässt. Die am häufigsten zitierte Tokenizer-Kennzahl ist Tokens pro Zeichen. Dabei sticht CJK heraus: Bei Claude kommt Chinesisch auf etwa 114 bereinigte Tokens pro 100 Zeichen, Koreanisch auf 106 und Japanisch auf 94. Englisch liegt bei 32. Betrachtet man nur diese Spalte, wirkt CJK wie ein Aufschlag von 3x. Das ist jedoch die falsche Perspektive. Bezahlt wird für übermittelten Inhalt, nicht für Zeichen, und der abgestimmte Text enthält in jeder Sprache dieselbe Bedeutung. Die folgende Tabelle zeigt beide Sichtweisen für den Erzähltext bei Claude:

Die beiden rechten Spalten vermitteln ein gegensätzliches Bild. Am deutlichsten ist das bei Chinesisch: Die Sprache hat die höchste Token-Dichte pro Zeichen im Datensatz, kostet für denselben Inhalt aber nur 1.07x so viel wie Englisch. 77 Zeichen transportieren denselben Inhalt, für den Englisch 254 Zeichen benötigt. Die hohe Rate pro Zeichen wird daher mit einer sehr kleinen Zeichenanzahl multipliziert und fast vollständig ausgeglichen. Der Ausgleich zeigt sich bei allen drei Texten, ist aber nicht perfekt: Chinesisch liegt bei Claude im Durchschnitt beim 1.17-Fachen des englischen Werts. Je nach Modell reicht die Spanne von 0.95x bis 1.32x. Das ist nahezu gleichauf und weit entfernt von den 3x, die der Vergleich pro Zeichen erwarten ließe.

Japanisch und Koreanisch zeigen, wo dieser Ausgleich schwächer wird. Beide haben ebenfalls eine hohe Token-Dichte pro Zeichen. Hangul und die japanischen Kana bilden Laute aber ungefähr mit einem Zeichen pro Silbe ab, statt wie chinesische Hanzi ein ganzes Wort in ein Zeichen zu packen. Deshalb benötigt Koreanisch 143 Zeichen und Japanisch 136 für denselben Text, der auf Chinesisch mit 77 auskommt. Mehr Zeichen bei gleichzeitig hoher Token-Rate pro Zeichen gleichen sich nicht aus, sondern verstärken einander. Bei Claude kostet Koreanisch über die drei Texte hinweg im Durchschnitt 1.96x so viele Tokens pro Inhaltseinheit wie Englisch, Japanisch 1.56x. Beide Sprachen sind damit tatsächlich teuer, obwohl ihre Werte pro Zeichen denen von Chinesisch ähneln.

Deutsch ist das Gegenbild zu Chinesisch: Die Rate pro Zeichen ist mit 48 niedrig und liegt nahe an Englisch. Gleichzeitig hat die deutsche Fassung mit 289 Zeichen den höchsten Wert im Vergleich, unter anderem wegen ihrer Komposita. Insgesamt ergibt sich dadurch trotzdem ein Faktor von 1.68x. Die Kosten sind das Produkt beider Achsen. Wer nur eine davon betrachtet, zieht den falschen Schluss.

Warum sich die Werte ändern: zwei Faktoren, miteinander multipliziert

Hinter allen Tabellen steht dieselbe Gleichung:

Tokens für einen Text = (Zeichen für denselben Inhalt) x (Tokens pro Zeichen)

Der erste Faktor ist die Informationsdichte des Schriftsystems. Sie ist eine Eigenschaft der Sprache, nicht des Modells. Dabei handelt es sich um ein Spektrum, nicht um einen chinesischen Sonderfall. Das logografische Chinesisch bildet mit jedem Zeichen ein Morphem ab und liegt am dichten Ende des Spektrums. Japanische Kana und koreanisches Hangul bilden Laute ab, sind daher weniger dicht und benötigen mehr Zeichen. Devanagari und die lateinischen Alphabete sind noch weniger dicht. Die Bedeutung pro Zeichen nimmt von Chinesisch bis Englisch kontinuierlich ab.

Der zweite Faktor gibt an, wie viele Tokens das Vokabular des Modells pro Zeichen dieser Schrift benötigt. Dieser Wert hängt vollständig vom Modell ab. Ein BPE-Tokenizer lernt aus seinem Trainingskorpus, mehrere Zeichen zu gemeinsamen Tokens zusammenzufassen. Häufig vorkommende Schriften erhalten kompakte Tokens. Bei seltenen Schriften nähert sich die Kodierung dagegen einer Aufteilung nach einzelnen Zeichen oder sogar Bytes, sodass ein Zeichen zwei oder drei Tokens belegen kann. Für dieselben drei Sprachen ergeben sich folgende bereinigte Werte pro Zeichen:

Die Tabelle erklärt drei Effekte. Chinesisch fällt in der Gesamtsumme auf, weil der erste Faktor extrem ist. Selbst Claudes schwache Kompression für Chinesisch mit 1.14 Tokens pro Zeichen, bei der einige Hanzi weiterhin in zwei Tokens zerfallen, führt wegen der nur 77 Zeichen nicht zu einer hohen Gesamtsumme. Die in China trainierten Modelle komprimieren mit 0.52 bis 0.58 Tokens pro Zeichen gut genug, um fast auf dem Niveau ihres eigenen englischen Werts zu landen. Der Aufschlag bei Hindi entsteht nicht durch die Dichte, sondern durch den zweiten Faktor. GLM benötigt 0.91 Tokens pro Devanagari-Zeichen, also fast ein Token pro Zeichen, weil sein Vokabular kaum aus mehreren Zeichen bestehende Devanagari-Merges enthält. GPT-5.5 benötigt dagegen nur 0.35 Tokens, weil ganze Silbencluster abgedeckt sind. Das ist eine Abdeckungslücke bei derselben Schrift. Claude liegt überall hoch, weil bereits seine Rate für Englisch mit 0.32 gegenüber 0.20 bei DeepSeek erhöht ist. Zu dieser modellweiten Basis kommt der jeweilige Spracheffekt noch hinzu.

Dieses Verhalten ist keine Besonderheit unserer sieben Modelle. In der Forschung heißt das Phänomen Token-Aufschlag. Petrov et al. (NeurIPS 2023) haben es für Hunderte Sprachpaare gemessen und dieselben beiden Ursachen gefunden: Für denselben Inhalt werden unterschiedlich viele Zeichen benötigt, und die Tokenizer decken die Schriften unterschiedlich gut ab. Bei ressourcenarmen Sprachen lagen die Aufschläge bei bis zu 15x. Die Folgen sind höhere Kosten, höhere Latenz und ein kleineres nutzbares Context Window, weil eine Sprache mit hohem Aufschlag dasselbe Kontextbudget mit weniger Inhalt füllt. Mit Investitionen der Anbieter wird die Lücke kleiner: Unabhängige Messungen ermittelten für Chinesisch mit Vokabularen aus der GPT-3-Ära +182% Tokens gegenüber Englisch und mit dem Vokabular von GPT-4o noch +24%. Das liegt nahe an den von uns gemessenen +32% bei GPT-5.5 und der annähernden Parität bei den in China trainierten Modellen. Abdeckung kostet Vokabularplätze, und die Anbieter investieren weiter darin.

Spart Lokalisierung jemals Geld?

Aus dem Abschnitt zur Zeichenfalle könnte man zwei falsche Schlüsse ziehen: „Claude ist über alle Sprachen hinweg gleich, also spielt Lokalisierung keine Rolle“ und „Chinesische Modelle sind bei Chinesisch günstig, also spart Lokalisierung Geld.“ Die folgende Tabelle vergleicht jede Sprache mit dem englischen Wert desselben Modells. Gezeigt wird der Durchschnitt über alle drei Texte für die fünf Sprachen, die in allen drei vorkommen:

Claude ist keineswegs über alle Sprachen hinweg gleich: Koreanisch kostet 1.96x so viel wie Englisch, Hindi 2.40x. Dass Chinesisch mit 1.17x fast gleichauf liegt, ist eine Besonderheit dieser Sprache und keine allgemeine Eigenschaft des Modells. Auch die chinesischen Modelle unterbieten bei Chinesisch nicht grundsätzlich den englischen Wert, sondern erreichen ihn ungefähr. Der beste Wert der gesamten Tabelle ist Kimi mit 0.95x, also fünf Prozent weniger als beim eigenen englischen Text. Alle anderen Zellen liegen gleichauf oder darüber. Bei Hindi, Japanisch und Koreanisch haben dieselben Modelle einen größeren Aufschlag als Claude, nicht einen kleineren, weil diese Schriften weiter vom Schwerpunkt ihrer Trainingsdaten entfernt sind. Das Muster lautet nicht „Anbieter X ist günstig“. Jedes Modell ist relativ zu seinem eigenen englischen Wert bei den Sprachen am effizientesten, die den Trainingsdaten am nächsten sind.

Auch das Sprachregister beeinflusst die Werte. Der lockere Erzähltext ist der günstigste Fall. Der technische Text und die Nachricht erhöhen fast alle Multiplikatoren, weil gerade Fachbegriffe und Lehnwörter in nicht lateinischen Vokabularen oft nicht als Merges vorhanden sind. Bei Claude steigt Deutsch von 1.68x im lockeren Text auf 2.29x im technischen Text. GLM erreicht bei Hindi in der Nachricht 5.98x seines englischen Werts. Ein Benchmark mit nur einem Text begünstigt die Sprache, deren Übersetzung am knappsten ausgefallen ist. Deshalb lag Chinesisch im einzelnen Erzähltext bei Kimi bei 0.80x, über drei Texte hinweg aber bei 0.95x.

Der Vergleich mit dem eigenen englischen Wert ist ohnehin nicht die entscheidende Perspektive. Bezahlt wird die absolute Token-Anzahl. Dabei ist Claude in acht der neun Sprachen am teuersten. Die einzige Ausnahme ist Hindi bei GLM. Chinesischer Content, der „im Verhältnis zu Claudes englischem Wert günstig“ ist, kostet im Erzähltext bei Claude trotzdem 88 bereinigte Tokens, bei Kimi dagegen 40. Lokalisierung ist deshalb kein Sparmechanismus. Stattdessen sollte das Modell zur Sprache passen: Kimi oder DeepSeek für Chinesisch, GPT-5.5 für Hindi und Koreanisch, DeepSeek für Japanisch. Claude gewinnt in keiner Sprache bei den Token-Kosten, kann qualitativ aber weiterhin die beste Wahl sein.

Die Token-Anzahl ist nur die halbe Rechnung

Ein Token-Multiplikator wird erst zusammen mit dem Preis pro Token relevant. Beide Faktoren verstärken einander. Claude Fable 5 kostet laut Listenpreis $10 pro Million Input-Tokens, Opus 4.8 $5 und Sonnet 5 nach Ende der Einführungspreise $3. Bei Chinesisch zählt ihr gemeinsamer Tokenizer außerdem 2.2x so viele Tokens wie das effizienteste Modell. Dieser Aufschlag wird mit dem ohnehin vorhandenen Preisunterschied zu der Alternative multipliziert, an die der Request sonst geroutet würde. Auch das Gegenteil ist möglich: Ein Modell kann wenige Tokens berechnen und wegen seines hohen Token-Preises trotzdem mehr pro Call kosten. Keine der beiden Kennzahlen reicht allein aus. Die Preise der anderen Anbieter führen wir hier nicht auf, weil sie sich schneller ändern als die Tokenizer. Die oben gemessenen Token-Anzahlen sind der langlebigere Teil der Berechnung.

Vergleiche deshalb nicht die Listenpreise, sondern die effektiven Input-Kosten: den tatsächlichen Traffic-Mix, gezählt mit jedem infrage kommenden Modell und multipliziert mit dessen Input-Preis. Bei einem Produkt mit überwiegend chinesischem oder koreanischem Traffic kann sich dadurch die Rangfolge der günstigsten Modelle umkehren. Der Unterschied liegt dauerhaft bei 1.5x bis 2x und ist kein Rundungsfehler. Aus demselben Grund zählt beim Caching der mit der Hit-Rate gewichtete effektive Preis und nicht der Listenpreis. Der Anbietervergleich rechnet das im Detail durch. Wie sich die Tokenizer zwischen Versionen verändern und warum Sonnet 5 für denselben englischen Text 41% mehr Tokens berechnet als Sonnet 4.6, erklärt der Beitrag zum Tokenizer von Sonnet 5.

Fazit

• Die Token-Kosten ergeben sich aus der Schriftdichte multipliziert mit der Tokenizer-Abdeckung. Die Sprache bestimmt den ersten Faktor, das Modell den zweiten. Eine isolierte Betrachtung führt bei beiden in die Irre.
• Claude Fable 5, Opus 4.8 und Sonnet 5 liegen in jeder Sprache beim 1.2- bis 2.3-Fachen des effizientesten Modells, weil ihre Token-Rate pro Zeichen bereits bei Englisch hoch ist.
• Welches Modell am effizientesten ist, 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 schneidet bei Hindi am schlechtesten ab und benötigt fast ein Token pro Zeichen.
• Formelle und technische Sprache erhöht den Multiplikator in fast jeder Sprache. Benchmarks sollten deshalb dasselbe Register verwenden wie die produktiven Requests.
• Lokalisiere nicht, um Kosten zu sparen. Wähle das Modell anhand der absoluten Token-Anzahl für die jeweilige Sprache und multipliziere sie anschließend mit dem Preis des Modells, um die effektiven Kosten zu vergleichen.

FAQ

Welcher LLM-Tokenizer ist am günstigsten? Das hängt von der Sprache ab. Bei sieben Modellen und denselben inhaltlich abgestimmten Texten war GPT-5.5 für die europäischen Sprachen, Hindi und Koreanisch am effizientesten und lag bei Englisch gleichauf. Bei Chinesisch führte Kimi K2.5, bei Japanisch DeepSeek-v4. Die Claude-Familie aus Fable 5, Opus 4.8 und Sonnet 5 war nie am effizientesten. Ihre Token-Anzahl lag in allen Sprachen und Registern beim 1.2- bis 2.3-Fachen des jeweiligen Bestwerts.

Verwenden Claude Fable 5, Opus 4.8 und Sonnet 5 denselben Tokenizer? Ja. Alle drei lieferten bei jedem Sample identische Token-Anzahlen, unabhängig von Sprache, Code oder JSON. Sie verwenden den mit Opus 4.7 eingeführten Tokenizer. Eine Messung für eines der Modelle gilt daher auch für die anderen. Die höhere Rechnung von Fable 5 entsteht ausschließlich durch den höheren Preis pro Token.

Ist Chinesisch bei Claude teurer als Englisch? Etwas: Bezogen auf denselben Inhalt liegt Chinesisch im Durchschnitt der drei Texte bei 1.17x. Bei den in China trainierten Modellen herrscht ungefähr Gleichstand. Pro Zeichen wirkt der Unterschied deutlich größer: etwa 114 bereinigte Tokens pro 100 chinesische Zeichen gegenüber 32 bei Englisch. Chinesisch übermittelt denselben Inhalt jedoch mit ungefähr einem Drittel der Zeichen, sodass sich die Gesamtwerte fast ausgleichen.

Verhalten sich Japanisch und Koreanisch wie Chinesisch? Nur teilweise. Beide haben wie Chinesisch eine hohe Token-Dichte pro Zeichen. Hangul und Kana bilden jedoch Laute ab und benötigen deshalb für denselben Text deutlich mehr Zeichen: Japanisch 136 und Koreanisch 143 gegenüber 77 bei Chinesisch. Die hohe Rate pro Zeichen wird dadurch nicht mehr ausgeglichen. Bezogen auf denselben Inhalt liegt Japanisch bei Claude bei ungefähr 1.6x des englischen Werts, Koreanisch bei etwa 2x. Über alle sieben Modelle hinweg reicht die Spanne von 1.5x bis 2.4x.

Wie messe ich das für meine eigenen Prompts? Sende mehrere echte Prompts in demselben Sprachregister wie deine produktiven Requests an jedes infrage kommende Modell. Lies die Input-Token-Anzahl aus den Usage-Feldern des Providers aus, statt einem lokalen Tokenizer zu vertrauen. Ein einzelner günstiger Text kann eine Sprache um etwa 20% besser aussehen lassen, deshalb solltest du mehrere verwenden. Multipliziere anschließend jede Token-Anzahl mit dem Input-Preis des jeweiligen Modells, um die effektiven Kosten für deinen Traffic zu berechnen.

← Zurück zum Blog