Miles：面向万亿参数模型的强化学习后训练框架，值不值得企业级采用

它解决什么问题：万亿参数后训练中的工程债

大模型的后训练，尤其是强化学习阶段，和预训练一样吃资源，但工程难度更高。Rollout 需要高吞吐推理，训练需要大规模并行，两者之间还要频繁同步权重。Miles 的目标就是把这套流程打包成企业级产品。它面向的是那些跑 DeepSeek-V4、Kimi-K3 这类千亿到万亿参数模型的团队，而不是个人开发者。官方文档明确说，Miles 把 SGLang 用于 rollout，把 Megatron-LM 用于训练，并为此加入了精度、稳定性和可观测性功能。换句话说，它解决的是 RL 训练中那些容易让集群白跑一周的细节问题，比如 MoE 路由不一致、token 重复编解码、引擎崩溃后需要重启。这些问题在小型实验里不致命，但在生产环境里会直接烧钱。

核心机制：TITO、R3 与异步解耦

Miles 的架构里最值得注意的三个机制是 Token-in-token-out（TITO）、Rollout Routing Replay（R3）和全异步 RL。TITO 的意思是，rollout 产生的 token 直接送入训练器，不做 detokenize 再 retokenize 的往返。这个设计避免了信息丢失，也减少了额外计算。R3 则针对 MoE 模型：训练时把 rollout 阶段记录的专家路由信息重放到前向传播中，消除训练和推理之间的路由不匹配。文档说这种不匹配会破坏大规模训练的稳定性，R3 通过重叠计算和通信来控制开销。异步方面，rollout 和训练 worker 完全解耦，支持可配置的 on-policy 和 off-policy 调度。这意味着训练不用等 rollout 完成，反之亦然，减少了流水线气泡。这三个机制组合起来，解决的是 RL 训练中三个最常见的性能杀手：token 转换开销、MoE 不一致、以及同步等待。

训练后端选择：Megatron-LM 为主，FSDP2 为辅

Miles 支持两个训练后端。主后端是 Megatron-LM，负责最大的模型和全部的并行策略。另一个是 PyTorch FSDP2，可以直接训练 HuggingFace 格式的模型。但 README 里说得很直白：配方、并行能力、以及最大的模型都依赖 Megatron-LM。这意味着如果你选择 FSDP2，你只能跑相对小的模型，而且可能享受不到那些针对大规模优化过的特性。这是一个明确的设计取舍：Miles 不是要做一个通用的训练框架，它优先服务那些已经投资 Megatron-LM 生态的用户。对于只用 HuggingFace Trainer 的团队，FSDP2 后端可以作为入门选项，但不要指望它能支撑万亿参数。文档里也提到，Miles 与 SGLang 深度绑定，rollout 引擎就是 SGLang，这意味着你的推理栈也被锁定了。

部署与启动：需要看官方文档，但命令行是入口

要跑起来 Miles，你需要先看安装文档，因为它对硬件有明确要求。官方支持 NVIDIA GB300、GB200、B200、H200、H100、A100，以及 AMD MI300X、MI325、MI350、MI355X，后者通过 ROCm 支持。不同 GPU 有对应的容器镜像，这是部署的关键。快速开始指南在 https://miles.radixark.com/docs/getting-started/quick-start，安装要求里会列出每个 GPU 的状态。从 README 看，Miles 没有提供简单的 pip install 命令，而是强调容器镜像和启动脚本。文档里有一个专门的 Launch Script Walkthrough 页面，说明启动过程需要写配置文件，涉及 rollout、训练、路由等多个组件。这意味着部署不是零配置的，你需要理解每个组件的角色，否则很难排查问题。对于没有专职基础设施工程师的团队，这个门槛可能偏高。

低精度训练：MXFP8 和 NVFP4 是卖点，但不是银弹

Miles 宣传支持 MXFP8 和 NVFP4 低精度训练，并声称有数值稳定的 RL 配方来减少精度导致的发散。这听起来很吸引人，因为低精度能显著降低显存占用和通信带宽。但文档没有给出具体的数据，比如在什么模型规模下能节省多少显存，或者精度损失具体是多少。它只是说支持这些格式，并提到 FP8、INT4 QAT、BF16 和 FP16。这里有一个明显的限制：低精度训练通常需要特定的硬件支持，比如 NVIDIA 的 Blackwell 架构。README 里提到一篇博客叫 Towards Blackwell-Native 8-bit and 4-bit RL，说明这些功能可能只在新一代 GPU 上完整可用。如果你的集群还是 A100 或 H100，MXFP8 可能无法发挥全部优势。所以这个特性是给那些已经升级到 B200 或 GB200 的团队准备的，而不是通用功能。

故障恢复与权重更新：生产环境的两个关键细节

Miles 强调两个生产级特性：故障恢复和快速权重更新。当 SGLang 引擎崩溃时，Miles 可以恢复它并原地继续运行，无需重启或暂停。这对于长时间运行的 RL 任务非常重要，因为一次重启可能浪费数小时。另一个特性是 P2P 权重更新，通过 RDMA 在引擎之间直接传输新权重，文档声称即使在万亿参数模型（如 Kimi-K2.6）上也能在几秒内完成。这两个特性都指向同一个目标：减少停机时间。但要注意，P2P 更新需要 RDMA 网络支持，这意味着你的集群必须有 InfiniBand 或 RoCE，否则这个快速路径不可用。故障恢复也依赖于特定的架构设计，文档没有说明如果训练器本身崩溃会怎样，只提到了推理引擎的恢复。所以这是一个不完整的容错方案，你需要自己评估训练端的可靠性。

生态与替代方案：绑定 SGLang 和 Megatron-LM 的代价

Miles 不是一个独立框架，它深度依赖 SGLang 和 Megatron-LM。这意味着你选择 Miles 的同时，也选择了这两个项目的更新节奏和限制。一个替代方案是使用 veRL（来自字节跳动），它同样支持大规模 RL 训练，但更偏向于纯 PyTorch 生态，不强制绑定 Megatron-LM。veRL 的架构更模块化，你可以自由组合不同的 rollout 和训练后端。另一个选择是 TRL（HuggingFace），它适合中小规模实验，但缺乏企业级特性如 P2P 更新和 R3。Miles 的优势在于它把这些特性整合在一起，并且与 SGLang 的集成是原生的。但如果你不想被 SGLang 绑定，或者你的模型不在官方支持列表里，那么 Miles 的价值就大打折扣。文档提到支持几乎所有前沿模型，包括 DeepSeek-V4、Kimi-K3、GLM-5.2 等，但如果你用的是一个小众模型，可能需要自己适配。

编辑结论

Miles 适合那些已经运行 Megatron-LM 和 SGLang、需要处理千亿甚至万亿参数模型、并且对训练稳定性有严苛要求的企业团队。它提供 TITO、R3、P2P 权重更新等机制，能显著减少 MoE 路由不匹配和 token 往返开销，这些特性在纯 HuggingFace 生态中是找不到的。对于中小团队或刚起步的 RL 项目，Miles 的部署复杂度和对特定硬件（如 GB200、MI355X）的依赖可能成为负担，建议先评估自己的 GPU 集群是否匹配官方容器镜像，再考虑迁移。如果你只是想在单机或小规模集群上快速验证 GRPO 或 PPO，更轻量的框架如 veRL 或直接使用 TRL 可能更合适。采用前务必验证两点：一是你的模型是否在官方支持列表中，二是你是否愿意接受 Megatron-LM 作为主训练后端的长期维护成本。Miles 的路线图明确指向万亿参数和前沿模型，如果你不在这个量级，它的优势会大打折扣。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes