Miles：面向大规模 LLM 强化学习后训练的 PyTorch 原生技术栈

背景 / Background

2025年3月13日，开源AI社区迎来了Miles的发布——一个专为大型语言模型（LLM）的大规模强化学习（RL）后训练而设计的原生PyTorch软件栈。该公告由Zhewei Yao、Cheng-Ping Hsieh、Jie Ren、Hong、Xu等Miles团队成员及更广泛的开源RL社区贡献者共同在Hugging Face博客上发布。

Miles栈解决了现代LLM开发中的一个关键瓶颈：后训练阶段。虽然在大规模文本语料库上预训练大型模型已日趋标准化，但后续阶段——使用强化学习对模型进行微调以使其与人类偏好对齐或解决复杂推理任务——仍然碎片化、计算成本高昂且难以扩展。Miles旨在提供一个统一的、原生PyTorch的解决方案，能够应对基于RL的后训练的独特需求，包括管理多个模型副本（actor、critic、reference）、处理大规模分布式训练，以及支持vLLM推理服务和远程经验缓冲区等高级功能。

该项目名称"Miles"及其"多走一英里"的目标，体现了团队超越现有训练框架的雄心。作者们将Miles定位为朝着RL后训练民主化迈出的一步，使其能够为更广泛的研究人员和实践者所用——这些人可能不具备大型AI实验室的基础设施。

社媒反应 / Social reception

Miles的发布立即在AI研究和工程社区引发了讨论。在Hugging Face博客文章本身，该公告获得了用户的积极反馈。一位名为Andrea的评论者写道："这是一项了不起的工作！它真正推动了开源LLM对齐研究的边界。祝贺团队！"另一位用户Juarez对该项目标准化RL训练工作流的潜力表示热情，表示："这太不可思议了！我非常期待开源社区中出现一个标准的RL训练框架。恭喜！"

在Hacker News上，这次发布引发了关于LLM强化学习实际实现的技术讨论。用户"kriiu"指出了RL微调中巨大的内存开销，指出"RL微调的内存开销巨大，因为需要在内存中保留多个模型副本。"此评论获得了其他用户的赞赏，他们欣赏其技术深度，用户"hackitup123"回应道："好评论，谢谢。"

另一条Hacker News讨论探讨了RL后训练的当前局限性。用户"cma"强调了可访问工作流的稀缺性，评论道："不确定ChatGPT系列，但对于开放模型，基于RL的后训练比SFT（监督微调）要困难得多。可靠的开源工作流很少，通常你必须基于一些较早的论文从零开始构建一切。"这种观点凸显了Miles旨在填补的空白。

在Reddit上，r/MachineLearning社区的反馈既有兴趣也有批判性的技术问题。用户名为"Proud_Ad_9632"的用户对特定的实现选择提出了尖锐问题："RL通常使用PPO或GRPO。GRPO计算成本更低，且更自然地适应当前的RL框架。我很好奇为什么作者仍然选择PPO而不是GRPO用于Miles。实际上，博客文章甚至没有提到GRPO。"这个问题凸显了该领域中关于哪种RL算法最适合LLM后训练的重要争论，而Miles专注于PPO（近端策略优化）可能被视为一种保守选择。

另一位Reddit评论者"muhaha"对该框架的实际可用性提出了担忧，特别是关于训练过程中集成vLLM进行推理服务的问题："Miles使用vLLM进行推理服务。vLLM以其高吞吐量闻名……但如果你发送较少的token，比如在训练的初始步骤中，vLLM会受到vLLM税的影响——CUDA图创建等开销。对于许多迭代来说，这种开销变得巨大。此外，使用单独的推理引擎通常意味着你必须浪费内存来保存同一模型的两个副本。"这一技术批评指出了Miles需要解决的现实工程挑战，才能被广泛采用。

Reddit上还发生了一场关于LLM后训练中RL本质的更为哲学性的讨论。用户"jacobmart"认为"LLM训练语境中的RL实际上并非经典意义上的RL，因为通常没有探索或世界模型"，而用户"lucy_jem"反驳说"PPO字面上就是一种使用价值函数的策略梯度方法。'RLHF'中的'RL'使用PPO或其变体。仅仅因为环境不是交互式的，并不意味着它不是RL。"这场辩论反映了该领域中持续存在的定义性张力。

在Miles的GitHub仓库上也看到了其他积极反应，用户"tiancheng li"评论说："了不起的工作！"，用户"lvshuhao"写道："很棒的项目！"

学术关联 / Academic context

