veRL-SGLang Roadmap

[zhaochenyang20]

veRL SGLang Tracking Roadmap

我们开发方向非常多，相互之间可能有依赖，但是一定得有清晰的 docs 来 keep track，而且这些活的 delivery 都很急，每个项目不超过 5 个人开发，互相协作。

要记录什么

一定要杜绝耳口相传的弊病，不然我们就成大厂了。

• test-log 文档用来让人快速复现你已经有的结果，要求详细，假设有新的 member 加入开发，他能够参考你的 test-log 快速复现出你的开发进度么？ 因此，test-log 要事无巨细，这个 verl-sglang-install 是个很好的例子。
• dev-log 文档用来记录开发心路，自己开发的同时梳理下思路，自己怀疑有问题的地方也记下来，方便复盘与讨论。我高中的时候学到的一个道理，如果一个问题你自己都不能写清楚或者给人讲清楚，那你肯定是够不清楚的。 因为，为了我们 team 的长期发展，一定要养成记录 dev-log 的习惯，方便大家复盘相互学习。这里 server-based-dev-log 是个很好的例子。
• TODO：@ 到某个具体的人，清晰列清楚这个人在下次讨论之前所需要做的事情，越清晰越好，避免因为沟通不清晰带来误解。
• 写的时候，中英文打空格，英文单词（比如 name 这个单词）和中文之间有空格。

VLM RLHF

移动到这里： #111

Multi-turn rollout

我先移动走到这儿了 #113

Server-Based RL

• 参与者：chenxing, jin
• 协调者：chenyang
• dev-log 和 test-log 在一块儿

目前进度

• 已经完成了开发，提出了 PR；
• chenyang review dev-log，然后发布正式文档；

TODO

• 正式文档还需要浅浅修复下； @jhinpan @yitianlian
• review PR； @zhaochenyang20
• 现在在重构一些 Tom 老师和 Kaiyu 老师提出的问题: 要重新讨论一下 EngineBase 设计以及 Testing Scripts 的增加: @jhinpan @yitianlian

Partial Rollout

这个还在讨论阶段，在我看来是个学术和工程都很有意义的话题。我的计划是这样的：

• 原文解析 + 基本的功能讨论：@zhaochenyang20
• 约顾老师和湘君老师一起讨论这个 topic，这种破坏了 on-policy 性质的 rollout 在学术上一定会让每个人 excited； @zhaochenyang20

一些理解

• Rollout 的不平衡问题：多任务 RL 内生性的不平衡性；同类任务考虑到难度，也会有区别；
• 纯 dp 的情况下，rollout 是完全分割的，比如 100k prompt dp 8，每个是 100k / 8，prompt queue 目前不共享，简单的 routing 策略可以缓和；

目前的实现

1. 设置一个长度范围，如果一个 propmt 的结果在在当前范围内得到了 eos，就返回，并且在当前轮训练；
2. 进行超量 rollout，不等待每个 prompt 都完成推理：譬如这一轮只需要 128 个完整的 sample，但我拿了 512 个 sample 来推，有的 sample 相对较短就能结束，有的会 decode 相当长才能结束。但是，我启动 512 个 sample 开始 rollout，等到有 128 个完成了 decode 后，我直接直接拿去训。此时，还有 384 个没有完成 rollout。此时，推理引擎可以停下，把这些 sample 和已经推理了的部分 cache 下来，下一轮继续使用，或者在 policy 被训练的同时，拿着旧的 policy 继续 rollout 结束。
3. 前者可能导致一个 sample 最终的 rollout tracjectory 由 policy 的多个 stage 推理而来，比如 0～64k 是 t-2 步，64～96k 是 t-1 步，最后只有 96～end 是真正由当前步骤的 policy rollout 而来的。
4. 无论如何做，这都会带来不严格 on policy。如果完全 on policy，超长的 rollout 耗时非常恐怖；但是反过来，学术上尚未证明。

这里有一个相关工作，但是也没开源。

Resharding

• 参与者：yongan, junrong
• 协调者：chenyang

TODO

