Ask what makes a data center good and you get two answers. The operator names utilization, cooling, and the power bill. The customer names performance, cost, and reliability. It is tempting to treat these as opposing interests — one side squeezing efficiency, the other demanding headroom. Far more often than it looks, they are the same pair of decisions seen from two ends, and the decisions are sizing and placement.

Everything that matters inside the building — the heat at a rack, the traffic on a link, the draw on a circuit — is downstream of what is running and where. Facility design and controls are real levers and operators use them well, but they adjust the building around whatever happens to be running in it. What runs, at what size, in which position, is the lever that usually goes untouched.

A workload carries a physical signature

We treat a workload as an abstract unit of demand: so many cores, so much memory, some storage. But every workload also leaves a physical mark. It runs with a certain efficiency, and in the running it produces heat, pulls power, and moves data. That mark isn’t one number you can slide up and down — it’s several things at once:

Heat is the thermal load it adds to its rack and its cooling zone. Power is the draw it places on a shared circuit and power domain. Network is the bandwidth it consumes and the path its traffic takes. Efficiency is how much useful work it returns per watt and per dollar. Two workloads that look identical on a capacity sheet can behave nothing alike once placed. One runs cool and quiet. The other lights up a thermal hot spot and saturates a link.

Location changes the signature

The mark is not fixed, because it depends on where the workload lands — the neighbors it sits beside, the cooling it draws from, the power domain it shares, the path its traffic takes. Move the same workload a few racks over and its effect on the building changes. Change what surrounds it and its own efficiency changes with it. The axes interact, which is why you cannot place a workload by looking at one number and stapling it to an open slot.

Two decisions: right-placed and right-sized

Placement and sizing are separate decisions, and they are easy to conflate.

Right-placed is the question of position — which rack, which node, which power and cooling domain, on which path. This is where hot spots are created or avoided, where links are balanced or bottlenecked, where a circuit runs comfortably or flirts with its limit. Right-placed puts a workload in the right seat.

But a seat is not a fit. Right-sized is the other decision — which silicon the workload actually runs on, and how much of it. A training job on an accelerator whose memory bandwidth it cannot saturate, an inference service holding a GPU tier it never draws on, a rendering job on hardware that finishes in four times the necessary time: none of those are placement failures. The workload is in a perfectly reasonable seat. It is the wrong size for the seat.

Right-placed is not enough

Sizing and placement are coupled — hardware choice changes what a workload does to its surroundings, and surroundings change what that hardware can deliver — but each can go wrong on its own, which is why treating them as one thing fails. A workload can be badly sized in a well-balanced hall, with nothing around it stressed, and still return less work per watt and per dollar than it should, because it never fit the silicon it was given. And a workload can be correctly sized and still run badly, because a hot spot or a saturated link around it throttles the hardware it was correctly matched to.

Both show up as the same symptom. The job is slower and more expensive than it should be. But they call for different corrections: one workload needs to be resized where it sits, the other moved without changing its shape at all, and some need both. Resize the throttled workload and you have hidden a facility problem behind a bigger bill. Move the misfit workload and you have relocated the inefficiency without touching it.

This is why the useful step is not detection but attribution — separating a workload that is on the wrong silicon from one that is on the right silicon in the wrong conditions. Until you can tell those apart, every corrective action is a guess.

The decision is easier to see in three cases, stated illustratively rather than measured. A workload holding more allocation than it draws on, with no sign of strain, is a sizing question: evaluate a smaller configuration. A workload with adequate resources that is throttling against thermal limits is a placement question: evaluate its position and the conditions around it. A workload showing both at once — holding capacity it never uses while straining against its surroundings — needs a combined correction, and arriving there depends on establishing that both are true rather than settling on whichever explanation surfaced first. That is harder than it sounds, because throttling can distort utilization readings: a low reading on a constrained workload does not by itself prove excess allocation, so the sizing case has to rest on evidence beyond the utilization the constraint is distorting. The symptom does not name the cause. The correction follows the cause.

Wrong size, wrong place: both strand capacity

Installed capacity is not usable capacity, and the gap between them is set by these decisions. Rightsizing is usually pitched as a customer concern — the tenant spends less. That framing is why operators have been slow to care about it, and it is wrong. Every one of these errors takes capacity out of circulation, and all of it lands on the operator’s side of the ledger.

Over-sizing strands capacity by holding it. A workload sitting on an allocation it never draws on has taken that silicon off the market, and no one else can use it. The rack looks committed and the hall looks full while a meaningful share of the fleet does nothing. Utilization — the number the whole business is measured on — degrades without any visible cause, because a booked GPU and a working GPU are indistinguishable on a capacity report.

Misplacement strands it a second way, and this one is harder to see, because the capacity is genuinely free. It just cannot be sold. A workload that concentrates heat in a cooling zone consumes that zone’s thermal budget, so the empty slots around it cannot be filled without breaching it. A workload sitting on a circuit already near its limit leaves the remaining power on that circuit unusable. A job whose collective traffic saturates a link makes the ports behind it worth less to anyone else. The GPUs are installed, powered, unallocated — and unsellable, because the conditions they need were spent by a neighbor. Capacity reports will show them as available inventory right up until someone tries to place a workload there.

Under-sizing stresses the workload first, and the facility through it. A device running near its limits is not the problem — a busy GPU doing useful work is what an operator wants. The problem starts past the point where the resources stop being sufficient: work queues, memory spills, latency targets slip, and the job takes materially longer to finish. A job that runs far longer than it should keeps drawing power and shedding heat for all of that time, so a sizing error prolongs resource pressure and worsens whatever thermal or power constraint already exists around it. Whether that becomes a hot spot that strands neighboring capacity depends on the hardware, the cooling, and what else is running nearby — but it is the mechanism by which sizing errors turn into placement problems. Utilization alone cannot tell you which case you are in. Health can.

