企业官网建设流程全解析

简介：强化学习训练不像传统监督学习那样有静态数据集，其数据由智能体在环境中交互产生，采样、训练、评估环节天然相互依赖。在昇腾NPU集群上，这种循环依赖更容易导致算力看似繁忙而有效吞吐低下。为突破这一瓶颈，需要从资源分配角度重新设计调度机制，将训练与推理按需共卡或分离部署，并通过异步流水调度解耦生产与消费速率；同时针对训练大报文和采样小请求并存的场景，实施通信域隔离、拓扑感知与小报文聚合等异构通信优化。这些方法不仅能有效提升昇腾集群上大规模强化学习任务的训练吞吐，也为RL模型从实验环境走向生产部署提供了可复用的工程范式。 做强化学习的人，把训练规模推到集群这一层之后，大概率都经历过这样的时刻：显存看着用满了，NPU利用率看着也不低，但训练的有效吞吐就是上不去。原因不复杂，RL的训练循环里，采样、训练、评估三个任务天然互相等待，任何一个环节跟不上，其他环节都在空转。这个问题放到昇腾生态里会更明显，主流RL框架的算子、内存管理、通信库默认都是按GPU生态设计的，直接搬过来能跑通，但很难跑满。我们做的这个基于昇腾生态的强化学习加速框架，就是面向昇腾芯片生态合作伙伴提供一个端到端的RL训推解决方案，核心能力覆盖超大昇腾集群的训推共卡/分离部署、多模型异步流水调度、训推异构切分通信。这篇文章我把架构选型、调度设计、通信优化、落地接入这几块的思路和踩坑经验完整展开，给准备在昇腾上跑RL的团队一个参考。

1. RL负载为什么跑不满NPU：通用训练框架的结构性短板

1.1 训练数据自己生成的循环，和常规训练不是一回事

要理解为什么需要一个专门的RL加速框架，得先看到强化学习的计算模式和传统训练的差异。CV、NLP的训练是典型的监督学习，数据是提前准备好的，训练过程就是“读数据、前向、反向、更新权重”这样高度规整的循环，数据和算子的形状基本是稳定的，很容易通过数据并行、梯度累积、流水并行把集群整卡喂满。这种情况下，哪个节点慢了，无非是等一个同步，问题不大。

RL完全不一样。训练数据不是静态存在的，而是Agent在环境里试错产生的。整个训练闭环是：策略网络和环境交互、拿到状态和奖励、产出轨迹数据、轨迹写入回放池、训练器从回放池采样更新权重、再把新权重发布回推理侧继续采样。这个循环里，推理采样和训练更新是互相耦合的，任意一个环节出问题，整个闭环的有效吞吐都会掉。换句话说，RL的瓶颈往往不在单卡算力，而在数据是怎么产生、怎么流动、怎么被消费的。

放到集群场景下这个问题更复杂。单机RL撑死同时跑十几个环境交互，集群RL要同时跑成百上千个采样Worker，还要保证它们拿到的模型权重是“足够新”的。这已经不是把torch.distributed换成HCCL就能解决的事，而是一个分布式调度问题、一个通信拓扑问题、一个数据管线问题。

1.2 昇腾AI Core对RL负载的真正挑战在“碎片化”

昇腾芯片的AI Core对矩阵乘、卷积这类规整算子的计算效率是很高的，这一点在主流模型训练上已经反复验证过。但RL负载恰恰不是规整的负载。

RL的推理采样路径里，模型通常不大，反而有大量小算子、动态Shape、控制流逻辑（比如环境返回的终止状态不一样，导致后续计算分支不同）。这类碎片化的计算对AI Core的调度并不友好——单笔采样请求的计算量可能只有几微秒，但请求之间的切换、Host侧的调度开销、数据搬运开销往往比计算本身还大。结果就是，明明是推理卡资源，实际有效算力可能只发挥出一小半。

这就是为什么不能把通用训练框架原封不动搬过来用于RL训推。通用框架为大规模稠密训练做了很多假设，比如训练和推理分开部署、数据预处理离线完成、算子形状稳定。而RL训推框架要做的是把这些假设全部打破，让推理采样和训练更新在同一个生态里跑起来，并让碎片化的小请求不再成为瓶颈。

