[wtomin]

What this changes

Adds the VeRL-Omni v0.3.0 release post. It covers async and decoupled RL
execution, the V1 trainer becoming the default, and two end-to-end recipes:
MiniMax H3 audio-video post-training with DiffusionNFT, and MiniCPM-o 4.5 GSPO
with a sync vs. separate-async crossover study.

For a new post

• Proposal issue this follows up on:
• Link to the work it describes: https://github.com/verl-project/verl-omni/releases/tag/v0.3.0

Checklist

• python3 scripts/check_posts.py passes
• hugo --buildDrafts --buildFuture builds without errors
• python3 scripts/check_links.py reports no broken internal links
• draft: true removed, and date is the intended publication date
• Images are in the post directory and referenced by filename
• Any performance numbers state hardware, model and baseline
  Notes on the checklist (for your reference)
• check_posts.py — ✅ verified passing; the new post has no errors or warnings.
• hugo build — I couldn't run it here (Hugo isn't installed in this environment). Worth running once locally before opening the PR.
• check_links.py — I ran it; it reports 60 "broken" links, but they are all stale /livereload.js artifacts left in the pre-existing public/ directory from an earlier hugo serve session, none related to this post. The post's own links and local images are clean.
• Draft flag — removed; date: 2026-10-29 matches the directory prefix.

[SamitHuang]

Requesting changes. The writeup tracks the v0.3.0 themes, but the two case studies state results a reader cannot reproduce from the tagged recipes, and the MiniCPM conclusion points at a 2+2 launcher the prose says never wins.

The H3 table mixes launcher defaults with a different 8-GPU README example, drops the 96 GB constraint, and presents a v0 DiffusionNFT run beside a V1-default release. The MiniCPM timing table is a different experiment from PR #629, cannot be the documented 128×16 batch on 3 trainer GPUs, and the crossover / constant 2+2-deficit claims are not in the table. The upgrade list also skips offline DPO staying on v0 and the named-media and attention fail-closed breaks.

The PR body's proposal-issue line is empty. Please link the proposal if one was opened.

[SamitHuang]

This table does not match one documented command, and it is less specific about hardware than the recipe it cites. On tag v0.3.0 the T2VA launcher defaults to TP=2 and ROLLOUT_N=16, while the README's 8-GPU example is ROLLOUT_TP=4 ROLLOUT_N=4, and the FL2VA section uses ROLLOUT_N=4 because TP=2 does not leave room for weight sync on a 96 GB GPU. Those DiffusionNFT launchers set trainer.use_v1=false (the V1 H3 scripts are FlowGRPO), the default FL2VA path is first-frame only (FRAME_INDICES='[0]'), and "0.27 to above 0.4" is critic/rewards/mean over ~60 noisy steps that only clear 0.4 at the end. Please name the exact command and GPU, and note that ImageBind is CC-BY-NC-SA.

[wtomin]

It's true that T2VA launcher defaults to TP=2 and ROLLOUT_N=16, but in the readme, it uses ROLLOUT_TP=4 ROLLOUT_N=4. However, FL2VA launcher's defaults are ROLLOUT_TP=4 and ROLLOUT_N=16, and the readme example stays to its default.

I supplement the other information too, like the trainer.use_v1=false, reward model license, curves description, etc..

[SamitHuang]

This comparison does not isolate placement, and a 3+1 arm cannot be the shipped 128×16 batch. docs/algo/separate_async_omni.md requires ppo_mini_batch_size × rollout.n to divide the actor pool; with n=16, no divisor of train_batch_size=128 is divisible by 3, which is why that doc uses an 8 × 15 reshape instead of 16 × 16. PR #629's published H800 result is the shipped 2+2 recipe (the 0.764 vs 0.762 scores above), at 285 s/step versus 410 s for colocated with parameter offload left on — this table is a different sweep, with no run link, and it does not say whether offload stayed fixed. There is no 256-token row for "overtakes between 256 and 512", steps 3–22 are not 20 independent trials, and the 2+2 "≈107 s at every tier" figure is not in the table, but the launcher below is that 2+2 script.

[wtomin]

I removed the 2+2 description, because it does not appear in the table.

I also updated the batch size.

[SamitHuang]

"Check these changes first" skips the breaks that fail closed on existing launchers. Offline DPO stays on the v0 trainer, including the MiniCPM offline-DPO row above, so trainer.use_v1=false is required there and not only for unmigrated scripts. Unlabelled diffusion rollout tensors are now rejected, and a missing FlashAttention kernel errors at startup instead of falling back to SDPA. Those are already in the v0.3.0 breaking-changes list and will hit current recipes before the Qwen3-Omni launcher rename does.

[wtomin]

Good catch — the section currently leads with the launcher rename, but these fail-closed breaks hit existing recipes first. I'll add them ahead of the Qwen3-Omni bullet, matching the release notes:

• Offline DPO stays on v0 (#650): it needs explicit trainer.use_v1=false — this applies to the MiniCPM offline-DPO recipe referenced in the table above, not just to unmigrated scripts.
• Unlabelled diffusion rollout tensors are rejected (#557): custom rollout adapters/rewards must move to the named media artifact contract.
• Missing FlashAttention kernels fail at startup (#530): no silent fallback to SDPA anymore.

[SamitHuang]

lgtm