Token-Steuer 2026: LLM-Tokenizer im Vergleich

TL;DR

Wir haben die Tokenizer aktueller LLMs anhand unterschiedlicher Texte und Sprachen verglichen.

• Überzeugend über alle Sprachen hinweg: Cohere Command A+, Metas Muse (Glimmer und Spark; auf Basis des Vokabulars von Llama 4), xAI Grok 4.6, Alibaba Qwen 3.8, OpenAI o200k (GPT-6, GPT-5, gpt-oss)
• Vorsicht vor der hohen Claude-Steuer: im Schnitt +65 % Tokens, bei deutschen Texten +101 %

1. Einleitung

Große Sprachmodelle (LLMs) verarbeiten und erzeugen Tokens. Was genau ein Token ist, bestimmt der Tokenizer des Modells, genauer gesagt sein Vokabular. Jedes Token ist ein Eintrag in einem Vokabular, das normalerweise vor Trainingsbeginn festgelegt wird. Manchmal kommen im Post-Training noch spezielle Tokens hinzu.

Bei den meisten aktuellen Modell-Tokenizern wird das Vokabular mit Byte Pair Encoding (BPE) aus dem Trainingsdatensatz oder einem Teil davon gelernt. Angefangen mit einzelnen Bytes, werden die am häufigsten vorkommenden Byte-Paare wiederholt zu neuen Vokabulareinträgen zusammengeführt. Solange, bis das Vokabular die gewünschte Größe erreicht hat. Dabei entstehen die zwei zentralen Bestandteile eines BPE-Tokenizers: 1) das Vokabular und 2) eine geordnete Liste von Zusammenführungen, mit der sich die Textsegmentierung reproduzieren lässt. Da sich die Trainingsdaten und Vokabular-Zielgröße zwischen Modellen unterscheiden, unterscheiden sich auch ihre Tokenizer-Vokabulare. Derselbe Text kann deshalb unterschiedlich viele Tokens benötigen, je nachdem, welches Modell ihn liest oder erzeugt. Wer sein Wissen über Tokenisierung auffrischen möchte, findet einen guten Einstieg in den Kapiteln C2S4 – Tokenisierung und C6S5 – BPE des LLM-Kurses von Hugging Face.

Hier verarbeiten zwei Tokenizer denselben Satz:

Bei LLM-APIs wird fast immer pro Token abgerechnet, mit unterschiedlichen Preisen für Eingabe- und Ausgabetokens. Die Anzahl der Tokens, in die ein Text zerlegt wird, beeinflusst somit direkt die Rechnung. Die Tokenizer-Effizienz wirkt sich aber nicht nur auf den Preis aus. Wer Modelle vergleicht, sollte zumindest grob einschätzen können, welchen Einfluss die Tokenisierung auf folgende Größen hat:

• Preis. Bei einem festen Preis pro Token kostet ein Text, der 30 % mehr Tokens benötigt, beim Senden und beim Generieren jeweils 30 % mehr. Je nach Tokenizer-Effizienz sind Preise pro Token deshalb nicht direkt vergleichbar.
• Inferenzgeschwindigkeit. Bei gleichem Decoding-Durchsatz in Tokens pro Sekunde dauert die Generierung derselben Antwort 30 % länger, wenn ihr Tokenizer dafür 30 % mehr Tokens benötigt. Selbst bei gleicher Modellarchitektur kann sich der Durchsatz mit der Vokabulargröße ändern. Die Tokenizer-Effizienz spielt deshalb auch beim Vergleich von Tokens pro Sekunde (TPS) und Limits in Tokens pro Minute (TPM) eine Rolle.
• Maximales Kontextfenster. Kontextlimits werden in Tokens angegeben. In dasselbe Fenster passt je nach Tokenizer unterschiedlich viel Text. Die Größen von Kontextfenstern sind deshalb nicht ohne Weiteres vergleichbar.
• Ausgabe- und Reasoning-Budgets. Auch Limits für die generierte Ausgabe werden in Tokens festgelegt, einschließlich der Reasoning-Budgets von Thinking-Modellen. Ein Modell, das mehr Tokens braucht, um einen Gedanken auszudrücken, kommt möglicherweise weniger weit, bevor es das Limit erreicht. Je nach Tokenizer-Effizienz sind Budgeteinstellungen deshalb nicht direkt vergleichbar.

