Calculate GPU Hosting Break-Even Points

For llm hosting, calculate break-even by finding the usage level at which On-Demand and the selected purchase option have the same total cost over the same period. Include compute charges, purchase commitments, storage, addresses and data transfer rather than comparing GPU rates alone. AWS's billing and purchasing options define per-second On-Demand billing, one- or three-year commitments, configuration-specific Reserved Instances and GPU cluster Capacity Blocks, while Capacity Reservation pricing and billing follows a separate billing path.

Prepare a comparable GPU hosting baseline

Use one evaluation window for both options. A shorter window may make a long commitment look artificially attractive, while a longer window may assume workload growth that has not been established.

Collect these inputs before comparing prices:

• RESOURCE_CONFIG: the exact GPU instance type, number of instances, Region, Availability Zone, tenancy and storage configuration.
• EVALUATION_PERIOD: matching start and end points for the On-Demand scenario and the committed plan.
• ELIGIBLE_USAGE: U, expressed in one consistent billing unit, such as the same usage unit used by your quote and invoice.
• ON_DEMAND_RATE: the effective rate for the exact configuration being replaced.
• PLAN_CHARGES: the fixed purchase or commitment charge, plus any variable charge shown in the quote.
• EXTRA_CHARGES: storage, addresses, snapshots, gateways and transfer charges associated with the workload.

Keep runtime patterns, restart frequency, data location and traffic direction consistent. Otherwise, a change in extras—not a change in GPU purchase economics—may appear to create the break-even point.

The EC2 instance state and billing rules also affect the baseline. A stopped instance is not billed for instance usage, but Amazon EBS volumes and Elastic IP addresses can still incur charges. Each stop-to-running transition starts a new billing period with a one-minute minimum, so repeated short runs cannot be modelled as cost-free interruptions.

Build an llm hosting break-even model

Put all amounts into the same currency and billing unit. A simple total-cost model looks like this:

ON_DEMAND_TOTAL(U) =
  OD_RATE_PER_USAGE_UNIT * U
  + OD_FIXED_CHARGES
  + OD_EXTRA_CHARGES(U)

PLAN_TOTAL(U) =
  PLAN_FIXED_CHARGES
  + PLAN_RATE_PER_USAGE_UNIT * U
  + PLAN_EXTRA_CHARGES(U)

BREAK_EVEN_EQUATION:
  ON_DEMAND_TOTAL(U_BREAK_EVEN)
  = PLAN_TOTAL(U_BREAK_EVEN)

Read OD_FIXED_CHARGES and PLAN_FIXED_CHARGES from the provider's quote or invoice rather than treating a discounted hourly rate as the entire cost of ownership. Keep extras outside the crossing calculation only when you have confirmed that both options produce the same storage and network charges.

When the charges are linear and the extra costs are equal, solve the equality algebraically:

U_BREAK_EVEN =
  (PLAN_FIXED_CHARGES - OD_FIXED_CHARGES) /
  (OD_RATE_PER_USAGE_UNIT - PLAN_RATE_PER_USAGE_UNIT)

A result outside your plausible usage range does not establish a useful break-even point. If the denominator is zero, the variable rates do not create a crossover by themselves. If usage charges vary by time or the extras are nonlinear, retain the full formulas and solve the equality iteratively instead of forcing the linear formula.

Calculate each purchase option

Savings Plans

Enter the quoted hourly commitment into the plan side of the worksheet. A screening ratio can show how much equivalent On-Demand usage the commitment would need to cover:

SP_SCREENING_BREAK_EVEN_USAGE =
  QUOTED_COMMITMENT_USD_PER_HOUR /
  ON_DEMAND_RATE_PER_USAGE_UNIT

Use this ratio only when both sides refer to the same usage unit and the quote treats the hourly commitment as the plan cost for your evaluation period. Then replace the screening values with the actual fixed and variable charges shown in the current quote or invoice. This prevents a broad commitment estimate from being mistaken for a final billing forecast.

Reserved Instances

Keep the instance type, Region and contractual term identical between the scenarios. The correct break-even is the matching usage at which the Reserved Instance charge for the selected horizon equals the corresponding On-Demand total:

RI_SCREENING_BREAK_EVEN_USAGE =
  RI_TOTAL_CHARGE_FOR_SAME_HORIZON /
  ON_DEMAND_RATE_FOR_MATCHING_CONFIGURATION

This simplified formula applies only when the plan charge can be treated as one fixed amount and the extra charges are unchanged. If the invoice separates additional usage or network charges, return to the complete PLAN_TOTAL(U) formula. A Reserved Instance should not be credited with savings against GPU usage that falls outside its matching configuration.

Capacity Reservations

Track INSTANCE_USAGE separately from RESERVED_DURATION. The reservation-side total must come from the capacity reservation billing period, while the On-Demand side follows the actual running workload:

RESERVATION_BREAK_EVEN_EQUATION:
  ON_DEMAND_TOTAL(INSTANCE_USAGE)
  = RESERVATION_TOTAL(RESERVED_DURATION)
    + PLAN_EXTRA_CHARGES(INSTANCE_USAGE)

Do not infer the reservation charge solely from instance uptime or divide a monthly reservation total by the number of visible GPU hours. Reconcile it against the reservation and discount lines in the invoice. Any operational value assigned to capacity availability should be shown separately unless the quote or bill contains a corresponding avoided charge.

Capacity Blocks

AWS does not allow a Capacity Block to be cancelled under its Capacity Blocks for ML documentation. Its pricing and billing documentation says the price is charged when the reservation is made and that Savings Plans and Reserved Instance discounts do not apply.

For a block that would replace otherwise billable On-Demand compute, use:

CAPACITY_BLOCK_BREAK_EVEN_USAGE =
  BLOCK_UPFRONT_CHARGE /
  AVOIDED_ON_DEMAND_RATE_PER_BILLING_UNIT

This result is valid only if the workload has enough expected usage to absorb the entire upfront amount and if both scenarios carry the same extras. If the block would replace work that would not otherwise run, the expected GPU usage alone does not justify the crossover.

Add extras before accepting the result

Do not set all extras to zero when U falls to zero. Assign each storage, address and transfer line according to its own billing record, then compare the two totals again:

ADJUSTED_COST_GAP(U) =
  PLAN_TOTAL(U) - ON_DEMAND_TOTAL(U)

The AWS data-transfer billing guide identifies transfer between Availability Zones inside one Region under DataTransfer-Regional-Bytes and transfer from AWS to the internet under DataTransfer-Out-Bytes. It states that internet-to-AWS inbound transfer is not charged. For inter-Region transfer, the charge applies to data leaving the source Region; transfer entering the destination Region is not charged.

Reconcile the spreadsheet in stages:

COMPUTE_CHARGES
PLAN_OR_RESERVATION_CHARGES
STORAGE_AND_ADDRESS_CHARGES
DATA_TRANSFER_CHARGES
OTHER_PERSISTENT_CHARGES

Only combine these lines after confirming that they describe the same resources, Region, period and usage pattern. A low GPU rate can still lose to a commitment if storage or transfer grows with the workload.

Check the result and catch common errors

First, verify that U_BREAK_EVEN falls inside the workload range supported by your records. Then calculate both totals at conservative, expected and high-demand usage levels without changing the quoted rates. A projected crossover should remain visible under more than one plausible workload pattern.

Compare the worksheet with an invoice for the same evaluation window. Every variable should map to a quote or billing line. If it does not, classify the difference as a commitment charge, usage mismatch, billing minimum, regional difference or unassigned extra rather than adjusting the break-even result manually.

Three errors cause most misleading calculations:

• Comparing an hourly On-Demand amount with the full price of a multi-period commitment.
• Treating a reservation or block as if its discounts also apply to every other capacity product.
• Counting expected future usage to justify a fixed purchase while ignoring unsupported workload demand.

Keep the contractual term, currency, Region, instance configuration and workload schedule visible beside the formulas. If those inputs differ, recalculate rather than transferring the previous break-even percentage.

These steps are compiled from the official documentation linked in the text and should be checked against the current versions before use. No service was run and no cost or performance result was measured for this article.

Sources

• Amazon EC2 billing and purchasing options
• Capacity Reservation pricing and billing
• Capacity Blocks for ML
• Capacity Blocks pricing and billing
• Amazon EC2 instance state changes
• Understanding data transfer charges