Engineering brief
NVL72 Racks Create a Scheduling Cliff That Kubernetes Cannot See
At a glance
The brief is enough
- Relevance
- Practical value
- Radar
- Time horizon
- Now
- Warnings
- None
On NVL72 hardware a single misplaced GPU costs 18x performance. Kubernetes and quota don't know where GPUs sit.
NVL72 hardware is too expensive to leave performance on the table. Topology-aware scheduling is now operational necessity.
Watch if you manage or operate NVL72 GPU clusters and need concrete production patterns for topology-aware scheduling.
Summary
The core problem. Training jobs spread across hundreds of GPUs and at every step every GPU must exchange data with every other GPU. The job runs at the speed of its slowest connection. On NVL72 hardware the NVLink domain is the entire rack of 72 GPUs. Stay inside the rack and every link runs at 900 GB/s. Cross to another rack and you drop to 50 GB/s over InfiniBand. That is an 18x speed cliff.
What Kubernetes misses. Kubernetes places pods one at a time wherever there is room. Quota tells you how many GPUs you may use but not where they should go. A 512-GPU job can be admitted correctly within quota and still land scattered across racks running at a fraction of peak performance. The speaker shows a 16-GPU example: a single misplaced GPU forces every communication round onto the network instead of only the final round. The same job the same quote usage but dramatically slower.
The scheduling fix. The Q batch scheduler fills the gap. Platform teams declare the cluster topology once as an ordered list of node labels. Users add a single annotation on their pod template. The annotation has three modes: unconstrained (no placement promise), preferred (best effort shape), and required (don't start until the shape is right). The rough rule is that pre-training uses required, post-training uses preferred, and inference or single-node workloads use unconstrained.
Production reality 1: test pods and preemption. When Cohhere first turned on topology-aware scheduling it interacted badly with CoreWeaves HPC verification pods. Q counted the test pods as real usage and blocked customer jobs. The fix was to omit the Q label on test pods set their priority to negative one and let ordinary Kubernetes preemption evict them when a real workload arrived. Q never knew they existed.
Production reality 2: fragmentation. Over time jobs finish in random sizes and leave holes. Aggregate free capacity can look plentiful while no single rack has enough contiguous GPUs for a large job. The cluster is a third empty but the hero workload cannot start. Q can slow the decay with different placement policies but nothing today can bend the curve back up. The only things that open a rack are jobs finishing or preemption.
My take
I've seen teams buy expensive GPU hardware and then treat scheduling as a Kubernetes default. This talk is a necessary corrective. The 18x cliff between NVLink and InfiniBand is real and the example of a single misplaced GPU turning every round into a network round is devastatingly clear. What most viewers will miss is that the fragmentation problem is unsolved. The stop-gap controller from CoreWave buys time but configurable preemptions in Q are not yet merged. Any team running NVL72 should plan for a dedicated operations rotation to manage topology state. The hard work is not the configuration. It is the ongoing monitoring of fragmentation and the politics of preemption across teams.
What to do with this
- Audit your current GPU cluster for topology boundaries and measure the performance cliff between NVLink and network.
- Plan a pilot of topology-aware scheduling with Q or an equivalent scheduler on one rack before expanding.
- Define preemption policies between teams before fragmentation blocks your highest-priority jobs.
Watch the video
This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.
Related breakdowns
Agent trust starts with tracing, not with better prompts
MasterClass built a four-agent AI teacher, but the operationally interesting part is the tracing layer that turns one learner complaint into a searchable…
Aston Martin F1 shows why embedded AI engineers beat model selection
How an embedded CoreWeave team turned F1 data chaos into three practical AI projects, and why domain context beat model choice.
IBM's GB200 rental shows security, not speed, decides GPU cloud success
IBM treats rented GB200s as primary AI infrastructure. The bottleneck is identity, egress, and agent sandboxing, not hardware.
Get TL;DW
Too Long; Didn't Watch.
A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.
Free. Weekly. No hype.
Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.