导读9 月 7 日，OpenBMB 发布 MiniCPM5-2B。它当然是一颗面向本地部署的 2B 模型，但这次更值得开发者关注的，是权重之外同时公开的数据、训练配方、强化学习路径和部署入口。它们不能替代真实业务验证，却让“端侧 Agent 的能力从哪里来、下一步该怎么改”有了更具体的检查线索。
2B 跑分领先之外，这次开源多交出了什么？
端侧模型的发布，最容易被压缩成一句话：参数更小，跑分更高，还能在本地跑。
MiniCPM5-2B 的确对准了这个场景。OpenBMB 的模型卡把它定义为面向本地、资源受限场景的 dense 2B 模型；项目仓库的更新日志则标注，它在 2026 年 9 月 7 日发布。模型卡还给出了 BF16、GGUF、MLX、GPTQ 等版本，以及 vLLM、SGLang、Transformers 等部署入口。
跑分也确实是这次发布的一个亮点，不能绕开。OpenBMB 在 9 月 8 日的官方公告中引用 Artificial Analysis 的当时快照：MiniCPM5-2B 的 Intelligence Index 为 23，在 4B 参数以下的开源基座模型中排第一，Agentic Index 为 20。模型卡则按另一套公开比较集报告：它在列出的 2B 级模型中平均分为 53.9，并高于该表所列的更大模型。两组结果都说明，这不是“能勉强塞进设备”的轻量模型；但它们分别受榜单时间点、比较对象和任务口径约束，不能直接推出任意端侧设备或真实任务都同样领先。
图片说明：官方公开比较表摘录中，MiniCPM5-2B 平均分为 53.9，所示的 Qwen3.5-4B 为 51.1；这是项目方列出的比较集，不等同于 AA 指数或真实端侧任务表现。图片来源：OpenBMB MiniCPM GitHub 仓库
但只下载权重，并不等于拥有一个可持续改进的端侧 Agent。
权重更像某次训练的“成品快照”：它告诉你模型此刻能输出什么，却不天然说明能力是如何长出来的。一个 Agent 如果工具调用不稳定、长任务容易丢步骤，开发者真正需要判断的是：问题出在底座数据、后训练样本、强化学习目标，还是推理服务和工具协议。没有训练链路，很多排查最后都会退化成换提示词、换量化版本，或者盲目再训一轮。
这也是这次开源更有意思的地方：它把模型、数据、训练过程与可运行的接口，放到了同一张桌子上。
相关资料
模型卡： https://huggingface.co/openbmb/MiniCPM5-2B
代码仓库： https://github.com/OpenBMB/MiniCPM
一条训练链，先把“谁负责什么”分清
这条链里最容易混在一起的，是数据集、训练方法、训练框架和最终权重。它们不是四个可以互相替换的名词。
数据集负责提供训练时看什么、练什么；训练配方决定不同阶段按怎样的顺序和目标使用这些数据；RL（强化学习）负责用奖励信号继续调整模型行为；Meshy 这类框架则负责把推理、rollout、训练等角色组织起来跑。最后的权重，是这些阶段共同留下的结果。
下面这张图先把它们的职责按顺序拆开。它不是官方训练架构图，也不描述具体实现细节；它只回答一个更基础的问题：当端侧 Agent 表现不好时，排查不该只盯着最后的模型权重。
MiniCPM5-2B 的模型卡把训练分成预训练、中训练和后训练。公开资料中，UltraX、UltraData-Code 等覆盖底座训练的数据精炼与代码数据；后训练则列出 UltraData-SFT-Agent-2609 和 UltraData-RL-2609。前者在模型卡中标为 50 万条 Agent 训练样本，后者标为 8 万余条 RL 样本。
这并不意味着“数据一公开，任何人都能复刻同样成绩”。数据量之外，还有具体的清洗标准、采样配比、训练资源、实现细节与评测口径。但至少开发者能知道：Agent 能力不是在模型部署后凭空出现的，它在训练期就需要工具调用、搜索、代码与长链路任务等不同类型的轨迹和奖励信号。
图片说明：图中把 Agentic RL 与推理、通用任务 RL 并列为教师模型来源，再经 OPD 汇聚到最终模型。图片来源：OpenBMB MiniCPM GitHub 仓库
图里还有一个关键动作：OPD（Online Policy Distillation，在线策略蒸馏）。根据模型卡，项目方先训练多个面向推理、通用任务和 Agent 任务的 RL 教师模型，再把这些能力蒸馏回一个最终模型。换成白话：不是指望一颗小模型在一次训练里同时学好所有任务，而是先让不同方向的训练各自把能力推起来，再把它们合并回可发布的单一权重。
所以，“开源一整条训练链”也不应被误读成全部流程都已经没有黑箱。它真正带来的，是把黑箱拆成了多个能逐一核对的盒子：数据是否公开、训练阶段是否说明、RL 框架能否运行、产物能否部署。对想继续做实验的人，这比只拿到一个聊天效果不错的 checkpoint 更有操作空间。
强化学习不是一个按钮，Meshy 也不是模型能力本身
发布材料里还有两个容易被混为一谈的对象：JustRL II 和 Meshy。
前者是后训练阶段使用的强化学习方法。模型卡称，RL 与 OPD 带来了推理、通用能力和 Agent 能力的提升；但这些数字属于项目方给出的特定 benchmark 口径，不能直接翻译成“本地 Agent 在任何任务上都更可靠”。尤其是端侧运行时，量化方式、设备内存、工具可用性和任务分布都会改变最终体验。
后者是训练系统。Meshy 的官方仓库把一次 RL 运行拆成独立服务：推理、训练与 rollout 等角色通过 TransferQueue 传递数据，并以数据是否就绪驱动控制流。它解决的是“怎样把训练跑起来、怎样安排这些角色协作”，而不是替模型生成更好的答案。
图片说明：蓝色为项目方内部 SFT 基线，紫色为 RL+OPD 带来的增益；图注说明大部分 SFT 分数来自内部评测。图片来源：OpenBMB MiniCPM GitHub 仓库
这层区分很重要。把一个 RL 框架装好，不等于你已经有了适合自己任务的奖励、数据和评测；反过来，即便模型有不错的公开基准，也不代表部署层已经能稳定完成工具调用。模型、方法、训练系统和运行时各自承担不同责任，缺任何一层，都可能让“端侧 Agent”只停在演示状态。
相关资料
Meshy 训练框架： https://github.com/OpenBMB/Meshy
UltraX 数据精炼项目： https://github.com/openbmb/UltraX
对开发者来说，这次开源改变了什么？
我更愿意把它看成一次排查路径的公开。
如果你只是想在本地跑一个能聊天、能生成代码的模型，选合适的格式和推理后端就够了。模型卡已经列出不同格式，也给出了 SGLang 的工具调用解析器配置。这个层面，重点是设备、显存、量化和接口兼容性。
如果你想做一个真正能完成任务的 Agent，问题就会往训练侧移动：任务失败时，是工具描述不清、工具执行环境不可用，还是 Agent 训练轨迹没有覆盖相似场景？如果要做领域微调，已有的 SFT 与 RL 数据结构能提供什么参考，哪些部分又必须按自己的业务重新构造？这些问题不会因为模型只有 2B 参数而自动变简单。
再往前一步，公开训练链的价值还在于让验证更具体。开发者不必把“模型不行”当成唯一结论，可以分别检查：部署是否按官方接口跑通，工具调用是否被正确解析，任务数据是否覆盖，评测是否真的贴近目标流程。每一步都有自己的失败模式，也应该有自己的验收方法。
这才是小模型进入端侧后更实际的变化：讨论不必只停在谁把参数压得更低，也可以追问谁把能力来源、训练过程和部署接口交代得更清楚。权重让人可以开始；一条可检查的训练链，才让人有机会继续往下做。
参考资料
OpenBMB MiniCPM5-2B 模型卡： https://huggingface.co/openbmb/MiniCPM5-2B
OpenBMB MiniCPM 项目仓库： https://github.com/OpenBMB/MiniCPM
OpenBMB Meshy 项目仓库： https://github.com/OpenBMB/Meshy
OpenBMB UltraX 项目仓库： https://github.com/openbmb/UltraX
面壁智能 MiniCPM5-2B 官方公告： https://mp.weixin.qq.com/s?__biz=Mzg3Mzg2MTg2NQ==&mid=2247499182&idx=1&sn=63164223aa7a0e4f1bf8a36a9593d36b
— THE END —
文章仅做学术分享，如有侵权请联系删除，非常感谢！