Tokens sind das, womit LLMs wirklich rechnen — nicht mit Wörtern, nicht mit Zeichen, sondern mit Subwort-Einheiten, die vom Tokenizer erzeugt werden. Wer LLMs produktiv einsetzt, muss Tokenization und Context Windows verstehen, sonst zahlt er zu viel oder bekommt unerwartete Qualitätseinbrüche. Dieser Beitrag erklärt die Mechanik und liefert praktische Strategien für lange Dokumente.
1. Was ein Token ist
Ein Token ist die kleinste Einheit, mit der ein LLM intern arbeitet. Tokens sind typisch Subworte — Teile von Wörtern, ganze Wörter oder einzelne Zeichen, je nach Häufigkeit. Der Tokenizer entscheidet bei Modelltraining, welche Sequenzen als ein Token zusammengefasst werden.
Beispiel: Das Wort „Modellanpassung” könnte als ein Token (wenn häufig im Training), zwei Tokens (Modell + anpassung) oder mehrere Tokens (Mod + ell + anp + assung) gespeichert werden — je nach Tokenizer.
Faustregeln:
- Englisch: ~4 Zeichen pro Token, ~0,75 Wörter pro Token.
- Deutsch: ~3,5 Zeichen pro Token, ~0,5–0,7 Wörter pro Token (lange zusammengesetzte Wörter werden zerlegt).
- Code: ~5 Zeichen pro Token, je nach Sprache.
- Logogramm-Sprachen (Chinesisch, Japanisch): ~1–2 Zeichen pro Token.
2. Tokenizer im Vergleich
Zwei Hauptfamilien dominieren:
- BPE (Byte Pair Encoding). Iteratives Zusammenfassen häufiger Subworte. OpenAI tiktoken, GPT-Reihe.
- SentencePiece / Unigram. Statistische Auswahl optimaler Subwort-Einheiten. Llama, Mistral.
Praktische Konsequenzen:
- Mehrsprachigkeit. Englisch-trainierte Tokenizer (GPT-2/3, Llama-1) sind für nicht-englische Sprachen oft ineffizient. Moderne Tokenizer (Llama-3, tiktoken-cl100k, Mistral) sind ausbalanciert.
- Vokabulargröße. Größeres Vokabular = effizientere Encoding (weniger Tokens pro Text), aber größere Embedding-Matrix. Typisch 32K–256K Tokens.
- Spezial-Tokens.
<|begin_of_text|>,<|user|>,<|tool|>etc. — kritisch für Chat-Formate und Tool Calling.
Für Unternehmen relevant: Bei Wahl zwischen Modellen lohnt ein Vergleich der Tokenizer-Effizienz auf eigenen Texten. Bei sehr deutschsprachigen Anwendungen kann ein guter Tokenizer 30%+ Kostenersparnis bedeuten.
3. Context Windows 2026
Die nutzbare Eingangslänge ist 2026 dramatisch gewachsen:
- 8K Tokens (2023-Standard). Reicht für eine Seite Text plus Antwort. Für kurze Aufgaben gut.
- 32K (Llama-2-Großmodelle, GPT-4 Standard). Mehrere Seiten Text. Sinnvolle Konversationen, mittellange Dokumente.
- 128K (GPT-4-Turbo, Llama-3.1, Claude 3). Mittellange Bücher, große Code-Dateien. 2026 Standard für die meisten produktiven Modelle.
- 200K–1M (Claude 3.5+, Gemini 2.0+). Volle Codebases, Buchsammlungen, ganze Datenbankexporte. 2026 produktiv verfügbar.
- Forschungsstand 10M+ Tokens. Experimentell. Sehr selten praktisch nötig.
Wichtig: Das nominelle Kontextfenster sagt nichts über die tatsächliche Nutzungsqualität aus. Eval auf realistischen Long-Context-Aufgaben bleibt zwingend.
4. Was lange Kontexte wirklich bringen
Long Context löst echte Probleme, hat aber Schwächen:
Stärken:
- Komplette Codebase-Analysen ohne Chunking.
- Vertragsprüfung über alle Seiten gleichzeitig.
- Buchzusammenfassungen aus dem vollen Inhalt.
- Lange Dialog-Memory ohne separates Retrieval.
Schwächen:
- Lost in the Middle. Informationen in der Mitte des Kontexts werden schlechter genutzt als Anfang und Ende.
- Kosten skalieren. Inferenz-Kosten und Latenz wachsen schnell.
- KV-Cache-Speicher. Bei 1M Tokens braucht der Cache mehrere GB GPU-Speicher pro Anfrage.
- Qualitäts-Drift. Modelle, die nominell 1M Tokens unterstützen, sind bei 100K oft schon nicht mehr optimal.
Praxis: Long Context wo es passt, ergänzt um RAG für sehr große Wissensbestände.
5. Token-Kosten und Latenz
Tokens kosten Geld auf zwei Ebenen:
- API-Preise typisch 0,001–0,1 USD pro 1.000 Output-Tokens. Eingabe meist günstiger, manchmal halber Preis.
- Eigenbetrieb-Kosten. Hardware-Auslastung, Stromkosten. Bei sehr hohem Volumen 5–10× günstiger als API.
Latenz wächst linear mit Output-Tokens (Decode-Phase) und ungefähr linear mit Input-Tokens (Prefill-Phase, parallelisierbar). Lange Inputs erhöhen Prefill-Zeit; lange Outputs erhöhen Decode-Zeit. Streaming der Antwort kann gefühlte Latenz reduzieren. Mehr in LLM Inference.
6. Strategien für lange Dokumente
Wenn Dokumente das Context Window sprengen:
- Chunking. Dokument in semantisch sinnvolle Stücke teilen, einzeln verarbeiten. Siehe Embeddings und Vector Databases.
- Map-Reduce. Jedes Chunk separat zusammenfassen, dann zusammenführen. Skaliert auf beliebige Größen, kann aber Details verlieren.
- Hierarchical Summarization. Multi-Level: Abschnitte zusammenfassen, dann diese Zusammenfassungen wieder zusammenfassen, etc.
- Retrieval-Memory. Relevante Teile per Embedding-Suche selektieren und nur diese in den Kontext laden.
- Sliding Window. Bei langen Konversationen: alte Inhalte zusammenfassen, jüngere im Detail behalten.
Die richtige Strategie hängt vom Use Case ab. Für „Frage zu einem 1.000-Seiten-Dokument” ist RAG meist besser als Long Context. Für „Refactoring einer Codebase” ist Long Context oft sinnvoll.
7. Praxis: Kontext-Architektur planen
Aus Beratungspraxis vier Schritte:
- Token-Budget pro Anfrage definieren. Wie viele Tokens darf eine Antwort maximal kosten?
- Tokenizer auf eigene Texte testen. Echte Anwendung simulieren, Token-Zahl messen. Bei Bedarf andere Modelle vergleichen.
- Kontext-Strategie wählen. RAG, Long Context, Hybrid — passend zur Datenstruktur.
- Eval auf Edge Cases. Lost-in-the-Middle-Tests, sehr lange und sehr kurze Eingaben, mehrsprachige Mischungen.
Tokenization und Context Windows sind keine reinen Backend-Details, sondern direkte Architekturentscheidungen mit Auswirkung auf Kosten, Latenz und Qualität. 2026 ist die Auswahl an Modellen und Strategien groß genug, um für fast jeden Use Case eine passende Kombination zu finden — vorausgesetzt, man kennt die Trade-offs. Wer die Mechanik versteht, baut Anwendungen, die sich rechnen. Wer sie ignoriert, zahlt unnötig oder bekommt Antworten, die wichtige Teile übersehen.
Häufige Fragen.
/ 01Was ist ein Token?
Ein Token ist die kleinste Einheit, in der ein LLM Text verarbeitet. Tokens sind typisch Subworte — ein Wort wie 'Modellanpassung' kann in mehrere Tokens zerlegt sein, ein häufiges Wort wie 'und' ist ein einzelner Token. Faustregel: ein Token entspricht etwa 0,75 englischen Wörtern oder rund 4 Zeichen. Deutsche Texte erzeugen pro Zeichen tendenziell etwas mehr Tokens.
/ 02Was bedeutet 128K Context Window?
Das Modell kann maximal 128.000 Tokens auf einmal verarbeiten — Eingabe plus generierte Antwort zusammen. 128K Tokens entsprechen etwa 90.000 Wörtern oder einem mittellangen Roman. Längere Eingaben werden abgeschnitten oder erfordern Chunking-Strategien.
/ 03Sind Modelle mit 1M Tokens Context immer besser?
Nein. Lange Context Windows lösen ein Speicherproblem, nicht zwangsläufig ein Verständnisproblem. Modelle zeigen oft 'Lost in the Middle'-Phänomene: Informationen am Anfang und Ende des Kontexts werden besser genutzt als in der Mitte. Eval auf realistischen Long-Context-Aufgaben bleibt zwingend.
/ 04Wie wirken sich verschiedene Tokenizer auf Token-Kosten aus?
Stark. Ein 1.000-Wort-Text in Deutsch kostet bei einem englisch-optimierten Tokenizer (z. B. GPT-2/3) deutlich mehr Tokens als bei einem mehrsprachigen Tokenizer (z. B. tiktoken-cl100k oder Llama-3). Für deutsche Anwendungen können Tokenizer-Unterschiede 30–50% Kostenunterschied bedeuten.
/ 05Wann brauche ich Long Context, wann reicht RAG?
Long Context lohnt, wenn der gesamte Inhalt für die Antwort relevant sein könnte (Codebase-Analyse, lange Verträge, Buchzusammenfassung). RAG ist besser, wenn die Quellen groß sind, aber jeweils nur ein kleiner Teil relevant ist (Wissensbasen, Produktkataloge). Häufig kombiniert man beide: RAG zur Vorauswahl, Long Context für detaillierte Analyse.
/ 06Was sind die Kosten von Long-Context-Inferenz?
Die Kosten skalieren bei modernen Implementierungen linear mit Token-Anzahl (Attention bleibt aber quadratisch für die Compute-Kosten). Eine 100K-Token-Anfrage kostet typisch 50–100× mehr als eine 1K-Anfrage. Außerdem braucht der KV-Cache deutlich mehr GPU-Speicher. Mehr in LLM Inference.