可扩展的强化学习：MiniCPM5-2B 后训练框架 Meshy 开源，四大创新提高端侧智能密度
过去大模型的强化学习阶段像一条流水线，模型先生成数据，系统再对结果进行评价，最后完成参数更新，所有环节按部就班、同步推进。
但随着人工智能从单轮问答逐步走向复杂任务执行，大模型不仅要持续生成和学习，进行多轮工具调用，还要与外部环境互动，并同时处理不同阶段、不同版本的数据。原本清晰固定的训练流程，也因此变得更加动态和复杂。
这种情况下，以 Single-Controller 为代表的中央控制架构开始显得力不从心。所有数据汇集到单一控制器再分发出去，容易造成传输拥堵；一个环节慢了，全链条都得等着，效率大打折扣；任务变复杂后，管理不同版本和阶段的状态也成了一笔糊涂账。整个系统的灵活性和扩展性都受到了制约。
为此，面壁智能联合 OpenBMB 开源自研强化学习框架 Meshy。它通过服务化架构实现结构性创新，彻底摆脱了对中央控制器和 Ray 的依赖，将推理、训练、奖励计算等角色拆分为独立运行的服务，并通过统一数据队列 TransferQueue 协同，支持同步训练、异步强化学习、流式训练和在线蒸馏等多种模式。
这一架构减少了不必要的数据通信与调度开销，使得大模型强化学习更灵活高效，从而进一步提升了智能密度。
与传统强化学习框架相比，Meshy 进行了四大技术创新。
角色服务化，像搭积木一样按需组合
在 Meshy 中，推理、训练、Rollout 等每一种角色都被定义为一个独立的服务。它们各自负责自身完整的业务逻辑，并通过数据队列契约 TransferQueue 与其他服务协作。这种设计相当于将原本中央控制的「大工厂」拆分为多个「独立车间」，各司其职。
在具体实现上，开发者在 Meshy 中用一份配方文件来定义整个训练流程，该配方由两部分配置组成。
ServiceGroup 用来描述一组相同角色的服务实例，包括稳定的 ID 、类型化的 config、副本数量以及每个副本使用的 GPU 数。
ColocationRing 描述哪些服务共置同一组 GPU，以及它们之间的调度模式与顺序。
这种设计带来的最大好处是灵活性。开发者可以像搭积木一样自由组合不同角色，只需要通过 ServiceGroup 选择参与的角色， TransferQueue 定义角色间的数据传输，由 ColocationRing 指定共置模式即可实现多种训练方案。
这种拆分让算法流程和系统实现互不干扰。想加新角色，写好服务、配好资源就能用，原有的推理、生成和训练服务统统不必改动本身。如此，强化学习系统更容易加入新能力，也为构建同步、异步、流式和蒸馏等不同训练流程提供了统一基础。
确定性拓扑推导，启动更简单
服务拆分后，首先要解决一个实际问题：每个服务应该运行在哪台机器、使用哪些 GPU 及端口。常见做法是使用注册中心或配置文件，统一记录和分发这些信息，但系统也因此增加了需要维护的组件。
Meshy 采用了一种更简单的方式——纯函数计算拓扑。
简单来说，系统采用预训练式的 SPMD 方式启动，一条 torchrun 命令在每张 GPU 上都会启动一个叫做 ignitor 管理进程，该进程不训练计算，只负责推导拓扑、拉起分配到本卡的服务，并管理其运行状态。
所有 ignitor 启动后，会先拿到全局的 GPU 列表，了解每张卡所在的主机和编号。随后，每个 ignitor 根据同一份 recipe（即服务配置方案）和 GPU 列表，各自独立执行同一个确定性纯函数，该函数可以计算出每个系统的完整部署信息。端口也按固定规则生成。
由于所有进程使用的是相同的信息和相同的计算规则，只要服务配置和 GPU 环境不变，每个进程算出的结果就完全一致，因此各进程之间无需传递服务位置，算完后只管启动分配到自己这里的服务即可。
这种设计的最大好处是轻量。系统不需要额外搭建注册中心，部署关系清晰可追踪。同一份配置在相同 GPU 环境下能得到一致结果，方便复现和调试。GPU 数量不足、端口冲突或配置不匹配等问题在启动阶段就能暴露，不会等到训练跑了一半才被发现。
数据驱动协作，服务更高效
Meshy 最大的创新之一，是重新设计了服务之间的协作方式。它让不同服务围绕同一个数据系统独立运行、自主推进。这个系统就是 TransferQueue（简称 TQ），数据传输和流程控制都建立在它之上。
TQ 是一个开源的数据传输系统，可以把它理解为几张固定容量的「共享数据表」。每张表称为一个分区，每条样本对应一行，行中包含多个命名的数据列，每条数据又包含多个可分别写入的数据项。不同服务可以围绕同一条数据补充各自负责的内容，下游服务只需确认自己需要的数据项已经全部准备就绪，就可以直接读取并开始计算，算完再把结果写回 TQ，供后续服务继续使用。
数据协作：内容齐全，即可开工每个服务会提前声明自己需要哪些数据，定期查询、按需读取，在本地完成计算后将结果写回 TQ。例如，训练服务需要教师模型的评分，只需将评分列加入读取条件；评分写入后，样本便自动可读，无需再发送「评分完成」通知。各服务的读取记录分别维护，不会互相争抢，末端服务用完样本后负责清理，避免存储持续膨胀。
流程同步：用简单信号协调节奏对于需要显式传递的控制信息，Meshy 会在 TQ 中使用独立的数据分区。例如，在同步强化训练中，Trainer 每完成一个训练 step，就会在 gen-gate 分区写入包含最新权重版本的 gate 信号。Rollout 在每次读取数据集前访问该分区，获取当前权重版本，并据此决定本次读取的样本数量，从而控制生成与训练之间的节奏。
简单来说，数据准备好了，下游就自动开工；需要统一节奏时，通过单独的信号来协调。大块数据不再经过中央节点，各个服务既能独立运行，又能保持步调一致。TQ 把数据搬运和流程控制彻底分开，用一套轻量、可追踪的机制实现了服务之间的高效配合。
多角色共享 GPU，有限算力灵活流动
在强化学习训练中，训练引擎和推理引擎通常会放置在同一组 GPU上，系统根据训练需要，通过训推切换实现算力资源的最大化利用。
但当训练流程中加入 Teacher 等更多角色后，GPU 的切换关系会变得更加复杂。过去的框架通常需要开发者针对不同的角色组合，分别编写资源交接和显存切换逻辑，训练配方一旦发生变化，就可能需要重新适配。
为此，Meshy 设计了基于令牌环的多角色共置机制。谁需要使用 GPU，谁就申请令牌；获得令牌后才能开始计算。任务完成后，服务会自动释放占用的显存，将令牌交给下一个角色。如果暂时没有其他角色申请时，GPU 则默认交给推理服务，保证资源持续工作。
以推理、教师模型和训练共同运行的蒸馏场景为例，推理服务平时负责生成数据。当教师模型需要评分，或训练服务需要更新参数时，它们可以暂时接管 GPU。任务完成后，GPU 再交还给推理服务。
这一过程均由 TransferQueue 传递申请和授权信号。开发者只需在配置中说明哪些角色共享 GPU 及其所属的令牌环，并为各服务实现统一的显存释放和恢复接口，就能完成多角色协作。
这种设计让 Meshy 不需要为每一种训练场景单独写一套适配代码，有限的算力可以在多个角色之间灵活调配，为开发者提供了更简易的开发流程和更高的组合自由度。
基于上述四大机制，Meshy 以数据就绪状态驱动各服务自主运行，样本由生产者直接传递给下游，让生成、打分与训练并行推进，减少了数据经中央节点中转的开销。新增角色时，系统主要承担该角色自身的计算与处理成本，而不再同步加重中央调度负担，从而提升整体资源的利用效率。
这一变化的意义不止于降低成本，更在于为 Agent 训练提供更灵活、可扩展的基础设施。从集中调度转向自主协作，Meshy 让有限算力能够支撑更多角色、更复杂的交互与更高频的训练迭代，为智能体能力的持续提升提供支持。
目前，采用 Meshy 框架训练的面壁智能新一代高智能密度端侧语言基础模型 MiniCPM5-2B 已正式开源。该模型在 Artificial Analysis 综合智能指数评测中位列全球 4B 参数以下开源模型榜首，并以 2B 参数规模初步具备端侧通用 Agent 能力。更多架构设计与实现细节，可参阅官方技术博客。
➤ Meshy 框架开源链接
GitHub：
🔗 https://github.com/OpenBMB/Meshy
博客：
🔗 https://maydomain.notion.site/meshy-blog-zh