RadixArk Miles 达到 v0.1，但生产级 RL 仍有待验证

RadixArk Miles 于 2026 年 8 月 18 日达到 0.1 版本，距离首次公开发布已有九个月。这一里程碑让一个尚年轻的代码库发展为覆盖强化学习、智能体训练和分布式模型后训练的更完整系统。

这一区别很重要，因为启动一项 RL 实验，比让它在多台机器上始终正确运行要容易得多。轨迹生成引擎负责产生经验，训练器更新模型，而新权重必须回传至推理工作节点，且不能破坏整个流程。

该项目近期在一份 GitHub Trending 热榜快照中位列第 14 名。不过，这一聚合器未提供经验证的发布时间，因此该排名并非事件本身。已确认的消息是 RadixArk 发布了 v0.1，以及其关于生产环境能力的详细主张。

Miles 进入了一个拥挤的开源训练系统赛道，其中包括它所演化而来的 slime 框架。因此，它真正面对的竞争并非一个代码库对抗另一个代码库，而是开放、可审查的基础设施与先进 AI 团队仍在自建的内部技术栈之间的较量。

RadixArk Miles v0.1 是已确认事件

重要的变化并非短暂的热门榜单排名。RadixArk 已为 Miles 发布了带版本号的版本，并附带了面向生产环境的叙事。

RadixArk 及其生态合作伙伴于 2026 年 8 月 18 日发布了 Miles v0.1 release。他们将其描述为面向前沿模型后训练的全栈系统。这一描述仍属于项目方主张，而非独立认证。

这一日期消除了热门榜单信息流中的不确定性。该代码库并非在 9 月突然出现。Miles 最初于 2025 年 11 月 19 日公布，随后持续公开开发，直至达到 v0.1 这一里程碑。

original Miles release 将该项目定位为 slime 的企业级扩展。Slime 强调小巧、可修改的架构。Miles 保留了这一基础，同时增加了支持更大规模混合专家模型和生产工作负载的基础设施。

混合专家模型，即 MoE，会为每个 token 激活选定的专家组件，而非动用全部参数。这种设计可以提升计算效率，但也让路由、训练一致性和分布式执行变得更加复杂。

0.1 版本试图覆盖完整的后训练闭环。SGLang 生成轨迹，NVIDIA Megatron-LM 或 PyTorch FSDP 训练策略模型，而同步层将更新后的权重回传给轨迹生成工作节点。

这一范围比新增一种算法实现更具意义。组织已经能够找到 PPO、GRPO、监督微调及相关方法的代码。当这些方法面对长时间智能体会话、持续变化的策略、硬件故障和不均衡工作负载时，真正困难的工作才刚刚开始。

RadixArk 表示，Miles 支持同步和完全异步的强化学习。在异步路径中，推理工作节点持续生成样本，而训练器消费已完成的样本组并更新模型。

该项目还整合了智能体环境和沙箱提供商。这些连接让训练任务能够运行编程或计算机使用任务、记录生成的轨迹，并将验证器评分作为奖励回传。

公开的 Miles repository 提供了支撑这些主张的代码、配方、测试、文档、问题记录和开发历史。其 Apache 2.0 许可证赋予团队广泛的权利，以审查和改造实现。

这种开放性使技术审查成为可能。但它并不保证其他组织能够在没有相当硬件、网络和运维专业能力的情况下复现 RadixArk 最大规模的运行成果。

因此，0.1 版本应被视为成熟度标志。RadixArk 已整合其架构、记录参考工作负载，并宣布了生产目标。更广泛的部署证据仍将是下一项考验。

为什么智能体 RL 会成为系统问题

智能体训练将普通模型后训练转化为一项协调问题，涉及推理、工具、沙箱、奖励和持续变化的权重。

一次简单的语言模型轨迹生成，可以根据一个提示生成一个回答。一次智能体轨迹生成则可能打开终端、检查文件、调用工具、从错误中恢复，并跨越多个回合持续执行。

这些轨迹很少会同时结束。一项编程任务可能很快失败，另一项则可能花费数分钟执行命令。同步训练器在推进前必须等待最慢的成员，导致昂贵的硬件处于闲置状态。

