Re-run your $/token math before H100's 22% rent jump resets your serving budget

The price jump changes the denominator

Your H100 invoice is the trigger: on September 7, 2026, Ornn reported that Nvidia H100 rental prices rose 22% over the prior month to $3.28 per hour. The trade-off is capacity. Effective $/token equals effective hourly cost divided by tokens per hour at target latency. If the result exceeds target, move non-latency-critical tiers to H200 or B200.

On September 7, 2026, the Ornn OCPI-H100 settlement price was $3.17 per hour, with a 30-day gain of 19%. As of Ornn's April 2, 2026 announcement, the Ornn Compute Price Index covered rental pricing for Nvidia H100, A100, H200, B200, and RTX-class GPUs.

SemiAnalysis data showed one-year H100 rental price ranges rising from $1.45-$1.95 per hour in October 2025 to $2.00-$2.70 per hour in March 2026, with midpoints moving from about $1.70 to $2.35, a gain of about 38%.

On May 19, 2026, ICE and Ornn said they would introduce GPU compute futures contracts. In August 2026, Nvidia disclosed a partnership with Apollo, BlackRock, Blackstone, Brookfield, Goldman Sachs, and KKR aimed at raising more than $500 billion for AI infrastructure financing. After Ornn's September 7, 2026 H100 price data, Nvidia CEO Jensen Huang posted on X that Nvidia compute is a flexible, long-lived, rent-generating asset.

The audit belongs before the next invoice

Work the tiers in the order your traffic uses them. Keep the audit on a shared sheet so H100, H200, and B200 lines stay comparable.

• Pull the current H100 price from the invoice, not the marketing page, and finish with an effective hourly rate for each provider, including any discount.
• Add idle time, network egress, storage, and support overhead to the rental rate to get effective hourly cost for the machine as deployed.
• Measure tokens per hour at target latency for each model, batch size, and sequence length from production traffic, not a benchmark run.
• Divide effective hourly cost by tokens per hour to get inference cost per token for each tier.
• Multiply the theoretical token rate by the share of time the fleet serves traffic so the $/token line reflects idle hours, not peak hours.
• Price the same token rate under reserved and spot contracts and state the spread in dollars per token.
• Price migration cost as engineering hours, revalidation, canary traffic, and rollback risk, with a dollar number that can be compared with the $/token spread.

Do not compare list price to spot price without utilization; a fleet that idles often hides the real $/token.

Move only when the spread pays for migration

Define S as the $/token spread between the current H100 tier and the candidate H200 or B200 tier. Set M to the migration cost from the audit. Treat R as the risk cost of a latency miss, an outage, or a failed canary. Move the tier when S exceeds M plus R.

Apply the rule by tier. Batch, offline, and background workloads usually tolerate a longer queue, so they are the natural candidates. Interactive workloads need a latency guardrail before any move. If the candidate tier cannot hold the target latency, keep the H100 tier and reprice the contract instead.

Older-hardware depreciation does not justify keeping a tier when the spread pays for migration, nor moving a latency-critical tier just because new hardware looks faster. The decision belongs to the $/token line, the utilization number, and the migration cost.

If GPU capacity shortage makes H200 or B200 allocation uncertain, keep a fallback path. A reserved H100 commitment can be cheaper than an outage. A spot H100 position can be cheaper than a missed service target, but only if the fleet can absorb the price swing.

Set a weekly rent-change trigger: re-run the audit when the H100 rental price moves again. Update the tier mix before the next invoice.