Should you sell your idle GPU time?

Owning only beats renting past a utilization line, and that line moves with every assumption behind it. Selling the leftover hours raises a second set of questions, about the counterparty and the payout, that the hourly rate doesn't answer.

If you own GPUs, or you’re deciding whether to buy instead of rent, someone will eventually tell you to sell the hours nobody is using. Sounds like free money. It isn’t, until you know whether owning made sense in the first place at the utilization you actually run.

Spot resale and token resale change the math at the margin. They don’t fix a utilization problem that was already bad before you started selling. So the answer to “should I sell my idle time” depends on whether owning the hardware was ever the honest choice.

What does utilization actually mean?

Utilization is GPU-hours put to productive use, divided by GPU-hours available in the period. A GPU sitting in a rack for a full year has 8,760 hours on the clock whether or not anyone ran a job on it.

That’s not uptime. Uptime just means the hardware could have worked. A cluster can report 99 percent uptime and 40 percent utilization at the same time: the GPU could have earned money every hour, and it actually did for a fraction of them. A dashboard full of green health checks tells you nothing about whether the meter is running.

What it costs to own a GPU, per hour

Start with the reference build from what it actually costs to run a GPU cluster: 8 racks of Nvidia GB300 NVL72, 576 GPUs, about $46M of capex, built from published specs. That’s roughly $79,861 per GPU.

Recover that straight-line over 3 years, no financing, no residual value, and the capital alone costs $79,861 / 3 / 8,760 = about $3.04 per GPU-hour. Used or not. The money is already spent.

Now add power, priced where the hardware actually sits instead of at a generic US rate. Hydro-Quebec’s Electricity Rates, 2026 edition, effective April 1, 2026, prices Rate L (large industrial, 5 MW and up) at 3.821 cents per kWh plus a demand charge of $15.027 per kW of billing demand. The reference build’s stated 1.3 MW facility draw for 576 GPUs works out to about 2.257 kW per GPU. That’s $0.086/hr in energy plus $0.046/hr in demand charges, about $0.13/hr per GPU in power.

Capital plus power: $3.04 + $0.13 = about $3.17 per GPU-hour. That’s before a cent of staffing, colocation markup, insurance, or software licensing. Those costs are real and depend on the site.

If the hardware sits in someone else’s facility, AI-ready colocation is commonly quoted around $200 to $300 per kW per month for space, cooling and capacity, with power billed separately at cost. At 2.257 kW per GPU and $250 per kW-month, that’s about $564 a month, or roughly $0.77 per GPU-hour. All in, about $3.94. Get a real quote for your site. Every breakeven below only goes up once that line is in.

Now compare $3.17/hr to CoreWeave’s own published on-demand rate for the same chip: GB200 NVL72 at $42.00/hr for a 4-GPU instance, or $10.50 per GPU-hour, on CoreWeave’s public pricing page, checked October 2026. Breakeven utilization against that rate is $3.17 / $10.50 = about 30 percent.

Under a third. That’s the honest answer if the thing you’re weighing against owning is retail, on-demand, no-commitment pricing.

Where does “two-thirds” come from?

On-demand is the weakest comparison. Almost nobody buying at this scale is really choosing between owning and paying on-demand. The real alternative is a reserved, multi-year contract, and that’s where the math changes.

It’s also where the newest chips hit a data gap. As of October 2026, none of the major clouds publish a self-serve reserved rate for GB200 or GB300. Every quote needs a sales call. You can’t run the two-thirds math on the newest hardware with public numbers alone. Know that before you build a model that pretends otherwise.

So step down one generation to H100, where reserved pricing is public. Compute Exchange’s reserved-GPU pricing page, published April 10, 2026, quotes an on-demand H100 SXM rate of about $2.99/hr on the same page where it lists a one-year reserved H100 SXM contract at about $1.89/hr.

The owning side is fuzzier. H100 has no manufacturer list price. Nvidia sells through OEM partners, not directly, so there’s no single authoritative capex figure like there is for the GB-class build above. The figures below are illustrative; check any system price against a current integrator quote before you rely on it.

Say a buyer pays around $30,000 per GPU for an 8-GPU H100 system. Over 3 years unlevered, that’s $30,000 / 3 / 8,760 = $1.14/hr. H100 SXM5’s published maximum TDP is 700W. At a 1.56 PUE (Uptime Institute’s 2024 Global Data Center Survey, the industry average), that’s 1.092 kW of facility draw, or $0.06/hr at the same Quebec pricing. Total illustrative owning cost: about $1.21 per GPU-hour.

