[Discussion] Support background evaluation while fully-async training rollout is running

[zhuyijie88]

Your Question

目前 slime 已经支持常规 eval 数据集配置，例如：

• --eval-interval
• --eval-prompt-data
• eval.datasets
• 独立的 eval_function_path

但是，当前的 fully-async rollout 入口会显式拒绝 evaluation mode：

if evaluation:
raise ValueError("fully-async rollout doesn't support evaluation mode")

对应代码：

https://github.com/THUDM/slime/blob/main/slime/rollout/fully_async_rollout.py

因此，当使用 fully-async rollout 持续生成训练数据时，eval 仍然无法作为后台任务并行运行。

Goal

希望支持以下工作模式：

1. 训练侧持续使用 fully-async rollout 生成训练数据；

2. 训练过程不必等待 eval 完成；

3. eval 在后台独立执行；

4. eval 使用明确的模型权重版本；

5. 支持两种权重选择方式：

   • 评估最近一次已完成同步的训练权重；
   • 评估用户指定的 checkpoint；

6. eval 结果应与对应的训练 step、checkpoint 或 policy version 关联，避免结果归属不明确。

理想的数据流如下：

                  +----------------------+
                  |  Fully-async rollout |
                  |  continuous training  |
                  +----------+-----------+
                             |
                             v
                       Training buffer
                             |
                             v
                       Training process
                             |
                  weight sync / checkpoint
                             |
            +----------------+----------------+
            |                                 |
            v                                 v
    Latest synced weights             Explicit checkpoint
            |                                 |
            +---------------+-----------------+
                            v
                     Background eval
                            |
                            v
                  Metrics / samples / logs

Possible approaches

Option 1: Reuse the fully-async rollout worker

让现有 fully-async worker 同时处理 training rollout 和 eval rollout，通过任务类型或优先级区分。

优点：

• 复用现有异步调度和 SGLang 请求逻辑；
• 代码改动相对集中；
• 训练和 eval 可以共享部分 rollout 配置。

问题：

• eval 任务可能与训练任务竞争并发额度；
• eval 长尾请求可能影响训练 rollout 的持续供给；
• 不同权重版本的请求需要严格隔离；
• eval 数据集耗尽、失败和取消会增加 worker 状态复杂度。

Option 2: Add a dedicated background eval worker

保留 fully-async training worker，同时增加独立的 eval worker 或 eval queue。eval worker 可以使用独立的 SGLang engine，也可以在资源允许时复用 rollout
engine，但需要显式标记权重版本。

优点：

• training rollout 和 eval 的资源、队列、失败处理相互隔离；
• 更容易保证 eval 使用固定 checkpoint 或 policy version；
• eval 的吞吐和并发可以单独配置；
• 不会因为 eval 长尾阻塞训练数据生成。

问题：

• 需要增加 worker 生命周期和权重管理逻辑；
• 如果使用独立 engine，会增加 GPU 或服务资源；
• 需要定义 checkpoint 加载或权重同步协议。

这是我目前更倾向的方案，尤其适合长时间运行的 fully-async RL 训练。

Option 3: Use an external evaluation service

将 eval 数据集和 checkpoint 发送给独立的评测服务，slime 只负责提交任务并异步收集结果。

优点：

• 训练和 eval 完全解耦；
• 可以跨机器或跨 GPU 集群运行；
• 适合大规模、长期、定时评测。

问题：

• 需要额外的服务、任务存储和结果回传协议；
• 部署复杂度更高；
• 与 slime 当前本地 eval 配置的兼容性需要额外设计。

Questions for discussion

1. 对 fully-async training，社区更推荐哪一种实现方式？

2. eval 是否应该默认使用最近一次已完成同步的权重？

3. 是否需要支持显式指定 checkpoint，例如：

   --eval-checkpoint /path/to/checkpoint

4. eval 使用独立 SGLang engine 是否是必要条件，还是可以和 training rollout engine 共享？

5. 如果共享 engine，training rollout 和 eval 是否需要独立的并发额度？

6. eval 是否允许使用与训练不同的：

   • sampling parameters；
   • n_samples_per_prompt；
   • reward function；
   • prompt formatting；
   • max response length？

7. eval 期间发生权重更新时，应该：

   • 继续完成当前 eval，并将结果标记为旧 policy；
   • 取消当前 eval；
   • 排队等待下一个稳定权重？

8. eval 结果中至少需要记录哪些 metadata？

   • training step；
   • checkpoint path；
   • policy version；
   • rollout ID；
   • eval dataset name；
   • eval start/end timestamp。

9. eval 失败或超时时，是否只记录失败并继续训练，还是应该触发训练侧告警或停止？

10. 是否需要支持多个 eval 数据集并行运行，以及不同数据集的独立调度策略？

Suggested initial scope

为了控制第一版复杂度，可以先支持：

• fully-async training rollout；
• 一个独立的后台 eval worker；
• eval 使用最近一次已完成同步的权重；
• 支持用户指定 checkpoint 的离线/后台 eval；
• eval 任务不阻塞 training rollout；
• 结果绑定 checkpoint 和 policy_version；
• eval 并发数、超时和失败策略可配置；
• 暂不处理跨集群 eval 和复杂的动态优先级调度。

后续再考虑：

• eval worker 与 rollout worker 共享 engine；
• 多 checkpoint 并行评估；
• eval 队列优先级；
• 跨节点或外部 eval service；
• eval 结果自动写入训练监控和 dashboard。

Related work

• Fully-async rollout implementation:
  https://github.com/THUDM/slime/blob/main/slime/rollout/fully_async_rollout.py

• PR perf(agent): isolate prompt rendering from event loop #2328: tokenizer/event-loop isolation for agent adapters, not eval support:
  perf(agent): isolate prompt rendering from event loop #2328

• PR perf(rollout): reuse filtered prompt token ids #2309: prompt token ID reuse, covering normal train/eval paths but not fully-async eval:
  perf(rollout): reuse filtered prompt token ids #2309

• PR feat: add deterministic fully-async staleness control #2278: persistent fully-async queue discussion:
  feat: add deterministic fully-async staleness control #2278

• PR feat: track policy versions in fully async rollout #2279: fully-async policy-version lifecycle:
  feat: track policy versions in fully async rollout #2279

• Issue Asynchronous rollout timeout when using server (LLM-as-a-Judge) #1361: asynchronous rollout timeout discussion:
  Asynchronous rollout timeout when using server (LLM-as-a-Judge) #1361

• Issue Training sglang rollout timeout #1562: training SGLang rollout timeout:
  Training sglang rollout timeout #1562

欢迎大家讨论整体架构、权重版本语义、资源隔离方式，以及第一版应该支持的最小范围。

What I've Tried

• I tried the relative issue and code, but find no discussion.

Environment (if relevant)

• slime version:
• Python version:
• PyTorch version:
• CUDA/ROCm version:
• GPU type and count:
• OS:

Additional Context

No response

Pre-submission Checklist

• I have read the CONTRIBUTING.md and understand the collaboration scope.
• I have read the documentation and FAQ and my question is not answered there.
• I have searched for existing issues and my question has not been asked before.