SkyPilot's 27% NVL72 capacity comparison describes modelled nodes available to a single very large job. It compares 16-node slices with full 18-node racks when some nodes are unavailable. It does not establish a 27% training-speed improvement or the gain an operator will achieve across a shared cluster.
Why smaller slices can help
An NVIDIA GB200 NVL72 rack connects 72 Blackwell GPUs across 18 compute trays through NVLink. A slice is a group of nodes that must fit within one rack. Keeping communication within that network makes the physical placement of a distributed job important.
An allocation needing all 18 nodes cannot fit within the rack when one is unavailable. A 16-node allocation can still fit with two nodes unavailable. In the model, choosing 16-node slices leaves two nodes per healthy rack outside that job's allocation, trading some immediate capacity for tolerance of unavailable nodes.
SkyPilot reports observing node-unavailability rates of around 2% on production NVL72 clusters. At that rate, its presentation of NVIDIA's model for a 128-rack cluster yields 2,037 usable nodes with 16-node slices versus 1,602 with 18-node slices, about 27% more.
NVIDIA describes the model as considering a single very large job using a specified segment size. The figures describe capacity available to that allocation pattern. They do not measure completed work across a shared workload mix. SkyPilot's production observation and the model result have not been independently reproduced for this article.
Capacity and throughput answer different questions
SkyPilot separately reports a comparison by NVIDIA's GR00T team during pre-training of GR00T N1.7 on 512 GB300 GPUs across 128 nodes. One run placed nodes across an arbitrary number of racks; the rack-aware run used exactly eight racks. SkyPilot reports that rack-aware placement raised throughput by 14.4%, cutting each iteration from 1.59 s to 1.39 s. That result concerns training speed rather than the number of nodes available for allocation. It is a reported comparison, not a test performed for this article.
What Slurm users can take from it
Operators using Slurm can express placement requirements through block scheduling and segment controls documented by NVIDIA. NVIDIA says using 18-node segments could be discouraged in favour of 16-node segments because the smaller allocation gives Slurm more opportunities to use blocks with drained or downed nodes.
Segment size also depends on the application's NVLink communication requirements. A 16-node segment is therefore not a universal recommendation. Nor does selecting that segment size alone establish that two healthy nodes are reserved as replacements: NVIDIA's segment control specifies placement groups, while SkyPilot separately describes a scheduling and recovery policy that reserves spares.
For an operator evaluating smaller allocations, a useful next test is whether they reduce failure-related waiting enough to offset the healthy capacity left outside the allocation. Record queue time alongside completed training work across the actual workload mix, including periods when nodes are unavailable. That evaluation would answer a question the single-job capacity model does not resolve.