MT-Miles 入门

1. Miles 是什么

Miles 是面向大规模模型后训练的高性能强化学习框架，由 Slime 演进而来。它使用 SGLang 执行高吞吐 rollout，并支持 Megatron-LM 和 PyTorch FSDP2 训练后端，重点解决大规模 RL 中的性能、稳定性、可观测性和容错问题。

Miles 面向的不只是单轮数学问答，还包括多轮工具调用、代码 Agent、环境交互和长轨迹训练。它提供同步/异步 rollout、权重同步、reward/verifier、自定义数据生成、LoRA、低精度训练等能力。

1.1 当前项目的 MT-Miles 边界

本目录名称为 MT-Miles，用于组织 Miles 与摩尔线程平台相关的文档。但截至当前版本：

目录中尚未提供可复现的 MUSA 训练脚本或实战页；
Miles 上游官方列出的主要硬件是 NVIDIA 和 AMD；
不能仅因为 Slime 已有 MUSA 实践，就推断 Miles 可以直接在 MUSA 上运行。

因此，本页首先介绍 Miles 的官方架构和标准工作流。真正执行 MUSA 训练前，仍需验证 torch_musa、MCCL、SGLang-MUSA、Megatron MUSA patch、torch_memory_saver 和权重同步链路。

1.2 适用场景

GRPO、GSPO、PPO、REINFORCE++ 等大模型 RL 后训练；
SFT 和 on-policy distillation；
多轮、工具调用和长时 Agent 轨迹生成；
大规模 Dense/MoE 模型及多机集群；
rollout 与 training 解耦或 fully async RL；
对容错、可观测性和精确 token 轨迹有较高要求的生产任务。

2. 核心架构

2.1 主要组件

组件	作用
Training Backend	使用 Megatron-LM 或 FSDP2 更新模型参数
SGLang Rollout	批量生成 response、工具调用或 Agent 轨迹
Router	将生成请求分发到多个 SGLang engine
Data Buffer / Collector	管理 prompt、response、reward 和训练样本
Reward / Verifier	计算规则奖励、模型奖励或环境反馈
Weight Update	将训练侧新权重同步到 rollout engine
Ray	编排训练、推理和辅助 worker 及其资源
Observability / Fault Tolerance	监控、恢复失败 engine 并记录训练状态

2.2 一个 RL step 如何运行

Prompt / Agent 任务
        ↓
SGLang engine 生成 token 与轨迹
        ↓
Reward / Verifier / Environment 返回反馈
        ↓
Collector 整理训练样本
        ↓
Megatron 或 FSDP2 更新参数
        ↓
Weight Update 同步新权重
        ↓
开始下一轮 rollout

Miles 强调 token-in-token-out（TITO），尽量避免在 rollout 与 training 之间反复 detokenize/retokenize，从而保留精确 token 和轨迹元数据。

3. 如何选择运行模式

3.1 同步、异步与 fully async

模式	特点	适合场景
同步 RL	rollout 完成后再训练，边界清晰	首次验证和严格 on-policy 任务
异步 RL	rollout 与 training 部分重叠	提高吞吐、减少等待
Fully async	两侧持续流水化运行	长尾 Agent 轨迹和大规模集群

异步程度越高，越需要明确样本版本、策略滞后和允许的 off-policy 范围。

3.2 Megatron-LM 与 FSDP2

最大规模、MoE、复杂并行和官方大模型 recipe → Megatron-LM
希望直接训练 Hugging Face 实现、规模较小       → FSDP2

Megatron 路径通常需要独立训练 checkpoint 和模型结构参数；FSDP2 更接近 Hugging Face 模型实现，但并不代表所有 Miles 特性和 recipe 都完全等价。

3.3 训练与 rollout 的资源放置

训练和 rollout 可以共置，也可以使用不同 GPU/节点。解耦部署通常更稳定且便于扩缩容，共置模式更节省资源但对 offload、显存和显存管理器兼容性要求更高。

4. 环境与 MUSA 适配准备

4.1 上游推荐环境

上游建议优先使用官方容器，以获得匹配的 Miles、SGLang、Megatron-LM 和 torch_memory_saver。从源码安装时，至少需要 Python、PyTorch、Ray、Transformers，以及选择的训练和 rollout 依赖。

4.2 MUSA 适配检查清单

在编写 MT-Miles 实战文档前，应逐项验证：

Miles 能否识别 MUSA accelerator；
SGLang-MUSA 是否支持目标模型和 attention backend；
Megatron MUSA patch 是否与 Miles 使用的 Megatron 版本匹配；
NCCL 调用是否已正确替换或映射为 MCCL；
torch_memory_saver 是否支持 MUSA 的 offload 和 graph capture；
权重同步传输是否支持目标硬件和网络；
Ray worker 中是否正确传递 MUSA 环境变量。

未完成这些验证前，不应直接复用 CUDA 示例中的 CUDA_VISIBLE_DEVICES、NCCL、FP8/MXFP8/NVFP4 或 RDMA 配置。

4.3 存储和网络

多机任务通常需要共享模型、数据、checkpoint 和权重更新目录。Ray、Gloo/MCCL、SGLang router 和权重同步服务还会使用不同端口；应明确节点 IP、训练网卡和防火墙策略，而不是只依赖默认网卡选择。

5. 从数据到训练的标准流程

