Wenn Ihr OpenAI-Traffic über LiteLLM, Portkey, Kong AI Gateway oder ein internes Gateway läuft, ist Ihre Kostenzuordnung längst kaputt.
Genau dort, wo das Geld zu fließen beginnt, verschmelzen alle vorgelagerten Aufrufer zu einer einzigen Workload-Identität. Provider-Rechnungen, tagbasierte FinOps-Tools und Cloud-Kostenplattformen können diese Kosten nicht mehr sauber auf Services, Teams, Features oder Kunden zurückverteilen.
Das ist der blinde Fleck der LLM-Gateways. Er entwickelt sich rasant zu einem Kernproblem in DevOps und FinOps for AI, wo tokenbasierte Ausgaben und gemeinsam genutzte Infrastruktur klassische Modelle der Kostenzuordnung sprengen.
Es ist die am schnellsten wachsende Lücke bei der Cloud-Kostenzuordnung – und sie folgt demselben Muster, das Teams bereits von Kafka, Snowflake und anderen geteilten Systemen kennen. Der Unterschied: Die Ausgaben sind jetzt tokenbasiert, wachsen schnell und hängen direkt an der Produktnutzung.
Warum die Kette am Gateway reißt
Ein per Gateway vermittelter Call hat zwei Hops:
upstream-svc ──► llm-gateway ──► api.openai.com
Die Identität, auf die es ankommt, sitzt am ersten Hop: Service, Tenant, Feature, Kunde.
Das abrechnungsrelevante Ereignis passiert am zweiten Hop: Token-Nutzung.
Auf Provider-Rechnungen taucht nur die Gateway-Identität auf. Ist diese Verschmelzung einmal passiert, können nachgelagerte Systeme sie nicht mehr auflösen.
Jede gängige Datenquelle greift erst danach:
- Provider-Billing-Exports zeigen Kosten pro API-Key oder Projekt – nicht pro Service
- Cloud-Billing (CUR, GCP, Azure) sieht OpenAI-Kosten gar nicht oder ordnet sie weiterhin dem Gateway zu
- Tagbasierte FinOps-Tools weisen die Kosten der Ressource zu, die sie ausgelöst hat: dem llm-gateway
Das Ergebnis ist ein Sammeltopf für Shared-Infrastructure-Kosten – statt belastbarer Unit Economics.
So sieht das in der Praxis aus
| Sicht | Standard (zusammengeführt) | Was das Business braucht |
| Kosten pro Workload | llm-gateway = X $ | Aufteilung auf reale Services nach Token-Nutzung |
| Kosten pro Kunde | Shared Infra | KI-Kosten pro Kunde |
| Kosten pro Feature | KI wirkt kostenlos | Echte KI-COGS pro Feature |
| Pricing-Signal | Aggregierter Kostenanteil in % | Profitabilität auf Kundenebene |
Das ist nicht bloß ein Sichtbarkeitsproblem. Es wirkt sich direkt aus auf:
- Analyse der Kundenprofitabilität
- Pricing-Entscheidungen
- Feature-ROI
- Optimierung der Cloud-Kosten
Warum Tagging und Logs scheitern
Die meisten Teams versuchen, das Problem mit Header-Propagation und Logs zu lösen. Im Staging funktioniert das. In der Produktion nicht.
1. Propagation driftet. Neue Services, Retries oder alternative Pfade reißen Lücken in die Attribution. Mit der Zeit landet ein wachsender Anteil der Ausgaben unter "Unbekannt".
2. Logs sind kein Kostensystem. Sampling, Retention-Limits und Ingestion-Bias verzerren den Datenbestand. Logs mit Billing zu joinen wird schnell zur brüchigen Pipeline.
3. Geteilte Calls lassen sich nicht per Tag aufteilen. Retries, Batching, Caching und Fan-out-Workflows führen dazu, dass sich mehrere Aufrufer einen Provider-Request teilen. Tags können die Kosten nicht fair verteilen. Das kann nur eine Abrechnung auf Token-Ebene.
4. Logs erfassen den Negativraum nicht. Fehlgeschlagene Calls, Retries und Fallbacks erzeugen weiterhin Infrastrukturkosten, werden aber nicht vollständig abgebildet.
Deshalb kommen Teams, die geteilte Cloud-Kosten ohne Tagging über Microservices hinweg aufteilen wollen, nicht weiter. Tagging verkleinert die Lücke – schließen kann es sie nicht.
Runtime-Attribution: den Request beobachten, statt ihn zu rekonstruieren
Die einzig verlässliche Lösung: Kosten zur Laufzeit beobachten, statt sie aus Billing-Daten zu rekonstruieren.
Attribute™ nutzt einen eBPF-Sensor, der neben dem Gateway läuft und beide Seiten des Requests beobachtet:
- Erster Hop: Upstream-Service → Gateway (Identität intakt)
- Zweiter Hop: Gateway → Provider (Token-Nutzung und Kosten)
Durch die Korrelation beider Seiten lassen sich Provider-Kosten anhand des tatsächlichen Token-Verbrauchs auf den ursprünglichen Workload zurückführen.
Das ermöglicht:
- Kubernetes-Kostentransparenz nach Ursprungs-Workload
- KI-Kostenzuordnung auf Kundenebene
- KI-COGS auf Feature-Ebene
- Kostensignale in Echtzeit
- Präzise Cloud-Kostenaufteilung ohne Tagging
Implementierungsdetails, die zählen
- Read-only-Sensor
- PII und Secrets werden entfernt, bevor Daten die Umgebung verlassen
- Minimale OpenTelemetry-Events über TLS mit JWT-Authentifizierung
- Funktioniert mit bestehenden OTel-Collectors
- Keine Sidecars, keine Code-Änderungen, keine Änderungen an der Gateway-Konfiguration
Das Ergebnis: Der Sammeltopf "llm-gateway" verschwindet. Jeder OpenAI-Dollar ist einem Workload, Team, Feature und Kunden zugeordnet.
Checkliste für die Evaluierung
Wenn Sie FinOps-Tools für KI und geteilte Infrastruktur evaluieren, fragen Sie:
- Kann das Tool Gateway-Kosten ohne Tag-Propagation nach Ursprungs-Workload aufteilen?
- Kann es KI-Kosten Kunden und Features zuordnen?
- Liest es Live-Traffic oder Billing-Exports?
- Kann es geteilte Calls anteilig nach Token-Nutzung aufteilen?
- Bleibt die Telemetrie innerhalb Ihrer Umgebung?
Die meisten Tools scheitern an mehreren dieser Punkte, weil sie erst nach dem Billing-Event ansetzen.
LLM-Gateways brechen die Kostenzuordnung genau dort, wo die Ausgaben beginnen. Startet Ihr FinOps-Modell mit Billing-Daten, ist das wichtigste Signal bereits verloren. Zurückgewinnen lässt es sich nur, indem man das System zur Laufzeit beobachtet. Genau das ist der Unterschied zwischen dem bloßen Schätzen von Kosten und dem tatsächlichen Verstehen.