Negotiating a Reserved Capacity Contract: Terms That Bite

Burst allowance is how far above the committed level you can go before overage rates apply, and at what price.

Ask these questions in order:

1. What is the burst ceiling, expressed as a multiple of the commitment (1.5x, 2x, 4x)?
2. What is the overage rate above the ceiling, and is it capped at a multiple of the reserved rate?
3. Is burst throttled, queued or billed when the ceiling is reached?
4. Does burst capacity carry the same latency guarantee as reserved capacity?

The last question is where reserved contracts hide their worst surprise. Serverless and elastic capacity can scale to meet a spike, but a 70B-class model may need 15 to 30 seconds of weight loading before the first token appears, so the spike that drives the most traffic is also when cold start hurts most per this burst capacity writeup. A burst allowance that is technically available but starts cold is not the same product as your reserved baseline.

Model it with numbers. Suppose you commit to 20 units per minute, burst ceiling is 2x (40 units), and your month of per-minute data shows 43 minutes above 40 units. Under a metered overage at 1.5x the reserved rate, those 43 minutes are cheap. Under a throttle, your users see errors. Cap overage at a multiplier of your reserved rate and get the throttle behavior written down, which matches the clause advice in this GPU reservation negotiation guide from Spheron.

A ramp schedule is whether the commitment starts at full volume on day one or steps up over weeks.

Most teams sign for a level that matches where they expect traffic to be in month three, then pay full price in month one. In an AI inference product, month one may be the proving ground with no traffic at all.

Ask whether the commitment ramps, and demand the schedule in the contract language itself. A defensible pattern is 50 percent in month one, 75 percent in month two, 100 percent from month three, each step measured against your actual consumption so far.

Run the numbers against your month. If you commit 30 units and your first month's average is 12, you paid for 18 units of nothing. That idle tax is the silent cost. On a single GPU provisioned for a 10x peak while running at 10 percent average utilization, the idle tax can reach roughly 90 percent of the spend per this burst capacity analysis. Ramping the commitment reduces the same tax without touching the rate.

If the provider refuses a ramp, ask for the term floor instead. Market guidance puts one year as the practical floor for a real discount, with two to three year terms usually requiring around 20 percent of contract value prepaid per this reservation negotiation guide. A shorter term with a steeper rate beats a long term with a slow ramp you cannot fill.

A true-down clause lets you lower the commitment later. Without one, the commitment is a floor you cannot move even after you refactor, migrate or lose a customer.

Ask these questions:

• Can the commitment be reduced, by what percentage, and how many times per term?
• How much notice is required (30, 60, 90 days)?
• Does the reduction take effect at the next billing cycle or only at renewal?
• Are there fees, clawbacks of discount, or a permanent floor below which you cannot go?

The failure mode is a "true-up only" contract. It lets you raise the commitment at any time and never lower it. That is an option written for the provider, not for you. The finance logic is simple: the provider may have signed an offtake agreement to fund the capacity you are reserving, so they want your commitment to stay firm as this negotiation guide explains.

There is a structural alternative worth asking for: a dual-rate reservation. Some platforms bill a lower holding fee to keep capacity available whether or not it runs, plus a higher usage rate charged only while the capacity works. Idle time costs less than under a flat reservation, at the price of a smaller headline discount per this negotiation guide. For bursty inference traffic, the dual-rate structure is often the better deal even though the quoted discount looks worse.

Test the true-down clause with a shrinking scenario. Take your month of data and cut every hour after the tenth by 30 percent, as if a refactor reduced token volume. If the commitment cannot follow that curve, you are paying for idle capacity. Microsoft's own reservation documentation notes that reservations do not renew automatically and that the purchased quantity is fixed unless you change the renewal settings, which is the same structural constraint in miniature per Microsoft Learn.

The unit of measure decides what you are actually buying. "Provisioned throughput," "capacity unit," "vCPU-hour" and "requests per minute" are not interchangeable, and the definition paragraph is the one most teams skim.

Ask:

• Is the unit metered by time (hour), by request, by token or by provisioned rate?
• What counts toward the unit? Does a failed request, a cached response, a health check or a retry consume it?
• Is the unit measured per second, per minute, or averaged over an hour?
• Are input and output metered the same way, or separately?

