LLM Basics: Tokenizer – warum derselbe Text unterschiedlich viele Tokens benötigt

Ein Tokenizer ist bei tokenbasierten Sprachmodellen die Schnittstelle zwischen Text und Modell.

Er zerlegt Text in Einheiten, sogenannte Tokens, und ordnet ihnen ganzzahlige IDs zu. Diese IDs verweisen auf gelernte Vektoren, die Embeddings, mit denen das Modell weiterrechnet.

Ein Token entspricht dabei nicht automatisch einem Wort. Es kann ein vollständiges Wort, einen Wortbestandteil, ein Satzzeichen oder eine Byte-Sequenz repräsentieren.

Der Ablauf sieht wie folgt aus:

Der eingegebene Text wird vom Tokenizer zunächst in Tokens zerlegt und in Token-IDs übersetzt. Anhand dieser IDs wählt das Modell die zugehörigen Embedding-Vektoren aus und verarbeitet sie im Kontext der gesamten Eingabe.

Auf dieser Grundlage sagt das Modell schrittweise das jeweils nächste Token voraus. Aus diesen Vorhersagen werden Token-IDs ausgewählt, die zusammen die Antwort bilden. Der Decoder des Tokenizers wandelt diese Folge anschließend in lesbaren Text um.

Warum Tokenizer wichtig sind

Die Tokenisierung beeinflusst, wie kompakt ein Text für ein Modell dargestellt wird. Das hat praktische Konsequenzen:

• Kontextfenster: Mehr Tokens benötigen mehr Platz im verfügbaren Kontext.
• Kosten: Bei tokenbasierter Abrechnung beeinflusst die Tokenzahl die Rechnung.
• Latenz: Die Länge der Tokensequenz ist ein Einflussfaktor auf den Rechenaufwand.
• Mehrsprachigkeit: Derselbe Inhalt kann je nach Sprache und Tokenizer unterschiedlich viele Tokens benötigen.
• Zeichenabdeckung: Byte-basierte Verfahren können auch seltene Zeichen über ihre Bytes darstellen.

Die Tokenisierung bestimmt allerdings nicht allein, wie schnell oder wie gut ein Modell antwortet.

Mein Experiment: Derselbe Thai-Satz, fünf Tokenizer

Ich lerne Thai und habe deshalb diesen Satz verglichen:

สวัสดีครับผมชื่อมาริอุสและผมพูดภาษาไทยครับ

Auf Deutsch:

Hallo, ich heiße Marius und ich spreche Thai.

Thai trennt Wörter im laufenden Text normalerweise nicht durch Leerzeichen wie Deutsch. Das macht die Frage interessant, welche Zeichenfolgen ein Tokenizer als zusammenhängende Einheiten kennt. Fehlende Wortzwischenräume sind aber nicht allein die Erklärung für unterschiedliche Tokenzahlen.

Auf Tiktokenizer habe ich den Satz mit fünf verschiedenen Tools verglichen:

Messgrundlage und Einschränkungen

Die Werte stammen aus meinen dokumentierten Browsermessungen vom 20. Oktober 2026. Verglichen wurde der oben gezeigte Satz.

Die Gemma-Sequenz enthält zusätzlich ein BOS-Token mit ID 2. BOS steht für „Beginning of Sequence“. Für den Vergleich der reinen Texttokenisierung weise ich diesen Marker separat aus: 19 angezeigte Tokens entsprechen hier 18 Texttokens plus einem Startmarker. Für einen tatsächlichen Modellaufruf kann der Marker dennoch erforderlich sein. Die Gemma-Dokumentation beschreibt sowohl die BOS-ID als auch das automatische Ergänzen dieses Tokens.

Der Vergleich ist ein Anschauungsbeispiel, kein allgemeiner Benchmark für Thai und keine Messung vollständiger API-Anfragen. Chatformatierung und zusätzliche Nachrichten können weiteren Tokenverbrauch verursachen.

Warum unterscheiden sich die Zahlen?

Ein Tokenizer besitzt ein Vokabular, das Text- oder Byte-Sequenzen auf Token-IDs abbildet. Eine Zeichenfolge kann bei einem Tokenizer als eine bekannte Einheit vorliegen, während ein anderer sie in mehrere kleinere Bestandteile zerlegt.

Dafür sind nicht einmal grundsätzlich verschiedene Algorithmen nötig: GPT-2, cl100k_base und das bei GPT-4o verwendete o200k_base sind BPE-basierte Encodings. Sie unterscheiden sich aber in ihren Vokabularen und weiteren Tokenisierungsregeln.

Diese Zuordnungen und Beispiele für unterschiedliche Zerlegungen dokumentiert das OpenAI Cookbook. DeepSeek-R1 und Gemma verwenden die Tokenizer-Konfigurationen ihrer jeweiligen Modellrepositories. Gemmas Tokenizer nutzt BPE mit Byte-Fallback und ist SentencePiece-basiert.

