Token-Kosten für LLM-Anfragen berechnet man, indem man die Anzahl der Eingabe- und Ausgabe-Token getrennt mit dem jeweiligen Preis pro 1.000 Token multipliziert und die beiden Ergebnisse addiert. Die Token-Anzahl erhält man entweder aus der Antwort des API-Anbieters (Usage-Feld) oder näherungsweise über die Tokenisierung des Prompt-Textes mit einem passenden Tokenizer. Anschließend lässt sich der Betrag pro Anfrage mit der geplanten Anzahl an Anfragen pro Tag und Monat hochrechnen.
Warum Token-Kosten entscheidend sind: Eingabe- vs. Ausgabe-Token
Jede Anfrage an ein Large Language Model (LLM) wird nicht in Wörtern oder Zeichen abgerechnet, sondern in Token. Ein Token ist die kleinste Texteinheit, die das Modell verarbeitet – das kann ein ganzes Wort, ein Wortteil, ein Satzzeichen oder ein einzelnes Zeichen sein. Die Abrechnung erfolgt in der Regel über einen Preis pro 1.000 Token, getrennt nach Eingabe (Input) und Ausgabe (Output). Diese Trennung ist der wichtigste Hebel für die Kostenplanung: Eingabe-Token sind der Text, den du an das Modell schickst (Prompt, Kontext, Dokumente, Chat-Verlauf), Ausgabe-Token sind der vom Modell generierte Text.
Der entscheidende Punkt: Ausgabe-Token sind bei nahezu allen Anbietern deutlich teurer als Eingabe-Token, oft um den Faktor drei bis fünf. Das liegt daran, dass die Generierung jedes einzelnen Tokens einen vollständigen Vorwärtsdurchlauf durch das Modell erfordert, während die Eingabe in einem einzigen Durchlauf verarbeitet wird. Wer die Kosten unterschätzt, tut das meist an zwei Stellen: lange Kontexte (viele Eingabe-Token, etwa bei RAG-Systemen oder langen Chat-Verläufen) und lange oder ausführliche Antworten (viele Ausgabe-Token).
Für die Praxis heißt das: Du musst beide Größen getrennt erfassen und getrennt bepreisen. Eine einzelne Durchschnittszahl über „Token insgesamt“ verdeckt, wo die Kosten tatsächlich entstehen. Gerade bei Agenten, die mehrere Schritte durchlaufen und dabei den wachsenden Gesprächsverlauf immer wieder mitsenden, wächst die Eingabemenge schnell – während die eigentliche Antwort kurz bleibt.
Ein zweiter Kostenfaktor ist die Wiederholung: In zustandslosen APIs wird bei jeder Anfrage der gesamte relevante Kontext erneut als Eingabe übertragen und abgerechnet. Ein Chat mit zehn Runden bezahlt in der letzten Runde also nicht nur die neue Frage, sondern den kompletten bisherigen Verlauf. Das solltest du bei der Hochrechnung berücksichtigen, sonst liegst du systematisch zu niedrig.
Von Text zu Token: Bezug zur BPE-Tokenisierung
Damit du Token vor dem API-Aufruf schätzen kannst, musst du verstehen, wie Text in Token zerlegt wird. Die meisten modernen Modelle verwenden Byte-Pair-Encoding (BPE). BPE ist ein Verfahren, das aus einem Trainingskorpus häufige Zeichenfolgen zu größeren Einheiten zusammenfasst: Aus Buchstaben werden Silben, aus Silben werden Wörter, aus häufigen Wörtern werden einzelne Token. Das Ergebnis ist ein Vokabular fester Größe (typischerweise im Bereich von Zehntausenden bis einigen Hunderttausend Einträgen), und der Tokenizer zerlegt neuen Text greedily in die längsten passenden Vokabular-Einträge.
Was bedeutet das konkret für die Anzahl? Häufige, kurze Wörter wie „und“ oder „der“ werden meist zu einem Token. Lange, seltene oder fachsprachliche Wörter sowie Komposita im Deutschen zerfallen häufig in mehrere Token. Sonderzeichen, Emojis und Zahlen kosten oft mehr Token als erwartet, weil sie im Trainingskorpus seltener vorkommen. Als grobe Orientierung – keine exakte Regel – gelten für englischen Text etwa vier Zeichen pro Token; deutscher Text liegt wegen längerer Wörter und Komposita eher niedriger, oft bei rund zwei bis drei Zeichen pro Token. Behandle diese Werte als Schätzannahme, nicht als Messwert.
Der praktische Konsequenz: Eine Zeichen- oder Wortzählung ist nur eine Näherung. Für belastbare Zahlen nutzt du den Tokenizer des jeweiligen Modells – viele Anbieter stellen dafür Bibliotheken bereit, und einige APIs liefern die Token-Anzahl vorab über einen eigenen Endpoint. Wichtig ist, denselben Tokenizer zu verwenden wie das Modell, denn Vokabulare unterscheiden sich zwischen Modellfamilien. Ein Text, der bei Modell A 100 Token kostet, kann bei Modell B 120 Token kosten. Für die Kostenrechnung zählt immer die Token-Anzahl des tatsächlich aufgerufenen Modells.
Ein letzter Punkt zur Genauigkeit: Die Token-Anzahl der Ausgabe kennst du vor dem Aufruf nicht, denn sie hängt vom Generierungsverhalten des Modells ab. Du kannst sie über die maximale Ausgabelänge (max_tokens) nach oben begrenzen und für die Planung mit einem Erfahrungswert oder einer Spanne arbeiten. Nach dem Aufruf liefert das Usage-Feld der API die exakten Zahlen für Eingabe und Ausgabe – das ist deine verlässliche Quelle für die Nachkalkulation.
Schritt-für-Schritt-Beispielrechnung mit Preis pro 1.000 Token
Wir rechnen mit einem bewusst einfachen, frei gewählten Preismodell, damit die Mechanik klar wird: 0,50 € pro 1.000 Eingabe-Token und 1,50 € pro 1.000 Ausgabe-Token. Das sind Beispielpreise, keine Aussage über aktuelle Anbieterpreise – prüfe für echte Budgets immer die Preisliste deines Anbieters.
Angenommen, eine Anfrage besteht aus einem Prompt von 800 Token (Systemanweisung, Kontext, Frage) und einer Antwort von 400 Token. Der Preis pro Token ergibt sich, indem du den Preis pro 1.000 Token durch 1.000 teilst:
Eingabe-Token: 800 Token × (0,50 € / 1.000) = 0,00080 €
Ausgabe-Token: 400 Token × (1,50 € / 1.000) = 0,00060 €
Kosten pro Anfrage = 0,00080 € + 0,00060 € = 0,00140 €
Also 0,14 Cent pro Anfrage. Wichtig: Ausgabe-Token sind hier dreimal so teuer wie Eingabe-Token – deshalb schlägt eine lange Antwort stärker zu Buche als ein langer Prompt. Rechne beide Posten getrennt, nie pauschal.
Checkliste für die eigene Rechnung:
- Prompt- und Antwortlänge in Token ermitteln (nicht in Wörtern, siehe BPE-Teil).
- Preise pro 1.000 Token für Eingabe und Ausgabe aus der Preisliste ziehen.
- Beide Posten einzeln multiplizieren und addieren.
- Mit der erwarteten Anzahl Anfragen multiplizieren (nächster Abschnitt).
Hochrechnung auf Tag und Monat: Kosten im Betrieb planen
Aus den Kosten pro Anfrage wird eine Betriebsplanung, indem du mit der Nutzungsmenge multiplizierst. Bleiben wir beim Beispiel von 0,00140 € pro Anfrage:
Anfragen pro Tag: 500
Kosten pro Tag = 500 × 0,00140 € = 0,70 €
Kosten pro Monat = 0,70 € × 30 = 21,00 €
Bei 5.000 Anfragen pro Tag wären es analog 7,00 € pro Tag und rund 210 € pro Monat (30 Tage gerechnet). Der Monatswert ist eine Schätzung unter Annahme konstanter Nutzung – reale Monate haben unterschiedlich viele Tage und schwankende Auslastung.
Ein kurzer Code-Gedanke als Formel, den du in jede Tabellenkalkulation übertragen kannst:
kosten_anfrage = (eingabe_token / 1000) * preis_eingabe
+ (ausgabe_token / 1000) * preis_ausgabe
kosten_monat = kosten_anfrage * anfragen_pro_tag * tage_pro_monat
Praktische Hinweise zur Planung:
- Rechne mit einer Spanne statt einem Punktwert: Schätze eine niedrige und eine hohe Antwortlänge, weil die Ausgabe-Token den größten Hebel haben.
- Plane einen Puffer ein, etwa für Retries, längere Kontexte oder Testaufrufe, die ebenfalls Token verbrauchen.
- Prüfe die Annahmen regelmäßig gegen die tatsächlich abgerechneten Token aus der API-Antwort (viele APIs liefern die verbrauchten Token mit).
So bleibt die Hochrechnung eine begründete Schätzung – transparent in den Annahmen, belastbar für Budgetentscheidungen.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Eingabe- und Ausgabe-Token bei den Kosten?
Eingabe-Token sind die Zeichen, die du an das Modell schickst (Prompt, Kontext, Beispiele), Ausgabe-Token sind die Zeichen, die das Modell zurückgibt. Die meisten Anbieter bepreisen beide getrennt, und Ausgabe-Token sind pro Token meist deutlich teurer als Eingabe-Token, weil die Generierung rechnerisch aufwendiger ist. Für die Kosten heißt das: Ein langer Prompt mit kurzer Antwort kostet vor allem über den Eingabepreis, eine lange generierte Antwort schlägt stärker über den Ausgabepreis zu Buche.
Warum beeinflusst die BPE-Tokenisierung die Anzahl der Token und damit die Kosten?
BPE (Byte Pair Encoding) zerlegt Text in wiederkehrende Zeichenfolgen: Häufige Wörter und Silben werden zu einem einzigen Token, seltene Wörter, Fachbegriffe, Zahlen oder Sonderzeichen in mehrere Teilstücke. Deshalb gilt nicht „ein Wort = ein Token", sondern grob ein Richtwert von etwa 1,3 bis 1,5 Token pro Wort im Deutschen – als Schätzung, nicht als fixe Konstante. Je nach Wortschatz des Modells und Sprache des Textes variiert die Token-Anzahl, und genau diese Anzahl multipliziert sich mit dem Token-Preis.
Wie rechne ich den Preis pro 1.000 Token auf meine Anfrage um?
Du zählst die Token deiner Anfrage (Eingabe und Ausgabe getrennt) und rechnest mit dem Preis pro 1.000 Token:
Kosten = (Eingabe-Token / 1000) * Preis_Eingabe_pro_1000
+ (Ausgabe-Token / 1000) * Preis_Ausgabe_pro_1000
Beispiel mit angenommenen Preisen von 0,50 Einheiten pro 1.000 Eingabe-Token und 1,50 Einheiten pro 1.000 Ausgabe-Token: Bei 800 Eingabe- und 400 Ausgabe-Token ergibt das (0,8 × 0,50) + (0,4 × 1,50) = 0,40 + 0,60 = 1,00 Einheit pro Anfrage. Setze einfach die tatsächlichen Preise deines Anbieters ein.
Wie hoch sind meine monatlichen LLM-Kosten bei täglicher Nutzung?
Multipliziere die Kosten pro Anfrage mit der Zahl der Anfragen pro Tag und dann mit den Einsatztagen im Monat:
Monat = Kosten_pro_Anfrage * Anfragen_pro_Tag * Tage_pro_Monat
Bei 1,00 Einheit pro Anfrage, 200 Anfragen am Tag und 30 Tagen kommst du auf 6.000 Einheiten pro Monat – eine Beispielrechnung, die nur die getroffenen Annahmen widerspiegelt. Pauschalwerte gibt es nicht; entscheidend sind Anfragemenge, Prompt-Länge und Modellpreis.
Kann ich Token-Kosten vor dem API-Aufruf schätzen?
Ja, und zwar in zwei Schritten: erst die Token-Anzahl grob über die Wortzahl (etwa 1,3 bis 1,5 Token pro deutschem Wort) oder mit einem Tokenizer des Anbieters schätzen, dann mit dem Preis pro 1.000 Token verrechnen. Für die Ausgabe planst du eine typische Antwortlänge als Annahme ein, da du sie vorab nicht kennst. Behandle das Ergebnis als Schätzung mit Puffer und miss später die tatsächlich abgerechneten Token, um deine Annahmen zu kalibrieren.