Comparing Reserved Capacity Across Two Vendors

Pick dollars per allocated core-hour per month as the common unit. It is close enough to how both CPU-style and accelerator-style reservations are sold that the conversion is mechanical, and it survives the jump from vCPU to physical core to whole node.

The conversion has three steps.

1. Read the commitment in the vendor's own unit. Note whether the vendor counts vCPUs, physical cores, or nodes, and whether a node is exclusive to you or shared.
2. Convert to a core count. If the vendor sells vCPUs, divide by the threads per physical core you intend to run (2 is typical for hyperthreaded hardware, 1 for a dedicated-core SKU). If the vendor sells nodes, multiply by cores per node. If the vendor sells token batches, converert throughput using your own measured tokens per core-hour, never the vendor's peak figure.
3. Fold in the minimum spend. Divide the monthly minimum by the normalized unit price to get the floor in core-hours, and treat that floor as the real commitment if it is higher than the nominal one.

A worked example makes the arithmetic concrete. Vendor A sells 64 vCPUs at a stated rate; on hyperthreaded hardware that is 32 physical cores. Vendor B sells one 32-core node with a monthly minimum spend. Both land on 32 cores, so their quoted prices are now divisible by the same denominator. Vendor C sells "1,000 tokens per second reserved" and claims a throughput per core that you have not reproduced; convert it with your own number or leave it out of the ranking until you can.

Two pitfalls dominate this block. First, allocated is not the same as usable: subtract the cores the platform reserves for system overhead before dividing. Second, a minimum spend that sits above the nominal commitment is a hidden larger commitment, and it must be reflected in the core count, not left as a footnote.

Most reserved capacity is bought alongside an inference or application workload, so it pays to know the on-demand rate you are comparing against, including batch discounts. On Bedrock, batch inference runs at roughly half the on-demand price (AWS Bedrock pricing), which lowers the bar your reservation has to beat for work that can wait. If your mix spans several model types, a single gateway like Quanta Inference also gives you one prepaid, dollar-denominated bill to compare the reservation against.

Ramps are where two quotes most often hide a difference. Vendor A might charge full price from month one; Vendor B might give a large discount for the first quarter, then step up. Comparing only the headline month-one price flatters B; comparing only the steady-state price flatters A. Neither number is the deal.

The effective rate is a weighted average: multiply each step's monthly price by the share of term months it covers, then sum. In formula form, effective rate = sum over steps of (step price x step months / total months). This is a deterministic calculation you can put in a spreadsheet column, and it answers the question "what did I actually pay per core-hour over the whole term?"

def effective_rate(steps):
    # steps: list of (price_per_core_hour_month, months)
    total_months = sum(m for _, m in steps)
    return sum(p * m for p, m in steps) / total_months

vendor_a = effective_rate([(1.00, 12), (1.00, 24)])          # flat
vendor_b = effective_rate([(0.60, 3), (1.10, 9), (0.95, 24)])  # ramp
print(vendor_a, vendor_b)   # 1.0 vs 1.0 (rounded from 0.9966...)

Work the numbers by hand once to see why the shape matters. Vendor A: 1.00 for 36 months gives 1.00. Vendor B: 0.60 for 3, 1.10 for 9, 0.95 for 24 gives (0.60x3 + 1.10x9 + 0.95x24) / 36 = (1.80 + 9.90 + 22.80) / 36 = 34.50 / 36 = 0.958. On paper B is about 4 percent cheaper over the term. But if your forecast only supports 20 months of use, A's cumulative spend is 20.00 per core-hour-month and B's is 1.80 + 9.90 + 0.95x8 = 19.30. B still wins, narrowly, but the margin shrinks and the risk of unused months now sits on B's later, higher steps. Run the effective rate at your expected utilization and at the full term, and if the ranking flips between the two, that flip is the finding.

Two adjustments belong in this block. Time value of money: if you pay upfront, discount future months before averaging, or you will overprice offers that take their money later. Contract mechanics: some reservations bill a flat holding fee whether or not the capacity runs, plus a separate usage rate (Spheron on flex reservations). Put the holding fee in the price column and keep the usage rate as a second column so the effective rate does not silently assume full utilization.

Price gets you a shortlist; terms decide it. Two clauses do most of the work, and both must be read from the contract text rather than the sales deck.

Burst headroom is the ratio of allowed peak to committed baseline. Define it once: burst = peak capacity permitted / committed baseline. If Vendor A commits 32 cores and permits sustained peaks of 96, its burst ratio is 3.0. If Vendor B commits 32 and permits 64, its ratio is 2.0. Score both against your own observed peak-to-baseline ratio: if your traffic peaks at 2.5 times baseline for a few hours a day, A covers it inside the reservation and B spills to overage. That spill needs a price, and the rate matters. Business-hours peaks commonly run 3 to 5 times baseline for 8 to 10 hours a day, and launch spikes can reach 10 to 20 times baseline for one to three days (GMI Cloud on burst capacity). Burst above the reservation that bills at full on-demand rate is not burst, it is overage with a friendly name. Burst above the reservation that bills at your reserved rate is genuinely valuable, because the marginal cost of the peak equals your marginal cost of the baseline.