Miles 通过样本级调度来解决这种不平衡。当一条轨迹结束时，另一条轨迹可以立即占用可用槽位。已完成的轨迹组会进入供训练器使用的有界缓冲区。

这一设计将轨迹生成节奏与优化器节奏分离。它也带来了一个棘手问题：在更新后的策略使其不再适合训练之前，一条经验样本最多能“过时”多久？

在异步强化学习中，策略滞后衡量生成样本的模型与当前训练策略之间的差距。更高并发度可以提高硬件利用率，但过度滞后可能削弱算法背后的 on-policy 假设。

Miles 提供了接受、重试、丢弃或拒绝过期样本的控制选项。这种灵活性有助于研究人员定义自己的边界，但也将一项重要的正确性决策交给了操作人员。

智能体训练还带来另一种不匹配。工具调用和聊天模板可能会改变消息在各回合之间转换为 token 的方式。训练器随后接收到的序列，可能与推理期间使用的序列略有不同。

Miles 将其称为 Token-In-Token-Out，即 TITO。会话服务器在仅添加新附加消息的同时，保留已生成 token 的标识符。损失掩码会排除并非由模型生成的 token。

这一机制针对一种微妙的故障模式。如果轨迹生成与训练对 token、概率或专家路由存在分歧，优化器学习的将是一次重构后的交互，而非实际经验。

代码库公开的 TITO roadmap 也揭示了当前支持的边界。指定模型家族需要明确配置，系统无法自动检测每一种模板。

这一细节是一个活跃工程项目的健康证据。它表明 token 保真度依赖于模型特定的约定、测试和集成。该功能并非一个能让所有外部智能体框架自动正确运行的通用开关。

Miles 还支持用于编程和计算机使用回合的隔离环境。每项任务都可以获得一个独立沙箱，包含各自的文件、进程和验证器。

隔离之所以重要，是因为一次失败的回合不应污染其他回合。但它也增加了编排工作，尤其是在数千个环境必须以可预测方式启动、执行、报告奖励并终止时。

这些问题解释了为何 v0.1 版本在此时发布。AI 开发正从单次响应调优转向在更长时间内行动的智能体。训练基础设施必须捕捉这些行动，同时不能丢失产生它们的精确上下文。

评估该项目的开发者应关注这一系统层面。算法支持固然必要，但可复现的轨迹、调度行为和故障恢复能力，将决定一次长期运行能否产出有价值的证据。

记录自身实验的团队，同样需要可检索的配置、故障和评估结果记录。结构化的工程知识库可以在训练框架之外保留这类运维上下文。

核心机制连接轨迹生成、训练与权重更新

RadixArk Miles 押注于一个协调统一的闭环，以减少独立推理与训练技术栈带来的不匹配。

该闭环始于 SGLang，这是一款为高吞吐量模型服务设计的开源推理引擎。Miles 使用它生成长篇、多回合轨迹，并在智能体会话之间复用缓存前缀。

前缀缓存会存储模型已处理文本中可复用的注意力状态。让后续回合继续由同一合适的工作节点处理，可以避免重复计算共享的对话历史。

Miles 会将新会话路由至负载较低的工作节点，同时尽量保留这种缓存局部性。这一方法旨在解决长尾问题，即少数耗时很长的任务消耗了不成比例的容量。

随后，训练器使用 Megatron-LM 或 FSDP 处理已完成的样本组。Megatron-LM 支持多种模型并行形式，而 FSDP 会在数据并行工作节点之间分片模型状态。

同时提供两条路径扩大了潜在用户群。拥有既有 Megatron 部署的团队可以使用其分布式控制能力。更接近 Hugging Face 模型实现的团队则可使用 FSDP，而无需经历同样的转换流程。

这一抽象并未消除后端差异。Megatron 配方可以在张量、流水线、上下文和专家维度之间拆分工作。FSDP 路径使用不同的分发模型，并且可能需要进行架构适配。

训练完成后，Miles 必须将变化后的权重移回轨迹生成集群。当模型横跨许多加速器、且推理使用不同的分片布局时，这一步可能主导迭代时间。

