Miles 将 Slime 的"研究级 RL 框架"升级为"Agentic-first 的企业级生产系统"，核心创新在于用 Session/TITO 解决多轮 tokenization 正确性，用全异步 + staleness 解决性能，用 R3 + True On-Policy 解决稳定性。
Miles 的技术特色总结如下：
| 特色 | 核心理念 | 实现 |
|---|---|---|
| Agentic-First | Agent 开发像写普通应用 | Session Server + TITO + agentic_tool_call |
| 正确性优先 | 消除所有训推不一致源 | R3 + FP8 统一 + True On-Policy + TIS/MIS |
| 性能极致 | GPU 永不空闲 | 全异步 + 投机解码 + 零拷贝 + 部分 rollout |
| 渐进式保证 | 从宽松到严格可选 | Staleness(宽) → TIS(中) → True On-Policy(严) |
| 工程纪律 | 静默错误 → 显式断言 | Chat template 验证 + 运行时 prefix 校验 |
| 插件化扩展 | 新模型零改核心代码 | miles_plugins/ + middleware_hub |
| Multi-Agent | 从轻量到生产级 | 内置示例 → MrlX 完整框架 |
下图可以看到Miles的工作：
Miles 的工作 = 利用Slime扩展点
+ 底层内核 / 精度改造 ◄─── 非扩展点
+ RDMA 权重同步基础设施 ◄─── 非扩展点
+ 训练后端深度改造 (FSDP/CP) ◄─── 非扩展点
+ Chat Template 正确性工程 ◄─── 非扩展点
+ 可观测性 / 调试系统 ◄─── 非扩展点
+ 20+ 场景示例生态 ◄─── 非扩展点
+ ......
注：在本文撰写时，朱小霖大神 已经发布了最新版本 slime v0.3.0: 面向 Agent 时代 ，因此，本文涉及的 slime 都是旧版本的表现，不代表 slime 的最新能力。
另：因为本文为从源码反推涉及，且编写仓促，所以肯定有错误，还请读者不吝指出，谢谢。
在传统 RLHF 中，模型根据一个 prompt 生成一段回答，reward model 对该回答打分，完成一轮训练。
而在 Agentic RL 场景下，Agent（LLM）在一个有状态的环境中通过多轮交互来完成任务——调用工具、搜索信息、执行代码、与外部 API 交互。模型需要从交互的最终结果（而非中间回答的评分）中学习。
以下数值不是精确值。
| 维度 | 传统 RLHF（单轮） | Agentic RL（多轮） |
|---|---|---|
| 交互轮次 | 1 轮 | 10-50+ 轮 |
| 序列长度 | <4K tokens | 8K-64K+ tokens |
| 单次 Rollout 时长 | <10s | 60-600s |
| Token 归属 | 全部归模型 | 混合：model token (loss_mask=1) + env token (loss_mask=0) |
| 环境依赖 | 无 | 强依赖外部环境（Docker/API/沙箱） |
| 失败模式 | 少 | 超时/环境崩溃/格式错误/上下文满/沙箱死亡 |
| Reward 来源 | 固定 Reward Model | 环境结果（test pass, task complete） |
| Credit Assignment | 短序列，信号直接 | 长序列，Reward 在末尾 |
| Off-policy 风险 | 低 | 高（生成慢，模型可能已更新多次） |
Agentic RL 的需要是：框架可以处理 推理编排、长程训练、外部环境和工程维护方式等功能，其核心难点具体举例如下：
| 难点 | 具体表现 | 影响 |
|---|---|---|
| 多轮状态管理 | 50 轮 × 200 token = 10K+ token 需要在 session server 中累积追踪 | 内存和 tokenization 一致性压力 |
| Token 混合属性 | env token（工具返回/用户输入）mask=0，model token mask=1；错标一个 = 梯度噪声 | 一个 token 错标 → 该样本梯度方向偏移 |
| Tokenization 一致性 | Jinja loop.last 导致 10% prefix 变化，首轮 tokenization 被后续轮覆盖 |
10% token 不一致 → 训练数据质量下降 |
| 训推不一致 (log prob) | 推理用 SGLang（FP8/int4），训练用 Megatron（BF16），log prob 不一致 | KL 估计失真 → 优势函数偏差 |
| MoE 路由翻转 | ~5-15% token 在训练和推理时路由到不同 expert；精度差异导致 expert 选择不同 → 梯度计算在错误 expert 上 | 前向 log prob 和反向梯度路径不一致 → 训练崩溃 |
| 长尾延迟 | 一个慢 Agent 会话阻塞整个 batch，GPU 利用率暴跌 | GPU 利用率断崖下降 |
| On-Policy 过期 | 120s 推理窗口内模型已更新 2-3 步，但 rollout 仍使用旧模型权重 | 重要性采样权重偏离 |
| Credit Assignment | 50 轮后 reward=1，不知道哪步贡献最大 | 策略梯度信号极稀疏 |
| 异构 Agent 协同 | 不同 agent 用不同模型、不同训练循环、消息队列通信 | 数据结构不统一、reward 非对称 |
| 规模可扩展性 | 1TB+ MoE 模型数十 GB 参数同步 | RDMA 带宽成为瓶颈 |
Miles fork 自 slime，继承其核心的 RL 流水线架构：
Miles 的系统架构如下：
Miles 由多个可独立启停的进程/服务组成，以下标准明各组件的职责边界：
| 组件 | 职责 | 何时需要 |
|---|---|---|
| SGLang Engine | 模型推理（ rollout 生成），每个实例管理一组 GPU | 始终需要（无推理则无 rollout） |
| SGLang Router (sglang_router) | Round-robin / cache-aware 推理请求路由 | 多 GPU 推理（默认搭配 SGLang engine） |
Miles Router (miles/router/) |
最少连接负载均衡 + 健康检查 + 故障隔离 + radix tree 缓存中间件 | 高级路由需求：--use-miles-router + --miles-router-middleware-paths |
| Session Server | 多轮会话管理 + TITO 增量 tokenization + OpenAI 格式代理 | Agentic RL（多轮交互）：--use-session-server |
| Megatron Actor | 分布式训练（前向/反向/optimizer step） | 始终需要（--train-backend megatron，默认） |
| FSDP Actor | 分布式训练（实验性后端） | --train-backend fsdp（小规模/非 MoE 模型） |
| Ray | 分布式进程编排、Placement Group、Actor 生命周期 | 始终需要（框架基础设施） |
| mooncake TransferEngine | RDMA 零拷贝权重传输 | P2P 模式（默认，--update-weight-transfer-mode p2p） |
miles 的 6 步完整流程如下：
路径：
JSONL 文件 → Dataset 加载 → tokenizer/processor 预处理
→ RolloutDataSource.get_samples(batch_size)
→ 每个 prompt 复制 n_samples_per_prompt 份 → list[list[Sample]]
每个 Sample 的初始字段：— prompt, tokens, response, response_length, loss_mask, rollout_log_probs, rollout_routed_experts, reward, status, metadata 等。
路径：
Sample → generate(Sample)
→ OpenAIEndpointTracer.create() → POST /sessions → session_id
→ custom_agent_function(base_url, prompt, kwargs, metadata)
→ Agent 内部多次 POST /sessions/{id}/v1/chat/completions
→ Session Server 代理到 SGLang Router → SGLang Engine 推理
→ collect_records() → GET /sessions/{id}
→ compute_samples_from_openai_records() → TITO trailing token trim
→ list[Sample] (每轮一个)
→ merge_samples() / 保持多轮
路径：_convert_samples_to_train_data()
Sample[] → {
"tokens": [...], # prompt + response 完整 token
"response_lengths": [...], # 每样本 response 长度
"rewards": [...], # 归一化后的奖励
"raw_reward": [...], # 原始奖励
"loss_masks": [...], # 每 token 是否参与 loss
"truncated": [...], # 是否被截断
"rollout_log_probs": [...], # SGLang 推理时的 log prob（用于 TIS）
"rollout_routed_experts": [...], # R3 路由数据
"weight_versions": [...], # 推理时的权重版本（用于 staleness 检测）
}
路径：train_actor()
rollout_data → get_data_iterator() → micro-batches
→ [if R3] _fill_replay_data() → 解析 routed_experts 到 Replay 对象
→ [if KL] _switch_model("ref") → compute_log_prob(ref_log_probs)
→ _switch_model("actor") → compute_log_prob(log_probs)
→ compute_advantages_and_returns() → GRPO/PPO/REINFORCE++
→ train() → Megatron 前向 + 反向 + optimizer step
优势函数计算的核心逻辑见，支持 6 种优势估计器：
| 估计器 | 机制 |
|---|---|
| GRPO | 组内 reward 减去均值 + 可选 std 归一化 |
| GSPO | 组内 reward 归一化 + 序列级 KL 约束 |
| PPO | GAE + value function clipping |
| REINFORCE++ | 逐 token 折扣累积 reward |
| REINFORCE++ Baseline | 同上 + baseline 减方差 |
| On-Policy Distillation | teacher - student log prob 差 |
路径：[actor.py] → [mixin.py] → [p2p.py]
Megatron GPU params
→ TP all_gather (收集 tensor parallel 分片)
→ EP all_gather (收集 expert parallel 分片)
→ Megatron→HF 格式转换
→ ParameterMapper.map() (HF name → SGLang name)
→ load_weights() → shared CPU buffer
→ mooncake RDMA write → SGLang GPU memory
→ post_load_weights() (FP8 重量化)
→ weight_version++
路径：[train_async.py]
rollout_data_next = generate(rollout_id + 1) ← 提前启动
rollout_data_curr = await rollout_data_next ← 等待本次
train(rollout_id, rollout_data_curr) ← 训练与下次 rollout 重叠
在 Slime 基础上，Miles 将 Slime 的 "支持 Agentic"升级为 "Agentic-first"，提供开箱即用的 Agent 训练工具链。
| 维度 | Slime | Miles (fork) |
|---|---|---|
| 设计初衷 | 通用 LLM RL 后训练框架 | 企业级大规模 Agentic RL |
| Agentic 支持 | 通过异步解耦架构支持 | 继承 + 增强 (多智能体 MrlX) |
| 核心用户 | GLM 系列模型训练 | 更广泛的企业场景 |
Slime 是 "分布式 RL/LLM 训练底座" - 负责把 Ray + Megatron + SGLang 组织成可训练、可 rollout、可评估的闭环系统。Slime 的核心职责不是定义具体 agent 玩法，而是提供：
train.py, train_async.py): rollout -> train -> save -> eval -> update weights--xxx-path 动态导入接口)Slime 不负责：复杂 agent/session/tool/多轮语义、训推精确一致性治理、多后端。
在 train.py 里，Slime 负责完整训练编排：
分配 GPU -> 启动 rollout manager -> 创建 actor/critic -> 每轮：generate rollout -> train -> save -> eval -> update rollout weights
在 rollout 层面：
在训练后端：
Slime 明确把以下内容(举例)设计成可插拔，这样开发者可以定制：
| 类别 | 扩展点 | 机制 |
|---|---|---|
| Rollout | --rollout-function-path / --custom-generate-function-path / --eval-function-path |
import path |
| 数据 | --data-source-path / --buffer-filter-path |
import path |
| 过滤 | --dynamic-sampling-filter-path / --rollout-sample-filter-path |
import path |
| Reward | --custom-rm-path / --custom-reward-post-process-path |
import path |
| Loss | --custom-loss-function-path / --custom-tis-function-path / --custom-pg-loss-reducer-function-path |
import path |
| 训练 | --custom-convert-samples-to-train-data-path / --custom-advantage-function-path |
import path |
| Megatron Hooks | --custom-megatron-init-path / before-log-prob-hook / before-train-step-hook |
import path |
| 模型 | args.spec / @register_model / @MegatronModelBridge.register_bridge |
import + 注册 |
| 日志 | --custom-rollout-log-function-path / --custom-eval-rollout-log-function-path |
import path |
| ABC | DataSource / TrainRayActor / HfWeightIteratorBase / HuggingfaceAttention |
继承 |
Miles 将 Slime 的"研究级 RL 框架"升级为"Agentic-first 的企业级生产系统"，核心创新在于用 Session/TITO 解决多轮 tokenization 正确性，用全异步 + staleness 解决性能，用 R3 + True On-Policy（当前支持 dense 模型）解决稳定性。
虽然 Slime 提供了扩展点，但是 Miles 并没有简单的利用扩展点，而是“利用扩展点 + 新增架构层 + 深度改造核心” 三者并行。具体可以分为三层：
Slime 做 "能跑起来"，Miles 做 "跑得正确 + 跑得快 + 跑复杂场景"。因此，两者分工边界如下：
| 维度 | Slime 负责 | Miles 负责 |
|---|---|---|
| 训练主循环 | 基本闭环 (同步/异步骨架) | 异步化增强 / AsyncRolloutWorker / Staleness |
| Ray 编排 | PG / Actor Group / Rollout Manager | 在上面加 runtime 语义，不改编排层 |
| Rollout | 单次 generate + eval + 基础 router | Session 多轮 + tool call + agent loop + 统一编排 |
| 训练后端 | Megatron only | Megatron 增强 + FSDP + 跨后端公共抽象 |
| 权重同步 | 基础 HTTP 传输 | broadcast + P2P RDMA + 多并行布局 |
| MoE 支持 | 基础 | + R3 路由重放, 解决训推不一致 |
| 算法一致性 | 无系统治理 | 频谱：Staleness -> TIS -> R3 -> True On-Policy |
| Token 正确性 | 无验证 | TITO + template 验证 + append-only 校验 |
| 可观测性 | 基础 logging | 4 后端 Tracking + debug dump + profiling |
| 模型生态 | GLM 为主的支持 | 10+ 模型族 bridge + megatron_bridge patch |
下表为Miles工作全景，对于主要工作领域进行分类，看看属于三层中哪一层。其中：
--xxx-path 接口注入实现| 工作领域 | Layer A. 利用扩展点 | Layer B. 新增架构层 | Layer C. 深度改造/修改核心 |
|---|---|---|---|
| ① Rollout 生成 | agentic_tool_call/multi_turn/single_turn |
generate_utils/ (token对齐/loss_mask/prefill log prob) |
inference_rollout/ 重构调度架构 |
| ② Session & 多轮 | - | Session Server / Linear Trajectory / TITO / Template 验证 / --custom-agent-function-path |
- |
| ③ Reward 体系 | 8+ 内置 RM | rm_hub/ 异步框架 |
- |
| ④ 样本过滤 | check_reward_nonzero_std / check_no_aborted |
filter_hub/ 协议抽象 |
- |
| ⑤ 数据源 | RolloutDataSourceWithBuffer |
- | 默认数据源切换 |
| ⑥ 训练 Loss | 保留 loss/tis 扩展点 | training_utils/loss.py 跨后端公共层 |
Loss 重构 (TIS/OPD/true-on-policy/CP) |
| ⑦ 训练一致性 | - | True On-Policy 契约 / FP8 统一内核 | 训练侧可直接用 rollout log prob |
| ⑧ MoE 路由 | - | - | R3 路由重放注入 MoE 层 |
| ⑨ 权重同步 | - | P2P RDMA 零拷贝 | 多并行布局支持 + broadcast 增强 |
| ⑩ Router & 中间件 | - | Miles Router / RadixTree 中间件 | - |
| ⑪ 训练后端 | args.spec 保留 |
FSDB 后端 / training_utils/ 抽象 |
Megatron actor 增强 (LoRA/CP/P2P/debug) |
| ⑫ SGLang 集成 | - | sglang_utils/ 引擎管理 |
rollout 启动改造 |
| ⑬ 模型插件 | 10+ 模型 bridge | megatron_bridge/ Core patch |
bridge 加载路径切换 |
| ⑭ 可观测性 | 保留 log 扩展点 | Tracking 4 后端 / Debug Engine | Tracking 生命周期改造 |
| ⑮ 训练主循环 | - | - | 全异步 / Staleness 过滤 / AsyncRolloutWorker |
| ⑯ 参数系统 | - | 200+ 新参数 / 插件自注册 args | 删除 advantage hook; 默认值调整 |
具体统计
| 改造方式 | 涉及领域数 | 工作量占比 |
|---|---|---|
| A. 利用扩展点（Layer A） | 5 | ~15% |
| B. 新增架构层（Layer B） | 12 | ~45% |
| C. 修改核心（Layer C） | 10 | ~40% |
说明：以下统计仅覆盖
--xxx-path类 import-path 扩展点。若把args.spec、@register_modelbridge 注册等机制也算入，Miles 利用的扩展接口更多。
| Slime 扩展点 | Miles 注入的实现 | 目的 |
|---|---|---|
--custom-generate-function-path |
agentic_tool_call:generate, multi_turn:generate, single_turn:generate |
Agent/多轮/单轮生成 |
--rollout-function-path |
InferenceRolloutFn |
统一 rollout 编排架构 |
--dynamic-sampling-filter-path |
check_reward_nonzero_std, check_no_aborted |
训练质量守门 |
--data-source-path |
RolloutDataSourceWithBuffer |
支持样本回收重生成 |
--custom-rm-path (框架) |
rm_hub/ 8+ 种 RM 类型 |
开箱即用 reward |
这些接口在 Miles 中仍然可用，留给最终用户（不完全列举，仅统计本文关注的主要 hook）：
--custom-loss-function-path--custom-tis-function-path--custom-pg-loss-reducer-function-path--custom-reward-post-process-path--custom-convert-samples-to-train-data-path--custom-model-provider-path--custom-megatron-init-path--custom-megatron-before-log-prob-hook-path--custom-megatron-before-train-step-hook-path--custom-rollout-log-function-path--custom-eval-rollout-log-function-path--buffer-filter-path--rollout-data-postprocess-path--rollout-sample-filter-path--rollout-all-samples-process-path--eval-function-pathargs.spec@register_model (用户可扩展更多模型)@MegatronModelBridge.register_bridge| 扩展点 | 原因 |
|---|---|
--custom-advantage-function-path |
Miles 直接内置 advantage 计算，不再暴露 |
Miles 不只 "使用 "Slime 的扩展点，还创造了新的扩展点（以下是例子）：
| Miles 新增扩展点 | 定义位置 | 说明 |
|---|---|---|
--custom-agent-function-path |
miles/utils/arguments.py |
Agentic RL 的 Agent 函数接口 |
--use-session-server + TITO 参数族 |
miles/utils/arguments.py:1660-1697 |
Session Server + TITO 整套基础设施 |
--miles-router-middleware-paths |
miles/utils/arguments.py:1128-1160 |
Router 中间件插件系统 |
| Plugin 可自注册 CLI args | miles/utils/arguments.py:1699-1714 |
Generate 插件可通过 fn.add_arguments(parser) 添加自己的参数 |
| Class-based rollout 合约 | miles/rollout/inference_rollout/compatibility.py |
从纯函数升级为类 |
| 模块 | 说明 |
|---|---|
| miles/router/ | R3 路由重放系统 - 自定义路由代理、健康检查、Worker 隔离、中间件加载 |
| miles/utils/fp8_kernel.py | 统一 FP8 Triton cast 内核 |
| miles/true_on_policy/ | True On-Policy 训练契约系统 (config、schema、contracts、model_profiles) |
| miles/backends/experimental/fsdp_utils/ | 实验性 FSDP 路径, 含 MoE helpers 和 Qwen3-MoE 支持 |
| miles/backends/megatron_utils/kernels/int4_qat/ | INT4 QAT CUDA 内核 |
| miles_plugins/ 全部 | 插件层 - mbridge (DeepSeek V3.2, GLM4 等模型桥接)、megatron_bridge、models 适配器 |
| miles/rollout/sleep_rollout.py | Sleep/vLLM 模式 rollout |
| docs/developer/migration.md | 从 slime 迁移到 Miles 的指南 |
rollout/session/ |
Session Server + TITO 增量 tokenization |
rollout/generate_hub/agentic_tool_call.py |
Agentic RL 生成框架 |
true_on_policy/config.py |
Kernel policy 生成器 |
| P2P 权重传输子模块 | mooncake RDMA 零拷贝同步 |
| 模块 | 改动内容 |
|---|---|
train.py + train_async.py |
从同步循环升级为同步/异步双模式 |
megatron_utils/ |
大量新增：R3 replay、P2P 权重同步、megatron_to_hf 模型扩展、colocate 内存管理 |
sglang_utils/ |
SGLang 引擎封装层：FP8 pipeline、PD 分离、多模型配置、外部引擎支持 |
| Chat Template 工具链 | TITO tokenizer + TokenSeqComparator + 固定 Jinja 模板系统 |
Slime = "能跑起来" - 提供训练底座 + 25 个扩展点。
Miles = "跑得正确 + 跑得快 + 跑复杂场景"。
Miles的工作以B（新增）+C（改核心）为主，纯利用扩展点的工作只是冰山一角。真正的价值在于Slime完全没预见的“会话化正确性“和“训推致性治理“等新架构层，是对计算核心、传输层、正确性保障、可观测性做了全面的工程建设。---- 具体体现为：
--xxx-path 接口 + bridge 注册)Miles 的价值不在于 "在扩展点上插实现"，而在于解决 Slime 最初设计时 **根本没预见的三类问题 **：
上面的角度是从如何改造 Slime 的思路来看，我们下面看看从解决问题角度来看，或者说从业务逻辑角度来看看如何对Miles进行分层。
Miles 对于问题域的解法如下。
| 问题域 | 核心痛点 | Miles 的解法 | 主要改造方式 |
|---|---|---|---|
| 正确性 | 多轮 token 漂移、MoE 路由翻转、训推 log prob 偏差 | TITO + Template 验证 + R3 + True On-Policy + FP8 统一 | B+C |
| Agent 开发体验 | 每个 Agent 重写 boilerplate | Session Server + agentic_tool_call + custom-agent-path | A+B |
| 性能 | GPU 空闲率高、权重同步慢、前缀重复计算 | 全异步 + P2P RDMA + RadixTree 缓存 | B+C |
| 算法能力 | 需要 GRPO/TIS/OPD/多后端/多模型 | Loss 重构 + FSDP 后端 + 10+ bridge | A+B+C |
| 生产可靠性 | 样本质量、worker 故障、训练诊断 | Filter + Router 健康检查 + Tracking + Debug | A+B |
| 规模扩展 | 1TB+ MoE、千卡、多并行 | P2P + CP + 多布局权重同步 + megatron_bridge | B+C |
以上问题域的解法可以分为如下 L1 ~ L5 这 5 层。
═══════════════════════════ Miles 增强层 ══════════════════════
──────────────────────────────────────────────────────────────
L5: Agent/Session/Tool 语义层
Session Server / TITO / agentic_tool_call / Agent Hook
──────────────────────────────────────────────────────────────
L4: 训推一致性治理层
True On-Policy 契约 / R3 路由重放 / TIS / FP8 统一内核
──────────────────────────────────────────────────────────────
L3: 训练后端扩展层
Megatron 增强 (LoRA/CP/replay) / FSDP / training_utils 抽象
──────────────────────────────────────────────────────────────
L2: Router/Session/Middleware 基础设施层
Miles Router / RadixTree / SGLang 引擎管理
──────────────────────────────────────────────────────────────
L1: RM/Filter/Tracking/Debug/Plugin 生态层
8+ RM / Dynamic Filter / 4 后端 Tracking / 10+ 模型 bridge
═══════════════════════════ Slime 底座 ═══════════════════════
──────────────────────────────────────────────────────────────
训练主循环 | Ray 编排 | Megatron 后端 | SGLang rollout | 扩展点体系
这 5 层具体信息如下：
| 层级 | 定位 | 归属的 Jobs |
|---|---|---|
| L5 Agent/Session/Tool 语义层 | 多轮 Agent 语义、工具调用、对话管理 | ① Session & 多轮、② Rollout 生成（agentic_tool_call/multi_turn 部分） |
| L4 True-on-policy 一致性治理层 | 训推 log prob 对齐 | ③ 训推一致性、④ MoE 路由 (R3) |
| L3 训练后端扩展层 | Megatron/FSDP/Loss/训练主循环 | ⑤ 训练 Loss、⑥ 训练后端、⑧训练主循环、⑦模型插件、⑨ SGLang 集成 |
| L2 Router/Session/Middleware 服务层 | 通信、路由、权重同步、基础设施 | ⑩Router & 中间件、⑪ 权重同步、⑫ 数据源、⑬ 参数系统 |
| L1 RM/Filter/Tracking/Debug/Plugin 生态层 | 奖励、过滤、监控、调试、插件 | ⑭ Reward 体系、⑮ 样本过滤、⑯可观测性 |
L5 Agent/Session/Tool 语义层
├─ Job① Session & 多轮 (Session Server, TITO, LinearTrajectory)
├─ Job② Rollout 生成 (agentic_tool_call, multi_turn, single_turn)
└─ (chat template autofix 也属此层)
L4 True-on-policy 一致性治理层
├─ Job③ 训推一致性 (契约系统, FP8统一, logprob直用)
└─ Job④ MoE 路由 (R3 路由重放)
L3 训练后端扩展层
├─ Job⑤ 训练 Loss (GRPO/PPO/TIS/OPD 跨后端公共层)
├─ Job⑥ 训练后端 (FSDP + training_utils 抽象)
├─ Job⑦ 训练主循环 (全异步/staleness/AsyncRolloutWorker)
├─ Job⑧ 模型插件 (10+ bridge + NemotronH patch)
└─ Job⑨ SGLang 集成 (sglang_utils + 启动改造)
L2 Router/Session/Middleware 服务层 / 基础设施层
├─ Job⑩ Router & 中间件 (Miles Router + RadixTree)
├─ Job⑪ 权重同步 (P2P RDMA + 多并行布局)
├─ Job⑫ 数据源 (RolloutDataSourceWithBuffer)
└─ Job⑬ 参数系统 (200+ 新参数 + 插件自注册)
L1 RM/Filter/Tracking/Debug/Plugin 生态层
├─ Job⑭ Reward 体系 (8+ RM + rm_hub 异步框架)
├─ Job⑮ 样本过滤 (filter_hub + 内置规则)
└─ Job⑯ 可观测性 (4 后端 Tracking + Debug 工具)
| 层 | Jobs 数量 | 改造比重 | 核心价值 |
|---|---|---|---|
| L5 语义层 | 2 | ***** | 差异化核心：Agentic 多轮能力 |
| L4 一致性层 | 2 | **** | 技术护城河：训推对齐 |
| L3 训练后端层 | 5 | ***** | 基础能力：异步+大规模训练 |
| L2 服务/基础设施层 | 4 | *** | 生产就绪：路由+同步+配置 |
| L1 生态层 | 3 | *** | 开箱即用：RM+过滤+监控 |
注: Job② "Rollout 生成" 跨越两层 — generate_utils (token 对齐、loss_mask) 属基础设施层, 而 agentic_tool_call/multi_turn 属语义层。
Miles工作全景：领域×改造方式×解决的问题
主要是：Session Server / TITO / agentic_tool_call / Agent Hook
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| B | Session Server (FastAPI) | 状态持久化 - 多轮 Agent 对话历史跨请求保持；提供 OpenAI 风格 chat/completions 接口 (session scoped: /v1/sessions/{id}/v1/chat/completions) |
| B | LinearTrajectory | 可回滚的轨迹管理 - Agent 产出有误时单步回退而非丢弃整条轨迹 |
| B | TITO Tokenizer | 多轮 token 前缀不变性 - 每追加一轮之前 token 不变，否则 logprob/loss_mask 全错 |
| B | Chat Template 验证+autofix | 静默 bug 预防 - 社区模板 loop.last/loop.index 破坏前缀一致性 |
| B | --custom-agent-function-path |
Agent 逻辑解耦 - 业务代码与训练框架彻底分离 |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| A | agentic_tool_call / multi_turn / single_turn |
降低 Agent 开发门槛 - 用户只写 agent 函数，无需处理 tokenization/session/sample 转换 |
| B | generate_utils/ (token 对齐、loss_mask 构建、prefill logprob) |
消除 token 错位 - stop token 与下一轮模板渲染重复时自动 trim 对齐 |
| C | inference_rollout/ 重构调度架构 |
统一 rollout 编排 - 训练/评测/中断/过滤/RM 调用重构为统一 pipeline |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| B | True On-Policy 契约系统 | 在受支持配置下对齐 log prob - 通过契约+deterministic 设置让两侧计算路径尽量 bit-exact (当前覆盖 qwen3 dense 契约) |
| B | FP8 统一内核 | 精度源对齐 - 两侧各用各的 FP8 cast -> 数值不一致 -> 统一 kernel |
| C | 训练侧可直接用 rollout logprob | 跳过重算 - 契约保证一致后无需浪费算力重算 |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| C | R3 路由重放 | MoE 梯度正确性 - 推理选 Expert{2,7} 训练选 Expert{2,8} -> 梯度在错误 expert 上。存储开销：bytes ≈ (tokens-1) × num_layers × topk × 4 (dtype=int32)，以 32K token × 60 layers × top8 为例约 60MB/样本 |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| B | training_utils/loss.py 跨后端公共层 |
避免重复实现 - GRPO/PPO/TIS/OPD 不应在 Megatron 和 FSDP 各写一遍 |
| C | Loss 大幅重构 | 支持新算法 - true-on-policy logprob 直用、OPD 蒸馏、CP 下 token 对齐 |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| B | FSDP 实验后端 | 多后端选择 - 小模型不需要 Megatron 复杂性 |
| B | training_utils/ 抽象 |
代码复用 - data/parallel/cp/log 在后端间共享 |
| C | Megatron actor 增强 | 高级训练 - LoRA/CP 超长序列/debug/多模型切换 |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| C | 全异步模式 | GPU 利用率 - 同步等 Agent 60-120s -> GPU 空闲 >90%; 异步后 wall_time ≈ max(rollout, train) |
| C | Staleness 过滤 | 训练质量 - 异步下旧样本 importance ratio 偏离 -> 丢弃重生成 |
| C | AsyncRolloutWorker | 持续供给 - 独立线程+有界队列+背压 |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| A | 10+ 模型 bridge | 广泛模型支持 - 每个模型权重命名/MoE/MTP 结构不同 |
| B | megatron_bridge/ Core patch |
特殊架构 - NemotronH (Mamba+MoE) 需 patch Megatron Core |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| B | sglang_utils/ |
引擎管理标准化 - 参数约束统一管理避免配置错误 |
| C | rollout 启动改造 | 支持新特性 - True On-Policy 需要特殊启动参数 |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| B | Miles Router | 生产级服务 - worker 故障自动隔离、最小并发路由、健康检查 |
| B | RadixTree 中间件 | 推理效率 - 多轮交互前缀重复，缓存后只推理增量 |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| B | P2P RDMA 零拷贝 (Mooncake TransferEngine) | 同步速度 - 1TB+ 模型 HTTP 太慢，RDMA 直写 GPU 显存 |
| C | 多并行布局支持 | 大规模部署 - TP/PP/CP 下权重分片需正确收集+分发 |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| A | RolloutDataSourceWithBuffer |
支持 buffer 回收 - staleness 过滤后样本需回收重生成 |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| B | 200+ 新参数 | 能力可配置 - 新功能都需要参数控制 |
| B | 插件自注册 CLI args | 可扩展性 - generate 插件声明自己的参数 |
| C | 删除 custom-advantage-function-path |
简化接口 - 内置即可，不再暴露 |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| A | 8+ 内置 RM (math/dapo/f1/gpqa/remote...) | 开箱即用 - 常见场景无需自己写 reward 函数 |
| B | rm_hub/ 异步框架 |
高吞吐 reward - batch 化异步 RM，避免串行成为瓶颈 |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| A | check_reward_nonzero_std / check_no_aborted |
防止无效训练 - 全对/全错组对 GRPO 无信号；ABORTED 组有噪声 |
| B | filter_hub/ 协议抽象 |
过滤可插拔 - 不同任务不同逻辑，统一接口 |
| 改造方式 | 具体工作 | 解决的问题 |
|---|---|---|
| B | 4 后端 Tracking (WandB/TensorBoard/MLflow/Prometheus) | 统一监控 - 不同团队用不同工具，统一扇出 |
| B | Debug 工具 | 快速诊断 - dump rollout/replay reward/直接发 SGLang 请求 |
我们把miles和Uni-Agent进行对比。
| 维度 | Miles（基于 Slime） | Uni-Agent（基于 verl） |
|---|---|---|
| 底座框架 | Slime (Megatron + SGLang) | verl (FSDP/Megatron + vLLM/SGLang) |
| 环境管理 | 不管理，推给外部（Harbor/HTTP/ 用户代码） | 框架内管理（AgentEnv 生命周期：start()/run_action()/close()） |
| Agent Loop | 用户完全自定义（async def my_agent） |
verl 提供 AgentLoopBase 抽象类，Uni-Agent 实现 UniAgentLoop |
| Token 对齐 | TITO（精确，预计算 + 验证，bit-exact） | 启发式 boundary_tokens 推断 + rollout_cache 增量追加（best-effort） |
| Session 实现 | 独立 FastAPI 服务（Session Server） | 进程内 rollout_cache（token/trajectory cache） + AgentEnv 保持环境状态 |
| MoE 支持 | 核心目标（R3 路由重放 + FP8 统一 + TIS） | 支持 MoE 训练（Expert Parallel），但无路由重放机制 |
| 配置层次 | 命令行参数（argparse，单层） | 训练层 Hydra + Agent 层 YAML 文件 + 样本层 tools_kwargs runtime override |
| 机制 | Miles 方案 | Uni-Agent 方案 | 权衡 |
|---|---|---|---|
| 增量 Tokenization | TITO：全量预计算 → 运行时 prefix 校验 + autofix | rollout_cache 增量追加 + 基于 chat template 的 boundary_tokens 启发式推断 |
Miles 更精确但模板需适配；Uni-Agent 更通用但 best-effort |
| 训推一致性 | 多级保证：Staleness>TIS>R3>True On-Policy；部分 recipe 用极小 clip_ratio（如 4e-4），另一些用标准值（0.2/0.28）；配合 staleness_threshold |
Miles 解决根因；Uni-Agent 按场景选择保守或激进 | |
| 并发控制 | Semaphore（512×GPU） + FIRST_COMPLETED 调度 |
worker_concurrent = max(global_concurrent // num_workers, 1) + asyncio.Semaphore 类似思路 |
Miles 更细粒度 |
| 异常处理 | 3 个训练相关主态（COMPLETED/TRUNCATED/ABORTED） + 2 个扩展态（PENDING/FAILED） + filter | ~11 种 exit_reason（token_limit/format_error/no_response/...） + 按 exit_reason 分类处理 |
Uni-Agent 更细粒度；Miles 更简洁 |
| Partial Rollout | TRUNCATED status + 正常参与训练 |
显式 partial rollout + overlong_buffer_cfg（配置预留，当前标注 unused） |
思路一致，实现形式不同 |
| Reward | 可插拔 RM（custom/remote/rule） | AbstractRewardSpec ABC + 环境内评估（如 reward 直接拿 AgentEnv 做容器内评测） |
Miles 更灵活；Uni-Agent reward&env 耦合更紧密 |
| Off-policy | 过期回收 + TIS ratio 修正（MIS 通过钩子可接入） | async_training.staleness_threshold + mask_abnormal_exit_traj |
都能检测，Miles 可修正而非仅丢弃 |
clip_ratio 缓解而非解决loop.index 等 TITO 规范；Uni-Agent 的 boundary 探测不需要模板约束miles_plugins/ 支持 10+ 模型零改核心；verl 需 fork 或 monkey-patch| 设计 | Uni-Agent 做法 | Miles 现状 | 可借鉴方向 |
|---|---|---|---|
| 细粒度异常分类 | ~11 种 exit_reason + 按类型分类处理 |
3 个主态 + 2 个扩展态 + filter | 可考虑扩展 ABORTED 子类型 |
| 样本级配置 | tools_kwargs 覆盖环境 /reward 参数（如 env.image, reward.*） |
全局配置 | 可考虑 per-sample 配置覆盖 |
| Timeout Budget | 允许 N 次超时再终止（默认 budget=3）；无（超时即 ABORTED） | 可增加容错次数 | |
| Terminal 健康检查 | 超时后 5 次 probe 探测沙箱存活（env.py:139-157） |
由环境侧负责 | 可作为最佳实践推荐 |
| Reward&Env 强耦合评估 | reward 直接拿 AgentEnv 做容器内评测（如 swe_bench.py） | reward 与 env 解耦（通过 HTTP/custom-rm） | 对于需要沙箱验证的场景可借鉴 |
| Overlong Buffer | 配置预留机制（overlong_buffer_cfg），设计意图为接近超长时施加 penalty |
无（直接截断） | 待 Uni-Agent 完整实现后可参考 |
Agentic RL训练：从单一算法到系统协同 中提出，Agentic RL 需要从"算法"扩展为"系统闭环"，涵盖 8 个方面。我们用这个框架来衡量 miles 的成熟度：
| # | 维度 | 描述 |
|---|---|---|
| 1 | 环境与接口建模 | 定义 agent 能看 / 做什么、何时结束、如何验证 |
| 2 | 探索能力与多样性保持 | 维护可探索行为的 support，非增大采样噪声 |
| 3 | 算力分配与学习信号整理 | 预算投向最可能打开梯度的任务与状态 |
| 4 | 目标函数与策略优化 | 判断坏在哪，约束更新与控制漂移 |
| 5 | Rollout 采样、异步并行与调度 | 调度策略本身就在改写训练分布 |
| 6 | 奖励、验证器与效率约束 | reward 不只是答对，是怎样工作才算好 |
| 7 | 记忆、层级与并行 Agent | 训练对象从 token policy 扩展到 operating policy |
| 8 | Infra 基础设施 | 不只承载算法，还在塑造效率、一致性和可扩展性 |
| 总分 |
解读：
Miles 各维度具体情况：
low_var_kl，预留）；entropy_coef 参数；over_sampling 默认 coef=0 未启用；无 curiosity/curriculumdynamic_filter 过滤无信号组；over-sampling 补偿；无优先级采样；无难度自适应Semaphore（512×GPU）、FIRST_COMPLETED；全异步；over-sampling | 调度仍是 FIFO，无智能排序overlong_penalty；无 timeout_budget继续给第二本书打广告。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。