AI data centers are becoming power-system projects
The next AI infrastructure bottleneck is not only accelerators. Grid connections, rack density, cooling, water, utilization, backup power and flexible scheduling now shape what can actually be deployed.
What is happening?
An AI data center is increasingly a power project with computers inside it. Buying accelerators is only one step. The operator must secure a real grid connection, deliver electricity through transformers and backup systems, remove concentrated heat, manage water, keep enough reserve for failures and make sure the expensive equipment is doing useful work. Some training and batch jobs can move to a cleaner or less congested hour, but interactive services still need firm power. A credible plan measures the whole facility and ties each megawatt to accepted work, not to a hardware announcement.
Why this trend is moving
- 01AI training and reasoning-heavy inference are increasing accelerator demand and concentrating more electrical load into each rack.
- 02New data-center campuses can require the power of a large industrial facility while being geographically concentrated in a small number of grid regions.
- 03Grid connections, transformers, switchgear, generation and cooling equipment can take longer to deliver than the computing hardware.
- 04Efficiency per chip or per prompt is improving, but lower cost and broader use can still increase total electricity consumption.
- 05Training, evaluation and batch workloads can sometimes shift across time or region, creating a potential grid resource when the flexibility is measured and contracted.
- 06Water, carbon and clean-energy claims are receiving closer scrutiny because annual fleet averages can hide local and hourly effects.
What this means in practice
- Power availability and interconnection dates can determine the AI product roadmap as directly as model or chip availability.
- A low PUE does not prove that the AI service is efficient when accelerators are idle, requests are repeated or outputs are rejected.
- High-density clusters require power delivery and cooling to be designed together rather than upgraded independently.
- Water impact must be evaluated by site, season, source and local stress instead of only through a global fleet number.
- Demand flexibility is valuable only when specific workloads can pause, move and recover without violating service or data rules.
- Annual renewable-energy matching, location-based emissions and hourly carbon-free operation are different claims and should remain separate.
- Complete cost per accepted task should include grid upgrades, energy, cooling, reserve capacity, networking, maintenance and failed work.
What the headline leaves out
This is the practical technical view: how the system is put together, where it can fail, and what a real deployment asks from the team running it.
How it is built
A production AI infrastructure program starts with the models, traffic, latency and quality contract. Hourly workload scenarios determine active compute, idle reserve, storage, networking and growth. Site selection then evaluates contracted power, interconnection milestones, grid quality, water, permitting and community effects. The facility power chain converts utility electricity through substations, transformers, switchgear, UPS systems and rack distribution. Schedulers place jobs across accelerators while thermal systems remove heat through air, direct liquid or hybrid cooling. Delay-tolerant work may respond to grid and carbon signals, but firm services remain protected. Metering joins facility energy, IT energy, water, utilization, emissions and accepted output under a versioned reporting method.
How inference behaves
AI clusters draw power through accelerators, host CPUs, memory, networking and storage, with additional facility demand for conversion and cooling. Power Usage Effectiveness relates total facility energy to IT energy but says nothing about model quality or useful utilization. Dense synchronized jobs can create large ramps and repeated electrical oscillations. Liquid cooling carries heat more efficiently at high density but adds coolant loops, pumps, connectors and maintenance. Scheduling, batching, quantization, routing and caching can reduce energy per completed job, while longer contexts, reasoning and agent workflows push in the opposite direction.
What the tests can miss
A credible evaluation meters at the facility boundary and the IT boundary, reports PUE and WUE with their standards and periods, and divides total energy by outputs that meet a declared quality and service threshold. It measures useful accelerator utilization, idle reserve, load factor, ramps, curtailment capability, cooling ride-through, backup generation, hourly location-based emissions and contractual market-based emissions. Forecasts should include multiple demand and efficiency scenarios, while project reports separate requested, contracted, energized and usable megawatts.
What deployment involves
Improve utilization and service efficiency before committing new capacity. Compare cloud, colocation, owned campuses and regional fleets using the same accepted-task, latency and availability denominator. For a new site, stage construction and energization against verified workload growth and grid milestones. Keep firm interactive services separate from flexible training or batch queues, then test curtailment, checkpoint recovery and rebound. Co-design rack, power and thermal systems and preserve a rollback path for model, scheduler, hardware and energy assumptions.
Where the risks sit
The physical and cyber boundaries now meet at the data center. Building management, cooling controls, substations, batteries, generators, cluster schedulers and remote administration can all affect service or safety. Network segmentation, signed updates, least privilege, protected telemetry and local fail-safe controls are required. A workload scheduler should not gain unrestricted control over safety-rated electrical or cooling equipment. Energy and utilization telemetry can also reveal sensitive business capacity, so public transparency and operational security need separate data views.
What it really costs
The economic model combines accelerators, servers, network fabric, storage, buildings, grid upgrades, substations, transformers, cooling, water, energy contracts, batteries, generators, financing, staff, maintenance and decommissioning. Reserved but unused power and idle compute remain real costs. The decisive denominator is an accepted training result or inference service delivered at the required quality, latency and availability. A site with cheaper electricity can still cost more when interconnection is late, utilization is poor or the workload cannot move there.
What the evidence supports
The infrastructure trend is established, while its final scale remains uncertain. The IEA projects data-center electricity consumption to roughly double by 2030 in its central case and reports faster growth for AI-focused facilities. Lawrence Berkeley National Laboratory now estimates a broad range for the U.S. share of electricity use by 2030, reflecting the uncertainty. FERC and DOE are addressing large-load connections, rapid demand changes and grid planning. ISO has updated the PUE standard, while WUE, ASHRAE and Open Compute Project guidance cover water and high-density cooling. MLCommons provides full-system power measurements for declared AI workloads. Company environmental reports and carbon-aware scheduling examples show real efficiency and procurement work, but they are vendor-reported and do not remove the need for location-, time- and service-specific measurement. The evidence supports treating power, cooling and grid integration as first-class AI architecture.
How it works in practice
AI infrastructure is no longer only a server-procurement problem. A credible deployment must join workload demand, accelerator utilization, grid interconnection, facility power, cooling, water, backup systems, carbon accounting and flexible scheduling into one measured operating plan.
How the parts work together
The headline technology is only one part of the product. Reliability, security and cost are usually decided by the handoffs around it.
- 01
Service and workload contract
Define the models, training jobs, inference traffic, latency targets, availability, data residency and quality threshold. Power planning begins with the useful service, not the nameplate accelerator count.
- 02
Capacity and utilization model
Forecast active compute, idle reserve, networking, storage, CPU and memory demand by hour. Include growth, retries, failover, maintenance and the gap between purchased capacity and sustained useful work.
- 03
Site and grid interconnection
Evaluate available megawatts, transmission and distribution upgrades, connection queue, power quality, generation mix, water stress, permitting and community impact before treating a site as deployable.
- 04
Facility power chain
Utility feeds, substations, transformers, switchgear, UPS systems, batteries, generators and rack distribution convert grid power into stable compute power. Every conversion adds loss, capacity limits and failure modes.
- 05
Cluster and scheduler
Accelerators, hosts, memory, storage and network fabrics execute jobs under placement, batching and admission controls. The scheduler decides whether expensive electrical capacity produces useful tokens or waits idle.
- 06
Thermal and water system
Air, direct-to-chip liquid or immersion cooling moves heat from silicon to the environment. Cooling design must match rack density, climate, water availability, maintenance capability and ride-through requirements.
- 07
Flexible operation and energy sourcing
Delay-tolerant training, batch inference and data processing can move across time or region when contracts and data rules permit. Interactive workloads need firm capacity and cannot be advertised as flexible without measured limits.
- 08
Metering, assurance and lifecycle
Measure facility and IT energy, water, utilization, emissions, reliability and accepted output. Version the methodology, preserve hourly data, review public claims and include hardware replacement and embodied impacts.
Estimate the limits before the demo
These equations are planning tools rather than substitutes for testing. They help expose a design that is unlikely to fit its hardware, budget, reliability or risk limits.
PUE connects the server floor to the utility meter
PUE = total facility energy ÷ IT equipment energy A PUE of 1.20 means that every 1 kWh delivered to IT equipment requires about 1.20 kWh at the facility boundary. PUE measures facility overhead, not whether the model, server or workload is efficient.
- A 100 MW IT load at PUE 1.20 requires about 120 MW before separate charging or export effects.
- Two sites can have the same PUE while one wastes far more energy through low accelerator utilization.
- PUE should be reported with measurement boundary, period and operating conditions.
The useful denominator is accepted work
energy per accepted task = total facility energy attributable to the service ÷ accepted outputs The numerator should include active accelerators, idle reserve, hosts, memory, networking, storage, cooling and power losses. The denominator should exclude failed, rejected or duplicate outputs unless they were part of the intended service.
- A faster model can use more watts yet less energy per completed job.
- Retries and long reasoning traces increase energy even when the final answer is short.
- Low utilization can dominate the footprint of a lightly used private cluster.
Annual matching cannot describe hourly emissions
location-based carbon intensity = Σ(hourly electricity × hourly grid factor) ÷ Σ(hourly electricity) A yearly renewable-energy contract and the physical electricity used each hour answer different questions. Credible reporting should keep location-based and market-based results separate and state whether supply is matched by region and time.
- A solar contract may match annual consumption while nighttime demand is served by a different grid mix.
- Moving a flexible job can reduce hourly emissions only when the receiving site and time are actually cleaner.
- Contracted clean-energy capacity is not the same as delivered generation.
Plan for scenarios, not one impressive electricity forecast
The International Energy Agency estimates that global data-center electricity consumption could roughly double from 2025 to 2030 in its central outlook, with AI-focused facilities growing faster. Lawrence Berkeley National Laboratory's 2026 update places U.S. data centers within a wide 2030 range rather than one precise number. Those ranges reflect real uncertainty in chip shipments, model efficiency, utilization, financing, grid connections and demand for AI services.
Efficiency does not automatically reduce total demand. A cheaper inference can attract more users, larger contexts, longer reasoning and agent workflows. The correct capacity plan therefore contains a base case, high-efficiency case, high-adoption case and connection-constrained case.
A company should be able to explain which business volume, model mix and service quality create each megawatt of forecast load. Without that link, the power request is a speculative reservation rather than an operating plan.
- Separate training, interactive inference and batch inference.
- Model active, idle, failover and maintenance states.
- Show sensitivity to model efficiency and utilization.
- Reconcile project pipelines with realistic interconnection dates.
Rack density changes power delivery and cooling together
AI clusters concentrate electrical load into racks and synchronized fabrics. The IEA's 2026 analysis describes rapidly rising server power density, while the Open Compute Project is developing facility and rack designs for much higher-density AI systems. A traditional hall cannot be upgraded by replacing servers alone when busways, switchgear, cooling distribution units and heat rejection were sized for another era.
Direct liquid cooling can remove heat close to the chip and support densities that are difficult for air. It also introduces pumps, coolant chemistry, leak detection, connectors, water loops and maintenance procedures. Many facilities remain hybrid: the accelerator is liquid cooled while memory, networking and power equipment still need air.
Power and thermal design must use the same rack roadmap. A stranded megawatt is possible when the grid connection exists but the facility cannot deliver or cool it at the intended density.
- Qualify rack, row and campus power separately.
- Measure conversion losses from utility meter to accelerator.
- Design cooling ride-through for utility and pump failures.
- Verify maintainability under live high-density operation.
Large-load interconnection is becoming a product dependency
A data-center shell can be built faster than new transmission, substations, transformers or generation. FERC's large-load interconnection proceeding and current DOE work reflect the pressure created by projects that may request tens or hundreds of megawatts in one location. The problem is local: global electricity share can remain modest while one cluster overwhelms a regional planning assumption.
A reservation in a utility queue is not firm capacity. Developers need milestones for land, permits, network upgrades, equipment, generation, fuel, water and commissioning. Utilities and communities also need confidence that speculative duplicate projects will not force unnecessary investment.
The operating contract should define ramp rates, power quality, curtailment, backup behavior and who pays for upgrades. AI training can create coordinated load changes that require measurement beyond annual energy.
- Track requested, contracted, energized and usable MW separately.
- Include transformer and switchgear lead times.
- Model rapid load ramps and oscillations.
- Publish community and ratepayer cost allocation clearly.
A full power envelope can still produce a poorly used cluster
Accelerators wait when models do not fit, networks stall, storage cannot feed data, jobs fragment the cluster or capacity is held for a traffic spike. High availability also requires some idle reserve. These states are operationally valid, but they belong in the energy denominator.
Performance per watt measured on an active benchmark is useful and incomplete. MLPerf Power measures full-system wall power for declared workloads, which is stronger evidence than thermal design power. A production service must add facility overhead, idle capacity, failed requests, data movement and quality acceptance.
Before requesting another block of power, operators should know whether better batching, model routing, quantization, caching, scheduling or hardware allocation can increase useful output from the existing site.
- Report accelerator utilization with accepted throughput.
- Measure idle and reserved energy.
- Track failed and repeated computation.
- Compare scale-up with efficiency and scheduling alternatives.
Water, electricity and heat rejection must be reported together
Evaporative cooling can reduce electricity use in suitable climates while consuming water. Closed-loop or dry designs can reduce direct water use while requiring different equipment or energy. The right design depends on local climate, watershed stress, water source, grid mix and rack density.
ISO defines PUE for facility energy overhead and WUE for operational water intensity. Neither metric is a complete environmental score. PUE can improve while IT demand rises, and low direct water consumption can coexist with water used to generate electricity.
Operators should publish direct water withdrawal and consumption, source quality, seasonal conditions, WUE boundary and local replenishment separately. A global replenishment portfolio does not remove a local shortage during a hot month.
- State whether water is withdrawn, consumed, reused or replenished.
- Report seasonal and site-level values where material.
- Include water associated with electricity when evaluating alternatives.
- Avoid presenting one cooling technology as universally superior.
Demand flexibility must be attached to a real workload
Google has demonstrated shifting delay-tolerant computing across time and location and using data-center demand response during grid events. This is credible because a central scheduler can identify work with slack. It does not mean an entire AI campus can disappear from the grid on request.
Training checkpoints, batch embedding, evaluation and some offline inference may pause or move. Interactive inference, storage, networking and safety systems need continuous service. Data residency, model availability and network capacity can prevent geographic movement.
A flexibility claim should specify available MW, notice time, duration, recovery ramp, frequency and service consequence. The same job must not be sold twice as reliability reserve and ordinary capacity.
- Classify workloads by deadline and migration constraint.
- Test curtailment and recovery under production-like load.
- Protect state and checkpoints before interruption.
- Measure rebound demand after a grid event.
A clean-energy claim needs time, place and accounting method
Annual renewable matching can finance clean generation and still leave hours when a data center uses a carbon-intensive grid mix. Google's 24/7 carbon-free-energy work and the GHG Protocol's proposed Scope 2 revisions show why hourly matching and deliverability are receiving attention.
Location-based emissions describe the grid where consumption occurs. Market-based emissions apply qualifying contractual instruments. Both are useful when labeled, and neither should be quietly substituted for the other. Procurement claims should also distinguish signed capacity from projects that are operating and delivering.
Operational emissions are only part of the footprint. Accelerators, servers, buildings, batteries and generators carry embodied and supply-chain emissions. Rapid hardware replacement can improve compute efficiency while increasing manufacturing impact.
- Report location- and market-based Scope 2 separately.
- Preserve hourly load and energy-source data.
- Distinguish contracted, constructed and delivered clean energy.
- Include embodied hardware and construction in lifecycle decisions.
Choose the operating system before choosing the megawatts
A new campus can offer lower unit cost at high utilization and still be a poor decision when interconnection delays, water constraints, low flexibility or uncertain demand are included. Cloud capacity, colocation, owned facilities and regional fleets distribute those risks differently.
The deployment decision should compare complete cost per accepted task at the required latency and availability. Include reserved but unused power, network transport, backup generation, batteries, cooling, financing, maintenance, curtailment and decommissioning.
The safer expansion sequence is measurement, utilization improvement, contracted capacity, staged energization and repeatable workload growth. Building far ahead of verified demand transfers model uncertainty into long-lived energy infrastructure.
- Use stage gates tied to service demand and energized capacity.
- Compare owned, colocated and cloud alternatives on the same denominator.
- Include grid and community obligations in project governance.
- Require rollback plans for workload, hardware and energy assumptions.
What a benchmark worth believing should report
A performance number means little unless the workload, system configuration and quality bar are fixed. This is the minimum record a team should keep.
| Metric | How to measure it | Why it matters |
|---|---|---|
| Accepted output per facility kWh | Divide metered facility energy by outputs that meet the declared quality and service threshold. | This joins model, serving, utilization and facility efficiency. |
| PUE with boundary and season | Report total facility energy divided by IT energy by site, measurement category and period. | A fleet average can hide poor sites and seasonal cooling peaks. |
| WUE and water source | Report operational water consumed per IT energy with source, stress and reuse information. | Water impact is local and cooling choices move tradeoffs. |
| Useful accelerator utilization | Measure active compute that contributes to accepted output rather than allocated device time alone. | Reserved or stalled capacity can consume power without useful service. |
| Peak-to-average power ratio | Compare site peak demand with average demand over the same period. | Grid and facility capacity are sized for peaks, not yearly averages. |
| Ramp rate and oscillation | Record MW change per second or minute and repeated load patterns during representative jobs. | Synchronized AI workloads can affect power quality and grid equipment. |
| Flexible-load capability | Test curtailable MW, notice, duration, recovery time and service impact. | A theoretical movable workload is not a dependable grid resource. |
| Interconnection readiness | Track requested, contracted, construction-ready, energized and usable capacity separately. | Project pipelines often overstate power that can serve equipment. |
| Cooling ride-through | Test temperatures and available control time after power, pump or network failure. | Dense racks can overheat before ordinary recovery procedures finish. |
| Location-based carbon intensity | Multiply hourly consumption by the best available local grid factors. | Annual averages miss when the site actually consumes electricity. |
| Market-based carbon result | Apply qualifying contracts and certificates under the stated accounting standard. | Procurement claims need a separate, auditable ledger. |
| Backup generation exposure | Record test and emergency generator fuel, runtime, emissions and local air-quality impact. | Reliability equipment can materially change site emissions. |
| Idle and reserve energy | Meter capacity held for failover, spikes, fragmented scheduling and maintenance. | High availability has an energy cost that active-chip benchmarks omit. |
| Complete cost per accepted task | Include compute, facility, grid upgrades, energy, water, networking, financing, maintenance and failed work. | Token price or accelerator price alone cannot compare deployments. |
Four sensible deployment patterns
Conventional firm-load campus
- Where it fits
- Interactive inference and mixed cloud services requiring continuous local capacity.
- What you take on
- Simple service contract, but high grid, backup and interconnection burden with limited curtailment.
Flexible training campus
- Where it fits
- Large checkpointed jobs and batch processing with schedulable deadlines.
- What you take on
- Can respond to energy conditions, but pauses, migration and rebound must be engineered and tested.
Regional inference fleet
- Where it fits
- Services that can route requests among several approved regions.
- What you take on
- Improves capacity and energy options while adding latency, data-residency, replication and consistency complexity.
Energy-integrated campus
- Where it fits
- Very large projects combining grid connection, generation, storage and flexible load.
- What you take on
- Can accelerate capacity and support the grid, but creates power-project financing, permitting, fuel and operational obligations.
Where projects usually go wrong
One forecast is treated as guaranteed demand
What you see: Power and buildings are committed before workload volume is verified.
What to do: Use scenario gates and stage energization against measured service growth.
PUE is presented as AI efficiency
What you see: A low-overhead facility masks idle accelerators or wasteful models.
What to do: Pair PUE with accepted output per facility kWh and utilization.
Nameplate MW is reported as available capacity
What you see: Projects appear ready while grid upgrades or facility equipment remain incomplete.
What to do: Track requested, contracted, energized and usable MW separately.
Cooling is designed after rack selection
What you see: The site has electrical capacity but cannot operate the planned rack density.
What to do: Co-design chip, rack, power and thermal roadmaps.
Water impact is hidden in a fleet average
What you see: A stressed site looks acceptable because replenishment occurs elsewhere.
What to do: Publish site, season, source and watershed context.
Annual renewable matching becomes a physical claim
What you see: Marketing implies the site runs carbon-free every hour.
What to do: Separate location-based, market-based and hourly matching results.
Flexible load is double counted
What you see: The same capacity supports customer commitments and grid curtailment promises.
What to do: Contract explicit workload slack and test service consequences.
Active-chip power omits the system
What you see: Energy estimates exclude idle reserve, hosts, network, storage and cooling.
What to do: Meter at the wall and allocate full service energy.
Rapid workload ramps disturb the grid
What you see: Voltage, frequency or equipment oscillations appear during synchronized jobs.
What to do: Measure ramps, coordinate scheduling and use storage or controls where qualified.
Backup power becomes routine generation
What you see: Generators operate beyond tests or emergencies to bypass grid constraints.
What to do: Govern runtime, permits, emissions and fuel use separately from resilience.
Hardware efficiency drives premature replacement
What you see: Operational savings are claimed without manufacturing and disposal impacts.
What to do: Use lifecycle carbon and cost with an explicit replacement threshold.
Local community cost is externalized
What you see: Grid upgrades, water pressure or air pollution affect residents without transparent allocation.
What to do: Include utility, regulator and community obligations in approval gates.
A checklist you can actually use
- Define the model, workload and service-quality mix that creates the forecast.
- Separate training, interactive inference and batch inference demand.
- Create base, efficiency, high-adoption and interconnection-constrained scenarios.
- Model active, idle, reserve, maintenance and failover power.
- State requested, contracted, energized and usable capacity separately.
- Verify utility, transmission, substation and equipment milestones.
- Measure rack, row, hall and campus power boundaries.
- Co-design power distribution and cooling for the rack roadmap.
- Select air, liquid or hybrid cooling from local conditions and maintenance capability.
- Report PUE with standard, category, period and boundary.
- Report WUE with water source, consumption and watershed context.
- Meter full-system energy rather than relying on chip specifications.
- Define accepted output and include failed or repeated work in the numerator.
- Measure useful utilization, fragmentation and idle reserve.
- Record load ramps, oscillations and peak-to-average demand.
- Classify workloads by deadline, data residency and migration ability.
- Test curtailment notice, duration, recovery and rebound.
- Keep location-based and market-based emissions separate.
- Distinguish contracted clean-energy capacity from delivered generation.
- Include backup generation, batteries and fuel in reliability and emissions plans.
- Calculate complete cost per accepted task at the required service level.
- Include embodied hardware, construction and replacement in lifecycle decisions.
- Stage expansion against measured demand, community obligations and repeatable operation.
Terms worth knowing
- Power Usage Effectiveness
- Total data-center facility energy divided by energy delivered to IT equipment.
- Water Usage Effectiveness
- Operational water consumption normalized to IT equipment energy under a stated measurement boundary.
- IT load
- Power used by servers, accelerators, storage, networking and related computing equipment.
- Facility overhead
- Power used by cooling, conversion, distribution, lighting and other non-IT systems.
- Interconnection
- The technical, contractual and construction process that connects a large load to the electric system.
- Firm power
- Capacity intended to be available under defined reliability conditions rather than only when generation is convenient.
- Demand response
- A measured reduction or shift in electricity consumption in response to a grid or price signal.
- Load factor
- Average power divided by peak power over a stated period.
- Ramp rate
- How quickly electrical demand rises or falls.
- Carbon-aware computing
- Scheduling or routing work using information about electricity emissions by time or place.
- Location-based Scope 2
- Purchased-electricity emissions calculated from the grid where consumption occurs.
- Market-based Scope 2
- Purchased-electricity emissions calculated using qualifying contractual instruments and supplier information.
- Hourly matching
- Matching electricity consumption with qualifying supply in the corresponding hour and deliverable region.
- Cooling ride-through
- The time a cooling system can keep equipment within safe limits after a primary failure.
- Embodied emissions
- Lifecycle emissions from materials, manufacturing, construction, transport and equipment replacement.
Primary references and technical starting points
These sources support the architecture, runtime, benchmark and security claims. Vendor capabilities can change, so the article records the distinction between established evidence, measured product behavior and editorial interpretation.
- 01 IEA: Key Questions on Energy and AIiea.org
- 02 IEA: Key Questions on Energy and AI executive summaryiea.org
- 03 IEA: Energy and AIiea.org
- 04 IEA: Energy demand from AIiea.org
- 05 IEA: Energy supply for AIiea.org
- 06 Lawrence Berkeley National Laboratory: U.S. Data Center Energy Usage Report 2025 Updateeta-publications.lbl.gov
- 07 Lawrence Berkeley National Laboratory: 2024 U.S. Data Center Energy Usage Reportenergyanalysis.lbl.gov
- 08 U.S. Department of Energy: Data-center electricity-demand reportenergy.gov
- 09 U.S. Department of Energy: Clean energy resources for data-center demandenergy.gov
- 10 U.S. Department of Energy: Monitoring oscillations from large data centersenergy.gov
- 11 FERC: Interconnection of Large Loads to the Interstate Transmission Systemferc.gov
- 12 ISO/IEC 30134-2:2026 Power Usage Effectivenessiso.org
- 13 ISO/IEC 30134-9:2022 Water Usage Effectivenessiso.org
- 14 ASHRAE: AI Data Center Energy Performance Framework site planningashrae.org
- 15 Open Compute Project: Open Data Centers for AIopencompute.org
- 16 Open Compute Project: Delivering an Open Data Center Ecosystem for AIopencompute.org
- 17 Open Compute Project and ASHRAE liquid-cooling allianceopencompute.org
- 18 MLCommons Power Working Groupmlcommons.org
- 19 MLPerf Inference Datacenter power measurementsmlcommons.org
- 20 MLCommons: MLPerf Inference v6.0 resultsmlcommons.org
- 21 Google: 2026 Environmental Reportsustainability.google
- 22 Google: Measuring the environmental impact of AI inferencecloud.google.com
- 23 Google: Data-center demand responsecloud.google.com
- 24 Google: Carbon-aware data-center resource managementcloud.google.com
- 25 Google: Ironwood TPU carbon-efficiency methodologycloud.google.com
- 26 Google: 24/7 carbon-free energy and regional matchingcloud.google.com
- 27 Microsoft: 2026 Environmental Sustainability Report announcementblogs.microsoft.com
- 28 Microsoft: 2025 Environmental Sustainability Reportmicrosoft.com
- 29 Microsoft: Datacenter cooling and energy-efficiency measuresmicrosoft.com
- 30 GHG Protocol: Scope 2 Guidanceghgprotocol.org
- 31 GHG Protocol: Scope 2 frequently asked questionsghgprotocol.org
- 32 GHG Protocol: Proposed hourly matching and deliverability revisionsghgprotocol.org