Wie viele Tokens hat mein Prompt?

Sprachmodelle lesen weder Zeichen noch Wörter. Sie lesen Tokens: Fragmente, die entstehen, wenn Text anhand eines festen, aus Trainingsdaten gelernten Vokabulars zerlegt wird.

Häufige Wörter sind meist ein einziges Token. Seltene Wörter werden in Teile zerlegt. Leerzeichen hängen typischerweise am Anfang des folgenden Tokens – deshalb kann dasselbe Wort unterschiedlich zählen, je nachdem, ob es am Satzanfang steht.

Mit dem Tokenizer von GPT-4o gemessen ergibt das Wort unbelievable allein stehend drei Tokens: un + bel + ievable. So geschrieben, wie es tatsächlich im Satz vorkommt, also mit vorangestelltem Leerzeichen, ist es ein einziges Token: unbelievable. Hier wirkt die Regel des führenden Leerzeichens – der Eintrag, den das Modell gelernt hat, ist die Form mit Leerzeichen davor, weil das Wort im laufenden Text fast immer so auftritt. the und international verhalten sich genauso: jeweils ein Token, das Leerzeichen inklusive.

Deshalb wirken Token-Zählungen so unberechenbar. Die Einheit ist nicht sprachlich, sondern statistisch. Die Häufigkeit im Trainingskorpus entscheidet, ob etwas ein Token oder vier ist.

Für englischen Fließtext, gemessen mit dem Tokenizer von GPT-4o über Register hinweg – von umgangssprachlichen Texten bis zu technischen Nachschlagewerken:

• 1 Token ≈ 4,3–5,9 Zeichen
• 1 Token ≈ 0,75–0,95 Wörter
• 1.000 Wörter ≈ 1.050–1.350 Tokens
• Eine Standardseite (~500 Wörter) ≈ 530–680 Tokens

Das Register zählt mehr, als die meisten Faustregeln zugeben. Lockere, gesprochensprachliche Texte liegen am unteren Ende dieser Spanne, bei rund 1.060 Tokens pro tausend Wörter, weil sie immer wieder auf einen kleinen Wortschatz häufiger Wörter zurückgreifen, die jeweils in ein einziges Token passen. Dichte Fachprosa – auch die Guides dieser Website – liegt mit etwa 1.310 am oberen Ende, weil Fachbegriffe in Teile zerlegt werden. Der geläufige Einzelwert von 1.300 Tokens pro tausend Wörter markiert also das fachliche Ende der Spanne, nicht die Mitte, und überschätzt gewöhnliche Texte damit um rund ein Fünftel. Für die Planung eines Kontextfensters ist das die sichere Richtung, in die man sich irren kann.

Außerhalb normalen Fließtexts fallen diese Werte schnell auseinander:

Inhaltstyp	Ungefähr
Englischer Fließtext	0,75–0,95 Wörter pro Token, je nach Register
Code	Rund 1,2× so viele Tokens pro Zeichen wie Fließtext, und etwa 1,5× für denselben Sachverhalt in beiden Formen ausgedrückt
JSON mit langen Schlüsseln	Sehr hoch – Satzzeichen und Anführungszeichen sind eigene Tokens
Chinesisch, Japanisch, Koreanisch	Etwa 0,6–0,7 Tokens pro Zeichen – also weniger als ein Token je Zeichen, aber ein Mehrfaches dessen, was Englisch für dieselbe Zeichenzahl braucht
Kyrillisch, Devanagari, Arabisch	Etwa 1,4–1,6× so viel wie Englisch beim selben Text
URLs und Hashes	Extrem hoch – Zufallszeichenfolgen lassen sich schlecht tokenisieren
Wiederholte Leerzeichen	Günstig statt teuer – Byte-Pair-Kodierung fasst lange Folgen zusammen, vierzig aufeinanderfolgende Leerzeichen sind also ein Token

Die mehrsprachige Lücke ist real, aber deutlich kleiner, als es die verbreitete Erzählung nahelegt. Gemessen an den englischen Seiten dieser Website gegenüber ihren professionellen Übersetzungen kostet die japanische Fassung etwa 1,7× so viel wie die englische, die koreanische etwa 1,5×, die chinesische etwa 1,2×, die hindi-sprachige etwa 1,6× und die arabische etwa 1,4×. Unter dem älteren Tokenizer cl100k_base lagen dieselben Paare bei 2,3×, 2,3×, 1,7×, 4,7× und 2,9× – daher stammt die oft wiederholte Angabe „zwei- bis dreimal so viel wie Englisch“. Damals stimmte sie; die neueren Vokabulare haben die Lücke weitgehend geschlossen.

Jede Modellfamilie nutzt ihren eigenen Tokenizer mit eigenem Vokabular – derselbe Text ergibt also unterschiedliche Zählungen.

GPT-Modelle verwenden Varianten der Byte-Pair-Kodierung – cl100k_base bei Modellen der GPT-4-Ära, o200k_base bei neueren. Claude nutzt einen anderen Tokenizer mit anderem Vokabular. Offene Modelle wie Llama und Mistral haben wiederum jeweils eigene.

