摘要 ：2026 年 9 月，OpenBMB（面壁智能）正式发布 MiniCPM5-2B：一个 25.2 亿参数的稠密 Transformer，Apache-2.0 协议，权重和全部训练数据同步开源。官方口径是 34 项基准均值 53.9，发布时 Artificial Analysis 的 AA-Index 在 sub-4B 档位排第一。这篇测评不复述通稿。我直接解析了本地 GGUF 权重文件的元数据，在 4GB 显卡上跑了一整套实测，并把后训练配方拆到具体步骤：SFT、专用 RL Teacher、On-Policy Distillation。文中数据分两类，本地实测与供应商口径，后者已逐一标注。
测试环境：Intel i5-12400F / NVIDIA GTX 1650（4GB 显存）/ 32GB DDR4 / Windows + Ollama 0.33.3 / opencode 客户端。所有本地实测数据均为作者本机测量。
0. 为什么值得盯住一个 2B 模型
2026 年的开源市场不缺大模型，缺的是在入门硬件上跑得动的智能。手机、办公机、入门独显用户是被大模型厂商选择性忽略的长尾，端侧模型要回答的问题很具体：多小的参数、多低的显存，能换来够用的推理、编码和工具调用能力？
MiniCPM5-2B 没有按"小模型=轻量版"的思路做减法。它把混合推理（Think/No-Think）和原生工具调用都塞进了 2.5B 参数，还配了 128K 原生上下文。与其说是妥协，不如说是在试探 2B 参数的上限能摸到多高。
1. 从 GGUF 二进制里读出的结构信息
我直接解析了本地 MiniCPM5-2B-Q4_K_M.gguf（1,561,318,368 字节，约 1.45 GiB）的 GGUF v3 元数据，得到下面的结构信息，均为本机一手读取：
| GGUF 字段 | 值 | 解读 |
|---|---|---|
general.architecture |
llama |
标准 LlamaForCausalLM，无需定制内核即可跑主流引擎 |
general.name |
MiniCPM5 2.6B |
权重内命名口径；官方参数量为 2,516,756,480（含 embedding），约 2.52B，两者略有出入 |
llama.block_count |
42 | 网络深度 |
llama.embedding_length |
2048 | 隐藏维度 |
llama.feed_forward_length |
6144 | FFN 宽度（约 3 倍 embedding） |
llama.attention.head_count / head_count_kv |
16 / 2 | GQA，16:2 压缩比 |
llama.attention.key_length / value_length |
128 / 128 | 每头 KV 维度 |
llama.context_length |
131072 | 原生 128K 上下文 |
llama.rope.freq_base |
5,000,000 | 高频基数，为长上下文预留 |
llama.rope.dimension_count |
128 | RoPE 作用维度 |
llama.vocab_size |
130,560 | 词表 |
tokenizer.ggml.model / pre |
gpt2 / minicpm5 | 分词器族与预处理 |
| 表里有几个数字值得多说两句： |
- GQA 16:2。2 个 KV 头服务 16 个查询头，KV 缓存量直接降到 1/8。这是 128K 长上下文能塞进小显存的前提之一：42 层 × 2 KV 头 × 128 维，配合 q8_0 量化，每 token 的 KV 开销约 21KB，第 4 节有明细。
- rope.freq_base = 5,000,000。比 Llama 系列常见的 500,000 高一个量级。长上下文扩展惯用的组合是"高频基数 + 训练时上下文插值"，这也解释了 128K 为什么不需要额外 YaRN 脚本就能开箱即用。
- 同架构的另一面。标准 LlamaForCausalLM 意味着 vLLM ≥ 0.21.0 原生加载、SGLang 内置 minicpm5 工具解析器、Ollama / LM Studio 直接跑。零 fork、零魔改，端侧生态扩散靠的就是这个。
注：部分发布通稿提到"512K 超长上下文"，但权重文件内
context_length为 131,072。本文实测一律按 128K 口径执行，超出官方 config 的宣称请以实际部署验证为准。
2. 训练配方：UltraData + 三段式后训练，把"专家"蒸馏回 2B
MiniCPM5-2B 的公开材料把训练流程讲得相当透明（开源方 GitHub、HF 模型卡、MiniCPM 技术报告），这也是它值得认真测的原因：开源的不只是权重，还有方法论。
2.1 数据、数据、还是数据
官方发布了整个 UltraData 分级数据体系：
- 预训练语料：Ultra-FineWeb（系列）、UltraX
- 能力语料：UltraData-Code、UltraData-Math（配合 mid-training）
- 后训练语料 ：UltraData-SFT-Agent-2609（SFT）、UltraData-RL-2609（RL）
模型与数据同牌照发行，在小模型厂商里仍然少见。
2.2 三段式后训练
公开资料描述的后训练分三步：SFT → 专用 RL Teacher → OPD 蒸馏。
- SFT：用数千亿 token 量级的 deep-thinking / hybrid-thinking SFT 数据打底，建立深度思考、混合思考与通用对话能力（MiniCPM5-1B 公开口径为各 200B tokens，2B 按同配方放大）。
- 专用 RL Teacher：针对数学、代码、闭卷问答、写作等方向分别训练 RL 专家。MiniCPM5-2B 一共合并了 16 个 RL 专家模型，其中 5 个面向 Agent 场景（供应商口径）。推理 RL 用 DAPO-Math-17k 数据集加两阶段长度调度，混入 TriviaQA、NQ-Open、LongWriter-Zero-RLData、合成可验证 RLVR 数据及 pair-wise RLHF 信号。
- OPD（On-Policy Distillation） ：把多位 RL 教师的能力蒸馏回同一个发布模型。实现上参考了 Thinking Machines Lab 的 On-Policy Distillation 与 THUNLP 的《Rethinking On-Policy Distillation》，用反向 KL 散度替代 verification-based advantage，并在序列每个位置对师生双方 logits 做双边 top-k 采样取并集，监督信号准确，训练开销也可控。
官方公告口径下，RL + OPD 两个阶段合计的增益是：推理/通用任务平均 +10.96 分，Agent 任务平均 +6.96 分（供应商口径；1B 版公开的"平均 ↑16 分、超长响应率 ↓29pp"出自同一套方法论）。
这套配方的逻辑很直白：先造专家，再把专家压回一个模型。16 个 RL 教师只在训练期存在，发布时只剩一份 2B 权重，教师的"慢思考"留给训练，学生拿到"快反应"。同期发布的 DSpark 草稿模型（用于投机解码）思路相同：训练端用蒸馏压缩智能，推理端用投机解码加速，两头都在压低本地推理的算力成本。
3. 能力画像：推理与工具调用
3.1 混合推理：一份权重，两种模式
核心卖点是聊天模板里的 enable_thinking 标志。同一份 checkpoint，承担两个角色：
| 模式 | enable_thinking |
官方采样建议（temperature / top_p） | 定位 |
|---|---|---|---|
| No-Think | false | 1.0 / 0.95 | 快问快答、实时对话 |
| Think | true | 0.9 / 0.95 | Agent 决策、高难推理 |
| 多数 2B 级模型要么全程开思考（慢），要么全程关（笨）。MiniCPM5-2B 把深度推理和快速响应放进同一份权重，由协议层按需切换。 |
3.2 原生工具调用：XML 风格 + 全生态接通
tool calling 采用 XML 风格输出，vLLM 与 SGLang 都把它作为原生解析器（minicpm5 parser）内置。我通过 Ollama 的 OpenAI 兼容接口做了标准 function calling 实测：
- 请求：注册一个
get_weather函数，任务用中文："帮我查一下北京的天气"； - 结果：
finish_reason = tool_calls，返回{"city":"Beijing"}。参数抽取准确，中文任务和英文参数名混排没有冲突。
也就是说，本地 2B 模型可以像真正的 Agent 一样调用工具，而不是停在给文字建议。这在 2B 级里并不多见。
3.3 横向坐标：53.9 意味着什么
把官方 34 项基准均值 53.9 放进坐标系（以下均为供应商口径）：
- 对比集内的 2B 级强手 LFM2.5-2.6B、Qwen3.5-2B、Gemma-4-E2B-it，MiniCPM5-2B 全面领先；
- 对比集内 4B 级最优是 51.1（Qwen3.5-4B 级别），2B 反过来压过 4B；
- SWE-bench Verified 46.4（供应商报告），这是编程 Agent 落地的主战场分数；
- AA-Index 17 ，发布时 sub-4B 第一（Artificial Analysis AA v4.1 口径）。
官方列出的优势最明显的领域：代码、数学、长上下文理解、工具使用与 Agent 任务。这几项正好是当前 Agent 应用最吃重的能力。
4. 4GB 显存上的部署实录
本节全程本机实测：GTX 1650 4GB / i5-12400F / 32GB DDR4 / Ollama 0.33.3，已开 OLLAMA_FLASH_ATTENTION=1 与 OLLAMA_KV_CACHE_TYPE=q8_0。
4.1 测得的性能数字
| 指标 | 实测值 | 备注 |
|---|---|---|
| 短回复生成 | 约 73.7 tok/s | 热态，149 token 级输出 |
| 长回复生成 | 约 58.6 tok/s | 678 token 中文连续输出 |
| 冷加载到首响应 | 约 6.2 s | 含模型加载 + 生成 |
| 加载态显存 | 约 2.92 GB（3578 − 591 静息） | 4GB 卡余量已经不多 |
| 工具调用 | 成功（tool_calls + 参数正确） |
OpenAI 兼容接口实测 |
| 长文本 prefill | 39,600 字符 / 20,416 token 输入 ≈ 161.5 s | 主要瓶颈在 prefill |
| 同机跑 Qwen3-4B-Thinking 只有约 29 tok/s（含思考 token）。MiniCPM5-2B 在 4GB 卡上的生成速度落在 59~74 tok/s 区间，体感已经接近云端服务。 |
4.2 上下文窗口的显存占用（为什么 128K 会"太卡"）
KV 缓存近似公式：
KV字节数/上下文token ≈ 层数 × 2(K,V) × KV头数 × 头维度 × 量化字节
= 42 × 2 × 2 × 128 × 1(q8_0)
= 21,504 B/token| 上下文窗口 | KV 缓存估算 | 权重加载 | 合计估算 | 4GB 卡结论 |
|---|---|---|---|---|
| 8K | 0.18 GB | ~1.36 GB | ~1.6 GB | 舒适 |
| 64K | 1.41 GB | ~1.36 GB | ~2.8 GB | 满载可跑，实测 2.92 GB（含少量激活与驱动开销） |
| 128K | 2.81 GB | ~1.36 GB | ~4.2 GB | 超出显存 → 溢到内存 + PCIe 回吐 → 卡顿 |
| （表中权重加载为 Ollama 的显存占用口径，比 GGUF 文件体积约 1.45 GiB 略小，属正常差异。） | ||||
| 调优过程是这样的。默认 8K 上下文对 Agent 明显不够，opencode 光 system prompt 加工具定义就要吃掉几千 token。升到 128K，模型原生支持，但 4GB 显存放不下"权重 + KV 缓存"的组合，推理被 PCIe 回吐拖垮。最终稳定在 64K 窗口：既覆盖 Agent 场景的文件和工具上下文需求，又不越过显存预算。 | ||||
调优方法 （可复现）：用自定义 Modelfile 重建 Ollama 模型并固定 num_ctx： |
dockerfile
FROM MiniCPM5-2B-Q4_K_M.gguf
# num_gpu 设为 999，表示把全部层放进 GPU
PARAMETER num_ctx 65536
PARAMETER num_thread 6
PARAMETER num_gpu 999
PARAMETER temperature 0.7
bash
ollama create minicpm5-64k -f Modelfile4.3 客户端集成的坑（与 Qwen3-4B 一脉相承）
在 opencode 里接入自定义模型，必须显式声明能力，否则框架会把它当纯聊天模型对待：能对话，绝不调用工具。
json
"minicpm5-64k": {
"name": "MiniCPM5-2B-64K (local)",
"tool_call": true,
"temperature": true,
"attachment": false,
"limit": { "context": 65536, "output": 4096 }
}另外两处容易被忽略：客户端的 context 上限要和 Ollama 的 num_ctx 同步，否则客户端会先于服务端截断；调试接口时中文务必显式用 UTF-8，PowerShell 默认编码会把中文打成问号，很容易误判成"模型不会回答"。
5. 局限与边界
- 长上下文的能力被 prefill 速度锁死，而不是被上下文长度锁死。4 万字输入实测 prefill 约 161 秒，128K 窗口在 4GB 卡上是"能载入但跑不快"的纸面能力。想真正用上长上下文，要么换更强的显卡，要么接受长输入等待。
- input-stage 的工程优化是当前短板。生成快、prefill 慢，是本地小模型部署的共性瓶颈，MiniCPM5-2B 没有豁免。
- 2B 终究是 2B。它擅长执行"探索→定位→行动"这类机械化的 Agent 流程；深层逻辑漏洞挖掘、大型架构重构、复杂多跳推理，和云端旗舰仍有代际差距。
- "53.9"是供应商口径，SWE-bench、AA-Index 等数字都需要第三方复测确认。本文能确证的，只有本机实测的速度、显存、工具调用与上下文承载能力。
- 未验证项：DSpark 投机解码、Think 模式在 OpenAI 兼容接口下的端到端链路、512K 宣称，均未在本环境完成全量验证。
6. 当下的坐标与未来的走向
6.1 它对 2026 年的端侧市场意味着什么
MiniCPM5-2B 把"端侧旗舰"的门槛抬高了一档。
- 它证明小模型可以不靠堆参数，而是靠更高质量的数据和更聪明的后训练，追平甚至反超上一代 4B。"2B 均值压过 4B 级"是一条可以复制的路径。
- 标准 LlamaForCausalLM + API 级工具调用 + 权重与数据双开源，vLLM / SGLang / Ollama / LM Studio 全栈零改动上手。
- 它也把上下文长度和显存预算的矛盾摆到了明面上：模型给 128K，但 4GB 显卡只买得起 64K 的运行成本。上下文不是白送的，得先付得起 KV cache 的显存。
6.2 端侧 LLM 的三条技术主线
结合 MiniCPM5-2B 的配方，可以抽象出端侧模型未来三五年会继续深化的三条主线：
- 训练端蒸馏 + 推理端投机。OPD 把多位教师压回一份小权重，DSpark 用草稿模型加速解码。思路是把智能尽量提前沉淀，把算力留给在线推理。
- 上下文作为第一公民。原生 128K 起步、RoPE 高频基数、GQA 压 KV，是三件套。未来比拼的不再是"能做多长"，而是"多长的上下文在成本内可用"。量化 KV、稀疏注意力、KV 复用是下一阶段的必争之地。
- Agent 原生优先。SFT 语料、RL 教师、评测指标都在向"工具调用 + 长上下文"倾斜。"能不能对话"退居二线，"能不能干活"成了端侧模型的选拔标准。
6.3 需要警惕的地方
小模型每"越级"一次，就是对可复现性的一次考验。权重开源只是第一步，训练数据、蒸馏配方、评测口径能否经受第三方复测，决定 MiniCPM5 系列能走多远。对开发者来说，值得采信的是能力可声明、行为可验证的部分（工具调用、速度、上下文承载力），其余的，请以自己机器上的实测为准。
7. 结语
三点总结：
- 架构：标准 Llama 骨架，GQA 16:2 压低 KV，RoPE 高频基数托起 128K，一行定制内核都不用写。
- 训练：数千亿 token 的 Thinking SFT、16 位 RL 教师、反向 KL 的 OPD 蒸馏，把推理和工具调用一起塞进同一份 2B 权重。对 2B 来说，这个投入不算小。
- 工程 ：4GB 显卡上能跑进 59~74 tok/s，工具调用一次通过。但 64K 才是显存预算内的甜点区间，128K 更接近纸面能力。
端侧 LLM 的竞争，已经从"能不能跑"转到"跑得多聪明、多便宜"。MiniCPM5-2B 值得下载，也值得你用自己的机器把它的边界再测一遍。
本文全部本地实测数据采集于 2026 年 9 月，环境：Windows + Ollama 0.33.3 + opencode；GGUF 元数据通过对 MiniCPM5-2B-Q4_K_M.gguf 二进制直接解析获得。官方数据（34 项基准均值、SWE-bench Verified、AA-Index、RL+OPD 增益幅度）来自 OpenBMB 官方 GitHub/HF 模型卡、vLLM Recipes 及公开报道，均标注"供应商口径"，请以第三方复测为准。