How can enterprises track infrastructure costs back to departments, projects, applications, or customers?

Enterprises can track infrastructure costs back to departments, projects, applications, or customers by attaching stable ownership identities to resource allocations and service consumption, then using CMDB and business relationships to roll those records up to the required business level. The source material directly supports project, tenant, model, and accelerator-type attribution, with accelerator card hours, Token usage, energy, storage use, and other consumption records feeding project and tenant cost reports.

For departments, applications, or customers, the source does not define a separate commercial billing engine. The supported approach is to connect those business objects to projects, tenants, or services in the relationship model, then aggregate the same underlying usage accordingly.

Why does infrastructure cost allocation fail?

Cost allocation fails when usage exists without ownership.

The infrastructure team may know:

How many GPU hours were consumed.

How much storage was used.

How much electricity was consumed.

How many Tokens were generated.

But if those records do not carry a project, tenant, service, or owner identity, the organization cannot reliably answer who created the cost.

The source model addresses this by connecting people, assets, activities, compute, and business objects through the CMDB and event-data model.

The metering layer then uses the same ownership dimensions for cost attribution.

That connection is the foundation.

What usage records should carry ownership?

Any usage record that can become a material cost should carry an ownership dimension where the source system supports it.

The source AI operations model includes:

Accelerator card hours
Accelerator memory use
Token usage
Energy
Storage use
Model
Project
Tenant
Accelerator type

The project-cost scenario specifically says the platform can:

Aggregate card hours and accelerator-memory occupancy by project.

Aggregate Token calls by project.

Associate energy and resource-occupancy cost.

Produce project and tenant cost reports.

Those are directly supported source capabilities.

The same principle can be applied to other infrastructure services if the usage and ownership are available.

Why should project identity be required early?

Because ownership is much harder to reconstruct after the workload finishes.

The source model requires API keys to be bound to a project tag so Token usage can be attributed correctly.

It makes the point explicitly:

If the key is not bound to a project tag, the usage cannot be allocated to the project.

The same logic applies to compute jobs.

A training task should carry project ownership when it is submitted.

A model service should carry project or tenant ownership when it is published.

A resource reservation should carry the owner when it is approved.

Do not wait until month-end to ask finance to guess which team created the usage.

How can accelerator card hours be allocated?

Accelerator card hours are naturally attributable when the scheduler knows which project owns the task.

A simple record contains:

Resource identity
Start time
End time
Allocated card count
Card type
Task
Project
Tenant

The source cost model then aggregates those records by project, tenant, model, and accelerator type.

If a workload uses eight cards for ten hours, that produces 80 card hours under the simple allocation definition.

The organization should document whether it reports allocated time, active time, or both.

The source supports card-hour metering but does not prescribe one universal commercial formula.

The definition must remain consistent across reports.

How can Token usage be allocated?

The source model-service layer uses the API gateway to meter Token usage by tenant, model, and project.

API keys are bound to project labels.

Each call can therefore inherit ownership.

The system can then aggregate:

Input and output usage according to the service definition
Request count
Token count
Model
Project
Tenant
Time period

This creates a direct service-consumption record.

For a MaaS environment, the Token record is often the cleanest way to attribute inference-service usage to a business owner.

How can energy cost be allocated?

The source project-cost scenario associates energy with resource occupancy.

The detailed energy model also supports GPU energy and unit Token energy.

The source does not prescribe one universal method for distributing every facility cost to every project.

A source-grounded approach is to use measured or attributable resource energy where available and then apply the organization's approved allocation rule.

For example:

GPU power is measured during a job.

The job belongs to Project A.

That accelerator energy can be associated with Project A's usage record.

If the organization applies facility overhead such as PUE, that should be a documented additional allocation rule rather than silently mixed into the raw GPU energy.

For the formulas, how a data center can calculate PUE, WUE, GPU energy consumption, and energy cost per Token explains the measurement side.

How can storage cost be allocated?

The source project-cost scenario includes storage use as one of the consumption dimensions.

Allocation requires an identifiable storage relationship.

Examples include:

Training task uses dataset storage.

Application uses a volume.

Model service loads model files from a storage path.

Project reserves a storage pool.

The organization can then decide which storage measure drives cost.

Capacity.

Throughput.

IOPS.

A fixed service fee.

The source does not define a universal storage-pricing formula.

The article should therefore keep that boundary clear.

The important source-supported point is that storage can be connected to the project and included in the cost view.

How do departments fit into the model?

