KI-Kosten einem Produkt-Feature zuzuordnen gelingt nur, wenn Sie drei Ebenen verbinden: getrennte Bereitstellungen je Feature, Tags oder Identitäten, die bis in die Abrechnung reichen, und Token-Logs mit Feature-Kennung in Ihrer Anwendung. Die Rechnung von Azure OpenAI oder Amazon Bedrock kennt Modell, Tokenart und Ressource, aber kein Feature. Erst der Abgleich der Logs mit der Rechnung macht aus Tokenzahlen belastbare Feature-Kosten.
Was die Rechnung liefert und was fehlt
Wie Azure-Meter und Bedrock-Usage-Types aufgebaut sind, beschreibt Azure-OpenAI- und Bedrock-Kosten: Meter, Usage Types, Tags. Für die Feature-Zuordnung zählt: Die Rechnung aggregiert nach Modell, Tokenart, Bereitstellungstyp und Ressource, in CUR je Usage Type und Stunde oder Tag. Einen einzelnen Request, ein Feature oder einen Kunden finden Sie dort nie. Diese Information müssen Sie entweder in die Struktur legen (Ebene 1 und 2) oder selbst protokollieren (Ebene 3).
Ebene 1: getrennte Bereitstellungen je Feature
In Azure geben Sie jedem Feature ein eigenes Deployment oder ein eigenes Foundry-Projekt. Die Kostenanalyse kann die Kosten einer Foundry-Ressource auf ihre Modell-Deployments aufteilen und nach Deployment-Tags filtern. Jedes Foundry-Projekt erhält laut Microsoft automatisch ein project-Tag auf seiner Nutzung; diese Funktion ist in Vorschau und gilt nur für Modelle, die Azure selbst verkauft, nicht für Marketplace-Modelle. Wer Feature-Kosten unabhängig von Vorschaufunktionen braucht, nimmt eine eigene Foundry-Ressource je Feature.
In AWS legen Sie je Feature ein Application Inference Profile an und rufen statt der Modell-ID dessen ARN auf. Die Tags des Profils landen in Cost Explorer und CUR:
aws bedrock create-inference-profile \
--inference-profile-name support-summary \
--model-source copyFrom={foundation_model_or_system_profile_arn} \
--tags key=feature,value=support-summary key=costcentre,value={kostenstelle}
Profile funktionieren mit InvokeModel und Converse auf bedrock-runtime. Die Responses- und Chat-Completions-APIs lehnen sie mit Fehler 400 ab; dort nutzen Sie auf bedrock-mantle Projects, die mehrere Modelle umfassen können. Jedes Profil gehört zu genau einem Modell, sodass die Zahl der Profile mit Modellen mal Features wächst.
Der Preis dieser Ebene: Kapazität und Quoten verteilen sich auf mehr Deployments, und provisionierter Durchsatz je Feature läuft schneller leer als ein gemeinsamer Pool.
Ebene 2: Tags und Identitäten
Tags auf Ressourcen, Profilen und Projekten wirken in AWS erst nach Aktivierung als Cost Allocation Tag im Management-Konto und nicht rückwirkend. Ein Backfill über bis zu zwölf Monate hilft nur, wenn das Tag damals schon an der Ressource hing. In Azure überträgt die Tag-Vererbung, sofern aktiviert, Tags von Subscription und Ressourcengruppe auf Nutzungsdatensätze, ab dem laufenden Monat.
Bedrock erfasst zusätzlich die aufrufende IAM-Identität. In einem neuen CUR-2.0-Export mit Identitätsdaten steht sie in line_item_iam_principal, Tags der Rolle oder Sitzung erscheinen mit dem Präfix iamPrincipal/. Läuft jedes Feature als eigener Dienst mit eigener IAM-Rolle, erhalten Sie die Feature-Aufteilung ohne Codeänderung. Laufen alle Features über ein gemeinsames Gateway mit einer Rolle, sehen Sie nur das Gateway.
Für Tag-Werte gilt: stabile, wenige Feature-Codes, keine Kunden-IDs, keine personenbezogenen Daten. Tags sind in Abrechnungsdaten für alle sichtbar, die Kosten lesen dürfen.
Ebene 3: Token-Logs mit Feature-Kennung
Für eine Zuordnung je Request oder bei vielen Features hinter einem Gateway protokollieren Sie jeden Aufruf. Diese Felder reichen, mit der Herkunft je Anbieter:
{
"ts_utc": "{Beginn des Requests in UTC}",
"feature_id": "support-summary",
"provider": "azure oder aws",
"deployment_or_profile": "{Deployment-Name oder Profil-ARN}",
"model": "{Modell}",
"deployment_type": "{GlobalStandard, DataZoneStandard, ...}",
"input_tokens": "{usage.prompt_tokens oder usage.inputTokens}",
"cached_input_tokens": "{prompt_tokens_details.cached_tokens oder usage.cacheReadInputTokens}",
"cache_write_tokens": "{prompt_tokens_details.cache_write_tokens (ab GPT-5.6) oder usage.cacheWriteInputTokens}",
"output_tokens": "{usage.completion_tokens oder usage.outputTokens}",
"reasoning_tokens": "{completion_tokens_details.reasoning_tokens}",
"attempt": "{1 beim ersten Aufruf, ab 2 bei Wiederholungen}",
"status": "{ok, error, cancelled}",
"request_id": "{Request-ID des Anbieters}"
}
Reasoning-Tokens rechnet Microsoft als Ausgabe-Tokens ab; im Antwortbeispiel stecken sie in completion_tokens, zählen Sie sie also nicht doppelt.
Bedrock kann Ihnen Teile davon abnehmen: Mit requestMetadata (Converse) oder dem Header X-Amzn-Bedrock-Request-Metadata (InvokeModel) hängen Sie bis zu 16 Schlüssel-Wert-Paare an, die in den Model Invocation Logs landen. Diese Logs sind standardmäßig aus, gelten je Region und können Prompts enthalten. Die Metadaten erscheinen nicht in Cost Explorer oder CUR.
In Azure leitet API Management mit der Richtlinie llm-emit-token-metric Tokenzahlen als Metriken an Application Insights, mit bis zu fünf eigenen Dimensionen, etwa einem Feature-Header. API Management begrenzt jede Dimension auf 100 Werte und jeden Namespace auf 1.000 aktive Zeitreihen; darüber hinaus werden Daten ohne Fehlermeldung verworfen. Kunden-IDs als Dimension zerstören diese Metrik also.
Logs mit der Rechnung abstimmen
Logs sind eine Schätzung, die Rechnung ist der Beleg. Verteilen Sie deshalb die abgerechneten Kosten nach geloggtem Anteil, statt Tokens mit einer eigenen Preisliste zu multiplizieren:
C(m) effektive Kosten des Meters oder Usage Types m im Monat (Rechnung)
Q_bill(m) abgerechnete Menge von m, in Tokens umgerechnet
Q_log(f,m) geloggte Menge von Feature f auf m
Kosten(f) = Summe über m von C(m) × Q_log(f,m) / Q_bill(m)
Nicht zugeordnet = Summe aller C(m) − Summe aller Kosten(f)
Abdeckung(m) = Summe über f von Q_log(f,m) / Q_bill(m)
- Aggregieren Sie die Logs je Tag in UTC, Modell, Tokenart und Bereitstellungstyp, so wie die Rechnung.
- Ordnen Sie jede Kombination einem Meter oder Usage Type zu und rechnen Sie 1K- und 1M-Einheiten um.
- Prüfen Sie die Abdeckung je Meter. Liegt sie deutlich unter eins, fehlen Logs: abgebrochene Streams, Batch-Jobs, andere Anwendungen auf derselben Ressource. Liegt sie über eins, loggen Sie Aufrufe, die nicht abgerechnet wurden, oder zählen doppelt.
- Verteilen Sie nur Token-Meter nach diesem Schlüssel. Provisionierte Kapazität (PTU, Model Units) verteilen Sie nur im Umfang der gemessenen Auslastung nach Tokenanteil auf genau diesem Deployment; den Rest weisen Sie als Leerlauf aus.
- Lassen Sie den Rest als „nicht zugeordnet“ stehen und versionieren Sie die Regel mit Monat und Datenstand.
AWS schreibt selbst, dass CUR keine Request-ID je Zeile enthält. Abstimmen können Sie also nur je Modell und Usage Type, mit den Logs als Detail darunter.
Embeddings, Vektorspeicher und andere gemeinsame Kosten
Nicht alles gehört einem Feature. Das Erzeugen von Embeddings für einen Index, den mehrere Features nutzen, ist gemeinsame Kosten; das Embedding einer einzelnen Suchanfrage ist dem Feature direkt zuzuordnen. Vektorspeicher kosten oft unabhängig von der Last: Azure AI Search im Modell Dedicated rechnet Search Units (Replikate mal Partitionen) stündlich ab und stoppt erst beim Löschen; Vektorisierer rechnet Azure zum Tarif des genutzten Modells ab, etwa als Azure-OpenAI-Kosten. Bei OpenSearch Serverless bestimmt der Mindestwert an OCUs je Collection-Gruppe die Grundlast.
Legen Sie für solche Posten eine schriftliche Regel fest: Anteil an Abfragen, Anteil am Indexvolumen oder zentrale Plattformkosten. Wie Sie für jede gemeinsame Komponente einen Schlüssel wählen, zeigt der Leitfaden zu Multi-Tenant-Kosten.
Welche Ebene für welche Frage
| Situation | Ebene | Grund |
|---|---|---|
| Wenige Features, jedes als eigener Dienst | 1 und 2 | Rechnungsnah, keine Log-Pipeline nötig |
| Viele Features über ein Gateway | 3 mit Abstimmung | Profile je Modell und Feature werden unübersichtlich |
| Geteilter provisionierter Durchsatz | 3 für Anteile, Leerlauf separat | Kapazität kennt kein Feature |
| Partnermodelle über Azure Marketplace | 1 (eigene Ressource) oder 3 | Kein project-Tag |
| Preis eines Features festlegen | 3 mit Abstimmung, Rest erklärt | Grundlage muss zur Rechnung passen |
| Kosten je Kunde | 3 mit pseudonymer Kennung nur in Logs | Tags und Metrik-Dimensionen sind dafür ungeeignet |
Für Kosten je Kunde verbinden Sie die Feature-Werte mit der Kennzahl aus Cloud-Kosten pro Kunde; ob KI-Kosten zu den Umsatzkosten gehören, behandelt Cloud-Kosten und SaaS-Bruttomarge.
Grenzen
Token-Logs bilden Rabatte, Commitments, Batch-Preise und Kapazität nicht ab; deshalb verteilen Sie Rechnungsbeträge statt Listenpreise. Bei abgebrochenen Streams können Tokenzahlen fehlen. Tags, Profile und Identitätsdaten wirken erst ab Einrichtung. Wenn Logs einzelne Beschäftigte erkennbar machen, etwa bei internen Werkzeugen, klären Sie Datenschutz und die Mitbestimmung des Betriebsrats mit Ihren Beratern, bevor Sie protokollieren; dieser Artikel ist keine Rechtsberatung.
Was Costfluent dabei abdeckt
Costfluent liest die Abrechnungsdaten von Azure und AWS über schreibgeschützte Connectoren und ordnet sie mit Zuordnungsregeln Teams, Produkten oder Kostenstellen zu, auf Basis von Konto, Ressource und Tags. Gemeinsame Kosten werden ohne Verlust oder Doppelzählung verteilt, nicht zugeordnete Kosten bleiben sichtbar; das Ergebnis ist Showback. Token-Telemetrie und Invocation Logs liest Costfluent nicht, die Aufteilung je Request bleibt in Ihrer Log-Pipeline.
Quellen und Methode
Geprüft am 10. Oktober 2026: Microsoft Foundry: Kosten planen und verwalten, Azure OpenAI: Prompt Caching, Azure OpenAI: Reasoning-Modelle, API Management: llm-emit-token-metric, Azure: Tag-Vererbung, Azure AI Search: Kosten, Bedrock: Application Inference Profiles, Bedrock: Projects, Bedrock: IAM-Principal-Zuordnung, Bedrock: Request-Metadaten, Bedrock: Model Invocation Logging, Bedrock: TokenUsage, AWS CLI: create-inference-profile, AWS CUR 2.0: Line-Item-Spalten, AWS: Backfill von Cost Allocation Tags, OpenSearch Serverless: Kapazität. Ebenenmodell, Formel und Entscheidungstabelle sind Costfluent-Empfehlungen, keine Rechts- oder Buchhaltungsberatung.
