Token-Kosten im Blick behalten
Sprachmodelle über eine Cloud-API kosten pro Token. Das ist bequem, weil man keine GPU kaufen und keinen Server betreiben muss – aber es ist auch die undurchsichtigste Kostenstelle, die ich je hatte. Eine Rechnung am Monatsende sagt dir nur eine Zahl. Sie sagt dir nicht, welcher Job das Geld frisst, welches Modell teuer ist und ob der Verbrauch gerade still und leise steigt.
Also habe ich angefangen zu messen. Nicht mit einem fertigen Tool, sondern mit einem kleinen Python-Skript, das die Nutzungsdaten der API abzieht und in eine Datei schreibt. Ein zweites Skript rechnet daraus, welcher geplante Job wie viele Token verbraucht. Ein drittes schaut sich die Historie an. Zusammen sind das vielleicht 200 Zeilen – und sie haben mir mehr über meine Kosten gesagt als jede Rechnung.
Was ich messe
Drei Zahlen pro Modell und pro Job: Eingabe-Token, Ausgabe-Token, und daraus der Preis. Die Preise unterscheiden sich je nach Modell deutlich, und ein großes Modell mit langem Kontext ist nicht einfach „besser", sondern vor allem teurer. Wer den Verbrauch nicht aufschlüsselt, sieht nur den Gesamtbetrag und kann nicht sagen, ob der gerechtfertigt ist.
Die Aufschlüsselung nach Job war der eigentliche Augenöffner. Ein einzelner geplanter Job – ein Heartbeat, der regelmäßig den Zustand meiner Dienste prüft – machte fast die Hälfte meines gesamten Verbrauchs aus. Nicht weil er kompliziert wäre, sondern weil er häufig lief und jedes Mal einen langen Kontext mit sich herumschleppte.
Was ich geändert habe
Drei Stellschrauben, in dieser Reihenfolge:
- Frequenz runter. Der Heartbeat lief alle 15 Minuten. Er läuft jetzt stündlich. Die Information, die er liefert, ist nach einer Stunde genauso wertvoll wie nach einer Viertelstunde – der Verbrauch ist ein Viertel.
- Kleineres Modell für Routine. Nicht jede Aufgabe braucht das größte Modell. Für einfache, wiederkehrende Jobs reicht ein kleineres, schnelleres Modell mit großem Kontextfenster. Die Umstellung hat den Verbrauch dieser Jobs um gut die Hälfte gesenkt, ohne dass die Ergebnisse schlechter wurden.
- Alarm statt Bericht. Ein täglicher Check meldet sich nur, wenn der Verbrauch über eine Schwelle steigt. Stille bedeutet: alles im Rahmen. Ein wöchentlicher Bericht fasst die Zahlen zusammen, damit ich den Trend sehe, ohne jeden Tag darauf schauen zu müssen.
Was ich gelernt habe
Der wichtigste Satz ist derselbe wie beim Monitoring: erst messen, dann optimieren. Vor der Messung hätte ich nicht sagen können, welcher Job teuer ist. Ich hätte vermutlich am falschen Ende gespart – am Modell, das ich selten nutze, statt an dem Job, der ständig läuft.
Der zweite Punkt: Token-Verbrauch ist keine statische Größe. Ein Job, der heute sparsam ist, kann morgen teuer werden, weil sich sein Kontext vergrößert oder weil jemand ein größeres Modell dranhängt. Deshalb ist das Tracking ein geplanter Job, kein einmaliges Projekt. Die Skripte laufen von selbst, und ich schaue nur noch auf die Ausreißer.
Der dritte Punkt ist der unbequemste: Die größte Kostenquelle war nicht ein Fehler im Code, sondern eine Entscheidung, die ich selbst getroffen hatte – ein Job, der zu oft lief, mit einem Modell, das zu groß war. Messen heißt auch, sich selbst beim Sparen zuzuschauen. Das ist der Teil, den kein Tool für dich übernimmt.