← all posts
// hardware · psu

Size the PSU for inference, transients, and efficient idle

Buy the power supply for the workload, not for the number printed on the GPU box. That needs a footnote: the two numbers aren't unrelated, they just measure different things, and conflating them is how a local inference machine ends up crashing mid-generation or running its efficiency curve into the ground for months. A workstation that alternates between an idle GPU waiting on the next prompt and a GPU pulling every watt it can during prefill is not a steady load. Size for that shape, not for a spreadsheet total.

Two failure modes, same spreadsheet mistake

The common approach is to add up every card's rated TDP, add the CPU, round up, and buy the biggest unit that fits the case. This produces two different failures depending on which way you round. Undersize and the symptoms rarely look like a power problem: a reboot mid-batch, a driver reset, a job that silently restarts. Runtimes are forgiving by design, they retry, they requeue, they fall back, so a brownout gets misdiagnosed as a software bug three times before anyone checks the wall. Oversize and the failure is quieter: a rig that spends most of its life at a small fraction of rated capacity, sitting on the flattest, least efficient part of the curve, burning more for idle than it needs to. Neither shows up on the invoice. Both show up on the power bill or the incident log a month later, long after anyone connects it to the PSU.

Where the curve actually bites

Efficiency curves are not flat. They dip at very low load, climb through a comfortable middle band, and taper again near the rated ceiling. A machine that idles most of the time and spikes hard during inference wants its typical operating point inside that middle band, not down in the flat end where an oversized unit sits idling. The spike itself is the other half of the problem: inference draw is transient, not steady, and a GPU can pull well above its steady TDP for the duration of a prefill burst. Sizing off summed TDP alone misses that, which is why the number you want is measured at the wall, not read off a spec sheet.

psu_sizing_note:
  workload: <idle-heavy chat | steady batch | mixed>
  peak_draw_watts: <measured at wall, not summed TDP>
  transient_spike_watts: <observed during prefill/decode burst>
  connector_count: <PCIe 8-pin / 12VHPWR, per card>
  typical_load_pct_of_rated: <where it actually sits most hours>
  retest_trigger: <new card, driver change, different traffic mix>

Check the connectors while you're at it. A cable rated for one draw carrying two cards' worth of current is a fire risk hiding behind a working benchmark, and it won't show up until the one run that finally needs it.

What goes in the sizing note

None of this is worth doing once and forgetting about. Write the peak and typical numbers into whatever file tracks the build, with the date and workload that produced them, and write down what should trigger a retest: a card added to the rig, a driver update that changes power management, a traffic mix that shifts the idle-to-load ratio. This applies whether you're speccing a single high-end card for local models or a multi-GPU box that runs continuously in a closet somewhere. Boring and documented beats clever and undocumented every time someone else has to touch the machine.

If I had to keep one rule out of all this: size to the wall draw you measure at your real operating point, add headroom for the transient, and ignore the number on the box.

#psu#power#hardware