Die Rechnung hinter einer LLM-Abrechnung

Inhalt
Die Rechnung für eine Anwendung, die ein Sprachmodell über eine Schnittstelle anspricht, ist leicht zu schätzen und wird meist falsch geschätzt. Der Grund ist einfach: Geschätzt wird je Anfrage, bezahlt wird je Gespräch. Eine Anfrage ist eine Frage und eine Antwort. Ein Gespräch ist dieselbe Frage, mit jeder folgenden erneut geschickt.
Alles Weitere – Zwischenspeicher, Stapelbetrieb, Modellwahl – verändert eine Zahl, die durch diesen Bau bereits festgelegt ist. Es lohnt sich also, den Bau vor der Preisliste anzusehen.

Warum ein langes Gespräch überproportional teuer wird
Modelle haben zwischen zwei Aufrufen kein Gedächtnis. Ein Gespräch fortzusetzen heißt deshalb, den gesamten bisherigen Verlauf noch einmal mitzuschicken. In der zweiten Runde wird die erste Frage samt Antwort erneut bezahlt, in der dritten die ersten beiden, und so weiter.
Die Tabelle rechnet das für ein Gespräch durch, in dem die Systemvorgabe 1200 Token lang ist, jede Frage 150 und jede Antwort 400. Token sind grob gesagt Wortteile; hundert Token entsprechen etwa fünfundsiebzig Wörtern.
| Runde | Eingabe dieser Runde | Bis hierhin insgesamt bezahlt |
|---|---|---|
| 1 | 1.350 | 1.350 |
| 2 | 1.900 | 3.250 |
| 3 | 2.450 | 5.700 |
| 4 | 3.000 | 8.700 |
| 5 | 3.550 | 12.250 |
| 6 | 4.100 | 16.350 |
| 7 | 4.650 | 21.000 |
| 8 | 5.200 | 26.200 |
Nach acht Runden sind 26.200 Token Eingabe bezahlt, obwohl das ganze Gespräch am Ende nur 5.200 Token lang ist. Und die Kosten wachsen schneller als das Gespräch: Die doppelte Zahl an Runden, von vier auf acht, kostet nicht das Doppelte, sondern etwa das Dreifache.
Von den 26.200 Token sind 21.000 Text, den das Modell schon einmal bekommen hat – vier Fünftel. Das ist das Argument für zwei Entscheidungen, die mit Preisen nichts zu tun haben: die Systemvorgabe kurz zu halten und ein langes Gespräch zusammenzufassen, statt es vollständig mitzuschleppen. Beides verkleinert eine Zahl, die in jeder noch kommenden Runde erneut anfällt.
Vier Preise für dasselbe Token
| Art | Verhältnis | Was sie im Gegenzug kostet |
|---|---|---|
| Eingabe | 1× | der Bezugswert, an dem jede weitere Zeile gemessen wird |
| Ausgabe | 3× bis 5× | nichts – sie ist schlicht die teure Hälfte |
| Zwischenspeicher, gelesen | etwa 0,1× | einen unveränderten Anfang und eine Haltbarkeit in Minuten |
| Zwischenspeicher, geschrieben | etwa 1,25× | einmal je Eintrag zu zahlen, bevor überhaupt etwas gespart ist |
| Stapel | 0,5× auf beiden Seiten | Wartezeit: eine Antwort in Stunden statt in Sekunden |
Die Zwischenspeicherzeile hat eine Bedingung im Gepäck. Ein Treffer verlangt einen Anfang, der einer früheren Anfrage bis aufs Zeichen gleicht – eine Systemvorgabe mit der aktuellen Uhrzeit darin wird also nie zwischengespeichert, und ein Gespräch, dessen Verlauf nachträglich bearbeitet wird, entwertet alles ab der Änderung. Der gemeinsame Teil muss stabil sein und er muss vorne stehen.
Der Schreibpreis ist der Grund, warum sich das Zwischenspeichern kurzer Vorgaben nicht lohnt. Schreiben kostet mehr als Senden, ein Eintrag muss also mehrfach gelesen werden, bevor er sich trägt – bei den Verhältnissen oben etwa zwei- bis dreimal. Eine Vorgabe, die stündlich einmal gebraucht wird, während der Eintrag fünf Minuten hält, wird jedes Mal zum Schreibpreis bezahlt.
Was der Stapelrabatt tatsächlich kostet
Der halbe Preis für dieselbe Arbeit sieht nach der leichtesten Entscheidung der Liste aus, und das ist er auch – für die Arbeit, die ihn verträgt. Eine Stapelanfrage wird beantwortet, wenn beim Anbieter Kapazität frei ist; das ist ein Zeitfenster von Stunden und keine Zusage, und nichts an der Anfrage darf davon abhängen, dass jemand wartet.
Das schließt alles Interaktive aus und fast alles andere ein: einen Rückstand einordnen, Beschreibungen für einen Katalog erzeugen, ein Archiv übersetzen, Felder aus einem Stapel Dokumente ziehen. Die brauchbare Gewohnheit ist, die Arbeit danach zu sortieren, ob gerade ein Mensch auf den Bildschirm sieht – denn diese Frage entscheidet, welcher der beiden Preise gilt, und nicht das Modell und nicht die Vorgabe.
Token sind keine Wörter und nicht in jeder Sprache gleich billig
Ein Token entspricht ungefähr vier Zeichen englischen Textes, ein Wort also etwa 1,3 Token. Deutsch und Polnisch schneiden schlechter ab: Zusammensetzungen, Beugungen und Zeichen mit Diakritika zerfallen in mehr Teile, und derselbe Satz kostet übersetzt merklich mehr Token als das Englische, aus dem er stammt.
In einer mehrsprachigen Anwendung zeigt sich das als Kostenunterschied von dreißig bis fünfzig Prozent je Sprache bei gleichem Inhalt, und zwar in beide Richtungen – die Vorgabe kostet mehr und die Antwort ebenfalls. Es ist kein Grund, etwas anders zu machen; es ist ein Grund, je Sprache zu messen, statt einmal zu messen und zu multiplizieren – denn so wird ein Budget genau in den zwei Sprachen knapp, mit denen niemand geprüft hat.
Die Ausgabeseite ist die, die niemand steuert
Die Ausgabe ist die teure Hälfte und die am wenigsten genau festgelegte. max_tokens ist eine Obergrenze und kein Ziel; ein Modell, das um eine Zusammenfassung gebeten wird, erzeugt die Länge, die es für angemessen hält, und die Anweisung, die sie kürzt, steht in der Vorgabe und nicht in den Parametern.
Zwei Gewohnheiten bewegen die Zahl mehr als alles andere. Eine strukturierte Antwort mit kurzen Feldnamen zu verlangen statt Fließtext – ein JSON-Objekt mit drei Schlüsseln kostet einen Bruchteil eines Absatzes, der dasselbe sagt. Und, wo ein Modell ausführliches Nachdenken beherrscht, im Kopf zu behalten, dass auch diese Token als Ausgabe abgerechnet werden: Eine Anfrage, die nach zweitausend Token Nachdenken vierzig Token Antwort liefert, wird über zweitausendvierzig abgerechnet.
Fragen und Antworten
Wie viel spart ein Zwischenspeicher im Gespräch aus der ersten Tabelle?
Rund zwei Drittel der Eingabekosten, sofern jede Runde innerhalb der Haltbarkeit des Eintrags folgt. Angenommen ist, dass jede Anfrage bis zu ihrem Ende zwischengespeichert wird. Die Runden 2 bis 8 lesen dann jeweils die komplette vorherige Anfrage aus dem Zwischenspeicher und schreiben nur das Neue hinzu: die letzte Antwort und die neue Frage, zusammen 550 Token.
Gerechnet in Vielfachen des Eingabepreises, mit den Verhältnissen aus der zweiten Tabelle:
- Runde 1 schreibt 1.350 Token zum Schreibpreis: 1.350 × 1,25 = 1.687,5.
- Die Runden 2 bis 8 lesen zusammen 21.000 Token, genau den Anteil, den das Modell schon einmal bekommen hat: 21.000 × 0,1 = 2.100.
- Dieselben Runden schreiben siebenmal 550 Token: 3.850 × 1,25 = 4.812,5.
Zusammen ergibt das 8.600 statt 26.200, knapp ein Drittel. Die Rechnung kippt, sobald zwischen zwei Runden mehr Zeit vergeht, als der Eintrag hält: Dann wird der ganze Verlauf erneut zum Schreibpreis bezahlt, und diese Runde kostet mehr als ganz ohne Zwischenspeicher. Ähnliches gilt für die erste Runde nach einer Zusammenfassung, denn die Zusammenfassung ändert den Verlauf und entwertet damit alles ab der Änderung; der gekürzte Verlauf wird einmal zum Schreibpreis bezahlt. Die Ausgabe bleibt von alldem unberührt.
Wird das Verhältnis bei noch längeren Gesprächen noch ungünstiger?
Ja. Mit den Zahlen der Tabelle kosten 16 Runden 87.600 Token Eingabe, das 3,3-Fache von acht Runden, und mit jeder weiteren Verdopplung nähert sich der Faktor dem Vierfachen. Der Grund: Die Summe über alle Runden wächst mit dem Quadrat der Rundenzahl, während der Teil, der in jeder Runde gleich anfällt, vor allem die Systemvorgabe, nur linear wächst und dadurch an Gewicht verliert.