Moondream 3 对比 MiniCPM-V 4.7：无人提及的 MoE 存储账单

两者都Moondream 3 Preview和MiniCPM-V 4.7是混合专家视觉语言模型，而且二者都以较小的激活参数量作为宣传点，让人觉得它们能适配配置不高的硬件。Moondream 3 Preview 每处理一个 token 会激活其 9B 参数中的 2B。MiniCPM-V 4.7 的主打变体 MiniCPM-V 4.7 35B-A3B，会激活 35B 中的约 3B。读完这两句话，你会以为 Moondream 这个检查点更容易部署。是否真的如此，完全取决于两篇发布文章都没有率先提及的一个问题：那些休眠的专家住在哪里？

那个问题正是这两个模型真正产生分歧的地方，而答案就在于 MiniCPM-V 4.7 为何以其现有形态存在。它的发布——来自 OpenBMB、于 2026 年 10 月 6 日发布的 MiniCPM-V 4.7 35B-A3B 和 MiniCPM-V 4.7 1B——核心就是让一个 35B MoE 在手机上流畅运行而不降低其性能。Moondream 于 2025 年 9 月 18 日发布的 Moondream 3 Preview——在 2026 年 10 月被收购后，现已成为 Prime Intellect 的一部分——则走了相反路线：让 MoE 保持小规模，并用 Photon（Moondream 自研的推理引擎）在 GPU 上运行它。两种选择都没有错。它们是对不同约束条件的回答，而你身处何种约束之下，就决定了这场比较对你的结果。

激活参数是计算数字，而非存储数字。

这就是让端侧 MoE 变得困难的那笔账，OpenBMB 在自己的模型卡中明确说明了这一点：一个 MoE 模型的总参数量可以远超它为单个 token 激活的参数量，但其端侧存储需求并不局限于那些被激活的参数。不同的 token 会在不同的层选择不同的专家，而设备内存往往无法容纳所有专家。

• Moondream 3 Preview — 总参数 9B，激活参数 2B。24 层，前四层为稠密层，其余为 MoE 前馈块，具有 64 个专家，每个 token 激活 8 个。隐藏维度 2048，GeGLU 内/门维度 1024。

• MiniCPM-V 4.7 35B-A3B —— 总参数量 35B，激活参数约 3B。这是 MiniCPM-V 系列中的首个 MoE 模型。同一版本中的 1B 变体是稠密模型，而非 MoE，这一点在下文很重要。

• 这种不匹配——将活跃参数除以总参数，Moondream 3 Preview 看起来是明显更轻量的那个模型。将字节数除以字节数，MiniCPM-V 4.7 35B-A3B 才是承载四倍权重的那个。

• 为什么它不能解决任何问题——常驻集才是限制设备的因素，而常驻集比活跃计数更接近总量。一个9B的MoE无法装入2B稠密模型所能装入的内存中，无论路由器触发什么。

所以，“2B active”是关于每个 token 计算量的说法。它不是关于所需内存的说法，而把它当成后者，是团队错误估算 MoE 部署规模的最常见方式。

OpenBMB 直接攻克了存储问题

MiniCPM-V 4.7 的设计最好理解为针对这一缺口的三项技术。Lookahead Expert Scheduling 使用跨层路由预测来预加载下一层可能需要的专家，并在实际路由器所选中的专家中优先处理成功预取到的那些——该预测仅指导预取和调度，而计算仍遵循模型原有的 token 级路由，预测遗漏的任何所需专家都会照常加载和评估。细粒度逐层量化可削减专家权重的存储占用和内存流量。DSpark 推测采样被集成到端侧路径中，以在这两者的基础上提升解码效率。

所述结果是，在 iPhone 17 Pro Max 上达到每秒 13 个以上 token，内存占用约 3 GB，OpenBMB 称其为首个能在设备端流畅运行且不牺牲性能的开源 MoE 模型。其对比明确，而且就其本身而言值得注意：在 Instruct 模式下，MiniCPM-V 4.7 35B-A3B 以更短的推理时间取得了比 Qwen3.6 35B-A3B 更高的总体得分。这是厂商报告的同一规模级别对比，而且属于更有用的那类，因为两个模型都是在同一测试框架上测量的。

