企业官网建设流程全解析

OSDI26的论文墙还没正式挂出来，我和几个做系统开发的朋友已经在群里讨论“Weave”这个题目了：面向解耦式RL后训练的高效协同调度。这标题把三个最烫的关键词全占了——RL、后训练、协同调度。过去大半年，我在实际项目里反复被这三样东西折磨，所以看到这个标题的瞬间就来了兴趣。这篇文章我不去预测论文里的具体数值，只从标题和行业背景里拆出真正值得琢磨的东西：解耦式RL后训练到底难在哪，协同调度要解决什么核心矛盾，以及这套思路对我们平时搭RL训练系统有什么可直接借鉴的启发。不管你是做系统的还是做算法的，只要跟大模型训练沾边，相信都能从里面读到点有用的。

1. 先搞清楚：RL后训练为什么火，又给系统出了哪些难题

1.1 从“预训练和后训练哪个薪资高”说起：RL后训练到底在做什么

最近网上有个挺火的问题：预训练和后训练哪个薪资高？答案其实没那么重要，真正值得看的是提问背后透露出的趋势——行业对后训练的工程需求正在暴涨。预训练是基础，但大模型从“会说话”变成“会干活”，靠的是后训练中的对齐、检索增强、工具调用和强化学习。传统上大家说的后训练包括SFT、RLHF、DPO、GRPO这些阶段，而这里“RL后训练”专指用强化学习继续调整大模型的那一段。到了Agent时代，模型不再只输出一段话就结束，而是需要规划动作、观察反馈、反复修正，这一整套能力目前最有效的训练方式就是RL。

RL后训练的基本流程，我用最直白的方式描述：让当前策略模型去生成一批回答，然后让奖励模型或规则验证器给回答打分，再用这个分数去更新策略模型，让它下次生成时更倾向高分行为。听起来不复杂，但工程上特别折腾。因为RL条件下模型要不断试错生成，一次实验可能跑几万步甚至几十万步，每一步都涉及采样、评估、更新三个环节。相比预训练那种“前向+反向”的稳定循环，RL后训练多了一条自我博弈的回路。

而且RL后训练还很考验调参和基建。模型学得不好不代表算法错了，可能是数据没对齐、优势估计不准、奖励可能被攻击，甚至只是样本吞吐不够导致训练迟迟不收敛。所以这个环节既烧钱又烧耐心，谁能把基础设施理顺、把GPU效率拉高，谁就能用同样的预算把模型多调几个版本。这也是为什么“面向RL后训练的系统优化”能登上OSDI这种顶级系统会议的原因。

1.2 Rollout和Learning，天生就是两种脾性的负载

理解“Weave”这个系统，必须先理解RL后训练里两大部分的不同脾气。一部分叫Rollout，也就是让actor模型做推理生成，本质是一个大吞吐的在线推理服务。另一部分叫Learning，也就是把采样结果拿去做梯度计算和参数更新，本质是稠密计算型训练任务。这两者放在同一批GPU上时，一个像川流不息的外卖订单，一个像忙一整天的中央厨房，节奏完全对不上。

Rollout是内存密集和访存密集的。它要不断加载模型权重做矩阵乘，同时还要维护KV Cache，生成过程中每个请求的响应长度还是不确定的。处理它需要的是像vLLM、TensorRT-LLM这类连续批处理引擎，以及PagedAttention这样的显存管理技术。Learning则完全是另一套模型，反向传播里典型的权重梯度计算非常吃计算密度，通常要设成较大的batch size，用CCL跑AllReduce之类的通信原语做梯度同步。

这两类负载对GPU资源形态的诉求也不一样。Rollout阶段可以容忍低一点的并发度，但需要快速响应；Learning阶段恨不得把整个集群的算力都喂给梯度更新。如果把这俩塞在一个静态资源池里，最典型的后果就是：采样慢的时候训练在干等，训练更新的时候采样集群又闲着，GPU利用率像过山车一样。我之前跑RLHF时还经历过更恶心的场景，模型并行组网里，一个节点正在做梯度通信，另一个节点还在拼命生成样本，结果互相挤占带宽，谁都没跑好。

1.3 BC、Agentic RL这些热词背后的系统压力

