On October 21, NVIDIA presented European developments around DSX, an architecture connecting compute, power, cooling and AI infrastructure operations. It announced three DSX OS components in developer preview: Config Manager, Rack Management Service and Cluster Readiness Engine. It also described closed-loop liquid and dry-cooler designs intended to bring facility cooling water use close to zero. That concerns a particular design boundary, rather than a claim of zero total water footprint. GTC Berlin announcement.
A modular operating layer
The DSX OS page describes a portfolio for provisioning, cluster runtime, workload placement and recovery. Components can be adopted incrementally. Cluster Readiness Engine addresses cluster validation; NVSentinel provides monitoring and remediation in Kubernetes environments. Having these tools does not itself establish the reliability of a particular operator. DSX OS product documentation.
The separate MaxLPS description addresses operation within a fixed power budget by combining thermal, hardware and software approaches. These include 45°C cooling and dynamic power allocation. The objective is more productive computation from available power. We do not present a product's advertised upper bound as guaranteed savings for every facility. MaxLPS overview.
What would make a meaningful comparison
Our editorial assessment is that such infrastructure should be judged against a clearly defined useful output. Request volume, response latency and answer quality are not interchangeable. A facility reporting more output tokens might be serving a different task or operating under different constraints. Without that context, an efficiency percentage is difficult to use for an organization's own investment decision.
Consider a hypothetical operator with a limited grid connection. It could compare two operating modes using the same model, input workload and response-time target. We would ask for measurement across the facility rather than only an individual accelerator. The comparison should also show behavior during busy periods, when one workload's demand might reduce the resources available for another. These are proposed evaluation criteria, not an independent test conducted by SIExpo.
Water requires the same discipline. For a particular comparison, we would define the measurement boundary: on-site cooling water, supplementary systems and the observation period. A reduction in one component does not automatically answer every question about consumption beyond it. That is a suggested way to examine an environmental claim, rather than a separate measurement of DSX or its operators.
Operational readiness needs its own evidence
For infrastructure teams, a useful question about preview software is how it behaves with incomplete configuration, a failed node or unsuccessful recovery. Our proposed starting point would be a limited test environment, explicit permissions for automated actions and a defined return to a previous state. These are editorial assessment recommendations, not instructions to change a live system or a claim that we have tested the software.
The same pilot should record what a human operator must still do when automation reaches its limits. A clean demonstration of a successful recovery would answer only part of that question. Time spent diagnosing an ambiguous failure, deciding whether to retry and restoring service would help establish the operational cost. This is a proposed acceptance test, without a claim about measured faults in the new components.
DSX connects a facility's physical constraints with its daily operation. The announcements offer concrete architectures and tools to examine. Their potential benefits still need evidence under the relevant climate, workloads, equipment and operating team. Developer preview is a product stage and should not be presented as independently established production readiness.
Cover: AI illustration of a hypothetical data center, not a photograph of a real facility.
Sources checked: 2026-10-22T06:12:07.455721+00:00.