Der Unterschied liegt also nicht einfach in „BPE gegen einen anderen Algorithmus“. Vokabular, gelernte Zusammenführungen, Vorverarbeitung und weitere Regeln beeinflussen die konkrete Zerlegung.

Echte Token-IDs: GPT-2 und DeepSeek-R

Besonders deutlich wird der Unterschied beim direkten Vergleich dieser beiden Ergebnisse.

GPT-2: Beginn der Token-Sequenz

Die ersten zwölf der insgesamt 84 Token-IDs lauten:

[19567, 103, 19567, 100, 19567, 109,
 19567, 103, 19567, 242, 19567, 113, …]

Die Auslassung steht für die restlichen 72 Token-IDs.

DeepSeek-R1: Vollständige Token-Sequenz

Beim DeepSeek-R1-Tokenizer wird derselbe Satz durch diese 18 Token-IDs dargestellt:

[2952, 34189, 2952, 25581, 79813, 113459,
 70400, 2088, 3768, 2659, 56354, 2952,
 8429, 113459, 92006, 100663, 39311, 79813]

Hier ist bereits die vollständige Sequenz abgebildet.

Für diesen Satz benötigt DeepSeek-R1 rund 78,6 % weniger Tokens als GPT-2. Umgekehrt ist die GPT-2-Sequenz etwa 4,7-mal so lang.

Die Zahlenlisten zeigen die tatsächlichen IDs und die unterschiedliche Sequenzlänge. Ohne das jeweilige Vokabular lassen sie sich aber nicht direkt als Text lesen. Die Zahlenwerte selbst bilden keine gemeinsame Skala: Eine größere ID bedeutet weder mehr Text noch höhere Qualität.

Ein Token muss kein vollständiges Zeichen sein

Unicode-Zeichen können in UTF-8 mehrere Bytes benötigen. Bei Byte-Level-Tokenizern kann ein Token nur einen Teil dieser Bytes enthalten – oder umgekehrt mehrere vollständige Zeichen repräsentieren.

Token-Grenzen müssen deshalb weder mit Wortgrenzen noch mit Unicode-Zeichengrenzen übereinstimmen. Die farbigen Blöcke im Tool sind nicht automatisch Buchstaben oder Silben. OpenAI warnt entsprechend davor, einzelne Tokens ohne Prüfung ihrer Byte-Grenzen als eigenständigen Text zu dekodieren; dafür gibt es die Methode decode_single_token_bytes().

Was zeigt das Experiment – und was nicht?

Das Experiment zeigt, wie unterschiedlich kompakt die ausgewählten Tokenizer diesen Satz darstellen.

Es zeigt nicht, welches Modell Thai am besten versteht, welche Antworten fachlich richtig sind oder welche API insgesamt am günstigsten ist. Ebenso wenig lässt sich der gemessene Faktor ungeprüft auf andere Texte oder Sprachen übertragen.

Welche Tokenizer-Ansätze gibt es?

BPE, WordPiece und Unigram sind Subword-Verfahren. SentencePiece ist davon als Implementierungswerkzeug zu unterscheiden.

Warum Subword-Tokenisierung ein Kompromiss ist

Wortbasierte Tokenisierung benötigt ein großes Vokabular und hat Schwierigkeiten mit unbekannten Wörtern, Namen oder neuen Zusammensetzungen.

Zeichenbasierte Tokenisierung bleibt flexibler, erzeugt aber längere Sequenzen.

Ein anschauliches und echtes Beispiel ist:

Grundstücksverkehrsgenehmigungszuständigkeitsübertragungsverordnung

Das Wort hat 67 Buchstaben. Bei einer einfachen Tokenisierung mit einem Token pro Buchstaben wären allein dafür 67 Tokens erforderlich.

Subword-Verfahren liegen dazwischen: Häufige Wörter können als Ganzes repräsentiert werden, seltene Wörter werden in kleinere bekannte Einheiten zerlegt.

Welche Grenzen entstehen, hängt vom konkreten Vokabular ab. Die Teile müssen dabei nicht sprachlich sinnvollen Einheiten wie Silben oder Wortstämmen entsprechen.

Was bedeutet das für die Modellauswahl?

Kosten pro Aufgabe statt nur Tokenpreise vergleichen

Für die Input-Kosten gilt:

Dabei ist:

• $C_{\text{Input}}$: die Kosten der Eingabe.
• $N_{\text{Input-Tokens}}$: die Anzahl der Input-Tokens.
• $P_{\text{Input}}$: der Preis pro Million Input-Tokens.