1.3 一个专用框架需要解决的四个核心问题

基于我们在昇腾上的实践，RL训推框架如果要落地，至少要解决四个核心问题。

第一是训推一体的资源视图。训练和推理不能是两套孤立的集群，不然权重同步、轨迹回传都会有很高的额外开销。第二是模型管理。RL任务里同时存在策略网络、目标网络、定期评估的Agent、多个采样用模型副本，它们更新频率不同、生命周期也不同，框架必须能统一管理这些模型的存储、版本、分发。第三是流水调度。采样、训练、评估三个环节必须解耦成流水线异步执行，不能让一方阻塞另一方。第四是通信设计。训练路径的AllReduce和推理采样路径的大量小请求天然冲突，需要按各自的通信特征做异构切分，否则集群规模一大，通信反而成为最大瓶颈。

这四个点不是互相独立的。部署形态决定了调度的边界，调度方式决定了模型版本如何流转，通信设计又限制了整个框架能撑到多大规模。下面我分别展开。

2. 训推共卡还是分离部署：先理清场景再选架构

2.1 共卡模式下资源切分与优先级保障

训推共卡，顾名思义，推理采样和训练更新共享同一批NPU设备。这种模式最直观的好处是权重同步几乎零成本——模型权重在同一个内存池里，不需要通过网络从训练端推到推理端，采样侧拿到的权重永远是最新的；轨迹数据也可以直接通过内存传递给训练器，省掉了跨集群传输的时延和带宽开销。

但共卡模式有个绕不开的问题：推理采样和训练计算在抢同一批资源。RL推理采样的特点是高并发、小请求，每个请求的计算量不大，但请求数量非常多；训练更新则正好相反，是低频次、大计算量的大任务。如果两者没有做资源隔离和优先级控制，推理请求会频繁打断训练算子的执行，导致训练Step时间明显变长。我们见过一个场景，共卡部署没做隔离，训练吞吐反而比分开部署还低，就是因为采样请求把AI Core的调度单元占满了。

解决思路是给采样和训练分别划分资源域。一个朴素但有效的做法是把NPU逻辑切分成两部分：固定比例的核心专跑训练算子，剩下部分处理采样请求。训练算子的优先级永远高于采样请求。当训练进入梯度更新阶段时，采样请求可以排队，但不能让采样请求在训练算子前面抢占调度。这个策略，本质上就是把慢路径和快路径用不同资源域隔离开，避免相互干扰。

2.2 分离部署的权重同步与链路设计

分离部署则是把推理采样放到独立的一批节点上，和训练集群彻底分开。这种模式适合训练集群和采样集群的规模都比较大，且互相之间负载波动不明显的场景。例如训练集群跑大规模PPO，需要几十张卡做并行训练，而采样集群需要贴近环境所在位置，或者在多个机房分布，这时候硬把它们绑在一个集群里反而是负优化。

分离架构最核心的问题是权重同步。训练端每更新一步，推理端并不需要立刻换权重，但也不能一直用旧权重。我们采用的机制是异步权重推送加版本控制：训练端每个Step结束之后，把新权重打成带版本号的快照，通过网络异步推送到采样集群；采样集群内部维护一个“当前生效版本”和一个“最新可用版本”，采样请求统一走当前生效版本，后台线程在合适的时机切换到新版本。

这里有个细节很多人会忽略：推送频率不是越高越好。采样用的权重太新，和训练端正在优化的梯度关联过强，反而容易让策略在更新时出现震荡。我们实际使用中，权重推送频率设置为每1到2个训练Step推送一次就够了，采样侧滞后几个Step不仅能容忍，在部分算法里还能起到类似目标网络的效果。

2.3 我建议的选型基线

选共卡还是分离，没有标准答案，但我建议按下面这几条去判断。

如果集群规模在几十卡以内、训练和采样都是同一个团队在维护、实验轮次多且单轮时长短，选共卡。原因是这种场景下的主要矛盾是迭代效率，共卡省掉的权重同步和轨迹传输开销非常可观，而且在同一个集群里调试问题也简单得多。

