MiniCPM5-2B-DSpark：OpenBMB悄然开放MiniCPM5-2B权重，配备为速度而生的草稿模型

六周前，MiniCPM5-2B还只是一个承诺。2026年7月19日，它作为位居Artificial Analysis Index榜首的sub-4B模型在上海WAIC大会上亮相，并附带了一份路线图说明，称开放权重"即将"推出。本周，"即将"化为了现实，但没有任何大肆宣传。2026年9月6日，OpenBMB将旗舰版MiniCPM5-2B代码库以Apache-2.0许可证推送到Hugging Face；21分钟后，又推送了MiniCPM5-2B-DSpark——一个拥有3.238亿参数的草稿检查点，其唯一任务是在DSpark推测解码算法下加速MiniCPM5-2B的解码。2026年9月7日，GPTQ构建版本也随之发布。截至本文撰写时，我们找不到任何公告、发布帖或更新日志条目；这次发布是以代码库在十一天时间内悄然转为公开的方式浮出水面的。

这是一篇“目前已知信息”性质的报道，叙事框架很关键。MiniCPM5-2B-DSpark 并非独立聊天机器人，也不是新的旗舰模型——它是一个加速器：一个轻量、快速的模型，先行于 MiniCPM5-2B 提出 token，再由 MiniCPM5-2B 并行验证。离开目标模型，它便毫无用处；而正是其目标模型让它值得关注。OpenBMB 在 7 月承诺的 MiniCPM5-2B 开放权重版本，如今确实已上线 Hugging Face；随其一同发布的草稿模型，正是该厂商推荐的以实用速度运行它的方案。下文未明确注明出处的所有信息，均直接取自这两张模型卡及其仓库。

发布了什么，以及何时发布

2B系列以滚动式、无预告的方式公开发布，最新条目优先：

• 2026-08-27 — MiniCPM5-2B-Base 和 MiniCPM5-2B-SFT 发布，即原始预训练检查点与监督微调检查点。

• 2026-09-01 — MiniCPM5-2B-Midtrain，智能体中期训练阶段。

• 2026-09-05 — MiniCPM5-2B-MLX 和 MiniCPM5-2B-GGUF，即 Apple-Silicon 与 llama.cpp 格式。

• 2026-09-06 — 先是旗舰版 MiniCPM5-2B 仓库，21 分钟后是 MiniCPM5-2B-DSpark。

• 2026-09-07 — MiniCPM5-2B-GPTQ，量化服务格式。

它们均采用Apache-2.0许可证——即ModelBest早在5月份为MiniCPM5-1B系列所用的那份许可证。序列中较早的检查点在社区中依旧基本没有任何信号：每个都只有屈指可数的下载量和点赞数。这正是权重在陆续放出、而非协同发布的标志：各工件按依赖顺序出现（先是基础模型和SFT模型，最后才是量化与草稿格式），并没有哪一天充当发布日。

MiniCPM5-2B-DSpark 究竟是什么

推测解码将生成过程拆分为一个廉价的提议器和一个昂贵的验证器：小型草稿模型猜测接下来几个 token；大模型在单次前向传播中检查所有这些猜测，并接受它认同的内容。当草稿校准良好时，你只需一小部分成本就能得到大模型的输出；当它出错时，也只不过浪费一次验证步骤。DSpark 是这一想法的一种具体实现，出自 2026 年 7 月 6 日发布的一篇论文（arXiv 2607.05147，题为 "Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation"）。两个设计选择令它独树一帜：其一，它将并行草稿主干与轻量级顺序模块耦合在一起，使提议块内的各 token 相互依赖，而不是在接近块尾时精度递减；其二，它会根据置信度估计和引擎吞吐量为每个请求定制验证运行的规模，而不是始终验证固定长度的块。