In diesem Beitrag messen wir, wie groß die Unterschiede in der Tokenizer-Effizienz tatsächlich sind. Wir testen 20 Tokenizer aktueller proprietärer Modelle und Modelle mit offenen Gewichten auf einem Datensatz mit 21 verschiedenen Text- und Promptarten. Den Test führen wir in zwölf Sprachen durch, um zu untersuchen, wie sich die Effizienz zwischen Sprachen unterscheidet.

Wir suchen Antworten auf folgende Fragen:

• Wie viele Tokens benötigt derselbe Text bei aktuellen Tokenizern? Wie stark hängt das von Textart und Sprache ab?
• Für welche Sprachen optimieren die verschiedenen Modellanbieter? Was steckt in ihren Tokenizer-Vokabularen?
• Wie lange bleiben Tokenizer über Modellgenerationen hinweg im Einsatz, und wie haben sich ihre Vokabulargrößen entwickelt?

2. Versuchsaufbau

2.1 Tokenizer

Wir testen 20 Tokenizer aktueller proprietärer Modelle und Modelle mit offenen Gewichten. Ihre Vokabulare reichen von etwa 16.000 bis 262.000 Einträgen. Manche Modellentwickler übernehmen die Tokenizer anderer Anbieter: Das Inkling-Modell von Thinking Machines verwendet beispielsweise OpenAIs o200k-Tokenizer aus tiktoken. Mistrals Tekken-Tokenizer kommt auch in NVIDIAs Nemotron 3 und im Schweizer Modell Apertus zum Einsatz, mit minimalen Unterschieden bei den im Post-Training hinzugefügten Spezial-Tokens. Metas Muse Glimmer und Spark verwenden ein nahezu identisches Vokabular wie Llama 4. Von den Einträgen im öffentlichen Muse-Glimmer-Vokabular kommen 99,0 % auch in Llama 4 vor.

2.2 Datensätze

Unsere Tests umfassen Texte unterschiedlicher Quellen, Textarten und Sprachen sowie Quellcode. Der erste Teil unseres Datensatzes besteht aus echten, von Menschen geschriebenen Dokumenten. Die Quellen umfassen Webseiten, PDFs, Enzyklopädien, öffentliche Ausschreibungen, Nachrichten, Gerichts- und Parlamentsunterlagen sowie offene wissenschaftliche Datensätze. Der zweite Teil enthält 3.261 synthetische Beispiele für dreizehn typische Aufgaben von LLM-Assistenten. Für zehn dieser Aufgaben haben wir Ausschnitte aus echten Dokumenten in typische Prompts eingebettet, wie sie ein LLM-Assistent im produktiven Einsatz erhalten könnte. Wir stellen den Datensatz in zwölf Sprachen zusammen: Englisch, Deutsch, Französisch, Spanisch, Italienisch, Niederländisch, Polnisch, Schwedisch, Chinesisch, Japanisch, Koreanisch und Arabisch. So ergeben sich 96 Dokument-Splits: acht Textarten in jeder Sprache.

Die zehn dokumentbasierten Aufgaben umfassen Zusammenfassen, Extraktion nach JSON, Umformulieren, Klassifizieren, Kritik, Fragen zum Dokument, Antwortentwürfe, einfaches Erklären, mehrstufige Chats und das Überführen wichtiger Punkte in eine Tabelle.

Der dritte Teil unseres Testdatensatzes besteht aus Quellcode und beinhaltet Python, JavaScript, C++, Bash und SQL. Hier bedienen wir uns beim Stack-Edu-Datensatz. Ergebnisse für Quellcode fließen nicht in Vergleiche zwischen natürlichen Sprachen ein, wir behandeln Code stattdessen als eigene, separate Sprache. Wir entfernen außerdem alle Code-Teile, die mehr als 5 % Nicht-ASCII-Zeichen beinhalten, damit unser Vergleich auch wirklich Quellcode misst und nicht die Sprache, in der Kommentare oder Docstrings geschrieben sind.

2.3 Unser Messverfahren

