LLM-Tokenkosten pro Anfrage berechnen
Produktionsleitfaden: LLM-Tokenkosten pro Anfrage berechnen. Enthalten sind ein deterministisches Artefakt, Fehlergrenzen, Rollout-Prüfungen und belegte Einschränkungen.
Produktionsleitfaden: LLM-Tokenkosten pro Anfrage berechnen. Enthalten sind ein deterministisches Artefakt, Fehlergrenzen, Rollout-Prüfungen und belegte Einschränkungen.
Entscheidung zuerst
LLM-Tokenkosten pro Anfrage berechnen ist ein expliziter Produktionsvertrag und keine isolierte Änderung. Erfolg, Endfehler und Rollback müssen vor einer Traffic-Änderung feststehen; das Artefakt trennt Beleg und Annahme.
Beginnen Sie mit usage_source, belegen Sie input deterministisch und machen Sie settlement zum Release-Gate.
Wiederverwendbares Artefakt
Eine Zeile gilt nur, wenn der Beleg aus derselben Anfrage, demselben Testfenster oder derselben Konfigurationsversion stammt.
| Prüfpunkt | Zu erfassender Beleg | Bestanden wenn |
|---|---|---|
usage_source |
provider_usage_or_named_normalization_rule |
Owner, Quelle, Datum und Grenze sind dokumentiert. |
input |
uncached_input_tokens_after_category_separation |
Der Wert bleibt an der Wire-Grenze exakt erhalten. |
cache |
cache_read_and_cache_write_token_categories |
Der Wert bleibt an der Wire-Grenze exakt erhalten. |
output |
visible_and_reasoning_output_under_the_owned_price_rule |
Der Wert bleibt an der Wire-Grenze exakt erhalten. |
formula |
versioned_coefficients_in_currency_per_one_million_tokens |
Owner, Quelle, Datum und Grenze sind dokumentiert. |
settlement |
reserve->actual_usage->idempotent_final_charge/refund |
Reservierung, Messung und Endwert stimmen im dauerhaften Ledger überein. |
Durchgerechnetes Beispiel
Das Beispiel ist synthetisch und deterministisch. Verwenden Sie geprüfte eigene Werte und niemals Secrets oder Kundendaten.
input_tokens = 1200
cache_read_tokens = 800
cache_write_tokens = 0
output_tokens = 300
cost = (input_tokens * input_rate
+ cache_read_tokens * cache_read_rate
+ cache_write_tokens * cache_write_rate
+ output_tokens * output_rate) / 1_000_000
round_at = owned_currency_or_quota_boundary
Umsetzungsverfahren
- Aktuelle Anfrage, Antwort, Konfiguration und Messbasis einfrieren.
- Einen deterministischen Positivfall vollständig erfassen.
- Den passenden Negativ- oder Grenzfall ausführen.
- Alle Versuche über eine logische Request-ID verbinden und Zeit, Endzustand sowie Nutzung ohne sensible Inhalte erfassen.
- Nur in einer begrenzten Kohorte mit Abbruchbedingungen ausrollen.
- Dauerhaften Zustand und öffentliches Verhalten erneut lesen; bei verletzter Invariante zurückrollen.
Fehlermodi
Diese Fehler machen das Ergebnis ungültig, auch wenn der äußere HTTP-Aufruf erfolgreich wirkt:
- Ein volatiler Preis oder Vertrag wird nicht neu geprüft.
- Ohne atomare Reservierung überschreiten parallele Anfragen das Limit.
- Ein Komfortfeld wird gelesen, typisierte Outputs, Tools, Ablehnungen oder Teilergebnisse gehen verloren.
- Geteilte Kosten werden so verteilt, dass die Gesamtsumme nicht mehr stimmt.
Modelflare-Grenze
Modelflare bündelt OpenAI-kompatibles Routing, Schlüssel, Gruppen, Nutzung und Fehlerbehandlung. Eine konfigurierte Route beweist jedoch keine optionale Provider-Fähigkeit. Modell und Kanal nativ prüfen, explizite Nullwerte erhalten und nur die dauerhafte Abrechnung als Billing-Wahrheit verwenden.
Die übergeordnete Anleitung beschreibt die Entscheidungsgrenze, die Dokumentation die aktuelle Client-Konfiguration.
Checkliste vor Veröffentlichung
- Kernfrage vor dem Hintergrund beantworten.
- Jedem Feld, Zustand, Messwert und jeder Formel einen Owner geben.
- Nur synthetische Kennungen verwenden.
- Struktur, Code, Grenzen und Hinweise in allen Sprachen erhalten.
- Verträge, Support und Preise an T-1 neu prüfen; bei Änderung verschieben.
- Vor dem Termin aus Public API, Routen und Sitemap ausschließen.
Quellen und Prüfdatum
Quellen geprüft am 2026-08-07; sie beweisen keine ungetestete Route.