部署方面的其余情况异常广泛。支持 iOS、Android 和 HarmonyOS，并对来自 Rockchip、Houmo、Intel、AMD 和 Arm 的芯片平台提供首日支持。推理可在 SGLang、vLLM、llama.cpp 和 Ollama 上运行；微调则基于 SWIFT 和 LLaMA-Factory。提供 GGUF、BNB、AWQ 和 GPTQ 量化，外加 FP8。1B 版本则又是另一回事——它是稠密模型，而非 MoE；OpenBMB 将其定位为在 MiniCPM-V 4.6 的基础上持续改进，同时在总体得分和推理效率上大幅超越 Qwen3.5 0.8B，而这才是一款亚 1B 模型更诚实的比较对象。

Moondream 的答案是移动硬件，而不是权重。

Moondream 并未试图让 9B MoE 装进手机。它保留了架构，只改变了运行位置：其推理引擎 Photon 将每个模型编译成带有自定义内核的单一 GPU 程序，并在从 Ampere 及之后的 NVIDIA GPU 以及 Apple Silicon Mac 上本地运行，且 API 与 Moondream Cloud 相同。

这是一种站得住脚的策略，Prime Intellect 的收购公告也道出了它为何具有吸引力：Moondream 的团队打造了 Photon 及其背后的 megakernel 编译器，而 Prime 收购该公司的理由在于，决定模型实用价值的是服务，而非架构。那篇公告中的吞吐量数字——单块 H100 上每秒超过 60 次 Moondream 推理、数十毫秒内给出答案、Moondream 3.1 每秒处理 34 个请求——均出自 Prime 自己之手，如今已是销售宣传材料，因此应照此标注。但方向是明确无疑的：Moondream 押注的是，人们宁愿要一个由 GPU 支撑的快速模型，也不要一个手机大小的模型。

还有第二个差异，而且它根本不在模型卡里。在被收购之后，Moondream 3 Preview 的托管端点 Moondream Cloud 将于 2026 年 11 月 13 日关闭，未使用的已购买额度将予以退还。MiniCPM-V 4.7 没有这种依赖，因为它从来就不是以托管产品为主——它是一组权重，并附带一套覆盖广泛的端侧部署方案。如果你的评估包含调用端点的便利性，那么在这一对比的一侧，这种便利性即将失效。

任务能力：这两张卡片在不同方面都是诚实的

Moondream 3 Preview 的四项原生技能是 query、caption、point 和 detect，均返回结构化输出，而发布文章则重点介绍检测和指向。query 技能默认以推理模式运行，文档中提供了用于简单问题的 reasoning=False 标志，并且推理轨迹是有依据的——它们会引用图像的特定部分，这正是 Moondream 将其称为带 grounding 的视觉推理，而非一般意义上的推理的原因。上下文为 32K token，相比上一代的约 2K 大幅提升，并使用自定义的 SuperBPE 分词器；发布文章坦承，后训练并未充分利用这一长窗口，完整的 32K 主要是为微调而设。

MiniCPM-V 4.7 的模型卡则以效率和广度见长：支持单图、多图与视频理解，并通过 4x/16x 混合视觉 token 压缩，让你可以按任务在视觉细节与推理成本之间做取舍；还采用了源自 LLaVA-UHD v4 的 ViT 内部早期压缩，减少编码器较后层的计算量。它还附带一种微调方法——自回放微调（Self-Replay Fine-Tuning），旨在以低成本扩展模型能力，同时减少对已有知识的遗忘。

• 接地检测与指向 — Moondream 3 Preview：架构中内置原生技能，结构化坐标，接地推理轨迹。MiniCPM-V 4.7：多图像与视频理解是其宣称的强项；模型卡并未主打开放词汇检测。

• 视频 — MiniCPM-V 4.7 支持视频输入，并有一个使用 128 帧的文档示例。Moondream 3 Preview 的卡片文档介绍了图像技能，并通过对同一图像的重复查询实现图像编码缓存。

• 可控细节 — MiniCPM-V 4.7：一个 downsample_mode 参数，默认 16x，4x 用于更精细的细节，可按调用选择。Moondream 3 Preview：视觉编码器中的多裁剪通道拼接，发布文章指出该编码器可能会被极小的字体难住。

• 许可证 — MiniCPM-V 4.7：Apache 2.0，两个变体均适用。Moondream 3 Preview：Business Source License 1.1 并附有附加使用授权，允许商业及生产用途，但禁止提供通用型托管 Moondream 服务。Moondream 3.1 已转为 Moondream Model License 1.0，核心限制相同，但表述更为清晰简洁。

