Token
Die Wortstücke, in denen ein Sprachmodell liest, schreibt und abrechnet – und warum es für das Modell eigentlich nur Zahlen sind.
Ein Token ist ein häufiges Stück Text – mal ein ganzes Wort, mal eine Silbe, mal ein Satzzeichen. Ein Tokenizer zerlegt jeden Text in solche Stücke und ersetzt jedes durch eine feste Nummer. Nur diese Nummern sieht das Modell.
Tokens sind die Maßeinheit für alles Praktische: Kosten, Länge des Kontextfensters, Geschwindigkeit. Faustregel: Ein deutsches Wort sind grob ein bis zwei Tokens.
Warum Wortstücke – und nicht Buchstaben oder Wörter?
Ein Modell braucht einen festen Satz an Bausteinen, aus denen sich jeder Text zusammensetzen lässt. Dafür gibt es drei naheliegende Kandidaten, und zwei davon taugen nicht:
Buchstaben
- winziges Vokabular
- extrem lange Folgen – 11 Schritte für ein Wort
- jeder Schritt trägt kaum Bedeutung
Ganze Wörter
- kurze Folgen
- Millionen Wörter, im Deutschen unendlich viele Komposita
- unbekannte Wörter gehen gar nicht
Wortstücke (Tokens)
- überschaubares Vokabular
- kurze Folgen
- auch neue Wörter lassen sich zusammensetzen
Typische Vokabulare haben einige Zehntausend bis über hunderttausend Einträge. Häufiges wie „der“, „und“ oder „␣Haus“ ist ein einzelnes Token; Seltenes wie „Donaudampfschifffahrt“ wird aus mehreren Stücken gebaut. Weil moderne Tokenizer notfalls bis auf einzelne Bytes herunterbrechen können, gibt es kein Wort, das sich nicht darstellen ließe – auch keinen Tippfehler und kein Emoji.
Wie das Vokabular entsteht
Niemand legt die Tokens von Hand fest. Das gängigste Verfahren heißt Byte-Pair-Encoding (BPE) und ist erstaunlich simpel:
- Starte mit einzelnen Zeichen.
- Zähle, welches benachbarte Paar im Trainingstext am häufigsten vorkommt.
- Verschmelze dieses Paar überall zu einem neuen Token.
- Wiederhole, bis das Vokabular die gewünschte Größe hat.
Probier es an einem Mini-Text aus fünf Wörtern aus. Die Zahl links gibt an, wie oft das Wort im „Trainingstext“ vorkommt:
Achte auf die ersten beiden Schritte: Aus „a“, „c“ und „h“ wird zuerst ach – ein Stück, das in allen fünf Wörtern steckt. Genau so entstehen in echten Tokenizern Bausteine wie ung, lich, ␣der oder public. Echte Tokenizer machen das auf riesigen Textmengen und lernen zehntausende Verschmelzungen.
enum-Version funktioniert.Vom Text zur Zahl – und zurück
Für das Modell existieren weder Buchstaben noch Wörter. Es bekommt eine Liste von Ganzzahlen und gibt am Ende wieder eine Ganzzahl aus.
Im Modell wird jede ID sofort in einen langen Zahlenvektor übersetzt, ein sogenanntes Embedding – damit beginnt die eigentliche Rechnerei. Die ID selbst ist nur ein Index, so wie ein Array-Index nichts über den Inhalt verrät: Dass „Hund“ die Nummer 4711 hat und „Katze“ die 4712, hieße nicht, dass sie verwandt sind.
Was daraus folgt
Kosten, Grenzen, Tempo
Abrechnung
APIs rechnen pro Token ab, Eingabe und Ausgabe meist getrennt – Ausgabe-Tokens sind in der Regel teurer.
Kontextgrenze
Das Kontextfenster ist in Tokens bemessen, nicht in Zeichen oder Seiten.
Tempo
Die Antwort entsteht Token für Token. Deshalb „tippt“ der Chat Stück für Stück.
Faustregeln für die Länge
| Text | Grobe Faustregel |
|---|---|
| Englisch | etwa 4 Zeichen pro Token, etwa ¾ Wort pro Token |
| Deutsch | spürbar mehr Tokens pro Wort, grob 1–2 – lange Komposita und weniger deutscher Trainingstext |
| Programmcode | Bezeichner werden oft zerlegt; Einrückung und Leerzeichen kosten mit |
| Seltene Schriften, Emojis | oft mehrere Tokens pro Zeichen |
Die genauen Werte hängen vom Tokenizer ab. Wer es exakt braucht: Die meisten Anbieter haben Zähl-Funktionen in ihren APIs oder Bibliotheken.
Typische Schwächen
Weil das Modell nie Buchstaben sieht, sind manche für Menschen triviale Aufgaben für es überraschend schwer:
- Buchstaben zählen, rückwärts schreiben, Anagramme – das Modell sieht die Buchstaben nicht direkt.
- Rechnen mit langen Zahlen – „1234567“ wird in beliebige Stücke wie
123·456·7zerlegt, die Stellen liegen nicht sauber untereinander. - Reime und Silben – Klang und Silbengrenzen stimmen oft nicht mit den Token-Grenzen überein.
Moderne Modelle können das trotzdem oft, weil sie viel darüber gelernt haben oder notfalls ein Werkzeug (z. B. Code) benutzen. Aber hier liegt der Grund, wenn es mal danebengeht.
Für Entwickler übersetzt
| Begriff | Entspricht ungefähr |
|---|---|
| Tokenizer | ein Lexer – nur dass die Token-Grenzen nicht aus einer Grammatik stammen, sondern statistisch gelernt wurden |
| Vokabular | eine feste Map<String, Integer> bzw. ein riesiges enum mit z. B. 100 000 Konstanten |
| Token-ID | der ordinal()-Wert dieser Konstante – ein bedeutungsloser Index |
| encode / decode | Serialisieren und Deserialisieren zwischen String und int[] |
// Pseudocode – echte Bibliotheken sehen ähnlich aus
Tokenizer tok = Tokenizer.fuerModell("mein-modell");
int[] ids = tok.encode("Hallo Welt!"); // z. B. [17093, 44921, 0]
int anzahl = ids.length; // danach wird abgerechnet
String text = tok.decode(ids); // "Hallo Welt!" – verlustfrei zurückDer Vergleich mit dem Lexer ist ziemlich genau – das Wort „Token“ stammt sogar aus derselben Tradition. Der Unterschied: Der Java-Lexer liefert IDENTIFIER, LPAREN und Co., also Einheiten mit Bedeutung. Ein LLM-Tokenizer liefert einfach häufige Zeichenfolgen, egal ob sie sprachlich Sinn ergeben.