如果集群规模在上百卡以上、训练集群要长时间保持高利用率、采样集群需要独立扩缩容、或者训练任务和采样任务分属不同团队，选分离。这种情况下，让训练和采样互相迁就的成本远高于多花一点带宽做权重同步的成本。

还有一种折中的混合做法：默认训练采样共卡，但把一部分采样Worker独立部署到“采样扩展集群”上，两个集群之间通过权重服务同步。这样既保留了共卡的低延迟优势，又能在采样量暴涨时弹性扩容。这套架构我们验证下来比较稳，适合从共卡往分离迁移的过渡阶段。

3. 多模型异步流水调度：把采样、训练、评估解耦成流水线

3.1 RL训练中同时存在的多种模型角色

一个标准的RL训练任务里，同时存在的模型角色远不止一个策略网络。

首先是Actor，也就是策略网络，它每一轮训练都在更新；其次是Critic，价值网络，和Actor一起更新，评估当前策略的好坏；此外还有Target Network，目标网络，通常是主网络的一份延迟副本，周期性同步，用来稳定训练；最后是评估用的Agent模型，每隔N步做一次完整评估，验证当前策略的真实水平。有些离线RL任务里还会有行为策略模型和当前策略模型，两者要在同一套特征空间里互相比较。

这些模型实体看起来是同构的，但它们的更新频率、调用方式、资源需求都不同。Actor和Critic是训练主循环的主角，需要高频更新和高算力；Target Network是低频同步，不需要额外计算资源；评估Agent则只在特殊时间点出现。如果框架把这些模型当成同一个东西平等对待，调度必然出问题。

所以我们把调度器设计成按“模型角色”划分优先级。训练主循环中的Actor/Critic拥有最高优先级；采样Worker使用的推理模型副本是第二优先级；Target Network同步是后台任务，优先级最低；评估Agent只有在评估窗口内才会临时占用资源，但它的优先级也不能高于训练主循环，否则一个Agent评估就会打断训练节奏。

3.2 调度器设计的三个关键机制

异步流水调度的核心，是把原来强耦合的“采样→训练→采样”循环拆成两条独立推进的流水线。

采样流水线的目标是持续产出轨迹数据，它不关心训练端具体训练到哪一步，只管从缓冲区拿当前可用的模型权重，频繁和环境交互，把产生的轨迹写入缓冲队列。训练流水线则持续从缓冲队列取数据做梯度更新，更新一定次数后，把新权重发布出来，供采样侧使用。

要让这个机制真正跑起来，三个设计点很重要。

第一，任务依赖关系建模。调度器内部用DAG描述采样任务、训练Step、评估任务、模型同步任务之间的依赖关系。训练Step依赖缓冲队列里有足够的数据；采样任务依赖模型权重处于可用状态。DAG的好处是任务之间只要没有依赖关系，就可以并行执行，调度器可以自由安排多个采样任务和训练Step在同一时间片内交错进行。

第二，动态并行度调节。采样Worker数量和训练算力分配不能是静态的，否则负载波动时要么采样跟不上训练、要么采样过多挤占训练资源。我们的做法是监控缓冲队列的水位，水位低说明采样太慢，动态增加采样Worker数量；水位高说明轨迹积压了，压缩采样Worker数量，把算力让给训练。

第三，权重版本新鲜度检查。异步调度最大的风险是权重滞后过久。框架在发布权重时给每个模型打上全局递增的版本号，调度器定期检查采样侧当前生效版本和训练端最新版本之差。这个差值一旦超过预设阈值（比如3到5个Step），就不允许继续采样，强制触发一次权重同步，保证策略不会在陈旧模型上跑太久。

3.3 流水级数和缓冲深度的经验值参考

流水线的级数不是越多越好，这个坑我们踩过。级数太少（比如只有采样和训练两级），当采样侧有波动时，训练端还是会感受到明显的等待；级数太多（拆成采样、预处理、回放、训练、同步五级甚至更多），端到端时延变长，权重陈旧度也会上升，反而影响训练稳定性。我们实测下来，3到5级流水是一个比较合理的区间，基本能把单点波动缓冲掉，又不会让整条链路的延迟大到不可控。

