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_hubMulti-Agent 从轻量到生产级 内置示例 → MrlX 完整框架下图可以看到Miles的工作Miles 的工作 利用Slime扩展点 底层内核 / 精度改造 ◄─── 非扩展点 RDMA 权重同步基础设施 ◄─── 非扩展点 训练后端深度改造 (FSDP/CP) ◄─── 非扩展点 Chat Template 正确性工程 ◄─── 非扩展点 可观测性 / 调试系统 ◄─── 非扩展点 20 场景示例生态 ◄─── 非扩展点 …注在本文撰写时朱小霖大神 已经发布了最新版本 slime v0.3.0: 面向 Agent 时代 因此本文涉及的 slime 都是旧版本的表现不代表 slime 的最新能力。另因为本文为从源码反推涉及且编写仓促所以肯定有错误还请读者不吝指出谢谢。0x01 基础1.1 Agentic RL 的需求与难点在传统 RLHF 中模型根据一个 prompt 生成一段回答reward model 对该回答打分完成一轮训练。而在 Agentic RL 场景下AgentLLM在一个有状态的环境中通过多轮交互来完成任务——调用工具、搜索信息、执行代码、与外部 API 交互。模型需要从交互的最终结果而非中间回答的评分中学习。1.1.1 传统 RLHF vs Agentic RL 范式对比以下数值不是精确值。维度 传统 RLHF单轮 Agentic RL多轮交互轮次 1 轮 10-50 轮序列长度 4K tokens 8K-64K tokens单次 Rollout 时长 10s 60-600sToken 归属 全部归模型 混合model token (loss_mask1) env token (loss_mask0)环境依赖 无 强依赖外部环境Docker/API/沙箱失败模式 少 超时/环境崩溃/格式错误/上下文满/沙箱死亡Reward 来源 固定 Reward Model 环境结果test pass, task completeCredit Assignment 短序列信号直接 长序列Reward 在末尾Off-policy 风险 低 高生成慢模型可能已更新多次1.1.2 核心难点Agentic RL 的需要是框架可以处理 推理编排、长程训练、外部环境和工程维护方式等功能其核心难点具体举例如下难点 具体表现 影响多轮状态管理 50 轮 × 200 token 10K token 需要在 session server 中累积追踪 内存和 tokenization 一致性压力Token 混合属性 env token工具返回/用户输入mask0model token mask1错标一个 梯度噪声 一个 token 错标 → 该样本梯度方向偏移Tokenization 一致性 Jinja loop.last 导致 10% prefix 变化首轮 tokenization 被后续轮覆盖 10% token 不一致 → 训练数据质量下降训推不一致 (log prob) 推理用 SGLangFP8/int4训练用 MegatronBF16log prob 不一致 KL 估计失真 → 优势函数偏差MoE 路由翻转 ~5-15% token 在训练和推理时路由到不同 expert精度差异导致 expert 选择不同 → 梯度计算在错误 expert 上 前向 log prob 和反向梯度路径不一致 → 训练崩溃长尾延迟 一个慢 Agent 会话阻塞整个 batchGPU 利用率暴跌 GPU 利用率断崖下降On-Policy 过期 120s 推理窗口内模型已更新 2-3 步但 rollout 仍使用旧模型权重 重要性采样权重偏离Credit Assignment 50 轮后 reward1不知道哪步贡献最大 策略梯度信号极稀疏异构 Agent 协同 不同 agent 用不同模型、不同训练循环、消息队列通信 数据结构不统一、reward 非对称规模可扩展性 1TB MoE 模型数十 GB 参数同步 RDMA 带宽成为瓶颈1.2 系统架构Miles fork 自 slime继承其核心的 RL 流水线架构mile-1-1Miles 的系统架构如下mile-1-21.3 组件边界说明Miles 由多个可独立启停的进程/服务组成以下标准明各组件的职责边界组件 职责 何时需要SGLang Engine 模型推理 rollout 生成每个实例管理一组 GPU 始终需要无推理则无 rolloutSGLang Router (sglang_router) Round-robin / cache-aware 推理请求路由 多 GPU 推理默认搭配 SGLang engineMiles Router (miles/router/) 最少连接负载均衡 健康检查 故障隔离 radix tree 缓存中间件 高级路由需求–use-miles-router --miles-router-middleware-pathsSession Server 多轮会话管理 TITO 增量 tokenization OpenAI 格式代理 Agentic RL多轮交互–use-session-serverMegatron Actor 分布式训练前向/反向/optimizer step 始终需要–train-backend megatron默认FSDP Actor 分布式训练实验性后端 --train-backend fsdp小规模/非 MoE 模型Ray 分布式进程编排、Placement Group、Actor 生命周期 始终需要框架基础设施mooncake TransferEngine RDMA 零拷贝权重传输 P2P 模式默认–update-weight-transfer-mode p2p1.4 数据流miles 的 6 步完整流程如下1.4.1 步骤 1Prompt 输入路径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 等。1.4.2 步骤 2Agent 交互多轮场景路径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() / 保持多轮1.4.3 步骤 3训练数据转换路径_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 检测}1.4.4 步骤 4训练路径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 clippingREINFORCE 逐 token 折扣累积 rewardREINFORCE Baseline 同上 baseline 减方差On-Policy Distillation teacher - student log prob 差1.4.5 步骤 5权重同步路径[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_version1.4.6 步骤 6循环全异步变体路径[train_async.py]rollout_data_next generate(rollout_id 1) ← 提前启动rollout_data_curr await rollout_data_next ← 等待本次train(rollout_id, rollout_data_curr) ← 训练与下次 rollout 重叠0x02 从 Slime 说起在 Slime 基础上Miles 将 Slime 的 支持 Agentic升级为 “Agentic-first”提供开箱即用的 Agent 训练工具链。维度 Slime Miles (fork)设计初衷 通用 LLM RL 后训练框架 企业级大规模 Agentic RLAgentic 支持 通过异步解耦架构支持 继承 增强 (多智能体 MrlX)核心用户 GLM 系列模型训练 更广泛的企业场景2.1 Slime 的职责定位Slime 是 “分布式 RL/LLM 训练底座” - 负责把 Ray Megatron SGLang 组织成可训练、可 rollout、可评估的闭环系统。Slime 的核心职责不是定义具体 agent 玩法而是提供训练主循环 (train.py, train_async.py): rollout - train - save - eval - update weightsRay 资源编排 (Placement Group, Train Actor, Rollout Manager 生命周期)Megatron 训练后端 (模型初始化, train/save, loss/value/log prob 计算)SGLang rollout 基础设施 (启动推理引擎, router, generate/eval, 健康检查)插件 / 扩展点 (25 个 --xxx-path 动态导入接口)Slime 不负责复杂 agent/session/tool/多轮语义、训推精确一致性治理、多后端。2.2 Slime 端到端做了什么在 train.py 里Slime 负责完整训练编排分配 GPU - 启动 rollout manager - 创建 actor/critic - 每轮generate rollout - train - save - eval - update rollout weights在 rollout 层面启动 / 恢复 SGLang engineRouter 地址与端口管理Offload/onload健康监控多 server group 组织在训练后端Megatron 初始化Tokenizer/config 加载Model/optimizer/scheduler 初始化Rollout 数据转训练 batchPolicy/value/log prob/loss 计算Actor - rollout 权重同步2.3 Slime 的扩展点体系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 pathReward --custom-rm-path / --custom-reward-post-process-path import pathLoss --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 pathMegatron 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 pathABC DataSource / TrainRayActor / HfWeightIteratorBase / HuggingfaceAttention 继承0x03 Miles 的升级Miles 将 Slime 的研究级 RL 框架升级为Agentic-first 的企业级生产系统核心创新在于用 Session/TITO 解决多轮 tokenization 正确性用全异步 staleness 解决性能用 R3 True On-Policy当前支持 dense 模型解决稳定性。3.1 升级思路 — 三层利用策略虽然 Slime 提供了扩展点但是 Miles 并没有简单的利用扩展点而是“利用扩展点 新增架构层 深度改造核心” 三者并行。具体可以分为三层Layer C: 新增架构层 (Miles 独创) Session Server / TITO / Miles Router / Agent Hook → Slime 完全没有预见Layer B: 深度改造 (修改 Slime 核心 扩展点) 改默认 rollout/data-source / 删 advantage hook 类 / 优化 rollout 合约 / bridge 路径切换Layer A: 直接利用扩展点 (Slime 设计的 path hooks) custom-generate / custom-rm / dynamic-filter Miles 用户进一步通过这些接口接入自己的逻辑3.2 分工边界Slime 做 “能跑起来”Miles 做 “跑得正确 跑得快 跑复杂场景”。因此两者分工边界如下维度 Slime 负责 Miles 负责训练主循环 基本闭环 (同步/异步骨架) 异步化增强 / AsyncRolloutWorker / StalenessRay 编排 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-PolicyToken 正确性 无验证 TITO template 验证 append-only 校验可观测性 基础 logging 4 后端 Tracking debug dump profiling模型生态 GLM 为主的支持 10 模型族 bridge megatron_bridge patch3.3 Miles工作全景下表为Miles工作全景对于主要工作领域进行分类看看属于三层中哪一层。其中Layer A. 利用扩展点通过 Slime 预设的 --xxx-path 接口注入实现Layer B. 新增架构层Slime 完全没有的模块Miles 从零建设Layer C. 深度改造/修改核心对 Slime 原有代码的深度改造 / 重写工作领域 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%3.4 Miles 对 Slime 扩展点的利用3.4.1 Miles 主动提供内置实现的扩展点说明以下统计仅覆盖 --xxx-path 类 import-path 扩展点。若把 args.spec、register_model bridge 注册等机制也算入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 类型 开箱即用 reward3.4.2 Miles 保留但不提供内置实现的扩展点 (~19 个)这些接口在 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.specregister_model (用户可扩展更多模型)MegatronModelBridge.register_bridge3.4.3 Miles 删除的扩展点 (1 个)扩展点 原因–custom-advantage-function-path Miles 直接内置 advantage 计算不再暴露3.4.4 Miles 在扩展点之上新增的层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 从纯函数升级为类3.5 完整工作3.5.1 全新增模块模块 说明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 模式 rolloutdocs/developer/migration.md 从 slime 迁移到 Miles 的指南rollout/session/ Session Server TITO 增量 tokenizationrollout/generate_hub/agentic_tool_call.py Agentic RL 生成框架true_on_policy/config.py Kernel policy 生成器P2P 权重传输子模块 mooncake RDMA 零拷贝同步3.5.2 大幅修改模块模块 改动内容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 模板系统3.5.3 继承核心RL 流水线结构rollout → train → update_weights后端布局megatron_utils / training_utils工具集arguments, misc, ray_utils 等模块化参数解析Megatron args SGLang args 的合并机制Ray Actor 基类3.6 结论Slime “能跑起来” - 提供训练底座 25 个扩展点。Miles “跑得正确 跑得快 跑复杂场景”。Miles的工作以B新增C改核心为主纯利用扩展点的工作只是冰山一角。真正的价值在于Slime完全没预见的“会话化正确性“和“训推致性治理“等新架构层是对计算核心、传输层、正确性保障、可观测性做了全面的工程建设。---- 具体体现为~15% 利用扩展点 (RM/filter/generate/data-source 等 --xxx-path 接口 bridge 注册)~45% 新增架构层 (Session/TITO/True On-Policy/P2P/Router/FSDP/Tracking)~40% 修改核心 (rollout 架构/loss/Megatron actor/权重同步/训练循环)Miles 的价值不在于 “在扩展点上插实现”而在于解决 Slime 最初设计时 **根本没预见的三类问题 **多轮 token 正确性 (TITO Template Token 对齐)训推 bit-exact 一致性 (True On-Policy R3 FP8)大规模 Agentic 场景的性能 (全异步 RDMA RadixTree)0x04 Miles 的逻辑分层上面的角度是从如何改造 Slime 的思路来看我们下面看看从解决问题角度来看或者说从业务逻辑角度来看看如何对Miles进行分层。4.1 问题域总结Miles 对于问题域的解法如下。问题域 核心痛点 Miles 的解法 主要改造方式正确性 多轮 token 漂移、MoE 路由翻转、训推 log prob 偏差 TITO Template 验证 R3 True On-Policy FP8 统一 BCAgent 开发体验 每个 Agent 重写 boilerplate Session Server agentic_tool_call custom-agent-path AB性能 GPU 空闲率高、权重同步慢、前缀重复计算 全异步 P2P RDMA RadixTree 缓存 BC算法能力 需要 GRPO/TIS/OPD/多后端/多模型 Loss 重构 FSDP 后端 10 bridge ABC生产可靠性 样本质量、worker 故障、训练诊断 Filter Router 健康检查 Tracking Debug AB规模扩展 1TB MoE、千卡、多并行 P2P CP 多布局权重同步 megatron_bridge BC4.2 分层架构图以上问题域的解法可以分为如下 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 层具体信息如下层级 定位 归属的 JobsL5 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 体系、⑮ 样本过滤、⑯可观测性4.4 详细映射表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 工具)4.5 各层工作量分布层 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 属语义层。0x05 Miles 每项工作解决的问题Miles工作全景领域×改造方式×解决的问题5.1 L5: Agent/Session/Tool 语义层主要是Session Server / TITO / agentic_tool_call / Agent Hook① Session 多轮改造方式 具体工作 解决的问题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 逻辑解耦 - 业务代码与训练框架彻底分离② Rollout 生成改造方式 具体工作 解决的问题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 调用重构为统一 pipeline5.2 L4: 训推一致性治理层③ 训练一致性改造方式 具体工作 解决的问题B True On-Policy 契约系统 在受支持配置下对齐 log prob - 通过契约deterministic 设置让两侧计算路径尽量 bit-exact (当前覆盖 qwen3 dense 契约)B FP8 统一内核 精度源对齐 - 两侧各用各的 FP8 cast - 数值不一致 - 统一 kernelC 训练侧可直接用 rollout logprob 跳过重算 - 契约保证一致后无需浪费算力重算④ MoE 路由改造方式 具体工作 解决的问题C R3 路由重放 MoE 梯度正确性 - 推理选 Expert{2,7} 训练选 Expert{2,8} - 梯度在错误 expert 上。存储开销bytes ≈ (tokens-1) × num_layers × topk × 4 (dtypeint32)以 32K token × 60 layers × top8 为例约 60MB/样本5.3 L3: 训练后端扩展层⑤ 训练 Loss改造方式 具体工作 解决的问题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 (MambaMoE) 需 patch Megatron Core⑨ SGLang 集成改造方式 具体工作 解决的问题B sglang_utils/ 引擎管理标准化 - 参数约束统一管理避免配置错误C rollout 启动改造 支持新特性 - True On-Policy 需要特殊启动参数⑩Router 中间件改造方式 具体工作 解决的问题B Miles Router 生产级服务 - worker 故障自动隔离、最小并发路由、健康检查B RadixTree 中间件 推理效率 - 多轮交互前缀重复缓存后只推理增量5.4 L2: 基础设施层⑪ 权重同步改造方式 具体工作 解决的问题B P2P RDMA 零拷贝 (Mooncake TransferEngine) 同步速度 - 1TB 模型 HTTP 太慢RDMA 直写 GPU 显存C 多并行布局支持 大规模部署 - TP/PP/CP 下权重分片需正确收集分发⑫ 数据源改造方式 具体工作 解决的问题A RolloutDataSourceWithBuffer 支持 buffer 回收 - staleness 过滤后样本需回收重生成⑬ 参数系统 (200 新参数 插件自注册)改造方式 具体工作 解决的问题B 200 新参数 能力可配置 - 新功能都需要参数控制B 插件自注册 CLI args 可扩展性 - generate 插件声明自己的参数C 删除 custom-advantage-function-path 简化接口 - 内置即可不再暴露5.5 L1 生态层⑭ Reward 体系 (8 RM rm_hub 异步框架)改造方式 具体工作 解决的问题A 8 内置 RM (math/dapo/f1/gpqa/remote…) 开箱即用 - 常见场景无需自己写 reward 函数B rm_hub/ 异步框架 高吞吐 reward - batch 化异步 RM避免串行成为瓶颈⑮ 样本过滤 (filter_hub 内置规则)改造方式 具体工作 解决的问题A check_reward_nonzero_std / check_no_aborted 防止无效训练 - 全对/全错组对 GRPO 无信号ABORTED 组有噪声B filter_hub/ 协议抽象 过滤可插拔 - 不同任务不同逻辑统一接口⑯ 可观测性 (4 后端 Tracking Debug 工具)改造方式 具体工作 解决的问题B 4 后端 Tracking (WandB/TensorBoard/MLflow/Prometheus) 统一监控 - 不同团队用不同工具统一扇出B Debug 工具 快速诊断 - dump rollout/replay reward/直接发 SGLang 请求0x06 对比我们把miles和Uni-Agent进行对比。6.1 整体设计哲学差异维度 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 实现 UniAgentLoopToken 对齐 TITO精确预计算 验证bit-exact 启发式 boundary_tokens 推断 rollout_cache 增量追加best-effortSession 实现 独立 FastAPI 服务Session Server 进程内 rollout_cachetoken/trajectory cache AgentEnv 保持环境状态MoE 支持 核心目标R3 路由重放 FP8 统一 TIS 支持 MoE 训练Expert Parallel但无路由重放机制配置层次 命令行参数argparse单层 训练层 Hydra Agent 层 YAML 文件 样本层 tools_kwargs runtime override6.2 关键机制对比机制 Miles 方案 Uni-Agent 方案 权衡增量 Tokenization TITO全量预计算 → 运行时 prefix 校验 autofix rollout_cache 增量追加 基于 chat template 的 boundary_tokens 启发式推断 Miles 更精确但模板需适配Uni-Agent 更通用但 best-effort训推一致性 多级保证StalenessTISR3True On-Policy部分 recipe 用极小 clip_ratio如 4e-4另一些用标准值0.2/0.28配合 staleness_threshold Miles 解决根因Uni-Agent 按场景选择保守或激进并发控制 Semaphore512×GPU FIRST_COMPLETED 调度 worker_concurrent max(global_concurrent // num_workers, 1) asyncio.Semaphore 类似思路 Miles 更细粒度异常处理 3 个训练相关主态COMPLETED/TRUNCATED/ABORTED 2 个扩展态PENDING/FAILED filter ~11 种 exit_reasontoken_limit/format_error/no_response/… 按 exit_reason 分类处理 Uni-Agent 更细粒度Miles 更简洁Partial Rollout TRUNCATED status 正常参与训练 显式 partial rollout overlong_buffer_cfg配置预留当前标注 unused 思路一致实现形式不同Reward 可插拔 RMcustom/remote/rule AbstractRewardSpec ABC 环境内评估如 reward 直接拿 AgentEnv 做容器内评测 Miles 更灵活Uni-Agent rewardenv 耦合更紧密Off-policy 过期回收 TIS ratio 修正MIS 通过钩子可接入 async_training.staleness_threshold mask_abnormal_exit_traj 都能检测Miles 可修正而非仅丢弃6.3 Miles 的优势R3 路由重放MoE expert 路由记录 → 训练时精确重放verl 支持 MoE 训练但无路由一致性保证True On-Policy 契约FA3 对齐 batch/TP 不变性 → bit-exactverl 部分 recipe 用小 clip_ratio 缓解而非解决FP8 统一内核推理训练同一 Triton cast → 消除精度差异verl 依赖引擎默认精度Session Server 服务化独立 FastAPI → 可跨进程 / 跨节点复用Uni-Agent session 是进程内 rollout_cache AgentEnvChat Template 验证编译期 loop.index 等 TITO 规范Uni-Agent 的 boundary 探测不需要模板约束Miles Router 中间件RadixTree 前缀复用 Worker 健康检查verl 用裸 SGLang/vLLM插件系统miles_plugins/ 支持 10 模型零改核心verl 需 fork 或 monkey-patch6.4 Uni-Agent 值得借鉴的设计设计 Uni-Agent 做法 Miles 现状 可借鉴方向细粒度异常分类 ~11 种 exit_reason 按类型分类处理 3 个主态 2 个扩展态 filter 可考虑扩展 ABORTED 子类型样本级配置 tools_kwargs 覆盖环境 /reward 参数如 env.image, reward.* 全局配置 可考虑 per-sample 配置覆盖Timeout Budget 允许 N 次超时再终止默认 budget3无超时即 ABORTED 可增加容错次数Terminal 健康检查 超时后 5 次 probe 探测沙箱存活env.py:139-157 由环境侧负责 可作为最佳实践推荐RewardEnv 强耦合评估 reward 直接拿 AgentEnv 做容器内评测如 swe_bench.py reward 与 env 解耦通过 HTTP/custom-rm 对于需要沙箱验证的场景可借鉴Overlong Buffer 配置预留机制overlong_buffer_cfg设计意图为接近超长时施加 penalty 无直接截断 待 Uni-Agent 完整实现后可参考0x07 Agentic RL 8 大关键维度Agentic RL训练从单一算法到系统协同 中提出Agentic RL 需要从算法扩展为系统闭环涵盖 8 个方面。我们用这个框架来衡量 miles 的成熟度维度 描述1 环境与接口建模 定义 agent 能看 / 做什么、何时结束、如何验证2 探索能力与多样性保持 维护可探索行为的 support非增大采样噪声3 算力分配与学习信号整理 预算投向最可能打开梯度的任务与状态4 目标函数与策略优化 判断坏在哪约束更新与控制漂移5 Rollout 采样、异步并行与调度 调度策略本身就在改写训练分布6 奖励、验证器与效率约束 reward 不只是答对是怎样工作才算好7 记忆、层级与并行 Agent 训练对象从 token policy 扩展到 operating policy8 Infra 基础设施 不只承载算法还在塑造效率、一致性和可扩展性总分解读Miles 强在 Infra(8) 和 Multi-Agent(7)生产级工程能力和系统协同Uni-Agent 强在 环境建模 (1) 和 奖励约束 (6)算法侧精细化设计共同短板探索策略 (2) 和 算力分配 (3) — 整个 Agentic RL 领域的开放问题Miles 各维度具体情况环境建模Session Server OpenAI 接口3 种终止状态Harbor/HTTP/ 用户自定义 | 不管理 env 生命周期无 env 抽象类探索多样性KL loss 框架low_var_kl预留entropy_coef 参数over_sampling 默认 coef0 未启用无 curiosity/curriculum算力分配dynamic_filter 过滤无信号组over-sampling 补偿无优先级采样无难度自适应目标函数GRPO/DAPOTIS 修正True On-PolicyStaleness 过滤Dr.GRPO 仅 stubRollout 调度Semaphore512×GPU、FIRST_COMPLETED全异步over-sampling | 调度仍是 FIFO无智能排序奖励约束8 内置 RMcustom/remote环境即 reward无 overlong_penalty无 timeout_budget多 Agent内置 Solver/Rewriter/SelectorMrIX 外部框架无层级 Agent无跨 episode 记忆
