AI FinOps is FinOps scoped to AI systems: allocation, forecasting, and optimization for GPU instances, accelerators, and managed model APIs whose unit of work is often a token or a job, not a vCPU-hour. The FinOps Foundation names this FinOps for AI and keeps it separate from AI for FinOps, which is using models to operate the FinOps practice itself. On AWS, Azure, Google Cloud, and Alibaba Cloud the billing meters differ, so a single GPU dashboard is a roll-up you build, not a native object. Documentation as of 2026-08-30.

If you only need the general practice, start at What is FinOps?. The sections below explain why AI spend does not fit that export without extra dimensions.

Two different problems

The Foundation’s FinOps for AI technology category describes cost complexity, faster change, spend that is hard to predict, and a need for tighter policy while teams still ship. That is a scope you apply the Framework to, the same way you might scope SaaS or a data center.

AI for FinOps is a different page: anomaly detection, natural-language queries over billing data, suggested rightsizing. Treat those as tooling. They do not allocate a training cluster.

Engineering recommendation: keep the names straight in steering meetings. Mixing them produces a chatbot on top of an untagged GPU account.

What the bill actually meters

Self-managed training and inference on AWS shows up as EC2 (or SageMaker, EKS, Batch) usage types tied to instance families. AWS documents instance type families in the EC2 user guide; GPU and accelerator families are billed as those instances, plus EBS, and plus data transfer. Idle time is still billed if the instance is running. That is product behavior, not a FinOps opinion.

Azure bills N-series and other GPU VM SKUs through Cost Management, plus any Azure OpenAI or Azure AI service meters if you use managed models. Those are separate products. A reservation on a VM SKU does not discount a token meter.

Google Cloud documents attaching GPUs to Compute Engine VMs. Billing follows the VM and the GPU attachment, plus Cloud Storage and egress. Vertex AI has its own SKUs for training and prediction. Grouping only by “Compute Engine” hides the model API.

Alibaba Cloud GPU instances and PAI or equivalent model services sit in member accounts under Resource Directory. Consolidated billing can show the member. It will not invent a cost-per-token column unless that service emits one.

Managed model APIs (Bedrock, Azure OpenAI, Vertex, Alibaba model services) invoice by tokens, requests, or provisioned throughput. Those lines will never match a GPU-hour report. Build two unit costs: cost per accelerator-hour for capacity you run, cost per 1k tokens (or per job) for APIs you call. If a team cannot state which unit they are buying, they cannot forecast.

Isolate GPU-shaped spend

On AWS Cost Explorer or CLI, group a month by usage type and filter to the services that hold accelerators:

aws ce get-cost-and-usage \
  --time-period Start=2026-08-01,End=2026-08-30 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE

Scan Groups[].Keys for usage types that include the instance family you actually run (for example families documented as GPU or Inferentia/Trainium). A large BoxUsage line on a GPU family with low job throughput is idle capacity. A missing tag dimension means allocation tags are off or the instances are untagged; AWS requires activation before tags appear.

Azure portal: Cost analysis > Group by Meter or Resource, filter to the GPU VM series. Google Cloud: Billing > Reports, filter SKU description for GPU. None of these outputs is utilization. Utilization lives in CloudWatch, Azure Monitor, or Cloud Monitoring. Cost without utilization is how idle GPUs survive.

Risks and limitations

Commitment products (Reserved Instances, Savings Plans, Azure reservations, Google committed use) lock a family and region. A model change that needs a different GPU leaves you paying for the old one. Documented billing behavior: unused commitments still charge.

Data egress to training data or to users can exceed the GPU line. That is still FinOps, and it is still per-provider pricing.

Shared responsibility does not move. You own access keys to the model endpoint, training data classification, and who can launch p or N or a2 class machines.

I do not quote dollar-per-GPU-hour here. Prices change by region and purchase option. Use the provider price list for the region you run.

For capacity, idle, and unit-cost design, continue with GPU and AI workload cost governance.

Official sources