• update_weights_from_tensor函数需要提供Iterable实现形式 ，PR
• 完成 SGLang 在 veRL 上的多机推理，测试 FSDP-SGLang 的 resharding 阶段及推理的准确性（目前单机完成测试
• (急)需要支持weights和kv cache分阶段wakeup的功能
• 目前mcore的支持环境为2.6版本，为了尽快推进sglang测的对齐，希望提供一个torch2.6版本下的安装方法。 直接上2.6会报错，已经反馈。
• Resharding 构建相关 CI，保护对应的文件。链接
• 基于 mcore0.11 和 SGLang 进行 resharding，需要在支持多机推理后，scale 到 dpsk v3 上。链接

Documentation

#74 (comment)

MCore

#119

[jhinpan]

4. Server-based RL: 承兴和我遇到一个棘手通信问题，会最近跟Tom请教一下

• 实现路径构想：
  由于现在Verl中已经使用了VERLengine作为rollout engine，因此我们打算基于现有的verlengine实现之上包裹一层server服务以达到支持server based rl的目的，目前暂时只考虑单机上的实现。

• 进度：
  Repo: https://github.com/yitianlian/sglang-fork/tree/feature/verlengine_server

  1. 已经完成了基于Verlengine中的tokenizer manager起相对应的server的函数
  2. 已经有相关测试脚本测试基于verlengine的server功能是否正常。经过测试已经确保使用verl engine的update_weights_from_tensor可以同时更新engine和server的模型参数并且不会出现卡死的现象

• 问题汇总： https://docs.google.com/document/d/1dACB5CsUhzCD0BF93YSE4dKavgkPdDxzMkt1XyZotGk/edit?tab=t.0

• 目前换了新的实现方法已经解决了，能顺利将原本的VeRLengine进行Server-based化

• TODO：

• 目前在使用 Server 进行 rollout 时，观察到生成速度明显慢于直接使用 Engine 的情况，初步怀疑可能与网络通信或 Server 内部处理机制有关，有大概30s-70s的延迟，正在进一步定位性能瓶颈。

• 在Atlas上发现test verl server的测试文件在部分运行环境中会稳定的出现broken pipe的问题，目前正在排查

• 将server based rollout engine融合到目前的Multi-turn VeRL rollout去

• 将Server-based rollout engine与mem-saver和multi-nodes相兼容，需要merge或者rebase

[minleminzui]

2. VLM RLHF 进度

• [feat] Initial support for VLMs, add Qwen2.5VL GRPO example volcengine/verl#386 / [Fix] self.worker assignment in TpModelWorker and refactor references sgl-project/sglang#4788 两个 PR 不冲突，后者解决的是 verl sglang rollout 调用的一个 bug。
• 目前跑起来还需要对 verl sglang rollout 做一些修改，可以临时参考这个提交： Fix padding length for sglang rollout in veRL volcengine/verl#773
• To do : 剩下还需要解决一些训练中跑挂的问题，以及最后的训练效果对齐 vllm rollout

先别合入吧，等完整跑完了，在一个pr里统一改吧，统一合入吧，不然有点乱

目前我对sglang和verl做了一些修改，基本顺利跑完了，目前能顺利跑到49步

目前要跑起来，可以使用apply volcengine/verl#773 中的修改，以及volcengine/verl#787 run_qwen2_5_vl-7b.sh的修改

sglang可以用这里的sgl-project/sglang#4806

可以尝试跑一下

[yitianlian]

Server-based RL Update：
@jhinpan 提到的棘手的通信问题经过排查可能是因为同一个资源被多个线程同时占用导致的，因此我们之前的实现方式存在一些问题，和tom老师讨论过后打算换一种实现方式。

目前我进度是可以使用verlengine接口起server同时更新参数并且生成response，但是一方面我目前只实现了部分原始engine的功能，同时测试并不全面，后续还需要进一步开发。

[zhaochenyang20]

1. junrong：mem savor today，现在更新依赖，打包新的镜像，就今天晚上就可以了。
2. multi-turn：yuzhen 启动 sandbox，把 verl multi-turn 真的训练起来，然后看到 validation 结果。
3. multi-node：zobin + jin，在 H20 上搞起来？可以找 tom junrong 还有 hancheng。

