FinOps for AI

• Higher level of uncertainty, so data source selection requires higher skill more labor
• Evaluating the cost-effectiveness of data ingestion is much more difficult
• Different 3rd party providers
• More uncertainty about the quality of data received from vendors

• More acute are the challenges of identifying the consumer of the model output, which is especially difficult when the consumers of the same model can be different
• interfaces/functional modules in the same user application (e.g., “tech support chatbot” or “new customer chatbot”)
• Overall architecture complexity typically involves additional tiers, which further complicates traceability
• Lack of generally accepted frameworks for cost allocation across multi-agent workloads
• With inconsistent/incomplete information from vendors about billing, the complexity of allocation increases further

• Specific reporting forms that include specific metrics for AI workloads
• Additional data structures required for tracking costs in all needed dimensions and linking them with business outputs
• A wider range of interested stakeholders

• Anomalies in general carry more risks and require more attention
• The frequency of anomaly management processes can be higher
• Higher volatility and more difficulty in establishing correct criteria for defining anomalies

• Estimation of “successful” outputs of a model and their segregation from unsuccessful (e.g. irrelevant outputs, hallucination) is a relatively new and large task
• Additional challenges to estimate quality and accuracy thresholds and and the subsequent selection of the optimal AI model in terms of TCO
• Lack of benchmarks, especially applicable to the estimation of unsuccessful outputs of the AI ​​model
• Lots of new tools that are rapidly evolving

• Predictability is generally lower, especially for the Crawl and Walk phases, and much more experience is required to make forecasts
• Complicated and low consistent pricing and physical consumption volume assessment (for example, for token-based billing) across 3rd-party services providers
• Additional challenges to integrate cloud and non-cloud AI spend forecasts, as well as forecasts for different cost components
• Higher volatility of costs makes trend-based forecasting in general more challenging
• More frequent revision of forecasts is needed

• The accuracy of “top-down” budgeting based on total costs in $ is limited due to the heterogeneity and variability of vendor pricing approaches
• “Bottom-up” budgeting is especially overloaded requiring individual cost estimates for each component and also requires taking into account the pricing features of a specific vendor
• Additional stakeholder management efforts are needed, especially when piloting new AI projects where consumption volumes are virtually impossible to predict and flexible budgeting is required
• More frequent revision of budgets is needed
• AI use may be spread across many stakeholders, making it harder to assign P&L responsibility for AI services

• A number of new specific metrics important for benchmarking, primarily per-token metrics
• Few “external” benchmarks and their low consistency
• The complexity of building “internal” benchmarks, in particular due to the uniqueness of various AI projects within the company

• Additional token-based units and drivers
• In addition to common metrics, specific Workload and Value metrics can be added, for instance, for customer service AI, such as cost-per-call, time-to-close, customer satisfaction score divided by AI costs

• New engineering steps (such as model training)
• A lot of new services offered by cloud providers specified for AI, which can be incorporated into the solution in a different combination
• More complicated choice between AI-specific and general-purpose tools
• Higher demands for the adoption of microservice architecture

• Processes require more careful and frequent monitoring, which is more labor intensive
• Volatile market requires more commitment up front to usage, including approaches such as pre-purchase, capacity reservations

• The number of factors which should be taken into account and their impact can vary greatly, including related to scarcity, commitments, and other concepts
• Approaches are much more dynamic, there can be changing models from vendors (e.g. OpenAI Scale Tier)

• New vendors and services from them can create more complicated processes of collaboration with them for those organizations that were previously limited to simple models of cloud service consumption
• Subscription management process is more dynamic

• More emerging concerns about per-request environmental impact.
• More attention to unused capacity, which encourages companies to minimize long-term commitments when there is no reliable forecast for high performance (even when using a serverless structure in the early stages).

• New stakeholders the FinOps team is not familiar with (or who are not familiar with FinOps) may be added
• Higher requirements for the adoption of FinOps practices by all affected teams and their end-to-end penetration into the decentralized business processes of the organization

• New knowledge is needed, taking into account alternative deployment options and pricing models
• Higher demands on facilitation

• Much more wide implementation of multiple limits such as quotas, use of reserved capacity, throttles, etc.
• It may be necessary to relax some of the regulations previously adopted for regular cloud projects, especially for pilot and experimental projects

• New specific tools for tracking at the level of individual architecture components
• More frequently evolving tools with more challenges in their integration with each other

• Closer collaboration will be required while service usage is new and learning is going on within the organization
• Once governance, automation and established architectures are better understood the need to collaborate may decrease
• The speed of decision making and granularity of the data used in AI will require closer collaboration with Procurement and Allied Persona teams that track licenses, assets, and entitlements over the long term
• Increased engagement with IT Security will likely be long term
• The increased number of and small or new vendor nature of AI vendors will likely increase the need to coordinate with Procurement

