MiniCPM-V 4.7-35B-A3B-DSpark：OpenBMB 的 389M 草稿模型登场，附带其基础模型从未有过的模型卡

MiniCPM-V-4.7-35B-A3B-DSpark 是一个拥有 389,223,169 个参数的草稿模型。它不回答问题，也看不见图像，单凭自身毫无用处。它的全部工作就是猜测接下来的十五个词元，以便 MiniCPM-V-4.7-35B-A3B 能在一次前向传播中验证一整块内容，而不是一次只生成一个词元。这就是推测解码，而十一天前，OpenBMB 为其新的 35B 视觉语言模型发布了草稿模型，却未在公开场合对此透露只言片语。

让它值得写上整整一页的，不是那份草稿，而是随它一同出现的文档。DSpark 检查点有一张模型卡：一份许可证、一张规格表、一份训练配方，以及一张覆盖七个任务类别的接受长度表。而它那个拥有 350 亿参数的父模型在问世时，这些东西一样都没有。于是，首次有真实数字与 MiniCPM-V 4.7 的发布联系在了一起——而这些数字关乎的是父模型，并且是通过一个 0.78 GB 的文件间接测得的，该文件声称的用途就是让它跑得更快。

以下内容区分了模型卡上写明的信息与模型卡并未确立的内容。验收数值来自 OpenBMB 自身，实验室之外无人复现过。基础模型的基准测试表仍然不存在。

DSpark 检查点究竟是什么

该仓库openbmb/MiniCPM-V-4.7-35B-A3B-DSpark可追溯至2026年10月8日。它是一个单文件检查点——model.safetensors，外加一个config.json和一个 README——采用 Apache-2.0 许可，标注为英语和中文。第二个草稿，openbmb/MiniCPM-V-4.7-1B-DSpark，创建时间早一秒，因此两者是同一批次推送到 hub 的，而不是逐个发现的。

每个草稿模型都只位于一个目标模型之前，而且只位于那一个目标模型之前。卡片上写得明明白白：这个检查点“经过训练，可与 MiniCPM-V-4.7-35B-A3B 及其分词器精确配对”。词表是父模型的，全部 248,144 个词元都属于它，这是硬性要求，而非优化——如果草稿模型的词元无法与目标模型的词元一一对应，它就无法提出任何目标模型可能接受的候选。同样的约束也正是为什么同系列草稿模型要单独存在，而不是让一个草稿模型服务整个家族。

该架构并非父模型的缩小副本。它是一个五层注意力堆栈，隐藏宽度为 2,048，8 个查询头对 2 个键/值头，中间大小为 6,144，且 RoPE 的 theta 为 10,000,000。其架构字段显示Qwen3DSparkModel——正是父模型语言栈所源自的同一个 Qwen3 系列骨干，但被缩减成了一个桩。

有趣之处在于桩模型如何与目标模型通信。它并不读取目标模型的最终层。它从五个中间层抽取隐藏状态——[3, 11, 19, 27, 35]，即父模型 40 层中的这些层——并通过一个 dspark 类型的投影器进行投影。从堆栈中部而非末端拉取是有意为之：网络中间状态更容易对齐，并且携带的信息是最终层已经压缩成下一 token logits 的信息。该配置还配备了一个带有秩为 256 的马尔可夫分量的置信度头，这正是 DSpark 论文中的机制，用于判断一个提议块中有多少部分值得验证。

验收表是一张卡片，而不是一项测量。

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

• Vision、MMMU — 每步接受 5.098 个 token。

• 视觉，MathVista — 6.126。

• 视觉、CharXiv 推理（验证）—— 5.479。

• 视觉，OCRBench — 5.407

• 文本、数学 — 6.687。

• 文本、代码 — 7.387

• 文本，常规 — 3.501。

关于那张表，有三件事值得明说。第一，它是自报的。OpenBMB 之外没有人运行过这个检查点并公布过数字，而且该仓库记录到的下载量只有一次，所以 OpenBMB 之外根本没有人运行过它。第二，接受长度是这一对模型的属性，而不是模型本身的属性——它衡量的是 MiniCPM-V-4.7-35B-A3B 的输出有多容易被预测，而不是该输出有多好。一个自我重复的目标模型会让草稿模型轻松得手。第三，真正的关键在差距：代码上 7.387 对通用文本上 3.501，最好和最差的类别之间有两倍之差；而代码最容易，更多反映的是代码低熵、高度重复的表面，而不是这些模型有什么优势。

这张卡片还隐含了一种纯算术层面的解读。一个提议 15 个 token、其中 5 到 7 个被接受的草稿器，在每次目标前向传递中仍然推进了多个 token，因此这里的上限是大幅吞吐量提升——但它并不是那种天真的“快 5 倍”说法，因为验证一个 15 token 的块比生成单个 token 成本更高，而且被拒绝的提议已经付出了成本却被丢弃。这个差距正是 DSpark 论文所讨论的内容，也正是配置中提供一个开关来关闭自适应验证的原因。

草稿意外地揭示了关于基础模型的哪些信息

