A reservation for thousands of GPUs can look reassuring on a capacity plan. Yet the harder question may emerge only when the hardware assigned to that reservation changes. The building can still have floor space, electrical allocation, network connectivity, and an active commercial commitment while struggling to support the heat profile of the next compute platform. NVIDIA’s current GB300 NVL72 architecture, for example, uses a fully liquid-cooled rack-scale design, illustrating how tightly high-end compute now connects server selection with cooling infrastructure. For AI buyers, this changes what “reserved” should mean across a multiyear infrastructure agreement. A capacity commitment that survives commercially may still face physical limits when the underlying compute architecture advances.
The risk does not mean customers should assume every future GPU deployment will overwhelm existing facilities. It means they should separate several resources that contracts often bundle into one capacity number. Power availability tells a customer whether electricity can reach the IT environment, while cooling capability determines whether the resulting heat can leave that environment within required operating conditions. Rack design, coolant distribution, heat exchangers, manifolds, piping, and facility-side systems all influence that equation. Open Compute Project work on advanced cooling explicitly covers components from cold plates and coolant distribution units to immersion systems and heat reuse, showing how broad the thermal chain has become. Therefore, customers evaluating long-duration reservations need to understand whether the supporting physical infrastructure can evolve with the hardware they expect to install.
A Compute Reservation Is Not Automatically a Cooling Reservation
An AI buyer may negotiate around GPU quantity, cluster size, megawatts, deployment dates, or access to a particular hardware generation. Those measures matter, but none independently describes the complete thermal capability supporting the workload. Two halls with similar electrical allocations can accommodate very different equipment configurations when their rack-level cooling systems, liquid loops, distribution equipment, and heat-rejection infrastructure differ. Uptime Institute notes that AI and high-performance computing systems use specialized hardware and high-speed interconnects that tend to create much denser environments than typical IT equipment. That density creates corresponding thermal-management challenges, especially as customers consolidate substantial compute inside tightly integrated racks. Buyers should consequently treat cooling characteristics as part of usable compute capacity rather than as an invisible facility service.
This distinction becomes important when reserved infrastructure extends beyond one hardware cycle. A customer could secure capacity before finalizing the exact servers that will occupy it, particularly when deployment dates sit months or years ahead. During that interval, accelerator platforms can change, and the chosen configuration can arrive with different cooling interfaces or rack requirements. NVIDIA documents its GB300 NVL72 as a liquid-cooled architecture, while its reference architecture states that a full rack can require up to 142 kW. That figure should not become a generic assumption for AI racks because configurations differ significantly across hardware and deployment models. It does demonstrate why a reservation defined mainly through floor area or total site megawatts may provide an incomplete picture of whether a particular future system can actually operate there.
Hardware Roadmaps Can Move Faster Than Facility Infrastructure
GPU hardware and the facility systems supporting it can follow different replacement and upgrade cycles. A new compute generation does not necessarily require a new building, although deploying it may require changes to power, cooling, networking, or rack infrastructure. Cooling infrastructure cannot always make the same transition through a simple equipment swap because it extends across racks, distribution systems, heat exchangers, pumps, controls, connections, and facility loops. Open Compute Project documentation describes the technology cooling system as including components such as cold plates, rack manifolds, coolant distribution units, heat exchangers, hoses, and couplings. Each component introduces design parameters that must align with the equipment deployed downstream. However, a facility designed around one operating envelope cannot automatically promise compatibility with every denser platform that follows.
The industry’s direction makes this mismatch worth examining before procurement teams sign long commitments. Open Compute Project says its community is working on rack architectures spanning power envelopes from 250 kW to 1 MW as part of efforts around next-generation AI clusters, although those figures describe development targets rather than typical deployed racks. The same initiative highlights advanced cooling, higher-voltage power delivery, interconnects, and rack architecture as interconnected infrastructure challenges. Such work does not establish that every AI installation will reach those densities. It does show that infrastructure engineering is already preparing for configurations far beyond conventional rack assumptions. A customer buying several years of compute access should ask whether its reserved location has an upgrade path toward the expected hardware roadmap, rather than assuming that available megawatts guarantee future deployment compatibility.
The Constraint Can Appear at Rack Level First
Aggregate site electrical capacity does not by itself establish the thermal capability available to every rack or deployment area. Higher-density equipment can demand changes to coolant delivery, rack manifolds, CDU placement, flow conditions, connections, monitoring, and leak-management systems. OCP’s current cold-plate work specifically addresses technology cooling components from cold plates through tubing, manifolds, quick disconnects, and CDUs. This means the question is not simply whether a building supports liquid cooling in a general sense. AI customers need to know what cooling architecture reaches the exact racks associated with their contracted deployment and what limits apply there. That distinction becomes increasingly important when future hardware introduces thermal requirements that differ from those assumed when the original capacity reservation was made.
That detail can materially change the value of an infrastructure reservation. Suppose a customer has secured enough aggregate site power for a future cluster, but the reserved area cannot accommodate the required rack-level thermal design without modification. Depending on the facility design, resolving that mismatch could require changes to equipment placement, rack density, cooling infrastructure, or deployment location. Those responses can affect network topology, deployment schedules, usable floor area, and potentially the commercial assumptions behind the original reservation. Meanwhile, the underlying capacity has not disappeared; its usefulness has changed relative to the equipment the customer now wants to deploy. For a C-level buyer, that distinction turns thermal engineering from an operational detail into a question about whether contracted infrastructure can support the intended technology roadmap.
Thermal Compatibility Should Become a Contract Question
Customers do not need to turn procurement teams into cooling engineers, but they do need contractual visibility into the relevant operating envelope. Instead of asking only whether a provider offers liquid cooling, buyers can request the supported rack configurations, cooling architecture, upgrade boundaries, interface requirements, and conditions attached to future hardware substitutions. Technical diligence should also clarify which party funds modifications when a later server platform needs different distribution equipment or physical interfaces. OCP’s cooling work demonstrates why these questions can become detailed: the ecosystem includes cold plates, cooling loops, heat-transfer fluids, tubing, manifolds, quick disconnects, and CDUs. A vague promise of “liquid-ready” infrastructure therefore communicates much less than a documented description of what the reserved environment can actually support. Procurement teams can use that detail to connect a commercial commitment with the physical capability available behind it.
Contract language also needs to distinguish current compatibility from future upgrade responsibility. A provider can accurately state that an environment supports the hardware specified at signing without guaranteeing support for an unknown future platform. Customers should identify that boundary before building an AI roadmap around a long reservation period. Useful diligence can examine what happens when the next approved server design exceeds existing rack conditions, requires another coolant arrangement, or needs infrastructure work before installation. The commercial issue is not whether technology will inevitably outgrow the site, because that conclusion would require knowledge of both the future equipment and the specific facility. The issue is whether the agreement clearly assigns the technical, financial, and scheduling consequences if those requirements change.
Upgradeability Can Matter More Than Spare Megawatts
Procurement discussions often treat additional power as the clearest form of future headroom. Yet spare electrical capacity offers limited protection if the supporting thermal system cannot accommodate the intended equipment configuration. Cooling headroom involves more than heat-rejection capacity because the path between silicon and the facility system contains several components and interfaces. Uptime Institute observes that increasing silicon power, richer server configurations, and higher utilization are pushing the industry toward greater density and wider consideration of direct liquid cooling. Its 2025 survey data also found typical rack densities shifting toward 10 kW, with more than one-quarter of operators reporting densities above that level, although those fleet-level observations should not serve as assumptions for a specific AI facility. Buyers need site-specific engineering data rather than industry averages when testing whether reserved infrastructure can absorb future equipment.
Documented cooling interfaces, rack-level operating limits, and clearly defined facility-side requirements can give customers better visibility into the available upgrade path, although the value of each depends on the specific facility design. Buyers should connect hardware planning with the physical systems expected to support it throughout the contract term. That does not require predicting the exact thermal characteristics of GPUs that have not yet shipped. It requires understanding where today’s facility limits sit, which parts can expand, how upgrades would occur, and who carries the cost and schedule risk. Ultimately, the most valuable reserved capacity may be the capacity whose physical envelope can evolve alongside the compute strategy it was purchased to support. That makes thermal compatibility a strategic capacity question rather than something buyers can safely leave until the hardware arrives.


