Token

Ein Token ist die kleinste Verarbeitungseinheit eines Large Language Models (LLM, also eines KI-Sprachmodells wie ChatGPT oder Claude): ein Textstück in Form einer Zahl, das ein sogenannter Tokenizer (das Zerlegungs-Programm vor dem Modell) aus Text, Bildern oder Audio erzeugt. In dieser Zahlenform läuft die Eingabe durch das Modell. Ein Token entspricht bei englischem Fließtext im Schnitt rund vier Zeichen oder drei Vierteln eines Wortes, bei deutschem Text spürbar weniger. Diese Zähl-Einheit bildet gleichzeitig die Grundlage für [Context-Window](/insights/glossar/context-window/) (die maximale Textmenge pro Aufruf), Preisberechnung und Rate Limits (Nutzungs-Obergrenzen).

Was ist ein Token?

Ein Sprachmodell verarbeitet keinen Rohtext, sondern eine Abfolge ganzer Zahlen. Der Tokenizer (das Zerlegungs-Programm) bildet Text auf ein festes Vokabular ab, also eine feste Liste erlaubter Textbausteine, typischerweise 32.000 bis 256.000 Einträge. Jeder Eintrag in dieser Liste ist ein Token, jedes Token trägt eine eindeutige Nummer (die Token-ID). Häufige Wörter werden zu einem einzelnen Token, seltene Wörter und lange Komposita in mehrere Teil-Tokens (Sub-Word-Units, also Wortbausteine unterhalb der Wortebene) zerlegt. Das Modell lernt seine Repräsentationen (die interne Bedeutungs-Ablage) ausschließlich auf dieser Token-Ebene; alle Aussagen zu Kontext-Kapazität, Kosten und Latenz eines LLM beziehen sich auf Tokens, nicht auf Zeichen oder Wörter.

