CMU、密歇根大学、UC Berkeley联手：让AI强化学习训练不再"一个脑袋管所有事"

这项由卡内基梅隆大学、密歇根大学、加州大学伯克利分校和Meta联合开展的研究，以预印本形式发布于2026年5月，论文编号为arXiv:2605.15565，题为"AstraFlow: Dataflow-Oriented Reinforcement Learning for Agentic LLMs"。有兴趣深入了解的读者可通过该编号在arXiv平台查询完整论文。

把AI训练系统比作一家餐厅——厨房里有一个总厨（训练器），他一边指挥采购食材（生成数据），一边盯着炉火（模型训练），还要安排传菜员（权重同步），所有事情都围绕着他转。这种模式在只做一道菜的小馆子里还行，但如果突然要同时开多个窗口、用不同设备、在全球各地厨房协作完成一桌宴席，这位总厨就会手忙脚乱、顾此失彼。

大型语言模型的强化学习训练，正面临着类似困境。这类训练被称为"agentic RL"，也就是让AI学会像真正的助手一样思考、使用工具、多步推理。研究团队发现，现有的训练系统几乎都把"训练器"当作整个系统的控制中枢，所有其他环节都必须听命于它。这种设计在单一任务、单一模型的场景下还说得过去，但一旦要训练多个相互协作的AI模型，或者要在地球不同角落的服务器上同时工作，整个架构就会变得极为脆弱且难以扩展。

AstraFlow的核心思路，是把这家"总厨制餐厅"改造成一套现代化的"中央配餐系统"：不再依赖一个人统管一切，而是让采购、烹饪和配送各自运转，通过一条标准化的传送带（数据流层）协调彼此，任何一个环节都可以独立替换或扩充，而不会牵一发动全身。

一、为什么现有系统都在"一脑袋管所有事"

要理解AstraFlow解决了什么问题，先得搞清楚当前主流训练系统的架构方式。在强化学习训练大型语言模型的过程中，通常有两个主要步骤交替进行。第一步是"推演"，也就是让AI模型根据当前的知识生成大量回答（称为轨迹），同时评估这些回答的好坏。第二步是"训练"，把这些评估结果喂给模型，让它调整自己，变得更聪明。

现有系统大体分为两类。一类是"同地同步"系统，推演和训练用同一批GPU，交替进行，推演时训练停，训练时推演停。这种方式简单直接，但有个大问题：AI生成回答的时间长短很不均匀——有时候几秒就搞定，有时候因为题目复杂要等很久。在那些"等待"的时间里，昂贵的训练GPU就在闲置，白白浪费。另一类是"分离"系统，把推演和训练放到不同的GPU组上，两边可以同时运行，解决了GPU闲置的问题。但分离之后，调度、资源分配和数据同步变得更复杂了。

然而，不管是哪种架构，它们都有一个共同的根本缺陷：训练器仍然是控制中枢。推演什么时候开始、数据怎么筛选、权重（模型的"知识"）什么时候同步给推演端——这一切都由训练器说了算。研究团队将这称为"trainer-centered control"（以训练器为中心的控制），并指出这正是阻碍系统扩展性和灵活性的根本原因。

举个具体的场景来说明这有多棘手：假设你想训练一个由"解题AI"和"验证AI"组成的协作系统，解题AI出答案，验证AI审查答案的对错，两者都在被不断训练和改进。在现有的"训练器中心"架构下，要实现这样的多模型协作，需要大量专门的系统改造——因为原来的设计只考虑了"一个训练器管一个模型"的情况。事实上，目前能支持这种多模型协作训练的系统极为稀少。

研究团队整理了一张对比表，将AstraFlow与AReaL、SLIME、verl、RLBoost、Dr.MAS和prime-rl等主流系统进行比较，涵盖七个维度：多模型协作训练、可替换的训练器和推演服务、模块化数据算法接口、完全异步训练、推演-训练分离架构、运行时弹性扩缩容、跨地域/异构推演。AstraFlow是唯一在所有七个维度都获得完整支持的系统，其他系统要么缺少某几项，要么只有部分支持。

二、AstraFlow：把"总厨制"变成"传送带制"

AstraFlow的整体设计由三个相互独立又通过接口连接的组件构成：数据流层、推演即服务（RaaS），以及训练器。用餐厅的比喻来说，数据流层是那条标准化传送带，RaaS是分布在各地的独立厨房，训练器是负责更新菜谱的研发部门。三者各自运转，只通过传送带上的标准托盘（数据和权重接口）交流。

