RadixArk开源Miles：全异步Agentic RL打通744B大模型，64卡GB300单步263秒

Miles v0.1: Production-Level Post-Training

论文原文 ↗ 论文发布 2026-09-08 解读发布 2026-09-11 解读：AI前沿分享

大语言模型的后训练（Post-Training）阶段正在发生深刻的范式转移。早期的强化学习（RL）微调往往局限在单轮对话或短文本生成的生成-评估循环中，系统负载相对匀质且线性。然而，随着长思维链模型、代码沙盒执行以及多轮工具调用（Agentic RL）成为前沿模型训练的标配，后训练面临的基础设施压力被成倍放大。在万亿参数级混合专家（MoE）架构下，模型不仅要进行耗时长达数十甚至数百步的环境交互，还要在毫秒级延迟的在线推理与吞吐导向的分布式反向传播之间频繁切换。这种动态异构的工作负载直接诱发了灾难性的算力空泡（Bubbles），更在隐蔽处带来了严重的数值一致性断层。

ArXiv URL：https://arxiv.org/abs/2609.08368v1

针对前沿规模后训练的工程阵痛，AI 基础设施团队 RadixArk 正式开源了 Miles v0.1。Miles 并非简单的训练脚本堆砌，而是一个面向工业级生产环境（Production-Ready）的全栈强化学习与后训练系统。它继承了开源项目 slime 简洁轻量的模块化理念，并将系统核心目标严格锚定在精度验证（Verified）、架构整洁（Clean）与高度可定制（Customizable）三大原则上。Miles 不仅将推理引擎 SGLang 与训练引擎深度缝合，还彻底打通了全异步执行、Token 级精准重放与跨节点权重同步通道，最终在 64 张 NVIDIA GB300 GPU 上成功跑通了拥有 7440 亿总参数（激活 400 亿参数）的 GLM-5.2 模型的全异步 Agentic RL 训练，前 30 步测得的中位数步时仅为 263 秒。

吞吐与忠实度的双重困境：为何传统 RL 框架在 Agent 场景溃败

在多轮工具调用的 Agentic RL 训练中，系统工程同时面临着“吞吐量”与“保真度”两个方向的挤压。吞吐量决定了研发迭代的物理上限。在传统同步强化学习机制中，训练阶段和采样阶段（Rollout）交替发生：GPU 集群在生成交互轨迹时，庞大的反向传播显存处于闲置状态；而当训练节点开始反向计算梯度时，推理生成集群又必须陷入停顿，等待参数更新完毕。这种交替等待在多轮交互任务中被数倍拉长，因为代码执行、沙盒重置以及动态思考长度导致每个样本的完成时间存在数量级差异，最终引发严重的“长尾效应”，拖垮整个集群的硬件利用率。

比吞吐瓶颈更为致命的是保真度危机（Fidelity Divergence）。在强化学习优化目标（如 GRPO 或 PPO）的数学定义中，重要性采样比率（Importance Sampling Ratio）极其敏感。训练器端计算当前策略下的动作对数概率时，必须严格基于采样引擎当时实际掷骰子得到的动作分布。然而在真实的多轮 Agent 交互中，模型生成的原始文本要经历结构化解析、工具参数提取、沙箱运行并返回结果，再重新通过聊天模板（Chat Template）拼接成下一轮提示词。这种反复的文本序列化过程极其脆弱，分词器（Tokenizer）细微的合并规则变动、历史思考内容的修剪、甚至 JSON 字段顺序的变化，都会导致训练器重构出的上下文与推理侧生成的 Token 序列产生偏差。此时，训练器实际上在对一段“从未真正发生过的轨迹”计算梯度，这种无声的分布偏移会迅速破坏训练的稳定性，导致策略模型性能崩溃。

全异步架构解耦与弹性数据缓冲设计

为了从根本上消除同步机制带来的算力空泡，Miles 实现了真正的全异步（Fully Asynchronous）RL 架构。在物理拓扑上，Miles 强制采用计算资源解耦部署（Disaggregated Placement），将 GPU 集群划分为独立的推理生成池与模型训练池，彻底避免了训练与采样在同张显卡上抢占显存引发的上下文切换开销。推理引擎集群基于 SGLang 进行持续不断的轨迹采样，而训练器则以纯粹的吞吐导向模式，从中间层消费已完成的数据批次，两者在时间线上完全重叠运行。

[ 推理集群 (SGLang) ]  ── 连续采样 ──> [ 弹性数据缓冲区 (Bounded Buffer) ]

        ▲                                          │

        │ 权重热更新                                │ 批量消费轨迹组

        └───────────────── [ 训练集群 (Megatron/FSDP) ] ◄──┘

