GPU Data Center: Power, Cooling and Deployment Guide

Updated September 19, 2026 to reflect current rack-scale GPU systems, high-density power and cooling requirements, EU reporting rules, and a clearer procurement and commissioning process.

A GPU data center is the complete facility and cluster environment required to operate GPU servers at their intended performance. It needs an electrical path sized for the actual rack schedule, a cooling system matched to the equipment interfaces, compute and storage networks, physical space for the rack geometry and service clearances, controls, monitoring, and a tested route from energization to production.

Start with the workload and selected hardware, not a generic GPU count. A training cluster, an inference platform, and an enterprise installation may use different rack layouts, network topologies, storage systems, redundancy objectives, and operating models even when they contain the same number of accelerators.

This guide shows how to turn a GPU deployment plan into facility requirements, compare an existing-room upgrade, colocation, conventional construction, and modular delivery, and specify the evidence needed before accepting the completed system.

The deployment decision has two separate axes: where the cluster will run and who will operate it; and whether the facility work will use conventional, prefabricated, or hybrid delivery. Those choices can be combined. Eliminate options that cannot meet the hard requirements, then compare the remaining options on the same scope and evidence.

What information should come before the data center design?

The design brief must connect the workload, IT equipment, facility, and operating plan. At minimum, define:

1. Workload and service objective. State whether the system will run distributed training, fine-tuning, batch inference, interactive inference, or mixed workloads. Add the availability, latency, throughput, security, and data-location requirements that affect the infrastructure.
2. IT bill of materials. Identify the server or rack-scale system, compute and support racks, network switches, storage, management nodes, nominal and peak power, voltage, rack dimensions, weight, and the heat rejected to liquid and air.
3. Cluster topology. Define the scale-up domain, scale-out fabric, storage fabric, management network, cable types, port counts, and permitted cable distances. A layout that fits the racks but breaks the topology is not usable.
4. Initial and ultimate phases. Show what is installed on day one, what is reserved for later, and which electrical, cooling, network, and control systems are shared between phases.
5. Site inputs. Record available utility or on-site power, voltage, fault level, fiber routes, water conditions, climate, acoustic and planning constraints, transport and lifting access, and the required in-service date.
6. Operating responsibility. Name the parties responsible for the facility, cluster, network, security, monitoring, maintenance, spares, and incident response.

The accelerator name alone cannot answer these questions. NVIDIA's current GB300 NVL72 reference architecture, for example, places 72 GPUs and 36 CPUs in one liquid-cooled rack that can require up to 142 kW. Rack power, cooling, networking and service interfaces must be checked for the exact OEM configuration.

How do you convert a GPU plan into an IT load?

Build a rack-by-rack load schedule. Include compute, network, storage, management, and service equipment rather than multiplying an accelerator thermal design power by the GPU count.

For illustration, eight GB300 NVL72 compute racks at NVIDIA's stated maximum of 142 kW represent up to 1.136 MW of compute-rack IT power:

8 racks × 142 kW = 1,136 kW

That is not the complete cluster load or the facility input. Network, storage, management, and support racks must be added. The electrical design must also distinguish nameplate, nominal, peak, and measured demand; account for the selected diversity and redundancy cases; and include power-conversion losses and supporting systems when calculating total facility power.

At this screening stage, the useful result is not a false total. It is a list of what is known and what must still be supplied:

• Known: eight compute racks can require up to 1.136 MW of IT power, and the selected rack-scale system needs liquid cooling.
• Still required: the network, storage, management, and service-rack schedule; nominal and peak operating cases; the liquid and residual-air heat split; and the selected availability state.
• Facility decision: utility and backup capacity, UPS or ride-through arrangement, rack distribution, CDU and facility-water capacity, residual-air cooling, outdoor heat rejection, and room for later phases.

A proposal that fills the missing values with generic percentages is not yet a design. The OEM bill of materials and operating cases should supply them.

Annual energy is a separate calculation. Multiplying annual IT energy by a defensible PUE can estimate facility energy under the same boundary and assumptions. It does not size the peak electrical system. The data center PUE guide explains the measurement and sizing distinction.

GPU data center power architecture

The power path normally runs from the utility or on-site source through medium-voltage distribution, transformers, low-voltage switchgear, UPS or another ride-through arrangement, distribution boards or busway, rack power shelves or PDUs, and finally the IT equipment. The exact topology depends on the voltage, hardware, availability objective, maintenance strategy, and project boundary.

For each stage, the design team should resolve:

• continuous, peak, step, and synchronized workload behavior;
• normal, maintenance, and failure-state capacity;
• UPS autonomy and the transition to standby or alternative generation;
• voltage, phase, connector, busbar, grounding, fault-level, protection, and harmonic requirements;
• metering from the incoming supply to the rack and major cooling loads;
• how later phases connect without unplanned work on live systems.

A contracted megawatt is not automatically a deployable megawatt. Utility availability, the transformer and switchgear path, redundancy, power quality, cooling capacity, and the actual rack distribution can each reduce the number of GPU systems that can be energized.

Cooling: follow the heat all the way outside

GPU data centers can use air-cooled servers, rear-door heat exchangers, direct-to-chip liquid cooling, or a hybrid of liquid and air. There is no universal rack-density threshold that selects the system by itself. Use the chosen equipment's specified interfaces and the site design conditions.

For a direct-liquid system, the design must connect the cold plates and rack manifolds to the technology-cooling loop, coolant distribution units, facility-water loop, pumps, and outdoor heat rejection. Equipment that remains air cooled still creates a residual room load. NVIDIA's DGX GB rack documentation explicitly separates liquid-cooled compute components from air-cooled networking and storage devices within the system.

Specify the following before selecting the plant:

• heat load entering the liquid and air paths;
• supply and return temperatures on the technology and facility sides;
• flow, pressure, water quality, filtration, and material compatibility;
• CDU capacity, heat-exchanger approach, pump redundancy, controls, and leak detection;
• outdoor design temperatures and the selected dry, adiabatic, evaporative, or mechanical heat-rejection method;
• capacity available during maintenance and credible component failures.

“Liquid cooled” does not mean the entire facility load enters the water loop, and “closed loop” does not prove that the site consumes no water. The outdoor system and control strategy determine annual energy and water performance. See the AI water-use guide for the direct, indirect, and embodied-water boundaries.

Network, storage, space, and serviceability

A GPU cluster normally needs several networks: the accelerator or compute fabric, storage fabric, in-band management, out-of-band management, and connections to the customer's users and data sources. NVIDIA's SuperPOD documentation keeps these functions distinct because storage and management traffic can interfere with distributed workloads if the design treats every connection as one general-purpose network.

Translate the logical topology into a physical point-to-point cable schedule before fixing the floor plan. NVIDIA's cabling design guide recommends documenting every source, destination, rack location, port, bundle, label, and actual installed connection. Cable lengths, bend radii, overhead or underfloor routes, and access to rear manifolds and busbars can change the layout.

The room also needs to carry the rack and distribution-system weight, provide safe replacement routes, and preserve clearances for trays, power shelves, manifolds, cables, doors, and lifting equipment. A rack-scale system should be evaluated as installed equipment, not as a standard cabinet with a familiar footprint.

What determines GPU data center cost?

A credible budget starts with a defined boundary. The cost of GPU hardware is separate from the facility and cluster infrastructure needed to operate it. For the facility, price the site and utility work, medium- and low-voltage systems, resilience and ride-through, rack distribution, cooling and heat rejection, fire protection, controls, civil works, transport, installation, commissioning, and service. For the cluster, add network, storage, management nodes, software, spares, and deployment services.

Upgrade, colocation, conventional construction, and modular proposals often include different scopes. Normalize external plant, utility connection, foundations, permits, network services, testing, taxes, operating staff, and maintenance before comparing them. A lower module or lease price can become the higher installed cost when major interfaces sit outside the quotation.

Model delay separately instead of inserting a generic cost per idle GPU. Use the actual financing or depreciation policy, committed capacity charges, contract revenue or internal workload value, utilization ramp, and avoidable operating costs. The result will differ sharply between an internal research cluster, a sovereign platform, and a GPU cloud operator.

Choose where it runs and how it is delivered

Do not treat existing facilities, colocation, conventional construction, and modular delivery as four mutually exclusive routes. Location and operating model are one decision: upgrade an owner-operated site, contract capacity from a colocation provider, or develop a new owner-controlled site. Delivery method is another: conventional site construction, factory-built modules, or a hybrid. An existing site can receive a prefabricated power or cooling block, and a new campus can combine modular data halls with conventionally built shared infrastructure.

Apply the same hardware schedule, production-ready date, availability objective, commercial boundary, and acceptance criteria to every option.

After choosing a viable location model, test conventional, modular, and hybrid delivery against design maturity, factory and site work that can proceed in parallel, transport and lifting constraints, external plant, local labor, disruption to live systems, commissioning boundaries, and the work needed between phases. Factory-built delivery requires interfaces to freeze early enough for fabrication; conventional delivery still requires control of long-lead equipment and package interfaces.