Cost allocated. Additional costs could be added in here for AI allocation. Generally zero for usage lines, can be the purchase price for purchase lines.

A Billing Account ID is a provider-assigned identifier for a billing account. Billing accounts are commonly used for scenarios like grouping based on organizational constructs, invoice reconciliation and cost allocation strategies.

A Billing Account Name is a display name assigned to a billing account. Billing accounts are commonly used for scenarios like grouping based on organizational constructs, invoice reconciliation and cost allocation strategies.

Billing Account Type is a provider-assigned name to identify the type of billing account. Billing Account Type is a readable display name and not a code. Billing Account Type is commonly used for scenarios like mapping FOCUS and provider constructs, summarizing costs across providers, or invoicing and chargeback.

Represents the charge currency of internal pricing (“USD”, “CAD”, “EUR”, …etc).

Billing Period Start represents the inclusive start bound of a billing period. For example, a time period where Billing Period Start is ‘2024-01-01T00:00:00Z’ and Billing Period End is ‘2024-02-01T00:00:00Z’ includes charges for January since Billing Period Start represents the inclusive start bound, but does not include charges for February since BillingPeriodEnd represents the exclusive end bound.

Charge Category represents the highest-level classification of a charge based on the nature of how it is billed. Charge Category is commonly used to identify and distinguish between types of charges that may require different handling – for example the classification of charges like  “Usage”, “Purchase”, “Tax” corrections.

Commonly used to differentiate corrections from regularly incurred charges. Charge Class indicates whether the row represents a correction to a previously invoiced billing period. Charge Class is commonly used to differentiate corrections from regularly incurred charges.

A Charge Description provides a high-level context of a row without requiring additional discovery. This column is a self-contained summary of the charge’s purpose and price. It typically covers a select group of corresponding details across a billing dataset or provides information not otherwise available.

Indicates how often a charge will occur. The Charge Frequency is commonly used to understand recurrence periods (e.g., monthly, yearly), and differentiate between one-time and recurring fees for purchases.

The start/end time period for when the usage occurs (hourly or daily). Charge Period Start represents the inclusive start bound of a charge period. For example, a time period where Charge Period Start is ‘2024-01-01T00:00:00Z’ and Charge Period End is ‘2024-01-02T00:00:00Z’ includes charges for January 1 since Charge Period Start represents the inclusive start bound, but does not include charges for January 2 since Charge Period End represents the exclusive end bound.

Commitment Discount Category indicates whether the commitment discount identified in the CommitmentDiscountId column is based on usage quantity or cost (aka “spend”). The CommitmentDiscountCategory column is only applicable to commitment discounts and not negotiated discounts.

A Commitment Discount ID is the identifier assigned to a commitment discount by the provider. Commitment Discount ID is commonly used for scenarios like chargeback for commitments and savings per commitment discount. The CommitmentDiscountId column is only applicable to commitment discounts and not negotiated discounts.

A Commitment Discount Name is the display name assigned to a commitment discount. The CommitmentDiscountName column is only applicable to commitment discounts and not negotiated discounts.

Commitment Discount Quantity is the amount of a commitment discount purchased or accounted for in commitment discount related rows that is denominated in Commitment Discount Units. The aggregated Commitment Discount Quantity across purchase records, pertaining to a particular Commitment Discount ID during its term, represents the total Commitment Discount Units acquired with that commitment discount. For committed usage, the Commitment Discount Quantity is either the number of Commitment Discount Units consumed by a row that is covered by a commitment discount or is the unused portion of a commitment discount over a charge period. Commitment Discount Quantity is commonly used in commitment discount analysis and optimization use cases and only applies to commitment discounts, not negotiated discounts.

When CommitmentDiscountCategory is “Usage” (usage-based commitment discounts), the Commitment Discount Quantity reflects the predefined amount of usage purchased or consumed. If commitment discount flexibility is applicable, this value may be further transformed based on additional, provider-specific requirements. When CommitmentDiscountCategory is “Spend” (spend-based commitment discounts), the Commitment Discount Quantity reflects the predefined amount of spend purchased or consumed.

Commitment Discount Status indicates whether the charge corresponds with the consumption of a commitment discount identified in the CommitmentDiscountId column or the unused portion of the committed amount. The CommitmentDiscountStatus column is only applicable to commitment discounts and not negotiated discounts.

Commitment Discount Type is a provider-assigned name to identify the type of commitment discount applied to the row. The CommitmentDiscountType column is only applicable to commitment discounts and not negotiated discounts.

Commitment Discount Unit represents the provider-specified measurement unit indicating how a provider measures the Commitment Discount Quantity of a commitment discount. The CommitmentDiscountUnit column is only applicable to commitment discounts and not negotiated discounts.

