Cloud Intelligence™
So validieren Sie die KI-Kostenzuordnung in Ihrer Produktionsumgebung
Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.
About Gregory Wiedeman
Senior Cloud Architect I
Greg is a Cloud Architecture Strategist at DoiT International and holds an M.S. in Systems Engineering from Regis University. He specializes in cloud architecture, FinOps consulting, and technical advisory services—helping clients optimize infrastructure and make smarter build decisions. When he's not immersed in cloud cost strategies, he enjoys writing about AI governance for non-technical leaders, playing cornhole, or climbing Colorado's many 14ers.
My personal pageEs ist einfach zu zeigen, dass man KI-Kosten zuordnen kann – schwer ist es, dieser Zuordnung zu vertrauen.
Ein Dashboard kann Tokens, Requests oder GPU-Nutzung anzeigen; die Schwierigkeit besteht darin herauszufinden, ob sich diese Zahlen auf den richtigen Kunden, das richtige Produkt-Feature, das richtige Team oder den richtigen Agenten beziehen – und ob die Summen mit den Werten übereinstimmen, denen Finance und Engineering heute vertrauen.
Dieser Artikel stellt einen praxisnahen Ansatz vor, um die Zuordnung von KI-Produktionskosten zu überprüfen. Ziel ist nicht, am ersten Tag ein voll funktionsfähiges Dashboard zu haben, sondern eine messbare Beweiskette aufzubauen, die Laufzeitaktivität mit dem Business-Kontext verbindet.
Beginnen Sie mit einer Definition von "korrekt"
Bevor Sie ein Zuordnungssystem aufbauen, sollten Sie zunächst festlegen, welche Frage die Ergebnisse beantworten sollen.
Zum Beispiel:
- Was kostet die Bereitstellung des Service pro Kunde?
- Welche Produkt-Features verursachen die höchsten Modellkosten?
- Was kostet der Betrieb jedes einzelnen KI-Agenten?
- Welche gemeinsam genutzten Workloads treiben die Infrastrukturkosten?
- Welcher Anteil der Ausgaben im Scope lässt sich derzeit nicht zuordnen?
Diese Fragen betreffen unterschiedliche Aspekte der Zuordnung: Für Showback mag eine Betrachtung auf Team-Ebene genügen, eine Sicht pro Kunde erfordert dagegen Tenant-Identifier, Details zum jeweiligen Feature und ein Mapping zwischen Laufzeit-Identifiern und Business-Namen.
Bevor Sie sich die Ergebnisse ansehen, müssen Sie die Validierungskriterien schriftlich festhalten. Ein belastbarer Validierungsplan sollte Folgendes festlegen:
- Die Workloads und Provider im Scope
- Die Dimensionen, die sichtbar sein müssen
- Die Vergleichsquelle (Source of Truth)
- Das verglichene Zeitfenster
- Die akzeptable Abweichung
- Den Umgang mit nicht zugeordneten Ausgaben
Attribute™ ordnet den Laufzeitverbrauch verschiedenen Dimensionen zu – etwa Team, Namespace, Workload, Modell, Feature, Umgebung, Tenant oder Kunde. Entscheidend ist, die Dimensionen zu wählen, die zur Business-Frage passen, statt jedes mögliche Label zu sammeln.
1. Beginnen Sie mit einem klar abgegrenzten Workload
Validieren Sie nicht gleich die gesamte Cloud-Umgebung. Beginnen Sie stattdessen mit einem kleinen, repräsentativen Ausschnitt:
- Einen Produktions-Service
- Ein Modell oder Gateway
- Ein kundenseitiges Feature
- Einen Kubernetes-Namespace
- Ein Billing-Konto oder Projekt
Durch den begrenzten Scope lassen sich Diskrepanzen eindeutig identifizieren, und das Plattform-Team erhält ein Referenzergebnis, das sich später erweitern lässt.
Erfassen Sie für den ersten Test die erwartete Aktivität unabhängig. Nützliche Vergleichsdaten sind zum Beispiel:
- Nutzungs- oder Abrechnungsdaten des Providers
- Request- und Token-Zähler des LLM-Gateways
- Anwendungslogs
- Tenant- oder Kunden-Identifier
- Kubernetes-Workload-Metadaten
- GPU- oder Compute-Auslastung
Die Systeme müssen nicht alle dieselbe Terminologie verwenden. Es geht lediglich darum zu verstehen, wie die verschiedenen Systeme zueinander in Beziehung stehen.
2. Stellen Sie sicher, dass der Zuordnungsschlüssel zur Laufzeit sichtbar bleibt
Zuordnungsfehler beginnen meist, bevor überhaupt Kosten berechnet werden: Beim Erfassen der Telemetrie fehlt unter Umständen der Zuordnungsschlüssel – also der Identifier, der nötig ist, um eine Nutzung von einer anderen zu unterscheiden.
Beantworten Sie für jede Zieldimension drei Fragen:
- Welcher Identifier verweist auf den Kunden, das Feature oder den Tenant?
- An welcher Stelle im Request-Pfad taucht der Identifier auf?
- Kann der Laufzeit-Collector ihn durchgehend beobachten?
Ein Kunden-Identifier kann beispielsweise in einem authentifizierten Request, in einem Gateway-Header, in einem Attribut der Datenbankverbindung oder in einem anwendungsspezifischen Feld enthalten sein. Existiert der Identifier jedoch nur im Speicher der Anwendung und passiert nie eine beobachtbare Grenze, ist eine andere Integrations- oder Instrumentierungsmethode erforderlich.
Deshalb sollte die Validierung mit der Sichtbarkeit des Schlüssels zur Laufzeit beginnen – nicht mit der Summe auf einem Dashboard. Lässt sich der Schlüssel nicht zuverlässig beobachten, bleibt die nachgelagerte Zuordnung unvollständig, selbst wenn die Reporting-Ebene noch so sorgfältig konfiguriert ist.
Tags können KI-Ausgaben nicht über gemeinsam genutzte GPUs und Gateways hinweg verfolgen. Lesen Sie AI Features Have a Visibility Problem und erfahren Sie, warum Runtime-Observability der Instrumentierung überlegen ist. Jetzt E-Book herunterladen →
3. Definieren Sie die Grenzen der Datenerfassung
Attribute™ erfasst Informationen über den Laufzeitverbrauch auf Kernel-Ebene mittels eBPF (extended Berkeley Packet Filter – eine Linux-Kernel-Technologie für Observability mit minimalem Overhead) und erfordert keine Änderungen am Anwendungscode oder am Anwendungs-SDK. Die Grenze der Datenerfassung bleibt dennoch wichtig.
Dokumentieren Sie:
- Welche Cluster, Hosts oder Konten abgedeckt sind
- Welche Workloads ein- oder ausgeschlossen sind
- Welche Betriebssysteme und Kernel-Versionen unterstützt werden
- Ob Traffic verschlüsselt wird, bevor er die beobachtbare Grenze erreicht
- Ob gemeinsam genutzte Infrastruktur innerhalb des Mess-Scopes liegt
Bevor die Zuordnungsmodellierung beginnt, umfasst das Onboarding bei DoiT eine Prüfung der Cluster-Topologie, einen Kompatibilitätscheck von Kernel und Betriebssystem, die Abstimmung der Sicherheitsanforderungen und eine Betrachtung des Telemetrie-Flusses. Weitere Informationen zum Engagement-Modell finden Sie in der Attribute-Übersichtsdokumentation.
Eine nützliche Abdeckungsbeschreibung sieht so aus:
Die Validierung umfasst den Produktions-Inference-Namespace, das selbst gehostete Gateway und die zugehörigen GPU-Nodes von Montag 00:00 UTC bis Dienstag 00:00 UTC; Entwicklungs-Traffic, Batch-Workloads und bereits bestehende Verbindungen sind ausgeschlossen.
Mit klar definierten Grenzen wertet kein Team ein bewusst partielles Ergebnis als fehlerhaft – und kein nicht gemessener Bereich wird als Bereich mit Kosten von null betrachtet.
4. Erstellen Sie ein Mapping von Identifier zu Business-Dimension
Laufzeit-Telemetrie beginnt häufig mit technischen Identifiern:
- Pod-Namen
- Container-IDs
- Namespace-Namen
- Modell-IDs
- API-Keys
- Tenant-IDs
- Service-Namen
Finance- und Produktteams brauchen lesbare Dimensionen:
- Kundenname
- Produkt-Feature
- Geschäftsbereich
- Umgebung
- Preisstufe
- Verantwortliches Team
Stellen Sie sicher, dass das Mapping eindeutig ist, und dokumentieren Sie es: Halten Sie fest, wer dafür verantwortlich ist und wann es zuletzt aktualisiert wurde, und definieren Sie, was passiert, wenn ein Identifier keinen zugehörigen Business-Eintrag hat.
Eine Mapping-Tabelle sollte beispielsweise mindestens folgende Spalten enthalten:
| Laufzeit-Identifier | Business-Dimension | Verantwortlich | Gültig ab | Validierungsstatus |
|---|---|---|---|---|
tenant-4821 |
Acme / Search Assistant | Product Platform | 01.09.2026 | Bestätigt |
tenant-5177 |
ExampleCo / Document Review | AI Applications | 01.09.2026 | Bestätigt |
tenant-unknown |
Nicht zugeordnet | Platform FinOps | 01.09.2026 | Prüfen |
Die Zeile mit nicht zugeordneten Einträgen ist wichtig. Wer sie ausblendet, erzeugt den Anschein vollständiger Zuordnung – und entfernt zugleich die Belege, die nötig sind, um die Abdeckung zu verbessern.
Möchten Sie sehen, welche Kunden Sie am meisten kosten? Holen Sie sich Cost Per Customer: A FinOps Field Guide to Multi-Tenant Cloud Attribution – mit einsatzbereitem SQL für AWS, Google Cloud und Azure. Jetzt Guide herunterladen →
5. Führen Sie die drei Sichten auf dieselbe Aktivität zusammen
Eine belastbare Validierung vergleicht mindestens drei Perspektiven:
- Laufzeitaktivität – was der Workload aufgerufen oder verbraucht hat
- Provider- oder Gateway-Nutzung – was die Plattform zu Tokens, Requests oder Compute meldet
- Zugeordnete Kosten – wie diese Nutzung den Business-Dimensionen zugewiesen wird
Vergleichen Sie dasselbe Zeitfenster und berücksichtigen Sie zeitliche Abweichungen: Billing-Exporte können verzögert eintreffen, Gateway-Zähler können einen Request anders interpretieren, und die Laufzeit-Telemetrie kann Retries oder gecachte Aufrufe anders erfassen als die Rechnung des Providers.
Zwei einfache Kennzahlen sind hilfreich:
Coverage = attributed in-scope spend / total in-scope spend
Variance = absolute (source total - attributed total) / source total
Behalten Sie diese Kennzahlen Tag für Tag auf Workload-Ebene im Blick, denn ein globaler Gesamtprozentsatz kann ein gravierendes Problem bei einem einzelnen Kunden oder Feature verdecken.
Klassifizieren Sie Abweichungen, statt sofort die Zuordnungsregel zu ändern:
- Scope-Abweichung
- Abweichung des Zeitfensters
- Verzögerte Provider-Abrechnung
- Fehlender Laufzeit-Identifier
- Nicht gemappter Identifier
- Retry oder doppelter Request
- Gecachte oder asynchrone Verarbeitung
- Nicht unterstützter Traffic-Pfad
Durch die Klassifizierung wird aus einer reinen Abstimmungsübung eine Reihe konkreter Engineering-Aufgaben. Das folgende Beispiel zeigt, wie diese Abstimmung vollständig durchgeführt wird, bevor Edge Cases getestet werden.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Validierungsbeispiel zur Veranschaulichung
Das folgende Beispiel dient ausschließlich der Veranschaulichung und basiert nicht auf dem Ergebnis eines realen Kunden.
Ein SaaS-Unternehmen möchte die Kosten seines Features zur Dokumentzusammenfassung pro Tenant ermitteln. Das Feature sendet seine Requests über ein gemeinsam genutztes LLM-Gateway, das in Kubernetes läuft.
Das Team definiert einen 24-stündigen Validierungszeitraum mit einem Produktions-Namespace, einem Gateway und zwei Modell-Providern und vergleicht anschließend die Token-Zähler des Gateways, die Provider-Nutzung und die Ausgabe von Attribute™.
| Validierungsschritt | Ergebnis |
|---|---|
| Summe Provider und Gateway | 10.200 $ KI-Nutzung im Scope |
| Bekannten Tenants zugeordnete Ausgaben | 9.650 $ |
| Nicht gemappte oder nicht zugeordnete Ausgaben | 550 $ bzw. 5,4 % des Scopes |
| Erstes Fazit | Die Zuordnung ist nützlich, aber noch nicht vollständig |
Das Team untersucht die Diskrepanz, statt sie als Rechenfehler abzutun. Es findet zwei Ursachen:
- Der zuletzt gelaunchte Tenant hat Laufzeit-Identifier, die nicht im Business-Mapping hinterlegt sind.
- Ein Batch-Workload nutzt dasselbe Gateway, liegt aber außerhalb des ursprünglichen Namespace-Scopes.
Das Team ergänzt das fehlende Tenant-Mapping, trennt den Batch-Workload heraus und wiederholt anschließend den Vergleich mit abgeglichenen Zeitfenstern. Diesmal wird für den definierten Feature-Scope eine Abdeckung von 99 % erreicht; die verbleibende Abweichung ist auf das Timing der Provider-Abrechnung zurückzuführen.
Entscheidend ist nicht der Prozentsatz selbst. Das Team verfügt nun über eine konsistente Erklärung für die Zahl, eine klare Verantwortlichkeit für nicht gemappte Ausgaben und ein Validierungsverfahren, das sich bei jedem neuen Tenant, Modell oder Workload erneut anwenden lässt.
Sehen Sie immer noch nicht zugeordnete KI-Ausgaben? Holen Sie sich 5 Reasons AI Costs Don't Add Up und erfahren Sie, warum Tags und SDKs die Lücke nicht schließen können. Jetzt E-Book herunterladen →
6. Testen Sie die Edge Cases, die Ihre Unit Economics verzerren
Ein einzelner Request genügt nicht, denn produktive KI-Systeme zeigen Verhaltensweisen, die die scheinbaren Kosten eines Features oder Kunden beeinflussen. Testen Sie mindestens:
- Retries nach Provider-Fehlern
- Streaming-Antworten
- Gecachte Prompts oder Antworten
- Batch-Requests
- Mehrere Modelle hinter einem Gateway
- Von Menschen und Agenten erzeugten Traffic
- Gemeinsam genutzte GPU-Workloads
- Langlebige Datenbank- oder Gateway-Verbindungen
- Failover zwischen Providern
Java-Workloads verdienen besondere Aufmerksamkeit, da die eBPF-Sichtbarkeit auf Kernel-Ebene für TLS-Traffic, der innerhalb der Java-Plattform verschlüsselt wird, nicht ausreicht. Deshalb hat Attribute™ für dieses Szenario einen Java-Agenten entwickelt. Informationen zu den unterstützten Deployment-Modi, den Einschränkungen und den Prüfungen nach der Installation finden Sie im Java Instrumentation Guide.
Bei der Validierung geht es nicht nur darum, ob der Sensor läuft, sondern auch darum, ob er den für diesen Workload relevanten Traffic so beobachtet, wie der Workload tatsächlich arbeitet.
7. Behalten Sie die Abdeckung als laufende Kontrollgröße im Blick
Die Qualität der Zuordnung variiert je nach Umgebung: Auch nach der Validierung des ersten Deployments können Lücken entstehen, wenn neue Tenants, Gateways, Modelle, Namespaces oder Features hinzukommen.
Richten Sie ein wiederkehrendes Review ein, das Folgendes prüft:
- Neu beobachtete Identifier ohne Mapping
- Ausgaben, die einer unbekannten oder gemeinsam genutzten Dimension zugewiesen sind
- Veränderungen der zugeordneten Abdeckung
- Unerwartete Veränderungen der Kosten pro Request oder Feature
- Workloads, die keine Daten mehr melden
- Differenzen zwischen Provider-Summen und zugeordneten Summen
Betrachten Sie die Abdeckung als operative Kennzahl – nicht als einmaligen Erfolg.
Eine praktische Abnahme-Checkliste
Bevor Sie ein Zuordnungs-Deployment als produktionsreif bezeichnen, stellen Sie Folgendes sicher:
- Die Business-Fragen samt relevanter Dimensionen sind dokumentiert.
- Der genaue Scope und der Zeitraum sind klar definiert.
- Der Ziel-Identifier ist im Pfad des Laufzeit-Traffics sichtbar.
- Cluster, Hosts, Konten und Workloads sind vollständig erfasst.
- Die Laufzeit-Identifier haben für das Business lesbare Namen.
- Nicht gemappte und nicht zugeordnete Ausgaben sind sichtbar.
- Die Laufzeitaktivität ist mit den Daten des Providers oder Gateways abgeglichen.
- Retries, Caching, Streaming und gemeinsam genutzte Workloads wurden getestet.
- Java-TLS-Workloads wurden ordnungsgemäß geprüft.
- Es gibt eine verantwortliche Person für Abdeckung und Abweichung samt Review-Zeitplan.
Fazit
Die KI-Kostenzuordnung ist nur so wertvoll wie das Vertrauen, das Menschen in sie setzen – und die Entscheidungen, die sie darauf stützen.
Dieses Vertrauen entsteht durch einen wiederholbaren Prozess: Definieren Sie die Frage, begrenzen Sie den Scope, prüfen Sie die Sichtbarkeit zur Laufzeit, verknüpfen Sie technische Identifier mit dem Business-Kontext, gleichen Sie die verschiedenen Sichten ab, testen Sie die Edge Cases in der Produktion und behalten Sie die Abdeckung über die Zeit im Blick.
Attribute™ liefert die Laufzeit-Messschicht für KI und gemeinsam genutzte Infrastruktur; die Qualität der Ergebnisse hängt dennoch vom Zuordnungsmodell, der Erfassungsgrenze und dem zugehörigen Validierungsprozess ab.
Für Teams, die von aggregierten KI-Rechnungen zu Kosten pro Kunde, Feature oder Agent übergehen, ist die Validierung nicht der letzte Schritt nach dem Deployment. Sie ist das Betriebssystem des gesamten Messprogramms.