支撑这种并发流程的核心中枢是一个有界数据缓冲区（Bounded Data Buffer）。由于 GRPO 等主流目标函数需要对比同一任务提示词下的不同轨迹来计算基线优势（Advantage），数据必须按“组”（Trajectory Group）进行调度与消费。Miles 在缓冲区处实现了精细的采样生命周期管理：

样本级即时回收机制：当某一交互轨迹率先完成时，后台工作线程立即释放其占用的生成槽位并拉起新任务，无需等待整组长尾样本全部结束，使并发采样容量始终贴合硬件上限。
悲观滞后性拦截与淘汰：全异步系统必须直面策略滞后性（Staleness）带来的方差。Miles 采取了极为严密的悲观定义：一个轨迹组的滞后阶数，等于当前训练器的最新权重版本号，减去该轨迹组内最古老 Token 生成时所使用的权重版本号。一旦滞后阶数超过预设阈值，这批样本就会被果断丢弃，避免用严重过期的策略梯度污染当前模型。

与此同时，这种基于缓冲区的拓扑赋予了系统极佳的工程可观测性。运维人员不再需要盲目猜测训练停顿的原因：当缓冲区队列大小长期归零时，说明生成集群吞吐无法满足反向计算需求，瓶颈在采样端；而当队列长时间处于满载且大量轨迹因过期被丢弃时，则意味着训练端计算吞吐不足，滞后淘汰率上升，系统拓扑亟需向训练侧倾斜算力。

保证数学忠实：TITO 与 MoE 路由重放机制

解决了并发吞吐问题后，Miles 将整套系统的第二道防线建立在训练忠实度上。针对多轮 Agent 交互中普遍存在的序列化漂移，Miles 推出了无损的“Token 输入/Token 输出”（Token-In-Token-Out, TITO）会话服务器。该架构接管了所有交互轮次的状态管理，当智能体在沙盒中反复调用外部终端并接收标准输出时，TITO 服务器记录的不再是经过二次转义的易失性文本，而是 SGLang 在推理时刻实际产生的底层 Token ID 序列。

在处理复杂的外部 Agent 框架（例如具有分支探索或上下文自动压缩特性的工作流）时，TITO 服务器设计了线性和分支双重会话历史规则。每当产生新的交互请求时，服务器会自底向上匹配既有的 Token 快照检查点，精准定位请求挂载的上下文深度。对于工具调用参数重新格式化、空字典省略或思考标记截断等微小格式差异，Miles 提供了带有智能容差的消息匹配器（Matcher）。只要语义未发生偏离，系统就强制复用已缓存的权威 Token 快照，仅对新追加的后缀进行增量分词。通过这种方式，训练端在计算 Log-probabilities 时能够完整复原推理发生瞬间的每一个 Token，彻底切断了传统框架中格式重构诱发的重要性采样漂移。

在 MoE 模型的支持上，保真度问题更加微妙。MoE 的每个路由层（Router）会根据全连接投影打分动态挑选 Top-$k$ 个专家。在单精度向低精度量化或推理框架特化算子（如 FP8/INT8 优化）的介入下，浮点舍入的微小差异就会使得同一个 Token 在推理阶段和训练阶段被分流至完全不同的专家网络。即便输入完全相同的 Token 序列，两个计算图产生的动作概率也会大相径庭。

为此，Miles 引入了高效的“采样路由重放”（Rollout Routing Replay, 简称 R3）机制。在推理采样阶段，SGLang 会记录下激活专家的硬路由决策索引，并将其随轨迹一同打包回传。训练器在反向计算时直接挂载这套路由索引，跳过训练端独立的 Top-$k$ 门控判定，强制让对应的专家网络计算前向激活与梯度。这种机制直接封死了专家路由分歧的发生路径，确保了在大规模 MoE 架构上，离散的推理动作概率与连续的反向梯度能够严格保持数学意义上的同一性。

训练引擎深度演进：双后端、低精度矩阵与显存流式卸载

在反向计算的引擎层，Miles 摒弃了单一绑定的技术路线，对外暴露了一套统一的分布式训练接口，底层同时支持两大主流分布式系统：NVIDIA Megatron-LM 与 PyTorch FSDP。用户无需重写复杂的环境交互逻辑，仅通过一个启动开关即可在两者之间无缝切换。对于超大规模参数模型，Megatron-LM 后端依托 Megatron Bridge 直接对接 Hugging Face 权重目录，实现无须离线格式转换的原生载入，其保存的检查点与具体的并行拓扑解耦，使得后续在扩缩容时能灵活重组张量并行（TP）与流水线并行（PP）切分策略。

