Was ist ein Token? Über Inferenz und den Preis einer Antwort

Bevor ein Text den Vektorraum, die Landkarte der Sprache, überhaupt erreicht, durchläuft er einen unscheinbaren technischen Schritt: Der Tokenizer zerlegt ihn in Einheiten und weist jeder eine numerische Kennung zu, eine Token-ID. Erst die Embedding-Schicht übersetzt diese Kennung anschließend in einen Vektor, mit dem das Modell weiterrechnet. Ein Token ist damit nicht die Adresse selbst, sondern das Stück Text, für das eine Adresse nachgeschlagen wird: eine technisch festgelegte Einheit im Vokabular des jeweiligen Modells. „Zitrone" bekommt bei vielen Tokenizern einen eigenen Eintrag. Ein selteneres oder zusammengesetztes Wort zerfällt dagegen in mehrere kleinere Einheiten, deren Embeddings das Modell erst im Satzkontext, durch seine Transformerschichten hindurch, zu einer kontextuellen Repräsentation verarbeitet.

Für die Rechnung ist genau diese Einheit die Größe, die zählt, und sie ist mehr als eine Fußnote: Der Token ist das Scharnier zwischen Sprache, Rechenarbeit und Preis. Der Tokenizer zerlegt die Sprache; das Modell verarbeitet die entstandenen Einheiten während der Inferenz, also bei der Anwendung des bereits trainierten Modells; der Anbieter macht sie zur Abrechnungseinheit. Und die Architektur eines Systems entscheidet am Ende mit, wie viele teure Tokens dabei überhaupt entstehen.

Ein Token kann ein vollständiges Wort sein, aber auch nur ein Wortteil, ein Satzzeichen oder ein Bruchstück eines Zeichens. Welche Einheit entsteht, hängt vom Vokabular des jeweiligen Tokenizers ab. Kurze, häufige Wörter wie „und„, „ist“ oder „Zitrone„ bleiben bei vielen Tokenizern vollständig erhalten; ob „Zitrone“ tatsächlich eine einzige Einheit bildet, hängt allerdings vom konkreten Tokenizer, der Schreibweise und mitunter sogar vom vorausgehenden Leerzeichen ab.

Längere oder seltene Wörter zerfallen in mehrere Einheiten: „Zitronenschale„ könnte in „Zitronen“ und „schale" aufgeteilt werden, ein Fachbegriff oder ein Name in noch mehr Teile. Verfahren wie Byte Pair Encoding oder Unigram, mit denen der Tokenizer vorab an einem eigenen Textkorpus trainiert wird, bevorzugen dabei häufige Zeichenfolgen für einen eigenen Eintrag im Vokabular. Bedeutung ist für diese Entscheidung nicht das Kriterium.

Das hat eine praktische Folge, die sich aber nicht pauschal für „Deutsch" behaupten lässt: Je nachdem, wie multilingual ein Tokenizer trainiert wurde, können deutsche Komposita und zusammengesetzte Fachwörter in mehr Einheiten zerfallen als ihr englisches Gegenstück, müssen es aber nicht. Ein direkter Vergleich hängt am konkreten Tokenizer eines konkreten Modells, nicht an der Sprache selbst.

Auf jeder Rechnung stehen zwei unterschiedliche Preise. Bei vielen kommerziellen Anbietern ist Ausgabe deutlich teurer als Eingabe, bei den aktuellen Claude-Modellen das Fünffache. Das konkrete Verhältnis ist eine kommerzielle Festlegung der Anbieter, keine Naturkonstante; der zugrunde liegende Aufwandsunterschied ist allerdings real. Er entsteht während der Inferenz, deren Name so viel wie Ableitung bedeutet: Das bereits trainierte Modell leitet aus einer neuen Eingabe eine Ausgabe ab, bei einem Sprachmodell in zwei Phasen, dem Prefill und dem anschließenden Decode. Abgerechnet wird diese Nutzung anhand der verarbeiteten Eingabe- und erzeugten Ausgabe-Tokens. Die Kosten des Trainings erscheinen zwar nicht als eigene Position auf der Rechnung, können als Teil der Vollkosten aber in den Tarif einfließen.

Die Eingabe, der Prompt, wird während der Prefill-Phase verarbeitet: Ihre Tokens laufen weitgehend parallel durch die Schichten des Modells. Dabei entstehen interne Repräsentationen, die in einem Key-Value-Cache, kurz KV-Cache, abgelegt werden, dem Arbeitsgedächtnis der folgenden Ausgabe. Dieser Cache wird leicht überschätzt: Er verhindert, dass alle bisherigen Tokens bei jedem weiteren Schritt vollständig neu berechnet werden müssen (1), mehr nicht.

