[garrett361]

This PR gives RL the same pad_to_seq_len flag that SFT supports (#4160). The flag pads every packed row to seq_len, so torch.compile and DeepGEMM stop recompiling on new lengths. Full-length padding makes an existing MoE problem worse (identical pad tokens all route to the same experts), so this PR also changes RL and SFT to pad with the row's own tokens instead of a constant id.

• RL used to pad with token 1, and router replay padded with zero bytes, which sent every pad slot to expert 0. This PR pads text rows with their own tokens and replay with their real routes.
• Multimodal rows keep a constant pad id, because a repeated image placeholder would have no image feature to receive.
• This PR supersedes fix: content padding in sft #3932 / fix(sft): pad packs with their own tokens to avoid MoE expert hot spots #4149 (SFT pad content, credit Mika). Please keep the Co-authored-by: Mika Senghaas trailer when squashing. Related: fix(trainer): distribute routing replay padding across experts #3350.

We ran FP8 e2e checks on one H200 node per run, each with an empty DeepGEMM cache (harness in a31524e):

Run	Dynamo recompiles per rank, total (after step 1)	DeepGEMM compiles, total (after step 1)
SFT GLM-4.5-Air 4L --data.pad-to-seq-len	1 (0)	22 (0)
SFT GLM-4.5-Air 4L	3 (0)	34 (7)
RL Qwen3-30B-A3B + replay --orchestrator.pad-to-seq-len	0 (0)	17 (0)
RL Qwen3-30B-A3B + replay	1 (0)	54 (28)

The flag only makes the row length static: the number of micro batches per step, max_seqlen, and multimodal shapes still vary. The throughput and MFU metrics count padding, so they are not comparable with and without the flag.

🤖 Generated with Claude Code

[samsja]

lgtm

[EazyReal]

Thanks for getting this landed. I appreciate the broader coverage here—SFT, pad_to_seq_len, and H200 end-to-end validation—and recognize that repeating real tokens and replay routes is a different implementation from the balanced assignments in #3350.

I’ve closed #3350 as superseded for the original zero-filled replay-padding hotspot. I’d still like us to resolve attribution for the earlier contribution: that PR identified the expert-0 hotspot and provided a proposed fix before this PR was opened.

Could we work out an appropriate way to give that work coauthor credit? That is the recognition I’m asking for; the current “Related: #3350” reference doesn’t fully convey the original diagnosis and implementation. I’m not claiming authorship of the distinct implementation here.

I understand this has already merged and that changing the existing commit’s trailers would involve rewriting history. I’m happy to work with you on a practical way to make the attribution right. If coauthor credit isn’t appropriate under the project’s contribution policy, could you explain how that policy applies here so we can resolve this with a shared understanding?

Thanks—I’d like to get this sorted out constructively and keep contributing.