Drei Tokenizer-Verfahren dominieren die Praxis. Byte-Pair Encoding ([BPE](https://arxiv.org/abs/1508.07909), Sennrich et al. 2016) ist das Fundament der GPT-Familie und der DeepSeek-Modelle; das Verfahren startet auf Byte-Ebene und fügt iterativ die häufigsten Paare zu neuen Tokens zusammen. WordPiece (Google, [Wu et al. 2016](https://arxiv.org/abs/1609.08144)) liegt BERT zugrunde und arbeitet ähnlich, aber mit einer wahrscheinlichkeitsbasierten Auswahl der Merge-Kandidaten. SentencePiece ([Kudo & Richardson 2018](https://arxiv.org/abs/1808.06226)) ist die Basis von Llama, Mistral und Gemini; das Verfahren behandelt Whitespace als reguläres Symbol und produziert dadurch sprachagnostische Sub-Word-Vokabulare. Alle drei erzeugen Tokens, die kleiner als ein Wort und größer als ein Byte sind.

Für die Umrechnung von Text in Tokens gilt bei englischem Fließtext die von OpenAI dokumentierte Faustregel: rund 4 Zeichen ≈ 1 Token, rund 100 Tokens ≈ 75 Wörter. Deutsche Texte sind bei denselben Zeichen tokenreicher, weil Umlaute (ä, ö, ü, ß) in Byte-Level-BPE-Tokenizern zwei Bytes belegen und weil Komposita wie „Datenbankarchitektur" oder „Verantwortungsverteilung" in mehrere Sub-Word-Tokens zerfallen. Der Faktor liegt je nach Tokenizer bei rund 1,3 bis 1,5. Ein 128k-Token-Fenster fasst damit ungefähr 90.000 bis 100.000 deutsche Wörter, ein 1M-Token-Fenster ungefähr 700.000 bis 800.000. Für multimodale Modelle rechnen die Anbieter Bild-Kacheln und Audio-Frames in Token-Äquivalente um: Gemini setzt 258 Tokens pro Bild-Kachel, Claude zählt pro Bild rund 1.500 bis 2.000 Tokens je nach Auflösung.

Der Begriff existiert, weil das Token die ökonomische Kern-Einheit eines LLM-Systems ist. Anbieter listen für jedes Modell zwei getrennte Preise pro eine Million Tokens: Input-Tokens für alles, was in das Modell hineinläuft (System-Prompt, Historie, Tool-Definitionen, abgerufene Dokumente), und Output-Tokens für die generierte Antwort. Der Faktor zwischen beiden liegt bei aktuellen Modellen zwischen 3 und 5 (Claude Sonnet 4.5: 3 USD Input / 15 USD Output, GPT-4o: 2,50 USD / 10 USD, Gemini 2.5 Pro: 1,25 USD / 10 USD pro 1M Tokens). [Prompt-Caching](/insights/glossar/prompt-caching/) und Batch-Inference sind Rabatt-Hebel auf diese Basis. Rate Limits werden ebenfalls in Tokens abgerechnet (Tokens per Minute, TPM); wer die Ökonomie eines LLM-Systems verstehen will, rechnet in Tokens.

Abgrenzung zu Tokenization, Wort, Byte und Embedding

Vier Begriffe werden mit Token vermischt. Die relevanten Trennlinien:

Die häufigste Verwechslung ist Token vs. Tokenization. Beide Begriffe erscheinen in Anbieter-Dokumenten oft synonym. Präzise ist die Trennung entlang der Verantwortung: Tokens werden gezählt (Kosten, Kontext, Rate Limits), Tokenization wird ausgeführt (Preprocessing-Schritt vor dem Modell-Call). Ein Kostenmodell rechnet nie in „Tokenizations", immer in Tokens.

Die zweite Vermischung betrifft Token vs. Wort. Ein deutsches Wort wie „Verantwortungsverteilung" hat 24 Zeichen, ein Wort, aber je nach Tokenizer 5 bis 7 Tokens. Wer die Kosten einer deutschen LLM-Anwendung mit einer Wortzahl schätzt, unterschätzt sie systematisch. Verlässlich ist nur der modell-spezifische Tokenizer (tiktoken für GPT, AutoTokenizer für Llama-Familien, SentencePiece für Gemini). Der Anthropic-count_tokens-Endpoint liefert dieselbe Zahl für Claude-Modelle.

Die dritte Trennlinie verläuft zwischen Token und Byte. Ein Byte-Level-BPE-Tokenizer wie tiktoken verarbeitet den UTF-8-Bytestream, aber jedes ausgegebene Token besteht aus einem oder mehreren zusammengefassten Bytes. Ein deutsches „ä" ist in UTF-8 zwei Bytes, in vielen Tokenizer-Vokabularen aber ein einzelnes Sub-Word-Token als Bestandteil eines häufigen Wortes. Der Byte ist die technische Basis, das Token die semantische Verarbeitungseinheit.

Die vierte Vermischung ist Token vs. [Embedding](/insights/glossar/embeddings/). Beide werden „aus dem Text abgeleitet", aber sie liegen auf unterschiedlichen Modell-Ebenen. Das Token ist eine ganzzahlige ID im Vokabular des Modells (eine einzelne diskrete Zahl). Das Embedding ist der reelle Vektor, den das Modell nach dem Lookup in seiner Embedding-Matrix für dieses Token bildet und der anschließend durch die Transformer-Schichten läuft. Anbieter-APIs für Embedding-Modelle geben einen einzelnen aggregierten Vektor pro Text-Input zurück; die Token-Sequenz bleibt darin implizit.

Beispiel: Token-Zählung und Kostenrechnung

Eine deutsche Support-Anfrage lautet: „Wie kann ich die Datenbankarchitektur mit einem Lakehouse migrieren?" Der GPT-4o-Tokenizer (tiktoken cl100k_base) zerlegt diesen Satz in rund 18 Tokens: „Wie" (1), „ kann" (1), „ ich" (1), „ die" (1), das Kompositum „ Datenbankarchitektur" in 4 Sub-Word-Tokens, „ mit" (1), „ einem" (1), „ Lakehouse" in 2 Tokens, „ migrieren" in 2 Tokens (im deutschen Trainings-Korpus seltener als das englische „migrate"), plus Whitespace-Marker und „?". Derselbe Satz auf Englisch, „How can I migrate database architecture with a Lakehouse?", ergibt rund 12 Tokens. Der Faktor 1,5 zwischen deutscher und englischer Tokenzahl ist typisch und wirkt sich direkt auf Kontext-Auslastung und Kosten aus.

Wird ein Support-Bot auf dieser Basis mit Claude Sonnet 4.5 betrieben, sieht die Rechnung pro Aufruf so aus. Der System-Prompt belegt 4.000 Tokens (Tonalität, Compliance-Regeln, Ablauf-Steuerung), die Historie der laufenden Sitzung 12.000 Tokens, die Nutzerfrage 800 Tokens, aus einem [RAG-Index](/insights/agentic-ai/llmops/prompt-caching/) werden 20 Chunks à 500 Tokens gezogen (10.000 Tokens). Die Antwort umfasst 1.500 Output-Tokens. Bei einem Preis von 3 USD pro 1M Input-Tokens und 15 USD pro 1M Output-Tokens ergibt das rund 0,08 USD Input (26.800 × 3 / 1M) plus 0,023 USD Output (1.500 × 15 / 1M), also etwa 0,10 USD pro Aufruf. Bei 10.000 Anfragen pro Tag ergibt das ~1.000 USD Tagesbudget oder rund 30.000 USD pro Monat, ohne Prompt-Caching-Rabatt.

Die Optimierungs-Hebel sitzen alle auf der Token-Ebene. Prompt-Caching senkt Input-Kosten für den stabilen Präfix (System-Prompt, Tool-Definitionen) um bis zu 90 Prozent, Batch-Inference um typischerweise 50 Prozent für latenzunkritische Workloads. KV-Caching senkt die Latenz innerhalb eines einzelnen Aufrufs. Ein Modell-Wechsel von Claude Sonnet auf Claude Haiku oder Gemini 2.5 Flash verändert dieselbe Rechnung um den Faktor 3 bis 10. Die Zähl-Einheit Token verbindet damit Modell-Architektur (Vokabular, Tokenizer), Kontext-Kapazität (Window in Tokens) und Betriebs-Ökonomie (Kosten pro 1M) in einem einzigen Begriff.