Token, die Bausteine der Sprache

Ein Sprachmodell liest keine Wörter. Es liest Token. Das klingt nach einer Kleinigkeit für Fachleute, erklärt aber eine ganze Reihe von Dingen, über die Anwender sonst stolpern: warum ein deutscher Text mehr kostet als der gleiche englische, warum ein Modell Buchstaben nicht zuverlässig zählen kann, und warum irgendwann mitten in einem langen Gespräch der Anfang verloren geht.

Probieren Sie es aus

Die folgenden Beispiele sind nicht geschätzt. Sie wurden mit dem echten Vokabular zerlegt, das die GPT-4o-Familie verwendet.

Ein paar Dinge fallen sofort auf.

Beim Alltagssatz passt fast jedes Wort in genau ein Token. So sieht der Normalfall aus, und deshalb kommt man mit der groben Faustregel „ein Token ist ungefähr ein Wort“ im Englischen ziemlich weit.

Beim Fachbegriff kippt das. „Künstliche Intelligenz“ braucht sechs Token, „artificial intelligence“ zwei. Beides ist derselbe Begriff, aber das Vokabular kennt die englische Schreibweise als Ganzes und die deutsche nicht.

Beim langen Wort wird es deutlich. Ein deutsches Kompositum zerfällt in Bruchstücke, die für sich genommen nichts bedeuten. Das Modell setzt daraus trotzdem einen Sinn zusammen, es hat nur mehr Arbeit damit.

Warum das im Alltag zählt

Deutsch kann teurer werden. Abgerechnet wird nach Token, nicht nach Wörtern. Wie groß der Aufschlag ausfällt, hängt vom Text ab. In den drei Beispielen oben, die es in beiden Sprachen gibt, reicht die Spanne von gleichauf beim Alltagssatz bis zum Doppelten beim langen Wort. Wer regelmäßig größere Mengen verarbeitet, sollte den eigenen Text einmal messen statt zu schätzen, dafür gibt es die Werkzeuge weiter unten.

Der Platz ist begrenzt. Jedes Modell hat ein Kontextfenster, gemessen in Token. Alles, was zusammen hineinpasst: die Anweisung, die angehängten Dokumente, der bisherige Gesprächsverlauf und die Antwort. Ist es voll, fällt der Anfang heraus.

Zeichen sind unsichtbar. Das Modell sieht das Token „·Katze“, nicht die fünf Buchstaben darin. Fragen nach Buchstabenzahlen, Reimen oder dem dritten Zeichen von hinten treffen deshalb auf eine Wahrnehmung, die diese Ebene gar nicht hat. Die bekannten Fehlschläge bei solchen Aufgaben sind eine Folge der Zerlegung.

Mit eigenem Text nachsehen

Das Modul oben hat feste Beispiele, weil die Zerlegung beim Bauen dieser Seite entstanden ist. Im Browser wird dafür nichts gerechnet. Für eigenen Text gibt es zwei Werkzeuge, die im Browser laufen und nichts kosten:

Tiktokenizer (externe Seite, tiktokenizer.vercel.app) ist das genauere von beiden. Oben links wählt man das Modell, etwa gpt-4o. Man tippt Text ins Feld und sieht sofort die Zerlegung farbig markiert, dazu die Zahl der Token. Der Schalter „Show whitespace“ macht Leerzeichen sichtbar, was den Aha-Moment liefert: das Leerzeichen gehört zum Token. Lohnende Versuche sind der eigene Name, eine E-Mail-Adresse, eine Telefonnummer, ein Codeschnipsel und derselbe Satz einmal auf Deutsch und einmal auf Englisch.

Der Tokenizer von OpenAI (externe Seite, platform.openai.com) ist schlichter und zeigt neben der Zerlegung auch die Nummern, die jedes Token im Vokabular hat. Für den ersten Eindruck reicht er.

Beide zeigen nur die Vokabulare von OpenAI. Andere Anbieter zerlegen anders, die Größenordnung bleibt aber vergleichbar.

Was danach passiert

Mit dem Token ist die Kette noch nicht zu Ende. Jedes bekommt anschließend eine lange Zahlenreihe zugeordnet, und erst mit diesen Zahlen rechnet das Modell. Darum geht es in Kapitel 04.

Zwischen dem Satz, den jemand eintippt, und der Rechnung, die ein Modell anstellt, liegen drei Übersetzungen. Keine davon ist besonders schlau, aber alle drei bestimmen, was danach möglich ist.

seitlich verschiebbar

eigene Darstellung, Token-IDs erhoben am 26.07.2026

Das Vokabular

Ein Modell hat eine feste Liste von Textstücken, die es kennt. Bei o200k_base, dem Vokabular der GPT-4o-Familie, sind das rund 200.000 Einträge. Jeder Eintrag hat eine Nummer. Alles, was hineingegeben wird, muss sich aus diesen Einträgen zusammensetzen lassen.

Damit das immer aufgeht, enthält die Liste auch einzelne Bytes. Ein Text, der nur aus unbekannten Zeichen besteht, wird deshalb Byte für Byte zerlegt statt abgelehnt. Das ist der Grund, warum kein Text ein Modell zum Absturz bringt, und zugleich der Grund, warum manche Texte absurd teuer werden.