The volume of a SKU associated with a resource or service used in vCPU-hours, GB-months, GB transferred, etc.

The Consumed Quantity represents the volume of a metered SKU associated with a resource or service used, based on the Consumed Unit. Consumed Quantity is often derived at a finer granularity or over a different time interval when compared to the Pricing Quantity (complementary to Pricing Unit) and focuses on resource and service consumption, not pricing and cost.

Represents the measurement unit of usage (like “GB”) for a SKU associated with a resource or service.

The Consumed Unit represents a provider-specified measurement unit indicating how a provider measures usage of a metered SKU associated with a resource or service. Consumed Unit complements the Consumed Quantity metric. It is often listed at a finer granularity or over a different time interval when compared to Pricing Unit (complementary to Pricing Quantity), and focuses on resource and service consumption, not pricing and cost.

Contracted Cost represents the cost calculated by multiplying contracted unit price and the corresponding Pricing Quantity. Contracted Cost is denominated in the Billing Currency and is commonly used for calculating savings based on negotiation activities, by comparing it with List Cost. If negotiated discounts are not applicable, the Contracted Cost defaults to the List Cost.

The Contracted Unit Price represents the agreed-upon unit price for a single Pricing Unit of the associated SKU, inclusive of negotiated discounts, if present, while excluding negotiated commitment discounts or any other discounts. This price is denominated in the Billing Currency. The Contracted Unit Price is commonly used for calculating savings based on negotiation activities. If negotiated discounts are not applicable, the Contracted Unit Price defaults to the List Unit Price.

Effective Cost represents the amortized cost of the charge after applying all reduced rates, discounts, and the applicable portion of relevant, prepaid purchases (one-time or recurring) that covered this charge. The amortized portion included should be proportional to the Pricing Quantity and the time granularity of the data. Since amortization breaks down and spreads the cost of a prepaid purchase, to subsequent eligible charges, the Effective Cost of the original prepaid charge is set to 0. Effective Cost does not mix or “blend” costs across multiple charges of the same service. This cost is denominated in the Billing Currency. The Effective Cost is commonly utilized to track and analyze spending trends.

An Invoice Issuer is an entity responsible for issuing payable invoices for the resources or services consumed. It is commonly used for cost analysis and reporting scenarios.

The cost calculated by multiplying ListUnitPrice and the corresponding PricingQuantity. Generally zero for usage lines, can be retail price for purchase lines.

A SKU specific suggested unit price for a single PricingUnit. Pricing at retail price for the FinOps Practitioner that wants to track retail pricing.

Pricing Category describes the pricing model used for a charge at the time of use or purchase. It can be useful for distinguishing between charges incurred at the list unit price or a reduced price and exposing optimization opportunities, like increasing commitment discount coverage.

Pricing Currency is the national or virtual currency denomination that a resource or service was priced in. Pricing Currency is commonly used in scenarios where different currencies are used for pricing and billing.

The Pricing Currency Contracted Unit Price represents the agreed-upon unit price for a single Pricing Unit of the associated SKU, inclusive of negotiated discounts, if present, while excluding negotiated commitment discounts or any other discounts. This price is denominated in the Pricing Currency. When negotiated discounts do not apply to unit prices and instead are applied to exchange rates, the Pricing Currency Contracted Unit Price defaults to the Pricing Currency List Unit Price. The Pricing Currency Contracted Unit Price is commonly used to calculate savings based on negotiation activities.

The Pricing Currency Effective Cost represents the cost of the charge after applying all reduced rates, discounts, and the applicable portion of relevant, prepaid purchases (one-time or recurring) that covered this charge, as denominated in Pricing Currency. This allows the practitioner to perform a conversion from either 1) a national currency to a virtual currency (e.g., tokens to USD), or 2) one national currency to another (e.g., EUR to USD).

The Pricing Currency List Unit Price represents the suggested provider-published unit price for a single Pricing Unit of the associated SKU, exclusive of any discounts. This price is denominated in the Pricing Currency. The Pricing Currency List Unit Price is commonly used for calculating savings based on various rate optimization activities.

The volume of a given SKU associated with a resource or service used or purchased (vCPU-hours, GB-months, GB transfer), based on the PricingUnit.

SKU level specified measurement unit (GB) for determining unit prices, indicating how the provider rates measured usage and purchase quantities.

A Provider is an entity that makes the resources or services available for purchase. It is commonly used for cost analysis and reporting scenarios.

A Publisher is an entity that produces the resources or services that were purchased. It is commonly used for cost analysis and reporting scenarios.

Note PublisherName has been deprecated in FOCUS v1.3 and will be removed in v1.4

A Region ID is a provider-assigned identifier for an isolated geographic area where a resource is provisioned or a service is provided. The region is commonly used for scenarios like analyzing cost and unit prices based on where resources are deployed.

