Wie LLMs Text sehen: Was mein i18n-System mich über Token-Ökonomie gelehrt hat

Als ich das i18n-Übersetzungssystem für meine Website entwickelte, stellte ich fest, dass die Übersetzung eines 1.500 Wörter langen englischen Blogbeitrags ins Koreanische 2,8-mal mehr Tokens verbrauchte als der englische Quelltext. Derselbe semantische Inhalt, dieselbe Bedeutung, aber 2,8-mal so hohe API-Kosten. Japanisch lag bei 2,4x. Traditionelles Chinesisch bei 2,1x. Spanisch bei 1,15x. Die Token-Ökonomie mehrsprachiger Inhalte überraschte mich völlig, weil ich nicht verstanden hatte, wie Tokenizer funktionieren.¹

TL;DR

Tokenisierung wandelt menschenlesbaren Text in numerische Tokens um, die Sprachmodelle verarbeiten. Nach der Übersetzung von 27 Blogbeiträgen in 6 Sprachen verfüge ich über reale Kostendaten: Nicht-lateinische Schriftsysteme verbrauchen 2-3-mal mehr Tokens pro semantischer Einheit als Englisch. Der interaktive Visualizer unten ermöglicht es Ihnen, Text in beliebiger Sprache einzufügen und die Token-Aufschlüsselung zu betrachten. Das Verständnis der Tokenisierung half mir, meine Übersetzungspipeline genau zu budgetieren, meine Prompts zu optimieren und die Kosten um 35 % zu senken, sowie einen Formatierungsfehler zu beheben, bei dem koreanische Übersetzungen die Markdown-Struktur verloren, weil der Tokenizer Fußnotenmarkierungen über Token-Grenzen hinweg aufteilte.

Meine i18n-Token-Kostendaten

Ich habe 27 Blogbeiträge mit Claude in 6 Sprachen übersetzt. Die Übersetzungsqualität erforderte Opus-Level-Modelle (niemals günstigere Modelle — eine Lektion, die ich lernte, als Haiku Übersetzungen produzierte, die sich wie maschinelle Ausgabe lasen). Der Token-Verbrauch pro Sprache überraschte mich:

Die Sprachen mit lateinischer Schrift (Spanisch, Deutsch, Französisch) blieben innerhalb von 20 % des englischen Werts. Die CJK- und Hangul-Sprachen stiegen um das 2-3-Fache. Der Kostenunterschied potenziert sich über 27 Beiträge × 6 Sprachen = 162 Übersetzungen.²

Warum die Lücke existiert

Die meisten Tokenizer (BPE, verwendet sowohl von Claude als auch von GPT-4) werden überwiegend mit englischem Text trainiert. Englische Wörter haben optimierte Token-Repräsentationen, weil die Trainingsdaten mehr Englisch als jede andere Sprache enthalten. Häufige englische Wörter („the”, „and”, „is”) werden auf einzelne Tokens abgebildet. Koreanische Silbenblöcke, japanische Kanji und chinesische Schriftzeichen werden oft in 2-3 Byte-Level-Tokens aufgeteilt, weil der Tokenizer ihnen während des Trainings seltener begegnete.³

Der Effekt ist systematisch, nicht zufällig. Jede koreanische Übersetzung kostet ungefähr das 2,8-Fache des englischen Äquivalents. Ich kann genau budgetieren, weil der Multiplikator konsistent ist.

Der Tokenisierungsfehler

