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 siebzig 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.
Passend dazu