Wir teilen echte Dokumente und Code in Chunks mit einer Zielgröße von 1.000 o200k-Referenztokens. Ein Chunk darf dabei Dokumentgrenzen überschreiten. Synthetische Prompts und Antworten zählen wir jeweils als vollständige Beispiele. Für jeden Chunk beziehungsweise jedes Beispiel teilen wir die Tokenanzahl durch die Tokenanzahl, die der o200k-Tokenizer für exakt denselben Text benötigt. Innerhalb jeder Textart bilden wir das arithmetische Mittel dieser Verhältnisse, mean(t / t_ref). Anschließend gewichten wir die Textarten innerhalb jeder Sprache gleich und die Sprachen für das EU- und Gesamtergebnis ebenfalls gleich. Fehlende Textarten lassen wir aus. Code wird separat gemittelt.

Als Standardreferenz verwenden wir OpenAIs o200k-Tokenizer aufgrund seiner Popularität und weil er in unseren Tests exzellent abschneidet. Zusätzlich berichten wir die durchschnittliche Zahl der Tokens pro 1.000 Zeichen. Konfidenzintervalle je Textart bestimmen wir durch Bootstrapping über Chunks beziehungsweise Beispiele. Aggregierte Intervalle nähern die Unsicherheit des Mittelwerts an, indem sie Stichprobenfehler mit der Streuung zwischen Textarten und gegebenenfalls Sprachen kombinieren.

Bei proprietären Tokenizern ermitteln wir die Tokenzahlen über die API des jeweiligen Anbieters. Anthropic und Google bieten API-Endpunkte, die Tokens zählen, ohne das Modell auszuführen. Die Grok-API von xAI hat eine tokenize_text Funktion, die Text als Token-Sequenz zurückgibt. Um die Tokenzahlen des reinen Textes zu vergleichen, ziehen wir den geschätzten Overhead an Spezial-Token der Chat-Nachrichten ab. In zwei kurzen Checks haben wir zudem geprüft, ob die APIs mit lokal ausgeführter Tokenisierung übereinstimmen: Gemini 3.x und der öffentliche Gemma-4-Tokenizer liefern identische Tokenzahlen, dasselbe gilt für GPT-5.6, GPT-6 Astra und gpt-oss.

3. Ergebnisse

3.1 Die Gewinner

Command A+ liegt in acht der zwölf Sprachen vorn und belegt insgesamt den ersten Platz. Muse und Grok 4.6 folgen auf den Plätzen zwei und drei. Anfangs hatten wir erwartet, dass der effizienteste Tokenizer stark von der Sprache abhängt. Meistens ist das aber nicht der Fall. Selbst in den drei Sprachen, in denen Command A+ nicht auf dem Podium steht, gehört er noch zu den besten sechs. Muse, o200k und Gemini 3/Gemma 4 vervollständigen die Gruppe der starken Allrounder: Sie landen immer unter den besten zehn.

Bei Chinesisch geht das gesamte Podium erwartungsgemäß an chinesische Anbieter: Kimi liegt vor DeepSeek-V4 und Qwen3.8. Europäische Tokenizer glänzen bei Polnisch. Bei Niederländisch schlägt kein Tokenizer OpenAIs o200k; der zweitplatzierte Muse benötigt 6,7 % mehr Tokens.

3.2 Hohe Token-Steuern

Claude 4.7+ benötigt in acht der zwölf getesteten Sprachen mehr Tokens als jeder andere Tokenizer und erreicht nie einen besseren Rang als Platz 16. Bei deutschen Texten braucht er doppelt so viele Tokens wie OpenAIs Modelle! Wer Preise für denselben deutschen Text vergleichen möchte, sollte Claudes Preis pro Token also ungefähr verdoppeln, um ihn auf eine mit o200k vergleichbare Basis zu bringen. Über alle Sprachen hinweg benötigt Claude 4.7+ 65,3 % mehr Tokens – eine ziemlich hohe Steuer.

Mit Ausnahme von Qwen sind alle chinesischen Modell-Tokenizer Spezialisten. Sie sind hervorragend bei Chinesisch und liegen bei Englisch etwa auf Referenzniveau, benötigen für die getesteten EU-Sprachen im Schnitt aber mindestens 10 % mehr Tokens.

Für deutsche Texte benötigt Kimi K3 29,4 % und Laguna S 2.1 42,2 % mehr Tokens als die OpenAI-Modelle und Inkling von Thinking Machines.

