Miles：企业级大模型后训练强化学习框架

想象这样一个场景：你的团队训练出了一个性能优异的千亿参数大模型，但用人类反馈微调（RLHF）时，训练动不动就崩溃、推理与训练精度不一致、8 卡机器跑不满 GPU……这些都是大模型后训练 RL 中的真实痛点。Miles 正是为解决这些问题而生——它不是又一个学术 demo，而是一个来自工业界的、生产级的 LLM/VLM 后训练 RL 框架，背后站着 InfiXAI、蚂蚁集团、SGLang RL 团队。

背景：从学术研究到工业落地的鸿沟

强化学习在大模型后训练（Post-Training）中扮演核心角色，从 GPT-4 到 Claude 再到 DeepSeek-R1，几乎所有顶级大模型的最后一步都离不开 RLHF 或 GRPO。然而学术届的 RL 算法（如 PPO）直接搬到千亿参数模型上，往往面临三重困境：

训练-推理不匹配（Train-Inference Mismatch）：训练时用的精度（BF16）和推理时不同（FP8/INT4），导致 loss spike 或模型崩溃，尤其在 MoE 架构上更为突出
扩展性墙：单卡放不下模型，多卡通信开销大，GPU 利用率低，分布式 RL 训练极其复杂
工程碎片化：每换一个模型架构就要改一套适配代码，从 Qwen 到 DeepSeek 再到 GLM，碎片化严重

Miles 起源于对 slime 的深度 fork，由 InfiXAI、蚂蚁集团、SGLang RL 团队联合发起（2025年11月正式发布），目标是打造企业级的高性能 RL 后训练框架。它的核心理念是：把系统层面的底层优化做到极致，让研究者和工程师专注于算法本身。

架构设计：SGLang + Megatron-LM 的深度耦合

Miles 的整体架构可以类比为两个精密齿轮的咬合：Rollout（推理阶段）由 SGLang 驱动，Training（训练阶段）由 Megatron-LM 驱动，中间通过 Ray 进行分布式资源调度。

Miles 架构图

图1：Miles 系统架构，Rollout 层与 Training 层通过 Zero-Copy 权重同步实现高效联动

核心模块包括：

模块	位置	职责
Rollout 层	`miles/rollout/`	推理数据生成，支持 SGLang、Session（多轮对话）、SFT 等多种模式
Training 层	`miles/backends/`	训练后端，支持 Megatron 和 FSDP 两种并行方案
Ray 调度	`miles/ray/`	分布式 GPU 资源编排、Placement Group 管理
Router	`miles/router/`	推理请求路由，支持 MoE R3 路由回放
插件系统	`miles_plugins/`	定制化模型适配（DeepSeek V4、GLM5、Qwen3-Next 等）
Loss Hub	`miles/backends/training_utils/loss_hub/`	GRPO、TIS、MIS 等优势估计和修正算法

关键设计决策：所有 Rollout 数据通过 Ray Actor 在推理集群生成，训练集群通过 Zero-Copy CUDA IPC 同步权重，绕过传统 HTTP/RPC 的序列化开销，权重同步时间减少 50%。

核心技术：解决 MoE + 低精度 RL 的稳定性难题

1. 统一 FP8 端到端流水线

这是 Miles 最核心的创新之一。传统方案中，推理用 FP8 加速，训练用 BF16 保精度——两者精度不一致是 MoE 模型 RL 训练崩溃的根源。Miles 在业界首次实现了端到端的 FP8 采样+训练，统一了 Rollout 和 Training 的量化逻辑，从根本上消除了训练-推理不匹配。2025年11月与 SGLang 联合发布，解决了 Qwen3、DeepSeek-V3 等 MoE 模型 RL 训练的不稳定问题。

2. Rollout Routing Replay（R3）

MoE 模型中，Expert 路由决策在推理和训练阶段可能不一致——推理时某些 Expert 被选中，训练时路由变化导致 KV Cache 与实际计算对不上，引发"训练-推理失配"甚至训练坍塌。R3 机制记录 SGLang 推理时的 Expert 路由决策，在训练时回放这些路由，保证 bit-wise 的一致性。相关论文：arXiv:2510.11370

3. INT4 量化感知训练（QAT）

2026年1月发布的重磅功能。借鉴 Kimi K2-Thinking 报告的思路，实现了完整的 W4A16 INT4 QAT 流水线，使 1TB 规模的模型能够塞进单台 H200 的显存。这不仅降低了硬件门槛，还通过消除跨节点通信瓶颈，将 Rollout 效率提升了一倍。

4. 投机解码 + 在线 SFT Draft Model

Miles 在 RL 中引入了投机解码（Speculative Decoding）——用一个小型的在线 SFT Draft Model 来预测主模型的 token 序列，猜对的 token 直接接受，猜错的再走完整推理。实测 Rollout 速度提升 25%+。与传统投机解码不同，Miles 的 Draft Model 是在 RL 过程中同步更新的，避免了 Policy Drift 问题。

支持的模型：覆盖主流千亿大模型

Miles 对模型的支持非常全面，尤其是国产模型：

DeepSeek 系列：R1、V3、V3.2（支持 MoE + MLA 注意力）
Qwen 系列：Qwen2/2.5/3 全系（含 Qwen3-Next 架构）
GLM 系列：GLM-4.5/4.6/4.7，GLM-5（含 744B-A40B 超大配置）
MiniMax：M2、M2.1
Llama 4：全系支持
Kimi：K2、K2-Thinking、K2.5

每种模型都有对应的预训练脚本存放在 scripts/models/ 目录下，脚本覆盖了从 4B 小模型到 235B-A22B 超大 MoE 模型的完整参数范围。

上手体验：命令行驱动，适合有 ML 经验的团队

Miles 不是一个有 Web UI 的可视化工具，而是一个纯命令行框架。标准的训练启动命令如下：

python train.py \
    --advantage-estimator grpo \
    --model-name qwen3-30b-a3b \
    --hf-checkpoint /path/to/qwen3-30b-a3b-hf \
    --rollout-batch-size 512 \
    --n-samples-per-prompt 8

核心依赖包括：Ray（分布式调度）、SGLang（推理引擎）、Megatron-LM（分布式训练）、FlashAttention-3、DeepGEMM（定制内核）、WandB/TensorBoard（实验追踪）。官方推荐使用 Docker 镜像部署，但也支持从源码安装。

局限与争议

Miles 并非没有缺点：

硬件门槛极高：虽然支持 INT4 QAT 降低显存需求，但完整 RL 训练流程至少需要 8 卡 A100/H100 集群，个人研究者和中小团队难以使用
调试成本高：分布式 RL 训练出问题往往难以定位，框架层面缺少完善的 Debug 工具
SGLang 强耦合：Rollout 层深度绑定 SGLang，若项目需要换推理引擎（如 vLLM），迁移成本较大
文档依赖官方站点：README 本身信息有限，深度使用需要查阅 miles.radixark.com 文档站

行业意义：填补大模型 RL 工业级框架的空白

Miles 的出现代表了 LLM 后训练从"算法研究"向"系统工程"的范式转变。它证明了大模型 RL 的瓶颈不只是算法创新，更是底层系统优化（量化、并行、通信、内存管理）的综合能力。随着 Qwen3、DeepSeek-V3 等国产 MoE 大模型的崛起，Miles 作为首个深度适配这些国产模型的 RL 框架，有着独特的生态位。

项目目前 Star 1549，Fork 254，近半年更新频繁（2025年11月至2026年2月连续发布多个重大功能），是一个活跃度高、背景实力强的企业级开源项目。