Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

AI-Kostenattribution: Warum Tags, SDKs und Code-Änderungen nicht greifen

By Josh PalmerJul 11, 20266 min read

Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.

Die FinOps Foundation hat die Tokenomics Foundation nicht deshalb ins Leben gerufen, weil AI-Kostenmanagement ein gelöstes Problem mit neuem Etikett wäre. Wie JR Storment geschrieben hat, ist Token-Economics die Disziplin, mit der AI-Verbrauch gemessen, zugeordnet und mit Geschäftsergebnissen verknüpft wird – und die meisten Unternehmen haben dafür bislang keine verlässliche Methode. Eine neue Disziplin entsteht nicht rund um ein Problem, das bereits im Griff ist.

Der Reflex: dieses Problem so lösen, wie Teams Cloud-Kostenprobleme schon immer gelöst haben – Ressourcen taggen, Aufrufe in ein SDK verpacken, Namenskonventionen durchsetzen. Für klassische Infrastruktur hat dieses Playbook funktioniert. Für AI-Infrastruktur funktioniert es nicht, und die Gründe dafür liegen in der Architektur, nicht in den Prozessen.

Ein neuerer Ansatz – Messung auf Kernel-Ebene mit eBPF – umgeht das Instrumentierungsproblem vollständig, indem er den Verbrauch direkt auf Betriebssystemebene beobachtet, ohne Tags, SDKs oder Code-Änderungen. Genau darauf zielt "Tokenomics ohne Tags, SDKs oder Code-Änderungen". Im Folgenden: warum der Instrumentierungsansatz an seine Grenzen stößt – und wie Attribution auf Kernel-Ebene anders funktioniert.

Was ist AI-Kostenattribution (und warum funktioniert sie heute nicht)?

AI-Kostenattribution bedeutet, AI-Ausgaben – GPU-Zyklen, Model-API-Aufrufe, Token-Verbrauch – bis zu dem konkreten Kunden, Feature, Team oder Agenten zurückzuverfolgen, der sie verursacht hat. Sie ist das Pendant zur Cloud-Kostenallokation im AI-Zeitalter, mit einem entscheidenden Unterschied: Die Infrastruktur, die es zu messen gilt, hält nicht lange genug still, damit klassische Methoden sie erfassen können.

Traditionelle Kostenallokation basiert auf Instrumentierung. Wer eine Ressource taggt, weiß, wem sie gehört. Wer einen API-Aufruf in ein SDK verpackt, weiß, welches Team ihn ausgelöst hat. Dieser Ansatz ist selbst in klassischen Cloud-Umgebungen unvollkommen – die Tag-Abdeckung bleibt eine Dauerbaustelle –, aber er reicht aus, weil die darunterliegende Infrastruktur relativ statisch und die Zuständigkeit relativ klar ist.

AI-Infrastruktur räumt mit jeder einzelnen dieser Annahmen auf.

Ein einziger Managed-Model-API-Account bedient Dutzende Teams gleichzeitig. Ein gemeinsam genutzter GPU-Cluster fährt Workloads für mehrere Produkte parallel, ohne ressourcenseitige Grenze dazwischen. Ein LLM-Gateway bündelt Anfragen von Agenten, Pipelines und menschlichen Nutzern in einem einzigen ausgehenden Stream und entfernt dabei die Identität des Aufrufers. Ein agentischer Workload kann Sub-Agenten starten, die nachgelagerte Kosten – Compute, Memory, Netzwerk – auslösen, ohne dass sich noch eine nachvollziehbare Verbindung zur ursprünglichen Position herstellen ließe.

Es gibt kein Tag, das einen Hop durch einen LLM-Proxy übersteht. Es gibt kein SDK, das man um eine geteilte GPU legen kann. Und selbst dort, wo Instrumentierung theoretisch funktionieren könnte, sind AI-Workloads schneller, als Instrumentierung ausgerollt werden kann: Ein Agent kann über Nacht tausend Sub-Agenten spawnen, und die Rechnung trifft ein, lange bevor irgendjemand den Tracking-Code aktualisiert hat.

Die Attributionslücke bei AI-Ausgaben ist kein Prozessproblem. Sie ist eine strukturelle Folge davon, wie AI-Infrastruktur tatsächlich funktioniert.

Warum klassische Ansätze an eine Decke stoßen

Die Werkzeuge, die für dieses Problem entwickelt wurden, lassen sich in der Regel einer von drei Kategorien zuordnen.

Billing-Layer-Tools arbeiten im Nachhinein und verdichten Provider-Rechnungen zu Reports. Sie zeigen aggregiert, was ausgegeben wurde – lange nachdem der verursachende Workload gelaufen ist.

Kubernetes-Agent-Tools instrumentieren die Orchestrierungsebene und erfassen den Ressourcenverbrauch auf Pod- und Container-Ebene. Sie funktionieren, solange der Workload innerhalb von Kubernetes und innerhalb einer einzigen Clustergrenze bleibt. Sobald eine Anfrage eine Managed API, eine geteilte GPU oder ein LLM-Gateway durchquert, verlieren sie den Überblick.