[yitianlian]

Server-based RL Update：
和 @jhinpan 一起完成了最初版的server based rollout，测试结果显示应该完全兼容verlengine的功能，但目前只支持单机单server。
PR link：sgl-project/sglang#4848

[SwordFaith]

partial rollout 这事情我好奇下，有人给我说，如果 context length 不 aim 特别长，不一定有必要，这合理么？能不能根据 rollout 的 steps 调大 context length。这是个 valid problem，因为 turn 很少的时候，contex length 不用那么大，越到之后越大，理想上该调高一些，但是实际上我理解对于 serving engine 完全做不到，得重启 engine 吧？这有什么可能么？

完全可以在 request-level 调度（with async rollout）

[zhaochenyang20]

partial rollout 这事情我好奇下，有人给我说，如果 context length 不 aim 特别长，不一定有必要，这合理么？能不能根据 rollout 的 steps 调大 context length。这是个 valid problem，因为 turn 很少的时候，contex length 不用那么大，越到之后越大，理想上该调高一些，但是实际上我理解对于 serving engine 完全做不到，得重启 engine 吧？这有什么可能么？

完全可以在 request-level 调度（with async rollout）

比如说 episode 1 的时候，每个 request 的平均长度是 1000 tokens，到了 episode 10，每个 requests 平均 10000 tokens，这种情况下调度并不能解决 context length 一开始就设置不够的问题吧？

[GeLee-Q]

VLM RLHF 进度更新:
定位到 validate 阶段精度异常的原因：

• sglang rollout 对输入数据处理不完整
  • 在 verl/verl/workers/rollout/sglang_rollout/sglang_rollout.py 的 generate_sequences 函数中，发现对 VLM 的输入处理存在缺失，特别是 multi_modal_data 相关字段未进行正确处理。
  • 当前实现与参考实现 verl/verl/workers/rollout/vllm_rollout/vllm_rollout_spmd.py 中的 generate_sequences 逻辑存在不一致，这可能是导致精度异常的主要原因。

TODO：

• 完善 sglang generate_sequences，验证对齐后的精度表现

---

verl 仅使用 validate 功能参考：
修改 verl/verl/trainer/config/ppo_trainer.yaml，在 trainer 下添加

 val_before_train: True
 val_only: True

[SwordFaith]

目前在 multi-turn rollout with sandbox 场景下，会新增 async rollout, tool server , ray agent trainer(一期先不实现)。

分期实现规划

一期没有 agent trainer 时，在 turn 间暂时先支持：

1. assistant turn 声明 tool call/function call
2. 在 async rollout 内 parse 后调用 tool server 提供的 process_action/submit/do_tool_call 语义的 api
3. tool server 内根据提交的 tool type 和 param 组合成相应具体 sandbox/tool （e.g. sandboxfusion、milvus、faiss、swe-gym）等的请求串，并在完成请求后，返回 tool response 结果（可在 tool server 内实现 format 逻辑）
4. 返回后为在之前的 tool call assitant 轮次后拼入 tool response 轮次，并让 assistant 继续生成

• 在 session 开始时，实现 start_session/enter 语义接口，为 swe 等需要为每一条轨迹实现隔离的环境修改的场景提供扩展点
• 在 session 结束时，实现 compute_env_state_rewad 语义接口，在释放资源前计算当前任务完成情况（一期用 hotpotqa/gsm8k 等可先不实现），实现 terminate_session/exit 语义接口，用来释放当前 session 在 enter 时创建的专属资源

二期，ray agent trainer 加入后，可以实现 pick gen batch -> rollout -> calc reward & filter -> train batch -> update actor etc. 在 rayppotrainer 中用处理结束显式分开，变成 gen batch 随着 rollout & filter & reward 跑到某个量，停止切换进后边的 update model ，为完成的 inference 进 partial rollout 逻辑或直接 drop，把 request level 的状态管理提到 async rollout 外边

三期，可以加入 roleplay 显式模拟用户交互 & interact as tool call，并支持处理比较重环境验证和 with feedback 的 RL 场景

