# Cloud vs on-prem costs: 2026 return on investment (ROI), rent or buy at 42% utilization?

Thomas Reed · November 14, 2026

> At 42% utilization, renting cloud compute usually beats buying on-prem because depreciation is charged across all calendar hours, not just productive ones.

| Takeaway | Detail |
| --- | --- |
| At 42% utilization, owned compute is usually the wrong pure-ROI call because depreciation is charged on 100% of calendar time while only about 42% of hours are monetized. | The break-even flips to 'buy' only when committed cloud rates exceed your all-in owned cost per productive hour. |
| Depreciation depends on utilization, and higher utilization spreads fixed depreciation across more revenue-generating days. | A camera at 50% utilization undergoes twice the physical wear of one at 25%, so the revenue difference must compensate for accelerated depreciation and maintenance. |
| Very low utilization can let depreciation dominate costs, as with SCI Pharmtech's Guanyin plant. | Next year's depreciation is NT$130 million with utilization at just 10%, and depreciation weighed on gross margin, down 2 points, in FY2026 Q3. |
| Use the reader rule: owned cost per productive hour equals annual depreciation plus power, maintenance, and idle power, divided by utilization-adjusted productive hours. | Compare that figure to your actual blended committed cloud rate; rent if cloud is lower, and buy only if committed cloud exceeds the all-in owned rate. |

At 42% utilization, buying owned GPU/compute is usually the wrong ROI call because calendar-time depreciation charges 100% of the asset while only about 42% of hours are monetized.

The answer flips to buy only when your committed cloud rate exceeds your all-in owned cost per productive hour.

