Dividing a period's cost by its planned request count leaves out the assumptions a pricing decision needs. Request bounds and provisioned capacity determine the cost; credits affect how much of the invoice becomes revenue. Cost recovery also depends on how many envelopes are billed. A synthetic planning model makes those choices explicit, but it cannot establish what a market will pay. Anyone using its floor to price an inference service must decide whether to accept the conditions behind it.
Request bounds and provisioned capacity
The standalone fixture plans 720 hours with one primary and one failover accelerator, sized for 1,000,000 bounded request envelopes. Each envelope carries 2,048 input tokens, at most 512 output tokens, and at most two attempts. The request bounds, hardware count and planning window are chosen inputs. They are set before the cost calculation and do not come from a market.
Capacity is sized for a stress case that assumes cache misses, maximum output and maximum attempts on every request envelope. This upper bound stays within the envelope limits; it does not forecast typical traffic. The resulting period cost is \$4,717.68, including a risk reserve. It covers every provisioned hour of both accelerators, so the failover unit costs money even if it never serves a single request.
The unit floor is \$0.006419 per envelope, which produces an invoice of \$6,419.00 at the full planned volume. The calculation includes cost, the credit reserve and the model's margin setting, then rounds up to microdollars. Dividing cost by volume alone would omit the credit and margin assumptions. All rates and costs are synthetic, and no throughput was measured. The floor depends on these conditions, and its arithmetic is exact only within them. RI-03
Credits and cost recovery
Credits can reduce revenue far below the invoice amount. The fixture holds back a 2% credit reserve, while contractual credits can reach 100% of the invoice. The reserve therefore leaves exposure to credits above the assumed fraction. With the stress-period cost held fixed, recovering that cost requires 749,955 billable envelopes. Below that count, billings after reserved credits do not cover the full period cost, because fewer requests do not reduce the cost of provisioned capacity. That threshold describes the arithmetic; it supplies no evidence of demand or an available service.
At the planned volume, revenue after the 2% reserve is \$6,290.62. The modeled net margin is about 25.005% of that net revenue. Invoice markup is about 36.063% over the \$4,717.68 cost. Both describe planned volume, with no measured operations behind them. At maximum credits, net revenue falls to zero and margin is undefined.
The public cloud compute SLAs reviewed for this research credit a percentage of affected monthly charges through a claim process. A price that ignores the credit position is quoting revenue the contract can later take back. RI-04
Regional eligibility
Capacity must also pass the declared locality rules before it can support an offer. The regional screen checks eight supplied location-policy dimensions: processing, storage, backup, telemetry, control, keys, operators and transit. It also reads resident and peak demand, latency, workload identity and declared warm failover. A US-labeled pool had a modeled 700 requests per second of warm spillover, but failed on all eight dimensions. Its spare capacity could not override those rules.
The screen's overall result is only a candidate for review, with production qualification and execution authority both set to false. It checks supplied lists and declarations, which establish neither field qualification nor a legal conclusion about where work may run. If the screen rejects capacity, a calculated price cannot make that capacity eligible for the offer. RI-01
Missing phase measurements
Calculating a floor requires separate accelerator-second rates for prefill, cached prefill and decode. The public benchmark records available to the calibration adapter report aggregate request and token rates. The adapter refuses to convert those aggregates into phase rates, so those rates stay missing until they are measured. Any floor that depends on them therefore remains incomplete. No GPU was run, and the adapter does not rank hardware.
When a rate card prices input and output tokens separately, a blended price already depends on a workload's token mix. In the systems studied in the DistServe paper, prefill is compute-heavy and decode is memory-heavy. Public records that cannot separate those phases cannot support a precise floor for each phase. RI-06
Capacity and payment choices
The pricing interface proposes predictable commitment, capped flexible usage and interruptible usage. Each class offers a fixed customer rate for a bounded envelope. These remain proposals, with no accepted products. Recovery and availability require capacity and policy qualification regardless of how the buyer pays.
A separate paired-offer fixture uses two primary and two failover accelerators, with one accelerator per replica. It reserves whole replicas for resident demand before it sizes the incoming workload's reserve. The offer adapter allocates no live capacity and runs no policy evaluator. This example must remain separate from the standalone fixture. A replica is not generally one accelerator, and combining the examples would conceal the capacity choice behind the offer. RI-02
A pricing decision must account for the request bounds, fixed capacity, recovery inventory, credit exposure and cost-recovery threshold with the stress-period cost held fixed. Whoever built the fixture chose those conditions; a market did not supply them. Buyers cannot reproduce a provider's floor without its capacity figures, recovery inventory and credit terms. The floor therefore gives them a checklist of what an offer must specify for comparison. It cannot give them an anchor or a walk-away number.
Operating limits
The budget guard holds an upper-bound amount before work starts and settles the charge after the work finishes, never above that hold. Spent plus held money must stay within the cap, and all of this state lives inside one process. A restart loses that state. It provides no durable multi-worker cap, supplier cancellation or invoice reconciliation. RI-05
The paper's checks establish implementation QA only; they do not constitute independent acceptance testing or prove an optimal allocation.
Nothing here ranks hardware or runs a GPU. Nothing here is evidence of demand, of an available service, of a real site or of measured performance, and no result establishes legal compliance, profitable operation or an SLA. It is a worked example of what a cost floor must carry with it. The full derivations are in the paper.