Obschon der Cache diese Arbeit abkürzt, bleibt die anschließende Decode-Phase langsamer und teurer. Sprachmodelle erzeugen ihre Antwort autoregressiv, Token für Token: Erst wenn eines feststeht, lässt sich das nächste bestimmen. Jeder neue Decode-Schritt ergänzt den KV-Cache um die Repräsentation des gerade erzeugten Tokens, und die Berechnung bezieht die gespeicherten Key- und Value-Werte des gesamten bisherigen Kontexts ein. Je länger dieser Kontext wird, desto mehr Daten müssen dafür aus dem Speicher gelesen werden – begrenzt wird diese Arbeit deshalb eher von der Speicherbandbreite als von der reinen Rechenleistung. Eine Antwort mit 500 erzeugten Tokens bedeutet mindestens 500 aufeinanderfolgende Decode-Schritte, keine 500 vollständigen Neuberechnungen, aber auch keinen einzigen Durchlauf.

Das muss man von einer neuen Gesprächsrunde unterscheiden. Innerhalb einer laufenden Antwort wächst der KV-Cache mit jedem erzeugten Token weiter. Beginnt dagegen eine neue Anfrage, etwa die nächste Nachricht in einem Chat, wird die bisherige Unterhaltung gewöhnlich komplett als Eingabe übertragen und durchläuft den Prefill von vorn. Ohne Prompt- oder Prefix-Caching erzeugt der bereits bekannte Gesprächsverlauf also neuen, kostenpflichtigen Prefill-Aufwand, keinen wachsenden, günstigen Cache.

Ein Token ist keine Erfindung der Buchhaltung. Jedes einzelne löst eine Berechnung auf physischer Hardware aus, die Energie verbraucht. Eine aktuelle Modellierung veranschlagt dafür, je nach Modellgröße und Auslastung, etwa 0,36 bis 7,2 Joule pro erzeugtem Token und rechnet mit 1,8 Joule als mittlerem Arbeitswert (2). Bei einer haushaltsüblichen 10-Watt-LED entspricht das knapp zwei Zehntelsekunden Leuchtdauer.

Zum reinen Stromverbrauch kommt die Rechenzeit auf spezialisierten, teuren Grafikchips, deren Anschaffung, Betrieb und Kühlung selbst Geld kosten, unabhängig vom Strompreis einer einzelnen Anfrage. Ein Tokenpreis ist deshalb kein Stromzähler, er ist ein Tarif: Er soll die variablen Grenzkosten einer zusätzlichen Anfrage decken, vor allem Energie und belegte Rechenkapazität, enthält zugleich anteilige Vollkosten, die investierten Milliarden in Chips und Rechenzentren, Entwicklung und Betrieb, sowie eine Marge. Wie diese Bestandteile gegeneinander gewichtet sind, legen die Anbieter nicht offen. Dass die Preise seit 2022 dennoch drastisch gefallen sind, grob um das Zehnfache pro Jahr bei vergleichbarer Leistungsfähigkeit, liegt an effizienterer Hardware und optimierter Software, an Quantisierung, leistungsfähigeren kleineren Modellen und am Wettbewerb. Erfunden waren die ursprünglichen Preise deshalb nicht.

Wie viel Spielraum nach oben trotzdem bliebe, zeigt das sogenannte Landauer-Limit, die theoretische physikalische Untergrenze für die Energie einer irreversiblen Bit-Operation. Der faire Vergleich setzt dabei nicht eine einzelne reale Rechenoperation gegen ihr physikalisches Minimum. Er setzt den geschätzten Energieaufwand eines ganzen Ausgabe-Tokens gegen die theoretische Untergrenze für dessen angenommenen Informationsgehalt, und selbst so liegt heutige Hardware ungefähr das 10¹⁹- bis 10²⁰-fache darüber. Das heißt keineswegs, dass ein Rechenzentrum „nur etwas effizienter" werden müsste, um dort anzukommen; die Kluft zwischen praktischer Technik und physikalischer Theorie liegt in einer ganz anderen Größenordnung. Es heißt nur: Der heutige Preis ist real, aber er ist nicht das letzte Wort der Physik.

Ein Modell wie Claude Haiku 4.5 kostet laut Anthropics aktueller Preisliste 1 US-Dollar pro Million Eingabe-Tokens und 5 Dollar pro Million Ausgabe-Tokens. Ein leistungsfähigeres und deutlich teureres Modell wie Claude Fable 5 kostet 10 beziehungsweise 50 Dollar (3). Derselbe Fünf-zu-eins-Sprung zwischen Ein- und Ausgabe wiederholt sich bei beiden, zwischen den Modellen liegt jedoch das Zehnfache.