![Cloud vs on-prem costs](https://static.mm-ais.com/article-images-ai/cloud-vs-on-prem-costs-2026-return-on-in-ai-5ee51ede.jpg)

## Why utilization drives depreciation cost

Depreciation is an accounting charge tied to calendar time, but the economic value of owned compute accrues only in the hours the hardware performs useful work. As OneSourceCloud notes in its GPU depreciation guidance, depreciation charges calendar time while value comes from productive hours, so the same scheduled expense buys less output when a fleet sits idle. That mismatch is the core mechanism behind utilization-driven cost: an underused asset does not become cheaper to carry simply because it is working less.

The capital-utilization literature formalizes this relationship. Research by K. Smith (1970), P. Taubman and H. Wilkinson (1970), and W. Oi (1981), summarized in the Academia.edu survey “Investment, Depreciation, And Capital Utilization,” establishes that depreciation is a function of the utilization rate. This gives a clear accounting basis for treating low utilization as a cost problem rather than merely a scheduling inconvenience: the rate at which capacity is exercised shapes how quickly capital value is consumed relative to the output it generates.

Utilization also affects the physical side of the asset, not just the allocation of a fixed accounting charge. Rental IQ’s equipment-utilization framework states the wear mechanism directly: an asset at 50% utilization is going through roughly twice the physical wear of one at 25%. When revenue or productive output does not keep pace with that accelerated wear, higher use can compress the economic life of the asset; when use is low, the calendar clock still advances even if physical wear accumulates more slowly.

To apply this mechanism, isolate depreciation in your own model: take the depreciation recognized over a fixed period and divide it by the hours in that period when the asset was actually productive. Holding the depreciation schedule constant, fewer productive hours mean each productive hour must absorb a larger share of the same calendar-time charge. This utilization-adjusted view makes the cost pressure visible before any broader ownership comparison, because it shows how much of the asset’s booked expense is being converted into monetized work.

![Why utilization drives depreciation cost — Cloud vs on-prem costs](https://static.mm-ais.com/article-images-ai/cloud-vs-on-prem-costs-2026-return-on-in-ai-fd383304.jpg)

## The evidence: utilization-cost convergence

SCI Pharmtech's FY2026 Q3 earnings call, as aggregated by Google News, reports next year's depreciation of NT$130 million with plant utilization at just 10%, dragging gross margin down 2 points. That is the extreme-case anchor: a fixed depreciation charge lands on a small base of productive hours, so the same NT$130 million becomes a larger share of each unit of output and compresses margin.

strategyforindustry.com's industry cost-curve analysis names "Asset Depreciation & Utilization Rate" as the primary cost driver. Its point is directional rather than numeric: higher utilization distributes fixed depreciation over more revenue-generating days, shifting a player left on the curve. The mechanism is the same as the SCI Pharmtech case—more productive days per unit of fixed cost—but expressed as a competitive-position claim rather than a single-company earnings line.

For a compute buyer, the practical reading is not that 10% utilization is typical, but that depreciation behaves like a fixed cost until utilization changes. The evidence therefore supports measuring owned cost per productive hour before comparing it to any committed cloud rate; the comparison is only meaningful after the denominator reflects actual utilization.

The SCI Pharmtech figure is a forward depreciation estimate from an earnings call, not an audited outcome, and the strategyforindustry claim is an industry cost-curve framing rather than a plant-level measurement. Use both as directional evidence that low utilization turns fixed depreciation into a margin line item, not as a universal threshold.

A useful check is to ask whether the depreciation line would still look large if utilization doubled or tripled. If the answer is no, the cost problem is not the asset's price alone; it is the mismatch between calendar-time charges and productive hours. That is the convergence point the two sources illustrate from opposite ends: one shows the margin damage at 10% utilization, the other shows the cost-curve benefit of spreading the same fixed charge across more revenue-generating days.

When applying this to GPU fleets, keep the comparison to committed cloud rates at the level of productive hours. The evidence does not establish a single break-even utilization percentage; it establishes that the denominator matters. A fleet at low utilization can make owned capacity look expensive even when the hardware price appears competitive, because the fixed charge is being divided by too few hours.

## Rent vs buy vs hybrid at 42%

At 42% utilization, rent. The asset's depreciation, power, and maintenance are spread over fewer than half of its productive hours, so owned cost per productive hour is roughly 2.4 times its fully-utilized equivalent (8,760 ÷ 3,679 productive hours). Cloud's bundled rate, with provider power, cooling, and data-centre overhead typically inside the hourly price, wins unless your committed rate is far below list — verify what your quoted rate actually bundles before comparing. That is the pure-ROI call at this utilization level.

The hybrid is to rent the spiky 58% of demand now and own nothing until two conditions are met: sustained utilization above the break-even level and a committed cloud rate above your all-in owned cost. That preserves the upside if utilization later rises while avoiding payment for idle ownership today, and it keeps the base layer flexible.

Before signing, compute owned cost per productive hour as annual depreciation plus power, maintenance, and idle power divided by utilization-adjusted productive hours, then compare it with your actual blended committed cloud rate. If the committed rate is lower, rent; if it is higher, revisit ownership. Use the same denominator every time so the comparison stays stable.

Keep the comparison honest by using your actual blended committed rate rather than list price, and treat 42% as a decision point rather than a universal threshold. Ownership can still win when your committed rate is far below list, but renting keeps capital free for workloads that reach higher utilization. Do not let a single busy week override the annualized calculation.

Re-run the same calculation whenever utilization changes. The break-even flips to buy only when committed cloud rates exceed your all-in owned cost, so a later rise in utilization can justify moving from rent to a hybrid or owned base without changing the underlying rule. Track the two triggers separately: utilization first, rate second. That keeps the decision reversible and tied to measured hours.

## Costs that decide the 42% question

Price the owned stack as a full annual cost, not just the invoice for the GPUs. Start with straight-line depreciation and choose the schedule explicitly—3, 5, or 6 years—because onesourcecloud.net shows the monthly cost differs materially by schedule. Then add the costs that are easy to omit: idle power draw while the fleet is not producing, maintenance and a failure reserve for spares and repairs, facilities such as space, cooling, and power delivery, and the opportunity cost of the capital tied up in the asset. These are the costs cloud pricing bundles away. Kunal Ganglani’s local LLM cost model is a useful checklist because it includes idle power, utilization, depreciation, failures, and opportunity cost in one spreadsheetable total.

Treat wear as utilization-dependent, not purely calendar-based. Rental IQ’s equipment example notes that a camera at 50% utilization goes through twice the physical wear of one at 25%, and that the revenue difference must compensate for accelerated depreciation and maintenance. Apply the same check to GPUs: a higher-utilization fleet may need a larger failure reserve and shorter effective life, while a 42%-utilized fleet still pays idle power and facilities for the unused hours.

Price the cloud stack with the same discipline. Use the committed-use or reserved hourly rate, add egress for the data you actually move, and include any provider overhead that is billed separately. Check whether the quoted hourly GPU rate already includes power and cooling; if it does, do not add those costs again. The comparison should use your actual blended committed rate, not a list price or a short-term on-demand rate.

Convert the owned stack to cost per productive hour: divide annual depreciation, power, maintenance, idle power, facilities, failure reserve, and opportunity cost by productive hours, where productive hours are 8,760 × utilization rate. At 42% utilization, that is about 3,679 productive hours per year. Compare that single number with the blended committed cloud rate for the same workload. If the owned figure is higher at 42% utilization, the gap is the price of carrying idle capacity; if it is lower, verify that your utilization measurement and committed-rate quote are both current.

| Owned stack | Cloud stack |
| --- | --- |
| Depreciation (3/5/6-year schedule), idle power, maintenance and failure reserve, facilities, opportunity cost of capital | Committed or reserved hourly rate, egress, separately billed overhead; power and cooling may already be bundled |

Before deciding, run two sensitivity checks: recompute the owned cost at 3 years and at 6 years, and recompute it with your actual cost of capital rather than a generic hurdle rate. A schedule or financing assumption that changes the ranking is a sign that the decision is close, not that one option is obviously cheaper.

## What the evidence does not establish

No source in the available sources set publishes a single universal break-even utilization percentage. The 42% figure is a scenario to test against your own rates, not a rule: whether owned compute wins depends on comparing your all-in owned cost per productive hour with your actual blended committed cloud rate.

The ResearchGate paper on capital utilization and maintenance costs was CAPTCHA-blocked, so its quantitative findings cannot be cited here. Treat any vendor claim such as "buy above X%" as unverified unless it is reproduced from your own cost model and assumptions.

The academic position treats depreciation as utilization-dependent, while straight-line accounting charges the same depreciation at 42% utilization as at 90%. Your P&L therefore does not show higher depreciation when use is low; it shows the same charge spread over fewer productive hours, so the accounting cost per productive hour changes even though the expense does not.

The practical test is to compute owned cost per productive hour as annual depreciation plus power, maintenance, and idle power, divided by utilization-adjusted productive hours, then compare it with your actual blended committed cloud rate. The break-even flips to buy only when that committed rate exceeds the all-in owned cost per productive hour, and at 42% utilization that comparison must be run with your own rates rather than assumed.

Because the depreciation line is calendar-based, a low-utilization fleet can look cheaper in accounting terms than it is in cash terms: idle power and maintenance still accrue, and the same depreciation is charged for less output. That is why the evidence here supports a method and a comparison, not a universal percentage.

If a vendor or internal model asserts a single threshold, ask for the underlying rate assumptions, the utilization definition, and whether depreciation is modeled as calendar-based or use-based. Without those details, the claim is not established by the evidence in this grounding set.

## 8-GPU node at 42%

Treat this as an illustrative method, not a quote: one 8-GPU node, 3-year straight-line depreciation, 8,760 calendar hours per year, and measured utilization of 42%, which gives about 3,679 productive hours per year before any uptime factor. Apply the uptime factor after these checkpoints; do not fold it into the 42% utilization figure.

| Checkpoint | Calculation | Input or observation |
| --- | --- | --- |
| 1 | Annual depreciation ÷ 3,679 productive hours | 42% measured utilization |
| 2 | Add idle power across all 8,760 calendar hours | Idle draw continues at 42% utilization |
| 3 | Summed annual owned cost ÷ 3,679, then compare to blended committed cloud rate | Cost per productive hour |

Checkpoint 1 is the depreciation cost per hour of useful output. The numerator is set by the 3-year schedule, while the denominator is the 3,679 productive hours, so the per-hour figure moves with utilization rather than with calendar time.

Checkpoint 2 adds idle power across the full 8,760 hours. Idle draw does not stop at 42%, so charging power only to productive hours understates owned cost. This follows the idle-power line item in Kunal Ganglani's local LLM total-cost model.

Checkpoint 3 divides the summed annual owned cost—depreciation, power, maintenance, and idle power—by 3,679, then compares that owned cost per productive hour to your actual blended committed cloud rate. Compare per productive hour, not per calendar hour, because the cloud rate buys the same useful output.

Cost of being wrong, both directions: if you buy and utilization stays at 42%, you carry depreciation and idle power for 8,760 hours while monetizing about 3,679. If you rent and utilization later rises, you pay the committed cloud rate for hours an owned node could have served at the checkpoint-3 owned rate. The break-even is the utilization level where those two excess costs cross.

Rerun all three checkpoints whenever measured utilization changes or the committed cloud rate is renegotiated. A node that fails checkpoint 3 at 42% can pass later if higher utilization shrinks depreciation per productive hour enough.

## Worked Example: Run the Numbers

Illustration only, not a quote or vendor offer: a finance team evaluates one owned GPU pool for the 2026 planning year at a fixed 42% utilization, with the all-in annual cost defined as annual depreciation plus power, maintenance, and idle power. The comparison figure is the team's actual blended committed cloud rate.

| Step | Calculation | Result |
| --- | --- | --- |
| 1 | Productive hours = 42% × 8,760 hours | 3,679.2 hours |
| 2 | Owned cost per productive hour = (annual depreciation + power + maintenance + idle power) ÷ 3,679.2 | All-in annual cost ÷ 3,679.2 |
| 3 | Compare the Step 2 quotient with the blended committed cloud rate | Lower rate wins |

On these inputs, renting wins unless the blended committed cloud rate is higher than the owned cost per productive hour; that inequality is the break-even trigger, and buying becomes the better pure-ROI call only when committed cloud rates exceed the all-in owned cost per productive hour.

Check the result with your actual utilization rather than the 42% illustration, and keep idle power in the numerator; omitting it understates owned cost. If utilization rises, productive hours rise and the owned cost per productive hour falls, so the trigger moves with the real operating data.

## Decision rules for the rent-or-buy call

Apply a trailing two-quarter utilization gate before committing capital: measure productive hours over the prior six months rather than reacting to a single bursty quarter. This smooths seasonal demand and prevents a short spike from justifying a long-lived asset. The rules below translate that measurement into a rent-or-buy call.

**Rule 1 — Rent below 55% utilization.** If measured utilization is below 55% on a trailing two-quarter basis, rent. At 42% utilization, you are paying for an asset whose output you monetize less than half the time, and no realistic committed cloud rate loses to that math. Treat 55% as the minimum threshold for even beginning an ownership evaluation.

**Rule 2 — Rent without a durable margin.** If your owned cost per productive hour (annual depreciation, power, maintenance, and idle power, divided by utilization-adjusted productive hours) is not at least 30% below your actual blended committed cloud rate, rent. A thin margin does not compensate for refresh risk, failure reserves, and idle power you now carry. As Kunal Ganglani’s 2026 local LLM cost model notes, a credible comparison must include idle power, utilization, depreciation, failures, and opportunity cost—not a vendor’s headline figure.

**Rule 3 — Qualify ownership above 60%, with exceptions.** If utilization exceeds 60% for two consecutive quarters and your computed owned cost clears the 30% margin, ownership becomes financially plausible. The **stranded-facilities exception** overrides this: if you lack reliable power, cooling, physical space, or the operational staff to sustain the fleet, continue to rent even when utilization is high, because facility constraints can strand capital as effectively as idle hardware.

| Condition (trailing two quarters) | Decision | Rationale |
| --- | --- | --- |
| Utilization below 55% | Rent | Insufficient productive hours to justify fixed ownership costs |
| Owned cost per productive hour not ≥30% below committed cloud rate | Rent | Margin too thin to absorb refresh, failure, and idle-power risk |
| Utilization above 60% and margin ≥30%, but facilities or operations are inadequate | Rent (stranded-facilities exception) | Infrastructure constraints prevent reliable monetization of owned capacity |

## What to do next

| Step | Action | Why it matters |
| --- | --- | --- |
| 1 | Compute owned cost per productive hour from annual depreciation, power, maintenance, and idle power divided by utilization-adjusted productive hours. | It creates the all-in owned benchmark to compare against your actual blended committed cloud rate per hour. |
| 2 | Compare that owned cost per productive hour to your actual blended committed cloud rate per hour and move toward buy only if owned is at least 30% below cloud. | The break-even flips to buy only when committed cloud rates exceed all-in owned cost per productive hour. |
| 3 | Require utilization to be contractually stable above ~60% for the depreciation period before treating a buy case as valid. | At 42% utilization, depreciation is charged on 100% of calendar time while only about 42% of hours are monetized. |
| 4 | Stress-test depreciation dominance using SCI Pharmtech's Guanyin plant: NT$130 million next-year depreciation at 10% utilization. | Very low utilization can let depreciation dominate costs and weigh on gross margin. |
| 5 | For a camera, if utilization rises from 25% to 50%, account for twice the physical wear and require the revenue difference to compensate accelerated depreciation and maintenance. | Higher utilization spreads fixed depreciation across more revenue-generating days, but wear increases. |
| 6 | Re-run the same owned-vs-cloud comparison before 2026 commitments rather than assuming the 42% case has changed. | Depreciation depends on utilization, so the rent-or-buy answer changes with utilization. |

## Frequently Asked Questions

**When does the break-even flip from renting cloud to buying owned compute?**

The break-even flips to buy only when committed cloud rates exceed your all-in owned cost per productive hour.

**How should a reader calculate owned cost per productive hour?**

Owned cost per productive hour equals annual depreciation plus power, maintenance, and idle power, divided by utilization-adjusted productive hours, and you rent if cloud is lower while buying only if committed cloud exceeds that all-in owned rate.

**Why is buying owned GPU or compute usually the wrong pure-ROI call at 42% utilization?**

At 42% utilization, calendar-time depreciation charges 100% of the asset while only about 42% of hours are monetized.

**What does the camera wear example imply about higher utilization?**

A camera at 50% utilization undergoes twice the physical wear of one at 25%, so the revenue difference must compensate for accelerated depreciation and maintenance.

**What edge case shows depreciation dominating costs at very low utilization?**

SCI Pharmtech's Guanyin plant shows this, with next year's depreciation at NT$130 million and utilization at just 10%, and depreciation weighed on gross margin, down 2 points, in FY2026 Q3.

**How does higher utilization affect depreciation?**

Higher utilization spreads fixed depreciation across more revenue-generating days.

## Quick answers

| At the stated utilization level, is it usually better to rent or buy owned compute? | At the stated utilization level, owned compute is usually the wrong pure-ROI call because depreciation is charged on all calendar time while only a portion of hours are monetized. |
| --- | --- |
| When does the break-even flip to buying owned compute? | The break-even flips to buy only when committed cloud rates exceed your all-in owned cost per productive hour. |
| How should you calculate the owned cost per productive hour? | Owned cost per productive hour equals annual depreciation plus power, maintenance, and idle power, divided by utilization-adjusted productive hours. |
| How does utilization affect depreciation and wear? | Higher utilization spreads fixed depreciation across more revenue-generating days, but increased usage also accelerates physical wear and maintenance compared to lower utilization levels. |
| What example illustrates the impact of very low utilization on costs? | SCI Pharmtech's Guanyin plant illustrates this, where next year's depreciation at a very low utilization rate dominated costs and weighed on gross margin in the cited fiscal quarter. |

Also worth reading: **2026 SOX 404: AI Monitoring 40% Claim Needs Context**: [2026 SOX 404: AI Monitoring](https://cleoai.tech/blog/2026-sox-404-ai-monitoring-40-claim-needs-context.php) · **2026 Cash Flow: Gradient Boosting Cuts MAPE 18% vs ARIMA**: [2026 Cash Flow: Gradient Boosting](https://cleoai.tech/blog/2026-cash-flow-gradient-boosting-cuts-mape-18-vs-arima.php) · **2026 Test: LLM Rate Lookups Miss 15.8% in ASC 830 Close**: [2026 Test: LLM Rate Lookups](https://cleoai.tech/blog/2026-test-llm-rate-lookups-miss-158-in-asc-830-close.php)

### Related reading

- [October Core CPI Surprise: +0.3% vs +0.2% — Shadow-Run the Reforecast](https://cleoai.tech/blog/october-core-cpi-surprise-03-vs-02-shadow-run-the-reforecast.php)
- [2027 Tax Brackets in FP&A: Automate Rate Tables Before Sunset Provisions](https://cleoai.tech/blog/2027-tax-brackets-in-fpa-automate-rate-tables-before-sunset-provisions.php)
- [JetBlue Bag Fees 2026: 3rd Hike in 12 Months vs Fuel Threshold](https://cleoai.tech/blog/jetblue-bag-fees-2026-3rd-hike-in-12-months-vs-fuel-threshold.php)
- [ASC 842 Lease Review Costs: Verify the $39 Manual Rate Before Committing](https://cleoai.tech/blog/asc-842-lease-review-costs-verify-the-39-manual-rate-before-committing.php)
- [Transaction matching software: BlackLine 95% cutoff shifts 28% interco lines to manual](https://cleoai.tech/blog/transaction-matching-software-blackline-95-cutoff-shifts-28-interco-lines-to-manual.php)
- [Berkshire Hathaway Class B: how to verify the 2026 high before you commit](https://cleoai.tech/blog/berkshire-hathaway-class-b-how-to-verify-the-2026-high-before-you-commit.php)

### Latest

- [October Core CPI Surprise: +0.3% vs +0.2% — Shadow-Run the Reforecast](https://cleoai.tech/blog/october-core-cpi-surprise-03-vs-02-shadow-run-the-reforecast.php)
- [2027 Tax Brackets in FP&A: Automate Rate Tables Before Sunset Provisions](https://cleoai.tech/blog/2027-tax-brackets-in-fpa-automate-rate-tables-before-sunset-provisions.php)
- [JetBlue Bag Fees 2026: 3rd Hike in 12 Months vs Fuel Threshold](https://cleoai.tech/blog/jetblue-bag-fees-2026-3rd-hike-in-12-months-vs-fuel-threshold.php)

Canonical: https://cleoai.tech/blog/cloud-vs-on-prem-costs-2026-return-on-investment-roi-rent-or-buy-at-42-utilization.php
Markdown: https://cleoai.tech/blog/cloud-vs-on-prem-costs-2026-return-on-investment-roi-rent-or-buy-at-42-utilization.php/index.md