Research-backed calculator guide
AI GPU Power and Cooling Cost Calculator: From IT Watts to Facility Load
Calculate GPU server electricity, cooling load, PUE-adjusted facility power, and a finance-ready monthly cost from explicit AI infrastructure assumptions.
An AI GPU power cooling total cost calculator should answer more than “how many watts does the card use?” The useful finance question is: how much does this deployment add to the facility’s monthly electrical and cooling line item, under a stated utilization, PUE, operating schedule, and utility rate?
Quick answer
Use this sequence:
- Multiply GPU count by board power and average utilization to estimate accelerator watts.
- Add a server overhead factor for CPU, memory, storage, fans, network adapters, and PSU losses. This is your IT load.
- Multiply IT load by PUE to estimate facility power. PUE includes cooling, power distribution, and other overhead; do not add the same overhead a second time.
- Convert IT heat to BTU/hour with
watts × 3.412, then divide by 12,000 for cooling tons. Add a design reserve only if you are sizing equipment. - Multiply facility kW by operating hours and the electricity rate for the utility estimate.
For example, eight 700 W GPUs at 80% average utilization, a 25% server overhead factor, PUE of 1.35, 720 hours per month, and $0.13/kWh produce 5.60 kW of IT load, 7.56 kW of facility load, about 1.59 tons of IT heat, and an estimated $708 per month in electricity. The $708 is an estimate, not a utility quote. Change the rate, schedule, or PUE to reflect your site.
NVIDIA lists the H100 SXM’s maximum configurable thermal design power as up to 700 W, but a board rating is not the same thing as a whole server or a continuously observed workload draw.[1] Google’s explanation of PUE defines it as total facility power divided by IT equipment power, including overhead such as cooling and power distribution.[2] Those two distinctions—board versus system, and IT versus facility—are what keep a GPU electricity estimate from being understated or double-counted.
What the calculator should measure
The first output is accelerator power, not total deployment power:
GPU power (kW) = GPU count × board TDP (W) × utilization ÷ 1,000
TDP is a useful planning ceiling or reference value. It is not a promise that an inference server will draw that number every minute. Utilization should represent the average power behavior you are budgeting, not merely the percentage of time a request exists. If telemetry is available, use measured GPU power. If not, state whether your estimate assumes 60%, 80%, or 100% of the board rating.
The second output is IT load. A GPU server also contains CPUs, memory, boot and data drives, fans, network adapters, voltage regulators, and power-supply losses. Represent these with an explicit multiplier or, preferably, a measured server baseline:
IT load (kW) = accelerator power × server overhead factor
A factor of 1.25 in the worked example means the rest of the server adds 25% to the utilized accelerator load. It is an assumption for an early estimate, not a universal “typical” value. A dense multi-GPU server, a workstation, and a rack with high-power switches can have materially different overhead. A vendor system specification or a power meter is stronger evidence than a generic multiplier.
The third output is facility load:
Facility power (kW) = IT load × PUE
PUE is a ratio, not a percentage discount. If IT load is 5.60 kW and PUE is 1.35, the facility estimate is 7.56 kW. The implied overhead is 1.96 kW. That overhead includes the cooling plant, power distribution losses, and other site systems represented by the selected PUE. Google reports a 2025 fleet-wide average PUE of 1.09 for its large-scale data centers, while noting that PUE varies by facility and boundary.[2] Do not copy that hyperscale result into a small server room without evidence from the actual site.
Google Cloud’s published inference methodology also calls out dynamic chip utilization, idle machines held for availability, CPU and RAM, and data-center overhead.[3] Those factors matter when you move from a single-box estimate to a production service. A model that is “80% busy” in request terms may still have provisioned failover capacity, host memory, or idle replicas drawing power.
Cooling load: separate heat sizing from energy accounting
For ordinary electrical equipment, nearly all consumed electrical power becomes heat that must be removed. Estimate the IT heat load as:
Heat (BTU/hour) = IT watts × 3.412
Then:
Cooling tons = BTU/hour ÷ 12,000
This produces a thermal load for the IT equipment. It does not mean the HVAC equipment will deliver exactly that nominal tonnage in every operating condition. You still need to consider room conditions, airflow, heat rejected elsewhere, redundancy, chilled-water temperatures, containment, and the engineer’s design margin.
Do not multiply cooling tons by PUE as if PUE were a second heat conversion. PUE is appropriate for estimating total facility energy. Cooling tons are a capacity-sizing view of heat that the cooling system must reject. If you add a 20% reserve to the worked example, that reserve is an equipment-design choice, not an additional monthly energy charge by itself. The actual plant’s efficiency is already represented in the PUE assumption used for facility power.
Cooling technology changes the assumption set. Air cooling, rear-door heat exchangers, direct liquid cooling, and immersion cooling can have different density limits and overhead. The right PUE is site-specific and should be supported by a facility quote, a measured operating value, or a documented design case. A calculator can expose the sensitivity without pretending that one PUE applies everywhere.
Electricity cost formula
For a recurring utility estimate, use:
Monthly electricity cost = facility kW × hours/month × electricity rate ($/kWh)
Use actual scheduled hours when the system is not continuously powered. For a 24/7 service, 720 hours is a simple 30-day planning month; 730 hours is closer to an average calendar month. Annual planning should use 8,760 hours only for a continuously operating year, and should be adjusted for maintenance windows or utilization changes.
The rate must be labeled. A US commercial utility tariff, a colocation pass-through charge, a blended internal rate, and a cloud GPU hourly price are not interchangeable. Taxes, demand charges, renewable surcharges, delivery fees, and contract minimums may sit outside a simple $/kWh model. If the facility bills demand in kW, add a separate demand-charge line instead of hiding it in the energy rate.
A good model reports at least two views:
- Energy-only estimate: the metered electricity implied by facility kW and $/kWh.
- Fully loaded internal rate: energy plus amortized hardware, networking, maintenance, space, staffing, and any fixed facility charge.
The FinOps Foundation recommends practical, transparent data-center cost models and unit economics rather than waiting for perfect precision. It also describes separating metered usage from estimated non-metered components and treating idle capacity as a visible signal.[4] That is a useful operating discipline: show finance which lines are measured, which are allocated, and which are still planning assumptions.
Worked cost example
Consider one 8-GPU inference server with these inputs. The values are deliberately explicit so another person can replace them with measured data.
| Step | Input or formula | Result | Assumption note |
|---|---|---|---|
| GPU board rating | 8 × 700 W | 5,600 W at rated board power | H100 SXM reference; verify the installed configuration [1] |
| Average workload draw | 5,600 W × 80% | 4,480 W / 4.48 kW | Planning utilization, not a vendor quote |
| Server overhead | 4.48 kW × 1.25 | 5.60 kW IT load | Adds 25% for non-GPU server components and losses |
| Facility load | 5.60 kW × 1.35 PUE | 7.56 kW | PUE includes facility overhead; do not add it again |
| Monthly energy | 7.56 kW × 720 hours | 5,443.2 kWh | 30-day, always-on month |
| Monthly electricity | 5,443.2 kWh × $0.13 | $707.62 | Illustrative rate, not a utility quote |
| IT heat | 5,600 W × 3.412 | 19,107 BTU/hour | Electrical IT load converted to heat |
| Cooling capacity | 19,107 ÷ 12,000 | 1.59 tons | Add design reserve only for equipment sizing |
| 20% design reserve | 1.59 × 1.20 | 1.91 tons | Engineering allowance, not extra billed energy |
The important result is not a universal price. It is the chain of evidence. At 80% utilization, the GPUs contribute 4.48 kW. The server becomes 5.60 kW after the stated overhead factor. The site’s PUE turns that into 7.56 kW at the meter boundary used by the model. At $0.13/kWh, energy is approximately $23.59 per day and $8,491 per year if the same assumptions hold for 365 days.
Sensitivity is easy to calculate. Keeping all other inputs fixed, a $0.10/kWh rate produces about $544 per month. A $0.20/kWh rate produces about $1,089 per month. At PUE 1.15, monthly electricity falls to about $603; at PUE 1.60, it rises to about $838. Those are scenario outputs, not claims about the efficiency of a particular provider or building.
For a larger fleet, multiply the IT and facility calculations by server count only after checking shared equipment. Network switches, storage, cooling pumps, UPS losses, and redundant capacity may not scale linearly per server. The Interconnected Systems result, for example, exposes switch/NIC overhead and selectable cooling-type PUE in its planner, which is a reminder to include infrastructure that a GPU-only multiplication misses. The calculator’s output should therefore retain an “included” and “excluded” list.
From power estimate to total cost of ownership
Power and cooling are recurring operating costs, but they are not the entire self-hosted inference TCO. Add separate rows for:
- GPU and server purchase price amortized across the chosen useful life;
- networking, storage, racks, PDUs, UPS capacity, and installation;
- maintenance contracts, replacement parts, and software licenses;
- colocation, floor space, water, or facility charges not captured by the PUE boundary;
- staffing and on-call coverage;
- idle or failover capacity that remains powered for availability;
- demand charges and taxes when the utility tariff includes them.
Keep capital and operating costs separate. A lower PUE can reduce energy cost while requiring liquid-cooling infrastructure with additional capital cost. A cloud GPU hourly rate can bundle power and cooling, but it is not evidence of your local electricity cost. Compare like with like: utilization, availability, contract term, network egress, storage, support, and hardware lifecycle all change the result.
For token economics, divide the fully loaded monthly cost by successful output tokens, requests, or another unit that finance and engineering agree to track. If traffic is variable, report idle hours and peak capacity separately. A low average cost per token can conceal a large always-on reserve.
If model selection affects the workload, pair this worksheet with the model pricing comparison. For retrieval-heavy systems, the RAG, embedding and vector database cost calculator helps keep storage and retrieval costs from being misclassified as GPU electricity. For implementation planning, see the AI agent development cost estimator and keep build labor distinct from steady-state infrastructure.
Run your scenario
Turn this framework into an editable estimate.
Use dated, source-linked assumptions and see cost per request, successful task and month.
Assumptions, exclusions, and limitations
This method is an estimate for planning and internal comparison. It does not replace an electrical engineer’s load study, a cooling design, a utility tariff review, or a facility operator’s measured PUE. Board TDP can differ from observed draw. Server overhead varies by chassis and workload. PUE changes with weather, load, redundancy, and the measurement boundary.
The worked example excludes GPU purchase price, staff, networking, storage, water, demand charges, taxes, and space. It also assumes constant utilization, constant electricity price, and a 30-day month. It treats PUE as a complete facility-overhead multiplier. If your provider invoices cooling as a separate charge or reports a different boundary, adapt the formula rather than stacking both numbers blindly.
The official product and methodology pages cited here were checked on 2026-11-02. Pricing and utility assumptions in this article are dated illustrative estimates, not vendor quotes. Re-run the model whenever GPU configuration, traffic shape, cooling system, tariff, or facility contract changes.
FAQ
Is GPU TDP the same as total server power?
No. TDP is a board-level planning specification. Total server power also includes CPU, memory, storage, fans, networking, voltage conversion, and PSU losses. Start with measured server telemetry when possible; otherwise expose the overhead factor as an editable assumption.
How do I calculate GPU server cooling cost?
First calculate IT heat with IT watts × 3.412 to get BTU/hour and divide by 12,000 for nominal tons. Then price the facility energy separately with IT kW × PUE × hours × $/kWh. Do not turn the cooling tons into a second electricity charge unless you have a separate cooling-plant model; PUE is already intended to capture facility overhead in the energy estimate.
What PUE should an AI inference calculator use?
Use a measured or contractually documented site value. Do not use a hyperscale fleet average as a default for a workstation, enterprise server room, or colocation cage. If the value is unknown, show a sensitivity range and label it as an assumption. Google’s published 2025 fleet-wide average of 1.09 is useful context, not a universal target.[2]
Does liquid cooling always make the monthly bill lower?
Not automatically. Liquid cooling can change thermal management and support higher rack density, but the net result depends on pumps, heat exchangers, chillers, water systems, controls, utilization, and capital cost. Model its PUE and infrastructure charges from the actual design. Compare the energy saving against the incremental installed cost and operating complexity.
Should idle GPUs be included in an inference cost model?
Yes, if they are powered and reserved for availability. A production service may need warm replicas, failover capacity, or headroom for traffic spikes. Google’s inference methodology explicitly discusses idle machines, CPU/RAM, and data-center overhead, which is why a GPU-only active-power estimate can understate operating energy.[3]
How should finance use the result?
Give finance the inputs, units, date, source, and boundary alongside the output. Label metered values, vendor specifications, allocated costs, and assumptions separately. Then create a stable internal unit rate, such as dollars per GPU-hour or dollars per million successful tokens, while keeping idle capacity visible rather than hiding it in a volatile average. That makes the estimate auditable and easier to reconcile with bills.
Primary sources checked
Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.