Bei meinem ersten Stapel koreanischer Übersetzungen ging in den übersetzten Beiträgen die gesamte Markdown-Formatierung verloren: Fußnotenverweise ([^1]) verschwanden, Codeblöcke verloren ihre Sprach-Tags und Überschriftenmarkierungen (##) verschmolzen mit dem Fließtext.

Die Diagnose dauerte eine Stunde. Die Ursache: Mein Übersetzungsprompt lautete „Übersetze diesen Blogbeitrag ins Koreanische”, ohne die Beibehaltung der Formatierung zu spezifizieren. Der Tokenizer teilte die Markdown-Syntax im koreanischen Kontext anders über Token-Grenzen auf als im englischen. Das Modell behandelte [^1] als übersetzbaren Inhalt anstatt als strukturelle Auszeichnung.

Die Lösung: Ich fügte meinem Übersetzungsprompt explizite Einschränkungen hinzu:

Preserve all markdown formatting exactly:
- Keep [^N] footnote references unchanged
- Keep ``` code fences with language tags unchanged
- Keep ## heading markers unchanged
- Keep **bold** and *italic* markers unchanged

Jede Einschränkung eliminierte einen Fehlermodus. Die Liste der Einschränkungen wurde länger als die eigentliche Übersetzungsanweisung — ein Muster, das ich in meinem OODA-Prompt-Engineering-Framework beschreibe.⁴

Was Tokens sind

Von Zeichen zu Tokens

Ein naiver Ansatz zur Textverarbeitung würde jedes Zeichen als Eingabeeinheit behandeln. „Hello world” wird zu 11 Zeichen. Zeichenbasierte Verarbeitung erfasst jedes Detail, erzeugt aber extrem lange Sequenzen: Ein Dokument mit 1.000 Wörtern wird zu ungefähr 5.000 Zeichen.⁵

Wortbasierte Verarbeitung reduziert die Sequenzlänge, scheitert aber an unbekannten Wörtern. Ein wortbasiertes Vokabular mit 50.000 Einträgen kann „Unfathomability” nicht verarbeiten, es sei denn, genau dieses Wort kam im Training vor.

Subwort-Tokenisierung findet einen Mittelweg. Häufige Wörter („the”, „and”) bleiben einzelne Tokens. Seltene Wörter werden in Subwort-Teile zerlegt. „Unfathomability” wird in [„un”, „fath”, „om”, „ability”] aufgeteilt, wobei jedes Teil häufig genug vorkommt, um eine trainierte Repräsentation zu haben.

Byte-Pair Encoding (BPE)

BPE, verwendet von Claude und GPT-4, beginnt mit einzelnen Bytes und führt iterativ die häufigsten benachbarten Paare zusammen:⁶

1. Beginn mit einzelnen Zeichen: [l, o, w, e, r]
2. Häufigstes Paar: (l, o) → Zusammenführung zu [lo, w, e, r]
3. Häufigstes Paar: (e, r) → Zusammenführung zu [lo, w, er]
4. Häufigstes Paar: (lo, w) → Zusammenführung zu [low, er]
5. Häufigstes Paar: (low, er) → Zusammenführung zu [lower]

Das endgültige Vokabular enthält alle ursprünglichen Bytes plus alle zusammengeführten Tokens, typischerweise 50.000-100.000 Einträge. Englische Wörter dominieren die zusammengeführten Tokens, weil Englisch die Trainingsdaten dominiert.

Wie ich meine Prompts optimiert habe

Nach der Entdeckung der Token-Kostenlücke optimierte ich meine Übersetzungspipeline und reduzierte die Kosten um 35 %:

Optimierung 1: Bündelung nach Sprachfamilie

Sprachen mit lateinischer Schrift (Spanisch, Französisch, Deutsch) weisen strukturelle Ähnlichkeiten auf. Ich bündle den Übersetzungsprompt, um alle drei in einem einzigen API-Aufruf zu erzeugen, wenn der Quellbeitrag kurz genug ist, um mit allen drei Ausgaben ins Kontextfenster zu passen. Der gemeinsame Kontext (die englische Quelle) wird einmal bezahlt statt dreimal.⁷

Optimierung 2: Deduplizierung von Einschränkungen

Mein ursprünglicher Übersetzungsprompt wiederholte die Einschränkungen für jede Sprache. Die optimierte Version definiert Einschränkungen einmal und wendet sie auf alle Ausgaben an:

# Constraints (apply to ALL translations below):
- Preserve markdown structure, footnotes, code blocks
- Keep proper nouns in English
- Adapt idioms, don't transliterate

# Translate the following post into: Spanish, French, German

Der Abschnitt mit den Einschränkungen verbraucht Tokens einmal. Die Alternative (Wiederholung der Einschränkungen pro Sprache) verbraucht 3x.

Optimierung 3: Prägnante Anweisungen

Mein ursprünglicher Prompt verwendete 340 Tokens für Anweisungen. Nach der Optimierung: 180 Tokens. Die 47%ige Reduktion potenziert sich über 162 Übersetzungen.

CJK-Sprachen profitieren weniger von der Prompt-Optimierung, weil die Ausgabe-Tokens (die Übersetzung selbst) die Kosten dominieren. Die Ausgabe ist in Token-Einheiten inhärent länger, unabhängig davon, wie prägnant die Anweisungen formuliert sind.⁸

Praktische Anwendungen

Kostenabschätzung

Eine grobe Faustregel für englischen Text: 1 Token entspricht ungefähr 0,75 Wörtern oder ungefähr 4 Zeichen. Ein Dokument mit 1.000 Wörtern verbraucht ungefähr 1.333 Tokens. Wenden Sie den Sprachmultiplikator aus meiner obigen Tabelle für nicht-englische Inhalte an.⁹

Code-Tokenisierung

Code wird anders tokenisiert als Prosa. Häufige Schlüsselwörter (def, return, if) werden auf einzelne Tokens abgebildet. Variablennamen werden basierend auf Häufigkeit aufgeteilt:

# "def calculate_total(items):" splits approximately as:
# ["def", " calculate", "_total", "(", "items", "):", ]

Konsistente Namenskonventionen reduzieren die Token-Anzahl. Meine Hook-Infrastruktur verwendet die verb-noun.sh-Konvention (git-safety-guardian, recursion-guard, blog-quality-gate). Das konsistente Muster hilft dem Tokenizer, häufige Subwörter effizient vorherzusagen und zusammenzuführen.

Fehlersuche bei unerwartetem Verhalten

Wenn ein Modell unerwartete Ausgaben erzeugt, kann die Tokenisierung den Grund erklären. Mein koreanischer Formatierungsfehler trat auf, weil der Tokenizer [^1] im koreanischen Kontext anders aufteilte als im englischen. Das Verständnis des Aufteilungsmusters führte direkt zur Lösung (explizite Erhaltungseinschränkungen).

Wichtigste Erkenntnisse

Für Entwickler, die LLM-APIs verwenden: - Messen Sie die Token-Kosten pro Sprache, bevor Sie sich zu mehrsprachiger Unterstützung verpflichten; CJK-Sprachen kosten 2-3-mal mehr pro semantischer Einheit als Englisch - Optimieren Sie Prompt-Anweisungen (prägnante Formulierung, deduplizierte Einschränkungen) für 30-50 % Kostenreduktion bei hochvolumigen Übersetzungspipelines - Testen Sie die Tokenisierung fachspezifischer Begriffe und Markdown-Syntax vor dem Produktiveinsatz; unerwartete Aufteilungen verursachen Formatierungsfehler

Für Produktmanager, die KI-Funktionen budgetieren: - Nicht-englische Sprachunterstützung kostet 1,5-3-mal mehr pro API-Aufruf als Englisch; budgetieren Sie mehrsprachige KI-Funktionen mit dem Sprachmultiplikator, nicht mit einer pauschalen Pro-Sprache-Schätzung - Kontextfenster-Limits betreffen CJK-Sprachen überproportional; ein 200K-Token-Fenster fasst 40 % weniger koreanischen Inhalt als englischen Inhalt

Referenzen