3.3 Vergleich zwischen Sprachen und Textarten

Die folgende Grafik zeigt, wie sich die Tokenizer-Effizienz zwischen Sprachen und Textarten verändert.

Beim Wechsel von Englisch zu Deutsch ändert sich der Rang von sechzehn der zwanzig Tokenizer. Kimi K3 gehört bei Englisch zu den besten fünf, liegt bei Deutsch aber nur auf Platz 17. OpenEuroLLM 256k schneidet in Englisch unterdurchschnittlich ab, steigt aber von Platz 16 auf Platz 2 für Deutsch. Nur Command A+, Muse und Grok 4.6 bleiben in beiden Sprachen unter den besten vier.

Wie stark hängen diese Durchschnittswerte davon ab, was tokenisiert wird? Hier könnt ihr einen Tokenizer und eine Sprache auswählen, um zu sehen, welche Textarten mehr oder weniger Token-Overhead als der Durchschnitt aufweisen. Die gestrichelte Linie markiert diesen Durchschnitt.

Über alle Kombinationen aus Tokenizer und Sprache hinweg hat die Textart meist einen moderaten Einfluss, es gibt aber erhebliche Ausnahmen. Für jede Kombination vergleichen wir das höchste mit dem niedrigsten Verhältnis einer Textart (max / min - 1). Die durchschnittliche Spannweite beträgt 12 %, die größte aber 60 %: Bei Gemini 3.x/Gemma 4 reicht das Verhältnis für Japanisch von 0,728 bei wissenschaftlichen Texten bis 1,167 bei politischen Texten.

3.4 Code

Bei Quellcode ist das Tokenzahlverhältnis zu o200k für 14 der 20 Tokenizer höher als bei englischen Texten. Claude 4.7+ benötigt für denselben Code 70,3 % mehr Tokens als die o200k-Referenz. Command A+ ist mit 2,2 % weniger Tokens erneut am effizientesten. Auch Llama 3.x, Muse, GLM-5.3 und cl100k schlagen o200k knapp. Die auf europäische Sprachen ausgerichteten Vokabulare fallen bei Code etwas zurück. EuroLLM benötigt 43,5 % mehr Tokens, die beiden OpenEuroLLM-Tokenizer 26,9 % und 30,9 % mehr. Laguna S 2.1 wurde für Coding entwickelt, seine Tokenizer-Effizienz spiegelt das in unseren Tests aber nicht wider. Er benötigt 11,1 % mehr Tokens als die Referenz und landet damit auf Platz 14. Gemessen in Tokens pro 1.000 Zeichen ist SQL für 16 der 20 Tokenizer die teuerste der fünf Programmiersprachen.

4. Ein Blick in die Vokabulare

Wir analysieren die veröffentlichten Vokabulardateien der Tokenizer und ordnen ihre Einträge einer Sprache oder einem Schriftsystem zu.

Dafür teilen wir die Einträge der 17 öffentlichen Vokabulare in sieben Kategorien ein:

So lässt sich grob beschreiben, was ein Vokabular darstellen kann. Das bildet nicht zwangsläufig ab, was in seinen Trainingsdaten enthalten war, kann aber Hinweise darauf geben.

Hier sind die Vokabularanteile, die wir verschiedenen Sprachen und Gruppen zuordnen:

Zu den ostasiatischen Schriftsystemen zählen Han-Zeichen, japanische Kana und koreanisches Hangul. Wir berichten sie nach Schriftsystem, weil Han-Zeichen sowohl im Chinesischen als auch im Japanischen vorkommen und sich nicht eindeutig einer der beiden Sprachen zuordnen lassen.

Der eindeutig den sieben europäischen Sprachen zugeordnete Anteil reicht von 1,7 % bei Kimi K3 bis 15,6 % bei EuroLLM. Die Herkunft des Modellentwicklers lässt diese Anteile recht zuverlässig vorhersagen. Die vier chinesischen Tokenizer reservieren zwischen 19,3 % und 42,9 % für ostasiatische Schriftsysteme, die beiden OpenEuroLLM-Vokabulare dagegen nur 0,2 % und 0,1 %. EuroLLM und OpenEuroLLM haben entsprechend vergleichsweise viele Einträge für die sieben getesteten EU-Sprachen vorgesehen.