在深入调度之前，先把几个热词背后的关系捋清楚，不然后面会乱。BC在RL里全称是Behavior Cloning，简单说就是让模型去模仿专家数据，本质上是有监督学习。很多人会在RL后训练前用BC给模型做初始化，先让它学会不犯低级错误，再进行策略探索。BC的局限也很明显，一旦遇到专家数据里没出现过的状态就抓瞎，所以它通常和强化学习混着用。R1风格的多阶段训练里，先用大量数据做SFT/BC，再用RL做推理能力的提升，就是这种组合的典型。

Agentic RL则把问题推向了更复杂的方向。智能体在真实或模拟环境里不断行动、观察奖励、调整策略，这种模式天然需要更长的轨迹、更多轮的状态切换。对系统的直接影响是：采样请求的到达模式完全随环境反馈而变，突发性更强；一次完整迭代可能需要跨多个设备协调，调度失败的代价也更高。这也是为什么大家越来越意识到，不能只用一套静态的集群分配逻辑去支撑RL后训练，必须要让调度器懂得“这个任务和那个任务其实是同一个训练流程的一部分”。

2. 解耦式架构：把训练和推理拆开是对的第一步，但也带来了新麻烦

2.1 解耦式RL后训练指的是什么

所谓的解耦式RL后训练，现在工业界已经形成比较明确的形态：把采样推理（Rollout）和模型更新（Learning）部署到不同的计算域里，各自按需伸缩。比如你可以在一个专门跑推理的GPU集群上部署vLLM服务，负责用当前策略模型生成样本；训练集群则跑Megatron-LM或类似框架，负责梯度更新。两个集群之间通过网络传输样本、奖励值和模型权重。

这种解耦能带来很直接的好处。首先是资源可独立规划，采样集群可以用推理友好型GPU，训练集群可以用计算更猛的卡；其次是可以复用成熟的推理优化栈，不用为了配合训练框架去改推理引擎；第三是故障隔离，推理服务和训练任务互不拖垮。再加上现在很多团队会做多卡并行，如果把推理和训练强行放在同一个并行组里，模型切分和通信组设置会变得非常别扭，解耦简直是顺势而为。

但要小心一个误区，解耦不等于没有关系，这两个集群仍然是一个流程的上下游。训练集群需要采样集群不断产出新样本，采样集群又需要训练集群更新后的权重。它们之间的连接如果调度不好，整个系统会退回“半吊子”状态。我在调优阶段遇到最典型的例子：采样集群由于网络带宽不够，传一批训练样本花了很长时间，训练集群的空闲率虽然很高，但整体产出就是上不去。解耦不背这个锅，锅在协同机制上。

2.2 拆开之后，调度问题的本质是什么

解耦式架构之后，调度就不再是简简单单地“某个任务来了，给一坨GPU跑起来”了，而是一个跨集群、跨时间、跨资源的联合分配问题。调度器要同时回答很多问题：采样集群现在应该分多少实例？训练集群参数更新完后，何时把新权重推给采样集群？采样的请求应该发给哪些副本，怎么避免过载？训练样本是攒一批传一次，还是实时流式灌进去？

这道题难在哪呢？难在“协同”二字。训练侧是同步迭代模型，它需要的是稳定、可预测的吞吐；采样侧是动态请求模型，它需要的是弹性、低延迟。当这两个目标不同的任务被放在一起联合调度时，仅仅保证单侧最优已经没有意义，必须找到一个平衡点，让整体端到端吞吐最大、代价最小。

我比较喜欢用一个流水线类比来解释这件事。如果烤箱一次能出炉一批面包，包装工一个面包一个面包地包，两者节拍不一致，中间就要设计好“暂存区”。但暂存区不能无限大，放多了前端烤新面包的空间就少了；放少了后端包装工又会断料。放在RL场景里，模型权重就是面包配方，训练样本就是面包，采样就是分装流水线，调度器必须在时钟周期内不断计算“每个工位的最大产能”、“在制品库存水位”和“交付时间”，任何一环卡住都会传导到整个系统。

2.3 协同调度到底在解决什么：流量模型一眼看明白

我试着把RL后训练的流量结构用最朴素的话描绘一下。一轮训练通常长这样：采样集群保持当前策略，产出N个样本；这些样本通过网卡传到训练集群；训练集群利用这些样本做若干步优化；优化完成后，新模型权重再从训练集群传回采样集群；采样集群加载新权重，继续下一轮采样。这个循环周而复始。

如果把采样和训练放在同一张网里，你会发现流量是“潮汐式”的。某一瞬间，大量训练样本从采样端涌入训练端；训练端做梯度同步时，又是内部AllReduce的天下；模型上新时，权重文件会把外网带宽打满。这种多峰流量是协同调度要处理的头号问题。如果调度器不知道当前正在处于哪个阶段，很可能会让权重传输与梯度通信抢同一批网络资源，结果两边都慢，整轮时间直接翻倍。

