Repository navigation
[Discussion] Support background evaluation while fully-async training rollout is running #2339
Description
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
希望支持以下工作模式：
-
训练侧持续使用 fully-async rollout 生成训练数据；
-
训练过程不必等待 eval 完成；
-
eval 在后台独立执行；
-
eval 使用明确的模型权重版本；
-
支持两种权重选择方式：
- 评估最近一次已完成同步的训练权重；
- 评估用户指定的 checkpoint；
-
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
-
对 fully-async training，社区更推荐哪一种实现方式？
-
eval 是否应该默认使用最近一次已完成同步的权重？
-
是否需要支持显式指定 checkpoint，例如：
--eval-checkpoint /path/to/checkpoint
-
eval 使用独立 SGLang engine 是否是必要条件，还是可以和 training rollout engine 共享？
-
如果共享 engine，training rollout 和 eval 是否需要独立的并发额度？
-
eval 是否允许使用与训练不同的：
- sampling parameters；
- n_samples_per_prompt；
- reward function；
- prompt formatting；
- max response length？
-
eval 期间发生权重更新时，应该：
- 继续完成当前 eval，并将结果标记为旧 policy；
- 取消当前 eval；
- 排队等待下一个稳定权重？
-
eval 结果中至少需要记录哪些 metadata？
- training step；
- checkpoint path；
- policy version；
- rollout ID；
- eval dataset name；
- eval start/end timestamp。
-
eval 失败或超时时，是否只记录失败并继续训练，还是应该触发训练侧告警或停止？
-
是否需要支持多个 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.
Activity
[-][Question] Support background evaluation while fully-async training rollout is running[/-][+][Discussion] Support background evaluation while fully-async training rollout is running[/+]WenzheWang commentedon Sep 2, 2026
Thanks for laying out the alternatives and failure modes in detail. I would like to work on this, but given slime's contribution scope I suggest a deliberately narrow and independently verifiable first PR, subject to maintainer approval.
Proposed first-PR boundary
eval_function_pathcontracts instead of introducing another evaluation format.checkpoint,training/global stepwhen available, dataset name, job ID, start/end time, and terminal status to every result.This first PR would intentionally not include latest-synced/live-weight evaluation, sharing the training SGLang engine, multiple concurrent eval jobs, priority scheduling, cross-cluster services, or dashboard integration. In particular, it would not depend on or redefine the policy-version semantics under discussion in #2278/#2279. Latest-synced evaluation could be a follow-up once that lifecycle is stable.
Invariants
succeeded,failed, ortimed_out) and its result remains attributable to the resolved checkpoint.Validation plan
Before I start implementation, could maintainers confirm whether this explicit-checkpoint-only, dedicated-worker slice is within the repository's collaboration scope, and where you would prefer the job lifecycle to be owned (trainer/controller versus rollout manager)?
zhuyijie88 commentedon Sep 14, 2026
@zhuzilin @fzyzcjy