Tokenzahl und Tokenpreis wirken zusammen. Eine API mit höherem Preis pro Token kann für denselben Text trotzdem günstiger sein, wenn sie deutlich weniger Tokens benötigt.

Ein hypothetisches Beispiel:

Modell B ist pro Token teurer, pro Aufgabe aber günstiger.

Das Beispiel berücksichtigt ausschließlich den Input. In einer echten Anwendung gehören außerdem folgende Bestandteile in die Kalkulation:

• Systemprompt und zusätzliche Anweisungen.
• Gesprächsverlauf.
• Abgerufene Dokumente, beispielsweise aus einem RAG-System.
• Generierte Antwort.
• Weitere Modellaufrufe und mögliche Wiederholungen.

Input und Output können außerdem unterschiedlich bepreist sein. Eine kompakte Eingabe garantiert deshalb noch keine niedrigen Gesamtkosten.

Kontextfenster in nutzbarer Textmenge betrachten

Ein Kontextlimit wird bei tokenbasierten Modellen in Tokens angegeben.

Da unterschiedliche Tokenizer denselben Text unterschiedlich zerlegen, entspricht dieselbe Tokenzahl nicht automatisch derselben Textmenge.

Für meine Anwendung ist daher die relevante Frage:

Wie viele meiner typischen Dokumente oder Chatnachrichten passen tatsächlich in den verfügbaren Kontext - einschließlich Anweisungen und Platz für die Antwort?

Ein Tokenizer, der meine Inhalte kompakter darstellt, lässt bei gleichem Tokenlimit mehr Platz für diese Inhalte.

Die Ergebnisse eines kurzen Thai-Satzes lassen sich allerdings nicht ungeprüft auf ganze Dokumente oder andere Sprachen übertragen.

Tokenverbrauch und Sprachverständnis getrennt messen

Mein Experiment vergleicht ausschließlich die Tokenisierung der Eingabe.

Es beantwortet nicht, ob ein Modell:

• Den Satz richtig versteht.
• Namen zuverlässig erkennt.
• Sprachlich korrekt antwortet.
• Eine fachliche Aufgabe erfolgreich löst.

Weniger Tokens sind daher kein Beweis für bessere Antworten.

Für eine fundierte Modellentscheidung brauche ich zwei getrennte Messungen:

1. Wie viele Tokens und welche Kosten entstehen?
2. Wie zuverlässig löst das Modell meine konkrete Aufgabe?

Tokenizer und Modell als zusammengehöriges System behandeln

Ich kann nicht einfach den DeepSeek-Tokenizer vor GPT-2 setzen, um dessen Tokenverbrauch zu reduzieren.

Die Token-IDs müssen zur gelernten Embedding-Zuordnung des Modells passen. Dieselbe Zahl kann bei zwei Tokenizern für völlig unterschiedliche Einheiten stehen.

Ein Austausch ist deshalb keine einfache Konfigurationsänderung. Änderungen am Vokabular erfordern entsprechende Anpassungen am Modell und gegebenenfalls weiteres Training.

Bei einem bestehenden Modell verwende ich daher den dazugehörigen Tokenizer.

Wie ich einen produktnahen Benchmark aufbauen würde

Mein einzelner Thai-Satz ist ein Anschauungsbeispiel. Für eine Produktentscheidung würde ich einen repräsentativen Testdatensatz zusammenstellen:

Für jedes Modell würde ich anschließend messen:

1. Tokenverbrauch bei identischen Eingaben.
2. Antwortqualität bei der konkreten Aufgabe.
3. Vollständige Input- und Output-Kosten.
4. Antwortzeit unter vergleichbaren Bedingungen.
5. Anteil der Fälle, die Nachbearbeitung oder einen zweiten Versuch benötigen.

Der wirtschaftlich relevante Zielwert ist nicht „wenigste Tokens“, sondern:

Kosten pro erfolgreich erledigter Aufgabe = Gesamtkosten aller Versuche / Anzahl erfolgreich erledigter Aufgaben.

Dabei bleiben Erfolgsquote, Sicherheitsanforderungen und akzeptable Antwortzeiten eigene Entscheidungskriterien. Ein billiges System mit unzureichender Qualität ist keine gute Wahl.

Fazit

Ein Token ist keine universelle Texteinheit. Wie viel Text es repräsentiert, hängt vom Tokenizer und seinem Vokabular ab.

Mein Thai-Beispiel macht diesen Unterschied sichtbar: Derselbe Satz wird je nach Tokenizer unterschiedlich stark fragmentiert.

Für die Modellauswahl reicht aber weder die Tokenzahl noch der Preis pro Million Tokens allein aus. Entscheidend ist die Kombination aus tatsächlichem Verbrauch, Antwortqualität, Antwortzeit und Kosten pro erfolgreich erledigter Aufgabe.