对于直接连接的集群，该项目提供基于 RDMA 的点对点传输。远程直接内存访问使机器能够在较少 CPU 参与的情况下，将数据写入远程内存。

RadixArk 报告称，这一路径将一次 Kimi-K2 万亿参数权重更新从 53.3 秒降至 7.2 秒。这一结果来自项目自身的参考工作负载，仍需在其他网络布局下复现。

在无法直接使用 NCCL 或 RDMA 连接时，Miles 还提供磁盘增量更新。系统只发布策略中发生变化的部分，而不是在每一步后发送完整检查点。

在一次报告中的 GLM-4.7-Flash 运行中，RadixArk 表示，这将每次载荷从 62.4 GB 降至 0.69 GB 至 0.83 GB 之间。相关的生成暂停时间保持在三至五秒之间。

这些数据描述的是不同部署路径，而非一项通用性能承诺。点对点传输依赖高速网络和兼容的拓扑结构。磁盘增量则取决于不同策略版本之间有多少字节发生变化。

低精度计算又增加了一层复杂性。Miles 包含在受支持模型上使用 FP8、MXFP8、NVFP4 和 INT4 量化感知训练的配方。

量化使用更少的比特表示数值，以降低内存使用并提高吞吐量。不过，推理与训练两端必须采用兼容规则，否则它们的数值差异可能改变策略行为。

对于 MoE 模型，这一问题会更加突出。微小的数值变化就可能为一个 token 选择不同的专家，从而改变前向计算以及接收梯度的参数。

Miles 通过名为 R3 的 Rollout Routing Replay 来应对这一问题。它会记录推理期间的专家路由选择，并在训练器的前向传播过程中重放这些选择。

这是该项目核心机制最清晰的体现。该框架并非只是连接彼此独立的工具，而是试图在完整的 RL 循环中保留所做出的决策。

同一原则也支撑着 on-policy 蒸馏和 zero-KL 对齐。On-policy 蒸馏使用在学生模型当前行为下收集的教师信号来训练学生模型。Zero-KL 对齐则旨在让 rollout 与训练在数值上保持一致。

每项功能都在解决一种偏差形式。它们共同让 Miles 不只是一组训练脚本，也带来了更大的正确性保障范围——需要跨越不同模型家族和硬件代际持续保持正确。

开放基础设施正在挑战私有训练栈

Miles 正在对仍将强化学习基础设施视为内部优势、认为每个严肃模型团队都必须自行重建的组织施加压力。

RadixArk 的立场很直接：开放推理通过 SGLang 等共享系统得以进步，而后训练基础设施也应走上类似道路。

该公司于 2026 年 5 月 5 日正式公开亮相，并宣布获得 1 亿美元种子轮融资，投后估值为 4 亿美元。Accel 领投，Spark Capital 共同领投。

其开放基础设施战略将 SGLang 和 Miles 列为两大基础。SGLang 负责推理，而 Miles 覆盖强化学习和模型后训练。

这笔融资改变了该代码仓库的背景。Miles 不再只是一个志愿者实验，而是一家获得融资、计划围绕开放基础设施打造托管产品的公司的战略资产。

因此，其主要竞争对手是私有 RL 栈。前沿实验室通常会搭建由 rollout 服务、训练器、数据缓冲区、评估器和 checkpoint 系统组成的内部组合。

这些内部平台可能凝结了多年的运营经验，包含公共代码仓库中无法获得的专有调度器、优化内核、专用可观测性能力和恢复流程。

Miles 试图通过公开一个集成式基线来缩小这一差距。创业团队可以从经过维护的配方和扩展点起步，而不必从头连接每一个子系统。

这并不会消除集成工作。团队仍需准备环境、奖励、数据集、模型 checkpoint、网络、存储和评估标准。

差别在于工程工作的起点。没有集成框架时，团队必须先搭建基础循环；有了 Miles，则可以直接测试其提供的循环是否适配自身工作负载。

该项目也在间接与更简单的研究框架竞争。Slime 仍是重要参考，因为 Miles 源自其设计，并称许多改动会回流至上游。