OpenBMB 发布的 DSpark 草稿模型是一个五层 Transformer，参数量 323.8M，采用 BF16 精度（约 648MB）。它基于 Q​wen3 架构家族，但带有 DSpark 特有的附加组件：一个投影器（projector），从目标模型 MiniCPM5-2B 的五个层（第 1、10、20、30 和 39 层）读取其隐藏状态；一个置信度头；以及一个用于对下一个 token 分布建模的小型马尔可夫头。其配置提出每次前向传播处理一个由七个 token 组成的块。它的参数量大约是 MiniCPM5-2B（2.5B 参数）的八分之一，是为主流开源 checkpoint 发布的最小的草稿模型之一——而这正是面向边缘设备的模型的要点所在：草稿模型必须足够廉价，使得在一台设备上运行两个模型仍能胜过只运行一个模型。

上述仓库是草稿模型对外公开的全部内容：一个 README、一个配置文件、一个 safetensors 文件，以及一张模型卡，其训练描述显示共有 1,959,525 个序列（7.05B 个 token）由 MiniCPM5-2B 从通用、数学和代码提示中生成，并使用交叉熵、L1 与置信度相结合的目标函数训练了六个 epoch。该检查点本身并未被单独用作生成式模型。

OpenBMB 公布的数字，皆如实标注

草稿模型的模型卡报告了一项重要指标——接受长度，即目标模型从每个七词元块中平均接受的提议词元数量。该评估在 MiniCPM5-2B 的输出上运行，涉及三个领域，最多生成 4,096 个词元：

• 数学 — 贪心解码（T=0）平均接受 6.05 个 token；T=1.0 采样下为 4.61。

• 代码：6.11（贪心）；4.44（采样）

• 通用 — 4.16 贪心；3.10 采样。

• 总体得分 — 贪婪：5.52；采样：4.05，满分七分。

这些数字是供应商根据模型卡片报告的，尚未被独立复现。它们描述的也是草稿的命中率，而非实际耗时加速：速度是一项服务端测量指标，取决于目标模型的验证阶段相对草稿提议阶段的成本、批处理占用情况，以及 DSpark 的置信度调度器对验证长度的裁剪。OpenBMB 没有公布这对模型的每秒 token 数。为了了解该方法的性能上限，DSpark 论文报告称，在 DeepSeek 的生产服务系统中，与 MTP-1 基线相比，在相同吞吐量下每用户生成速度快 60–85%——这是该算法在其他场景中表现的一个有用参照，而非对 MiniCPM5-2B 在您硬件上性能的断言。

上方的记分板是该发布版本自身的规格表。请将验收指标视为初步命中率；实际吞吐量上的乘数仍有待通过一次独立的 SGLang 运行来衡量。

草案加速的模型

MiniCPM5-2B 是一个稠密（dense）的 25 亿参数 Transformer 模型——总参数为 2,516,756,480——拥有 42 层、16 个查询头和 2 个 KV 头、130,560 个词元的词表，以及 131,072 个词元的上下文窗口，以 BF16 格式运行，约占用 5GB。从架构上看，它刻意保持中规中矩：是一个标准的 LlamaForCausalLM，没有自定义内核，也没有模型代码分支，这正是它能在众多运行时和芯片目标间轻松移植的原因。在 OpenBMB 自己的内部基准套件上，该模型卡给出的平均分为 53.9，覆盖推理、指令遵循、知识、长上下文、工具使用、编程和搜索智能体等任务——高于同一张表中 Qwen3.5-4B 的 51.1 和 granite-4.2-3B 的 42.7，其中若干单元格（GPQA-Diamond 70.2、HLE 8.9，以及多个长上下文和智能体相关行）被标注为来自 Artificial Analysis，而非内部复现。主要的单任务成绩包括 MATH-500 94.6、AIME 2025 和 2026 均为 86.5、IFEval 86.7、MMLU-Pro 70.8、SWE-bench Verified 46.4。这些是厂商在其自有套件上给出的数据，且模型卡明确说明部分行来自第三方来源；请据此区别看待这组混合数据。

在7月的发布活动中，ModelBest的发布材料引用了Artificial Analysis Index分数17——在4B参数以下的模型中排名第一——而7月的报道提到了512K token的上下文窗口。实际发布的检查点配置了131,072 token的上下文。当发布当天的营销数据与实际发布的配置不一致时，配置才是决定你能运行什么的数字，而在围绕营销数据规划长上下文工作负载之前，了解这一差距是值得的。