缓冲队列的深度同样需要调。太浅，训练端频繁等数据，流水线退化成同步模式；太深，训练端吃到的是很久之前采样出来的轨迹，策略新鲜度下降。我们验证下来，缓冲队列长度维持在训练单步消耗量的5到10倍是比较合适的——训练端能连续消费好几步，不会因为采样瞬时抖动而停下；同时队列里的数据又足够新，不会导致策略更新明显滞后。

这些数值都不是固定的，需要按具体模型大小、环境交互耗时、集群规模去实测。但作为起始参数，以上配置可以让调度器先跑起来，再根据队列水位和权重新鲜度曲线做微调。

4. 训推异构切分通信：大集群下真正的性能瓶颈

4.1 训练通信和推理通信为什么必须分开

标题里“训推异构切分通信”中的“异构”两个字，值得单独拆开讲。大多数做训练的人看到“异构”第一反应是混合精度或者异构硬件，但在这里，“异构”指的是训练路径和推理路径的通信特征是截然不同的，必须用不同的通信策略去对待。

训练路径的通信以AllReduce、AllGather为主，比如张量并行每层前反向都要做几次AllReduce，数据并行梯度更新时也要做全量梯度规约。这类通信的特点是单个报文非常大（动辄几百MB甚至上GB），频率相对可控，对带宽要求极高。

推理采样路径则完全反过来。每个采样请求是一个很小的batch，对应的模型推理输出也是小尺寸张量，报文通常只有几KB到几十KB。但采样请求的频率极高，一个集群可能同时有几百上千个采样Worker在跑，每个Worker每秒钟发出几十到上百个请求。如果这些小报文和训练的大通信挤在同一个通信域里，大通信会把链路带宽吃掉，小报文在队列里排队等待，时延直接飙到不可接受。

4.2 拓扑感知、小报文聚合与零拷贝

理解了“异构”的含义，处理手段就很明确了。

第一是通信域隔离。训练通信和采样通信必须使用不同的虚拟通道或不同的通信组，在物理链路上也可以做优先级配置。我们实际使用时，HCCL支持创建多个通信域，训练AllReduce走一个域，采样小请求走另一个域。两者互不干扰，即便某条链路暂时拥塞，也不至于让另一个方向的请求跟着遭殃。

第二是拓扑感知的rank分配。集群的物理拓扑是分层的，机内总线快、跨机架慢。训练通信要尽量把张量并行的rank放在同一个交换域内，减少跨域跳数。推理采样的通信频率高但单次数据量小，节点间的拓扑距离敏感度反而没那么高。如果默认rank分配不做拓扑优化，很可能出现某几个张量并行rank被分配到不同机架，每次AllReduce都要绕远路，通信时延成倍增加。我们在初始化阶段会读取物理拓扑信息，重新排布rank，针对训练通信域单独做拓扑亲和。

第三是小报文聚合。这个优化非常重要。推理采样请求如果在通信原语层逐个发送，系统调用和协议开销会远大于数据本身。我们设计了一个聚合缓冲层，按固定时间窗或者固定字节数把积压的小报文合并成一个大的Batch再批量发送。实测下来，聚合之后节点间通信的报文数量可能减少两个数量级，通信效率提升非常明显。

第四是零拷贝。这个在共卡部署模式下特别关键。训练和采样都在同一批NPU上时，轨迹数据完全可以通过共享内存映射直接让训练器读取，不需要先把数据从NPU显存搬到Host内存，再通过通信库从Host搬到另一个进程。省掉这两次搬运，数据管线延迟能降一截，这个优化成本极低、收益极高。

4.3 通信优化的实测参考

关于通信优化的收益，我用自己实践中的一组数据做参考。某个集群规模中等（约32卡），未做任何通信优化时，训练Step间通信开销平均占比接近40%，也就是每跑一个Step，接近一半时间花在通信等待上。做了通信域隔离和rank拓扑重排之后，这个占比降到20%左右。再把小报文聚合加进来，采样请求侧的网络负载明显下降，训练侧的采样等待时间也随之改善，整体训练吞吐相对初始状态大概提升了50%以上。