Capacity remains tight in several established colocation markets. CBRE reported 1.4% vacancy across North American primary markets in H1 2026, with 80.4% of capacity under construction already committed. Its European midyear review also describes constrained power and continued competition for new capacity. Those market figures justify checking availability early; they do not prove that colocation is unavailable for every project or that modular construction is always the right answer.

Rank the options that pass the gates

Check mandatory legal, site, security, and hardware requirements first. Then rank the surviving options against the production-ready date; normalized capital, operating, and lifecycle boundary; operational control; expansion fit; interface and integration risk; disruption to live systems; and contractual accountability. The project owner should set the priorities, and every supplier should return evidence against the same criteria. A generic weighting would hide the differences between a research cluster, a sovereign platform, and a commercial GPU service.

Keep the load boundary visible

At 0.5 MW of installed or peak IT load, an assessed existing room, suitable colocation, or one purpose-built block may all be credible. Around 2 MW of installed or peak IT load, the choice increasingly turns on rack technology and cluster topology. Four 500 kW MDC500 systems provide a nominal aggregate 2 MW IT-capacity screen for dense air-cooled equipment; that arithmetic is not a complete cluster architecture. Validate the rack allocation, support loads, network topology, shared electrical, cooling and control systems, maintenance states, and failure domains. Rack-scale liquid-cooled systems point toward an MDC2000-type architecture. A 5 MW IT-load project is a multi-block site, not one standard unit. It needs a campus-level plan for shared medium-voltage systems, backup power, heat rejection, controls, network, phasing, maintenance isolation, and common-mode risk. Total facility input will be higher and remains project-specific.

How long does a GPU data center take to deploy?

There is no defensible universal deployment time. A supplier's schedule should state its start event, finish event, assumptions, exclusions, and critical path. Factory assembly can run in parallel with foundations and site utilities, but it cannot remove grid, permitting, hardware, transport, or commissioning dependencies.

Request a program that includes:

• hardware and facility design freeze;
• utility, permit, and authority approvals;
• long-lead electrical, cooling, network, and control equipment;
• factory assembly, inspection, and FAT;
• foundations, external power, heat rejection, fiber, and site preparation;
• transport, lifting, connection, and energization;
• SAT, integrated systems testing, cluster deployment, validation, and handover.

The completion date should mean usable production capacity, not the date the module or GPU racks arrive.

Commissioning: test the facility and the cluster

Facility acceptance and cluster acceptance are connected but different. The facility team verifies electrical protection, transfer sequences, cooling controls, alarms, metering, leak detection, maintenance states, and failure responses. The IT team verifies firmware, node health, network topology, storage, orchestration, monitoring, and workload performance.

NVIDIA's current cluster guidance uses single-node and multi-node tests, including NCCL for fabric validation and HPL for compute and network stress. The acceptance plan should also include a representative customer workload or agreed reference job. A successful power-on does not demonstrate that the cluster sustains the required performance.

Define the pass criteria before testing:

• available IT and cooling capacity in normal, maintenance, and selected failure states;
• rack inlet, liquid supply/return, flow, pressure, and component temperatures;
• network and storage bandwidth, latency, error rate, and topology correctness;
• node-health, burn-in, and workload-performance thresholds;
• alarm routing, data retention, recovery procedures, spares, and responsibility for failed components.

EU reporting and project-specific compliance

Commission Delegated Regulation (EU) 2024/1364 applies its reporting framework to operators of EU data centers with installed IT power demand of at least 500 kW. The regulation defines installed IT power as the nominal power demand of the installed network, server, and storage equipment. The rack schedule and metering design therefore need to be agreed before commissioning.

The EU regulation does not establish one universal PUE limit. National rules can add requirements. Germany's Energy Efficiency Act, Section 11, for example, sets PUE and energy-reuse requirements for data centers within its scope. Confirm the applicable law, calculation method, exemptions, reporting period, and evidence for the actual site. A factory-built product is not automatically compliant.

How ModulEdge maps GPU requirements to a platform

ModulEdge offers factory-built modular data-center platforms from 20 kW to 2.5+ MW per deployment unit, scalable to multi-megawatt capacity. Across the portfolio, project configurations support 5–236 kW per rack. The selected hardware, rack schedule, site, cooling interfaces, availability objective, and external scope still determine the final design.

The figures below come from the ModulEdge Catalog 2026, MDC500 Product Brochure Revision 24, MDC2000 Product Brochure Revision A version 03, and the current public GB300 arrangement. The catalog and product brochures are available on request or with a proposal. They are product and reference-design specifications, not evidence of measured field performance at every density. The detailed project load schedule remains configuration-specific. Ask for the dated product pack, project load schedule, drawings, and test plan with the proposal.