数据流层是这套系统的协调核心，但它的协调方式与传统系统截然不同——它不主动发号施令，而是通过"数据的有无和流向"来隐性协调各方。推演端（RaaS节点）自己从传送带上取任务、处理完成后把结果放回传送带；训练器自己从传送带上取数据批次、训练完更新菜谱。两边都在独立运转，传送带只负责确保托盘里的东西流向正确的地方。

在这个架构里，数据流层还承担了"数据算法接口"的角色。所谓数据算法，是指在强化学习过程中决定"用哪些数据"、"什么时候用"、"用多少"的各种策略。比如，某些AI生成的回答对训练没有任何帮助（既不特别好也不特别坏，模型从中学不到任何东西），动态采样算法可以在送去训练之前把这些无用数据过滤掉；GRESO算法可以在让AI生成回答之前就判断哪些题目值得生成、哪些可以暂时跳过；重放缓冲（buffer replay）算法可以把有价值的历史数据反复利用，而不是用一次就扔掉。在AstraFlow中，这些算法都被实现为"数据流策略"——就像传送带上的分拣机器，不需要改动厨房或研发部门的任何东西，直接在传送带上加装一个新模块就行。

推演即服务（RaaS）的设计思想是把"AI生成回答"这件事变成一个标准化的对外服务。每个RaaS节点只需要做三件事：从数据流层接收任务，执行对应的推演流程，把结果返回数据流层，并按需从权重管理器同步最新的模型参数。RaaS节点不需要知道数据是怎么筛选的，不需要知道训练器在做什么，也不需要知道自己的输出最终会被哪个训练器用到。这种彻底的解耦，使得任何符合RaaS接口规范的推演引擎都可以直接插入系统——就像插座和插头的标准化，让不同品牌的电器都能在同一个插座上使用。

更重要的是，RaaS的弹性特征。增加推演容量，只需要启动更多RaaS节点，让它们连接到同一个数据流层和权重管理器即可。撤掉某个节点、某个节点变慢、某个节点出故障，影响的只是数据的生产速率，训练器的独立控制循环完全不受干扰。这就好比快递分拣中心的传送带，某条支线停了，主线照样运转，只是输送量暂时减少而已。

训练器在AstraFlow中的角色被大幅简化：它只需要从数据流层拉取数据批次、执行优化、把更新后的权重推送给权重管理器。训练器不再需要管理推演节点，不需要直接向推演端发送权重，也不需要与其他训练器协调。这种简化使得训练器本身也变成了可替换的组件——无论是标准的强化学习训练器、监督微调训练器，还是具备容错能力的特殊训练器，只要能从数据流层读数据、往权重管理器写权重，就可以接入AstraFlow。

权重传输机制也值得单独说明。在传统系统中，每完成一轮训练，就需要把完整的模型权重同步给推演端。对于一个140亿参数的大型模型来说，完整权重约有28GB——在跨地域的网络传输中，这是一个巨大的负担。AstraFlow采用了"稀疏增量传输"方案：每次只传输从上一轮到这一轮发生变化的参数。研究团队实测发现，在使用bf16精度（一种常用的数字存储格式）训练时，相邻两轮之间超过98.9%的参数是完全没有变化的。这意味着每次实际需要传输的数据量，可以从28GB压缩到约1.5GB，压缩比超过30倍。每隔20轮进行一次完整同步，用于纠正累积误差。这种设计让跨地域的低带宽连接也能正常工作。

三、多模型协作训练：一套系统，多个AI角色同时成长

AstraFlow最具特色的能力之一，是原生支持多个AI模型在同一个训练框架内相互协作、共同进步。研究团队用三种不同的协作场景来验证这一能力。

第一个场景是数学解题中的"解题者+验证者"组合。解题者AI提出一个解答方案，验证者AI审查这个方案并给出"通过"或"拒绝"的判断；如果被拒绝，解题者收到反馈后重新尝试。两个AI都从同一个基础模型（Qwen3-8B，一个拥有80亿参数的开源模型）出发，被当作两个独立的策略分别训练。