这个数字不是理论值，是我们在实际集群上多次压测得到的。它说明一个问题：在RL训推一体的场景里，通信优化的空间往往比算子优化的空间还大。因为算子在NPU上已经足够高效，而通信路径上每一层停留、每一次拷贝、每一次排队，都是在白白消耗时间。

5. 端到端框架的落地路径：合作伙伴从0到1的接入过程

5.1 框架抽象：采样器、训练器、评估器、权重服务的分工

一个面向生态合作伙伴的框架，光有底层加速能力是不够的，关键是让用户能低成本接入自己的RL算法。我们框架在设计上抽象了四个核心组件：Sampling Server、Training Worker、Evaluator和Weight Service。

Sampling Server负责和环境交互，产出轨迹数据。它对外提供高吞吐的采样接口，用户只需要把自己的仿真环境或者真实环境按Gym接口包一层。Training Worker负责从回放池采样数据、计算损失、更新策略，用户实现的核心只是“如何从轨迹算损失”和“如何更新模型参数”。Evaluator是一个独立的轻量组件，周期性读取当前最优权重，在测试环境里跑几轮评估，产出奖励曲线和策略熵等指标。Weight Service是全局模型管理服务，负责模型版本管理、权重存储和分发，所有组件的权重读取都通过它完成，保证版本一致性。

四个组件通过消息队列和共享存储解耦，用户接入一个新算法时，理论上只需要实现两个回调函数——损失计算和策略参数更新，调度、分布式、通信层都不需要改。这个抽象层决定了框架能不能真正落到生态里去，如果一个新算法接入要动调度器，那框架的可用性就大打折扣了。

5.2 四步迁移路径与每一步验收标准

合作伙伴从GPU生态迁到昇腾，我们不建议一次性把整个集群切过去。按下面四步走，每一步都设验收标准，能大幅减少排查问题的难度。

第一步是算子兼容性检查。模型脚本里最常见的LayerNorm、激活函数、Softmax等算子，昇腾生态下都有对应实现，但总有一些小众算子在迁移时会出问题。建议先跑自动扫描工具，把所有算子过一遍，把有兼容性问题的算子列出来，优先替换或者走自定义算子开发。

第二步是单机单卡跑通小规模RL任务。固定随机种子，在同样的超参数下，对比原GPU框架上的loss曲线和奖励曲线。两者应当基本一致，如果曲线趋势出现明显分叉，说明训练逻辑里有算子级行为差异，需要先排查再继续。

第三步是两机四卡小集群验证异步流水。把采样和训练解耦，跑通多模型异步流水调度，重点看两个指标。一个是采样等待时间占比，正常情况下它应该在10%以下；另一个是权重新鲜度，也就是采样侧模型版本和训练端版本之差，应该稳定在设定阈值内。这两个指标正常，说明调度逻辑没有问题。

第四步才是上大集群，启用拓扑感知的rank分配、通信域隔离、小报文聚合这些优化。这阶段重点看扩展性：集群规模翻倍时，训练吞吐是否接近线性增长；通信开销占比是否随规模上升而显著增加。如果通信占比涨得比算力还快，说明通信系统还没有真正优化到位。

5.3 工具链与运维：多实验管理、断点续训、状态可视化

框架的可操作性很大程度取决于工具链。一个RL训练任务动辄跑几小时甚至几天，中途状态可视化、断点续训、多实验管理这些能力，不是锦上添花，而是必需品。

状态可视化方面，我们在框架里内置了训练Dashboard，实时上报每个训练Step的奖励均值、价值损失、策略熵、缓冲队列水位、NPU利用率、各节点通信时延。其中缓冲队列水位和NPU利用率是定位性能问题最直接的抓手，这两个指标一拉出来，调度是否有问题基本一目了然。

