verl-project/verl

集中 SP 与 use_remove_padding 校验至 FSDP 引擎

值得快速合并。这是一个低风险、高收益的 bugfix，消除了 SFT 场景的校验盲区。关注点：需确认 SFT 相关文档和示例配置中是否已默认设置 use_remove_padding=True 以配合序列并行。

修复 Hydra seed:null 时 vLLM 初始化崩溃

该 PR 为一次精准的 bugfix，改动极小，逻辑清晰，建议快速合入。值得关注的点是在 Hydra 配置中显式 null 与配置键缺失的区别——前者在 `dict.get(key, default)` 时不会回退到默认值。后续类似场景可统一使用 `or` 或自定义 getter 避免此类问题。

升级 sglang 到 0.5.12 并适配代码

该 PR 核心目标（升级 sglang）合理，但 Dockerfile 中的版本参数存在明显错误，建议在合并前修复 CUDA 和 TransformerEngine 版本。agent_loop 的 prompt 长度控制和统一 padding 方法设计良好，值得独立审查。attention 后端默认值的变更谨慎且有明确版本判断，可减少新版本兼容问题。整体建议在修复 Dockerfile 版本后批准。

在 Ascend Dockerfile 中配置 triton-ascend 专用 pip 源

该 PR 是典型的 Docker 基础设施维护，变更简单、聚焦。建议：1) 确认构建 CI 已涵盖这些 Dockerfile；2) 后续优化可将 `export` 改为 `ENV` 以提升可维护性。整体值得快速合并。

修复 HYBRID 模式下 DP > 1 时 CUDA OOM

**建议精读**: 这是一个典型的“单行修复背后有深度 root cause 分析”的 PR。值得关注的点： 1. `engine.sleep()` 与 `collective_rpc("sleep")` 在 vLLM 分布式架构中的语义差异（DP 协调器 vs 仅 TP 工人）。 2. 通过消除间接层（collective_rpc）直接调用 actor 方法的重构技巧。 3. 死代码识别与清理的决策过程。 对于 reviewer，重点关注是否仍有其他路径（如非 HYBRID 模式）意外使用了 collective_rpc 进行 sleep/wake_up。

requirements-npu 添加 triton-ascend 依赖

该 PR 为简单的依赖修复，技术洞察价值低。可快速合入，无需精读。

支持Qwen3.5 Ulysses序列并行

**建议合并**，但有以下后续行动： 1. **确认 PyTorch 版本**：在项目文档或 CI 中明确最低 PyTorch 版本要求，确保 `DTensor.full_tensor()` 可用。 2. **考虑性能优化**：评估 `full_tensor()` 的通信开销，若成为瓶颈可考虑改用 `to_local()` 并在 FSDP 确保下张量已复制的场景下使用。 3. **补充测试**：建议至少添加一个简单的 CPU 测试用例，验证 `forward_with_torch_backend` 和 `forward_with_triton_backend` 在启用 Ulysses SP 时的行为。 4. **精读亮点**：该 PR 展示了如何在已有模型架构中为序列并行添加支持，模式可复用于其他模型，值得关注。

为VeOmni引擎添加MoE路由器重放支持

推荐阅读`verl/utils/veomni/router_replay.py`中的注释和设计决策（id键索引、R3掩码、回退机制）。对于专注于VeOmni或MoE训练的研究者，理解RR的工作原理有助于排查策略梯度偏差。PR中的测试设计也值得参考，特别是模拟recompute的测试。