MDC500 is a three-module operational system, not one standard shipping container. MDC2000 is a prefabricated modular building. For MDC2000, upstream medium-voltage switchgear, transformers, and standby generators are included only when the project scope adds them.

ModulEdge manufactures switchboards and related electrical and control assemblies. When specialist OEM equipment such as UPS systems, generators, or transformers is included, ModulEdge selects, engineers, assembles, integrates, and tests it within the agreed power-system scope. The proposal should identify the OEM, responsibility, interface, and acceptance test for every major system.

For a Helios deployment, our AMD Helios rack and facility requirements guide distinguishes the published reference-design envelope from the selected OEM’s electrical, thermal and layout requirements.

GPU data center procurement checklist

Ask bidders to return the same information so that the proposals can be compared on an equal boundary:

• Rack and load schedule: every compute, network, storage, and service rack, with nominal and peak power and air/liquid heat split.
• Scope and interface matrix: what each party designs, supplies, installs, connects, tests, operates, and warrants.
• Power one-line and operating cases: normal, maintenance, failure, autonomy, protection, grounding, metering, and expansion states.
• Thermal basis of design: temperatures, flow, pressure, water quality, air duty, residual heat, ambient conditions, heat rejection, and redundancy.
• Physical and network layouts: rack geometry, weight, service clearances, cable schedule, pipework, manifolds, replacement routes, and fiber entry.
• Controls and data: BMS, EPMS, DCIM, APIs, protocols, alarms, cybersecurity boundaries, licenses, retention, and data ownership.
• Dependency-based program: design freeze, long-lead release, factory work, site work, utility milestones, transport, energization, testing, and handover.
• FAT, SAT, integrated systems, and cluster acceptance plans: witnesses, loads, failure cases, thresholds, records, and remedies.
• Expansion sequence: repeated and shared systems, reserved capacity, and every intervention required on live infrastructure.
• Assumptions and exclusions: permits, civil work, external plant, OEM supply, commissioning, local service, spares, training, and warranty response.

Evidence to request before shortlisting a supplier

Apply the same evidence standard to ModulEdge and competing bidders. Request the dated product specification, project-specific drawings and load schedule, manufacturing location and available production window, sample FAT and SAT records, comparable references the supplier is permitted to disclose, and the proposed local commissioning and service organization. For every certification or partner claim, ask for the legal holder, scope, current document, and relevance to the offered configuration.

The commercial package should also state payment milestones, change-control rules, performance commitments and their test conditions, delay responsibility, warranty boundaries, spare-parts provision, service response, and remedies. These terms cannot be inferred from the product architecture or a marketing lead time.

Day-two operating package

Handover should include current drawings, rack and cable schedules, settings and backups, meter and sensor lists, alarm routing, standard and emergency procedures, maintenance plans, coolant-management requirements, spares, training, warranty contacts, escalation paths, and ownership of BMS, EPMS, and DCIM data. Add a configuration and change-control register covering approved firmware, settings and control baselines, compatibility review for GPU and network upgrades, and tested rollback or restoration procedures. Assign who can isolate electrical and cooling equipment, who can drain a failed GPU node, and who coordinates facility and cluster incidents.

GPU data center FAQ

What is a GPU data center?

A GPU data center is a facility and cluster environment designed to operate GPU servers or rack-scale accelerator systems. It includes power distribution, cooling, networking, storage, physical infrastructure, controls, monitoring, commissioning, and operations.

How many GPUs are in a data center?

There is no standard number. A deployment can range from a few enterprise servers to thousands of accelerators. Start with the workload and selected system, then build the rack, network, storage, and power schedule. One GB300 NVL72 rack contains 72 GPUs, but that count and its facility interfaces do not apply to every platform.

How much power does a GPU data center need?

Add the nominal and peak loads of every compute, network, storage, management, and service rack. Then model the electrical losses and cooling and facility loads for the chosen architecture. Do not size the site by multiplying GPU TDP alone, and do not use annual PUE as a peak-sizing factor.

Does every GPU data center need liquid cooling?

No. Some GPU servers remain air cooled and can operate in facilities designed for their actual rack density. Rack-scale systems such as GB300 NVL72 require direct liquid cooling and retain an air-cooling component. Select the cooling method from the OEM interfaces, rack schedule, site climate, resilience requirement, and heat-rejection design.

How long does it take to deploy a GPU data center?

The answer depends on power, permits, hardware selection, design maturity, long-lead equipment, site works, transport, testing, and commissioning. Ask for a dependency-based program from design freeze to accepted production capacity. Module delivery alone is not the finish date.