A GPU sitting in a warehouse is not compute. The AI infrastructure bottleneck is no longer the accelerator alone. A GPU cluster becomes usable compute only after it has stable power, a validated cooling loop, high-speed networking, controls, fire protection, and a commissioned facility around it.
That distinction is becoming more important than the accelerator purchase itself.
At Ai4 2026, former Intel CEO Pat Gelsinger criticized the energy efficiency and computational limits of current GPUs. Yet the more commercially important message came from the infrastructure discussion around that statement. Sachin Katti, OpenAI’s head of compute, said that data center construction, energy availability, semiconductor fabs, memory capacity, and system integration have all become constraints. He described OpenAI’s ambition as reducing infrastructure deployment from roughly three years to three quarters.
That is an ambition, not a guaranteed industry-wide schedule. Still, it exposes the right procurement question for every infrastructure buyer:
How quickly can purchased hardware be converted into stable, cooled, networked, and revenue-producing IT capacity?
1. Power Availability Is Now Part of the Compute Specification
AI infrastructure buyers often begin with GPU quantity, server model, and rack density. The site team begins somewhere else: utility capacity, substation schedule, transformer availability, fault-current limits, voltage architecture, backup strategy, and the amount of facility power required to support each megawatt of IT load.
These are not secondary construction details. They determine whether the servers can be energized at all.
The International Energy Agency projected in 2025 that global data center electricity demand could more than double by 2030 to around 945 TWh, with electricity demand from AI-optimized data centers more than quadrupling. Berkeley Lab’s June 2026 update estimates a reference case of 649 TWh for U.S. data center electricity use in 2030, equal to about 11.8% of total U.S. electricity. Its uncertainty range extends from 521 to 843 TWh.
The commercial implication is straightforward. Competition for grid capacity, electrical equipment, engineering resources, and approval time will intensify in many markets. A site with inexpensive land but an uncertain power date may be less valuable than a more expensive site with a credible energization path.
Buyers should therefore separate three numbers in every proposal:
– Utility or generation capacity: the power available at the site boundary.
– Facility capacity: the power remaining after distribution and infrastructure losses.
– Usable IT capacity: the power that can continuously reach the compute equipment under the agreed redundancy and operating conditions.
Do not size a project from the nameplate megawatts alone. Redundancy, transformer loading, UPS topology, harmonic performance, cooling demand, auxiliary systems, and operating reserve all affect the final IT load.
Pro Tip:
Before freezing the server order, request a one-line electrical diagram and a load schedule that connects utility input, transformers, switchgear, UPS or backup architecture, cooling equipment, auxiliary loads, and final rack power. If those documents do not agree, the project is not ready for a reliable capacity commitment.
2. Cooling Has Become Part of Compute Capacity
At lower rack densities, cooling was often treated as a facility support function. In a high-density AI deployment, cooling is a direct limit on compute availability.
If a rack can receive power but cannot continuously reject its heat, that electrical capacity is not usable IT capacity.
This is why the cooling decision must begin with the server thermal specification rather than a generic container size. Buyers need to define the design heat load, liquid-cooled percentage, coolant supply and return temperatures, required flow rate, pressure-drop limits, water-quality requirements, allowable ambient range, redundancy target, and expected part-load behavior.
For direct-to-chip systems, the thermal path normally includes the server cold plates, technology cooling loop, rack or row manifolds, a coolant distribution unit, facility water loop, and an outdoor heat-rejection system such as a dry cooler or cooling tower. Every interface changes the available temperature approach and pumping requirement.
NVIDIA’s June 2026 description of its Rubin reference architecture shows where the market is heading. The company says the platform can use fully liquid-cooled servers with coolant supply temperatures up to 45 degrees Celsius and, in suitable climates and designs, closed-loop dry-cooler heat rejection with little or no chiller operation. This is a vendor-specific architecture, not a universal operating point for all AI servers. However, it demonstrates why warmer liquid loops, dry coolers, and coordinated server-to-facility design are becoming central to AI infrastructure economics.
For procurement teams, a CDU should not be selected only by its headline kilowatt rating. Its real suitability depends on usable capacity at the project’s actual temperatures and flow, pump redundancy, heat-exchanger approach temperature, filtration, water chemistry, controls, service access, leak response, and communication with the BMS or DCIM platform.
Go liquid when rack density requires it. Engineer the whole loop before ordering the CDU.
Pro Tip:
Ask the supplier to provide a heat-balance calculation and pump operating point for the exact server configuration. The submittal should show design and part-load flow, supply and return temperatures, pressure drop, outdoor design conditions, and the duty available after redundancy is applied. A nominal CDU rating without these conditions is not a complete engineering answer.
3. The Integration Bottleneck Buyers Underestimate
OpenAI’s reported concern about turning individual components into usable compute points to a familiar project risk: every major product can be technically correct while the complete system still fails to commission on time.
The electrical team may design around one rack count while the mechanical team uses another heat load. The CDU supplier may expect one coolant temperature while the server vendor validates a different range. The controls contractor may receive the I/O list after equipment has already entered production. The site may prepare pipe and cable entries that do not match the factory-built module.
Each mismatch creates redesign, field modification, testing delays, or stranded capacity.
The solution is an interface-controlled design process. Before production release, the project should align at least the following documents:
– Server and rack schedule with maximum and expected operating power.
– Electrical single-line diagram, protection settings, and load schedule.
– Cooling P&ID, heat balance, flow rates, temperatures, pressures, and water-quality limits.
– Equipment layout, service clearances, pipe routes, cable routes, and lifting requirements.
– Controls architecture, I/O list, alarm logic, BMS/DCIM protocol, and remote monitoring scope.
– Fire detection, suppression, emergency shutdown, leak detection, and access-control strategy.
– Site interface drawing covering foundations, utility entries, drainage, grounding, networking, and outdoor heat rejection.
This documentation may appear slower than immediately placing equipment orders. In practice, it is one of the fastest ways to protect the schedule because it moves conflict resolution into engineering instead of commissioning.
4. What a Three-Quarter Deployment Model Actually Requires
Reducing a multi-year delivery cycle does not mean compressing every task into a shorter sequence. It means changing which tasks happen in parallel, standardizing interfaces, and moving integration work away from the construction site.
A faster deployment model usually requires six decisions.
Freeze the operating envelope early
The project must define rack density, IT load, cooling temperatures, ambient conditions, redundancy, controls, and compliance boundaries before detailed manufacturing begins. Late server substitutions can change power distribution, pipe sizing, CDU duty, dry-cooler selection, and control logic at the same time.
Build repeatable capacity blocks
Instead of redesigning the facility for every expansion, buyers can define a repeatable block that combines a known amount of IT capacity with matching power, cooling, controls, and service space. The block may be a containerized AI module, an IT pod, a power module, or a cooling skid.
Run factory work and site work in parallel
Civil works, utility preparation, foundations, and external connections can progress while power and cooling modules are assembled and tested in a controlled factory environment. Schneider Electric describes this modular approach as a way to reduce onsite work, revisions, and complexity while improving repeatability and predictable performance.
Validate interfaces before shipment
Factory acceptance testing should verify more than individual equipment startup. A useful FAT checks protection logic, pump sequencing, redundancy changeover, sensors, alarms, emergency stops, leak detection, BMS communication, and operation under simulated load conditions where practical.
Plan logistics as part of engineering
Transport dimensions, lifting points, center of gravity, route restrictions, packaging, weather protection, and site crane access can determine whether a prefabricated module arrives ready to install or becomes a field-rework project.
Commission by system, then by capacity phase
Mechanical completion is not the same as usable compute. The final schedule needs time for flushing, water-quality verification, electrical testing, controls point-to-point checks, integrated systems testing, thermal validation, and phased rack energization.
Pro Tip:
Build the project schedule backward from the required power-to-rack date, not from the equipment shipping date. Assign a responsible party and acceptance evidence to every interface: utility, foundation, grounding, network, power module, cooling loop, controls, server connection, FAT, site acceptance test, and final load validation.
5. Measure ROI From Power-to-Production, Not Purchase Price
The lowest equipment quote is not automatically the lowest-cost infrastructure plan. A cheaper system that delays energization, limits rack density, requires major field changes, or cannot expand cleanly may create a larger financial loss than its initial saving.
A practical deployment-speed ROI model can begin with four calculations.
1. Delay cost
Delay Cost = Unavailable IT Capacity x Expected Contribution per MW per Day x Delay Days
The contribution figure should be based on the buyer’s actual business model, such as contracted capacity revenue, inference revenue, training capacity value, or avoided cloud expense. It should not be replaced with an optimistic industry average.
2. Usable-capacity ratio
Usable-Capacity Ratio = Continuously Available IT MW / Contracted or Installed Facility MW
This exposes designs that appear large at the utility boundary but lose too much capacity to infrastructure limits, conservative derating, or mismatched cooling.
3. Expansion cost per live megawatt
Include the next-phase transformer, switchgear, CDU, dry cooler, piping, controls licenses, civil work, installation, testing, and the downtime required to connect the expansion. A modular design is valuable only when the interfaces for future blocks are genuinely prepared.
4. Operating cost under real conditions
Model pump power, fan power, chiller hours, water treatment, filter replacement, maintenance labor, redundancy operation, and climate-specific heat rejection. PUE remains useful, but it should be evaluated together with IT utilization, cooling availability, water use, serviceability, and delivered compute output.
The better procurement metric is therefore not cost per container or cost per rack. It is:
Total cost per commissioned, continuously usable megawatt delivered by the required date.
6. Infrastructure RFQ Checklist for AI Data Center Buyers
To receive a technically comparable proposal, buyers should provide:
1. Site and schedule: country, site coordinates, altitude, design temperatures, humidity, dust conditions, target delivery date, and required power-to-rack date.
2. Power: utility voltage, available and future MW, frequency, grounding method, fault-current data, backup strategy, redundancy target, and expected power quality.
3. IT equipment: server model, rack type, rack quantity, maximum rack power, expected utilization, network architecture, and planned expansion phases.
4. Cooling: server coolant requirements, liquid-cooled percentage, supply and return temperatures, flow and pressure limits, water-quality specification, heat-rejection preference, and water availability.
5. Operations: BMS/DCIM protocol, remote monitoring, alarm hierarchy, maintenance access, spare-parts strategy, and local service capability.
6. Safety and compliance: fire strategy, leak detection, emergency shutdown, applicable electrical and mechanical codes, certification expectations, and authority-having-jurisdiction requirements.
7. Site interfaces: foundation, crane access, transport restrictions, piping and cable entry points, drainage, grounding, fiber entry, and responsibility matrix.
Without these inputs, suppliers can only quote assumptions. Assumption-based quotations may look comparable on price while describing very different operating systems.
Final Procurement Verdict
The next AI infrastructure advantage will not come from purchasing accelerators in isolation. It will come from connecting power, cooling, networking, controls, safety, factory testing, logistics, and commissioning into one repeatable delivery system.
Buy the power-to-production path, not just the hardware list.
For projects considering factory-integrated deployment, ACT-Boxes can support project-specific 40HC AI data center modules with liquid cooling or precision air cooling, power distribution, fire protection, monitoring, service access, factory acceptance testing, and delivery coordination. Final IT capacity, cooling performance, PUE, redundancy, certification, and deployment time depend on the selected servers, site conditions, utility interface, code requirements, and project scope.
The three-quarter ambition is valuable because it changes the buyer’s question. The winning design is not the one that promises the largest number of GPUs. It is the one that can prove how those GPUs will be powered, cooled, integrated, tested, delivered, and placed into stable operation on schedule.
