H100 measurements show why energy per completed job needs its own validation

The customer problem is budgeting AI workloads from hardware ratings or vendor efficiency slogans alone. Engage facilities, research computing, finance and the scientists responsible for output quality. Ask what fraction of cost is measurable, whether job completion is comparable and whether a configuration change preserves scientific usefulness. Offer a bounded metering study on approved workloads. The value hypothesis is a more credible operating-cost estimate. Do not promise the paper's energy reduction, recommend denser racks from sampled peaks or describe faster training as better research.

Reproduce the incumbent job and candidate configuration on the actual target environment. Prerequisites include versioned data and code, calibrated metering and an agreed quality metric. Collect total job energy, runtime and task accuracy across repeated runs, including ordinary shared-service contention. Keep metering separate from sensitive data and account for measurement granularity. Validate larger batches against scientific acceptance before adoption. The proof of value should resolve the paper's missing quality comparison locally and keep node observations separate from facilities capacity decisions.

Research computing should own the experiment with facilities and domain scientists. Implement a repeatable harness, telemetry retention and a controlled rollout of approved settings. Dependencies include metering access, researcher time and stable comparison workloads. Review data handling and output quality before changing defaults. Proposed acceptance criteria are reproducible energy measurements, no unacceptable scientific-quality regression and a documented rollback. Train users to report runtime and quality changes. Risks include hidden cooling costs, workload drift and optimizing a benchmark that poorly represents institutional demand.