Wenn Sie mit LLMs arbeiten, werden Sie einem Begriff immer wieder begegnen: Token. Token-Limit. Token-Verbrauch. Tokens pro Sekunde. Die gesamte Industrie spricht darüber, als wäre es selbstverständlich, was damit gemeint ist.
Ist es aber nicht.
Denn ein Token ist weder ein Wort noch ein Zeichen. Es ist nicht einfach „ein Stück Text”. Es ist die atomare Einheit, in der ein Sprachmodell arbeitet – und zu verstehen, was das bedeutet, ist entscheidend für alles, was danach kommt.
Intuitiv würden die meisten Menschen vermuten: Ein Token ist ein Wort. Das wäre logisch, denn wir denken in Wörtern. Wir schreiben in Wörtern. Wir kommunizieren in Wörtern.
Aber LLMs denken nicht. Sie arbeiten mit Zahlen.
Ein Token ist eine Texteinheit, die ein Tokenizer aus dem ursprünglichen Text extrahiert. Manchmal ist das ein ganzes Wort. Manchmal ein Wortteil. Manchmal nur ein einzelnes Zeichen. Es gibt sogar Tokens für Leerzeichen und Satzzeichen. Was genau ein Token ist, entscheidet der Tokenizer – und der ist modellspezifisch.
Nehmen wir ein Beispiel. Der Satz „Künstliche Intelligenz ist überschätzt” könnte von einem Tokenizer so zerlegt werden:
["Kün", "stliche", " Intelligenz", " ist", " über", "schätzt"]Von einem anderen so:
["Künst", "liche", " Intel", "ligenz", " ist", " übers", "chätzt"]Und von einem dritten vielleicht so:
["Künstliche", " Intelligenz", " ist", " überschätzt"]Welche Variante die richtige ist? Keine. Oder alle. Es kommt darauf an, welches Modell Sie verwenden.
Jedes große Sprachmodell bringt seinen eigenen Tokenizer mit. GPT-4 verwendet einen anderen als Claude. Mistral hat seinen eigenen. Llama ebenfalls. Sie können nicht einfach einen Text tokenisieren und davon ausgehen, dass jedes Modell ihn gleich verarbeitet. Das wäre, als würden Sie erwarten, dass alle Programmiersprachen Variablen gleich behandeln.
Der Tokenizer ist trainiert worden – genau wie das Modell selbst. Er hat gelernt, welche Textmuster häufig vorkommen und wie man sie sinnvoll aufteilt. Deutsche Komposita sind dabei eine besondere Herausforderung. „Donaudampfschifffahrtsgesellschaftskapitän” wird vermutlich in mehrere Tokens zerlegt, während englische Wörter oft als Ganzes tokenisiert werden. Das liegt schlicht daran, dass die meisten Trainingsdaten auf Englisch sind.
Wenn Sie mehrsprachige Anwendungen bauen, merken Sie das schnell an den Kosten. Derselbe Inhalt kostet in verschiedenen Sprachen unterschiedlich viele Tokens. Ein deutscher Text verbraucht typischerweise mehr Tokens als ein englischer mit derselben semantischen Bedeutung. Nicht weil Deutsch schlechter wäre, sondern weil die Tokenizer auf andere Sprachmuster optimiert wurden.
Schauen wir uns einen konkreten Fall an. Der Satz:
„GPT-4 ist ein Large Language Model.”
könnte von GPT-4s eigenem Tokenizer etwa so zerlegt werden:
["GPT", "-", "4", " ist", " ein", " Large", " Language", " Model", "."]Das sind neun Tokens. Nicht neun Wörter. Der Bindestrich ist ein eigenes Token. Das Leerzeichen vor „ist” gehört zum Token. Der Punkt am Ende ebenfalls.
Würden Sie denselben Satz an Claude schicken, könnte die Tokenisierung anders aussehen. Vielleicht wird „GPT-4” als Ganzes erkannt, weil es häufig in den Trainingsdaten vorkommt. Vielleicht wird „Large Language Model” als zusammenhängende Einheit behandelt. Vielleicht auch nicht.
Sie sehen: Es gibt keine universelle Wahrheit darüber, was ein Token ist. Es gibt nur modellspezifische Definitionen.
Drei Gründe, warum Sie sich mit Tokens auseinandersetzen müssen:
Erstens: Kosten. Jeder API-Aufruf an ein LLM kostet Geld – pro Token. Input-Tokens kosten, Output-Tokens kosten. Wenn Sie nicht wissen, wie viele Tokens Sie verbrauchen, wissen Sie nicht, was Sie zahlen. Ein prompt, der „nur ein bisschen” länger ist, kann schnell doppelt so teuer werden. Prompt-Engineering bedeutet auch: Token-Engineering.
Zweitens: Limits. Jedes Modell hat ein Kontextfenster – eine maximale Anzahl von Tokens, die es gleichzeitig verarbeiten kann. Bei GPT-4 waren das lange Zeit 8.000 Tokens, später 32.000, dann 128.000. Neuere Modelle schaffen Millionen. Aber egal wie groß das Fenster ist: Es gibt eine Grenze. Wenn Sie nicht wissen, wie viele Tokens Ihre Eingabe hat, wissen Sie nicht, ob sie überhaupt verarbeitet werden kann.
Drittens: Verständnis. Wenn Sie wissen, wie Ihr Text tokenisiert wird, verstehen Sie besser, wie das Modell ihn „sieht”. Sie verstehen, warum manche Formulierungen besser funktionieren als andere. Sie verstehen, warum Code manchmal zuverlässiger verarbeitet wird als Prosa. Sie verstehen die Maschine – nicht als denkendes System, sondern als mathematisches.
Jetzt wird es interessant. Denn Tokens sind nicht das Endprodukt. Sie sind nur der erste Schritt.
Was passiert, nachdem Ihr Text in Tokens zerlegt wurde? Er wird in Zahlen übersetzt. Jedes Token bekommt eine eindeutige ID – eine Ganzzahl. „GPT” könnte die ID 5432 haben, „ist” die 891, und so weiter. Diese IDs sind im Vokabular des Modells definiert, einer riesigen Tabelle, die alle möglichen Tokens auflistet.
Aber auch diese Zahlen sind noch nicht das, womit das Modell wirklich arbeitet. Der nächste Schritt ist die Umwandlung in Vektoren. Jedes Token wird zu einem hochdimensionalen Vektor – typischerweise mit mehreren hundert oder tausend Dimensionen. Diese Vektoren sind trainiert worden, so dass Tokens mit ähnlicher Bedeutung oder ähnlichem Kontext in diesem Vektorraum nahe beieinander liegen.
Und ab hier ist alles Mathematik. Es ist eine choreografierte Folge linearer Algebra. Oder anders ausgedrückt: Ein maschinell optimierter Wahrscheinlichkeitsautomat.
Das gesamte Modell – all das, was GPT-4 „kann”, was Claude „weiß”, was Mistral „versteht” – ist nichts anderes als eine gigantische Sammlung von Gewichtungsmatrizen. Milliarden, manchmal hunderte Milliarden von Zahlen, organisiert in Matrizen. Wenn Sie einen tokenisierten, vektorisierten Text durch das Modell schicken, passiert nichts anderes als: Matrizenmultiplikationen. Hunderte Male. Layer für Layer.
Keine Magie. Keine Intelligenz. Nur lineare Algebra.
Diese Matrizen sind das Ergebnis des Trainings. Sie kodieren die statistischen Muster, die das Modell gelernt hat. Wenn Sie fragen: „Wo ist das Wissen gespeichert?“, dann ist die Antwort: In den Gewichtungen. In den Zahlen. Nicht als Fakten, sondern als Wahrscheinlichkeitsverteilungen.
Am Ende dieses mathematischen Durchlaufs steht eine Wahrscheinlichkeitsverteilung über alle möglichen Tokens im Vokabular. Das Modell sagt: Mit einer Wahrscheinlichkeit von 37% kommt als nächstes Token „ist”, mit 12% „war”, mit 8% „wird”. Dann wählt es eines aus – meist das wahrscheinlichste, manchmal mit etwas Zufall versetzt, damit die Ausgabe nicht immer identisch ist.
Und dann beginnt der Prozess von vorn. Das neue Token wird an die Sequenz angehängt, wieder vektorisiert, wieder durch die Matrizen geschickt. Token für Token entsteht so eine Antwort.
Hier liegt eine wichtige Falle. Nur weil ein Text in Tokens zerlegt wird, heißt das nicht, dass das Modell die Bedeutung versteht.
Nehmen wir die Phrase „nicht schlecht”. Für einen Tokenizer sind das zwei separate Tokens: „nicht” und „schlecht”. Das Modell sieht zwei aufeinanderfolgende Vektoren. Dass „nicht schlecht” im Deutschen oft „ziemlich gut” bedeutet – eine Litotes –, ist nicht in den einzelnen Tokens kodiert. Es ist im trainierten Modell kodiert, in den Gewichtungen, die gelernt haben, dass diese Token-Kombination eine bestimmte semantische Bedeutung hat.
Aber das Modell „versteht” das nicht. Es hat nur gelernt, dass nach „nicht schlecht” oft Formulierungen folgen, die positive Aussagen unterstützen. Statistisch, nicht semantisch.
Das ist der Unterschied zwischen Repräsentation und Verständnis. Token repräsentieren Text. Vektoren repräsentieren Token im Modell. Gewichtungen repräsentieren trainierte Muster. Aber nirgendwo in dieser Kette entsteht Verständnis im menschlichen Sinne.
Token spielen nicht nur bei der Textgenerierung eine Rolle. Sie sind auch die Grundlage für eine andere wichtige Technologie, die Sie beim Bau produktionsnaher KI-Anwendungen kennen müssen: Vektordatenbanken.
Wenn Sie semantische Suche implementieren wollen – also die Fähigkeit, Dokumente nicht nach exakten Stichworten, sondern nach Bedeutung zu durchsuchen –, dann arbeiten Sie mit Embeddings. Und Embeddings entstehen durch… genau, Tokenisierung. Der Text wird in Tokens zerlegt, die Tokens werden vektorisiert, und diese Vektoren werden durch ein spezialisiertes Modell geschickt, das daraus eine kompakte Repräsentation – einen Embedding-Vektor – erzeugt.
Dieser Vektor kann dann in einer Vektordatenbank gespeichert werden, wo Sie später ähnliche Vektoren finden können. Das ist die Basis für Retrieval-Augmented Generation, für semantische Dokumentensuche, für intelligente Chatbots, die auf Ihre eigenen Daten zugreifen.
Aber das ist ein Thema für später. Erst einmal ist wichtig zu verstehen: Tokens sind überall. Sie sind die fundamentale Einheit, mit der moderne Sprachmodelle und die darauf aufbauenden Systeme arbeiten.
Und sie sind nichts weiter als eine technische Notwendigkeit. Eine Brücke zwischen menschlicher Sprache und mathematischen Operationen.
Kein Denken. Keine Intelligenz. Nur gut trainierte Matrizen, die auf Tokens operieren.
Wenn Sie das nächste Mal ein LLM eine komplexe Frage beantworten sehen – scheinbar durchdacht, eloquent formuliert, überzeugend in der Argumentation –, dann erinnern Sie sich an dieses Kapitel.
Da denkt niemand.
Da ist kein Bewusstsein, das Ihre Frage erfasst, über sie nachdenkt und eine Antwort formuliert. Was Sie sehen, ist das Ergebnis von Millionen Matrizenmultiplikationen, die auf tokenisierte Eingaben angewendet werden. Token für Token berechnet das Modell, welche Fortsetzung statistisch am plausibelsten ist. Die Gewichtungsmatrizen – trainiert auf Milliarden von Texten – enthalten nichts als Zahlen. Keine Bedeutung. Keine Intentionen. Keine Gedanken.
Nur trainierte Parameter, die erstaunlich gut darin sind, menschliche Sprache nachzuahmen.
Das klingt ernüchternd? Ist es auch. Aber es ist notwendig, diese Ernüchterung zu durchlaufen, wenn Sie professionell mit diesen Systemen arbeiten wollen. Denn nur wenn Sie verstehen, dass ein LLM nicht versteht, können Sie es richtig einsetzen. Nur wenn Sie begreifen, dass jede Ausgabe eine Wahrscheinlichkeitsberechnung ist, können Sie die Grenzen erkennen. Nur wenn Sie wissen, dass Tokens die atomare Einheit sind – nicht Bedeutungen, nicht Konzepte, sondern Textfragmente, die in Vektoren umgewandelt werden –, können Sie die Architektur hinter den schönen Interfaces durchschauen.
Dieses Wissen ist nicht akademisch. Es hat direkte Auswirkungen auf Ihren Alltag als Entwickler.
Wenn Sie einen Prompt schreiben, schreiben Sie nicht für einen menschlichen Leser. Sie schreiben für einen Tokenizer. Manche Formulierungen erzeugen mehr Tokens als andere. Manche werden günstiger vektorisiert. Manche passen besser zu den Mustern, die das Modell gelernt hat. Ein guter Prompt ist nicht nur inhaltlich klar – er ist auch token-effizient.
Wenn Sie die Ausgabe eines LLMs in Produktivumgebungen einsetzen wollen, müssen Sie mit Halluzinationen rechnen. Nicht ab und zu. Strukturell. Denn das Modell hat keine Möglichkeit, zwischen „ich habe das in den Trainingsdaten gesehen” und „das klingt plausibel” zu unterscheiden. Beide führen zu hohen Wahrscheinlichkeitswerten für bestimmte Token-Sequenzen. Das Modell kann Ihnen mit derselben Überzeugung einen Fakt oder eine Fiktion präsentieren.
Wenn Sie mehrere Modelle vergleichen, vergleichen Sie nicht nur deren Fähigkeiten. Sie vergleichen verschiedene Tokenizer, verschiedene Vokabulare, verschiedene Gewichtungsmatrizen. Ein Prompt, der bei GPT-4 hervorragend funktioniert, kann bei Claude anders tokenisiert werden und zu anderen Ergebnissen führen. Nicht weil ein Modell „besser denkt”, sondern weil die mathematischen Transformationen unterschiedlich sind.
Die meisten Modellhersteller bieten Online-Playgrounds an, in denen Sie Texte tokenisieren lassen können. OpenAI hat einen Tokenizer-Playground. Anthropic zeigt die Token-Anzahl direkt in der API-Dokumentation an. Nutzen Sie diese Werkzeuge. Geben Sie Ihre Prompts ein und schauen Sie, wie sie zerlegt werden.
Sie werden überrascht sein.
Ein deutscher Fachbegriff wie „Qualitätssicherungsmaßnahme” wird vermutlich in fünf oder sechs Tokens zerlegt. „QA” vielleicht in ein einziges. Das hat nichts mit Semantik zu tun – nur damit, was der Tokenizer in seinen Trainingsdaten häufig gesehen hat. Englische Abkürzungen sind überrepräsentiert. Deutsche Komposita unterrepräsentiert.
Machen Sie sich ein Bild davon, wie Ihre typischen Eingaben verarbeitet werden. Wie viele Tokens kosten sie? Wo werden sie aufgetrennt? Welche Formulierungen sind effizienter als andere?
Das ist kein Selbstzweck. Es ist Grundlagenarbeit. So wie Sie als Entwickler verstehen müssen, wie Ihr Compiler mit Code umgeht, sollten Sie verstehen, wie ein Tokenizer mit Text umgeht.
Es mag paradox klingen, aber die Entzauberung ist der erste Schritt zur professionellen Arbeit mit LLMs. Solange Sie glauben, dass diese Systeme „intelligent” sind, werden Sie sie falsch einsetzen. Sie werden ihnen zu viel zutrauen. Sie werden sich auf ihre Ausgaben verlassen, ohne sie zu validieren. Sie werden enttäuscht sein, wenn sie versagen – und Sie werden nicht verstehen, warum.
Aber sobald Sie begreifen, dass ein LLM nichts weiter ist als eine mathematische Funktion, die tokenisierte Eingaben in wahrscheinliche tokenisierte Ausgaben transformiert, ändert sich Ihre Perspektive. Sie sehen das Werkzeug so, wie es ist. Nicht als Ersatz für menschliches Denken. Sondern als extrem leistungsfähiger statistischer Textgenerator, der auf Grundlage von Trainingsmustern arbeitet.
Und genau diese Perspektive brauchen Sie, um die nächsten Schritte zu gehen. Um zu verstehen, wie Sie LLMs in echte Anwendungen integrieren. Wie Sie ihre Schwächen kompensieren. Wie Sie Retrieval-Augmented Generation nutzen, um faktische Korrektheit zu erhöhen. Wie Sie mit Vektordatenbanken arbeiten, um semantische Suche zu implementieren. Wie Sie Prompt-Engineering betreiben, das nicht auf Hoffnung, sondern auf Verständnis basiert.
Aber all das baut auf der Grundlage auf, die Sie jetzt haben: Tokens sind keine Wörter. Vektoren sind keine Bedeutungen. Gewichtungsmatrizen sind kein Wissen. Und Wahrscheinlichkeitsberechnungen sind kein Denken.
Es ist Mathematik. Sehr gute Mathematik. Aber eben nur Mathematik.