一期实现方式

1. 抽离单独的 ToolServer 类，提供如下方法：
   a. init(self, tools, tool_call_fns) ：初始化 tools list 为 https://docs.sglang.ai/backend/function_calling.html 格式（和 async rollout 共享），并额外增加每个 tool 添加一个可在初始化时注入的 tool_call_fn dict 用来扩展 create, call, calc_reward, release 4 种语义，tool_call_fns 可以考虑封装为一个 BaseTool class
   b. enter / create_session （这里没想好是不是要作为 context manager），因为是 session level 的，目前更偏向 create_session 这个命名方式，依次调用 tool_call_fns 中每个 tool 的 create 函数，没有则跳过
   c. exit / release_session 依次调用 tool_call_fns 中每个 tool 的 release 函数，没有则跳过
   d. call 根据 engine 返回的 tool_calls 字段（tool name + args）拼成调用串，调用对应工具的 call 函数
   e. calc_reward reward manager 可以访问 tool server 完成 env state 相关的 reward 计算，gsm8k 和 r1-searcher 不需要
2. 重构 AsyncRollout 逻辑，在 generate seq 时，接受当前任务的 tool server 类，将 tools 本身放到轮级调度，等之后上 partial rollout 再考虑 max token 导致 turn 不完整的情况，在 async rollout 过程中用 req_id trace tool server instance
3. loops 和 tasks 功能看起来可以被 tool server class 吸收，可以单独做个 tool_call_fn dir 提供不同任务的 tool 实现和注册机制（注册可以先不搞）

0402 update
doc: https://github.com/SwordFaith/verl-sglang-dev-log/blob/main/rlhf/verl/multi-turn/veRL-multiturn-rollout-RFC.md
dev branch: https://github.com/zyzshishui/veRL-multiturn-rollout/tree/feat/add_async_sglang_multi_turn_support

[SwordFaith]

partial rollout 这事情我好奇下，有人给我说，如果 context length 不 aim 特别长，不一定有必要，这合理么？能不能根据 rollout 的 steps 调大 context length。这是个 valid problem，因为 turn 很少的时候，contex length 不用那么大，越到之后越大，理想上该调高一些，但是实际上我理解对于 serving engine 完全做不到，得重启 engine 吧？这有什么可能么？

完全可以在 request-level 调度（with async rollout）

比如说 episode 1 的时候，每个 request 的平均长度是 1000 tokens，到了 episode 10，每个 requests 平均 10000 tokens，这种情况下调度并不能解决 context length 一开始就设置不够的问题吧？

我理解 context length 是模型推理时 set 的最大长，这里 partial 的收益只在前几步所有 req 都还比较短的时候有效，后边如果多数据集混训，还是会出现一些数据集一些数据短。partial rollout 主要解决的是等待长尾 req 结束，导致 gpu 利用不充分的问题，通过允许一部分 token offline 几步，保吞吐。这里逐渐调大 max tokens 可以避免长尾步数 offline 过多

[JustinTong0323]

VLM RLHF 进度更新: 定位到 validate 阶段精度异常的原因：

• sglang rollout 对输入数据处理不完整

  • 在 verl/verl/workers/rollout/sglang_rollout/sglang_rollout.py 的 generate_sequences 函数中，发现对 VLM 的输入处理存在缺失，特别是 multi_modal_data 相关字段未进行正确处理。
  • 当前实现与参考实现 verl/verl/workers/rollout/vllm_rollout/vllm_rollout_spmd.py 中的 generate_sequences 逻辑存在不一致，这可能是导致精度异常的主要原因。

TODO：

• 完善 sglang generate_sequences，验证对齐后的精度表现

verl 仅使用 validate 功能参考： 修改 verl/verl/trainer/config/ppo_trainer.yaml，在 trainer 下添加

 val_before_train: True
 val_only: True

VLM Update:

原来的问题是没有图像输入， 我按照参考添加了图像输入，并且debug了 sgl 的一些逻辑，draft pr如下：
sgl-project/sglang#4915
volcengine/verl#824