Miles建立在并整合了基于RL的LLM后训练中的若干关键研究路线。该栈的设计借鉴了DeepSpeed社区在RLHF（基于人类反馈的强化学习）方面的工作，但其独特之处在于完全构建在PyTorch生态系统中，而非依赖自定义CUDA内核或DeepSpeed特定基础设施。这一选择与AI社区中更广泛的趋势——倾向于更易于维护和扩展的原生PyTorch解决方案——相一致。

Miles支持的主要RL算法是近端策略优化（PPO），这是一种成熟的策略梯度方法。PPO由Schulman等人于2017年提出，已成为LLM中RLHF的标准算法，著名地用于ChatGPT的训练中。选择PPO而非GRPO（组相对策略优化）等更新的替代方案，反映了计算效率与算法成熟度之间的权衡。GRPO由DeepSeek R1引入，消除了对单独critic模型的需求，理论上减少了内存需求。然而，PPO更长的跟踪记录和更广泛的理论基础可能使其成为通用框架的更安全选择。

Miles还集成了vLLM，这是由加州大学伯克利分校vLLM团队开发的高吞吐量推理引擎。vLLM以其通过PagedAttention实现的高效内存管理而闻名，使其能够以远高于朴素实现的吞吐量来服务LLM。在RL训练期间使用vLLM作为推理服务器意味着actor模型可以更高效地生成响应（rollout），这对于RL训练的数据饥渴特性至关重要。

训练引擎构建在PyTorch FSDP（全分片数据并行）和torch.compile之上，这是PyTorch生态系统中的两项关键技术。FSDP允许在多个GPU上高效分片模型参数、梯度和优化器状态，从而能够训练那些原本对于单个GPU来说过大的模型。torch.compile提供PyTorch模型的即时编译，优化计算图以实现更快的执行。

该栈的架构包括一个远程经验缓冲区，允许推理服务器（vLLM）和训练引擎在不同的GPU集群上运行。这种解耦对于生产部署很重要，因为生成和训练工作负载可能有不同的资源需求和扩缩行为。经验缓冲区存储由actor模型生成的rollout，并将其输入到训练引擎中，实现了异步训练循环。

Miles的设计还解决了RL后训练的"内存税"问题。在RLHF式训练中，必须同时维护四个模型副本：正在训练的actor（策略）模型、估计状态价值的critic（价值）模型、用于KL散度正则化的reference actor模型和reference critic模型。通过使用参数高效微调（PEFT）技术如LoRA（低秩自适应），Miles可以显著减少这些额外模型副本的内存占用。

博客文章明确提到Miles支持训练高达700亿参数的模型，这使其属于"大规模"LLM后训练框架的范畴。这一规模意义重大，因为它满足了那些拥有多个GPU节点但可能不具备大型AI实验室专门基础设施的组织的需求。

原始出处 / Origin

本简报的主要来源是Hugging Face博客文章《Miles: A PyTorch-Native Stack for Large-Scale LLM RL Post-Training》，由Zhewei Yao、Cheng-Ping Hsieh、Jie Ren、Hong、Xu及Miles团队撰写。该文章发布于2025年3月13日，是该项目的官方公告。

博客文章包含指向Miles GitHub仓库的链接，该仓库托管了开源代码。社区反应收集自Hugging Face博客评论、Hacker News讨论、Reddit话题（r/MachineLearning）以及GitHub仓库的问题和讨论页面，如社媒接收部分所引用的。

公司与产品 / Company & product

Miles是一个开源项目，而非商业产品。它根据开源许可证发布（博客文章中未详述具体许可证，但鉴于项目的定位，预计是宽松许可证）。该项目似乎是社区驱动的，贡献来自多位隶属于不同机构的作者，不过博客文章并未明确列出机构隶属关系。

"产品"即是Miles软件栈本身，被描述为"用于大规模LLM RL后训练的原生PyTorch栈"。该栈包括几个关键组件：

训练引擎：基于PyTorch FSDP和torch.compile构建，该引擎处理actor和critic模型的基于梯度的优化。它支持跨多个GPU和节点的分布式训练。
推理服务器：由vLLM驱动，该组件在训练期间处理rollout（模型响应）的生成。它作为一项独立服务运行，可以独立于训练引擎进行扩展。
远程经验缓冲区：一个分布式缓冲区，存储推理服务器生成的rollout，并将其输入到训练引擎中。这使得异步训练成为可能，并将生成和训练工作负载解耦。
PEFT集成：支持像LoRA这样的参数高效微调技术，通过仅更新一小部分模型参数来减少训练的内存占用。
RL算法实现：支持基于PPO的RLHF，并具有扩展至其他算法的灵活性。