5.1 准备数据和 reward

开始前要明确：

prompt、label 和 metadata 的字段；
reward 是规则、模型还是环境返回；
单轮还是多轮生成；
是否调用工具或 sandbox；
最大输入、输出和轨迹长度。

先使用极少量数据运行 rollout-only 测试，检查 token、response、reward 和 metadata，再启动训练闭环。

5.2 准备模型和训练后端

Megatron 路径需要匹配的模型配置和训练 checkpoint；FSDP2 路径通常直接加载 Hugging Face 模型。无论选择哪种后端，rollout 模型、训练模型、tokenizer 和 chat template 都必须一致。

5.3 配置资源与 rollout

需要同时配置：

训练节点和每节点 GPU 数量；
rollout engine 数量及每个 engine 的并行度；
是否共置、offload 或完全解耦；
rollout batch、每个 prompt 的采样数和最大长度；
权重同步方式和频率。

5.4 启动 Ray 和训练入口

Miles 提供同步和异步训练入口，实际命令应以目标版本的官方 Quick Start 和 recipe 为准。提交任务前先验证 Ray 集群资源、模型路径、共享目录和所有节点的软件版本一致。

5.5 监控正确性和性能

至少同时观察：

rollout throughput、排队请求和失败率；
reward 分布、有效样本率和轨迹长度；
policy version 与样本新鲜度；
loss、KL、entropy 和梯度范数；
GPU 利用率、显存、网络和权重同步耗时；
engine 恢复和 checkpoint 状态。

6. 参数概念速查

6.1 资源参数

概念	含义
Actor nodes / GPUs	训练模型使用的节点和 GPU
Rollout GPUs	推理生成使用的 GPU
GPUs per engine	每个 SGLang engine 的并行规模
Colocate	训练和 rollout 分时共享资源
Disaggregated	训练和 rollout 使用独立资源

6.2 数据和算法参数

概念	含义
Rollout batch size	每轮参与生成的 prompt 数量
Samples per prompt	每个 prompt 生成的 response 数量
Advantage estimator	GRPO、GSPO、PPO 等优势估计方法
Steps per rollout	一批 rollout 数据执行的训练更新次数
KL / entropy	约束策略变化和生成分布的正则项

6.3 权重与精度参数

概念	含义
Weight update	将训练权重同步到推理 engine
Full / delta update	传输完整权重或权重增量
BF16 / FP16 / FP8	训练和通信使用的数值精度
LoRA	只训练和同步低秩 adapter

7. 常见问题定位

7.1 Ray 或 SGLang engine 启动失败

先定位第一个退出的 worker，并向前查找原始异常。scheduler is dead、Ray actor died 等通常只是后续现象。

7.2 Rollout 正常但训练不收敛

检查 reward、mask、token 对齐、旧策略 log probability、权重同步和样本版本。RL 中很多错误不会直接导致进程崩溃，而会表现为奖励不增长或训练逐渐发散。

7.3 共置模式 OOM

降低 rollout 显存比例、batch 和最大长度，确认 training 与 rollout 的 offload 顺序。如果错误涉及 graph capture 和显存创建，先关闭 CUDA/MUSA Graph 进行兼容性验证。

7.4 多机权重同步失败

确认各节点模型拓扑和参数顺序一致，网络传输后端可用，端口未被占用，并检查失败是否发生在某个更早的 worker OOM 之后。

7.5 MUSA 环境参数不识别

这通常说明当前 Miles 版本没有对应 MUSA 适配，或 patch 没有在 Ray worker 环境中生效。不要用简单参数替换掩盖底层 accelerator、kernel 或通信实现缺失。

8. 下一步阅读

Miles 官方仓库：源码、版本和已支持能力；
Miles 官方网站：核心特性、模型和硬件支持；
Miles 文档：安装、Quick Start、后端和核心概念；
SGLang 文档：rollout engine 和 router；
Slime 入门：本项目中已有 MUSA 实践的相关 RL 框架。

当前页面不代表 Miles 已在 MUSA 上完成端到端验证。后续增加 MT-Miles 实战文档时，应同时记录硬件、镜像、依赖版本、patch、训练命令和验证结果。

1. Miles 是什么​

1.1 当前项目的 MT-Miles 边界​

1.2 适用场景​

2. 核心架构​

2.1 主要组件​

2.2 一个 RL step 如何运行​

3. 如何选择运行模式​

3.1 同步、异步与 fully async​

3.2 Megatron-LM 与 FSDP2​

3.3 训练与 rollout 的资源放置​

4. 环境与 MUSA 适配准备​

4.1 上游推荐环境​

4.2 MUSA 适配检查清单​

4.3 存储和网络​

5. 从数据到训练的标准流程​

5.1 准备数据和 reward​

5.2 准备模型和训练后端​

5.3 配置资源与 rollout​

5.4 启动 Ray 和训练入口​

5.5 监控正确性和性能​

6. 参数概念速查​

6.1 资源参数​

6.2 数据和算法参数​

6.3 权重与精度参数​

7. 常见问题定位​

7.1 Ray 或 SGLang engine 启动失败​

7.2 Rollout 正常但训练不收敛​

7.3 共置模式 OOM​

7.4 多机权重同步失败​

7.5 MUSA 环境参数不识别​

8. 下一步阅读​

这篇文章对您有帮助吗？