MiniCPM-V 4.7 曾将其发布描述为悄然上线——只有权重，没有发布帖。如今情况已有所改变，虽然微小，却切实可见。其父仓库位于 openbmb/MiniCPM-V-4.7-35B-A3B 于 2026 年 10 月 7 日创建。到 10 月 12 日，它已拥有完整的模型卡，包括 README、Hugging Face 风格的发布页、声明列表、端侧部分和权重表。此后，该仓库又发展出一个量化系列——FP8、int4、AWQ、GPTQ 和 GGUF 构建，各自位于独立仓库中，全部在 10 月 12 日更新——并获得 27 个点赞，下载量为 166 次。

因此，准确的情况是分两阶段发布，而不是静默发布。权重于10月6日和7日上线。草稿检查点随后于10月8日发布。文档、量化版本和端侧方案到10月12日才到位。OpenBMB 仍未为该系列发布博客文章或技术报告，主卡片上也仍然没有基准测试表——性能声明存在于链接的图表图片中，而不是读者可以引用的文本。

文中确实出现的说法是那个被当作标题来宣传的说法：凭借 Lookahead Expert Scheduling、逐层量化以及“DSpark 推测采样集成”，35B-A3B 模型被描述为首个能在设备端流畅运行的开源 MoE 模型，在 iPhone 17 Pro Max 上达到每秒 13 个以上 token。该数字由厂商报告，未经复现，也未加任何限定——没有量化格式，没有构建版本，没有提示词，没有测量方法。DSpark 检查点是该说法所依赖的三项技术之一，这使它成为三者中唯一可以下载并检查的。它也是三者中唯一其证据仅为每个任务一行未被阅读的基准测试记录的那一项。

如果你想的话，那就跑吧

这张卡随附一份配方，而且它是一条 vLLM 命令，不是空口白话。它以张量并行度为 2 的方式服务目标模型，最大模型长度为 40,960，语言和多模态编码器注意力后端均启用 FLASH_ATTN，视觉下采样模式为 4x，enable_thinking 设为 false，推测配置指向 DSpark 检查点、使用 15 个推测 token，并且自适应验证处于关闭状态。这一行里有两点细节值得单独留意：--max-num-seqs 1 意味着所发布的配置一次只服务一个序列，而 --disable-custom-all-reduce 再加上 all-reduce 融合 pass 被关闭，意味着这是一个为了能跑通而调优的配置，而不是为了追求极致速度。请把这份配方当作 OpenBMB 已经跑起来的起点，而不是一份吞吐量声明。

硬件规格才是真正的瓶颈。目标是 KV 缓存之前约 70 GB 的 BF16 权重，而草稿模型还要在此基础上再增加约 0.78 GB。官方给出的最低要求是两块加速器，这使得它远远超出了该系列营销所倚重的手机范畴——对于 35B-A3B 模型而言，端侧部署意味着激进的量化和卸载，这正是 LES 和逐层量化工作要做的事，而这两者都不在上面那份 vLLM 方案中。

这种不对称是大多数团队的务实决策。部署 MiniCPM-V 4.7 会占用你自有的两块 GPU；而调用一个可比的托管多模态 MoE 则无需任何前期成本。Qwen3.6 35B A3B 是最接近的直接对比——同样是 35B 总量、3B 激活的形态，同样的 262K 上下文，支持图像和视频输入——它通过 OrcaRouter 提供服务，费用为每百万输入 token $0.248、每百万输出 token $1.485 起，具体取决于供应商路由，并且当其中某条路由性能下降时会自动故障转移。MiniCPM-V 4.7 并不是 OrcaRouter 上的托管模型，本文也不会假装它是；诚实的表述是，二者是在决策点上的替代方案，而托管的那一个是你今天下午就能衡量的。

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

{{1}}DSpark{{/1}} 检查点是 Apache-2.0 许可，大小不到一吉字节，并且附带一条服务命令，拥有两块 GPU 的人今天就能把它粘贴到终端里运行。这一组合使它成为在 MiniCPM-V 4.7 上获得一个独立数字的最廉价途径——不是基准测试分数，而是几乎同样有用的东西：一个可复现的接受长度。如果外部方能复现 MMMU 上的 5.1 和通用文本上的 3.5，这张卡就可信，该系列的高效率叙事也将获得首个外部数据点。如果接受长度明显更低，那么已发布的表格就是在该配方无法复现的条件下测得的，而每秒 13 个 token 的说法也会因此继承这一疑点。

仍然缺失的，正是模型卡通常所要提供的东西。没有 MMMU 得分，没有 OCRBench 得分，没有文档理解结果，没有 grounding 数值，也没有 MiniCPM-V 4.7 本身的延迟数据——没有任何能回答这个模型到底好不好的内容。草稿模型的表格无法替代这些，而把较高的接受长度当作质量信号来解读，恰恰是这些数字所诱人犯下的错误。ChatGPT 式的预测对草稿模型来说很容易，却完全不能说明预测是否正确。

所以：一个真实的制品，一份真实的许可证，一条关于一个此前毫无已发布证据的模型、真正全新的已发表证据——以及一个与10月7日时一样大的评估缺口。下一个要刷新的文件仍然是父模型的模型卡。