And the tenant is paying for that at the same time, in a way that has nothing to do with the operator’s power bill. An under-provisioned workload takes longer to finish, misses latency targets, and returns a worse cost per result than it would on hardware that fit — and it does all of that even in a facility whose thermal and electrical characteristics were never affected. The two injuries are independent. Fix the cooling and the customer is still waiting; comp the customer and the hardware is still running pinned at its ceiling. Under-sizing is not one problem seen from two angles. It is two problems from one cause, and where the facility is already constrained, the operator carries both.

The obvious objection is that an over-sized customer is still paying for what they hold, and it deserves a careful answer rather than a dismissal. Rightsizing that tenant does reduce what they pay. The gain is not a second payment for the same silicon; it is that the operator can serve a customer it would otherwise have turned away, on hardware it already owns, while keeping the first tenant on terms that reflect what they actually use. Whether that nets out positive depends on demand, pricing, and contract structure. Where demand exceeds sellable supply, which describes most of this market, it usually does.

“Rightsizing does not pay the operator twice for the same silicon. It lets them serve a customer they would otherwise have turned away.”

One caveat operators will recognize immediately: freeing a GPU allocation does not by itself free the power and cooling headroom needed to run those GPUs hard, which is precisely why sizing and placement have to be solved together. And the tenant left over-provisioned is not a stable customer anyway — a workload quietly running at a fraction of what it pays for is a repricing conversation waiting to happen, or a churn risk, depending on who notices first.

Why the two sides stop competing

Get both right and the picture changes on both sides at once. The facility runs closer to its true capacity, because nothing is stranded behind an artificial hot spot, a saturated link, or an allocation nobody is using. The workload runs closer to its best, because it is not fighting its neighbors for headroom or fighting hardware that was never the right match. While there is obvious waste in the system, removing it can improve efficiency while preserving or improving performance, and preserving it at lower cost is the economical goal working exactly as intended. The benefit is not symmetric in timing, though. The tenant gains immediately, while the operator’s gain depends on capturing the freed capacity — through resale, retention, or customers that would otherwise have been turned away.

Real trade-offs return once the waste is gone. More performance may cost more power. Spreading workloads to relieve heat can raise communication cost. An explicit optimization goal is what resolves those — and it was already doing work earlier than that, because the goal decides what counts as waste in the first place. Headroom that is excess under an economical target may be exactly right under a performance-enhancing one. Someone has to say which outcome is worth more, and the answer changes the sizing decision, not just the tiebreaks after it.

Where naive placement fails

The simplest form of placement does none of this. It reads a capacity requirement, finds an open slot the workload nominally fits, and stops. Better tools exist on both sides: schedulers such as Kubernetes can spread workloads across topology and failure domains, and facility tools model the hall’s power, thermal, and airflow behavior in detail. What is usually missing is the join between them — measured workload behavior on one side, measured surrounding conditions on the other, resolved together against an explicit cost-performance goal so that sizing and placement are decided as one problem. That is the capability being added.

“Capacity-only placement is not placing the workload where it belongs. It is dropping it in the first slot a capacity check does not reject.”

That is the entire gap between filling space and placing workloads. And it never asks the sizing question at all — whether the configuration the workload requested is the one it needs. A capacity check confirms the request can be honored. It has no opinion on whether the request was right.

What it is worth

Four returns, and they compound.

Lower bills, for the same work. Cooling is a significant component of facility energy use, and a plant that has to chase its worst rack runs to that rack rather than to the hall’s average. Removing the hot spots created by concentrated placement, and the prolonged pressure created by undersizing, lets the same plant hold the same hall at less expense. The comparison that matters is per unit of work: if the recovered capacity is then filled with more paying workloads, the total electricity bill can rise even as energy per result falls and the facility earns more. The saving is recurring and it requires no new equipment.

Better revenue, where there is demand to absorb it. Capacity recovered is inventory recovered. Where there is demand for it and the power and cooling headroom to run it, recovered capacity is silicon that can be sold without procuring new megawatts. The gain is not automatic — it comes from resale, from retention, or from serving customers that would otherwise have been turned away — but in a market where demand exceeds sellable supply, those conditions are the normal case rather than the exception.

Happier customers. A tenant that is right-sized and right-placed gets closer to what it is paying for — more predictable performance, a cost per result that reflects the work done, and far less of the noisy-neighbor behavior that generates support tickets nobody can explain. More predictable performance and better cost per result give customers a reason to stay.

Happier investors. These facilities are underwritten on revenue per megawatt and on how quickly deployed capital starts earning. Selling recovered capacity can increase revenue per megawatt of installed power capacity — the recovery creates the opportunity; the sale realizes it — and it can defer the next buildout — the single largest call on capital an operator faces. A facility that sells more of what it already has is a better asset than one that answers demand by breaking ground.

Each of these comes with its conditions, and the conditions are worth stating because they are the difference between a promise and a plan. But where the waste is real and the demand is there, these decisions can improve customer outcomes and operator economics together — and the fact that they can is the tell that sizing and placement were the right levers all along.

This is what the Serra Labs Platform does. It sizes every workload against how it actually behaves, not against what it requested — identifying the configuration that matches the goal in force, whether that is saving cost, preserving performance, or improving it, weighing the expected benefits and drawbacks of every change, and validating each recommendation against the workload’s own history before anyone acts on it. Sizing is judged in the conditions the workload actually runs in: a workload straining against its surroundings is not treated as though it were running clean, so a constrained workload is not mistaken for an oversized one, and the correction points at the right problem.