What is Neocloud Metering?
Written by Arnon Shimoni
✓ Expert
Last updated on:
What is neocloud metering?
Neocloud metering is the measurement, attribution, and recording of infrastructure consumption on a GPU cloud: which tenant used which GPU SKU, on which cluster or instance, for how long, in which state. It's the data layer that neocloud billing, showback, and capacity planning are all computed from.
The general concept is usage metering. What makes the neocloud version its own discipline is the stack it has to measure through: orchestration layers, multi-tenancy, and hardware states that all change what "usage" means.
What does a neocloud meter?
Rafay's metering APIs, which several GPU clouds use as their measurement layer, give a concrete picture of the record shape: organization (tenant), profile type, profile (the SKU, e.g., an 8-GPU H100 VM, a SLURM cluster, a serverless pod), instance, usage hours, and status. Generalized:
Metered dimension | Examples | Why it's on the record |
|---|---|---|
Tenant / organization | The paying customer, or their sub-team | Attribution, the whole point |
SKU / profile | GPU type and configuration (e.g., H100 8-GPU node, B200 bare metal) | Different SKUs, different rates |
Instance | The specific provisioned resource | Dispute resolution and audit |
Time consumed | Usage hours, often to the second | The quantity being priced |
State | Running, idle, suspended, preempted | Decides whether the hour is billable |
Higher-level units | Tokens for hosted inference, jobs, storage GB, egress GB | The stack above raw compute |
Why is attribution the hard part?
A GPU-hour doesn't announce who it belongs to. Between the physical GPU and the paying customer sit layers that each fragment attribution: virtualization or bare-metal allocation, Kubernetes namespaces or SLURM partitions, shared clusters with fractional GPU allocation (MIG slices), and enterprise tenants who sublet capacity to internal teams and expect per-team reporting.
Then there's the allocated-vs-consumed question, which is really a commercial policy hiding inside the meter. A customer who provisions 64 GPUs and runs them at 30% utilization: are they billed for 64 GPU-hours per hour, or for what they used? Nearly all neoclouds bill allocation (the capacity was reserved and unavailable to anyone else), which means the meter must record provisioned time and state transitions, and idle time becomes the customer's optimization problem. Get the state model wrong (e.g., billing hours a node spent in a failed state) and the invoice is wrong at H100 prices.
What are the accuracy requirements?
The same ledger properties as any metering pipeline, with the stakes raised by the rates: idempotent ingestion, correct handling of late and out-of-order events, and replayability, since a disputed 7-figure invoice gets settled by whoever can reconstruct the usage history per instance.
The reference implementations in this space are explicit about the shape. Backblaze's neocloud partner kit specifies an append-only usage ledger with reconciliation against the provider's own records, and drift monitoring between them. Rafay's guidance separates price modeling from usage collection so rates can change without touching the pipeline. Both patterns exist because their absence is how revenue leakage happens at GPU prices.
How does metering connect to billing?
Badly, in most first implementations. The common v1 is a nightly cron that exports usage CSVs into a billing spreadsheet or a separate invoicing tool, with rating logic living in neither system. It works until the first mid-cycle commit amendment, the first disputed invoice, or the first pricing change, and then the reconciliation gap becomes a finance project. The argument for keeping the meter and the biller in one ledger is the same as for any usage-based business (see don't split metering and billing), just with more zeros.
Solvimon ingests metering events into the same ledger that rates, invoices, and recognizes them, so per-tenant GPU-hours reconcile to invoice line items by construction. See Solvimon Meter.
FAQ
Is neocloud metering different from cloud cost monitoring?
Yes, in direction. Cost monitoring (FinOps) measures what you spend as a consumer. Neocloud metering measures what your customers consume so you can bill them as a provider. Same data shapes, opposite side of the invoice.
How real-time does it need to be?
Billing runs periodically, but two things need current data: customer-facing usage dashboards, and enforcement, e.g., suspending workloads when a prepaid balance or entitlement runs out. Nightly batch metering can't enforce anything.
What about metering tokens instead of hours?
That's the inference layer, where the meter counts model input and output tokens per tenant per model. It sits on top of the infrastructure meter, and providers moving up the stack run both at once. See GPUaaS billing for how the layers price differently.
Related
Neocloud billing: the hub term, what the metering feeds
Usage metering: the general discipline
GPUaaS billing: the product layer
GPU-hour: the unit being measured
Ready for billing v2?
Solvimon is monetization infrastructure for companies that have outgrown billing v1. One system, entire lifecycle, built by the team that did this at Adyen.