实验结果显示，单独训练解题者时，在AIME24、AIME25、MATH500和Minerva四个数学基准上的平均准确率为51.1%。加入验证者后，使用verl框架（一个主流的竞品系统）实现的版本平均准确率达到54.4%，提升了3.3个百分点。而使用AstraFlow实现的同样协作配置，平均准确率达到56.5%，比单独训练解题者提升了5.4个百分点，也比verl版本高出2.1个百分点。更关键的是训练效率：verl的每轮迭代耗时212.64秒，而AstraFlow只需77.65秒，速度快了2.7倍。原因在于verl继承了"同地同步"执行的方式，一旦多智能体协作中有某次推演特别慢（比如验证者需要很长时间分析一个复杂解答），整轮迭代都必须等待；而AstraFlow的完全异步设计让训练不必等待任何一个慢节点。

第二个场景是代码生成中的"解题者+选择器"组合。解题者AI生成两段候选代码，选择器AI从中挑选更可能正确的那个提交。在LiveCodeBench v5、LiveCodeBench v6和Codeforces三个代码评测基准上，单独训练解题者的平均准确率为30.29%，加入选择器后提升到32.14%，提升了1.85个百分点。

第三个场景是更复杂的"解题者+测试用例生成器"组合。解题者AI写出代码，测试用例生成器AI专门生成能检验这段代码的测试案例；代码被这些测试案例检验后，如果失败，解题者会收到具体的错误反馈并重新尝试。这种"生成-测试-反馈-重试"的循环，让解题者在更丰富的反馈信号下成长。这个配置的平均准确率达到34.55%，比单独训练提升了4.26个百分点，是三种配置中提升最大的。

在AstraFlow中，实现这三种不同的协作场景，用户需要改动的只是"工作流定义"——角色顺序、上下文传递方式、奖励分配方式。底层的训练器、推演服务、数据流层和权重接口完全不需要修改。而在verl等竞品系统中，每种新的协作结构都需要对系统管道进行专门的工程改造。

四、弹性扩缩容：让AI自动帮你管理服务器

系统灵活性的第一个案例研究，是用一个AI助手来自动管理推演资源的扩缩容——而且这个过程完全不需要修改任何系统代码。

数据流层持续监控三个关键指标：每个推演节点每轮生产了多少轨迹数据（产出量）、训练器每轮消费了多少数据（消费量），以及训练器在等待数据上花了多少比例的时间（等待率）。每隔10个训练步骤，系统会生成一份"负载报告"，里面包含等待率 w、近期产消比，以及每个RaaS节点的状态和吞吐量。

基于这份报告，系统设计了一个三区间策略：如果等待率超过10%，说明推演产能不足、训练器在挨饿，需要增加推演GPU；如果等待率低于5%，说明推演产能过剩，可以释放一些GPU；否则维持现状。具体的扩缩容目标计算公式也很直接：产能不足时，目标GPU数量等于当前GPU数量除以（1减去等待率）；产能过剩时，目标GPU数量等于当前GPU数量乘以产消比再乘以一个安全裕量系数1.1（避免过度收缩）。

执行这些操作的是Claude Code（一个AI编程助手），它被配置为"运维维护者"：每隔10步读取负载报告，按照建议的目标GPU数量发出集群指令来启动或关停RaaS实例。AstraFlow自身不包含任何调度器专有代码——如果要换用Slurm、Kubernetes或内部集群系统，只需要修改AI助手的操作指令，系统逻辑本身不变。

实验对比了三种配置：固定6个推演GPU、固定11个推演GPU、以及自动扩缩容（在6到11之间动态调整）。固定6个GPU的情况下，训练器等待率高达26.9%，训练总时长35.8小时，推演GPU消耗214.8 GPU小时，总GPU消耗358.0 GPU小时。固定11个GPU的情况下，等待率降到2.1%，总时长23.9小时，但推演GPU消耗攀升到263.4 GPU小时，总计359.2 GPU小时。自动扩缩容的结果非常漂亮：等待率3.0%，总时长24.4小时（仅比固定11个GPU多0.5小时），推演GPU消耗214.5 GPU小时，总计312.0 GPU小时——比两种固定配置都节省了约13%的GPU总成本，同时最终模型准确率几乎相同（67.9% vs 68.0% vs 68.6%）。简单说：花同样少的钱，跑出几乎一样快、一样准的训练。

五、异构跨地域训练：让慢网络不拖累训练进度

第二个系统灵活性案例，展示了AstraFlow在硬件条件参差不齐、跨地理位置部署时的表现。

