[yuki-97]

What does this PR do ?

Fixes two failing nightlies:

1. flow_grpo-qwen-image-ocr-2n8g-dp16-lora
2. sft-gpt-oss-20b-1n8g-automodel-ep8

What changed

1. Run the apt install as a Ray task pinned to each alive node in common.env. #4696 ran apt-get once in the driver shell, so on 2n8g only the head node got libxcb1, and _RewardWorker on the other node still failed with ImportError: libxcb.so.1. The #4696 validation passed because that container already shipped the libs (libxcb1 is already the newest version), so the install was a no-op. The install moves after uv sync because uv run --no-sync python needs the venv.

2. Re-baseline sft-gpt-oss-20b-1n8g-automodel-ep8.sh. train/loss["50"] < 0.4 becomes < 0.35, train/grad_norm["50"] < 17.5 becomes < 14.0, and > 10.0 becomes > 8.0. The old band was set in #1708 and every nightly since the Automodel r0.6.0 bump (#3498) fails the lower bound. The shift is a benign change from the bump, not a regression:

	before #3498	after #3498
loss, step 1	5.734	5.7337
loss, step 3 / 10 / 40	2.956 / 0.548 / 0.274	2.53 / 0.44 / 0.255
loss, mean of steps 40-50	0.282	0.255
grad_norm, step 1	518.3	518.2
grad_norm, step 50	14.4	9.5-9.9 (3 nightlies), 10.1 (bump branch)
grad_norm, mean of steps 40-50	16.1	~11.8 (bump branch)

• Step 1 is identical, so forward/backward scale and data are unchanged. The curves diverge from the first optimizer update on, and loss is lower throughout, so the smaller grad_norm follows from being closer to convergence.
• Nothing in build(automodel): bump Automodel to r0.6.0 #3498 changes the loss scale for this recipe: it has cp=1, so cp_gradient_fanout is 1, and the scale_grads_and_clip_grad_norm call is unchanged. max_grad_norm is 1.0, so the update is clipped on both sides of the bump.
• The new bounds leave room for step-to-step noise: in the same runs steps 48/49 sit at grad_norm 12.0-13.6 and loss 0.28-0.30, so tighter bounds such as 8-11 and < 0.3 would fail on step-50 placement alone.

Tests

Validated both recipes. All checks pass.

🤖 Generated with Claude Code

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[yuki-97]

Self-review via /review-pr-team: 2 agents (reviewer, devil's-advocate pass).

Verdict — no findings above the confidence bar. LGTM, no action needed.

Verified clean

• The per-node install cannot race node registration: ray.sub:1141 only starts the driver once all NUM_ACTORS workers are online, so ray.nodes() already lists every node.
• ray.init(address="auto") attaches to the running cluster, the same call the driver path makes at virtual_cluster.py:483, and ray is importable because the install now runs after uv sync.
• A failed install propagates: check=True raises in the task, ray.get re-raises in the driver, and common.env:5 sets set -eou pipefail with the recipe scripts calling run_flow_grpo_recipe as a plain statement.
• The new SFT bounds are not vacuous: step-50 grad_norm of 9.5-10.1 sits inside 8.0-14.0, and loss of ~0.255-0.30 is under 0.35.

Lower-priority notes that are not inline

• main still has the old SFT bounds, and its research/flow_grpo/tests/test_suites/common.env has no cv2 apt install; #4789 (the main cp of #4696) still carries the driver-only version. This PR has no cherry-pick-to-main label, so nothing will land it on main automatically.
• grad_norm["50"] < 14.0 is the thinner of the two grad_norm bounds against the 12.0-13.6 seen at steps 48/49; < 15.0 would be an optional loosening.

Generated by Claude Code

[yuki-97]

/ok to test 00824a0