这种关系使“赢家与输家”的叙事变得复杂。重视透明性和快速修改的研究，可能仍更适合小型框架；而需要更多内置运营控制能力的团队，则可能需要更大的系统。

Miles 必须同时保留这两种特质，才能证明其定位合理。即使框架将自身描述为模块化，过多的基础设施也可能让调试更加困难。

该公司强调，为 rollout、奖励、损失、过滤器和数据源提供了类型化接口与可替换组件。只有当用户能够理解跨越这些边界的故障时，这些扩展点才有意义。

商业激励同样值得关注。当开放项目被广泛采用时，RadixArk 将从围绕这些项目发展的托管基础设施和支持服务中获益。

这一模式在开源基础设施领域很常见。它可以为维护和硬件验证提供资金，也可能引发哪些能力仍可独立轻松运作的紧张关系。

Apache 2.0 许可证缓解了一部分锁定担忧，因为团队可以 fork 并修改代码。但部署服务、专有工具或专业经验仍可能形成运营依赖。

对采购方而言，关键问题不是 Miles 是否开源，而是其他组织能否在不依赖 RadixArk 私有知识的情况下可靠运行它。

对开发者而言，该代码仓库作为 RL 系统问题的一张可读地图，已经提供了即时价值。其架构展示了 rollout 保真度、调度、精度和同步如何相互作用。

对 AI 产品团队而言，这类基础设施会影响实验速度。更快的循环意味着在相同硬件预算内，可以测试更多 agent 环境、奖励设计和数据策略。

参考运行结果无法证明什么

RadixArk 发布了异常具体的系统声明，但大多数性能证据仍来自构建该框架的团队本身。

旗舰 v0.1 示例在 64 块 NVIDIA GB300 GPU 上，对 GLM-5.2 744B-A40B 模型进行了终端使用任务训练。RadixArk 将其中 32 块 GPU 分配给 rollout，另外 32 块用于训练。

参考配置使用了 65,000 tokens 的最大序列长度和 64 的 batch size。该公司报告称，系统完成了 100 个稳定的 rollout step，每个训练 step 耗时约 4.5 分钟。

该公司还报告了平均 1.7 steps 的 policy lag，以及 96% 的 prefix-cache 命中率。据称，内存优化在该工作负载下为每块 GPU 节省了超过 30 GB 的 HBM。

这些数据很有价值，因为它们为评估者提供了明确的目标。但它们仍只是针对一个模型、一个集群、一个软件版本、一种任务分布和一套调优配置的测量结果。

一次 100-step 运行证明系统可以在该设置下运作，但不能证明其在数千次更新、间歇性故障或不断变化的环境负载下具备长期可靠性。

在更小的集群上，性能表现也可能不同。针对数十块新型加速器优化的功能，在 8 块 GPU 或混合硬件上可能只会增加复杂性，而无法带来相同收益。

该项目的异步设计带来了不可避免的权衡。让 rollout 和训练持续忙碌可以提高利用率，但较旧的轨迹可能会与当前策略产生更大的偏离。

RadixArk 提供了 staleness 控制，并在示例中报告了 lag。独立用户仍需判断，这些控制手段能否为其算法和奖励分布保留学习质量。

低精度声明也应接受同样审视。RadixArk 表示，其奖励曲线与 BF16 基线高度接近，同时减少了 rollout 时间。但这一结果并不能自动迁移至所有模型、优化器或任务。

量化训练可能对激活分布和特定层较为敏感。Miles 允许选定组件保持 BF16，但如何选择这些例外需要针对模型进行验证。

模型支持也是一个不断变化的目标。该代码仓库列出了许多 dense、MoE、多模态和 agentic 配方。列出某个配方，并不意味着每种 backend 与精度组合都获得同等测试。

公开 issue tracker 让这种不确定性变得可见。公开报告涵盖同步行为、配置语义、LoRA 细节、路由替代方案，以及对更多模态的支持。

这些活动并不意味着 Miles 异常缺陷严重。分布式训练项目通常都会暴露复杂的故障模式。但这确实表明，“production-ready”这一说法应针对每个采购方的具体要求接受检验。

容错能力仍尤其重要。当一个 worker 失败、传输停滞或 checkpoint 失去一致性时，集群规模的运行可能损失数小时。

最初的 2025 年路线图明确将围绕 GPU 故障提升弹性列为未来工作。v0.1 加入了更多运营机制，但用户仍应测试恢复能力，而不应仅从成功运行中推断其可靠性。

安全性也不仅限于训练器。Agentic 环境会执行模型生成的操作，其中有时包括 shell 命令和网络请求。

全新的 sandbox 可以减少跨 episode 污染，但运营方仍必须审查镜像来源、凭据、网络边界、日志和保留的产物。训练框架无法定义每个组织的威胁模型。

正确的结论应当审慎。Miles 已超越最小化演示，其参考运行在技术上具有意义。广泛的生产成熟度仍需要独立复现和更长时间的运营记录。

三个信号将决定 RadixArk Miles 能否长久

下一阶段取决于可复现性、故障恢复能力，以及在已与 RadixArk 或 SGLang 有关联的团队之外获得采用。

第一个信号是对大型参考工作负载的独立复现。研究人员不需要一套完全相同的 64-GPU 集群，但应发布可比较的利用率、policy-lag 和收敛结果。

成功复现将强化 RadixArk 关于其协调机制具有普适性的主张。若出现无法解释的巨大差异，则可能表明私有调优或特殊拓扑在已发布性能中占据了更大作用。

第二个信号是长期运行中的故障恢复证据。用户应关注涉及中断 worker、停滞的推理引擎、受损环境和 checkpoint 恢复的文档化测试。

可靠恢复比另一张峰值吞吐量图表更能有力支撑“生产级”标签。反复出现的同步或恢复失败，则会削弱在昂贵、无人值守运行中使用 Miles 的理由。

第三个信号是未参与构建或发布该框架的团队采用它。独立案例研究应说明模型规模、硬件、任务类型、所做修改，以及遇到的运营问题。

Logo 和用户评价可提供有用线索，但详细报告更具说服力。最有力的证据将展示 Miles 替代了什么、仍需进行哪些工程工作，以及团队节省了多少时间。

代码仓库活动也将为这三个信号提供背景。维护者需要在支持新模型、精度、硬件和 agent 环境的同时，关闭正确性问题。

这项工作会产生一种常见的开源张力：快速支持能够吸引用户，而过度扩展则会增加在难以测试的组合中发生回归的风险。

Miles 最持久的形态，是定义一个经过测试的核心，并清晰说明实验性边界。这样，用户便可区分获支持的生产路径与前景可期的扩展功能。

RadixArk 还需要证明社区贡献能够影响路线图。一个与单一公司优先事项紧密绑定的代码仓库，可能仍然开源，却会变得难以由外部人士推动。

对较小团队来说，眼下的决策不需要接受每一项规模声明。他们可以针对现有工作流，测试一个受支持的模型、一个环境和一个 backend。

这种评估不应只衡量每秒 tokens。团队还应记录失败 episode、陈旧样本率、奖励可复现性、checkpoint 恢复能力，以及诊断问题所需的投入。

目前的结论是，RadixArk Miles 已成为一次严肃的开放尝试，目标是实现生产规模的 agent 训练。值得追踪的事件是其 8 月发布的 v0.1，而不是一个没有日期的热门排名。

接下来的证明将来自用户。独立团队能否复现报告中的行为、恢复失败的运行，并在没有隐藏运营知识的情况下扩展系统？

考虑采用 RadixArk Miles 的团队，应先从范围有限的工作负载入手，并公开发布测试结果。比较同步与异步运行，检查 token 保真度，并在扩大规模前测试恢复能力。记录每一次配置变更和每个未能成立的假设。这些证据将比单纯的仓库热度更重要。若不同模型和集群上的结果趋于一致，Miles 有望成为开放式后训练的共享基础。如果结果仍难以复现，该项目依然会是有价值的系统参考，但尚不足以取代私有基础设施。