[veomni] feat: enable VeOmni engine for on-policy distillation

[hjshi84]

What does this PR do?

Add VeOmni strategy support to the distillation and separation worker components so that VeOmniEngine can be used as a training backend in on-policy distillation (OPD) scenarios.

Design & Code Changes

1. verl/trainer/distillation/losses.py: Match 'veomni' alongside 'fsdp' in compute_topk_loss() so VeOmni can reuse FSDP's topk forward KL loss implementation. VeOmni inherits from FSDP2 and shares the same loss computation logic.

2. verl/experimental/separation/engine_workers.py: Add 'veomni' to DetachActorWorker's save/restore strategy handlers (fsdp2 sharded save/load), enabling model offload in separation mode. Also pass **kwargs through __init__ to parent class for distillation_config compatibility.

3. examples/on_policy_distillation_trainer/run_qwen_gsm8k_veomni.sh: Add example script for testing OPD with VeOmni backend, following the model_engine=veomni configuration pattern with actor.veomni.* settings.

API and Usage Example

export DATA_PATH=/path/to/data
bash examples/on_policy_distillation_trainer/run_qwen_gsm8k_veomni.sh

Test

• Verified with GSM8K dataset using Qwen2.5-0.5B (student) and Qwen2.5-3B-Instruct (teacher) on 2+4 GPUs.

Checklist Before Starting

• Search for similar PRs: no existing PR adds veomni OPD support.
• PR title follows [veomni, trainer] feat: ... format.

Checklist Before Submitting

• Read the Contribute Guide.
• Apply pre-commit checks: pre-commit install && pre-commit run --all-files --show-diff-on-failure --color=always
• Add unit or end-to-end test(s) to cover the code. If not feasible, explain why: this is an integration-level feature requiring multi-GPU and the veomni external dependency; e2e testing covered by manual script validation.
• Add / Update the documentation.

[gemini-code-assist]

Code Review

This pull request introduces support for the veomni engine in on-policy distillation, including a new example script for GSM8K and updates to worker initialization and loss computation. Feedback suggests explicitly defining the distillation_config parameter in the DetachActorWorker constructor to prevent potential TypeError issues when arguments are passed positionally.

[wuxibin89]

We haven't support distillation in fully async training yet.

[hjshi84]

This change is not about enabling distillation in fully async training. It's a signature alignment fix — the parent class ActorRolloutRefWorker.init already accepts distillation_config and **kwargs, and ray_trainer.py already passes distillation_config when constructing the worker. The previous DetachActorWorker.init(self, config, role) silently dropped these arguments because its signature was narrower than the base class. This PR simply makes the subclass properly forward them to super().init.

[wuxibin89]

Got it, I think pass **kwargs should be enough?

[hjshi84]

yes, however gemini suggests explicitly defining the distillation_config parameter in the DetachActorWorker constructor to prevent potential TypeError issues when arguments are passed positionally TT

[wuxibin89]

Please format code: https://github.com/verl-project/verl/blob/main/CONTRIBUTING.md#code-linting-and-formatting