FinOps gave teams a real playbook for cloud cost discipline: tag your resources, track unit economics, build chargeback models that hold engineering and finance accountable to the same numbers. It works. Most mature cloud organizations run on some version of it today.
AI infrastructure is breaking that playbook, and most teams haven't reckoned with how completely yet.
What FinOps for AI means today
FinOps for AI is the natural extension of cloud financial management discipline into machine learning and generative AI workloads. The goal hasn't changed from traditional FinOps: connect spend to the team, product, or customer driving it, so finance and engineering can make decisions from the same numbers. What's changed is the infrastructure underneath, and the mechanics of how an LLM actually processes a request are a useful place to start if that infrastructure is unfamiliar.
In practice, FinOps for AI typically covers a handful of core capabilities, each borrowed from the traditional FinOps playbook and pointed at a new kind of workload.
Cost allocation. Tagging GPU instances the way you'd tag a VM. Mapping API keys, models, and projects to teams, products, or customers. Building the same ownership map for a training cluster that you'd build for a Kubernetes namespace.
Showback and chargeback. Producing reports that tell a team what their model training run cost, or what a feature's inference spend looked like last month, the same way showback has worked for compute and storage for years.
Unit economics. Translating raw spend into a number the business can act on: cost per inference, cost per active user, cost per feature, applying the same logic that's long existed for cost per transaction or cost per request.
Budgets, alerts, and anomaly detection. Setting thresholds per team or per model, and getting notified when token consumption or prompt length spikes unexpectedly, mirroring the budget and anomaly tooling that's standard in cloud cost management.
Governance and policy enforcement. Defining who can spin up what, with what model, at what cost ceiling, the AI equivalent of resource quotas and tagging policies.
For a meaningful set of AI workloads, this approach still works well. A dedicated training cluster with a clear owner. A single-tenant inference endpoint serving one product. A model with a predictable, traceable call pattern. Tag it, track it, done.
Where the playbook holds, and where it doesn't
The trouble starts with the workloads that don't look like that, and increasingly, that's most of them.
Shared infrastructure breaks the ownership model
A managed model API account routinely serves dozens of teams from a single billing line. There's no per-team boundary in the bill itself, only what you can reconstruct after the fact from metadata that may or may not be reliable. A shared GPU cluster runs inference for multiple products simultaneously, with compute cycles interleaved at a level no tag can see into.
Gateways strip the signal that tagging depends on
An LLM gateway aggregates requests from agents, automated pipelines, and human users into a single outbound stream, and in doing so, strips the caller's identity out of what reaches the provider. By the time a request hits the model, the context that would let you attribute it back to a team or feature is often already gone. Tags applied upstream don't survive the hop.
Agentic workloads spawn costs no SDK was wrapped around
An agentic workload can spawn sub-agents that trigger real infrastructure costs, compute, memory, network, database load, with no relationship to the original AI bill line item they originated from. There's no tag or naming convention connecting any of it back to the request that started the chain, because the chain wasn't anticipated when the instrumentation was built.
Instrumentation can't move at the speed AI infrastructure does
The coverage problem is only half of it. AI workloads move at a pace instrumentation can't keep up with. An agent can spawn a thousand sub-agents overnight. By the time engineering has identified the new call pattern, wrapped it in an SDK, and shipped the update, the bill has already landed. This isn't a tagging discipline problem you can fix with better governance or stricter naming conventions. It's an architectural reality of how AI infrastructure actually runs, and it applies regardless of how disciplined the FinOps practice is.
The orphaned spend problem
Talk to any FinOps practitioner six months into an AI cost program and you'll hear some version of the same story: a line item that's grown 40 percent month over month, with no owner anyone can find. The tags point to a service account that's shared across three teams. The naming convention that worked for VMs never got applied to the inference endpoints. Someone built a spreadsheet to reconstruct ownership by hand, and it's already out of date by the time it's finished.
That spend isn't unowned. It's unattributed, because the method used to find it was built for infrastructure that doesn't move, doesn't share, and doesn't spawn its own children at runtime. AI infrastructure does all three.
FinOps for AI vs. traditional cloud FinOps
| Traditional cloud FinOps | FinOps for AI | |
|---|---|---|
| Primary attribution method | Tags, naming conventions, account structure | Tags work until shared infrastructure or gateways are involved |
| Infrastructure stability | Relatively static; ownership is usually clear | Highly dynamic; ownership can shift mid-request |
| Coverage gaps | Mostly a tagging discipline problem | Architectural: some workloads can't be tagged at all |
| Speed of change | Predictable, governed change cycles | Can change overnight, faster than instrumentation can be updated |
| Where it breaks down | Edge cases, legacy resources | Shared GPU clusters, LLM gateways, agentic and multi-agent workloads |
What comes next: measuring below the tag
If the architecture of AI workloads defeats instrumentation by design, then instrumentation is the wrong layer to measure from. The alternative is to measure from somewhere instrumentation can't be skipped, stripped, or outpaced: the kernel.
That's the architecture behind Attribute™ by DoiT. It deploys an eBPF sensor inside the operating system that observes actual consumption, every token, every model request, every GPU cycle, as it happens, and maps each unit back to the process, container, and request responsible. No tags. No SDKs. No code changes. It then joins that data with provider billing from Anthropic, OpenAI, Google Gemini, and AWS Bedrock, splitting cached, reasoning, input, and output tokens automatically.
This is the layer where Tokenomics becomes operational: token-level economics, attributed automatically, for the workloads tagging was never going to reach. Tokenomics without tags, SDKs, or code changes.
Why this matters now
Our research, a survey of 500 finance leaders conducted by Sapio Research, found that 79 percent of enterprises have already experienced AI cost overruns, and only 15 percent can calculate AI ROI without significant bottlenecks. The gap isn't a process problem teams haven't gotten around to fixing yet. It's a measurement problem that requires a different layer to solve.
DoiT has managed more than 8 billion dollars in cloud spend for 4,500 customers across 27 countries, and we've watched this pattern before across every major cost category, compute optimization, commitment management, Kubernetes cost allocation. The teams that get the measurement foundation right early make every subsequent decision better. The teams that wait spend years reconstructing context they could have had from day one.
We're working with the Tokenomics Foundation, alongside JR Storment and the FinOps Foundation, to help define what that foundation looks like for the industry.
FAQ
What is FinOps for AI?
FinOps for AI is the application of cloud financial management practices, cost allocation, showback and chargeback, unit economics, budgets, and anomaly detection, to machine learning and generative AI workloads. It extends the discipline that's worked for traditional cloud infrastructure into a new category of spend.
Why doesn't tagging work for AI cost attribution?
Tagging depends on a stable, traceable relationship between a resource and its owner. Shared GPU clusters, LLM gateways, and agentic workloads break that relationship by design: gateways strip caller identity, shared infrastructure has no clean ownership boundary, and agentic chains spawn costs no tag was ever applied to.
What's the difference between FinOps for AI and Tokenomics?
FinOps for AI describes the practice of applying cost management discipline to AI workloads. Tokenomics is the underlying measurement discipline of understanding what each token is worth, who consumed it, and whether the spend was justified by the outcome, regardless of whether the workload can be tagged.
Can you do FinOps for AI without instrumentation?
Yes. Kernel-level measurement, using technology like eBPF, observes consumption at the operating system level rather than depending on tags or SDKs. This allows attribution for workloads that traditional instrumentation can't reach, including shared GPU clusters and gateway-routed traffic.
Who owns FinOps for AI inside an organization?
It varies by company, but FinOps for AI typically sits at the intersection of the existing FinOps or cloud cost team, platform or infrastructure engineering, and increasingly, the teams building AI products directly. Because AI spend moves faster and touches more teams than traditional cloud spend, the practice tends to need closer collaboration between finance and engineering than legacy FinOps did, since neither side has full visibility on its own.
How is AI cost allocation different from cloud cost allocation?
Cloud cost allocation generally maps spend to a resource with a relatively stable owner: an instance, a bucket, a namespace. AI cost allocation has to account for consumption that crosses ownership boundaries inside a single request, a shared GPU serving multiple products, a gateway routing traffic from several teams, an agent spawning costs in services it never directly touches. The underlying goal is the same. The mechanics required to get there are not.
What metrics should a FinOps for AI program track?
Most programs track some combination of cost per token, cost per inference, cost per feature, and cost per customer or account, alongside the input, output, cached, and reasoning token splits that vary by provider. The right mix depends on whether the audience is engineering, who typically wants workload-level detail, or finance, who typically wants account- or feature-level rollups tied to revenue or renewal data.
Ready to see your true AI cost-to-serve?
Fifteen minutes to install. No instrumentation required. Token economics by end of day.