断点续训方面，框架定期保存的不是单一的模型权重，而是完整的“训练现场”，包括模型版本、回放池状态、优化器状态、环境状态、随机数生成器状态。这样集群故障或者实例被抢占后，可以从最近一个检查点恢复，损失的时间控制在几十分钟以内。

多实验管理方面，一个集群同时跑多个RL实验是常态。框架按实验维度做资源组隔离，每个实验可以独立指定卡数、优先级、最大并发采样数。实验A的采样负载波动不会挤占实验B的训练资源，这是平台化框架必须提供的基本能力。

6. 踩坑实录：从单卡到集群规模遇到的四个问题

6.1 共卡模式下推理采样把训练算子挤到“假忙”

第一个坑是共卡模式下NPU利用率看起来很高，但训练Step时间不降反升。表面看资源没闲着，实际上推理采样的小算子频繁抢占调度单元，训练大算子被打断的次数太多，导致有效计算下降。

排查过程相对直接：先关掉采样请求，只看纯训练Step时间，显著下降；再把采样请求逐步加回来，Step时间随采样并发数同步上升。确认是采样导致之后，我们的方案是把采样任务绑定到固定的AI Core上，并限制它可占用的最大调度时间片，保证训练算子所在核心不被抢占。做了这个隔离之后，训练Step时间恢复了正常水平，采样吞吐也没有明显损失。

6.2 权重版本滞后导致策略震荡

第二个坑出现在异步流水调度刚上线的阶段。我们把采样和训练解耦之后，训练吞吐确实上来了，但训练出来的策略反而不稳定，奖励曲线一直上下震荡，收敛不到一个相对平稳的水平。

排查之后发现是权重滞后失控。当时没有对版本号做约束，采样侧拿到的权重可能滞后了十几个训练Step。滞后一两个Step还能当隐式的目标网络用，滞后太多，训练端基于新梯度更新的权重和采样端实际执行的权重差异过大，策略评估就不准了，训练自然震荡。

解法就是前面提到的权重新鲜度检查：给权重加版本号，超过阈值就暂停采样、强制同步。加了这层机制之后，奖励曲线很快恢复了正常。这个坑对我们来说价值很大，它说明异步流水不是简单把同步去掉就能行的，必须引入版本管理作为安全性护栏。

6.3 默认通信组与物理拓扑不匹配

第三个坑是集群规模到几十卡之后，训练通信时延突然明显上升。一开始我们以为是带宽不够，扩了链路之后效果依然有限。后来仔细检查了通信rank分布，发现HCCL默认的rank分配完全没考虑物理组网，部分参与张量并行的卡被分配到了不同机架，每次AllReduce都要经过上层交换机，时延自然居高不下。

解决方法是初始化阶段读取集群拓扑信息，重新排布训练通信域内的rank，把需要高频通信的卡尽量放在同一个交换域内。调整之后AllReduce平均时延降了大约30%，这个优化在刚开始搭框架时就要做进去，否则后面扩规模还会反复碰到。

6.4 轨迹数据拷贝路径绕远路

第四个坑相对隐蔽。我们最初在共卡模式下，采样侧产生的轨迹数据从NPU显存搬到Host内存，再通过进程间通信传给训练进程，训练进程再把它搬回NPU侧做训练。多了一次完全没有必要的搬运。

排查时看数据管线延迟，发现大部分时间耗在数据搬移而不是计算上。后来改成共享内存零拷贝方案，采样侧把轨迹数据直接写到共享内存映射区域，训练进程直接读取，跨过一次数据复制，管线延迟明显下降。这个优化很不起眼，但它在采样频率很高的时候至关重要，积少成多，省下来的时间相当可观。

结合这段时间的实践，还有一点想对新接入的团队强调：别急着追求大集群，先把单机、小集群的链路跑通，把算子兼容性、调度稳定性、权重新鲜度这些问题在一个小环境里解决干净，再往大了扩。昇腾生态的软件栈和GPU生态有很多细节差异，但这些差异恰恰需要通过小规模验证才能暴露清楚。框架本身只是工具，把RL闭环的每个环节都吃透，集群规模对他来说才只是时间问题。

本文还有配套的精品资源，点击获取