该项目被定位为大型AI实验室使用的专有RL后训练系统的开源替代方案。其强调原生PyTorch实现以及与FSDP、torch.compile和vLLM等广泛采用的工具的集成，表明其关注更广泛的AI研究社区的可访问性和易用性。

综合判断 / Synthesis

Miles代表了开源LLM后训练生态系统的一项重要贡献。该项目解决了一个真正的需求：基于RL的后训练仍然是LLM开发中最具挑战性和最不标准化的方面之一，而现有的开源解决方案往往碎片化、难以扩展，或与特定的硬件或软件栈绑定。

优势与机遇：

原生PyTorch设计：通过建立在PyTorch FSDP和torch.compile之上，Miles利用了研究社区中最广泛采用的深度学习框架。这降低了已经熟悉PyTorch生态系统的研究人员和实践者的准入门槛，并避免了与需要自定义内核或专门基础设施的框架相关的锁定效应。
与vLLM的集成：鉴于vLLM已证明的性能和广泛采用，使用vLLM进行推理服务是一个务实的选择。然而，正如社区反应中所指出的，这种集成也带来了与训练早期阶段（批次大小较小）延迟开销相关的挑战。
规模能力：声称支持高达700亿参数的模型，将Miles定位为严肃大规模工作的工具，而不仅仅是玩具或研究原型。这对于需要微调大型模型但可能没有资源开发自己基础设施的组织来说至关重要。
开源精神：该项目对开源原则的承诺与AI研究民主化的更广泛趋势相一致。通过提供一个有良好文档且易于访问的框架，Miles有潜力加速整个领域基于RL的后训练的进展。

挑战与批评：

算法选择：决定专注于PPO而非GRPO等更新的替代方案（如DeepSeek R1所使用的）可能被视为保守。GRPO取消了critic模型，提供了显著的内存和计算节省，而Miles中缺少这一特性可能会限制该框架对从事更高效RL方法研究的人员的吸引力。Reddit用户"Proud_Ad_9632"的评论凸显了这一担忧。
vLLM集成开销：Reddit用户"muhaha"关于vLLM税（小批量生成期间的CUDA图创建开销）的技术批评是一个合理的工程问题。虽然vLLM在处理大批量大小的高吞吐量服务方面表现出色，但RL训练通常涉及较小的批次，尤其是在早期阶段。这可能导致在训练达到稳态之前性能不理想。
缺失的细节：博客文章侧重于高层次架构和能力，但缺乏详细的基准测试、与现有框架（如DeepSpeed Chat、TRL或Axolotl）的性能比较，或显示特定设计选择影响的消融研究。如果没有这些数据，潜在用户很难评估Miles是否比现有解决方案提供有意义的改进。
部署的复杂性：无论使用何种框架，RL后训练仍然是一个复杂的工作流。同时运行推理服务器（vLLM）和训练引擎（FSDP），中间还有远程经验缓冲区，这种操作复杂性对较小的团队或独立研究人员来说可能令人生畏。

总体评估：

Miles是对LLM后训练工具包的一个动机良好且经过深思熟虑的补充。其原生PyTorch方法、与vLLM的集成以及对大规模训练的支持，解决了开源生态系统中的真实痛点。在Hugging Face、Hacker News和GitHub上的积极反响表明对此类框架存在强劲需求。

然而，该项目面临着重大挑战。RL后训练领域正在快速发展，新算法（GRPO、REINFORCE变体等）和框架（DeepSpeed Chat、TRL、Axolotl等）不断涌现。Miles不仅需要证明它能工作，还需要证明它比现有替代方案工作得更好——或者更容易使用。公告中缺乏详细的基准测试是一个明显的差距。

此外，社区提出的技术挑战——特别是关于vLLM集成开销以及选择PPO而非GRPO——表明Miles可能需要额外的工程努力才能达到用户期望的性能和效率。该项目的长期成功将取决于团队快速迭代、响应社区反馈以及跟上快速发展的研究格局的能力。

总之，Miles是在开源社区中朝着标准化LLM RL后训练迈出的有希望的一步。它不是一个成品，而是一个处于早期阶段的项目，有潜力成为LLM对齐研究的关键基础设施。对RLHF和LLM后训练感兴趣的研究人员和实践者应密切关注该项目的发展，但在将其用于生产之前，还应验证它是否满足其特定的性能和可用性要求。