但是仍有 bug:

    return fn(*args, **kwargs)
  File "/root/.python/verl-sglang/lib/python3.10/site-packages/ray/_private/client_mode_hook.py", line 103, in wrapper
    return func(*args, **kwargs)
  File "/root/.python/verl-sglang/lib/python3.10/site-packages/ray/_private/worker.py", line 2782, in get
    values, debugger_breakpoint = worker.get_objects(object_refs, timeout=timeout)
  File "/root/.python/verl-sglang/lib/python3.10/site-packages/ray/_private/worker.py", line 929, in get_objects
    raise value.as_instanceof_cause()
ray.exceptions.RayTaskError(IndexError): ray::TaskRunner.run() (pid=3966683, ip=172.17.0.21, actor_id=f8014ad72791f032683952fe01000000, repr=<main_ppo.TaskRunner object at 0x7f9b1ce42d70>)
  File "/root/verl/verl/trainer/main_ppo.py", line 171, in run
    trainer.fit()
  File "/root/verl/verl/trainer/ppo/ray_trainer.py", line 780, in fit
    val_metrics = self._validate()
  File "/root/verl/verl/trainer/ppo/ray_trainer.py", line 533, in _validate
    test_output_gen_batch_padded = self.actor_rollout_wg.generate_sequences(test_gen_batch_padded)
  File "/root/verl/verl/single_controller/ray/base.py", line 42, in func
    output = ray.get(output)