实验模拟了一个真实的跨地域部署场景：一台本地4-GPU训练节点，加上三个4-GPU推演节点，其中一个在本地、两个在"远端"。GPU异构性通过功率限制来模拟：本地推演节点的GPU运行在700W，两个远端节点分别被限制在400W和250W，导致三个节点的推演吞吐量大约是100%、60%和30%的比例关系。网络异构性通过流量整形工具模拟：两条远端链路被限制在4Gbit/s带宽和300毫秒往返延迟，这相当于真实跨洲际网络的典型条件。

在这种条件下，AstraFlow的稀疏增量传输方案发挥了关键作用。研究团队测量了Qwen3-14B模型在训练过程中的权重增量稀疏率：在正常学习率（3e-6）下，平均有98.9%以上的参数在相邻两轮之间完全没有变化。这意味着实际需要传输的数据量从约28GB压缩到约1.5GB，在4Gbit/s的网络上大多数传输可以在数十秒内完成。每隔20轮进行一次完整同步，这些完整同步会在传输时间图上形成明显的峰值，但由于被摊薄在大量增量传输轮次中，整体影响有限。

更关键的是训练流程是否被这些网络延迟所阻断。实验结果显示，推演端的停机时间（等待权重更新的时间）在整个训练过程中基本保持恒定，就是SGLang（一种推演引擎）在重新加载权重时的必要窗口，与权重是通过本地网络还是远端网络传来的无关。训练端在训练初期偶有等待（前一轮的完整同步还没传输完），但随着训练迭代推进、生成轮次变长，训练阶段本身的耗时足以覆盖下一轮权重传输的时间，等待率趋近于零。最终，这个跨地域异构部署的训练结果达到了67.6%的平均数学准确率，与完全同构本地部署的68.0%几乎持平。

研究团队还专门测量了权重增量稀疏率在不同模型规模和不同任务上的稳定性，涵盖Qwen3-1.7B、8B、14B三个规模的数学任务，以及Qwen2.5-7B在AlfWorld（家居任务型AI）、WebShop（购物型AI）和搜索问答三类任务上的结果。在固定学习率下，稀疏率几乎与模型规模和任务类型无关：所有数学任务的稀疏率落在0.989到0.993之间，所有低学习率（1e-6）的agentic任务稀疏率均不低于0.996。学习率是影响稀疏率的主要因素：把学习率提高到5e-6时，稀疏率降到约0.978，但即便如此，压缩比仍然超过30倍。

六、数据算法的积木式组合

第三类灵活性测试聚焦在数据算法上。研究团队选取了三种代表性算法，分别作用于数据流的不同阶段，验证它们是否可以像积木一样自由组合，而不需要修改任何底层系统代码。

动态采样算法（来自DAPO论文）的作用是"推演后过滤"：在AI生成回答之后、送去训练之前，把那些对训练没有帮助的数据扔掉。所谓"没有帮助的数据"，是指对某道题目，AI给出的所有回答质量都差不多——要么全对，要么全错——这种情况下模型无法从中学到任何新东西，因为它不知道"哪里做对了、哪里做错了"。动态采样会把这样的数据组整体丢弃。实验结果显示，加入动态采样确实能提升最终准确率，但代价是大量数据被丢弃，需要生成约700万个回答才能积累足够的有效训练数据（而不加过滤只需约200万个）。

GRESO算法（来自同一研究团队此前的工作）的作用是"推演前筛选"：在让AI生成回答之前，就预测哪些题目此时对AI的训练最有价值——既不是太简单（模型已经完全掌握）、也不是太难（模型完全不会）——只把这些"恰好合适"的题目送去生成回答。通过这种方式，GRESO可以在生成更少数据的情况下，达到与完整数据相近的训练效果。

缓冲重放算法的作用是"训练批次管理"：把有价值的历史轨迹数据保存下来，在组织训练批次时重复使用，而不是用一次就丢弃。这样可以在生成数据量较少的情况下，给训练器提供足够多的数据。

实验中，研究团队测量了不同算法组合在相同训练迭代次数（800轮）下的准确率与生成数据量的关系。单独使用动态采样时，在消耗约700万生成量的情况下达到最高准确率；GRESO加重放组合（重放比例r=0.5时）在仅消耗约250万生成量的情况下就接近了动态采样的准确率；三者叠加（动态采样+重放+GRESO，r=0.3时）进一步在约300万生成量下达到接近最高的准确率。这些结果表明，根据计算资源的多少，研究者可以灵活选择不同的算法组合来取得计算成本与模型质量之间的最优平衡。

