KI-Kostenverteilung ordnet die Kosten der Modellnutzung dem Feature, der Umgebung, dem Team oder dem Kunden zu, der sie verursacht hat: über die Dimensionen, die der Anbieter mitschreibt (Projekt, Workspace, API-Schlüssel, Deployment, Inference-Profil, IAM-Prinzipal, Label), und darunter über die eigenen Aufzeichnungen der Anwendung zu jeder Anfrage. Die allgemeine Methode aus direkten Kosten, verteilten geteilten Kosten und sichtbarem Rest beschreibt Kosten je Kunde, Feature und Umgebung. Speziell an KI ist, dass die feinste verfügbare Dimension davon abhängt, wo das Modell gekauft wird, und von einer Entscheidung vor der ersten Anfrage: unter welchem Schlüssel, Projekt oder Profil sie läuft.
So funktioniert es
Welche Exporte die Anbieter liefern und wie fein, beschreibt Nutzungs- und Kostenexporte der KI-Anbieter; hier geht es um die Dimensionen, an denen eine Zuordnung hängen kann.
OpenAI
Eine Organisation gliedert sich in Projekte, und der Kosten-Endpunkt gruppiert Tageskosten nach Projekt, Nutzer, Position, API-Schlüssel und API-Quelle. OpenAI schlägt getrennte Projekte für Staging und Produktion vor, mit eigenen Rate- und Ausgabenlimits je Projekt. Eine Anfrage kann bis zu 16 Schlüssel-Wert-Paare als metadata tragen, die am gespeicherten Objekt abrufbar sind; der Kosten-Endpunkt gruppiert nicht danach. Das Feld safety_identifier dient der Missbrauchserkennung, nicht der Kostenrechnung.
Anthropic
Die Organisation gliedert sich in Workspaces, standardmäßig bis zu 100. Ein API-Schlüssel kann auf einen Workspace beschränkt sein, und Nutzungs- und Kostenberichte zeigen die Workspace-ID. Der Default-Workspace und Schlüssel für alle Workspaces erscheinen dort ohne Workspace-ID. Für Claude Code legt Anthropic einen eigenen Workspace mit einem Schlüssel je Person an. metadata.user_id nimmt eine undurchsichtige Kennung für die Missbrauchserkennung auf.
AWS
Amazon Bedrock bietet zwei Wege. Ein Application Inference Profile mit Tags macht On-Demand-Aufrufe über dieses Profil als Tags zur Kostenzuordnung auswertbar. Der zweite Weg ist die Zuordnung nach IAM-Prinzipal: Mit der Option für Aufruferidentitäten im Standard-Export von CUR 2.0 steht in line_item_iam_principal je Bedrock-Aufruf der aufrufende Nutzer oder die Rolle, und Tags an diesen Prinzipalen erscheinen mit dem Präfix iamPrincipal/. In beiden Fällen muss der Tag-Schlüssel in der Billing-Konsole aktiviert werden: bis zu 24 Stunden, bis er dort erscheint, und bis zu 24 weitere bis zur Aktivierung. Tags eines Prinzipals erscheinen erst, nachdem er mindestens einen Aufruf gemacht hat, und der Export wächst um eine Zeile je aufrufender Identität und Modell.
Azure
In Microsoft Foundry erscheinen Azure OpenAI und Microsofts eigene Modelle als Zähler unter der jeweiligen Foundry-Ressource, Modelle von Partnern unter der Ressourcengruppe. Die Kostenanalyse lässt sich nach Deployment-Tags und eigenen Tags filtern. Als Vorschau versieht Foundry die Nutzung jedes Projekts automatisch mit einem Tag project, sodass sich eine geteilte Ressource je Projekt aufteilen lässt; das gilt für von Azure verkaufte Modelle, noch nicht für Modelle über Azure Marketplace.
Google Cloud
Bei der Gemini API gehören Schlüssel zu Google-Cloud-Projekten, und die Kosten erscheinen je Projekt in Cloud Billing. Die Gemini Enterprise Agent Platform nimmt zusätzlich Labels je Aufruf an, die an Cloud Billing weitergegeben werden: bis zu 64 je Aufruf für Google-Modelle, 32 für unterstützte Partnermodelle. Jeder Label-Schlüssel darf über die Lebensdauer des Rechnungskontos höchstens 1.000 verschiedene Werte haben, sonst kann er ohne Hinweis verworfen werden. Für Partnermodelle (derzeit Anthropic und Mistral AI) gibt Google Labels nur bei Pay-as-you-go-Aufrufen an Cloud Billing weiter; über Provisioned Throughput fallen sie ohne Fehlermeldung weg.
| Kauf | Feinste Einheit beim Anbieter | Gelangt in die Kostendaten | Grenze |
|---|---|---|---|
| OpenAI direkt | Projekt, API-Schlüssel, Nutzer | Kosten-Endpunkt, täglich | keine Gruppierung nach metadata |
| Anthropic direkt | Workspace, API-Schlüssel | Kostenbericht nach Workspace, täglich | Default-Workspace ohne ID |
| Amazon Bedrock | Inference-Profil, IAM-Prinzipal | CUR 2.0 mit aktivierten Tags | nur Aufrufe über das Profil oder mit aktivierter Option |
| Microsoft Foundry | Ressource, Deployment-Tag, Projekt | Azure-Kostendaten | Projekt-Tag nicht für Marketplace-Modelle |
| Agent Platform | Projekt, Label je Aufruf | Cloud Billing | 1.000 Werte je Schlüssel; Partnermodelle nicht über Provisioned Throughput |
Je Kunde
Keiner dieser Anbieter kennt die Kunden der Anwendung. Jede Antwort enthält aber ihre Token nach Art (bei OpenAI Eingabe, gecachte und in den Cache geschriebene Eingabe, Ausgabe und darin Reasoning; bei Anthropic Eingabe, Cache-Schreiben, Cache-Lesen und Ausgabe) und eine Anfrage-ID. Schreibt die Anwendung je Anfrage Kunde, Feature, Modell, Token nach Art und Anfrage-ID mit, ergeben sich die Kosten je Kunde aus Token mal Satz der Preisliste je Art. Die Summe aller Kunden wird gegen die Tageskosten des Projekts, Workspaces oder Profils abgeglichen; was fehlt, bleibt als nicht zugeordneter Rest sichtbar.
Geteilte KI-Kosten
Ein Gateway, ein Cache, ein Vektorspeicher, eine Evaluierungs-Pipeline oder reservierte Kapazität dienen mehreren Features. Sie werden nach einer Verteilungsregel aufgeteilt, etwa nach Token oder Anfragen je Feature aus demselben Zeitraum; Geteilte Kosten und wie man sie verteilt beschreibt die Schlüssel.
Was es für Ihre Kosten bedeutet
Die Einheit, die ohne Code auskommt, ist ein eigenes Projekt, ein eigener Workspace, ein eigenes Inference-Profil oder ein eigenes Deployment je Feature und Umgebung. Eine Anfrage wird dort verbucht, wo sie lief; wer diese Wahl beim Bau des Features trifft, hat die Zuordnung ab dem ersten Tag. Warum Kostenzuordnung vor jeder Optimierung kommt, beschreibt Warum Kostenzuordnung vor Optimierung kommt.
Kosten je Kunde aus den Protokollen der Anwendung sind eine Rekonstruktion, keine Rechnung. Sie treffen die Rechnung nur, wenn die Protokolle dieselben Sätze verwenden wie der Anbieter: Batch, Cache und ein Aufschlag für Datenresidenz ändern den Satz je Token, und bei Anthropic multiplizieren sie sich. Der Abgleich gegen die Tageskosten zeigt, wie groß die Lücke ist, und eine Lücke, die von Monat zu Monat wächst, deutet auf einen Satz, den die Protokolle nicht kennen.
Erst die Zuordnung macht die nächsten Schritte möglich. Die Kosten pro Ergebnis eines Features brauchen seine Kosten als Zähler, und ein Limit je Feature setzt voraus, dass das Feature einen eigenen Rahmen hat, an dem ein Limit hängen kann. Wie die Methode für SaaS im Ganzen aussieht, zeigen die Artikel Cloud-Kosten pro Kunde im SaaS und Multi-Tenant-Kosten verteilen.
Wo es schiefgeht
- Ein Schlüssel für alles. Alle Features stehen in einer Zeile. Ursache: Der Anbieter schreibt Projekt und Schlüssel mit, nicht das Feature; Details in Abrechnung der KI-Anbieter.
- Tags gesetzt, aber nicht aktiviert. Das Inference-Profil oder die Rolle trägt einen Tag, der Kostenbericht zeigt ihn nicht. Ursache: Der Tag-Schlüssel wurde in der Billing-Konsole nicht als Kostenzuordnungs-Tag aktiviert, oder der Prinzipal hat noch keinen Aufruf gemacht.
- Aufrufe am Profil vorbei. Ein Teil der Bedrock-Kosten bleibt ohne Tag. Ursache: Ein Dienst ruft das Modell direkt auf statt über das Application Inference Profile.
- Kunden-ID ohne Token. Das Protokoll zählt Anfragen je Kunde, aber die Kosten passen nicht. Ursache: Anfragen kosten je nach Kontext und Ausgabe sehr Verschiedenes; ohne Token nach Art lässt sich der Preis nicht anwenden.
- Wiederholungen und Fehler fehlen. Die Kunden ergeben zusammen weniger als die Rechnung. Ursache: Protokolliert wird nur die letzte, erfolgreiche Antwort. Microsoft weist darauf hin, dass der HTTP-Status allein nicht entscheidet, ob eine Anfrage berechnet wird.
- Ein Label je Kunde. Ab einer bestimmten Kundenzahl fehlt das Label in den Kosten. Ursache: Mehr als 1.000 Werte je Label-Schlüssel kann Google verwerfen; Labels taugen für Features und Umgebungen, nicht für Kunden.
Quellen
Gelesen am 2026-10-16. OpenAI Production best practices, Costs-Endpunkt und Responses API: Antwort erstellen; Anthropic Workspaces, Preise, Messages API und Fehler und Anfrage-IDs; AWS Inference-Profile, Kostenzuordnung nach IAM-Prinzipal und Aktivieren von Kostenzuordnungs-Tags; Microsoft Kosten in Microsoft Foundry planen und verwalten; Google Abrechnung der Gemini API und Custom Metadata Labels der Gemini Enterprise Agent Platform.