Amazon Bedrock illustrates why this matters. The online pricing page lists per-token rates per model and per region, and separately notes that batch inference runs at 50 percent lower price than on-demand per the Bedrock pricing page. A reservation expressed in tokens per minute is a different object than a reservation expressed in model units per hour, and one guide argues the hourly model-unit table is effectively stale per this Bedrock pricing guide. If a vendor quotes you in a unit their public documentation no longer uses, ask for the invoice definition in the contract.

For vendor-side framing, Bedrock's own description of Provisioned Throughput is billed hourly or monthly for provisioned units regardless of use, while on-demand bills per token per this pricing explainer. That is the clean statement of the trade: you pay for the option, not the usage, unless the unit definition says otherwise.

You need 60 days or more of per-minute usage for a model worth trusting. Here is a small Python script that turns your own data into the comparison.

import csv, statistics

# columns: minute, units_used
rows = []
with open("usage.csv") as f:
    for r in csv.DictReader(f):
        rows.append(float(r["units_used"]))

per_minute = sorted(rows)
total = sum(per_minute)
p50 = statistics.median(per_minute)
p95 = per_minute[int(len(per_minute) * 0.95)]
p99 = per_minute[int(len(per_minute) * 0.99)]
minimum = per_minute[0]

# Reserved scenario: commit to the 90-day minimum, burst above it
commit = minimum
reserved_rate = 0.6      # reserved rate as a fraction of on-demand
overage_rate = 0.9       # overage as a fraction of on-demand
reserved_cost = commit * len(per_minute) * reserved_rate
overage_cost = sum(max(0, u - commit) for u in per_minute) * overage_rate
reserved_total = reserved_cost + overage_cost
on_demand_total = total  # on-demand index equals units used

print(f"commit={commit} p50={p50} p95={p95} p99={p99}")
print(f"reserved={reserved_total:.1f} on_demand={on_demand_total:.1f}")
print(f"utilization of commit={total / (commit * len(per_minute)):.2f}")

Run it three times: once with your real month, once with every value after the tenth of the month scaled by 1.3, and once with every value scaled by 0.7. The growing case tests the burst clause; the shrinking case tests the true-down clause. If the reservation only wins in the growing case, you are not buying insurance, you are buying a bet on your own forecast.

The output also gives you the utilization figure that matters. If it lands near or below the break-even implied by the discount, shrink the commitment until it clears. A provider that will not accept the smaller number is telling you they need the idle tax to make the deal work. Quanta Inference prices per model and prepaid rather than per reservation, which is a useful comparison row when you are arguing the on-demand side of the table at Quanta Inference.

Use these verbatim in the review call. Each one is designed to force a number rather than a commitment to "partner with you."

1. "Show me the invoice for a customer who used 40 percent of their commitment for a full month." If the provider cannot produce a worked example, treat the pricing table as unverified.
2. "What is the overage rate above burst, and is it capped?" An uncapped overage rate turns your busiest day into your most expensive one.
3. "If we reduce committed units by 25 percent in month nine, what do we pay?" Silence here is the true-down trap.
4. "Does our committed capacity behave identically to your on-demand capacity at peak?" Cold start and latency differences are the burst trap.
5. "Is the unit definition attached to the contract as an exhibit?" If not, the definition can be changed without your signature.

Edge and serverless products are where the latency-behavior question bites hardest. Cold starts arise on first invocation, on scale-from-zero, and when the provider reallocates resources, and observed durations range from half a second to a few seconds for Lambda functions depending on package size and runtime per this cold start explainer. One team measured consistent median cold latency of about 400ms versus 125ms hot in one edge platform in this provider thread. Ask whether burst traffic inherits those numbers.

Bundle size is the lever you control on your side. A validation library comparison showed a 141.43 KiB raw bundle (26.75 KiB gzipped) against an alternative at 11.92 KiB (2.72 KiB), a 9.8x gap, because the smaller library tree-shook down to only what the schema used per this experiment writeup. If your burst capacity is cold-start sensitive, shrinking your bundle is a contract-negotiation lever, not just an engineering chore. Providers who publish region choices for edge functions make this easier to verify per this discussion thread.

If it helps to have someone read the term sheet against your usage data, a consulting call with the Quanta Intelligence team is a reasonable next step at Quanta Intelligence.