Selbst dieser Vergleich ist weniger eindeutig, als er aussieht. Claude Fable 5 gehört zu einer Modellgeneration, die laut Anthropic einen neueren Tokenizer verwendet, der für denselben Text im Schnitt rund 30 Prozent mehr Tokens erzeugt als der ältere Tokenizer, den Haiku 4.5 noch nutzt (3). Ein Token ist also nicht einmal zwischen zwei Modellen desselben Anbieters eine vollständig standardisierte Mengeneinheit: Für denselben Satz zählt Fable 5 mehr Tokens als Haiku, bevor die eigentliche Preisdifferenz überhaupt greift.

Der naheliegendste Hebel ist, nicht jede Aufgabe demselben Modell zu geben. Ein kurzer Klassifizierungsschritt, eine einfache Zusammenfassung oder eine Standardantwort braucht kein Modell der teuersten Kategorie. Ein komplexer Analyseschritt, eine mehrstufige Argumentation oder eine Aufgabe mit hohem Fehlerrisiko rechtfertigt dagegen den höheren Preis.

Dafür haben sich in der Praxis mehrere Bausteine etabliert, die man auseinanderhalten sollte. Ein Model Router wählt vor der eigentlichen Generierung ein passendes Modell aus; oft ist er selbst ein kleines, eigens trainiertes Modell, das die Schwierigkeit einer Anfrage einschätzt, kein starres Regelwerk. Microsofts Model Router in Azure funktioniert genau so (4). Eine Modellkaskade geht anders vor: Sie beginnt mit einem günstigen Modell und zieht ein stärkeres, teureres nur hinzu, wenn die erste Antwort nicht zuverlässig genug wirkt. Ein Provider Router wählt dagegen für dasselbe Modell nur den günstigsten Anbieter oder Endpunkt aus; OpenRouter etwa priorisiert beim Provider Routing standardmäßig den Preis, während sein zusätzlicher Auto Router auch das Modell selbst bestimmt (5). Ein LLM-Gateway wie LiteLLM oder Portkey bildet schließlich die technische Infrastrukturschicht für all das: Routing, Limits, Protokollierung, Fallbacks (6).

RouteLLM, eine Arbeit der UC Berkeley, ist ein Model Router: Auf dem Benchmark MT-Bench erreichte eine seiner Konfigurationen bei 95 Prozent des GPT-4-Scores eine rund 3,66-fach niedrigere Kostenrechnung, also etwa 73 Prozent Ersparnis, weil ein großer Teil der Anfragen an ein schwächeres, günstigeres Modell ging (7). FrugalGPT aus Stanford ist dagegen eine Modellkaskade: Es beginnt günstig und zieht nur bei erkannter Unsicherheit ein stärkeres Modell hinzu, mit bis zu 98 Prozent Ersparnis als Bestwert in den untersuchten Testszenarien (8). Beide Werte sind Benchmarkergebnisse mit bestimmten Modellpaaren und den damals gültigen Preisen, keine Garantie für ein produktives System.

Zwei weitere Hebel senken die Rechnung unabhängig vom gewählten Modell. Prompt Caching erspart es einem identischen Anfang eines Prompts, etwa einer langen Systemanweisung, bei jeder erneuten Anfrage komplett neu durch die Prefill-Phase zu laufen. Bei Anthropic kostet ein solcher Cache Write beim ersten Mal das 1,25- beziehungsweise 2-Fache des normalen Preises, je nachdem, ob der Eintrag fünf Minuten oder eine Stunde gültig bleibt; ein anschließender Cache Hit kostet nur ein Zehntel (3). Die Batch-Verarbeitung schließlich, bei der Anfragen ohne Zeitdruck gesammelt statt einzeln in Echtzeit beantwortet werden, halbiert die Kosten bei Anthropic, wenn auch nicht bei jedem Anbieter in gleicher Höhe.

Die Rechnung zählt Tokens korrekt. Sie misst damit aber weder Textmenge oder Qualität noch Wert. Ein Token sagt nichts darüber aus, wie klug eine Antwort ist; nicht einmal die Textmenge lässt sich damit über Modellgrenzen hinweg eindeutig vergleichen. Der Token ist eine technische Verarbeitungseinheit und zugleich ein kommerzieller Tarif. Wie günstig ein einzelnes Token ist, ist deshalb die falsche Kostenfrage. Die richtige lautet: Welches Modell sollte eine Aufgabe bearbeiten, und wie viele Tokens lässt das System dafür überhaupt entstehen? Ein Rest bleibt dabei eine Blackbox, denn wie Grenzkosten, Vollkosten und Marge in einem einzelnen Preis gewichtet sind, verrät kein Anbieter. Der Preis ist auf das Token genau berechnet und bleibt doch eine Setzung.