协同调度的目标就是要根据当前训练进度，主动安排流量优先级和传输路径，让外部样本传输、内部梯度同步、权重下发这三类数据流互不打搅。说白了，调度器需要拿到“训练阶段的时钟”，不能只做静态资源分配，还要做动态流量编排。这也是我认为Weave这种系统最大的价值所在：它不是又做一个集群管理器，而是把RL后训练当成了一个可感知阶段、可编排流量的整体流程来处理。

3. Weave的核心思路：像编织一样把训练与采样协同起来

3.1 Weave这个名字不是随便起的

“Weave”在英文里是编织的意思，用在调度系统上确实贴切。前面说过，解耦式RL后训练最大的问题是把两个不同脾气的集群硬生生放在同一个流程里，而Weave的定位应该就是那个“把经纬线织在一起”的角色。它要看住训练进度、采样负载、网络拓扑和资源状态，编织出一份动态的调度方案，让两条生产线能配合着转起来。

只看这个标题的话，我能明显感受到作者想传达的立场：仅仅把资源池做好分区、把任务静态分配到各自集群是不够的。必须要有一个上层协调机制，能根据RL训练迭代的节奏去主动调整两边的资源配置。这种思路在系统领域不算横空出世，分布式训练里的弹性调度、推理场景中的autoscaling都已经有积累，但把两者放到同一个RL迭代闭环里做专门协同，确实是目前社区里还比较缺的一块。

如果按这类系统的常规做法来推演，Weave很可能有一个全局调度器负责跨集群资源分配，同时在各子集群内部保留本地编排能力。调度决策不会非常频繁地“一刀切”，而是按训练迭代的粒度来动态调整，比如采样集群当前base实例数、权重下发是否该预取、样本传输是否可以压缩。这些操作对一个普通的Kubernetes集群调度器来说是几乎不可能做好的，因为它根本不理解RL迭代是什么。

3.2 可能的三个协同维度：资源、拓扑、任务优先级

要协同的东西不少，但拆开看，做调度系统无非是把握好三个维度。第一个维度是资源协同，也就是说采样集群和训练集群之间GPU数量的配比不是固定的。当一次训练更新完成后，旧策略不再被需要，可以把一些采样实例缩下来，把资源交给训练集群做下一轮更重的梯度计算；反过来当采样成为瓶颈时，就要把资源从训练侧临时匀给采样侧。这种弹性伸缩的前提是权重加载快、状态迁移可控，否则资源一抖动，整个训练可能直接崩掉。

第二个维度是拓扑协同。训练任务通常要做节点内NVLink通信、节点间RDMA通信，采样集群也要处理大量并发请求和结果回传。调度器如果对物理拓扑没感知，很可能会把需要密集通信的任务推到一个网络拥塞严重的区域，导致AllReduce骤慢。好的调度系统会把GPU集群按通信半径分成若干“域”，优先把高流量任务放在同一个域内，把跨域流量减到最少。

第三个维度是任务优先级协同。同一时间系统里可能既有训练样本传输、又有模型评估请求、还有checkpoint落盘。这些任务优先级不一样，调度器要能做到队列级别的感知和抢占。比如模型权重下发这种短但影响面大的操作，应该给最高优先级；而checkpoint这类后台任务，就可以用闲时带宽慢慢传。这个听起来简单，真正落地时很考验系统对任务依赖的判断能力。

3.3 技术实现上的几个关键选择

在这种系统里，有几个技术点大概率是绕不开的。第一个是“阶段感知”。调度器得知道当前训练进行到哪个迭代、哪些步骤正在等待数据，然后才能决定要不要给采样集群扩容、要不要压低后台流量。实现阶段感知需要改造训练框架，把关键事件上报给调度器，或者通过统一的分布式协调服务来做事件同步。

第二个是“数据传输优化”。当模型权重从训练集群同步到采样集群时，模型少则几十G、多则几百G，如果每次更新都全量传，网络开销会非常恐怖。更实用的做法是权重校验和比对、增量同步，以及结合模型参数的量化和压缩手段。把权重切碎成块，在训练更新过程中就开始预传已知不动的部分，也能大大隐藏传输延迟。