True-down is the month when the commitment can first decrease, and by how much. Read three things: the first month a reduction is allowed, the maximum size of the reduction per step, and whether the reduction requires a notice period. An offer with no true-down is a 36-month commitment disguised as a ramp. An offer with true-down at month 12, capped at 20 percent per quarter, is far more forgiving than the same clause capped at 10 percent per year. Score offers on the month the commitment drops and the total amount it can drop by, not on the presence of the word "flexible."

Two scoring rules keep the block fair. First, score terms with the same arithmetic on both sides: a ratio for burst, a month number for true-down. Second, treat any term that is not written down as the vendor-favorable default. If the contract is silent on burst, assume the reservation is a hard ceiling; if it is silent on reduction, assume there is none. When you negotiate, the clauses worth capping are the overage rate (a multiple of your reserved rate), step-downs that actually reduce the commitment, SKU flexibility, and an exit clause, all in writing (Spheron on negotiation).

A sheet that survives a procurement review has three horizontal blocks and one summary row. Lay it out like this:

• Rows for each offer, one column per input, and a final ranking column.
• Block one columns: unit as sold, threads per core, cores per node, converted cores, monthly minimum, normalized rate.
• Block two columns: ramp steps, step months, effective rate at full term, effective rate at your forecast utilization, payment timing.
• Block three columns: burst ratio, spill price multiple, true-down month, max reduction, notice period.
• Summary: break-even month and savings versus on-demand at your forecast.

The break-even month is the single number that ties the blocks together. It is the term divided by 1 minus the discount, so a 30 percent discount on a 12-month term breaks even at 8.4 months, and a 50 percent discount on 36 months breaks even at 18 months (ProsperOps on break-even). Compute it for each offer with that offer's effective rate, not its headline rate. The offer with the lowest effective rate loses if its break-even month sits after the point where your forecast turns uncertain.

Utilization and coverage are the two metrics to track after signing, and they have different jobs. Utilization measures how much of the purchased capacity you actually used, so 100 percent is the goal; coverage measures what share of eligible hours is discounted at all (AWS re:Post on utilization and coverage). Put them next to the comparison sheet so the assumptions you scored become the numbers you monitor.

Reserved capacity is only part of the bill, and the other parts use the same logic of normalizing a unit before comparing. Token pricing differs sharply between model tiers, so a modest reservation on an expensive model can cost more than a large one on a cheap model (OneUptime on Bedrock pricing). A discount on a model you retire early is worth nothing; a flat rate on a model you keep is worth a lot. Microsoft's reservation program has the same shape: capacity units are bought in increments, reservations cover capacity usage but not storage or networking, and they do not renew automatically (Microsoft Fabric reservations). Whatever the vendor, ask which line items the reservation covers and what happens at expiry.

Three offers arrive for the same workload. All run 24 hours a day for a 36-month term, so 26,280 core-hours per core.

• Offer A: 32 cores, flat 1.00 per core-hour-month, burst 3.0, spill at 1.0x reserved, true-down at month 12, no reduction cap.
• Offer B: 32 cores, ramp of 0.60 for 3 months, 1.10 for 9, 0.95 for 24, burst 2.0, spill at 1.0x reserved, true-down at month 24 at 10 percent per year.
• Offer C: 32 cores, flat 0.92, burst 1.0 (hard ceiling), spill at 1.8x reserved, no true-down.

Block one: all three normalize to 32 cores, so the denominator is identical and the comparison is fair from here. Block two: A computes to 1.00; B to 0.958 at full term and about 0.965 at a 20-month forecast; C to 0.92. On price alone C leads, B is second, A is third. Block three changes the order. C has no burst, so any peak above baseline bills at 1.8 times the reserved rate; at a 2.5 peak-to-baseline ratio for 3 hours a day, roughly 12.5 percent of monthly hours would bill at 1.8x, which adds enough to erode most of the 8 percent price advantage. C also has no true-down, so a forecast miss carries to month 36. B's ramp is cheaper but its true-down at month 24 leaves only a third of the term to correct a mistake, and the 10 percent annual cap limits the correction. A costs about 8 percent more than C at full utilization but absorbs your peaks at the reserved rate and lets you step down from month 12, which is worth more than 8 percent when the forecast is uncertain.

The decision rule: rank by effective rate at your forecast utilization, then eliminate any offer whose burst ratio is below your observed peak-to-baseline, then eliminate any offer whose true-down month is after your forecast horizon divided by two. Keep the lowest-cost survivor. In this example that is A, despite the highest headline rate, because its terms are the only ones that match how the workload actually behaves. Work the other direction if your peak-to-baseline is 1.0 and your forecast is stable for the entire term: then C's discount is real and its missing burst costs nothing.

When the workload spans many models, the effective rate you compute against can drift as the mix changes. That is one argument for keeping the inference layer flexible and buying reserved capacity only for the stable baseline; Quanta Inference prices text, image, video, audio and embedding models through one OpenAI-compatible API, which makes the on-demand side of the comparison a single number instead of a table.