MiniCPM-V-4.7-1B-DSpark：一款未作任何公告便发布的 213M 草稿模型

MiniCPM-V-4.7-1B-DSpark 是一个拥有 213,547,777 个参数的检查点，却无法回答一个问题。它不读取图像，不能进行对话，单独部署时也生成不出任何值得一读的内容。它的全部工作就是位于一个模型——MiniCPM-V-4.7-1B——之前，预测接下来的十五个 token，以便一个小型的手机级视觉语言模型能在单次前向传播中验证其中一块 token，而不是逐个生成它们。

该文件为 0.85 GB，采用 Apache-2.0 许可，于 2026 年 10 月 8 日 04:26 UTC 出现在 Hugging Face 上，与更大的 35B-A3B 兄弟模型的草稿出现在同一批次中。四天后，父模型卡仍将其视为脚注：该草稿仅出现一次，作为权重表中的一行，并隐藏在一个折叠的“投机解码（DSpark）”开关之后。OpenBMB 没有为其发布博客文章，没有技术报告，项目自身的 GitHub 文档中也没有相关条目。

那种沉默才是有意思的部分，因为正是这个特定文件让某些事情成为可能。在 MiniCPM-V 4.7 家族中，它是第一个核心主张——1B 视觉模型能在手机上以可接受的水平运行——可以由 OpenBMB 之外的人检验的产物。下文始终把两堆东西分开：哪些是磁盘上你能打开的文件，哪些是厂商在旁边印出的数字。

仓库里实际有什么？

四个文件。这就是全部：.gitattributes、README.md、config.json，以及单独一个 model.safetensors，其中保存着 854,204,052 字节的 BF16 权重。仓库里没有分词器，因为并不需要有——草稿模型借用目标模型的分词器，而它配置中的词表正是父模型的 248,094 个词元，分毫不差。如果一个草稿模型的词元无法与目标模型的词元一一对应，它就无法提出任何目标模型会接受的内容，所以共享词表是必需条件，而非便利之举。

Hub API 记录该仓库的创建时间为 2026-10-08T04:26:19Z，最后修改时间为 2026-10-12T14:29:57Z，标注为英语和中文，采用 Apache-2.0 许可证，在撰写本文时有三点赞和一次下载。最后一个数字才是要牢牢记住的那个。四天过去，只有一次下载，而这个文件小到用手机网络就能获取。

架构字段显示为 Qwen3DSparkModel，其 model_type 为 qwen3，这是合理的而非奇怪：MiniCPM-V 4.7 的语言主干源自 Qwen3 系列，因此从同一家族裁出的五层桩正是你预期会看到的东西。并非父模型缩小副本的，是这个桩与它交互的方式。该配置启用了一个 dflash_config，其中包含 projector_type: "dspark"、enable_confidence_head: true、confidence_head_alpha: 1.0、confidence_head_with_markov: true、markov_head_type: "vanilla" 以及 markov_rank: 256。那个置信头是从 DSpark 方法中拿来的部分：它是用于估计一个提议块中有多少值得验证的机制，这正是服务配置会暴露一个关闭自适应验证的开关的全部原因。

规格说明，以及每个数字为何是那个值

草稿侧，根据卡牌和配置，二者一致：

• 草稿参数 — 213,547,777，全部 BF16，位于 0.85 GB 的单文件检查点中

• 草稿深度 — 5 层，全部采用全注意力，隐藏层大小 1,024，中间层大小 3,584，SiLU 激活

• 注意力几何结构 — 8个查询头对2个键/值头，头维度为256，分组查询注意力

• 每次前向传播的 token 数 — 15，在配置中表示为 block_size: 15

• 位置范围 — RoPE theta 为 10,000,000，采用 256 维旋转嵌入，且 max_position_embeddings 设置为 262,144，与父模型的 256K 窗口一致

• 轻点图层 — [3, 7, 11, 15, 19]，属于父级的 24 个图层（num_target_layers: 24）

• 词表 — 248,094，与目标模型的分词器绑定，并在 248,076 处设有一个专用掩码标记，用于半自回归草拟步骤

其中有两行值得多看一眼。第一处是引出层。草稿模型并不读取父模型的最后一层；它读取的是散布在父模型深度中的五个层的隐藏状态，再通过一个dspark投影器将它们投影出来。网络中段的隐藏状态更容易对齐，而且仍然携带着最后一层已经压缩进下一 token logits 的信息。第二处是 256 的头维度与 1,024 的隐藏大小之间的对比。在一个窄模型上，这是刻意加宽的头，而配置项设定了tie_word_embeddings: false——嵌入矩阵与输出投影保持分离，而非共享，因此参数量把两者都计算在内。

总而言之，草稿模型的大小约为目标模型的五分之一，但形状完全不同。作为对比，35B-A3B 同系列模型的草稿有 389,223,169 个参数，从 40 层中抽取[3, 11, 19, 27, 35]层。之所以有两个草稿、每个目标模型各配一个，是因为草稿只对它训练时所依据的词表和中间表示有效。