Wie das Vokabular entsteht

Zuerst die Frage, warum es überhaupt Bruchstücke sein müssen. Eine Liste ganzer Wörter wäre entweder unbrauchbar groß oder lückenhaft, und im Deutschen scheitert sie an den Komposita: Man kann beliebig viele davon bilden, und was in der Liste fehlt, könnte ein Modell gar nicht erst darstellen. Sennrich, Haddow und Birch haben das 2015 als offenes Vokabularproblem (externe Seite, arxiv.org) beschrieben und einen Ausweg vorgeschlagen, nämlich seltene und unbekannte Wörter in kleinere Einheiten zu zerlegen (externe Seite, arxiv.org). Zusammensetzungen nennen sie ausdrücklich als einen der Fälle (externe Seite, arxiv.org), in denen das aufgeht.

Das Verfahren dafür heißt Byte Pair Encoding, kurz BPE, und stammt ursprünglich aus der Datenkompression.

Der Ablauf ist erstaunlich schlicht:

1. Zu Beginn besteht das Vokabular nur aus einzelnen Bytes.
2. Über eine sehr große Textmenge wird gezählt, welches Paar benachbarter Einheiten am häufigsten vorkommt.
3. Dieses Paar wird zu einem neuen Eintrag verschmolzen.
4. Zurück zu Schritt 2, bis die gewünschte Größe erreicht ist.

Häufige Wörter landen dadurch als Ganzes im Vokabular, seltene bleiben in Bruchstücken. Maßgeblich ist allein die Häufigkeit in den Trainingsdaten, Grammatik und Bedeutung spielen dabei keine Rolle. Wer diese Daten dominiert, bekommt die kompakteren Token.

Die dritte Übersetzung

Mit der Nummer ist die Kette noch nicht zu Ende. Eine Nummer ist eine Adresse im Vokabular, und aus zwei Adressen folgt nichts über die beiden Wörter dahinter. Das Modell schlägt deshalb zu jeder Nummer eine lange Zahlenreihe nach, und erst mit diesen Reihen rechnet es. Das ist die letzte Stufe in der Grafik oben und der Gegenstand von Kapitel 04.

Was die Zerlegung im Betrieb bedeutet

Kosten. Abgerechnet wird nach Ein- und Ausgabe-Token, meist getrennt und zu unterschiedlichen Preisen. Eine Kostenschätzung, die in Wörtern rechnet, geht bei deutschen Fachtexten regelmäßig daneben. Ein mitgeschicktes Bild zählt ebenfalls in Token, dort allerdings nach Fläche statt nach Textmenge (Kapitel 13).

Kontextfenster. Die Obergrenze gilt für alles zusammen: Systemanweisung, Tool-Beschreibungen, angehängte Dokumente, bisheriger Verlauf und die entstehende Antwort. Ein Fenster von 200.000 Token bedeutet nicht 200.000 Token Nutztext.

Geschwindigkeit. Ausgegeben wird Token für Token. Eine deutsche Antwort braucht für denselben Inhalt mehr Schritte als eine englische und wirkt deshalb langsamer, auch bei gleichem Modell und gleicher Last.

Zerlegung von Bezeichnern. Kundennummern, Artikelschlüssel und IDs zerfallen in Stücke, die nichts miteinander zu tun haben. Wenn ein Modell eine Auftragsnummer verstümmelt wiedergibt, ist das oft hier begründet statt in mangelnder Sorgfalt.

Zum Nachsehen

Für eigenen Text: Tiktokenizer (externe Seite, tiktokenizer.vercel.app). Modell oben links wählen, Text eintippen, „Show whitespace“ einschalten. Aufschlussreich sind Auftragsnummern, E-Mail-Adressen, JSON und derselbe Absatz in zwei Sprachen. Wer die Nummern der Token sehen will, nimmt den Tokenizer von OpenAI (externe Seite, platform.openai.com).

Was daraus für die Praxis folgt

Wer Dokumente für eine Wissensbasis zerschneidet, sollte in Token messen, nicht in Zeichen. Wer Kosten plant, misst einen echten Beispieltext statt zu extrapolieren. Und wer ein Modell nach Buchstaben, Silben oder Reimen fragt, sollte wissen, dass es die Ebene, auf der die Antwort läge, gar nicht sieht. Diesem letzten Punkt geht die dritte Tiefe nach.

Die Zerlegung ist die einzige Stelle in der ganzen Kette, an der ein Modell etwas verliert, das sich später nicht mehr rekonstruieren lässt. Alles danach ist gelernt und damit im Prinzip verbesserbar. Was das Vokabular nicht abbildet, kommt nie an.

Die Zerlegung ist nicht sprachlich motiviert

BPE optimiert Häufigkeit, nicht Bedeutung. Das führt zu Grenzen, die quer zu allem liegen, was ein Linguist ziehen würde. Wie ein Linguist zerlegt hat und wie Text davor zu Zahlen wurde, steht in KI-Wissen, Kapitel 06. Im Beispiel oben zerfällt „Künstliche“ in K, ünst, liche. Der erste Buchstabe steht allein, weil das Vokabular die Wortform mit großem K seltener gesehen hat als die kleine.