The source model directly supports organization hierarchy, people, tenants, projects, and business relationships.

It does not define a separate "department cost allocation formula."

However, department rollup is possible when the department is an authoritative parent of the project or tenant.

Example:

Department: AI Research

Project A

Project B

Project C

If each project's usage is measured consistently, the department total is the sum of the projects assigned to that department during the reporting period.

That is an inference from the relationship model, not a separately specified source feature.

The key requirement is stable organizational mapping.

If projects move between departments, the reporting system should preserve the effective time period so historical costs are not silently reassigned.

How do applications fit into the cost model?

Applications can become a reporting dimension when the business topology connects services to the resources and consumption records supporting them.

The source CMDB and business-topology model links:

Business system
Application
Model service
Container
Compute resource
Storage
Network
Owner

That allows infrastructure usage to be associated with an application where the relationship is unambiguous.

For example:

Inference Service IS1 supports Application A.

IS1 produces 20 million Tokens and consumes a defined amount of accelerator time.

Those records can be rolled up to Application A.

The source does not state that every shared infrastructure cost can always be allocated precisely to an application.

Shared network and facility costs may still require an agreed allocation method.

How do customers fit into the model?

The source material directly supports tenants and projects, not a universal external-customer billing model.

A customer-level rollup therefore depends on how the enterprise represents the customer.

If each customer has a tenant, tenant-level metering can act as the customer cost boundary.

If one tenant serves several customers, the service or project relationship needs another customer identifier.

The safest operating rule is:

Do not infer customer ownership from usage after the fact.

Capture or map the customer identity at the service, project, key, or tenant layer before the usage occurs.

That makes customer reporting traceable.

Why does CMDB relationship data matter for cost?

Because cost attribution often needs more than direct metering.

A GPU-hour record can identify the project.

The business may want the department.

A model-service record can identify the project.

Finance may want the application or customer.

The relationship graph provides the rollup path.

The source data foundation explicitly treats CMDB as a shared base for monitoring, scheduling, metering, and fault analysis.

That means cost should reuse the same object relationships rather than maintain a separate ownership spreadsheet.

For the relationship model, how a CMDB can connect servers, GPUs, containers, applications, business services, and owners explains how those objects are linked.

How should shared costs be allocated?

Shared costs need an explicit rule.

The source directly measures project and tenant usage for several resource types, but some infrastructure is shared across many consumers.

Examples include:

Network fabric
Shared storage
Facility power overhead
Operations labor
Rack cost

The source does not define one universal allocation method for these items.

An enterprise can use an agreed driver such as:

Card hours
Token volume
Reserved capacity
Storage capacity
Project share
Fixed allocation

The important requirement is transparency.

A shared-cost allocation should be labeled as an allocation rule, not presented as direct metering.

How should cost reports be reconciled?

Use the same ownership and metric definitions across detailed usage, project reports, tenant reports, and any billing output.

The source model repeatedly emphasizes consistent data definitions.

Token usage should not be attributed by one project label in the gateway and another project name in finance.

Card hours should not use allocated time in one report and active time in another without clear labels.

Reconciliation should check:

Total raw usage
Attributed usage
Unattributed usage
Project totals
Tenant totals
Model totals
Time-period consistency

Unattributed usage should be visible.

It is a data-quality problem, not something to hide inside "other."

How should showback and chargeback use the same data?

Both can use the same metering and ownership model.

The difference is what the enterprise does with the result.

Showback reports the cost to the owner for visibility.

Chargeback uses the cost as an actual internal or external financial allocation.

The source materials support project and tenant cost reports and "billing output," but do not explicitly use the showback and chargeback terminology.

For the distinction, what is showback versus chargeback in IT and AI infrastructure cost management explains how the two operating models relate to the same metering foundation.

What should a cost-attribution dashboard show?

A useful dashboard can show:

Total infrastructure cost
Accelerator card hours
Token usage
Energy
Storage use
Idle cost
Project cost
Tenant cost
Model cost
Accelerator-type cost
Unattributed usage
Business rollup where mapped

Every total should support drill-down to the usage record that created it.

A platform example that connects project, tenant, model, accelerator type, card hours, Token usage, and cost is Sensaka.

If I were building cost attribution, I would start with one requirement: every material usage record must carry a stable project or tenant identity at the time it is created. Departments, applications, and customers can then be rolled up through the business relationship model. If ownership is missing at the raw usage level, month-end allocation becomes guesswork.