FinOps hat Teams ein belastbares Playbook für Cloud-Kostendisziplin an die Hand gegeben: Ressourcen taggen, Unit Economics messen, Chargeback-Modelle aufbauen, die Engineering und Finance auf dieselben Zahlen verpflichten. Und es funktioniert. Die meisten gereiften Cloud-Organisationen betreiben heute eine Variante davon.
AI-Infrastruktur bringt dieses Playbook ins Wanken – und den meisten Teams ist noch nicht klar, wie grundlegend.
Was FinOps for AI heute bedeutet
FinOps for AI ist die logische Erweiterung des Cloud-Finanzmanagements auf Machine-Learning- und Generative-AI-Workloads. Das Ziel ist dasselbe geblieben wie im klassischen FinOps: Ausgaben mit dem Team, Produkt oder Kunden verknüpfen, das sie verursacht, damit Finance und Engineering auf Basis derselben Zahlen entscheiden können. Neu ist die Infrastruktur darunter – und wie ein LLM einen Request tatsächlich verarbeitet, ist ein guter Einstieg, falls diese Infrastruktur noch Neuland ist.
In der Praxis deckt FinOps for AI typischerweise eine überschaubare Zahl an Kernfähigkeiten ab – jede aus dem klassischen FinOps-Playbook übernommen und auf eine neue Art von Workload zugeschnitten.
Cost Allocation. GPU-Instanzen so taggen, wie Sie es mit einer VM tun würden. API-Schlüssel, Modelle und Projekte auf Teams, Produkte oder Kunden abbilden. Für einen Trainings-Cluster dieselbe Ownership-Map aufziehen wie für einen Kubernetes-Namespace.
Showback und Chargeback. Reports erstellen, die einem Team zeigen, was ein Modelltraining gekostet hat oder wie hoch die Inference-Ausgaben eines Features im letzten Monat ausgefallen sind – so, wie Showback für Compute und Storage seit Jahren funktioniert.
Unit Economics. Rohe Ausgaben in eine Kennzahl übersetzen, mit der das Business etwas anfangen kann: Kosten pro Inference, Kosten pro Active User, Kosten pro Feature – nach derselben Logik, die für Kosten pro Transaktion oder pro Request längst etabliert ist.
Budgets, Alerts und Anomalieerkennung. Schwellenwerte pro Team oder Modell festlegen und benachrichtigt werden, wenn Token-Verbrauch oder Prompt-Länge unerwartet ausschlagen – das Pendant zu den Budget- und Anomalie-Tools, die im Cloud-Cost-Management längst Standard sind.
Governance und Policy Enforcement. Festlegen, wer was mit welchem Modell und bis zu welcher Kostenobergrenze hochziehen darf – das AI-Äquivalent zu Ressourcen-Quotas und Tagging-Richtlinien.
Für einen relevanten Teil der AI-Workloads trägt dieser Ansatz weiterhin. Ein dedizierter Trainings-Cluster mit klarem Owner. Ein Single-Tenant-Inference-Endpoint, der genau ein Produkt bedient. Ein Modell mit einem berechenbaren, nachvollziehbaren Aufrufmuster. Taggen, messen, fertig.
Wo das Playbook trägt – und wo nicht
Die Probleme fangen bei den Workloads an, die eben nicht so aussehen. Und das sind zunehmend die meisten.
Geteilte Infrastruktur bricht das Ownership-Modell
Ein Managed-Model-API-Account bedient routinemäßig Dutzende Teams über eine einzige Abrechnungsposition. In der Rechnung selbst gibt es keine Team-Grenze – nur das, was sich im Nachhinein aus Metadaten rekonstruieren lässt, deren Verlässlichkeit ungewiss ist. Ein geteilter GPU-Cluster fährt Inference für mehrere Produkte parallel, mit Compute-Zyklen, die auf einer Ebene ineinandergreifen, die kein Tag mehr auflösen kann.
Gateways streifen genau das Signal ab, auf dem Tagging beruht
Ein LLM-Gateway bündelt Requests von Agenten, automatisierten Pipelines und menschlichen Nutzern zu einem einzigen ausgehenden Stream – und entfernt dabei die Identität des Aufrufers aus dem, was beim Provider ankommt. Wenn der Request das Modell erreicht, ist der Kontext, der eine Zuordnung zu einem Team oder Feature erlaubt hätte, meist schon verloren. Tags, die upstream gesetzt wurden, überleben den Sprung nicht.
Agentische Workloads erzeugen Kosten, um die kein SDK herumgebaut wurde
Ein agentischer Workload kann Sub-Agenten spawnen, die reale Infrastrukturkosten auslösen – Compute, Memory, Netzwerk, Datenbanklast – ohne jeden Bezug zur ursprünglichen AI-Rechnungsposition, aus der sie hervorgegangen sind. Es gibt weder Tag noch Naming-Konvention, die das Ganze zurück zum auslösenden Request verknüpft – weil diese Kette beim Aufbau der Instrumentierung schlicht nicht vorgesehen war.
Instrumentierung kommt dem Tempo von AI-Infrastruktur nicht hinterher
Das Coverage-Problem ist nur die halbe Wahrheit. AI-Workloads bewegen sich in einem Tempo, bei dem Instrumentierung nicht mehr Schritt hält. Ein Agent kann über Nacht tausend Sub-Agenten spawnen. Bis Engineering das neue Aufrufmuster identifiziert, in ein SDK gepackt und das Update ausgeliefert hat, ist die Rechnung längst da. Das ist kein Tagging-Disziplin-Problem, das sich mit besserer Governance oder strengeren Naming-Konventionen lösen ließe. Es ist eine architektonische Realität dessen, wie AI-Infrastruktur tatsächlich läuft – und sie gilt, egal wie diszipliniert die FinOps-Praxis aufgestellt ist.
Das Problem der verwaisten Ausgaben
Sprechen Sie mit einem beliebigen FinOps-Praktiker sechs Monate nach dem Start eines AI-Kostenprogramms, und Sie hören eine Variante derselben Geschichte: eine Position, die Monat für Monat um 40 Prozent wächst, ohne dass sich ein Owner finden lässt. Die Tags verweisen auf einen Service Account, den sich drei Teams teilen. Die Naming-Konvention, die für VMs funktioniert hat, wurde auf die Inference-Endpoints nie angewendet. Jemand hat eine Tabelle gebaut, um Ownership manuell zu rekonstruieren – und die ist schon veraltet, bevor sie fertig ist.
Diese Ausgaben sind nicht ohne Owner. Sie sind unzugeordnet – weil die Methode, mit der man sie finden wollte, für Infrastruktur gebaut wurde, die sich weder bewegt noch teilt noch zur Laufzeit eigene Kinder spawnt. AI-Infrastruktur tut alle drei.
FinOps for AI vs. klassisches Cloud-FinOps
| Klassisches Cloud-FinOps | FinOps for AI | |
|---|---|---|
| Primäre Attributionsmethode | Tags, Naming-Konventionen, Account-Struktur | Tags tragen, bis geteilte Infrastruktur oder Gateways ins Spiel kommen |
| Infrastruktur-Stabilität | Relativ statisch; Ownership meist klar | Hochdynamisch; Ownership kann mitten im Request wechseln |
| Lücken in der Abdeckung | Überwiegend eine Frage der Tagging-Disziplin | Architektonisch: manche Workloads lassen sich gar nicht taggen |
| Änderungsgeschwindigkeit | Berechenbar, geregelte Change-Zyklen | Kann über Nacht kippen – schneller, als sich Instrumentierung nachziehen lässt |
| Wo es bricht | Randfälle, Legacy-Ressourcen | Geteilte GPU-Cluster, LLM-Gateways, agentische und Multi-Agent-Workloads |
Was jetzt kommt: Messen unterhalb des Tags
Wenn die Architektur von AI-Workloads Instrumentierung schon per Design aushebelt, ist Instrumentierung die falsche Ebene zum Messen. Die Alternative: dort ansetzen, wo Instrumentierung nicht übersprungen, abgestreift oder überholt werden kann – im Kernel.
Genau das ist die Architektur hinter Attribute™ by DoiT. Ein eBPF-Sensor im Betriebssystem beobachtet den tatsächlichen Verbrauch – jedes Token, jeden Model-Request, jeden GPU-Zyklus – in dem Moment, in dem er entsteht, und ordnet jede Einheit dem Prozess, dem Container und dem Request zu, der sie verursacht hat. Keine Tags. Keine SDKs. Keine Code-Änderungen. Diese Daten werden anschließend mit den Provider-Abrechnungen von Anthropic, OpenAI, Google Gemini und AWS Bedrock zusammengeführt – und automatisch in gecachte, Reasoning-, Input- und Output-Tokens aufgeschlüsselt.
Auf dieser Ebene wird Tokenomics operativ: Token-Ökonomie, automatisch attribuiert, für genau die Workloads, die Tagging nie hätte erreichen können. Tokenomics ohne Tags, ohne SDKs, ohne Code-Änderungen.
Warum das jetzt zählt
Unsere Untersuchung – eine von Sapio Research durchgeführte Befragung von 500 Finance-Verantwortlichen – hat ergeben, dass 79 Prozent der Unternehmen bereits AI-Kostenüberschreitungen erlebt haben und nur 15 Prozent den AI-ROI ohne größere Reibungsverluste berechnen können. Diese Lücke ist kein Prozessproblem, das die Teams nur noch nicht angepackt hätten. Es ist ein Messproblem – und lösen lässt es sich nur auf einer anderen Ebene.
DoiT hat über 8 Milliarden Dollar Cloud-Ausgaben für 4.500 Kunden in 27 Ländern gemanagt, und wir haben dieses Muster in jeder großen Kostenkategorie schon einmal gesehen – Compute-Optimierung, Commitment-Management, Kubernetes-Kostenallokation. Die Teams, die früh das richtige Messfundament legen, treffen jede darauf folgende Entscheidung besser. Die Teams, die abwarten, verbringen Jahre damit, Kontext zu rekonstruieren, den sie ab Tag eins hätten haben können.
Gemeinsam mit der Tokenomics Foundation sowie JR Storment und der FinOps Foundation arbeiten wir daran, zu definieren, wie dieses Fundament für die Branche aussehen soll.
FAQ
Was ist FinOps for AI?
FinOps for AI ist die Anwendung von Cloud-Financial-Management-Praktiken – Cost Allocation, Showback und Chargeback, Unit Economics, Budgets und Anomalieerkennung – auf Machine-Learning- und Generative-AI-Workloads. Es überträgt die Disziplin, die sich für klassische Cloud-Infrastruktur bewährt hat, auf eine neue Kategorie von Ausgaben.
Warum funktioniert Tagging für AI-Kostenattribution nicht?
Tagging setzt eine stabile, nachvollziehbare Beziehung zwischen einer Ressource und ihrem Owner voraus. Geteilte GPU-Cluster, LLM-Gateways und agentische Workloads brechen diese Beziehung per Design: Gateways entfernen die Identität des Aufrufers, geteilte Infrastruktur hat keine saubere Ownership-Grenze, und agentische Ketten erzeugen Kosten, auf die nie ein Tag angewendet wurde.
Was ist der Unterschied zwischen FinOps for AI und Tokenomics?
FinOps for AI beschreibt die Praxis, Kostenmanagement-Disziplin auf AI-Workloads anzuwenden. Tokenomics ist die zugrunde liegende Messdisziplin: verstehen, was jedes Token wert ist, wer es verbraucht hat und ob die Ausgabe durch das Ergebnis gerechtfertigt war – unabhängig davon, ob sich der Workload überhaupt taggen lässt.
Lässt sich FinOps for AI ohne Instrumentierung betreiben?
Ja. Kernel-Level-Messung mit Technologien wie eBPF beobachtet den Verbrauch direkt auf Betriebssystemebene, statt auf Tags oder SDKs angewiesen zu sein. Damit lassen sich auch Workloads attribuieren, die klassische Instrumentierung nicht erfasst – darunter geteilte GPU-Cluster und Traffic, der über Gateways läuft.
Wer verantwortet FinOps for AI in einer Organisation?
Das ist von Unternehmen zu Unternehmen unterschiedlich, aber FinOps for AI sitzt typischerweise an der Schnittstelle zwischen dem bestehenden FinOps- oder Cloud-Cost-Team, dem Platform- oder Infrastructure-Engineering und – zunehmend – den Teams, die AI-Produkte direkt entwickeln. Weil sich AI-Ausgaben schneller bewegen und mehr Teams berühren als klassische Cloud-Ausgaben, braucht die Praxis meist eine engere Verzahnung zwischen Finance und Engineering als das klassische FinOps – schlicht, weil keine Seite allein die volle Sicht hat.
Wie unterscheidet sich AI-Kostenallokation von Cloud-Kostenallokation?
Cloud-Kostenallokation ordnet Ausgaben in der Regel einer Ressource mit einem relativ stabilen Owner zu: einer Instanz, einem Bucket, einem Namespace. AI-Kostenallokation muss Verbrauch abbilden, der innerhalb eines einzigen Requests Ownership-Grenzen überschreitet – eine geteilte GPU, die mehrere Produkte bedient, ein Gateway, das Traffic aus mehreren Teams routet, ein Agent, der Kosten in Diensten erzeugt, die er nie direkt berührt. Das übergeordnete Ziel ist dasselbe. Die Mechanik, um dorthin zu kommen, ist es nicht.
Welche Metriken sollte ein FinOps-for-AI-Programm messen?
Die meisten Programme messen eine Kombination aus Cost per Token, Cost per Inference, Cost per Feature und Cost per Customer oder Account – zusammen mit den Aufteilungen in Input-, Output-, Cached- und Reasoning-Tokens, die je nach Provider variieren. Der richtige Mix hängt davon ab, ob die Zielgruppe Engineering ist – meist mit Bedarf an Workload-Detailtiefe – oder Finance, das typischerweise Account- oder Feature-Rollups an Umsatz- oder Renewal-Daten geknüpft haben möchte.
Bereit, Ihre echten AI-Cost-to-Serve zu sehen?
Fünfzehn Minuten Installation. Keine Instrumentierung nötig. Token-Ökonomie bis zum Feierabend.