Own the floor, rent the peak

Five years ago, almost every software company I knew had settled the question of where to run its computers. The cloud had won. Renting capacity by the hour removed the need to forecast, freed capital and let engineers provision a server in minutes rather than months. For general-purpose workloads I still think that settlement is mostly right. For GPU workloads, which now account for a fast-growing share of many software companies' costs, I think it deserves to be reopened, carefully and with numbers.

At Sternhollow GPUs do several kinds of work. They compute the lighting for game worlds, a process called baking that studios run through our hosted service before every milestone. They convert art assets into the formats each platform needs. They train the machine-learning models behind our animation-retargeting tools. And they run part of our automated testing, rendering thousands of frames each night to check that a change has not altered an image. In 2021 this cost us C$6.1 million in rented cloud capacity. By late 2023 the annualised figure was C$19.4 million, and some studios were waiting nine hours for a bake because our cloud region could not supply the GPUs we wanted.

Forecast by workload, not by headcount

The first mistake I see in GPU planning is forecasting demand as a single number. Companies take this year's GPU bill, apply a growth rate tied to customers or employees, and argue about the rate. That approach hides the most important fact about the workload, which is its shape.

Our workloads have very different shapes. Baking and asset processing follow our customers' production calendars: they run around the clock, rise before milestones and fall at holidays, but never fall to zero, because 3,100 studios do not all rest at once. Model training is lumpy: a few large runs a quarter, each needing many GPUs for days, then little. Nightly image testing is as regular as a clock. When we measured each workload hour by hour for twenty-six weeks, we could see what the single number concealed: a floor of demand that existed every hour of every week, and peaks of very different heights and durations above it.

Planning by workload also changes who owns the forecast. The team responsible for baking can explain why its demand rises; a finance model of total GPU spending cannot. We now ask each workload's owner for a quarterly forecast with a range, and we compare their forecasts with what actually happened. The first two quarters were humbling for everyone, including me.

The floor is lower than the average

The second mistake is sizing owned capacity to average demand. Average demand includes the peaks, and hardware bought to meet the average sits idle whenever demand falls below it. The case for owning rests on utilisation: a server that runs every hour of its life is far cheaper than renting the same hours, and a server that runs half the time may not be.

Our measurements showed a floor at about 60 per cent of median demand. We sized our purchase to that floor, 128 GPU servers in a colocation facility in Québec, where power is low-carbon and comparatively inexpensive, and we send everything above it to the cloud. A scheduler routes work to our own machines first and overflows the rest, giving priority to jobs whose owners face a customer deadline. Through 2025 our fleet ran at 74 per cent utilisation, and our all-in cost per GPU-hour fell from C$3.10 to C$1.45. Total GPU spending in 2025 was C$14.2 million, against C$27 million had we continued renting every hour at the prices we were paying.

Had we sized to the average instead, the fleet would have been about two-thirds larger, its utilisation markedly lower and the case much weaker. The discipline of buying for the floor is what made ownership worthwhile.

What the spreadsheet forgets

The third mistake is comparing a cloud price with a hardware price and stopping there. Owning brings costs that a pricing comparison omits, and we met most of them.

People come first. We had not run hardware at scale since 2014, and we hired nine specialists to do it. Their cost is in our C$1.45, but it was not in our first draft. Supply is the second. Our servers went live two months late because network switches arrived after the servers did, and the cloud bill ran on in the meantime. Failure is the third. In November 2024 a firmware fault took almost a third of the fleet offline for three days, and the overflow cost C$310,000. In the cloud that would have been someone else's problem.

Obsolescence is the cost I worry about most. GPU generations now arrive quickly, and each one changes the price of renting. Newer cloud instances have already narrowed the gap between our owned cost and what we would pay to rent. We depreciate the fleet over four years, and I now think three would have been more honest. When we buy again, we will buy in smaller tranches, so that no single generation dominates the fleet.

None of this argues for owning everything. Our peaks still belong in the cloud, and so does any workload whose shape we cannot yet measure. Model training, in particular, we continue to rent, because its demand is too lumpy for owned capacity to stay busy. The argument is narrower: once a GPU workload has a measured floor, renting all of it is a choice with a price, and boards should see that price.

The questions I would put to any board considering its GPU bill are therefore simple. What is the floor of our demand, measured hour by hour and workload by workload? Who forecasts each workload, and how accurate were they last quarter? What would owning the floor cost once people, delays, failures and a realistic depreciation life are included? And what happens to the case if rental prices fall by a third? A plan that survives those questions is worth approving. A plan built on the total bill and a growth rate is not yet a plan.