Illustrative capexOwning cost/hrBreakeven vs. reserved ($1.89/hr)Breakeven vs. on-demand ($2.99/hr)
$25,000/GPU$1.0254%34%
$30,000/GPU$1.2164%40%
$40,000/GPU$1.5984%53%
H100: illustrative owning cost vs. reserved vs. on-demand ($/GPU-hr)USD per GPU-hour
Own, $30k/GPU (illustrative)1.21
Reserved, 1-yr (Compute Exchange, Apr 10 2026)1.89
On-demand (Compute Exchange, Apr 10 2026)2.99

At the cheap end of a plausible capex range, breakeven against a reserved contract lands close to two-thirds. That’s probably where the rule of thumb comes from. At the expensive end of the same range, it’s pushing 85 percent, and that’s before colocation, staffing, or financing.

So “roughly two-thirds” is a real number. But it’s a reserved-rate number, it assumes close to the cheapest purchase price, and it leaves out most of the operating cost. Know which comparison you’re making before you adopt someone else’s utilization target.

A GPU-hour is not a token

Once you know your real breakeven, selling the hours above it depends on what you’re selling.

Selling a GPU-hour is the simple product. CoreWeave’s own pricing page, checked October 2026, lists HGX B200 at $68.80/hr on-demand against $34.11/hr as an interruptible spot instance. Roughly half price, and the buyer accepts preemption risk. As the seller, that risk isn’t yours. You get paid the spot rate for the hours you deliver. It looks almost exactly like renting out on-demand capacity at a standing discount.

Selling tokens is a different bet. Together AI’s own pricing page, checked October 2026, lists a dedicated on-demand H100 instance at $5.49/hr, a fixed hourly product, next to serverless Llama 3.3 70B inference at $1.04 per million input tokens and $1.04 per million output tokens.

Whether tokens beat renting the GPU-hour depends entirely on how many tokens you can push through that hour. That number isn’t fixed. Artificial Analysis’s own provider benchmarking of this exact model, checked October 2026, shows output speed from a median of 86.0 tokens per second up to 317.3 tokens per second at the fastest provider it tracks. That’s a spread of as much as 1,550 percent between providers serving the identical model.

A GPU-hour is a price you set. Tokens are a throughput you have to earn. A marketplace’s headline per-token rate tells you nothing about which end of that spread you’ll land on.

Where people get taken

A per-token price that looks better than a per-hour rental is only better if you hit the throughput the quote quietly assumes. Most sellers never see that assumption written down.

Marketplaces also enforce their own bar. OpenRouter’s public provider documentation, checked October 2026, requires 95 percent or higher uptime for normal routing priority, drops providers to a degraded tier between 80 and 94 percent, and routes around anyone below 80 percent entirely. It tracks performance by time to first token and output tokens per second of generation time. Miss that bar and it’s your realized utilization that collapses, not your listed price.

Payout currency is another trap. Decentralized GPU networks such as io.net pay suppliers in their own token, not cash. In June 2026, io.net replaced its fixed emission schedule with what it calls an Incentive Dynamic Engine, tying payouts to a stable dollar target instead of a fixed token amount. The project itself frames that as a response to earnings instability under the old model. If a marketplace pays you in a token whose dollar value floats separately from the compute market, you’re now long a second asset on top of the hardware.

And if the same machine runs your own workloads, isolation comes before pricing. Ask whether a third party’s job gets a separate virtual machine, a separate container with enforced resource limits, or the same bare-metal environment as your own data and models. Then ask who’s liable if that boundary fails.

For deeper diligence on the counterparty, provider financing, and what happens if it goes under, see how do you vet a GPU cloud provider before you wire the deposit. For whether a reservation you already signed can be resold or exited at all, see can you resell GPU compute you already bought.

The checklist, in order

  1. Confirm your actual utilization, not your uptime. Compare your fully burdened owning cost per hour against the reserved rate you could sign today, not the on-demand rate, before you decide you have a utilization problem worth solving by selling.
  2. If selling a GPU-hour on spot: confirm who bears preemption risk, what the clearing price has done over the last quarter, and how fast it settles.
  3. If selling tokens: ask for the throughput you should actually expect on your hardware and model, not the headline per-token rate. Run the arithmetic yourself before trusting someone else’s revenue projection.
  4. Ask what uptime or performance threshold you must clear to stay in a marketplace’s primary routing pool, and what happens to pending earnings if you drop below it.
  5. Ask what currency you’re actually paid in, on what schedule, and whether its value can move independently of the compute market.
  6. If the hardware also runs your own workloads or holds your own data, ask exactly what isolation the marketplace guarantees between your jobs and a third party’s, and who’s liable if it fails.

You don’t need to be an engineer for any of this. You need to know your own breakeven before you take anyone’s utilization rule of thumb, and you need to know who carries the risk, in dollars, uptime and isolation, before you list anything.