Daraus folgt eine Eigenheit, die im Betrieb regelmäßig auffällt: Groß- und Kleinschreibung sowie ein führendes Leerzeichen erzeugen verschiedene Token. Katze, katze, ·Katze und ·katze sind vier verschiedene Einträge mit vier verschiedenen Nummern. Das Modell hat gelernt, dass sie zusammengehören, aber nicht, weil es die Buchstaben vergleicht.

Zahlen und Code

Sehen Sie sich im Modul die beiden letzten Beispiele an.

Beim Datum 24.07.2026 zerfällt die Jahreszahl in 202 und 6. Der Grund liegt in der Häufigkeit: 202 kam als Zeichenkette öfter vor als 2026. Bei 1.299,90 trennt das Vokabular an Punkt und Komma und zerlegt die Ziffernblöcke nach eigener Logik.

Damit ist erklärt, warum Sprachmodelle beim Rechnen so eigentümlich scheitern: Sie sehen keine Stellenwerte. Zwei Zahlen, die sich nur in der letzten Ziffer unterscheiden, können völlig unterschiedlich zerlegt sein. Die Zuverlässigkeit bei Arithmetik steigt deshalb sprunghaft, sobald das Modell die Rechnung an ein Tool abgibt statt sie selbst zu erzeugen. Darin liegt der eigentliche Grund für den Tool Call, und wie er abläuft, steht in Kapitel 09.

Bei Programmcode ist die Lage besser, weil Code in den Trainingsdaten stark vertreten war. Trotzdem zerfällt werte in wer und te, während .reduce als ein Token durchgeht. Einrückung ist ebenfalls Token: Vier Leerzeichen am Zeilenanfang kosten in manchen Vokabularen ein eigenes Token je Ebene. Bei großen Dateien summiert sich das.

Verschiedene Vokabulare, verschiedene Zahlen

Es gibt kein allgemeingültiges Token. Wechselt man das Modell, ändert sich die Zerlegung und damit jede Zahl, die daran hängt.

Vokabular	Typische Verwendung	Einträge
cl100k_base	GPT-3.5, GPT-4	rund 100.000
o200k_base	GPT-4o und Nachfolger	rund 200.000

Andere Anbieter nutzen eigene Vokabulare mit eigenen Größen. Größer heißt tendenziell sparsamer bei nicht-englischem Text, kostet dafür mehr Speicher in der Embedding-Schicht, siehe Kapitel 04.

Praktische Folge: Eine Kostenrechnung, ein Grenzwert für die Länge eines Textabschnitts oder ein Prüfwert im Testlauf gelten immer nur für ein bestimmtes Vokabular. Beim Modellwechsel gehören sie neu gemessen. Wer solche Werte hartkodiert, baut sich eine Zeitbombe ein.

Konsequenzen für den Bau von Systemen

Chunking. Beim Zerschneiden von Dokumenten für eine Wissensbasis wird die Länge in Token gemessen, nicht in Zeichen. Eine Grenze in Zeichen führt bei deutschen Fachtexten zu Abschnitten, die das Fenster des Embedding-Modells überschreiten, während sie bei englischen Texten Platz verschenkt.

Kostenschätzung. An einem repräsentativen Ausschnitt messen statt hochzurechnen. Der Unterschied zwischen Schätzung und Messung liegt bei deutschen Fachtexten regelmäßig im zweistelligen Prozentbereich.

Ausgabegrenzen. Ein Limit für die Antwortlänge in Token trifft deutsche Antworten härter als englische. Wer dieselbe Grenze für beide Sprachen setzt, schneidet deutsche Antworten früher ab.

Formatvorgaben. JSON-Antworten kosten Token für Klammern, Anführungszeichen und Feldnamen. Bei vielen kleinen Aufrufen ist der Anteil dieses Gerüsts an den Gesamtkosten nicht klein. Kurze Feldnamen wirken kleinlich und sparen hier messbar.

Cache. Verfahren, die Teile der Eingabe zwischenspeichern, gleichen in der Regel Token-Folgen ab, nicht Zeichenketten. Eine Systemanweisung, die sich am Anfang um ein einziges Zeichen ändert, kann die gesamte Wiederverwendung entwerten. Der stabile Teil gehört deshalb nach vorn, der wechselnde nach hinten.

Was man daraus nicht schließen sollte

Die Zerlegung erklärt eine Reihe von Fehlern, aber nicht alle. Wer jedes schwache Ergebnis auf den Tokenizer schiebt, hört auf, nach der eigentlichen Ursache zu suchen. Ein Modell, das eine Frage inhaltlich falsch beantwortet, scheitert fast nie an der Zerlegung. Ein Modell, das eine Zeichenkette verstümmelt, eine Zahl verrechnet oder Buchstaben zählt, oft schon.

Der Prüfschritt ist einfach: Lässt sich der Fehler reproduzieren, wenn man dieselbe Frage in einer anderen Formulierung oder auf Englisch stellt? Bleibt er bestehen, liegt es nicht am Tokenizer.