A GPU cluster profit margin calculator is only ever this: rate times hours times utilization times GPU count, minus costs. An 8-GPU H100 node at 50% utilization and one at 95% run identical hardware, draw close to the same power, and carry close to the same fixed cost; the difference between them, in dollars, is the entire question this post answers. Every financing and depreciation post on this blog touches utilization somewhere, but none of them has laid out, side by side, what an H100, H200, or B200 node actually bills at 50%, 70%, 85%, and 95% booked hours, and where the line sits between a node that pays for itself and one that doesn't.
TL;DR: The GPU Cluster Profit Margin Calculator by Utilization in 2026
An 8-GPU H100 node's monthly revenue is Rate x Hours x Utilization x GPU count: at Spheron's on-demand rate of $2.64/hr per GPU, as of 18 Oct 2026, the gap between 50% and 95% utilization on that same hardware is close to double the monthly bill.
- Formula: Revenue = Rate x Hours x Utilization x GPU count; Margin = (Revenue - Costs) / Revenue x 100.
- Rate: Spheron's H100 on-demand rate is $2.64/hr per GPU, as of 18 Oct 2026; see the worked revenue table in this guide for dollar figures at 50%-95% utilization, frozen at the rate captured 17 Oct 2026.
- Build vs run: an 8-GPU H100 node costs $222,000-$383,000 to build and $6,800-$18,900/month to run.
- Break-even: roughly 55-65% after depreciation, or 60-70% for ownership to beat renting.
- Spot caveat: 90% booked hours on spot can mean fewer productive hours once reclaims hit.
- Compare GPU cloud pricing across hyperscalers and neoclouds.
The GPU Cluster Profit Margin Calculator Formula: Rate x Hours x Utilization x GPU Count
Every number in this post comes from one formula, and it is worth writing out before the tables start, because the formula is also the profit-margin calculator the title promises:
Monthly node revenue = Rate ($/GPU/hr) x Hours in month x Utilization (%) x GPU count
Profit margin (%) = (Revenue - Costs) / Revenue x 100
Revenue is the easy half. Hours in month is a constant (730, using the standard 365 x 24 / 12 conversion). GPU count is fixed by the node you built or rented (8 GPUs is the standard node size referenced throughout this post). Rate and utilization are the two variables that actually move, and they move independently: rate is set by the market you're selling into, utilization is set by how much of your capacity you actually book.
Costs are the harder half, and the next section breaks them down. But the margin formula itself never changes: take whatever revenue the first formula produces, subtract your all-in monthly cost (operating expenses plus a monthly depreciation charge), divide by revenue, and multiply by 100. A node earning $14,647 a month against $13,000 in costs is running an 11.2% margin. The same node at $7,709 in revenue against that same $13,000 cost base isn't running a margin at all, it's running a loss. Utilization is the only lever in that sentence that doesn't require buying anything new, which is why the rest of this post spends so much time on it.
For the cost side of the H100 ownership question specifically, including what the card itself costs against renting the same capacity, see our H100 GPU price breakdown.
H100, H200, and B200 Node Revenue at 50%, 70%, 85%, and 95% Utilization
The table below applies the formula above to Spheron's on-demand rates for H100, H200, and B200, each per-GPU figure frozen at the value captured on 17 Oct 2026 so the arithmetic in this section stays checkable. Rates move with marketplace supply and demand, so check the current GPU pricing before using these for a real budget; the formula, not the frozen numbers, is what to reuse.
| Utilization | H100 node (8x $2.64) | H200 node (8x $4.80) | B200 node (8x $9.70) |
|---|---|---|---|
| 50% | $7,708.80 | $14,016.00 | $28,324.00 |
| 70% | $10,792.32 | $19,622.40 | $39,653.60 |
| 85% | $13,104.96 | $23,827.20 | $48,150.80 |
| 95% | $14,646.72 | $26,630.40 | $53,815.60 |
Pricing fluctuates based on GPU availability. Spheron rates above are frozen as of 17 Oct 2026 for this worked example; other providers reflect their own published rates and may have changed. Check current GPU pricing → for live rates.
Two things jump out. First, the gap between 50% and 95% is roughly double, for every GPU generation: going from half-booked to nearly-full books isn't a marginal improvement, it's close to doubling revenue on hardware that already exists. Second, B200's revenue ceiling is close to four times H100's at the same utilization, which matters for the margin question in the next section, since B200's hardware cost and power draw scale up too, just not necessarily in the same ratio.
Market rates for the same hardware span a wider range than Spheron's single rate implies. Checked in October 2026, H100 SXM5 rental rates across the broader market ran $1.40 to $2.70 per GPU per hour, and B200 SXM ran $3.75 to $6.99, per packet.ai's utilization-income breakdown. Run the table above with your own achievable rate; the shape of the curve (roughly linear with utilization, holding everything else fixed) doesn't change.
That same analysis puts a number on the utilization lever directly: moving an 8-GPU H100 fleet from 30% to 90% utilization at $2.70/hr adds approximately $9,461 a month, or $113,530 a year, from the same rack with no additional capital spend. That's the entire thesis of this post compressed into one sentence.
What Eats the Margin: Power, Colocation, Staff, and Depreciation Per Node
Revenue is the number everyone quotes. Margin is the number that decides whether the node was worth building. An 8-GPU H100 node's all-in build cost, covering GPUs, chassis, networking, storage, and rack and PDU hardware, runs $222,000 to $383,000, and the same node's monthly operating cost (power, colocation, bandwidth, staff, software, and insurance) runs $6,800 to $18,900, per GPUnex's 2026 GPU cluster economics breakdown.
Put that opex range next to the revenue table above and the picture gets uncomfortable fast. At 50% utilization, an H100 node on Spheron's on-demand rate bills $7,708.80, which clears the low end of GPUnex's opex range but not the high end. Even at 95% utilization, $14,646.72 in revenue still sits under the top of that $18,900 opex band, before a single dollar goes toward recovering the $222,000-$383,000 the node cost to build. Thin margins on expensive hardware is the normal case here, not the exception.
Scale changes the shape of the cost side more than it changes the margin. A 100-GPU H100 cluster's power bill alone runs roughly $420,000 a year, on GPUaaS's own assumption of $0.12/kWh electricity and a 1.4 PUE, a figure that already has cooling overhead baked into it rather than sitting on top, according to GPUaaS's real TCO analysis. Continuous power draw at 1,024 GPUs works out to approximately 1.76 MW for H100, against about 1.8 MW for a comparable B200 deployment, per the same source. B200's per-GPU power draw isn't dramatically higher than H100's at that scale, which is part of why its revenue ceiling in the table above looks so favorable. On the capital side, a 256-GPU B200 cluster built and colocated runs about $12M in hardware and $15.5M in all-in three-year TCO, working out to roughly $2.88 per GPU per hour at 80% utilization, per the same GPUaaS analysis. Choosing which generation to deploy in the first place is a workload question as much as a cost one; our best GPU for AI inference guide covers which models and batch sizes actually justify B200's higher build cost over H100.
A separate model of a 100-H100 cluster, from Mercatus's GPU ROI analysis, puts rough numbers on the ownership side specifically: $4.5M in capex, a $1.1M residual value (25% of capex) at year three following an H100 depreciation curve, an operating cost of $0.41 per GPU-hour covering power, colocation, and ops, and $269,370 in annual opex at 75% utilization. That same model's three-year IRR against a $2.50/hr mixed-cloud baseline comes out to roughly 8% at 75% utilization, climbing to about 13% at 85% and about 18% at 95%. Ten utilization points, in that model, is worth more to the return than most hardware decisions a buyer will make.
Where the Break-Even Sits (and What Pushes a Cluster Below It)
The honest answer is that break-even utilization isn't one number, it's a range that depends on which costs you count and which source you trust, and even a single source doesn't land on one clean figure. That's less a contradiction to resolve than a sign of how source-dependent the number really is. GPUaaS, modeling the buy-versus-rent decision rather than pure opex coverage, finds owned hardware typically beats renting above roughly 60-70% sustained utilization, depending on GPU generation and electricity rate. Taken together, the practical takeaway is that a node running meaningfully below 55% utilization is very likely underwater on a fully-costed basis, and one running above roughly 70% has a real shot at beating the rental alternative outright.
What pushes a cluster below that line in practice usually isn't a pricing problem, it's a debt-service problem layered on top of an idle-capacity problem. CoreWeave is the clearest public example of what happens when financed scale outruns realized utilization. The company's total principal of debt grew from $8.0 billion at the end of 2024 to $8.8 billion by the end of Q1 2025, per its own SEC filing, and its quarterly interest expense hit $640 million in a recent quarter, 2.4 times what it was a year earlier, according to reporting by The Motley Fool. None of that debt service shows up in the per-node opex ranges above; it's a separate claim on revenue that only gets heavier as a fleet scales, and it makes the break-even utilization threshold a moving target rather than a fixed one. For the pricing structure behind that debt-financed growth, see our CoreWeave GPU pricing breakdown.
On-Demand vs Spot: Why "Utilization" Isn't the Same Number for Every Tier
Every calculation above treats utilization as booked hours over available hours, which is the right definition for on-demand capacity. It's the wrong definition for spot. A spot node showing 90% booked hours in a dashboard has not necessarily delivered 90% of a month's worth of productive compute, because every reclaim costs more than the interrupted hour itself: there's a cold-start gap before the workload resumes somewhere else, and depending on the job, a checkpoint that didn't quite save in time.
That gap is not theoretical. In testing inference workloads on Spheron's own fleet, every 8-GPU spot instance type used was reclaimed at least once on 14 Oct 2026. If you're serving inference on spot capacity, the practical takeaway is to keep spare capacity in reserve and build automatic recovery into the serving layer, rather than assuming a booked-hours percentage translates directly into served-hours.
This is also why spot and on-demand rates shouldn't be assumed to sit in a fixed order relative to each other. Spheron's own spot and on-demand pools are priced from different pools of supply and move independently; check both rates on the day you provision rather than assuming spot is always cheaper. The same caution applies to utilization: a 90% booked-hours figure on a spot fleet and a 90% booked-hours figure on an on-demand fleet are not the same claim about revenue, because only one of them has reclaim overhead subtracted from it already. Build the margin calculation in the formula above using productive hours, not booked hours, whenever spot capacity is in the mix.
How to Raise Utilization Without Buying More Hardware
Given the table above, the fastest margin improvement available to most node owners isn't a better GPU, it's a higher percentage on hardware already running. A few levers that don't require new capex:
- Mix workload types. A node serving only bursty, business-hours inference traffic will structurally cap out somewhere in the 50-70% range. Layering in batch or training jobs that can fill overnight and weekend gaps raises the denominator without adding a GPU.
- List on more than one demand channel. A node that only takes bookings from one sales relationship is utilization-capped by that relationship's deal flow, not by the hardware.
- Price the floor, not the ceiling. A rate set too high to compete leaves capacity idle; a rate set with no floor at all leaves money on the table during periods of genuine scarcity. Either mistake shows up as lost utilization, not as a pricing error anyone notices directly.
- Build reclaim-tolerant serving for spot capacity, per the section above, so interrupted hours convert back into billed hours faster.
The demand-aggregation lever is where a marketplace actually changes the math, because an owner sitting at 55% utilization has an idle-capacity problem, not a pricing problem. Spheron's supplier program routes buyer demand to GPU owners directly: buyers come to Spheron looking for specific GPUs, and owners get qualified requests without cold outreach, paid ads, or a sales hire. Spheron doesn't run a reverse auction either, owners set the price floor and approve each deal themselves, which keeps the pricing lever in the section above in the owner's hands rather than racing it to the bottom.
That said, Spheron's program routes demand, it doesn't guarantee a utilization level or a revenue outcome; the capex, opex, and depreciation risk modeled throughout this post still sits with the owner. It's also not the right fit for an owner who wants a reseller to operate capacity under its own brand, or who needs a counterparty to mediate disputes after a contract is signed, and it offers no help picking a price floor for an owner who hasn't thought about one yet. For an owner who already knows roughly what they need to charge and just needs more of the booked-hours side of the formula filled in, it's a direct answer to the exact lever this post has been arguing matters most.
If idle capacity, not pricing, is what's holding your node's margin below break-even, the fastest fix is more qualified demand, not a rate change.
Frequently Asked Questions
Profit margin = (Revenue minus Costs) divided by Revenue, times 100. Revenue is Rate x Hours x Utilization x GPU count: an 8-GPU H100 node renting at Spheron's on-demand rate of $2.64/hr per GPU, as of 18 Oct 2026, for 730 hours a month at 70% utilization bills Rate x 8 x 730 x 0.70 (see the worked revenue table in this guide for the dollar figure at the rate captured 17 Oct 2026). Costs are monthly operating expenses (power, colocation, bandwidth, staff, software, insurance) plus a monthly share of depreciation on the hardware. Subtract costs from that revenue figure, divide by revenue, and multiply by 100 to get the margin percentage. Run it at your own utilization and cost numbers; the formula does not change, only the inputs do.
At Spheron's on-demand rate of $2.64/hr per GPU, as of 18 Oct 2026, an 8-GPU H100 node billing 70% of 730 monthly hours brings in Rate x 8 x 730 x 0.70; at the rate captured 17 Oct 2026, that worked out to roughly $10,792 (see the revenue table in this guide). GPUnex puts an 8-GPU H100 node's monthly operating cost at $6,800 to $18,900, so at 70% utilization that revenue clears the low end of the opex range but can still fall short of the high end before any hardware depreciation is counted.
Estimates vary by source and by what is counted. GPUnex puts break-even on operating costs alone at around 60% utilization for an 8-GPU H100 node, and a separate 55-65% range once depreciation is fully loaded in, a range that straddles rather than clearly tops that 60% figure. GPUaaS frames it differently: it finds owned hardware only beats renting above roughly 60-70% sustained utilization, depending on GPU generation and electricity rate. Either way, a node idling below the mid-50s to high-60s percent range is a common threshold where ownership stops paying for itself.
