Renting vs Buying GPUs: The Break-Even, Derived

“It pays for itself in N months” is the wrong shape of answer, because it assumes a utilisation nobody has verified. Solve for the utilisation instead and you get a threshold you can check against your own traffic.

The usual comparison is the wrong one

Dividing a purchase price by an hourly rental rate gives a number of hours, and that number is meaningless for two reasons. It ignores everything owning costs besides the purchase, and it silently assumes the owned hardware is busy every hour it exists. Both errors point the same way, and both flatter ownership.

The comparable quantity is cost per compute hour — an hour in which work is actually being done — on both sides.

It helps to notice what kind of decision this is. Buying converts a variable cost into a fixed one; renting does the reverse. Fixed costs are cheaper in total when volume is high and predictable, and catastrophic when volume disappoints, which is the same trade a business makes between owning premises and leasing them. Framed that way, the question is not “which is cheaper” but “how confident am I in my own demand, and over what horizon” — and the arithmetic below exists to tell you how confident you need to be.

The true cost of an owned hour

cost_owned_per_compute_hour =

    ( capex / L
    + power_kW * PUE * price_per_kWh
    + hosting_and_space_per_hour
    + maintenance_and_spares_per_hour
    + staff_per_hour )
    / U

capex = purchase, plus the host system, network and installation
L     = useful life in hours (economic, not physical)
PUE   = power usage effectiveness: facility power divided by
        IT power. 1.0 is impossible; every fraction above it is
        cooling and distribution you also pay for.
U     = utilisation: compute hours divided by elapsed hours

Two of those terms are habitually underestimated. Useful life is economic rather than physical: hardware keeps working long after a newer part delivers more tokens per watt and per rack unit, and the moment it is cheaper to run the new part, the old one’s remaining life is worth little. And power is not the device’s rating alone — it is the rating times the facility overhead, continuously, and it is why cooling belongs in a cost model rather than in a facilities appendix.

The rented side, from the same reasoning as any cloud cost model, is:

cost_rented_per_compute_hour = rate / U_rented

where U_rented can be much closer to 1 than U_owned, because
you can stop paying between bursts. That difference is the
whole of the argument, and it is why the comparison is about
utilisation rather than about price.

Solving for break-even utilisation

Set the two equal and solve for the owned utilisation at which they match. Write F for the fixed hourly cost of ownership — the entire numerator above, which is incurred whether or not the device is busy:

F / U_owned  =  rate / U_rented

U_owned*  =  F * U_rented / rate

Read it as: owning wins when your achieved utilisation exceeds
the ratio of your all-in hourly ownership cost to the rental
rate (scaled by how efficiently you could have rented).

If F is a third of the rental rate and you could rent at
U_rented = 1, then U_owned* = 0.33 — you need to keep the
hardware genuinely busy a third of the time to break even.

The structure of the answer is the durable part. Owning is a bet that you can keep the hardware busy; renting converts a fixed cost into a variable one and charges a premium for that conversion. Everything else is arithmetic on quotes that change.

Be careful about what counts toward U_owned, because this is where estimates go wrong in a predictable direction. A compute hour is an hour in which the device is doing work you needed done — not an hour in which the process was running, not an hour of an idle endpoint waiting for traffic, and not an hour spent on a job that was rerun because something failed. Deriving it from traffic rather than from a plan is the only reliable method: requests per day, multiplied by seconds of device time per request from your throughput arithmetic, divided by 86,400. Most people who have done this discover a number well below the one they assumed, and the number they assumed was the basis of the purchase.

A worked example with symbols

Suppose capex per device including its share of the host and network is K, and you assume a three-year economic life at 8,760 hours a year, so L = 26,280 hours. Suppose the device draws p kilowatts, your facility runs at PUE 1.4 and electricity costs c per kWh.

F = K / 26280            depreciation per hour
  + p * 1.4 * c          power, including cooling overhead
  + h                    hosting, space, network, support
  + m                    maintenance and spares provision

Then:   U_owned*  =  F / rate      (taking U_rented = 1)

Fill in your own K, p, c, h, m and rate. The formula is the
deliverable; the numbers are yours, and any figure printed
here would be wrong for your region and your quote.

Sensitivity is worth checking explicitly, because two of these inputs dominate. Shortening the assumed life from three years to two raises the depreciation term by 50%. Raising electricity cost or PUE moves a term that runs continuously. Utilisation, as always, scales everything at once.

The useful way to present the result to somebody else is as a threshold rather than a total: “owning wins if we sustain more than this much utilisation for this long”. That form invites the right conversation, because the disagreement is almost never about the arithmetic — it is about whether the demand will be there, and about how long the hardware stays competitive. Stating the threshold makes both assumptions explicit and testable, and it leaves you with a number you can check against reality a quarter later rather than an answer that quietly stops being true.

The terms that are not in the formula

• Capacity risk cuts both ways. Owned hardware cannot be taken from you when supply is tight; rented capacity may be unavailable exactly when you need to scale. Against that, owned hardware cannot be handed back when demand falls.
• Time to first result. Rented capacity is available now; procurement, delivery and installation are months. For anything uncertain, that difference is worth more than the rate.
• Operational load. Driver updates, firmware, failed devices, thermal problems and on-call. Real staff time, absent from most comparisons, and it is a step cost rather than a marginal one.
• Obsolescence risk is asymmetric. A better part landing mid-life reduces your asset’s value; a renter simply switches instance types.
• Residual value. Hardware can be resold, which offsets capex — but the resale market for accelerators is exactly as cyclical as the supply situation that made them expensive.