ray.exceptions.RayTaskError(IndexError): concurrent.futures.process._RemoteTraceback: 
  File "/usr/lib/python3.10/concurrent/futures/process.py", line 211, in _sendback_result
    result_queue.put(_ResultItem(work_id, result=result,
  File "/usr/lib/python3.10/multiprocessing/queues.py", line 371, in put
    obj = _ForkingPickler.dumps(obj)
  File "/usr/lib/python3.10/multiprocessing/reduction.py", line 51, in dumps
    cls(buf, protocol).dump(obj)
  File "/root/sglang/python/sglang/srt/patch_torch.py", line 42, in _reduce_tensor_modified
    output_args = _modify_tuple(
  File "/root/sglang/python/sglang/srt/patch_torch.py", line 71, in _modify_tuple
    return *t[:index], modifier(t[index]), *t[index + 1 :]
IndexError: tuple index out of range
"""

The above exception was the direct cause of the following exception:

ray::WorkerDict.actor_rollout_generate_sequences() (pid=3973205, ip=172.17.0.21, actor_id=6b6fd931e20478b6d526392c01000000, repr=<verl.single_controller.ray.base.WorkerDict object at 0x7f968576cbb0>)
  File "/root/verl/verl/single_controller/ray/base.py", line 419, in func
    return getattr(self.worker_dict[key], name)(*args, **kwargs)
  File "/root/verl/verl/single_controller/base/decorator.py", line 404, in inner
    return func(*args, **kwargs)
  File "/root/verl/verl/workers/fsdp_workers.py", line 511, in generate_sequences
    output = self.rollout.generate_sequences(prompts=prompts)
  File "/root/.python/verl-sglang/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 116, in decorate_context
    return func(*args, **kwargs)
  File "/root/verl/verl/workers/rollout/sglang_rollout/sglang_rollout.py", line 269, in generate_sequences
    output = self.inference_engine.generate(
  File "/root/sglang/python/sglang/srt/entrypoints/verl_engine.py", line 74, in generate
    output = self._engine.generate(
  File "/root/sglang/python/sglang/srt/entrypoints/engine.py", line 188, in generate
    ret = loop.run_until_complete(generator.__anext__())
  File "uvloop/loop.pyx", line 1518, in uvloop.loop.Loop.run_until_complete
  File "/root/sglang/python/sglang/srt/managers/tokenizer_manager.py", line 368, in generate_request
    async for response in self._handle_batch_request(
  File "/root/sglang/python/sglang/srt/managers/tokenizer_manager.py", line 553, in _handle_batch_request
    tokenized_obj = await self._tokenize_one_request(tmp_obj)
  File "/root/sglang/python/sglang/srt/managers/tokenizer_manager.py", line 401, in _tokenize_one_request
    image_inputs: Dict = await self.mm_processor.process_mm_data_async(
  File "/root/sglang/python/sglang/srt/managers/multimodal_processors/qwen_vl.py", line 151, in process_mm_data_async
    ret = await self._process_single_image(
  File "/root/sglang/python/sglang/srt/managers/multimodal_processors/qwen_vl.py", line 58, in _process_single_image
    return await loop.run_in_executor(
IndexError: tuple index out of range

@minleminzui @GeLee-Q 可以帮忙看看吗？

[GeLee-Q]

目前进度

• 开发进度
  [VLM RLHF] Take Image input for verl vlm rollout sgl-project/sglang#4915
  feat: enhence sglang_rollout to handle image input volcengine/verl#824
  修改已经更新在上面的PR中。基于 sglang branch(JustinTong0323:txy/verl_vlm_rollout) 和 verl branch(JustinTong0323:txy/vlm_sgl_rollout) 都已经 merge main 了。(直接拉取这两个分支的代码即可
  跟着文档一步一步走可复现结果
  https://github.com/zhaochenyang20/Awesome-ML-SYS-Tutorial/blob/main/rlhf/verl/VLM/veRL-VLM.md

• 模型训练进度
  1.模型最终训练结果待验证

• 模型精度对齐进度
  1.目前 val 的最高结果在 step 0 比起 vllm 低（0.33 vs 0.40
  2. 对齐了 vllm/sglang 的输入（ids_list, image_list)， 暂时排除了输入（veRL 数据处理）的干扰
  3. 对比了 vllm/sglang validate 的输出 response_str & ground truth，低分回答的前十几个token可以对齐，但是最终的结果出错

TODO
@minleminzui @JustinTong0323

1. 完成全流程的训练
   • 目前在第二个 step 可能存在 OOM的问题，下一步需要调整超参来完成全流程的训练
2. validata的对齐，merge main 分支后，目前 validate的结果 0.33 -> 0.199
   • 单独抽出整个的validate 流程，进行精度对齐

[zhaochenyang20]

1. 抽离单独的 ToolServer 类，提供如下方法：
   a. init(self, tools, tool_call_fns) ：初始化 tools list 为 https://docs.sglang.ai/backend/function_calling.html 格式（和 async rollout 共享），并额外增加每个 tool 添加一个可在初始化时注入的 tool_call_fn dict 用来扩展 create, call, calc_reward, release 4 种语义
   b. enter / create_session （这里没想好是不是要作为 context manager），因为是 session level 的，目前更偏向 create_session 这个命名方式，依次调用 tool_call_fns 中每个 tool 的 create 函数，没有则跳过
   c. exit / release_session 依次调用 tool_call_fns 中每个 tool 的 release 函数，没有则跳过
   d. call 根据 engine 返回的 tool_calls 字段（tool name + args）拼成调用串，调用对应工具的 call 函数
   e. calc_reward reward manager 可以访问 tool server 完成 env state 相关的 reward 计算，gsm8k 和 r1-searcher 不需要
2. 重构 AsyncRollout 逻辑，在 generate seq 时，接受当前任务的 tool server 类，将 tools 本身放到轮级调度，等之后上 partial rollout 再考虑 max token 导致 turn 不完整的情况，在 async rollout 过程中用 req_id trace tool server instance
3. loops 和 tasks 功能看起来可以被 tool server class 吸收，可以单独做个 tool_call_fn dir 提供不同任务的 tool 实现和注册机制（注册可以先不搞）

@zyzshishui

[JustinTong0323]

VLM update:
基于 sglang branch(JustinTong0323:txy/verl_vlm_rollout) 和 verl branch(JustinTong0323:txy/vlm_sgl_rollout): Apply prs below
sgl-project/sglang#4915
volcengine/verl#824

TODO:

1. 对齐 validate 的结果(目前 val 的结果在 step 0 比起 vllm 略低（0.33 vs 0.40)
2. 在 sglang python/sglang/srt/managers/multimodal_processors/base_processor.py中需要注释掉 L142 的assert， 这个是 main 的问题.
3. 目前仍会报错，log 如下