在AstraFlow中实现这三种算法的组合，不需要修改训练器或RaaS的任何代码——每种算法都是在数据流层挂载的一个独立插件，就像在传送带上加装不同的分拣模块，随时可以拆装和组合。

七、与现有主流系统的性能对比

为了排除"AstraFlow的灵活性是以牺牲基础性能为代价"的疑虑，研究团队将AstraFlow与AReaL（一个专为单模型异步训练优化的主流框架）在完全相同条件下进行了正面比较。两个系统使用相同的模型（Qwen3-1.7B和Qwen3-8B）、相同的训练数据、相同的算法配置、相同的硬件（8块NVIDIA H100 80GB GPU的单节点），差异只是框架实现本身。

结果显示，在Qwen3-1.7B上，AReaL平均准确率49.5%，AstraFlow为49.3%；每轮迭代时间AReaL为81.5秒，AstraFlow为81.1秒；每百万训练token耗时AReaL为70.1秒，AstraFlow为69.4秒。在Qwen3-8B上，AReaL平均准确率65.4%，AstraFlow为64.8%；每轮迭代时间AReaL为137.0秒，AstraFlow为139.6秒；每百万token耗时AReaL为117.6秒，AstraFlow为119.6秒。两个系统在准确率上相差不超过0.6个百分点，在速度上相差不超过2%——这在实验误差范围之内。换句话说，AstraFlow在AReaL最擅长的单模型训练场景下与之旗鼓相当，同时还额外提供了AReaL根本不支持的一系列能力。

归根结底，AstraFlow的贡献是从架构层面解决了一个长期存在的系统设计矛盾：AI强化学习框架要么针对单一场景高度优化但缺乏扩展性，要么通过一个个补丁打出了各种功能但整体结构越来越难以维护。通过把"训练器是控制中枢"这个假设彻底推翻，替换为以数据流为媒介的自治组件协作，研究团队让多模型协作、弹性扩缩容、异构跨地域部署和模块化数据算法这四类能力不再是需要专门工程师定制开发的特殊功能，而是系统架构天然涌现的属性。

当然，任何系统设计都有其适用范围。研究团队坦诚地指出，AstraFlow专注于系统架构抽象，本身并不提出新的强化学习优化算法；部分实验使用了受控或模拟的部署环境；系统假设推演任务、轨迹元数据和奖励信号可以通过数据流层统一表示，这对某些特殊类型的任务可能存在限制。此外，对于长时程网页代理、机器人控制等特殊场景的适用性，还有待进一步验证。

对于希望在自己的研究中应用这套框架的读者，完整代码已在GitHub上开源（github.com/Infini-AI-Lab/astraflow），相关技术细节可通过arXiv编号2605.15565查阅完整论文。

Q&A

Q1：AstraFlow是什么，它解决了什么问题？

A：AstraFlow是由卡内基梅隆大学等高校联合开发的强化学习训练框架，专门针对多模型协作的AI训练场景。它的核心贡献是打破了传统框架"训练器控制一切"的设计，把推演、数据管理和训练三个环节分解为独立组件，通过数据流层协调，让系统能够原生支持多模型协作训练、弹性扩缩容和跨地域异构部署，而无需针对每种新场景进行专门的系统工程改造。

Q2：AstraFlow的多模型协作训练比verl快多少，准确率如何？

A：在数学推理的"解题者+验证者"协作训练场景中，AstraFlow每轮迭代耗时77.65秒，verl框架（Dr.MAS实现）为212.64秒，速度快了约2.7倍。准确率方面，AstraFlow版本平均达到56.5%，verl版本为54.4%，单独训练解题者为51.1%，AstraFlow在更快的同时也取得了更高的准确率。

Q3：AstraFlow的稀疏权重传输技术是如何减少跨地域通信量的？

A：AstraFlow利用了强化学习训练中一个普遍存在的现象：相邻两轮训练之间，绝大多数模型参数的数值不会发生任何变化。实测中，Qwen3-14B模型在正常学习率下有超过98.9%的参数在相邻两轮之间完全不变，实际需要传输的数据从约28GB压缩到约1.5GB，压缩比超过30倍。每隔20轮进行一次完整同步用于纠正误差，其余时间只传输变化的增量，使得4Gbit/s带宽、300毫秒延迟的跨地域链路也能正常支持训练。