The Bare Metal Return Isn't a Homecoming -- It's a New Landlord

On March 11, 2026, a storage vendor named Cloudian put a number on something a lot of companies were already doing quietly. In a survey of 203 enterprise IT decision-makers, 93 percent said they had already moved AI workloads off public cloud, were in the middle of doing it, or were actively deciding whether to. That same quarter, Broadcom ran its own separate survey and found something just as telling: for the first time, cost had overtaken security as the single biggest complaint enterprises have about public cloud.

Both companies sell something that benefits from that story. Cloudian sells storage you keep yourself. Broadcom sells the software that runs your own data center. Read past the numbers, though, and the pattern underneath them is real, and it's been building all year: companies running AI workloads are backing away from the virtualized public cloud they signed up for five years ago, and going somewhere described, almost universally, as "bare metal."

Everyone covering this wrote it up as a homecoming — a return to control, to predictability, to owning your own infrastructure again. Almost nobody asked the obvious follow-up question: who actually owns the hardware this homecoming is landing on?

So if "the return to bare metal" mostly isn't a return to owning your own servers, what exactly are you returning to — and whose balance sheet is it sitting on?

What's Actually Driving Companies Off Virtualized Cloud#

The repatriation that usually isn't repatriation

"Repatriation" is the word the industry uses for moving a workload back out of public cloud. It's a slightly misleading word, because most of what's happening isn't a company moving a workload back into its own building. It's a company moving a workload from one rented arrangement to a different rented arrangement that happens to look more like the hardware they used to own.

Here's the plain-language version of what changed. Public cloud, since roughly 2010, has mostly meant virtualized computing: you don't get a physical server, you get a slice of one, carved up by software called a hypervisor so that dozens of customers can share the same machine without seeing each other's data. Think of it like an apartment building — you get your own locked unit, but the plumbing, the electrical, and the walls are shared infrastructure the landlord controls and optimizes across every tenant at once. That sharing is exactly what makes cloud computing cheap and flexible. It's also exactly what a growing number of AI teams say is costing them performance and money they can't fully explain on a bill.

"Bare metal" is the opposite of the apartment building: a dedicated physical machine, no hypervisor, no shared plumbing, no neighbor whose workload can slow yours down. For a decade it was a niche option, mostly for database and legacy workloads that needed guaranteed, unshared performance. In the last eighteen months, AI engineers — not old-school administrators who distrust virtualization on principle — have become the people asking for it, because they ran the numbers on what the shared-plumbing model costs them when the workload is training or running a large AI model instead of serving a website.

The performance problem hiding inside the word "cloud"

Here's where the analogy needs a second floor. Virtualizing a graphics processor — the specialized chip that does the actual math behind AI model training — doesn't cost the same tax every time. It depends entirely on how it's shared.

If your workload gets a graphics processor attached directly to your virtual machine with modern direct-attachment techniques, the tax is close to nothing — benchmarks from VMware's own performance engineering team put single-chip direct attachment at 0 to 2 percent overhead on current virtualization software. That's a rounding error.

The tax shows up when the chip is time-sliced — shared in rotating turns among several customers, the way a conference room gets booked in thirty-minute blocks. VMware's benchmarks show that configuration costing 4 to 12 percent for workloads that are mostly doing math, and up to 25 percent for workloads that spend a lot of time waiting on memory, when several tenants are competing for the same chip at once. Stretch that across many machines working together on one large training job, and the gap widens further: one set of published benchmarks found distributed training setups losing 18 to 35 percent of their speed compared to a dedicated setup, with congested, heavily-shared configurations losing far more than that.

There's real disagreement in the data here, and it's worth naming rather than smoothing over. A separate measured study found some virtualized graphics-processor setups delivering only 65 to 76 percent of the dedicated machine's peak output, while another found a different virtualized configuration landing at 94 to 100 percent of bare-metal performance for a different workload shape. The honest summary: the performance gap ranges from nearly nothing to very large, and which end you land on depends almost entirely on whether your workload gets a chip to itself or shares one, and how many machines have to work together at once. A company running a single AI model to answer customer questions has very little performance reason to leave virtualized cloud. A company training a large model across dozens of machines at the same time has a real one.

The landlord nobody vetted

This is the part that gets skipped in most of the coverage, and it's the part worth your attention. When a company decides it wants that dedicated-hardware performance, it rarely buys a data center. Buying and running physical computers is capital-intensive, slow, and a business most companies have no interest in being in. Instead, the money goes to a newer class of company — in the industry, "neoclouds" — built specifically to rent out dedicated graphics-processor hardware without the broader cloud platform wrapped around it. CoreWeave, Lambda, Crusoe, and Nebius are the best-known names.

The price difference is the whole pitch. As of roughly early-to-mid 2026, the major hyperscalers — Amazon, Microsoft, and Google — charge somewhere around $7 to $12 per hour for a single high-end graphics processor rented on demand. The neoclouds charge roughly $2 to $4 for the same NVIDIA hardware, and some charge nothing extra to move your own data back out, where the hyperscalers typically charge a data-out fee for exactly that. Specialized providers running 50 to 75 percent cheaper than the biggest names in computing sounds like a straightforward win, and for a lot of companies the math genuinely does work out that way.