运行 MiniCPM5-2B 及其草稿模型

预期的路径是 SGLang，自 v0.5.16 起它已在上游支持 DSpark 算法——这正是模型卡所要求的最低版本。模型卡中的完整服务命令如下：

python -m sglang.launch_server --model-path openbmb/MiniCPM5-2B --speculative-algorithm DSPARK --speculative-draft-model-path openbmb/MiniCPM5-2B-DSpark --speculative-dspark-block-size 7

在贪心解码（T=0）条件下，DSpark 验证是无损的：输出结果与单独部署 MiniCPM5-2B 完全一致，这使得草稿模型纯粹是一种延迟优化手段。启用采样后，SGLang 的 DSpark 默认采用仅目标模型采样，并可选启用拒绝采样。OpenBMB 还提供了直接使用 Transformers（transformers ≥ 5.6）加载模型，以及使用 vLLM ≥ 0.21 单独服务目标模型的文档方案，此外还附带一个用于智能体工作负载的 minicpm5 工具调用解析器；具体而言，DSPARK 投机路径是由 SGLang 提供的。

边缘级这对组合的关键在于硬件算力：MiniCPM5-2B 以 BF16 精度约需 5GB，草稿模型另需约 0.65GB。凡是原本能单独运行 2B 模型的设备，草稿加目标的组合都能轻松容纳——这正是采用如此小的草稿模型、而非另一款更大模型的原因所在。

什么尚未确认

• 就我们所能找到的而言，没有任何相关公告——OpenBMB 或 ModelBest 的博客上没有，英文或中文的社交媒体帖子也没有。“悄然发布”（quietly shipped）这一说法是字面意义的，唯一的公开界面就是 Hugging Face 上的合集。

• 没有独立评估。草案的接受长度以及 MiniCPM5-2B 的 53.9 套件平均分均为供应商自行报告且未经复现；标记为 AA 的单元格虽来自第三方，但只是快照值，并非在这些确切权重上运行得到的结果。

各处都找不到托管 API，因此如今要采用就意味着得自己运行检查点。发布时七月报道中承诺的 ModelScope 镜像，截至撰文时仍未见踪影。

• DSPARK组合没有给出墙钟加速比数据。5.52 的接受长度是相当高的命中率，但在特定 GPU 上“快多少倍”恰恰是 OpenBMB 未公布的数字。

• 上述上下文窗口的歧义：营销材料称 512K，实际随附的配置却写的是 131,072，而仓库中没有任何内容能将两者衔接起来。

悄然发布的开放权重模型在技术栈中的位置

如今对 MiniCPM5-2B 的如实解读是：这是一场押注——厂商数据亮眼、零独立运行记录、没有服务历史，外加一个真实加速效果未被量测的草稿模型。这正是路由层存在的意义。一个团队若想测试某个小型开源模型的输出能否替代其已在调用的托管模型，只需通过一个 API 就能跑这场对比——OrcaRouter 以提供商挂牌价、零加价代理 200 多个托管模型，因此搭建一个评估周无需任何成本；自动故障转移则意味着，一个几天前的检查点在证明自己期间，永远不必挟持生产路径。这一切都不要求 MiniCPM5-2B 被托管在任何地方；它只是围绕你现有依赖模型的安全网，让你从容判断一个自托管的 2B 是否值得那块 GPU。

请按重要性顺序关注以下事项：针对这对模型的一次独立SGLang DSPARK运行，报告真实的每秒token数，因为接受长度只是代理指标而非基准；一份正式公告或ModelScope镜像，确认该版本已最终发布；以及有托管服务商采用MiniCPM5-2B——如果真有服务商采用，你从我们这边支付的价格就是该服务商自己的当日标价，因为这才是直通（pass-through）的含义。与此同时，在这两者之中，草稿模型才是更有意思的成果。一个五层提议模型，目标模型每七个token会接受其中的五个半，这正是“让人感觉很小的小型边缘模型”与“让人感觉像在同样设备上运行更大模型”之间的差别。