Cost Normalisation Across Providers

Why Raw Provider Bills Are Not Comparable#

Each cloud and GPU provider invents its own billing semantics. Two services that look equivalent in name can be billed in radically different ways. A meaningful comparison requires lining up the units, the time windows, the discount treatment, and the currency before any analysis happens.

The Normalisation Pipeline#

A normalisation pipeline takes raw provider exports and emits a unified, analysis-ready dataset. With FOCUS, the schema work is largely done by the provider; the customer focuses on semantic alignment.

• Ingest — pull each provider's billing export to object storage on a fixed schedule.
• Conform — map provider columns to FOCUS where the provider does not already publish FOCUS exports.
• Amortise — convert one-time commitment purchases to per-day cost over the commitment term.
• Convert currency — apply a consistent FX rate (period-average, period-end, or transaction-day depending on policy).
• Strip or include tax — based on whether 'spend' for your analysis is gross or net of tax.
• Apply allocation rules — distribute shared costs across consumers, untagged costs to a default bucket.
• Publish — emit the conformed dataset to the analytics warehouse for downstream consumption.

Worked Example — GPU-Hour Comparison#

Suppose you want to compare the cost of an H100 GPU-hour across three providers. The naive comparison reads each provider's on-demand list price and stops there. A defensible comparison normalises along several dimensions before drawing conclusions.

• Confirm the GPU configuration — SXM5 vs PCIe, 80GB vs 94GB, NVLink topology — these affect performance per hour as well as price.
• Include reserved or committed pricing if you would realistically buy in that mode.
• Add egress assumptions — a training workload that pulls TBs from object storage may be cheaper on a provider with bundled egress even if the per-GPU-hour rate is higher.
• Include support tier costs if material — enterprise support can add a meaningful percentage.
• Convert to a single reporting currency.
• Compare the resulting total cost per training run or per inference batch, not the GPU-hour in isolation.

Where FOCUS Helps and Where It Does Not#

FOCUS normalises the schema — column names, types, charge categories. It also defines EffectiveCost as the cost after commitment amortisation, which removes one of the larger sources of normalisation toil.

FOCUS does not normalise definitions of services or units. Two providers can label different things 'object storage' or 'compute', and FOCUS will not paper over the difference. That remains a customer responsibility, supported by mapping tables maintained internally.

Yobitel and Cost Comparability#

Yobitel publishes a FOCUS-conformant billing feed alongside its native API. EffectiveCost is reported after applying reserved-capacity amortisation, so Yobitel spend lines up directly with hyperscaler EffectiveCost columns in the same warehouse table — no provider-specific transformation required.