A GPU that is powered on and waiting on the network is still burning the watt you paid for.
On 22 September 2026, NVIDIA engineers Dmitry Shmulevich and Rob Esker published Topology-Aware Workload Scheduling with NVIDIA Topograph, an open-source toolkit that discovers how GPUs and fabric switches are actually wired, normalizes that view, and feeds it to the schedulers that place training and inference jobs. The point is blunt: a scheduler can only honor locality if it can see the topology, and the topology changes as the cluster does.
Placement is a capacity problem
Distributed training and multi-GPU inference move data continuously. Inside a rack-scale domain, NVIDIA NVLink and NVLink Switch give each GPU a dedicated high-bandwidth path — 1.8 TB/s bidirectional per GPU on fifth-generation NVLink (Blackwell-class systems such as GB200/GB300) and 3.6 TB/s on sixth-generation Vera Rubin, per the same post. Across systems and racks, Spectrum-X Ethernet and InfiniBand carry the scale-out traffic. Spread a tightly coupled job across distant domains and that traffic crosses shared links and switches. Contention and latency rise. Throughput falls. The GPUs keep drawing provisioned power while the job waits.
That is the same multiplier we wrote about in AI infrastructure still pays for the byte: every wasted transfer is paid for in bandwidth, time, and energy. Buying another hall does not fix a scheduler that cannot see the fabric it is placing onto.
What Topograph actually does
Topograph splits the work into providers and engines. A provider discovers topology from a cloud API or an on-premises fabric tool — InfiniBand via ibnetdiscover, or NetQ for Spectrum-X and Multi-Node NVLink domains — and normalizes it into a common model. An engine publishes that model in the shape each workload manager expects: Kubernetes node labels, Slurm topology.conf or per-partition topology YAML, Slinky ConfigMaps, or Node Feature Discovery resources.
Cloud integrations listed in the post include Google Cloud, Lambda, Nebius, Nscale, and Oracle Cloud Infrastructure, with more in development. On Kubernetes, Topograph can install via Helm and label nodes with a variable-depth fabric hierarchy (fabric.topograph.run/tier-0 closest to the node, then outward) plus accelerator domain labels. Native affinity, KAI Scheduler, and Kueue Topology-Aware Scheduling can then prefer or require placement inside a locality domain. A node observer regenerates the map when watched nodes or pods change, so the scheduler is not stuck on a manually edited snapshot.
On Slurm, the same discovery path writes tree or block topology and can trigger scontrol reconfigure. The matrix of supported provider-to-engine combinations is dated to upstream main as of 16 September 2026 in the announcement.
Why this matters for the buildout
AI factories are power-limited systems. The Topograph post frames the win in tokens per watt and job cost: keep tightly coupled work inside high-bandwidth domains, keep GPUs doing useful work instead of spinning on congested paths. That is not a substitute for lossless compression of the bytes that still have to move — it is the scheduling half of the same capacity story. Less cross-domain chatter means less fabric contention and less energy spent on waiting.
The toolkit is open source under the DSX AI factory umbrella. Operators who already run Kubernetes or Slurm can consume a live fabric map without inventing their own discovery loop. The remaining judgment call is whether your cloud or on-premises fabric is among the providers that report accurate topology today — Topograph reflects what the provider reports, not an intended design.
The next halls will still buy megawatts and 800 Gb/s ports. The open question is whether the scheduler that fills them can see the road map.