Mehr Einträge für eine Sprachgruppe reichen allein aber nicht für den Sieg. Im Durchschnitt über die sieben getesteten EU-Sprachen schlägt keiner der vier europäischen Tokenizer o200k. OpenEuroLLM 256k benötigt zwar nur 1,3 % mehr Tokens, hat aber ein um 30 % größeres Vokabular. EuroLLM benötigt 5,6 % mehr Tokens, Mistrals Tekken 7,8 % und OpenEuroLLM 128k 9,2 %. EuroLLM schlägt o200k nur bei Polnisch. Beide OpenEuroLLM-Vokabulare schlagen die Referenz bei Polnisch und Italienisch, verlieren aber bei Französisch und Niederländisch. Tekken verliert in allen sieben Sprachen, einschließlich Französisch. OpenEuroLLM optimiert allerdings für 36 europäische Sprachen. Die sieben von uns getesteten Sprachen sind also nur ein Teil dessen, was sein Vokabular abdecken muss.

Die beiden Vokabulare mit dem größten strukturellen Anteil, cl100k und Laguna S 2.1, verwenden dafür jeweils fast 40 % ihrer Einträge: etwa ein Viertel des Vokabulars für Satzzeichen, Ziffern und Symbole, den Rest für kurze Fragmente und Steuertokens. Poolside entwickelt seine Modelle vor allem für Coding-Anwendungen; auf den ersten Blick ergibt das also Sinn. In Abschnitt 3.4 haben wir das jedoch direkt gemessen und das Gegenteil festgestellt: Laguna benötigt für Code 11,1 % mehr Tokens als o200k und liegt damit nur auf Platz 14 von 20. Ein großer Anteil struktureller Tokens führt also nicht automatisch dazu, dass das Vokabular für Code effizient ist.

Die unterschiedliche Verteilung der Vokabulareinträge erklärt einen Großteil von dem, was wir in Abschnitt 3 gemessen haben. Der Kimi-Tokenizer enthält nur 570 deutsche Einträge, was in etwa 0,35 % des Vokabulars entspricht. Weniger als 30 % der tausend häufigsten deutschen Wörter bestehen aus einem einzigen Token, was Kimis geringe Effizienz bei deutschen Texten erklärt.

Die Verteilung der Einträge kann wichtiger sein als die Vokabulargröße. DeepSeek-V4 hat zum Beispiel nur etwa halb so viele Einträge wie Gemini 3.x/Gemma 4, nämlich 129.280 statt 262.144, und benötigt für Chinesisch trotzdem 15 % weniger Tokens. DeepSeek verwendet 35.285 Vokabulareinträge für Han-Zeichen, Gemini 3.x/Gemma 4 dagegen 20.163.

5. Tokenizer im Zeitverlauf

Tokenizer ändern sich langsam und werden oft über mehrere Modellgenerationen oder Versionen hinweg weiterverwendet. Kimi K3 erschien beispielsweise ein Jahr nach Kimi K2 und verwendet dasselbe Vokabular. Mistrals Tekken v1 wurde Mitte 2024 mit dem Nemo-Modell eingeführt und ist bis heute im Einsatz – nicht nur bei Mistral selbst, sondern auch in NVIDIAs Nemotron 3 und 3.5, Apertus und SOOFI. Selbst OpenAI scheint keinen Anlass zu sehen, seinen o200k-Tokenizer abzulösen: Er steckt weiterhin in den veröffentlichten Frontier-Modellen des Anbieters.

Vokabulare werden im Laufe der Zeit nicht immer größer. Rekonstruktionen deuten darauf hin, dass Anthropic Claudes Vokabular verkleinert hat: von 65.000 Einträgen bei Claude 1 und 2 auf geschätzte 49.152 bei Claude 3 bis 4.6 und auf 16.384 ab Claude 4.7. Die beiden neueren Größen sind Schätzungen und wurden nicht von Anthropic veröffentlicht; siehe Lands Rekonstruktion. Die kleinste Schätzung entspricht ungefähr einem Zwölftel des o200k-Vokabulars von OpenAI. Z.ai ging nach einer frühen Verkleinerung den umgekehrten Weg: von 130.344 Einträgen bei ChatGLM auf 64.789 bei ChatGLM2 und 3 und anschließend auf 151.343 ab GLM-4. Bei Google und Cohere blieben die Vokabulargrößen weitgehend konstant.

