Tokens & Tokenizer

Modelle sehen nie Wörter oder Buchstaben. Sie sehen Token-IDs — Ganzzahlen, die in ein festes Vokabular aus Subwort-Stücken indizieren, gebaut mit Byte-Pair Encoding (BPE) oder einer nahen Variante. Tokenisierung ist der Grenzübergang für alles: Ihr Prompt, die Antwort, das Kontextfenster, der Tokens-pro-Sekunde-Zähler, API-Rechnungen. Sobald Sie in Tokens denken, löst sich die Hälfte des Folklore-Wissens über LLM-Verhalten auf.

Wie ein Vokabular entsteht

BPE startet bei rohen Bytes und verschmilzt wiederholt das häufigste benachbarte Paar, bis das Vokabular sein Budget erreicht. Das Ergebnis: Häufige Wörter werden einzelne Tokens, seltene Wörter 2–5 Stücke, und nichts ist unrepräsentierbar — Byte-Fallback deckt jeden String ab, inklusive Tippfehlern und Emojis. Vokabulare reichen von ~30k Einträgen (ältere Modelle) bis ~250k (modern, multilingual):

Ein Tokenizer, der überwiegend auf Englisch trainiert wurde, verschmilzt englische Fragmente aggressiv; koreanische Silbenpaare bekommen weit weniger nützliche Merges. Das Vokabular entscheidet über Ihre Koreanisch-Steuer, lange bevor das Model selbst gut oder schlecht in Koreanisch ist.

Durchgerechnetes Beispiel: Englisch

"Tokenization turns text into pieces."

→ ["Token", "ization", " turns", " text", " into", " pieces", "."]
→ 37 characters → 7 tokens ≈ 5.3 chars/token

Beachten Sie die Details: Das häufige Wort „Token“ ist ein Stück; das Suffix bekommt ein eigenes; und das führende Leerzeichen gehört zum folgenden Token („ turns“, nicht „turns“). Deshalb sind „hello“, „ hello“ und „Hello“ verschiedene Tokens — Prompts, die sich durch ein Leerzeichen oder einen Großbuchstaben unterscheiden, tokenisieren unterschiedlich.

Durchgerechnetes Beispiel: Koreanisch

Gleicher Satz, schlechtere Ökonomie. Hangul wird in Silbenblöcken geschrieben, und koreanische Merges sind in englischlastigen Vokabularen seltener (die Splits unten sind plausibel, nicht exakt):

"안녕하세요, 만나서 반가워요."        # 17 Zeichen

starkes multilinguales Vokabular (~150k Einträge):
["안녕", "하세요", ",", " 만나", "서", " 반", "가", "워", "요", "."]
→ ~10 tokens ≈ 1.7 chars/token

schwaches Vokabular (~32k Einträge, Splits auf Jamo-Ebene):
["안", "녕", "하", "세", "요", ",", " 만", "나", "서", ...]
→ 15+ tokens ≈ 1.1 chars/token

Englisch liegt im Schnitt bei ~4 Zeichen pro Token. Koreanisch landet üblicherweise bei 1–1,5. Gleiche Bedeutung, 3–4× die Tokens. Deshalb:

• CJK-Prompts fressen Kontextfenster alarmierend schnell — ein 8k-Token-Fenster fasst grob 3–4× mehr Englisch als Koreanisch.
• Generierung „fühlt“ sich auf Koreanisch bei identischem tok/s langsamer an: mehr Tokens pro Satz, weniger Text pro Token.
• Koreanisch kostet bei APIs mit Token-Abrechnung mehr, und auf Koreanisch geschriebene Reasoning-Traces verbrennen das Budget genauso.

Warum Buchstabenzähl-Fragen scheitern

Fragen Sie „wie viele r hat strawberry“ — selbst große Modelle patzen. Grund: Das Model sieht nie Buchstaben. „strawberry“ kommt als ungefähr ["straw", "berry"] an — zwei Ganzzahlen. In einer Ganzzahl steckt keine Buchstabenzahl, so wenig wie eine Seitenzahl die Rechtschreibung der Seite verrät. Das Model kann auswendig gelernte Schreibweisen aufsagen oder Schritt für Schritt argumentieren, und beides ist unzuverlässig. Wenn es sein muss: Zwingen Sie das Model, das Wort zunächst mit einem Buchstaben pro Zeile zu buchstabieren, und zählen Sie dann die Zeilen.

Das Vokabular kommt mit dem Model mit

• Tokenizer-Dateien (Vokabular, Merges) sind Teil des Releases; GGUF bettet sie ein, Safetensors-Repos führen sie neben den Gewichten mit.
• Engines (llama.cpp, LM Studio, vLLM, …) laden den passenden Tokenizer automatisch. Sie suchen nie einen aus.
• Token-Zahlen sind modelrelativ: Derselbe Text kann im Vokabular der einen Familie 1.000 Tokens sein und in dem einer anderen 1.150. Hardcoden Sie nie Token-Budgets modellübergreifend.
• Vokabular-Qualität und Model-Qualität sind getrennte Achsen: Ein Modell mit 32k-Vokabular kann Koreanisch (es versteht seine Tokens); es gibt nur mehr Tokens pro Satz aus.

Alles wird in Tokens abgerechnet

Spezial-Tokens und das Chat-Template

Neben Textstücken reserviert das Vokabular Steuer-IDs: Beginning-of-Sequence, End-of-Sequence und Rollen-Marker. Wenn Ihre Chat-UI eine Nachricht sendet, sendet sie keinen rohen Text — sie füllt ein Chat-Template, das Spezial-Tokens wie <|im_start|>user … <|im_end|> um Ihre Worte legt. Diese Umhüllung ist der Grund, warum die von der Engine gemeldete Token-Zahl immer etwas höher ist als der Text Ihrer Nachricht allein — und warum gemischte Templates verschiedener Familien Modelle verwirren.

Schätzregeln: Englische Zeichen ÷ 4. Koreanische Zeichen ÷ 1,0–1,5 — gehen Sie vom Schlimmsten aus. Der Simulator nutzt die Näherung ~4 Zeichen pro Token und ist auf Englisch kalibriert; rechnen Sie für Koreanisch mental hoch.

Tokens selbst zählen

pip install tiktoken
python -c "import tiktoken as t; e = t.get_encoding('o200k_base'); print(len(e.encode('hello world')))"

• tiktoken (https://github.com/openai/tiktoken) deckt die Encodings der OpenAI-Familie ab; andere Familien weichen ab, landen für Englisch aber grob innerhalb von ±15%.
• Hugging-Face-Modellseiten haben einen Tokenizer-Viewer; Tokenizer-Playgrounds lassen Sie Text einfügen und die Splits live mitverfolgen.
• Lokale Engines drucken Prompt-Token-Zahlen in ihre Logs — einmal gegen Ihre echten Prompts prüfen, dann per Verhältnis schätzen.

Verwandt: Innenleben des Transformers · Prefill vs. Decode · KV-Cache