Buy an operating boundary, not a cooling adjective
Liquid-cooled describes a family of systems, not a service level. A remote buyer needs to know which equipment is in the offered path and who operates each part. A cold-plate arrangement can include server cold plates, tubing, quick disconnects, rack manifolds, a secondary loop, a coolant distribution unit, and a facility water system. Open Compute Project material explicitly depicts these layers and emphasizes compatibility among wetted materials and coolant.
Ask the provider to draw the offered boundary from chip to heat rejection and mark ownership, monitoring, maintenance, and escalation at every handoff. The answer should identify whether the server vendor, hosting operator, facility landlord, or another contractor owns the rack loop and coolant distribution unit. Without this map, a promise of liquid cooling says little about who responds when flow, pressure, leak detection, or facility supply leaves its expected range.
Assign responsibility at each interface
Request a responsibility matrix for facility water, heat exchanger or coolant distribution unit, secondary coolant, pumps, filters, manifolds, hoses, quick disconnects, cold plates, leak detection, controls, and server firmware. For each item, ask who selects specifications, commissions it, monitors it, carries spares, performs preventive maintenance, authorizes isolation, and restores service. Also ask which telemetry the customer can see remotely and how long raw records are retained.
Quick disconnects deserve specific questions because they are service interfaces as well as components. Ask whether connections are hand-mated or blind-mated, what compatibility standard or vendor specification applies, how mating cycles are tracked, how residual fluid is managed, and what inspection follows reconnection. Do not ask sales staff for an unsupported leak-free guarantee. Ask for the documented procedure, training ownership, alarm path, and relevant maintenance record.
Map maintenance to workload impact
Obtain planned maintenance frequency, notice period, expected service interruption, draining or isolation requirements, and post-maintenance validation. Ask whether server service requires isolating one tray, one manifold, a rack, or a wider loop. OCP's cold-plate work treats quick disconnects as a means to detach equipment for serviceability, but the presence of a connector does not by itself prove that maintenance is online or confined to one server.
Translate each procedure into scheduler consequences. Can jobs checkpoint before isolation? Are nodes drained automatically? Is spare capacity available during a coolant distribution unit service window? What happens to reserved capacity and billing when a maintenance event exceeds its window? The written answer should distinguish routine preventive work, component replacement, coolant sampling or treatment, firmware or control work, and emergency response.
Draw failure domains before counting GPUs
Ask for a dependency diagram showing which servers share a manifold, pump set, coolant distribution unit, facility branch, controller, power feed, and alarm path. Redundant pumps do not eliminate a common controller, valve, filter, heat exchanger, or facility supply dependency. Likewise, two racks may appear separate while sharing the same secondary loop. Request the maximum number of offered GPUs made unavailable by each single planned isolation and each documented component failure mode.
Use a measurable buying rule: the capacity counts toward a hard availability requirement only if the provider identifies its shared dependencies and demonstrates that the largest credible maintenance domain fits within your tolerated unavailable GPU count. If the workload tolerates queueing, a larger domain may be acceptable at a lower service class. If it requires continuous service, distribute capacity across genuinely independent domains and verify that the scheduler and network design can use them.
Worked example: count usable capacity, not installed devices
Consider an illustrative requirement for 64 continuously usable GPUs with tolerance for one eight-GPU server offline. A provider offers 80 installed GPUs in ten eight-GPU servers. If all ten servers share one coolant distribution unit and a planned service isolates the full loop, installed headroom does not satisfy continuous usability during that window: 80 minus 80 equals zero. Actual architectures and commercial terms vary.
Suppose a revised offer places five servers on each of two independently serviceable loops, and one loop can be isolated while the other runs. The maintenance domain is then 40 GPUs, still larger than the tolerated eight. The buyer could change the workload objective, require smaller domains, or acquire capacity in another independent location. The lesson is arithmetic tied to a dependency diagram, not an assumption that 16 spare installed GPUs cover every cooling event.
Validate performance with completed-work tests
Avoid negotiating around an unsupported coolant temperature or a generic claim that liquid cooling prevents throttling. Instead, define an acceptance workload and outcome: model revision, precision, batch or traffic distribution, GPU count, run length, quality criterion, completed-work rate, latency where relevant, error rate, and allowed variability. Run long enough to cover steady state and representative workload phases, with synchronized clock-event and temperature-margin telemetry supplied by the operator.
One illustrative acceptance rule is that each of three long runs must complete successfully, median throughput must stay within 3 percent of the agreed reference, and no thermal clock-event reason may persist during declared compute phases. The percentages are planning assumptions, not hardware specifications. Preserve the raw logs and system configuration. A pass establishes performance for that tested boundary and workload; it does not certify every model, season, rack state, or future software release.
Ask what evidence arrives during an incident
Request sample, redacted incident artifacts before signing: alarm timestamps, affected dependency, customer notification, workload drain record, operator actions, restoration test, and post-incident review. Ask which conditions trigger automatic shutdown, controlled drain, or continued operation, but leave safety thresholds and physical interventions to authorized operators. Confirm the communication channel, acknowledgment target, escalation ladder, and evidence available to a remote customer.
Also ask how capacity is treated while impaired. The technical record should name installed, schedulable, allocated, and successfully completed capacity separately. A server that is powered but excluded after a cooling alarm is not schedulable. A node that accepts jobs but repeatedly fails them is not useful capacity. These definitions make performance credits or operational reviews possible without pretending the telemetry alone settles contractual questions.
Record open questions as procurement conditions
Summarize diligence in four columns: dependency or procedure, responsible party, evidence supplied, and unresolved condition. A useful final gate is that no capacity enters the committed plan while ownership of its cooling loop, maintenance isolation domain, incident escalation, or acceptance test remains unknown. Where evidence is unavailable, classify the offer as best-effort or trial capacity and keep it outside hard service commitments.
Remote diligence has limits. Diagrams can become stale, telemetry can omit physical conditions, and an acceptance run cannot reveal every materials, water-quality, maintenance, or control failure. Independent inspection or certification may be appropriate for a large commitment, but it does not replace workload validation. The buyer's defensible position is narrower: know the operational boundary, size the failure domains, require observable procedures, and count only capacity that passes the agreed test.