6. Grenzen und Einschränkungen

Tokenizer-Effizienz ist nicht Modellqualität. Wie viele Tokens ein Text benötigt, sagt nicht zwangsläufig viel darüber aus, wie gut ein Modell damit umgeht. Wie gut ein Modell in einer Sprache schlussfolgert, schreibt oder Anweisungen befolgt, muss überhaupt nicht mit der Tokenizer-Effizienz zusammenhängen. Ein Modell mit weniger effizientem Tokenizer kann für eine Aufgabe trotzdem die bessere Wahl sein. Anthropic gelingt es trotz geringer Tokenizer-Effizienz, die Leistungsgrenze weiter zu verschieben. Gerade deshalb ist der Wechsel zu einem deutlich kleineren Vokabular so interessant. Stabilisieren ein kleineres Vokabular die Optimierung von großen Transformer-Modellen, oder fördert es gemeinsame Repräsentationen über Sprachen hinweg, oder bietet es einen anderen Vorteil, der den zusätzlichen Token-Verbrauch ausgleicht? Unsere Messungen können das nicht beantworten. Uns würde aber sehr interessieren, welchen Vorteil Anthropic aus Sicht unserer Leserinnen und Leser mit dieser Entscheidung erzielt.

Ein Vokabulareintrag garantiert nicht, dass das Modell ihn gut nutzt. In Abschnitt 4 zählen wir, was die verschiedenen Vokabulare enthalten. Wird ein Vokabular aber auf einem Datensatz erstellt und anschließend für das Modelltraining auf einem anderen verwendet, können Einträge entstehen, die das Modell kaum zu sehen bekommt. Land und Bartolo (2024) nennen sie unzureichend trainierte Tokens und zeigen, dass sie weit verbreitet sind. Das bekannteste Beispiel ist SolidGoldMagikarp in GPT-2 und GPT-3. Das ist ein bekanntes Risiko bei der Übernahme bestehender Tokenizer-Vokabulare.

Unsere Testdatensätze sind keine parallelen Übersetzungen. Für jede Sprache messen wir die Verhältnisse zur Referenz. So vermeiden wir Effekte, die durch Übersetzung entstehen, nehmen dafür aber in Kauf, dass wir weniger belastbare direkte Aussagen zwischen Sprachen treffen können. Deshalb vergleicht Abschnitt 3.3 Rangfolgen und relative Verhältnisse zu einer Referenz innerhalb der jeweiligen Sprache, statt Texte in unterschiedlichen Sprachen als gleichwertig zu behandeln.

Unsere Verhältnisse messen Kompression, nicht Vorhersagequalität. Für jeden Tokenizer berichten wir seine Tokenzahl geteilt durch die Tokenzahl des Referenz-Tokenizers für denselben Text. In der Literatur wird dies auch als normalisierte Sequenzlänge bezeichnet. Bits pro Byte ist eine Metrik zum Vergleich von LLMs mit unterschiedlichen Vokabularen. Dafür wird der Modellverlust pro Token in Bits mit den Tokens pro Byte des Tokenizers multipliziert. Hier messen wir nur den zweiten dieser beiden Faktoren. Unser Tokenzahlverhältnis ist unabhängig von Zeichen und Bytes: Beide kommen in t / t_ref nicht vor. Die Achse für die absolute Tokendichte in der interaktiven Grafik hängt dagegen von dieser Wahl ab. In einer separaten Prüfung der lokal gemessenen Textkorpora ohne Code führte eine Rangfolge nach durchschnittlichen Tokens pro Byte statt pro Zeichen zu zwei Vertauschungen benachbarter Plätze: einer bei Arabisch und einer bei Japanisch. Dabei geht es um absolute Dichten; die referenzrelativen Verhältnisse ändern sich nicht. Ein japanisches Zeichen benötigt beispielsweise etwa 2,7 UTF-8-Bytes. In diesen Textkorpora kostet Japanisch beim Referenz-Tokenizer pro Zeichen das 3,48-Fache von Englisch und pro Byte das 1,33-Fache. Wir haben uns letztlich für Zeichen entschieden, weil das die Einheit ist, die man tippt und zählen kann. Über Schriftsysteme hinweg löst aber keine der beiden Einheiten das Vergleichsproblem: Hundert japanische und hundert deutsche Zeichen sind nicht dieselbe Mitteilung. Dafür bräuchte man aus den oben genannten Gründen parallele Texte.

