Kosten und Latenz für Modellaufrufe in einem Agenten budgetieren

Ziel

Vor dem Einsatz wissen, was ein Lauf des Agenten kostet und wie lange eine nutzende Person wartet, beides innerhalb von im Code durchgesetzten Grenzen halten und erkennen, wann eine Änderung eine der beiden Grössen verschiebt.

Voraussetzungen

Die Nutzungsfelder je Aufruf, die der Anbieter zurückgibt (Input-Token, Output-Token, Cache-Lese- und -Schreibzugriffe); die semantischen OpenTelemetry-GenAI-Konventionen (in Entwicklung, in einem eigenen Repository gepflegt; die Registry-Seite auf opentelemetry.io führt sie als verschoben) benennen sie gen_ai.usage.input_tokens, gen_ai.usage.output_tokens und gen_ai.usage.cache_read.input_tokens. Eine Preisliste für die verwendeten Modelle sowie wiederabspielbare Laufprotokolle, um Kosten den einzelnen Schritten zuzuordnen.

Schritte

1. Eine Baseline am Evaluationsdatensatz messen: je Lauf die Anzahl der Modellaufrufe, die gesamten Input- und Output-Token, die Realzeit und den längsten einzelnen Aufruf.
2. Budgets je Lauf festlegen: eine Token-Obergrenze, eine Schritt-Obergrenze und eine Frist. Diese in der Schleife durchsetzen; wird ein Budget erreicht, erhält der Agent einen letzten Zug, um zu berichten, was erledigt ist und was nicht.
3. Zuerst Input-Token kürzen. Systemprompt, Werkzeugdefinitionen und Referenzdokumente an den Anfang der Anfrage stellen und für das Caching markieren. Die Anbieterdokumentation beschreibt cache_control-Haltepunkte mit einer Lebensdauer von 5 Minuten oder 1 Stunde, meldet Treffer in cache_read_input_tokens und hält fest, dass eine Änderung an einem Block bei oder vor dem Haltepunkt einen anderen Hash erzeugt; Zeitstempel und anfragespezifische Werte hinter dem gecachten Prefix behalten.
4. Output-Token kürzen: nach der kürzesten Ausgabe fragen, die der nächste Schritt verarbeiten kann (ein Werkzeugaufruf, eine Kennung, strukturierte Daten), keine Erzählform.
5. Den Kontext straffen: alte Werkzeugergebnisse löschen oder zusammenfassen, statt sie bei jedem Schritt erneut zu senden.
6. Offline-Arbeit (Evaluationsläufe, nächtliche Extraktion) an einen Batch-Endpunkt leiten. Die zitierte Batch-Dokumentation hält fest, dass Batch-Nutzung zu 50 % der Standard-API-Preise berechnet wird und dass Batches ablaufen, wenn die Verarbeitung nicht innerhalb von 24 Stunden abgeschlossen ist.
7. Für Schritte, bei denen der Evaluationsrahmen zeigt, dass ein kleineres Modell besteht, dieses verwenden; das grössere Modell dort behalten, wo der Evaluationsrahmen zeigt, dass es gebraucht wird.
8. Auf Kosten je abgeschlossener Aufgabe und auf p95-Latenz alarmieren, nicht nur auf die Gesamtausgaben; ein günstigeres Modell, das mehr Wiederholungen braucht, ist nicht günstiger.

Erwartetes Ergebnis

Dokumentierte Kosten und Latenz je Aufgabentyp, im Code durchgesetzte Budgets und ein Dashboard, in dem eine Prompt-Änderung, die den Token-Verbrauch verdoppelt, noch am selben Tag sichtbar wird.

Grenzen und Prüfbasis

Preise, Cache-Lebensdauern und Batch-Bedingungen stammen vom Anbieter und ändern sich; die obigen Zahlen sind zum Zeitpunkt der Abfassung aus der zitierten Dokumentation entnommen. Batch-Verarbeitung eignet sich nicht für interaktive Nutzung. Budgets stoppen ausufernde Läufe, machen einen Lauf aber nicht günstiger; das leisten nur die Schritte 3 bis 7.