{"id":10406,"date":"2026-09-14T12:30:00","date_gmt":"2026-09-14T10:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10406"},"modified":"2026-09-09T13:18:42","modified_gmt":"2026-09-09T11:18:42","slug":"die-rechnung-hinter-einer-llm-abrechnung","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/cloud-ai-de\/die-rechnung-hinter-einer-llm-abrechnung\/","title":{"rendered":"Die Rechnung hinter einer LLM-Abrechnung"},"content":{"rendered":"

Die Rechnung f\u00fcr eine Anwendung, die ein Sprachmodell \u00fcber eine Schnittstelle anspricht, ist leicht zu sch\u00e4tzen und wird meist falsch gesch\u00e4tzt. Der Grund ist einfach: Gesch\u00e4tzt wird je Anfrage, bezahlt wird je Gespr\u00e4ch. Eine Anfrage ist eine Frage und eine Antwort. Ein Gespr\u00e4ch ist dieselbe Frage, mit jeder folgenden erneut geschickt.<\/p>\n

Alles Weitere – Zwischenspeicher, Stapelbetrieb, Modellwahl – ver\u00e4ndert eine Zahl, die durch diesen Bau bereits festgelegt ist. Es lohnt sich also, den Bau vor der Preisliste anzusehen.<\/p>\n

\n\"Acht
Dieselbe Systemvorgabe, achtmal bezahlt. Nur der schmale blaue Streifen ist je Runde neu.<\/figcaption><\/figure>\n

Warum ein langes Gespr\u00e4ch \u00fcberproportional teuer wird<\/h2>\n

Modelle haben zwischen zwei Aufrufen kein Ged\u00e4chtnis. Ein Gespr\u00e4ch fortzusetzen hei\u00dft 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.<\/p>\n

Die Tabelle rechnet das f\u00fcr ein Gespr\u00e4ch 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\u00f6rtern.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
Runde<\/th>\nEingabe dieser Runde<\/th>\nBis hierhin insgesamt bezahlt<\/th>\n<\/tr>\n<\/thead>\n
1<\/td>\n1.350<\/td>\n1.350<\/td>\n<\/tr>\n
2<\/td>\n1.900<\/td>\n3.250<\/td>\n<\/tr>\n
3<\/td>\n2.450<\/td>\n5.700<\/td>\n<\/tr>\n
4<\/td>\n3.000<\/td>\n8.700<\/td>\n<\/tr>\n
5<\/td>\n3.550<\/td>\n12.250<\/td>\n<\/tr>\n
6<\/td>\n4.100<\/td>\n16.350<\/td>\n<\/tr>\n
7<\/td>\n4.650<\/td>\n21.000<\/td>\n<\/tr>\n
8<\/td>\n5.200<\/td>\n26.200<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Nach acht Runden sind 26.200 Token Eingabe bezahlt, obwohl das ganze Gespr\u00e4ch am Ende nur 5.200 Token lang ist. Und die Kosten wachsen schneller als das Gespr\u00e4ch: Die doppelte Zahl an Runden, von vier auf acht, kostet nicht das Doppelte, sondern etwa das Dreifache.<\/p>\n

Von den 26.200 Token sind 21.000 Text, den das Modell schon einmal bekommen hat – vier F\u00fcnftel. Das ist das Argument f\u00fcr zwei Entscheidungen, die mit Preisen nichts zu tun haben: die Systemvorgabe kurz zu halten und ein langes Gespr\u00e4ch zusammenzufassen, statt es vollst\u00e4ndig mitzuschleppen. Beides verkleinert eine Zahl, die in jeder noch kommenden Runde erneut anf\u00e4llt.<\/p>\n

Vier Preise f\u00fcr dasselbe Token<\/h2>\n\n\n\n\n\n\n\n\n\n
Art<\/th>\nVerh\u00e4ltnis<\/th>\nWas sie im Gegenzug kostet<\/th>\n<\/tr>\n<\/thead>\n
Eingabe<\/td>\n1×<\/td>\nder Bezugswert, an dem jede weitere Zeile gemessen wird<\/td>\n<\/tr>\n
Ausgabe<\/td>\n3× bis 5×<\/td>\nnichts – sie ist schlicht die teure H\u00e4lfte<\/td>\n<\/tr>\n
Zwischenspeicher, gelesen<\/td>\netwa 0,1×<\/td>\neinen unver\u00e4nderten Anfang und eine Haltbarkeit in Minuten<\/td>\n<\/tr>\n
Zwischenspeicher, geschrieben<\/td>\netwa 1,25×<\/td>\neinmal je Eintrag zu zahlen, bevor \u00fcberhaupt etwas gespart ist<\/td>\n<\/tr>\n
Stapel<\/td>\n0,5× auf beiden Seiten<\/td>\nWartezeit: eine Antwort in Stunden statt in Sekunden<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Die Zwischenspeicherzeile hat eine Bedingung im Gep\u00e4ck. Ein Treffer verlangt einen Anfang, der einer fr\u00fcheren Anfrage bis aufs Zeichen gleicht – eine Systemvorgabe mit der aktuellen Uhrzeit darin wird also nie zwischengespeichert, und ein Gespr\u00e4ch, dessen Verlauf nachtr\u00e4glich bearbeitet wird, entwertet alles ab der \u00c4nderung. Der gemeinsame Teil muss stabil sein und er muss vorne stehen.<\/p>\n

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\u00e4gt – bei den Verh\u00e4ltnissen oben etwa zwei- bis dreimal. Eine Vorgabe, die st\u00fcndlich einmal gebraucht wird, w\u00e4hrend der Eintrag f\u00fcnf Minuten h\u00e4lt, wird jedes Mal zum Schreibpreis bezahlt.<\/p>\n

Was der Stapelrabatt tats\u00e4chlich kostet<\/h2>\n

Der halbe Preis f\u00fcr dieselbe Arbeit sieht nach der leichtesten Entscheidung der Liste aus, und das ist er auch – f\u00fcr die Arbeit, die ihn vertr\u00e4gt. Eine Stapelanfrage wird beantwortet, wenn beim Anbieter Kapazit\u00e4t frei ist; das ist ein Zeitfenster von Stunden und keine Zusage, und nichts an der Anfrage darf davon abh\u00e4ngen, dass jemand wartet.<\/p>\n

Das schlie\u00dft alles Interaktive aus und fast alles andere ein: einen R\u00fcckstand einordnen, Beschreibungen f\u00fcr einen Katalog erzeugen, ein Archiv \u00fcbersetzen, 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.<\/p>\n

Token sind keine W\u00f6rter und nicht in jeder Sprache gleich billig<\/h2>\n

Ein Token entspricht ungef\u00e4hr 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 \u00fcbersetzt merklich mehr Token als das Englische, aus dem er stammt.<\/p>\n

In einer mehrsprachigen Anwendung zeigt sich das als Kostenunterschied von drei\u00dfig bis f\u00fcnfzig 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\u00fcft hat.<\/p>\n

Die Ausgabeseite ist die, die niemand steuert<\/h2>\n

Die Ausgabe ist die teure H\u00e4lfte und die am wenigsten genau festgelegte. max_tokens<\/code> ist eine Obergrenze und kein Ziel; ein Modell, das um eine Zusammenfassung gebeten wird, erzeugt die L\u00e4nge, die es f\u00fcr angemessen h\u00e4lt, und die Anweisung, die sie k\u00fcrzt, steht in der Vorgabe und nicht in den Parametern.<\/p>\n

Zwei Gewohnheiten bewegen die Zahl mehr als alles andere. Eine strukturierte Antwort mit kurzen Feldnamen zu verlangen statt Flie\u00dftext – ein JSON-Objekt mit drei Schl\u00fcsseln kostet einen Bruchteil eines Absatzes, der dasselbe sagt. Und, wo ein Modell ausf\u00fchrliches 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 \u00fcber zweitausendvierzig abgerechnet.<\/p>\n

\n

Quellen<\/h2>\n