训练万亿规模大模型的另一个核心掣肘是显存墙（HBM Wall）。除了针对前向与反向计算的激活值重计算优化，优化器状态占据了显存开销的半壁江山。标准的 FP32 Adam 优化器需要为每个参数维护一份主权重以及一阶、二阶动量，额外带来高达 12 字节/参数的固定显存开销。面对这一挑战，Miles 提供了细粒度的显存卸载（Offload）与流式更新机制：

其一是针对协同部署（Colocated）的训练进程休眠驱逐。当推理与训练不得不复用同一套 GPU 硬件时，系统在训练迭代间隙将整个训练 Actor 的权重、梯度及优化器状态完整踢出显卡，把全部 HBM 腾挪给 SGLang 推理进程使用，待采样完成后再瞬时迁回。

其二则是更具通用价值的“优化器状态磁盘流式加载”（Streaming Optimizer State to Disk）。系统将庞大的模型参数划分为若干离散的参数桶（Buckets），其对应的 Adam 优化器状态全部持久化暂存在高速磁盘或主机内存中。在反向传播计算梯度的过程中，GPU 显存中完全不存在任何优化器状态；只有当进入参数更新阶段时，训练器才依次以“桶”为单位，将局部优化器状态流式拉入 HBM，就地执行梯度更新后立刻将其逐出。这种分批流转机制打破了模型规模受限于物理显存的硬性约束，为极端参数规模下的全参数微调留出了宝贵的操作空间。

在数值精度方面，Miles 积极拥抱新一代硬件架构特性，全面兼容了 Blackwell 架构下的 NVFP4 以及广泛应用的 MXFP8 低精度矩阵乘法配方。为了防止量化引发训练崩溃，Miles 制定了严苛的双端验证基准：在投入生产前，系统会对 SGLang 与训练后端在同一批 Token 序列上给出的对数概率进行对齐度审计。实验表明，在已验证的模型配置下，采用低精度量化配方的奖励曲线能够与 BF16 基线紧密重合，在换取数倍推理吞吐提升的同时，将数值精度损失牢牢锁死在安全边际之内。

工业级落地实战：GLM-5.2 744B MoE 的 64 卡终端 Agent 训练

所有架构设计的优劣，终究要在严酷的真实工业级场景中见分晓。Miles v0.1 在报告中展示了一个极具代表性的高难度全流程端到端案例：针对智谱大模型 GLM-5.2 进行多轮终端代码 Agent 强化学习训练。

GLM-5.2 采用大规模 MoE 架构，模型总参数量高达 7440 亿（744B），单次前向激活参数约为 400 亿（A40B）。任务目标为高强度的复杂终端环境编程：模型不仅要自主编写逻辑代码，还必须在真实的命令行沙盒中执行多轮调试命令、查看环境报错、调用编辑器修补文件，并最终通过自动化单元测试集获取奖励信号。

在此次端到端任务中，系统配置完全展开：

硬件集群配置：全流程部署在 64 张新一代 NVIDIA GB300 GPU 构成的计算集群上，按照非共存的解耦拓扑将卡群分配给 SGLang 推理组与训练器。
训练模式与长尾控制：采用完全解耦的全异步 RL 范式，通过 TITO 会话架构维系真实终端多轮会话的精准上下文，配合 SGLang 的前缀缓存机制（Prefix Cache）。在高并发随机路由与最少负载调度算法的协同下，推理端前缀缓存命中率稳定维持在惊人的 96%，大幅压低了多轮交互前缀的冗余重计算。
真实端到端吞吐表现：在包含了漫长的真实环境执行、网络通信、复杂 MoE 前向路由与反向更新的全链条中，前 30 个完整训练步的步时中位数仅为 263 秒。对于一个 744B 规模的庞然大物而言，这一耗时证明了系统在面对高度异构、长尾严重的多轮交互工作流时，拥有极其出色的算力吞吐与调度稳定性。

除了应对极端规模的全参数 RL，Miles 展现出的另一个关键工业价值在于对异构工作负载的兼收并蓄。它不仅能够无缝承载 LoRA 强化学习、在策略蒸馏（On-Policy Distillation）以及单纯的监督微调（SFT），还将整套流水线架构横向扩展到了 Diffusion 扩散模型的后训练生态中。这种将复杂底层（并行通信、显存编排、数值保真）彻底封装，同时在上层暴露出清晰类型化损失函数接口的设计，标志着大模型后训练系统正在从作坊式的脚本拼凑，大步迈入标准化的基础设施工程时代。随着 Miles 开源生态的演进，前沿尺度的 Agent 训练技术门槛将被进一步拉低，为学界与工业界构建真正具备自我演进能力的复杂智能体提供了稳固可靠的工程底座。