Metadata-Inference-Tools versuchen, manuelles Tagging ganz zu umgehen, indem sie Zuständigkeiten aus verfügbaren Metadaten ableiten und virtuelle Tags automatisch vorschlagen. Das ist ein spürbarer Fortschritt gegenüber manuellem Tagging, stößt aber an dieselbe Decke: Sie können nur zuordnen, wofür Metadaten existieren – und genau auf der Ebene, wo AI-Verbrauch tatsächlich entsteht, gibt es diese Metadaten nicht.

Alle drei Ansätze rekonstruieren Attribution im Nachhinein, aus Signalen, die oberhalb der Ebene liegen, auf der der tatsächliche Verbrauch stattfindet. Keiner kann in eine geteilte GPU hineinsehen. Keiner kann einem Token durch ein Gateway hindurch bis zum auslösenden Agenten folgen.

Die Plattformen, die das können, messen unterhalb aller drei Schichten – nicht neben ihnen: auf Kernel-Ebene, wo Verbrauch direkt beobachtet und nicht abgeleitet wird.

Wie Attribution auf Kernel-Ebene funktioniert

Ein Kernel-Level-Ansatz platziert einen eBPF-Sensor direkt im Betriebssystem. Der Rollout dauert typischerweise Minuten: keine Code-Änderungen, keine Bearbeitung von Kubernetes-Manifests, kein SDK zu integrieren.

Einmal aktiv, beobachtet der Sensor den tatsächlichen Verbrauch in Echtzeit: jeden Token, jede Model-Anfrage, jeden GPU-Zyklus – und ordnet jede Einheit dem verantwortlichen Prozess, Container, Pod und Request zu. Diese Laufzeitdaten lassen sich anschließend mit Provider-Billing aus Quellen wie Anthropic, OpenAI, Google Gemini und AWS Bedrock zusammenführen und trennen dabei automatisch nach Cached Tokens, Reasoning Tokens, Input Tokens und Output Tokens.

Das Ergebnis: Token-Economics pro Kunde, pro Feature und pro Agent – kontinuierlich, ohne Instrumentierung, ohne Tagging und ohne Code-Änderungen. Weil der Sensor auf Kernel-Ebene arbeitet, sieht er den Verbrauch unmittelbar. Es gibt nichts abzuleiten – und nichts, hinter dem sich ein Agent, ein Gateway oder eine geteilte GPU verstecken könnte.

Was Attribution auf Kernel-Ebene für jedes Team ändert

Für VPs of Engineering bedeutet Attribution auf Kernel-Ebene belastbares Chargeback. GPU-Kosten werden dem verursachenden Workload zugeordnet – und damit ist Schluss mit strittigen Abrechnungsdebatten zwischen Teams, die sich Infrastruktur teilen.

Für FinOps-Praktiker bedeutet es das Ende der verwaisten Tabelle. Tags verfallen. Tagging-Konventionen sind veraltet, sobald ein neuer Service live geht. Messung auf Kernel-Ebene ist nicht darauf angewiesen, dass sich jemand ans Taggen erinnert.

Für CFOs und Finance-Verantwortliche bedeutet es ROI-Transparenz, die an konkrete Features und Kundensegmente gekoppelt ist – nicht an Schätzungen auf Account-Ebene. Zu wissen, dass ein bestimmtes Feature die Renewal-Wahrscheinlichkeit erhöht, ist eine ganz andere Qualität von Erkenntnis als der aggregierte Monatsumsatz eines Accounts.

Warum das jetzt zählt

Das Muster wiederholt sich in jeder bisherigen Cloud-Kostenkategorie: Compute-Optimierung, Commitment-Management, Kubernetes-Kostenallokation. Organisationen, die früh die richtige Messgrundlage schaffen, treffen jede spätere Entscheidung besser. Wer Attribution aufschiebt, bis die Rechnungen bereits groß sind, verbringt Jahre damit, Kontext zu rekonstruieren, den man vom ersten Tag an hätte haben können.

AI-Ausgaben bewegen sich schneller als jede vorherige Kategorie – und die Daten belegen das. Eine Sapio-Research-Umfrage unter 500 Finance-Verantwortlichen zeigt: 79 % der Unternehmen haben bereits AI-Kostenüberschreitungen erlebt, und nur 15 % können den AI-ROI ohne erhebliche Engpässe berechnen. Der richtige Moment, die Grundlage zu legen, ist jetzt – nicht nach der nächsten überraschenden Rechnung.


Wie DoiT das angeht

DoiT verwaltet über 8 Milliarden US-Dollar an Cloud-Ausgaben für 4.500 Kunden in 27 Ländern – und hat dieses Messmuster in jeder großen Cloud-Kostenkategorie wiederkehren sehen. Attribute™ by DoiT setzt den oben beschriebenen Kernel-Level-Ansatz um: ein eBPF-Sensor, der in rund fünfzehn Minuten ausgerollt ist – ohne Tags, ohne SDKs, ohne Code-Änderungen – und noch am Tag der Installation Token-Economics pro Kunde, pro Feature und pro Agent liefert.

DoiT ist außerdem Marketingpartner der Tokenomics Foundation und arbeitet gemeinsam mit JR Storment und der FinOps Foundation daran, offene Industriestandards für AI-Token-Economics zu definieren, während die Kategorie reift.

Demo buchen und Attribute™ in der eigenen Umgebung erleben.