Billing-grade metering: an invoice is a claim

Every month, a GPU provider sends an invoice for reserved capacity. Every month, the customer decides whether to believe it. In most of this industry, the invoice summarizes what the provider's monitoring happened to record, and the customer checks it against what their schedulers happened to observe. The two records disagree eventually. When they do, the dispute is settled by negotiation.

An invoice is a claim. Evidence is what settles it. This post is about the difference.

Why disputes are endemic

Reserved GPU capacity sounds like the simplest thing you could bill: a set of nodes, a billing period, a rate per reserved GPU hour. The ambiguity hides inside the words.

What counts as reserved? A node that was delivered but never passed acceptance? A node that passed, then developed a flapping NIC on day nine? A node the customer chose not to schedule anything on? Each case has a defensible answer in both directions, which is exactly the problem.

What counts as available? Reachable is not healthy. Healthy is not performing. A node can answer pings while a GPU throws XID errors and falls off the fabric. Whether that hour bills depends on definitions most contracts never operationalize.

Maintenance windows. Planned work is excluded from the availability math and unplanned work is not, so the classification of every incident is a billing event. Who declared the window, when it actually opened, and whether the work stayed inside it are all money questions.

Spare swaps. Fleets keep hot spares because hardware fails. When a spare rotates in, one serial number is delivering the reserved capacity and another is on a bench. Which one bills, and from which minute, is genuinely unclear unless something records the swap as it happens.

None of these cases is exotic. All of them recur every month, on every fleet. And on most fleets, each side reconstructs the month from records that were never designed for billing: the provider from monitoring dashboards, the customer from job logs and ticket threads. Two partial records produce two different months.

What billing-grade means

Billing-grade metering means the record is strong enough that both sides would rather consult it than argue. Four properties, concretely.

An append-only per-node state history. Every node carries a timeline of state transitions: delivered, imaged, burned in, accepted, assigned, degraded, in maintenance, swapped, wiped, retired. Transitions are recorded when they happen, with the triggering evidence attached. Nothing is edited after the fact. A correction is a new event that says so. On Lilac, a node begins billing only after it passes acceptance, and that pass is itself an event in the history.

Reserved-hour metering both sides can export. The provider's console and the customer's console query the same ledger and produce the same numbers. If the two sides cannot run the same report, the meter is an assertion, not a measurement.

Maintenance exclusions and clock-stops applied mechanically. The contract's rules are encoded once. When a maintenance window opens, the billing clock stops according to the rule, not according to whoever remembered to file the exclusion. Discretion at invoice time is where disputes breed.

Monthly reports reproducible from raw events. Delete the report, replay the event stream, and the same report comes back. A number that cannot be derived from recorded events does not belong on an invoice.

Lilac's first product metered inference by the token, and the habit carried over: nothing goes on a bill that the raw events cannot reproduce.

One ledger, three audiences

The same record settles three different conversations.

The customer's invoice. Every line item decomposes into node-hours, and every node-hour decomposes into state events. A billing question stops being a debate and becomes a lookup.

The SLA credit. When the contract owes the customer a credit, the credit is computed from the same history that produced the invoice. The number that reduces the bill and the number that generated it cannot drift apart, because they are the same number read twice.

The lender's audit. GPU fleets are increasingly debt-financed against depreciating hardware. A lender underwriting that debt wants to verify the revenue the fleet actually produced and the condition of the collateral producing it. An exportable, reproducible meter turns that audit from a spreadsheet exercise into a records review.

Three audiences, one ledger. The alternative is three records that drift, and every drift is a future dispute.

Evidence, not relationships

The standard advice for buying infrastructure is to pick a provider you trust. The advice is fine and insufficient. Relationships do not export reports, survive personnel changes, or hold up in an audit.

Trust in infrastructure is an evidence problem, not a relationship problem. When the record is complete, append-only, and reproducible, the invoice conversation gets short, the SLA conversation gets mechanical, and the lender conversation gets boring. That is the ground a good relationship is built on.

This is how the Lilac platform is built: the state history, the metering, and the reports are the system of record that invoices, SLA disputes, and lender audits settle against. Both sides read it in their own console.