在这场对比中，许可证这一项绝不是脚注。如果你打算为其他人托管该模型，Apache 2.0 和 Moondream 的源码可用条款完全不是同一个起点，而无论哪一个在你的任务上基准测试表现更好，这一点都成立。

微调是两张卡共同指向的答案，但原因截然相反。

两家供应商都告诉你，基础型号并不是产品本身，这既令人耳目一新，也暗示了价值所在。

Moondream 的发布文章将可训练性列为四大目标之一，理由是真实的视觉任务需要专业化——解读 X 光片、在人群中认出正在挣扎求救的人——而且即便是人类，做这些事也需要训练。公司为此推出了 Lens，而 Moondream 3.1 的发布则更进一步：已公布的 3.1 基准测试成绩，是通过 Lens 在每项基准测试各自的训练集上微调针对各任务的 LoRA 得出的，随后再以同策略蒸馏把学到的东西折回基础权重，因此可下载的检查点无需任何调优就能取得好成绩。这一点值得读上两遍。这是一种正当的工作流程，也是一次异常透明的披露，但它同时也意味着，那些数字并非冷启动、开箱即用的成绩——相关任务的训练集被喂给了模型。

OpenBMB 的对应方案是 Self-Replay Fine-Tuning，它瞄准的是另一个问题：以低成本获得新能力，同时不遗忘已有能力。其核心主张关乎的是能力保持，而非峰值分数。

如果你打算对任一模型进行微调，实际差别与贯穿整个对比的那个差别是一样的。Moondream 的路径假定需要 GPU 和托管服务。MiniCPM-V 4.7 的路径则假定你可以在自己已经在用的框架上进行微调，然后部署到你已经瞄准的设备上，并有一套已发布的端侧量化方案来支撑它落地。

路由层何处彰显其价值

这里的两个模型都不是通过 OrcaRouter 提供的——两者都是你自己托管的开放权重检查点，而且其中一个下个月将失去其托管端点。这就让真正有意思的问题变成了两张模型卡都回避的那个：你选中的模型处理不好的那些请求会怎样？

标准的答案是再加一个模型，而再加一个模型的标准代价就是集成：又一个 SDK、又一套认证方案、又一条重试策略。这类工作会悄无声息地消耗掉一个冲刺，随后变成永久性的维护负担。OrcaRouter 的模型融合针对的是这一问题中较窄的那一面——在单个模型的回答不足以单独采信的那些调用上，让一组模型共同作答——而路由 DSL 则针对更宽泛的那一面，让你能把多个模型组合成一次调用，由廉价的本地模型处理简单的多数，剩下的部分交给更大的模型。

一个密钥背后就有 200 多个模型，按供应商标价提供，不加任何加价，这意味着供应商降价当天就能传导到你这里，而不是等到下一个计费周期；当上游服务降级时，跨提供商的故障转移会自动进行。对于自托管 VLM，路由层位于模型之上，而不是取代模型。这就是对它在本次比较中所处位置的诚实描述；对于一个在设备端运行 MiniCPM-V 4.7 35B-A3B、并由托管模型覆盖遗漏场景的系统来说，它正是让两者不至于变成两套系统的那一环。

哪一个，由你实际拥有的约束条件来决定

如果模型必须在设备上运行，MiniCPM-V 4.7 35B-A3B就是答案，而且优势明显。OpenBMB 整个发布都是围绕那个阻碍 35B MoE 在手机上运行的存储问题来打造的——专家调度、逐层量化、投机解码——并公布了由此得出的数字：约 3 GB 内存下每秒 13+ 个 token。Moondream 3 Preview 中没有任何内容能解决这个问题，因为 Moondream 选择不面对它。

如果方案中涉及 GPU，且任务是基于定位的检测，Moondream 3 Preview则是更专用的工具。原生 detect 和 point，配有结构化坐标和可检查的视觉定位推理轨迹，这与一个同时能读取图像文字的通用多模态模型是截然不同的产品；而如果由人工审核输出结果，轨迹本身就是其核心特性。

如果你在两者之间犹豫，不要根据基准测试表格来做决定。用你自己的提示词，把你自己的图像分别跑过两者，并给输出打分，因为在这场比较中，唯一能经受住你的工作负载考验的数字，就是你自己测出来的那个。而且要先看许可证，再看模型，因为 Apache 2.0 和带有托管服务限制的源码可用许可证，完全是两种不同的决策——其中一种可能会在准确率数字变得重要之前就终结评估。