![\"Ein](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/tokenverbrauch-messen-de.png\")
Wo die wahre Zahl l\u00e4ngst steht<\/h2>\n
Jede Antwort einer Chat-Vervollst\u00e4ndigung tr\u00e4gt einen usage-Block. Er ist keine Sch\u00e4tzung und keine Rundung, sondern das, was der Z\u00e4hler festgehalten hat.<\/p>\n
{\n \"usage\": {\n \"input_tokens\": 12400,\n \"cache_creation_input_tokens\": 8200,\n \"cache_read_input_tokens\": 96000,\n \"output_tokens\": 1850\n }\n}<\/code><\/pre>\nDie vier Felder sind vier verschiedene Preise, und die Aufteilung wiegt schwerer als die Summe. Frisch gesendete Eingabe ist der Grundpreis. Token, die in einen Prompt-Cache geschrieben werden, kosten einmalig einen Aufschlag. Token, die daraus wieder gelesen werden, kosten einen Bruchteil des Grundpreises. Die Ausgabe ist die teuerste Klasse \u00fcberhaupt, meist ein Mehrfaches des Eingabepreises.<\/p>\n
Andere Anbieter benennen dieselben Dinge anders – prompt_tokens<\/code>, completion_tokens<\/code> und ein verschachteltes cached_tokens<\/code> sind die \u00fcbliche Alternative -, aber der Aufbau ist derselbe und die Folgerung auch: Eine einzelne Zahl mit der Beschriftung \u201eToken” l\u00e4sst sich nicht in Geld umrechnen.<\/p>\nF\u00fcr das Streaming geh\u00f6rt eine Anmerkung dazu. Der usage-Block kommt nicht mit dem ersten St\u00fcck, sondern am Ende, im Abschlussereignis des Stroms. Code, der den Text liest und den Rest verwirft, verliert also genau den Teil, der etwas kostet.<\/p>\n
Z\u00e4hlen, bevor gesendet wird<\/h2>\n
Manchmal wird die Zahl gebraucht, bevor die Anfrage existiert – um zu entscheiden, ob ein Dokument noch passt oder ob ein Gespr\u00e4ch gek\u00fcrzt werden muss. Daf\u00fcr gibt es einen Z\u00e4hlendpunkt, der kostenlos ist und zur\u00fcckgibt, was das Modell sehen w\u00fcrde.<\/p>\n
curl https:\/\/api.anthropic.com\/v1\/messages\/count_tokens \\\n -H \"x-api-key: $API_KEY\" \\\n -H \"anthropic-version: 2023-06-01\" \\\n -H \"content-type: application\/json\" \\\n -d '{\n \"model\": \"claude-sonnet-5\",\n \"messages\": [{\"role\": \"user\", \"content\": \"...\" }]\n }'<\/code><\/pre>\nEin \u00f6rtlicher Tokenizer beantwortet dieselbe Frage ohne Netzaufruf und reicht f\u00fcr eine L\u00e4ngenpr\u00fcfung, aber er ist nicht der Z\u00e4hler. Systemvorgaben, Werkzeugdefinitionen und Bildbl\u00f6cke bringen alle Token mit, die ein Texttokenizer nie sieht, und der Unterschied geht bei einer Anfrage mit angeh\u00e4ngten Werkzeugen in die Tausende. F\u00fcr ein Budget z\u00e4hlt allein der usage-Block.<\/p>\n
Eine Zeile je Anfrage<\/h2>\n
Das Protokollieren selbst ist unspektakul\u00e4r, und sein Wert liegt vollst\u00e4ndig in den Feldern, die den Zusammenhang beschreiben, nicht die Anfrage. Modell und Tokenzahlen allein beantworten nichts; eine Kennzeichnung, welche Funktion den Aufruf ausgel\u00f6st hat, beantwortet fast alles.<\/p>\n
import json, sqlite3, time, uuid\n\nDB = sqlite3.connect(\"verbrauch.db\")\nDB.execute(\"\"\"CREATE TABLE IF NOT EXISTS aufrufe (\n id TEXT PRIMARY KEY, zeit INTEGER, modell TEXT, zweck TEXT,\n ein INTEGER, cache_neu INTEGER, cache_gelesen INTEGER, aus INTEGER,\n kosten REAL, versuch INTEGER)\"\"\")\n\ndef buchen(antwort, modell, zweck, versuch=1):\n u = antwort[\"usage\"]\n zeile = dict(\n id=str(uuid.uuid4()), zeit=int(time.time()), modell=modell, zweck=zweck,\n ein=u[\"input_tokens\"],\n cache_neu=u.get(\"cache_creation_input_tokens\", 0),\n cache_gelesen=u.get(\"cache_read_input_tokens\", 0),\n aus=u[\"output_tokens\"], versuch=versuch)\n zeile[\"kosten\"] = kosten(modell, zeile)\n DB.execute(\"INSERT INTO aufrufe VALUES (:id,:zeit,:modell,:zweck,:ein,\"\n \":cache_neu,:cache_gelesen,:aus,:kosten,:versuch)\", zeile)\n DB.commit()\n return zeile[\"kosten\"]<\/code><\/pre>\nDie Spalte versuch<\/code> ist die, die sich unerwartet auszahlt. Ein Wiederholungsversuch nach einer Zeit\u00fcberschreitung sendet die ganze Eingabe erneut und wird erneut berechnet, w\u00e4hrend die Anwendung einen einzigen logischen Aufruf sieht. Ohne diese Spalte verstecken sich Wiederholungen im Mittelwert, und ein schlechter Nachmittag sieht aus wie eine teure Funktion.<\/p>\nAus Token Geld machen<\/h2>\n
Preise geh\u00f6ren an eine Stelle, je Modell und je Tokenklasse, angegeben je Million Token – denn so werden sie ver\u00f6ffentlicht.<\/p>\n
# Beispielpreise je Million Token - die echten stehen in der\n# Preisliste des Anbieters und \u00e4ndern sich \u00fcber die Zeit.\nPREISE = {\n \"claude-sonnet-5\": {\"ein\": 3.00, \"cache_neu\": 3.75, \"cache_gelesen\": 0.30, \"aus\": 15.00},\n}\n\ndef kosten(modell, z):\n p = PREISE[modell]\n return round(sum(z[k] * p[k] for k in (\"ein\", \"cache_neu\", \"cache_gelesen\", \"aus\")) \/ 1e6, 6)<\/code><\/pre>\nAuf die Anfrage von oben angewandt, ergeben die vier Klassen 0,0372, 0,0308, 0,0288 und 0,0278 – zusammen 0,1245 je Aufruf. Der aufschlussreiche Vergleich ist der dritte Wert gegen den ersten: 96 000 aus dem Zwischenspeicher gelesene Token kosten weniger als 12 400 frisch gesendete. Ein Zwischenspeicher, der greift, senkt also nicht nur die Rechnung, sondern verschiebt auch, welcher Teil der Anfrage sie bestimmt.<\/p>\n
Liegen ein paar Tage Zeilen in der Tabelle, l\u00e4sst sich die eigentliche Frage mit einer Anweisung beantworten.<\/p>\n
SELECT zweck,\n COUNT(*) AS aufrufe,\n ROUND(SUM(kosten), 2) AS gesamt,\n ROUND(AVG(kosten), 4) AS je_aufruf,\n ROUND(100.0 * SUM(cache_gelesen) \/\n NULLIF(SUM(ein + cache_neu + cache_gelesen), 0), 1) AS cache_anteil\nFROM aufrufe\nWHERE zeit >= strftime('%s', 'now', 'start of month')\nGROUP BY zweck ORDER BY gesamt DESC;<\/code><\/pre>\nDie Sperre, die wirklich etwas aufh\u00e4lt<\/h2>\n
Ein Budget, das nur warnt, ist ein Bericht. Aufhalten setzt voraus, dass die Pr\u00fcfung vor dem Aufruf steht – und dass die Zahl aktuell ist statt von letzter Nacht.<\/p>\n
class BudgetErschoepft(Exception):\n pass\n\nMONATSBUDGET = 400.0\nWARNSCHWELLE = 0.80\n\ndef monatssumme():\n (s,) = DB.execute(\n \"SELECT COALESCE(SUM(kosten), 0) FROM aufrufe \"\n \"WHERE zeit >= strftime('%s', 'now', 'start of month')\").fetchone()\n return s\n\ndef pruefen(geschaetzte_kosten):\n verbraucht = monatssumme()\n if verbraucht + geschaetzte_kosten > MONATSBUDGET:\n raise BudgetErschoepft(f\"{verbraucht:.2f} von {MONATSBUDGET:.2f} verbraucht\")\n if verbraucht > MONATSBUDGET * WARNSCHWELLE:\n logging.warning(\"Budget zu %.0f %% verbraucht\", 100 * verbraucht \/ MONATSBUDGET)<\/code><\/pre>\nDrei Entscheidungen machen daraus mehr als eine Formalit\u00e4t. Die \u00fcbergebene Sch\u00e4tzung sollte die pessimistische sein – h\u00f6chstm\u00f6gliche Ausgabetoken zum Ausgabepreis -, denn ein Aufruf ist entweder erlaubt oder nicht, und eine Erlaubnis auf optimistischer Grundlage ist der Weg, ein Budget um genau eine Anfrage zu \u00fcberschreiten.<\/p>\n
Die zweite betrifft das, was nach der Ausnahme geschieht. Ein Stapellauf sollte anhalten und sagen, wo er angehalten hat. Eine Funktion im Dialog sollte nachgeben statt zu scheitern: ein kleineres Modell, ein k\u00fcrzerer Zusammenhang oder eine Warteschlange, die im n\u00e4chsten Monat weiterl\u00e4uft. Beides ist besser als ein Fehlerbericht, der bis zum Leser durchschl\u00e4gt.<\/p>\n
Die dritte: Ein geteiltes Budget braucht einen geteilten Z\u00e4hler. Mehrere Prozesse mit je eigener Summe bleiben jeder f\u00fcr sich unter der Grenze und \u00fcberschreiten sie gemeinsam. Eine einzige Tabelle mit einer Transaktion um Lesen und Schreiben, oder ein Z\u00e4hler in einem gemeinsamen Speicher, ist die ganze Abhilfe.<\/p>\n
Was die Sperre nicht sieht<\/h2>\n
Drei Arten von Ausgaben laufen nie durch die Pr\u00fcfung, und jede hat ihren eigenen Weg, doch erfasst zu werden.<\/p>\n
Die Stapelverarbeitung wird mit Rabatt berechnet und l\u00e4uft oft im Hintergrund, sodass der usage-Block Stunden sp\u00e4ter mit den Ergebnissen eintrifft. Diese Kosten geh\u00f6ren in dieselbe Tabelle, eingetragen beim Abholen der Ergebnisse, aber mit dem Zeitpunkt der Einreichung – sonst landet die Ausgabe an einer Monatsgrenze im falschen Monat.<\/p>\n
Fehlgeschlagene Anfragen sind der zweite Fall. Ein Aufruf, der in eine Zeit\u00fcberschreitung l\u00e4uft, nachdem das Modell den gr\u00f6ssten Teil seiner Antwort bereits erzeugt hat, wird trotzdem berechnet und liefert keinen usage-Block zum Auslesen. Was er liefert, ist eine Anfragekennung in den Antwort-Headern, und der Verbrauchsbericht des Anbieters f\u00fchrt sie. Ein monatlicher Abgleich zwischen der eigenen Tabelle und diesem Bericht kostet zehn Minuten und findet genau diese Klasse von Abweichung.<\/p>\n
Der dritte Fall ist alles, was keine Chat-Vervollst\u00e4ndigung ist: Einbettungen, Transkriptionen, Bilderzeugung, ein serverseitig aufgerufenes Suchwerkzeug. Jedes hat seinen eigenen Z\u00e4hler und seinen eigenen Preis, und keines davon taucht im hier protokollierten usage-Block auf. Der Abgleich f\u00e4ngt auch diese ein – und das ist der praktische Grund, ihn \u00fcberhaupt zu f\u00fchren.<\/p>\n