Choose a GPU Rental Contract for Self-Hosted LLMs

Compare GPU rental terms and extra charges before committing compute, including AWS commitments with one- or three-year terms and capacity obligations.

Choose a GPU rental contract by matching commitment length, capacity rights, interruption behavior, and downtime remedies to the workload you can sustain. For a self hosted llm, compare the full invoice rather than the advertised GPU rate, because storage, network, addresses, and unused commitment time can change the decision. Keep the current quote, pricing page, order form, and SLA in one decision record.

Prepare the decision sheet

Create a workload record before comparing prices. Use placeholders until your architecture and provider quotes are fixed:

GPU_TYPE: YOUR_VALUE
GPU_COUNT: YOUR_VALUE
COMPUTE_REGION_OR_ZONE: YOUR_VALUE
STORAGE_PROFILE: YOUR_VALUE
NETWORK_REQUIREMENT: YOUR_VALUE
USAGE_PATTERN: YOUR_VALUE
COMMITMENT_HORIZON: YOUR_VALUE
RECOVERY_REQUIREMENT: YOUR_VALUE

Describe the workload as steady, bursty, scheduled, or cluster-based. State which jobs must remain online, which can retry, and what interruption would cost in time or engineering effort. Separate required GPU attributes from preferences, then identify the location, storage, and network needs that the contract must cover. If these fields cannot be completed from your architecture and the provider’s current documentation, the comparison is not ready.

Match a self hosted llm workload to the purchase structure

Within Amazon EC2, Amazon EC2 billing and purchasing options describe On-Demand billing by the second; Savings Plans that commit to consistent usage measured in USD per hour for a one- or three-year term; Reserved Instances tied to a specific instance type and Region for those term lengths; and Capacity Blocks for reserving clusters of GPU instances. These structures expose you to different combinations of duration, configuration specificity, and capacity obligations, so a low headline rate alone is not a sufficient basis for selection.

The Amazon EC2 Reserved Instances overview adds two important exit details: a Reserved Instance purchase cannot be cancelled, and it does not renew automatically. An EC2 instance can continue running after expiry, but it is then charged at On-Demand rates. Record the expiry and post-expiry treatment before treating the commitment as a complete cost calculation.

RunPod’s Pods pricing documentation states that Pods are billed per second for compute and storage, with no fees for data ingress or egress. On-demand Pods are pay-as-you-go, their resources cannot be displaced by other users, and deployment requires an account balance covering at least one hour of the selected configuration. RunPod savings plans require an upfront three-month or six-month commitment; after a Pod is stopped, the plan applies to the next deployment using the same GPU type.

Google Cloud’s Spot VM documentation documents a different interruption profile: a Spot VM can be preempted at any time, its shutdown period is best effort and up to 30 seconds, and it has no minimum or maximum runtime unless the customer limits it. Google sets the preempted metadata value to TRUE to signal preemption, and Spot VMs are excluded from the Compute Engine SLA. Use these documented operating conditions to decide whether your recovery design can support the purchase structure.

Calculate the complete bill

Build the calculation from the provider’s quote or your own invoice. Keep fixed commitments separate from usage that changes with runtime:

PLANNED_TOTAL =
  FIXED_COMMITMENT_COST
+ ACTIVE_COMPUTE_COST
+ STORAGE_COST
+ ADDRESS_COST
+ NETWORK_COST
+ OTHER_EXPLICIT_CHARGES

Fill each value from the same workload assumptions used to select the option. Do not combine a discounted rate with storage, traffic, address, or capacity charges unless the quote clearly says they are included.

For a committed option, also calculate your internal exposure:

COMMITMENT_EXPOSURE =
  FIXED_COMMITMENT_COST
- VALUE_OF_USABLE_COMMITTED_CAPACITY

This second figure is a planning measure, not a refund claim. Fill it using the period you could realistically use the contracted capacity; do not treat unused commitment time as money returned by the provider.

Amazon EC2 instance lifecycle documentation also shows why the total-bill view matters: a stopped instance is not billed for instance usage, but EBS volumes and Elastic IP addresses can incur charges regardless of instance state. Each stop-to-running transition starts a new instance billing period with a one-minute minimum. For every provider, ask separately how compute, idle storage, snapshots, addresses, internal traffic, internet transfer, and reserved capacity appear on the bill.

Read the SLA as an operational contract

The checklist below comes from the Amazon Compute Service Level Agreement:

Coverage architecture: The Region-Level commitment provides 99.99% monthly uptime when all running instances are deployed across at least two Availability Zones in the same Region. The Instance-Level commitment provides 99.5% monthly uptime for a single EC2 instance.
Definition of unavailability: For the Instance-Level SLA, the single instance is considered unavailable when it has no external connectivity.
Billing relief and credits: AWS states that it will not charge for a single EC2 instance that is unavailable for more than six minutes of a clock hour. Service credits are calculated as a percentage of the monthly bill, exclude one-time upfront payments such as Reserved Instance upfront fees, apply to future EC2 payments, and do not constitute refunds.
Claim requirements: A credit is issued only when it exceeds one US dollar for the applicable billing cycle. The customer must open an AWS Support Center case, and the request must arrive by the end of the second billing cycle after the incident. Region-Level and Instance-Level claims cannot be combined for the same single instance.
Limits and remedy: The SLA excludes causes outside AWS’s control, customer actions or inaction, and customer equipment or software. It states that service credits are the sole and exclusive remedy for the covered failure.

Read the SLA as a chain: deployment architecture determines which commitment applies, the contract defines unavailability, and the remedy section determines whether a qualifying failure produces bill relief, a future credit, or neither. Verify that your intended deployment satisfies the architecture before focusing on the headline uptime figure.

Run the pre-sign checklist

Before accepting a contract, require written answers to the following:

Which GPU type, count, memory configuration, Region, and Availability Zone are actually covered?
When does the term begin and end, and what happens at expiry?
Can the purchase be cancelled or modified, and what remains payable after a stop or early exit?
Which resources are billed while compute is running, stopped, idle, or only partially used?
Which SLA applies to the selected purchase option and deployment arrangement?
Is the stated remedy bill relief, a future credit, a refund, or something else?
What notice, checkpoint, retry, and recovery process applies if capacity is interrupted?
Which storage, address, load-balancing, snapshot, and data-transfer resources must be removed at exit?

If the current pricing page or order form is silent on cancellation, renewal, unused commitments, or charges, obtain an answer before signing. Treat an unanswered question as unresolved rather than assuming that the cost or penalty is zero.

Check that the selection works

The selection is ready only when another person can reproduce the total-cost calculation from the same quote and workload assumptions. The workload owner should also confirm that the documented interruption behavior matches the recovery requirement, while the billing owner can identify every separate charge line.

When charges appear, reconcile the invoice against the calculation and return any unexplained line to the provider before making a renewal decision. Keep the quote, applicable pricing documentation, order confirmation, SLA, and internal calculation together so that later price or policy changes are visible.

Common failure points

The most frequent decision errors are comparing advertised GPU rates while ignoring storage and transfer, committing capacity before establishing a credible usage horizon, choosing interruption-based compute without a recovery plan, and treating an SLA credit as cash. Stopping a compute service also does not prove that the associated bill is empty; review each attached resource separately.

These steps are compiled from the official documentation linked in the text and should be checked against the current version before use. This is general infrastructure purchasing information, not legal advice.