Ein Teil unseres Testdatensatzes wurde von Modellen erzeugt. Unsere synthetischen Beispiele enthalten Prompts und Antworten, die auf Basis echter Textausschnitte generiert wurden. Damit wollten wir neben reinen Dokumenten auch typische Texte aus der Nutzung von LLM-Assistenten testen.

7. Die wichtigsten Erkenntnisse

• Command A+ schneidet insgesamt am besten ab. Er gewinnt in acht der zwölf Sprachen. Muse und Grok 4.6 sind die nächstbesten Allrounder in unserem Test.
• Claude 4.7+ braucht mit Abstand die meisten Tokens. Bei Deutsch das 2,01-Fache der Referenz, über alle zwölf Sprachen hinweg 65,3 % mehr. In acht der zwölf getesteten Sprachen liegt er auf dem letzten Platz.
• Die Tokenizer-Wahl kann einen Faktor von rund 2 ausmachen. Für denselben deutschen Text erzeugt der ineffizienteste Tokenizer 2,1-mal so viele Tokens wie der effizienteste.
• Die Textart hat meist einen moderaten Einfluss, mit Ausnahmen. Die Spannweite zwischen dem höchsten und niedrigsten Verhältnis je Textart beträgt innerhalb einer Sprache im Schnitt 12 %, im größten Fall aber 60 %.
• Spezialisten sind in wenigen Sprachen hervorragend und in anderen unter den schlechtesten. Kimi K3 liegt bei Chinesisch auf Platz eins und bei Deutsch auf Platz 17.
• Auch rein englische Anwendungen zahlen eine Token-Steuer. Claude 4.7+ braucht für englische Texte 58,6 % mehr Tokens als OpenAIs Modelle.
• Warum einen eigenen Tokenizer entwickeln? OpenAI hat das Leistungsniveau von GPT-6 Astra mit einem Tokenizer erreicht, den das Unternehmen im Mai 2024 veröffentlicht hat. Auch Thinking Machines verwendet o200k für seine Inkling-Modelle und hat sich gegen die Entwicklung eines eigenen Tokenizers entschieden. Keiner der vier europäischen Tokenizer schlägt o200k im Durchschnitt über die sieben getesteten EU-Sprachen, und bei Code schneiden sie ebenfalls schlechter ab! Bessere Unterstützung für Sprachen, die bestehende Tokenizer schlecht abdecken, kann ein guter Grund für einen eigenen Tokenizer sein. Man sollte sich aber der Abwägungen bewusst sein und sorgfältig prüfen, ob sich der Aufwand lohnt. Potenziell unzureichend trainierte Tokens loszuwerden, kann ein weiterer Grund für ein eigenes Vokabular sein. Aber warum nicht einfach ein bestehendes Vokabular ausdünnen?

Fehlt euer Lieblings-Tokenizer?

Wenn ein Tokenizer fehlt, der euch wichtig ist, oder ihr Ergebnisse für eine nicht berücksichtigte Sprache sucht, meldet euch bei uns.

Danksagung

• Diese Arbeit wird durch das Projekt OpenEuroLLM unterstützt, kofinanziert durch das Programm „Digitales Europa“ unter der Fördervereinbarung Nr. 101195233.
• Diese Arbeit wird durch das Projekt LLMs4EU unterstützt, kofinanziert durch das Programm „Digitales Europa“ unter der Fördervereinbarung Nr. 101198470.
• Diese Arbeit wird durch das Bundesministerium für Wirtschaft und Energie (BMWE) im Rahmen von EU-SAI/SOOFI: Sovereign Open Source Foundation Models for European Intelligence gefördert (Förderkennzeichen 13IPC040J).
• Diese Arbeit wird durch das Land Nordrhein-Westfalen und die Europäische Union im Rahmen des Innovationsprogramms NEXT.IN.NRW über das Projekt LLM4KMU gefördert.