Here's the question almost nobody in that transaction is asking: how is a company with a fraction of a hyperscaler's balance sheet renting the same chip for a third of the price? Part of the answer is real — neoclouds skip the broad platform of services (databases, security tooling, compliance certifications) that hyperscalers bundle in and charge for, and they run leaner operations built around one product. But part of the answer is a bet on an asset that may not hold the value everyone is pricing it at.

Graphics processors lose value on a schedule set by NVIDIA, not by accountants. The company has released a new, faster chip architecture roughly every year, and each release pushes down what the previous generation is worth, the way a smartphone's resale value drops when a new model comes out. How fast that happens is exactly what is being argued about. The hyperscalers, for accounting purposes, currently spread the cost of their chips over 5 to 6 years. A visible and vocal line of critics — most prominently investor Michael Burry, in an analysis that's been reported independently by several financial outlets — argues the real usable life is closer to 2 to 3 years, and that stretching the schedule understates how fast these assets actually wear out economically, by a cumulative figure north of $150 billion industry-wide by 2028 on his math. The hyperscalers and NVIDIA's own leadership dispute that, arguing older chips keep plenty of value running smaller, less demanding AI workloads even once they're no longer competitive for the biggest training jobs. Nobody has settled this argument, and you don't need it settled to notice the shape of the risk: a lot of money has been borrowed against the assumption that these chips hold their value for years, and that assumption is now openly disputed.

Here's why that argument matters to you and not just to accountants. Reporting on data-center financing puts the current scale of debt backed directly by graphics-processor hardware as collateral above $20 billion. A hyperscaler the size of Amazon or Microsoft can absorb a bad bet on how fast a chip loses value — it's a rounding error on a balance sheet with hundreds of billions of other assets. A neocloud built around a few data centers and a pile of that borrowed money cannot absorb the same bet nearly as easily. If a chip's resale value drops off the cliff the way the history above suggests, the company most exposed to that air pocket isn't the hyperscaler you left. It's the newer, leaner provider now holding your contract.

Hyperscalers didn't sit still for this

The last piece completes the picture, and it complicates the simple "escape the cloud" story further. Amazon and Oracle both now sell dedicated, no-hypervisor machines directly, inside the exact same contracts and billing relationships companies already have with them. Oracle has offered this for years and has extended it with dedicated graphics-processor configurations built for AI training. Amazon's own bare-metal computing instances, which the company markets as delivering meaningfully better performance than its virtualized options for the same workload class, mean a company can often get the dedicated-hardware benefit without signing a single new vendor relationship, filing a single new security review, or leaving its existing compliance footprint at all.

For a real share of the companies chasing "the return to bare metal," the fastest and lowest-risk move is a conversation with the account representative they already have, not a new contract with a company they've never vetted.

When "Owning Your Infrastructure" Means Owning Someone Else's Risk#

Here's the structural problem underneath all of this, and it's the reason the usual advice doesn't fully solve it. The standard answer to any concentration risk is "diversify" — use more than one vendor so a single failure doesn't take you down. That advice works when the risk is operational: one data center catches fire, one network link gets cut, you fail over to the other one. It works much less well here, because the risk sitting underneath every one of these providers — hyperscaler, neocloud, or your own purchased hardware — is the same risk: the same NVIDIA chip, depreciating on the same schedule, subject to the same once-a-year architecture jump. Signing contracts with three different neoclouds doesn't diversify you out of that exposure. It just means you're carrying the same bet in three places instead of one.

AI startups that built their entire training infrastructure on a single neocloud relationship found this out the hard way earlier in the cycle, when contract renegotiations and provider consolidation left them re-shopping for compute mid-build. Enterprises signing multi-year capacity deals to lock in today's price are making a quieter version of the same bet: that the provider on the other end of a multi-year contract will still be standing, on the same terms, when the next chip generation resets what that hardware is actually worth.

The chip you're renting and the chip the provider financed are the same chip, and they're both aging on the same clock.

This is also why the loudest argument for bare metal — better, more predictable performance — and the quietest risk in bare metal — counterparty exposure to an asset that may be worth far less in two years — sit on exactly the same decision. You don't get to pick up the performance benefit and leave the balance-sheet question behind. They're the same contract.

How This Impacts Your Organization#

The underlying principle doesn't change with company size: a real performance driver (shared, virtualized graphics processors cost some workloads real speed) is colliding with a real financial risk (the hardware behind the alternative may be worth much less, much sooner, than its price assumes). What changes by size is how much of that performance problem you actually have, how much leverage you have over a provider's contract terms, and how much of the balance-sheet risk you can see — let alone negotiate around.

Large Enterprises (1,000+ employees)