Am stärksten unterscheiden sich die Vokabulare bei Code und nichtenglischem Text – dort weichen folglich auch die Zählungen am weitesten voneinander ab.

Praktisch heißt das:

• Eine Zählung eines Tokenizers ist für jedes andere Modell eine Schätzung.
• Nur der eigene Tokenizer des Anbieters liefert die exakte Zahl für dessen Abrechnung.
• Plane mit Puffer statt exakt bis ans Limit.

Unser Token-Zähler zeigt eine GPT-4o-Zählung und eine Claude-Schätzung nebeneinander. Die GPT-4o-Zahl ist eine echte Tokenizer-Zählung. Die Claude-Zahl ist es bewusst nicht: Anthropic veröffentlicht keinen Tokenizer, den wir in deinem Browser ausführen könnten, daher handelt es sich um eine zeichenbasierte Schätzung von einem Token je 3,5 Zeichen. Bei englischem Fließtext liegt diese Schätzung 22–50 % über der GPT-4o-Zählung – bei üblichen Texten etwa ein Drittel darüber. Lies den Abstand also als Breite einer Schätzung, nicht als gemessenen Unterschied zwischen den beiden Modellfamilien. Zusammen reichen die beiden Zahlen weiterhin, um zu erkennen, ob ein Prompt bequem innerhalb des Limits liegt oder unangenehm knapp daran; muss die Zahl exakt sein, nimm den Zähler des jeweiligen Anbieters.

Kosten. API-Preise gelten pro Token, Eingabe und Ausgabe werden getrennt abgerechnet, und die Ausgabe ist typischerweise um ein Mehrfaches teurer. Ein doppelt so langer System-Prompt verdoppelt diese Kosten bei jedem einzelnen Aufruf – so etwas fällt im Test nicht auf, wird aber bei Volumen teuer.

Kontextlimits. Das Fenster umfasst alles: System-Prompt, Gesprächsverlauf, abgerufene Dokumente, die aktuelle Nachricht und den reservierten Platz für die Antwort. Lange Chats scheitern nicht, weil eine einzelne Nachricht lang ist, sondern weil sich der Verlauf ansammelt.

Abschneiden. Wenn die Eingabe das Limit überschreitet, fällt etwas weg – oft stillschweigend, und oft der früheste Inhalt. Ein Modell, das deine Anweisungen „vergessen“ hat, hatte sie häufig schlicht herausgeschnitten.

Chunking für Retrieval. Das Aufteilen von Dokumenten für Embeddings erfolgt in Tokens, nicht in Zeichen. Nach Zeichenzahl bemessene Abschnitte werden uneinheitlich, und Abschnitte, die mitten im Satz enden, liefern schlechte Treffer – eine Retrieval-Pipeline braucht also einen Splitter, der Satz- und Absatzstruktur berücksichtigt. Unser Text-Splitter ist dieses Werkzeug nicht: Er schneidet Abschnitte fester Größe von bis zu 2.000 Zeichen und trennt dabei am nächstgelegenen Leerraum, sodass kein Wort in der Mitte zerteilt wird – ein Abschnitt kann dadurch aber mitten im Satz enden. Nutze ihn, um ein langes Dokument durch ein Kontextfenster oder ein Einfügelimit zu bekommen – nicht, um Embedding-Abschnitte für Retrieval zu erzeugen.

Die wirksamsten Maßnahmen, ungefähr in dieser Reihenfolge:

1. Gesprächsverlauf kürzen. In langen Chats überwiegt er alles andere. Fasse alte Runden zusammen, statt sie wortwörtlich erneut zu senden.
2. Redundante Anweisungen streichen. Eine Regel dreifach zu formulieren macht es nicht dreimal wahrscheinlicher, dass sie befolgt wird. Es verdreifacht aber zuverlässig ihre Kosten.
3. Formatierungsartefakte entfernen. Unsichtbare Zeichen, wiederholte Leerzeichen und dekorative Trennlinien werden alle tokenisiert. Einzeln betrachtet sind sie günstiger, als man denkt, denn die Byte-Pair-Kodierung fasst lange Folgen zusammen: Vierzig aufeinanderfolgende Leerzeichen sind ein Token und eine Trennlinie aus vierzig Bindestrichen zwei – gegenüber dreizehn für den Satz darüber. Reiner Ballast bleiben sie trotzdem, und in einem Dokument mit einer Trennlinie zwischen jedem Abschnitt summiert sich das. Unsichtbare Zeichen entfernen beseitigt die, die du nicht sehen kannst.
4. JSON-Schlüssel kürzen in strukturierten Prompts. {"n": ...} statt {"customer_full_name": ...} macht über tausend Datensätze hinweg einen großen Unterschied.
5. Nur relevante Auszüge senden. Drei passende Absätze abzurufen schlägt das Einfügen des ganzen Dokuments – und liefert meist auch bessere, nicht nur günstigere Antworten.

Was nicht hilft: gewöhnliche Satzzeichen entfernen, Artikel streichen oder in abgehacktem Telegrammstil schreiben. Die Einsparung ist marginal, der Schaden für die Ausgabequalität nicht.