Comparing power efficiency in AI servers helps you identify how much useful training or inference work each system delivers for the electricity it consumes. Gather comparable workload results and power readings for the GPUs, power supplies and cooling setup; the result is a fair, repeatable comparison rather than a guess based on component ratings.
What You’ll Need
- Access to each server’s power telemetry, such as a suitably rated power meter or facility monitoring system. For a complete comparison, measure at the wall or power distribution unit (PDU), not only GPU-reported power.
- The same AI model, dataset or inference request mix, software settings, and target quality or accuracy for each system.
- A way to record completed work, elapsed time, energy, ambient or inlet temperature, and cooling conditions.
- Permission to run tests during a controlled period, plus a spreadsheet or log for results.
Step-by-Step
- Define the comparison goal. Decide whether you are comparing training throughput, inference throughput, or a particular production workload. Choose the useful-work measure before testing: examples include training samples per second, tokens generated per second, or requests completed per second at a stated latency target. Do not compare different kinds of work using a single raw throughput number.
- Make the workload equivalent. Use the same model, precision, batch size, input lengths, software versions where practical, and quality settings. Match the number of GPUs and their configuration if your aim is component-level efficiency. If systems differ in GPU count or memory, record that and compare both total-system results and per-GPU results. Warm up each system so initialization and compilation do not distort one run.
- Establish a measurement boundary. For total server efficiency, measure energy entering the server at its power inputs, or use a PDU reading that isolates that server. A GPU’s telemetry excludes CPUs, memory, fans, power-supply losses, and often other devices. For facility-level efficiency, also account for cooling and power distribution overhead, but do not mix facility readings for one test with server-only readings for another.
- Check power measurement and logging. Confirm the meter or telemetry reports watts and cumulative energy in known units, and that timestamps align with the workload. Sample often enough to capture changing loads; a single instantaneous reading can miss peaks and idle periods. Use the same measurement method across candidates. Record GPU, CPU, and system power separately when available, but use the agreed boundary for the headline comparison.
- Control environmental and operating conditions. Keep inlet temperature, airflow, fan policy, workload duration, and background activity as consistent as possible. Record temperature and any thermal or power throttling. Ensure each system has settled at its normal operating state. Avoid blocking vents or changing cooling controls just to improve one result; that can make the comparison unsafe or unrepresentative.
- Run repeated tests. Run the workload for a fixed, meaningful interval or until a defined amount of work is complete. Repeat each run several times after the same warm-up procedure. Record completed work, elapsed time, average wall power, total energy, temperatures, and errors. Allow equipment to return to comparable conditions between runs if heat buildup affects results.
- Calculate useful-work efficiency. Prefer work per energy: divide completed work by energy used. For example, if a run completes 12,000 requests using 2.4 kWh, efficiency is 5,000 requests per kWh. If energy is in joules, use the same units for every system; 1 kWh equals 3.6 million joules. You may also report energy per unit of work, such as joules per token, which is the inverse perspective. State the workload and measurement boundary alongside every figure.
- Compare GPUs without overlooking the platform. Compare GPU energy or throughput per GPU only when the telemetry and workload are equivalent. Then compare whole-server energy per unit of work. A GPU with better chip-level efficiency may not yield a better server result if it needs more host power, memory, or cooling. Report throughput and latency as well: efficiency alone does not show whether a system meets service requirements.
- Assess power supplies fairly. A PSU’s rated wattage is its capacity, not the power it always draws or a measure of efficiency. Compare input and output power at the actual operating load, using reliable telemetry or manufacturer efficiency data for the relevant input voltage and load. PSU conversion efficiency is output power divided by input power. Check that candidates are tested under comparable load and conditions; do not infer efficiency from model names or maximum ratings.
- Include cooling and facility overhead where relevant. Server fans and liquid-cooling equipment consume power, while room-level chillers and pumps may sit outside the server meter. If comparing total operating efficiency, measure or allocate that overhead consistently. A facility power usage effectiveness (PUE) figure can help describe facility overhead, but it is a facility-wide ratio, not a GPU efficiency score. Keep server-only and facility-inclusive results clearly separate.
- Summarize uncertainty and choose on the right basis. Calculate the average of repeated runs and show the spread or range. Flag changes in clocks, throttling, temperatures, software, or measurement precision. Choose the best result only if it meets the same throughput, latency, quality, and reliability requirements. Keep the raw logs so another person can reproduce the comparison.
Common Mistakes
- Comparing GPU board power on one server with wall power on another. The measurement boundaries are not equivalent.
- Using peak watts or PSU capacity as a substitute for energy consumed during useful work.
- Testing different batch sizes, precision, model quality, or request lengths and calling the result an efficiency comparison.
- Reporting throughput per watt from a brief peak without including idle periods or the full workload interval.
- Ignoring throttling, temperature, or cooling power. These can change both performance and energy use.
- Relying on one run or rounding results so heavily that small differences appear decisive.
Tips
- Publish both throughput per kWh and energy per unit of work; readers can interpret whichever is more useful.
- Label each metric with its boundary, such as GPU, server input, or facility input.
- Use a representative workload mix for deployment decisions, not only a synthetic benchmark.
- Record software and firmware settings, power limits, GPU count, and ambient or inlet temperature.
- Compare performance at a stated latency target for inference; higher throughput is not useful if response times miss the requirement.
Troubleshooting
- Power readings differ unexpectedly: Check units, meter placement, timestamps, and whether readings are instantaneous, averaged, or cumulative. Confirm no other equipment shares the measured circuit.
- Results vary between runs: Look for background jobs, changing request mixes, temperature differences, clock changes, or inconsistent warm-up. Repeat under controlled conditions and report the spread.
- One server is slower and uses more energy: Check for thermal or power throttling, configuration mismatches, software issues, and cooling restrictions. Correct the cause, then rerun both systems rather than adjusting only one result.
- PSU efficiency data is unavailable: Measure input and output power with appropriate instrumentation, or compare total server energy at the wall. Do not estimate PSU efficiency from its capacity rating.
- Cooling overhead cannot be isolated: Report server-only efficiency and state that cooling is excluded. For facility-inclusive comparison, use a consistent allocation method or dedicated measurements rather than applying unrelated PUE values.
Frequently Asked Questions
What is the best unit for AI server efficiency?
Use useful work per kWh, such as tokens per kWh or requests per kWh, and state the workload and measurement boundary.
Should I compare watts or energy?
Use energy for a defined amount of work or test interval. Watts describe power at a moment or average rate; energy captures power over time.
Does a higher-efficiency PSU always make the server more efficient?
No. It can reduce conversion losses, but the result also depends on GPU and host power, workload performance, and cooling.
Can GPU power telemetry be used for the whole-server result?
No. It is useful for GPU-level analysis, but it omits other server components and may not match power measured at the input.
How should I account for cooling?
Measure cooling energy consistently for a facility-level result, or clearly label the comparison as server-only. Do not combine mismatched boundaries.
How many runs should I perform?
Use several repeat runs and report their average and variability. Add runs when results fluctuate enough to obscure meaningful differences.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.
More cards in this drawer
- Delete Picture Kik? How to Remove Photos
- Disable Google Assistant: Turn It Off on Android & Home
- Resin vs FDM Printers for Miniatures: Detail, Durability, Cost
- Are Networked Implants Safe? What If One Fails?
- How to Stop WordPress Comment Spam: A Layered Guide
- What Happens to X Replies, DMs, and Followers After Deletion?