If you're running large, multi-machine AI training jobs, you're the segment most exposed to the real end of the performance gap — the 18 to 35 percent and worse figures above are describing your workload, not a single researcher's side project. You're also the segment with the most leverage to do something about the balance-sheet question nobody else is asking: you likely already have an enterprise agreement with at least one hyperscaler, which means the first and cheapest move is asking your account representative for dedicated-hardware pricing before signing anything new. If you do sign with a newer provider, your legal team has the standing to negotiate price-protection, early-termination, or financial-health disclosure clauses tied to that provider's own balance sheet — most companies at your scale simply haven't thought to ask for them yet. This quarter: inventory every AI workload currently virtualized across every business unit, flag which ones are actually large enough to justify the performance argument, and have procurement ask one direct question of any non-hyperscaler bidder — how is your pricing possible, and what happens to our contract if your financing changes.

Companies in the hundred-to-a-thousand-employee range

You feel this one fastest, because the engineer or IT director who signed your first graphics-processor contract is usually the same person who'll be asked to defend the decision eighteen months later. The overcorrection to avoid is signing a multi-year neocloud contract for the price advantage alone, without reading past the price line to the termination and renewal terms. Three moves that don't require a platform team: run the actual performance numbers on your own workload before assuming you need dedicated hardware at all — a lot of what gets sold as a performance problem is a workload too small to need the fix; ask any non-hyperscaler provider directly what happens to your contract and your data if they're acquired, restructured, or run out of financing, and get the answer in writing; and check your existing hyperscaler contract for a bare-metal or dedicated-instance option before evaluating anyone new — it's often already sitting there, unused, inside the agreement you already pay for.

Small & Growing Organizations (under 100 employees)

Honest counsel: you almost certainly don't have a real version of this decision to make. The workloads large enough to justify dedicated hardware, and the contracts large enough to carry meaningful counterparty risk, both start well above the scale most companies your size are running. If a vendor or consultant is pitching you on "owning your own AI infrastructure," ask what specific workload of yours actually needs it — the honest answer, most of the time, is none. Where this does reach you is one step removed: if you build your product on an AI platform or app vendor that itself runs on a neocloud, you've inherited a sliver of that provider's balance-sheet risk without ever signing a contract with them. It's worth one direct question to any AI vendor you depend on — whose infrastructure are you actually running on, and what's your contingency if they can't. Nothing here requires you to buy anything.

What to Do Monday Morning#

1. Separate your actual performance problem from the marketing version of it.Before evaluating any dedicated-hardware provider, benchmark your own workload against your current virtualized setup. If you're running single-chip, single-machine work, you're very unlikely to have the performance problem this whole conversation is premised on.
2. Ask your existing cloud provider about bare-metal or dedicated-instance pricing before shopping anywhere new.Amazon and Oracle both sell this inside contracts you may already have. It's a free phone call that could make the entire rest of this list unnecessary.
3. If you're evaluating a newer provider, ask the balance-sheet question out loud.What happens to your contract, your data, and your pricing if the provider is acquired, restructured, or runs out of financing before your contract term ends? Get the answer in writing, not in a sales call.
4. Read your current contract's termination and data-return terms before you ever need them.This costs nothing and takes an afternoon. Most companies read these clauses for the first time during a crisis, which is the worst possible time to negotiate them.
5. Build a one-page list of every AI workload currently running, and tag each one by how much it would actually benefit from dedicated hardware.Most companies have never done this inventory. It turns a vague sense of "we should look into bare metal" into a short, specific shopping list — or into the discovery that you don't need to shop at all.
6. If you depend on a third-party AI product or platform, ask them directly whose infrastructure they run on.You've inherited whatever exposure they carry whether you asked for it or not. Knowing the answer costs you nothing and tells you how many layers removed you actually are from this whole question.
7. Treat any "50 to 75 percent cheaper" pitch as a question, not a conclusion.A price gap that large between a trillion-dollar company and a much smaller one is almost never free — it's either genuine efficiency, a bet on an asset's future value, or both. Ask which one you're being offered before you sign.

The Uncomfortable Truth#

So: the return to bare metal mostly isn't a return to owning your own servers, and the balance sheet underneath most of it belongs to a company you probably haven't vetted the way you'd vet a bank. The performance reason to go looking is often real. The ownership and control story wrapped around it mostly isn't — you've usually just swapped one landlord's shared walls for a different landlord's exposed one.

Over the next six to twelve months, expect two things to collide: the hyperscalers will keep expanding their own dedicated-hardware options specifically to pull this business back without ever losing the customer relationship, and the depreciation argument now circulating about these chips will get a real test the next time NVIDIA releases a new architecture and the resale market for the old one has to actually clear. Whoever is holding the contract when that happens will find out, in a very concrete way, who was really carrying the risk all along.

I'd rather my clients ask the balance-sheet question before they sign than after something forces the answer. That's the whole post, really — not "don't go bare metal," but know whose risk you're renting along with the hardware.

— Charles Redding, Founder, DLegendDigital