Synchronous data-parallel training usually assigns every rank the same number of records, even when record costs vary by orders of magnitude. For variable-length models, this converts input variation into idle time because each step waits for its most expensive rank-local batch. We present Batch Cost Lookahead (BCL), a coordination-free data-loading policy that buffers a bounded rank-local window and repartitions it into fixed-cardinality packs with balanced estimated cost. BCL preserves the trainer's record-count contract and requires neither cross-rank metadata exchange nor runtime modification. In simulation over public workload distributions, enabling BCL reduces per-rank estimated batch-cost variability by up to 82.8%. Across 13 NeMo-RL SFT corpora on eight H200 GPUs, rank-local BCL runs 1.050 to 1.167 times faster than pooled MFFD. Compiled H200 measurements on an internal sequence workload show speedups of 1.197 to 1.343 times over packed execution from one to four nodes. We also identify a memory-feasibility boundary: a p99 cap for high-variance or OOM-prone data bounds outliers before BCL balances the rest. These results show that substantial variable-cost imbalance can be removed at the data-loader boundary, while clarifying when data preparation or broader coordination is still necessary.
Figures & tables
Diagnostic
Implication
η<1 , δ≈1
Local variation is potentially reducible; increase bounded lookahead until marginal gains saturate.
η≥1
A record meets or exceeds mean modeled pack cost; cap, split, or change its representation before scheduling.
δ>1
Rank-window means differ; if material, reshard or use cross-rank coordination.
ρ≈1
Little modeled imbalance remains; limited modeled scheduling headroom.
Table 1: Workload boundary and appropriate intervention.
Dataset
Records
p50
p99
Alpaca
30,000
59
270
CodeParrot
30,000
975
20,423
Dolly
15,011
101
1,146
OpenHermes
30,000
237
2,468
OpenWebMath
30,000
763
16,900
UltraChat
30,000
1,051
3,004
Table 2: Public length arrays used by the scheduling simulation. Percentiles are token lengths before the 1,024-token cost cap.
Dataset
CV, K=1
CV, K=32
ΔCV
Alpaca
0.187
0.032
82.8%
CodeParrot
0.051
0.009
81.5%
Dolly
0.228
0.041
82.1%
OpenHermes
0.133
0.024
82.2%
OpenWebMath
0.066
0.012
81.4%
UltraChat
0.036
0.006
82.3%
Table 3: Paired public-distribution simulation. Both arms consume the exact same sampled record stream on every rank. Δρ is the reduction in ρ−1 .
Arm
Assignment
Default packing
Per-rank reader and collector; next B documents from each rank, no lookahead.
BCL
Same per-rank path with K=32 ; exactly B documents per rank.
Pooled MFFD
Earlier global-input path; per-step token-budget packing into one row per rank.
NeMo default path
Own loader and MFFD packer; potentially multiple rows per rank.
Table 4: NeMo-RL SFT comparisons. Only the first two arms share the per-rank input path. MFFD is a pooled reference from the preceding campaign; the default path was rerun in the current campaign.
Corpus
vs. pooled MFFD (%) *
vs. default packing (%)
vs. NeMo default (%) †
Alpaca
+5.0
+0.4±1.4
+122.8±2.5
Dolly
+12.3
+4.3±0.4
+77.1±2.0
OpenHermes
+11.3
+7.5±0.5
+74.8±0.8
OASST1
+9.5
+4.9±1.2
+109.1±1.0
OASST2
+11.1
+5.5±0.3
+104.2±2.1
FineWeb
+16.7
+22.7±0.2
+58.5±0.9
Table 5: NeMo-RL SFT wall-clock speedup at B=8 , defined as 100(tbaseline/tBCL−1) . Values are percentages; ± terms are standard deviations in percentage points over three repeats. Pooled MFFD uses a cross-campaign ratio of mean per-step times.
Ranks
K=1
K=32
K=64
8
1.1438
1.0261
1.0192
16
1.1931
1.0363
1.0286
Table 6: Modeled straggler ratios from scheduling 327,680 measured capped lengths, not GPU step times.
Nodes / ranks
Packed
BCL
Speedup
1 / 8
0.3915±0.0035
0.3271±0.0005
1.197 ×
2 / 16
0.4398±0.0035
0.3540±0.0005
1.242 ×
4 / 32
0.5436±0.0233
0.4049±0.0034
1.343 ×
Table 7: Primary measured compiled H200 step time. Values are mean ± sample standard deviation in seconds per step across repeated runs.
K
1
2
4
8
16
32
64
ρ
1.159
1.107
1.076
1.054
1.038
1.027
1.019
Table 8: Calibrated Feed workload sensitivity. These values are model/replay outputs, not direct hardware measurements.