第三个是“容错和弹性恢复”。RL实验经常跑几天几夜，任何一个节点故障都可能导致采样结果丢失或训练状态不一致。调度器需要支持副本迁移、样本缓冲区和周期性checkpoint，如果某个采样实例挂了，它的未消费任务可以被其他实例接管。把这些机制和调度动作绑定，才算是一个能落地的协同调度系统，而不是停留在理论层面。

3.4 为什么说“协同”比“分离”更难也更值钱

我记得之前听一位搞过多年MRP系统的人说，“分离是懒人的做法，协同才是真正的工程”。放到RL系统里，解耦架构谁都会搭，把训练和推理各放各的集群就行。难就难在解耦之后你怎么保证端到端性能不退化。每次训练更新完成，新策略要对齐到采样侧，采样数据又要回流到训练侧，如果这个循环跑不顺，整体效率甚至可能不如单体架构。

协同调度的价值恰恰在于，它把每次迭代的时间窗口抠出来了。原来采样集群要等新权重，训练集群要等新样本，两边都在干等，GPU利用率很难超过50%。有了协同，训练侧在做梯度更新时，采样侧可以继续用旧策略做少量探索；一旦新权重就绪，马上就切换。这种“中间有缝但缝里也有产出”的状态，才是后训练系统该有的样子。

我还想强调一个观点：协同调度做的不是“平均分配”，而是“错峰编排”。让每个任务尽量在资源充足的窗口里启动，让通信尽量在链路空闲时进行，让等待中的任务占用最少的资源。这个设计思路放到更大范围也有普适性，以后凡是多组件大模型训练系统，都会往这个方向走。

4. 实战视角：如果要复现/借鉴Weave，需要准备哪些东西

4.1 一套可拆解RL后训练系统的组件清单

纸上谈兵结束，回到动手层面。如果你想在自己的环境里搭一套偏解耦的RL后训练，并试图加入协同调度的思路，下面这些组件早晚都要面对。我先给一份基础清单，再逐个讲责任边界。

很多人一开始会忽略奖励/验证器这个组件，实际上它在系统开销里占比不小。如果一个reward model和actor放在同一个GPU卡上，推理显存必然吃紧；如果单独放，又增加一次跨节点调用。在设计解耦时，最好把reward也当成一个可独立扩展的服务，跟actor采样并列考虑。

4.2 监控指标应该重点盯哪几个

配置好组件之后，真正决定系统能不能跑顺的是监控和诊断能力。我强烈建议不要只看GPU利用率，那玩意在解耦系统里很会骗人——可能GPU利用率看着很高，但中间有很大一部分是在做无效等待，而不是有效计算。重点要盯这几类指标：

• 训练吞吐：单位时间完成的梯度步数，以及每个step的耗时曲线，观察是否有明显锯齿。
• 采样吞吐：每秒生成token数、请求队列深度、P99响应时延。如果采样吞吐跟不上训练消耗，下游一定饿死。
• 数据流转时间：样本从采样端产生到训练端拿到，中间消耗多少毫秒；权重从训练端到采样端，又消耗多少秒。这个往往是隐形瓶颈。
• 跨环节等待分布：训练侧的“数据等待时间”和采样侧的“权重更新等待时间”，这两项直接反映协同调度有没有起作用。
• 网络带宽占用：区分节点内、节点间、跨集群三类流量，看是否存在某个时间窗内的流量峰值冲突。

我之前调试时就发现，训练集群的空闲时间往往不是GPU算不动，而是网络传样本没传过来。当时靠抓“step中等待数据的比例”才定位出来。后来我们加了一个样本缓冲队列，让训练永远有数据吃，才算解决。这个经验放到有协同调度器的系统里也是一样，调度器可以根据队列水位预判要不要临时加采样卡。

4.3 典型的坑与排查手段

这类系统里最常见的坑，排第一的一定是“权重下发风暴”。训练每更新一个版本就把全量权重推到采样集群，采样集群几十个副本同时去拉，RDMA网络瞬间被击穿。排查信号是：训练侧的网络利用率不高，但采样侧连接全部超时，样本产出直接归零。对策是把权重下载做成P2P分片，或者用中心缓存挂载，并错开副本的刷新时间。

第二个常见坑是“样本重复消费”。采样和训练各自异步推进时，如果没有健壮的消息确认机制，一个样本可能被消费两次，或者某个批次样本对应的模型版本已经过期。这会让训练曲线直接崩掉。务必要在样本里带上模型版本号、采样时间戳和全局ID，训练端也要做消费去重。