Region Name is a provider-assigned display name for an isolated geographic area where a resource is provisioned or a service is provided. Region Name is commonly used for scenarios like analyzing cost and unit prices based on where resources are deployed.

A Resource ID is an identifier assigned to a resource by the provider. The Resource ID is commonly used for cost reporting, analysis, and allocation scenarios.

The Resource Name is a display name assigned to a resource. It is commonly used for cost analysis, reporting, and allocation scenarios.

Resource Type describes the kind of resource the charge applies to. A Resource Type is commonly used for scenarios like identifying cost changes in groups of similar resources and may include values like Virtual Machine, Data Warehouse, and Load Balancer.

Linked to layer (“Compute”, “Databases”, “Networking”). Broad classification, derived from the rate card.

The Service Category is the highest-level classification of a service based on the core function of the service. Each service should have one and only one category that best aligns with its primary purpose. The Service Category is commonly used for scenarios like analyzing costs across providers and tracking the migration of workloads across fundamentally different architectures.

Internal name of the offering or tier. Linked to layer (“Compute”, “Databases”, “Networking”).

A service represents an offering that can be purchased from a provider (e.g., cloud virtual machine, SaaS database, professional services from a systems integrator). A service offering can include various types of usage or other charges. For example, a cloud database service may include compute, storage, and networking charges.

The Service Name is a display name for the offering that was purchased. The Service Name is commonly used for scenarios like analyzing aggregate cost trends over time and filtering data to investigate anomalies.

A SKU ID is a provider-specified unique identifier that represents a specific SKU. SKUs are quantifiable goods or service offerings in a FOCUS dataset that represent specific functionality and technical specifications.

Each SKU ID represents a unique set of features that can be sold at different price points or SKU Prices. SKU ID is consistent across all pricing variations, which may differ based on multiple factors beyond the common functionality and technical specifications.

SKU ID should be consistent across pricing variations of a good or service to facilitate price comparisons for the same functionality, like where the functionality is provided or how it’s paid for. SKU ID can be referenced on a catalog or price list published by a provider to look up detailed information about the SKU. The composition of the properties associated with the SKU ID may differ across providers. SKU ID is commonly used for analyzing and comparing costs for the same SKU across different price details (e.g., term, tier, location).

SKU Meter describes the functionality being metered or measured by a particular SKU in a charge.

Providers often have billing models in which multiple SKUs exist for a given service to describe and bill for different functionalities for that service. For example, an object storage service may have separate SKUs for functionalities such as object storage, API requests, data transfer, encryption, and object management. This field helps practitioners understand which functionalities are being metered by the different SKUs that appear in a FOCUS dataset.

SKU Price Details represent a list of SKU Price properties (key-value pairs) associated with a specific SKU Price ID. These properties include qualitative and quantitative properties of a SKUs (e.g., functionality and technical specifications), along with core stable pricing properties (e.g., pricing terms, tiers, etc.), excluding dynamic or negotiable pricing elements such as unit price amounts, currency (and related exchange rates), temporal validity (e.g., effective dates), and contract- or negotiation-specific factors (e.g., contract or account identifiers, and negotiable discounts).

The composition of properties associated with a specific SKU Price may differ across providers and across SKUs within the same provider. However, the exclusion of dynamic or negotiable pricing properties should ensure that all charges with the same SKU Price ID share the same SKU Price Details, i.e., that SKU Price Details remains consistent across different billing periods and billing accounts within a provider.

SKU Price Details helps practitioners understand and distinguish SKU Prices, each identified by a SKU Price ID and associated with a used or purchased resource or service. It can also help determine the quantity of units for a property when it holds a numeric value (e.g., CoreCount), even when its unit differs from the one in which the SKU is priced and charged, thus supporting FinOps capabilities like unit economics. Additionally, the SKU Price Details may be used to analyze costs based on pricing properties such as terms and tiers.

SKU Price ID is a provider-specified unique identifier that represents a specific SKU Price associated with a resource or service used or purchased. It serves as a key reference for a SKU Price in a price list published by a provider, allowing practitioners to look up detailed information about the SKU Price.

The composition of properties associated with the SKU Price ID may differ across providers and across SKUs within the same provider. However, the exclusion of dynamic or negotiable pricing properties, such as unit price amount, currency (and related exchange rates), temporal validity (e.g., effective dates), and contract- or negotiation-specific elements (e.g., contract or account identifiers, and negotiable discounts), ensures that the SKU Price ID remains consistent across different billing periods and billing accounts within a provider. This consistency enables efficient filtering of charges to track price fluctuations (e.g., changes in unit price amounts) over time and across billing accounts, for both list and contracted unit prices. Additionally, the SKU Price ID is commonly used to analyze costs based on pricing properties such as terms and tiers.