验收表是一张模型卡，而不是一次测量。

以下是 OpenBMB 发布的关于这一组合表现如何的全部数值数据，以每验证步骤接受的 token 数表示，并采用自然 EOS 终止以及 max_new_tokens=8192：

• Vision、MMMU — 每步接受 3.452 个 token

• Vision、MathVista — 4.333

• 视觉，CharXiv 推理（验证）—— 4.452

• 视觉，OCRBench — 4.752

• 文本、数学 — 5.891

• 文本、代码 — 5.347

• 文本，常规 — 3.370

该分布区间从5.891下降到3.370，最容易的类别与最难的类别之间相差约1.75倍。这种排序看似不出所料，却也揭示了这些数字背后的某种含义：数学是语言模型所生成的最规则的表面，通用文本则最不规则，而草拟模型的成功率取决于目标输出的可预测性，而非其质量。

有三条注意事项本应出现在那张表上，而这张卡片并未主动说明其中任何一条。

这是自行报告的数据，而该仓库记录在案的下载量恰好只有一次。OpenBMB 之外没有任何人为这个检查点给出过其他人能够查看的验收数字。这些数字出自厂商，是在厂商的测评框架中、用厂商的任务集测得的。

接受长度是这一对模型的属性，而非模型本身的属性。一个自我重复的目标会给它的草稿模型送上一场轻松的胜利，因此这里数值更高并不能证明 MiniCPM-V 4.7-1B 擅长什么。它只能说明其输出有多可预测，而那是另一个问题，答案也另当别论。

而且这并不是一种加速。一个草稿模型提出 15 个 token、其中 3.4 个通过验证，确实仍然能在每次目标模型前向传播中推进多个 token，但验证一个 15-token 块的成本高于生成单个 token，而且每一个被拒绝的提议都付出了代价并被丢弃。要把接受长度换算成实际耗时，需要验证成本、批大小和硬件，而这张卡都没有提供。它确实提供的唯一一个服务配方设置了 --max-num-seqs 1，这是一个调成能跑通、而非调成快的配置。

与同门模型对照来看，这张表会更有用。35B-A3B 草稿模型在代码上得到 7.387，在 MMMU 上得到 5.098；而这个 1B 草稿模型则得到 5.347 和 3.452。更小的目标模型搭配更小的草稿模型时，每步接受的 token 数明显更少，而这是单张卡片无法呈现、两张卡片才能呈现的那类跨系列细节。

训练，以及那个解释整个设计的细节

这份配方只有四行：两百万条训练序列、六个 epoch、AdamW，以及由交叉熵、L1 项和置信度损失组成的联合目标。真正关键的是关于训练数据来源的那一行——回复是由 MiniCPM-V-4.7-1B 自身生成的，来自视觉和文本提示的混合。

那就是自蒸馏，它为像这样的草稿模型设定了构建成本的下限。你无法在不先大规模运行目标模型的情况下训练出一个，而且还要跨两种模态，这意味着你能下载的 0.85 GB 工件只是一个昂贵过程留下的廉价残余。这也解释了为什么草稿模型是一对一配对的，而不是共享的：它模仿的行为是这个模型的行为，而不同目标的输出会训练出不同的草稿模型。

该方法自己的论文 arXiv 2607.05147 并不属于 OpenBMB。它是一篇于 2026 年 7 月 6 日提交、有 33 位作者的论文，将 DSpark 描述为一个推测解码框架，该框架将并行主干与轻量级顺序模块配对，并根据估计的前缀存活概率来安排验证长度。论文报告了其在 DeepSeek-V4 服务系统内部的部署，采用一个名为 MTP-1 的生产基线，并声称在吞吐量匹配的情况下，单用户生成速度提高了 60% 到 85%。这些说法属于该论文和那次部署。没有任何已发表内容将它们与一个基于 1B 视觉模型的五层、213M 草稿模型联系起来，而上文的接受率表是任何人提供的唯一桥梁。

为什么这个文件比它的大小所暗示的更重要

MiniCPM-V 4.7 系列的核心主张是端侧能力。其中 1B 模型卡提供了一张性能与推理时间对比图、一张 1B instruct 版本的总体性能图、一段在 iPhone 17 Pro Max 上录制的未剪辑屏幕录像,以及一句定性描述:1B 变体在综合得分和推理效率上均大幅优于 Qwen3.5 0.8B。它还列出了量化系列——int4、AWQ、GPTQ、GGUF,外加 FP8 支持——以及覆盖 iOS、Android、HarmonyOS、Rockchip、Houmo、Intel、AMD 和 Arm 的首日硬件支持目标。