第三个坑是“checkpoint频率过高导致的次生调度抖动”。有的团队为了安全，每几百步就存一次checkpoint，每次几十G，直接抢占网络带宽，把协同调度好不容易挤出来的流量窗口又堵上了。解决办法是降低checkpoint频率，或者把它规划到训练step间隙里，和权重下发使用不同的带宽池。

5. 这个方向对做系统的人和做算法的人各意味着什么

5.1 通用调度器为什么很难直接拿来用

很多团队一开始想的是，直接用K8s加一个GPU调度插件，不就能把活干了吗？现实没那么简单。K8s擅长的是一段式任务管理，它看到的是单个Pod和单个容器，不理解“这个Pod和那个Pod之间是采样依赖训练的关系”。如果你只按资源余量把Pod随便装到一堆机器上，很可能出现训练集群在A区、采样集群在B区，中间还要跨网段传权重，延迟直接爆炸。

通用调度器的另一个问题是缺乏阶段概念。它不知道当前权重正在下发、梯度正在AllReduce，所以没法主动避开冲突。你会看到模型权重传输和梯度通信同时发生，两边都在抢带宽。要缓解，就得在应用层做很多妥协，比如人为限制传输速度、设置低优先级流量标记等，这些都治标不治本。

所以像Weave这种专门为RL后训练设计的协同调度，本质上是在通用调度器之上再加一层领域逻辑。它可以把训练相关的事件与资源动作绑定，把通信流量按重要程度进行规划。这套思路值得所有做LLM基础设施的人学，未来你不需要完整复刻它们，只要在自家调度器里引入“阶段感知”和“任务亲缘性”，就已经能赢过大多数粗放方案了。

5.2 Agentic RL会不会让这个问题更难

接下来的Agentic RL浪潮，会让RL后训练的调度压力只增不减。Agentic RL的特点是代理需要在环境中多轮行动，每轮行动都产生一个状态变化，同时奖励信号往往是稀疏和延迟的。体现在系统层面就是：采样请求更碎、更多、更不规律；模型上下文长度更长，KV Cache需求猛增；环境反馈等待时间不稳定，导致“下一批样本何时就绪”不可预测。

这种情况下，协同调度器还得增加一个“环境依赖感知”的维度。比如某个agent正在等外部工具返回，系统不需要给这个采样请求分配满格算力，但也不能直接释放资源，否则结果回来时又要冷启动。这很像数据库里的连接池管理，既要保持连接，又要控制占用。要把这种动态负载管好，静态调度策略完全不够用，必须引入类似预测、队列、超时控制等手段。

而且Agentic RL对期望收益的定义也更复杂，可能一个场景里同时存在多个子任务，训练信号还要组合和权衡。这意味着系统的实验管理、回放缓冲和数据切片会互相交织，调度器如果对任务依赖没有抽象，很容易把一批相关性极强的样本切得七零八落。所以我的判断是，未来专门做“RL数据流与训练流协同”的调度系统会越来越多，Weave这类方向只会更热门。

5.3 对个人技术路线的一点观察

回到最开始那个“预训练和后训练哪个薪资高”的问题，我的观察更偏整体。预训练模型的门槛高、机会少，而且已经被头部几个团队牢牢攥着；后训练和RL的工程化需求则处于爆发期，做SFT、RL、评估、推理加速的系统工程师特别缺。换句话说，这轮红利更可能落在“能把RL训练工程跑顺”的人身上。

如果你对这类系统感兴趣，我的建议是先亲手跑通一个最小闭环，不要只停留在看论文。用一台多卡机，把vLLM做采样、DeepSpeed做训练、Redis做样本通道，然后自己写一个简单的调度脚本去控制两边的实例数，观察不同策略下的吞吐变化。等你亲手踩过权重下发风暴、踩过样本重复消费，再回头看Weave这类系统，就能真正看出它精妙在哪里了。

我自己在实际操作中还有一个挺深刻的心得：不要一开始就追求复杂的调度策略，先把“让两边都不会饿死”的缓冲机制做好，再逐步加入阶段感知和弹性伸缩。很多时候系统慢不是缺资源，而是缺稳定的数据流。先把水管子造粗，再谈水龙头怎么拧，这句话对RL后训练尤其适用。最后再分享一个小技巧，所有跨集群的同步动作，都尽量在训练step的空隙里发起，哪怕只提前几十毫秒，对整体稳定性的帮助都会大得超出你的预期。