这些说法全都来自厂商，并未附上任何外部数据，而且其中一条本身就前后不一：卡片文案称其为 1B 模型，而 Hub 侧边栏却显示模型规模为 2B 参数。DSpark 检查点则与这一切性质不同。它只有 0.85 GB，采用 Apache-2.0 许可，并附带一条服务命令——这意味着任何拥有消费级 GPU 的外部方都能在本周运行它，并得出该系列首个由外部实测的数字。不是基准测试分数，而是几乎同样有用的东西：一个可复现的接受长度。

如果有人在 MMMU 上复现出 3.45、在通用文本上复现出 3.37，那么这张卡就是可信的，端侧叙事也迎来了第一个外部数据点。如果验收结果明显更低，那么表中数据是在已发布配方无法复现的条件下测得的，单位推理时间性能图表也会继承这份疑虑。无论哪种结果，都比又一张厂商图表更有价值，而这是该系列中唯一能低成本拿到一个数据点的环节。

运行它，以及尝试的成本

该模型卡附带一个配方，它是一个vllm serve调用，而非空谈。它加载目标 openbmb/MiniCPM-V-4.7-1B，以名称 MiniCPM-V-4.7-1B 提供服务，设置 --max-model-len 40960 和 --max-num-batched-tokens 40960，固定 --attention-backend FLASH_ATTN 和 --mm-encoder-attn-backend FLASH_ATTN，传入一个多模态处理器关键字参数：{"downsample_mode": "4x"}，信任逐请求的多模态关键字参数，并将推测配置指向 DSpark 检查点，使用 "method": "dspark"、"num_speculative_tokens": 15，并关闭自适应验证。默认聊天模板关键字参数会使思考保持禁用。

这一行里有两个细节值得反复读。 --max-num-seqs 1意味着所公布的配置一次只服务一个序列，因此该配方描述的是一种单流延迟配置，而非吞吐量配置。而 4x 视觉下采样模式是母卡所宣传的两种模式中代价较低的一种——同一张卡还提供一种混合 4x/16x 方案，以细节换取速度，而该配方选择的正是这一权衡中偏向速度的一侧。

硬件需求范围与该系列的营销宣传正好相反。1B 目标模型在 BF16 下约为 2 GB，再加上 KV 缓存，而草稿模型又额外增加 0.85 GB，所以这是一项单 GPU 任务——消费级显卡，或具备足够统一内存的工作站——而不是手机任务。父级文档中的端侧路径走的是量化构建和框架，这些都不在本方案中；而按发布状态，DSpark 检查点是 BF16 服务器端产物。

这就留下了一个大多数团队都会撞上的缺口：MiniCPM-V 4.7-1B 真正有意思的版本是端侧版本，而今天无需拥有手机工具链就能运行的版本是服务端版本。如果你当下真正需要的是小型多模态推理，那么最接近的托管等价物是另一个模型——Qwen3 VL 8B Instruct 在 OrcaRouter 上的价格是每百万输入 token 0.18 美元、每百万输出 token 0.70 美元，拥有 128K 上下文窗口，支持文本、图像和视频输入，无需本地权重，也没有需要持续维护的部署方案。MiniCPM-V 4.7 并非 OrcaRouter 上的托管模型，本文也不会假装它是；诚实的说法是，这是完成同一项工作的两种方式，而只有其中一种能在今天下午从目录中衡量出来。

像 DSpark 这样的东西真正体现价值的地方，是那些尚未经过验证的模型场景，而这是一个路由问题，而不是模型问题。一个没有人复现过的草稿模型，恰恰是你希望放在一个可以随时回退的端点背后的那种组件。用一把密钥运行 200 多个模型，供应商标价以 0% 加价直接透传，并在某条路由性能下降时自动故障转移，这意味着一次出错的推理服务实验带给你的只是重试，而不是服务中断——而且由于没有任何加价，目录中任何模型的供应商价格变动都会在当天生效，而不是等到下一个计费周期。

什么能让这个变得可核查？

缺少三样东西，而其中只有一样需要 OpenBMB。

厂商尚未发布任何公告。仓库里有模型卡、许可证和训练配方，但没有博客文章，没有技术报告，项目 GitHub 文档中也没有一行提及——而截至该系列的第一周，这份文档仍将上一代描述为当前一代。检查点落地四天后，父级 1B 模型卡也只是把它作为表格中的一行链接出来，仅此而已。

没有人复现过验收数据，而下载量只有 1。这是最容易弥合、也最重要的缺口，因为这是唯一一个外部测量能切实推动这个家族故事的地方。

而质量问题则完全没有被触及。在整个发布内容中，MiniCPM-V 4.7-1B 没有任何 MMMU 分数，没有 OCRBench 结果，没有文档理解数值，也没有 grounding 指标——那张接受率表是一张关于解码的表，而将很高的接受长度解读为质量信号，恰恰是那些数字诱使人犯下的错误。

所以：一个真实的产物，一份宽松的许可证，一条能用的服务命令，以及一条关于一个此前没有任何证据的模型的真正新证据。下一个值得刷新的文件仍然是父模型的模型卡。