MiniCPM-V 4.7 35B-A3B 对比 Qwen2.5-Omni：十九个月后，其中一个依然听得见你

把 MiniCPM-V 4.7 35B-A3B 和 Qwen2.5-Omni 放在同一张规格表上对比，较新的模型几乎在每一行都胜出。它的上下文长度是后者的八倍，采用稀疏架构，每处理一个 token 只激活十二分之一的参数，还享有十年的推理工具链积累，而这些在较旧模型发布时根本不存在。但看到音频那一行时，MiniCPM-V 4.7 35B-A3B 却完全空白。Qwen2.5-Omni 于 2025 年 3 月下旬发布，能接收音频输入，并流式输出自然语音；MiniCPM-V 4.7 的权重于 2026 年 10 月问世，只接收文本、图像和视频，并返回文本。在这组特定模型中，十九个月的进步并没有造就一个更好的全模态模型。它造就的是一个更好的视觉模型，却做不了旧模型当初正是围绕其打造的那件事。

这种框架并不是在贬低任何一方。它就是这项比较的整体形态，也正是为什么需要语音的读者和需要阅读上千页扫描件的读者，应当得出不同结论的原因。就来源而言：Qwen2.5-Omni 的数据来自厂商，时间为 2025 年 3 月，如今已有十九个月，并因广泛部署而得到部分验证。MiniCPM-V 4.7 35B-A3B 的数据来自 OpenBMB，于 2026 年 10 月 12 日发布在一张模型卡上——这是它的首张模型卡，距权重首次出现仅十天——其中没有任何一项在实验室之外得到复现。

较旧的模型实际上是什么

Qwen2.5-Omni 是该产品线中首个端到端全模态模型，厂商当时的表述很明确：它是对“专家模型动物园”问题的解答，即转录、视觉和语音各自都需要一个单独的模型和单独的胶合层。这个 7B 模型以文本、图像、音频和视频为输入，并以文本或流式自然语音作答，配备 Chelsie 和 Ethan 两种固定音色。它声称在 OmniBench 融合基准上取得了最先进的结果，领先于 Gemini-1.5-Pro，语音生成质量得分为 4.51，厂商称其达到人类水平。

这套工程设计能够成立，是因为它针对约束而设计，而非绕开约束。Thinker-Talker 将工作拆成两部分：Thinker transformer 融合音频和图像编码器，生成语义和文本；而 Talker 从 Thinker 的隐藏状态中流式输出语音 token，并共享完整的对话历史。时间对齐的多模态 RoPE 交错排列视频和音频位置，使两路流保持同步；分块流式处理让编码器执行感知工作，同时由语言模型处理长序列——这才真正使低延迟语音回复成为可能。

这些限制同样真实，而且它们是内存限制，而非上下文限制。厂商自己的表格显示，与 32,768 token 的上下文窗口相比，使用 FlashAttention-2 进行 BF16 推理时，15 秒视频大约需要 31 GB GPU 内存，30 秒需要 42 GB，完整一分钟需要 60 GB。在 7B 模型上、在你能租到的最大的单块 GPU 之一上，一分钟视频就是那个必须始终放在心上的数字——它正是此后一切都被构建来摧毁的数字。

新模型改做什么

MiniCPM-V 4.7 35B-A3B 则完全走了另一条路线。它是 OpenBMB 在 MiniCPM-V 系列中的首个 MoE：40 层中设有 256 个专家、每个 token 激活 8 个，上下文窗口为 262,144 个 token，词表规模为 248,144 个 token，总参数量为 35.2B，其中激活参数约为 3B。视觉部分通过 SigLIP2 模块处理，采用 LLaVA-UHD v4 的 ViT 内早期压缩，以及可选的混合 4x/16x token 压缩模式——默认 16x，当精细细节值得消耗 token 时则使用 4x。它可处理单张图像、多图集合和视频，并以文本作答。

该卡片的核心主张是，这是首个具备无损、流畅端侧推理能力的开源 MoE 模型，其实现方式包括 Lookahead Expert Scheduling、细粒度逐层量化，以及通过单独的 DSpark 草稿进行的投机采样，据称在 iPhone 17 Pro Max 上达到每秒 13 个以上 token。这个数字由厂商报告，未经复现且缺乏限定条件——没有量化格式、没有构建版本、没有提示词、没有测量方法。该卡片还声称，在更短推理时间内，其整体 Instruct 模式得分高于 Qwen3.6 35B-A3B；而这一主张呈现在图表图像中而非表格里，因此不能作为数字引用，也不应被当作数字对待。

七个维度，两侧

• 输入模态——Qwen2.5-Omni 支持文本、图像、音频和视频；MiniCPM-V 4.7 35B-A3B 支持文本、图像和视频，完全没有音频路径。

• 输出 — 文本加两种固定语音的流式自然语音，对比仅文本。

• 上下文 — 32,768 个 token，对比 262,144，增加了八倍。

• 参数——供应商用来命名该模型的 7B 数字，对比 MiniCPM 一侧总计 35.2B、激活 3B。仓库本身为该检查点列出 11B 参数，因为 7B 计入的是语言模型，而不包括与之并列的视觉和音频编码器——这提醒我们，这里的“7B”既是一个名称，也是一种度量。

• 内存占用——厂商自己的表格显示，15 秒视频约需 31 GB，一分钟约需 60 GB；MiniCPM-V 4.7 光是 BF16 权重就约 70 GB，这还没算任何 KV 缓存，正因如此，其量化版本和端侧部署方案才在这份介绍中占据了如此大的篇幅。

• 许可证——两者均为 Apache-2.0，这是唯一一条他们无条件达成一致的地方。

• 部署工具 — 十九个月来针对 SGLang、vLLM、llama.cpp、Ollama 和 OpenVINO 支持的社区量化与工具，GGUF/BNB/AWQ/GPTQ/FP8 构建，以及 iOS、Android 和 HarmonyOS 应用。

• 公开评测——一个已存在十九个月、被广泛引用的 OmniBench 得分 0.561，而对照的却是一张完全没有可引用评测表格的卡片。

音频漏洞就是整个决策

如果你的流水线需要一个模型来听到声音，那么这场比较在第一段就结束了。Qwen2.5-Omni 是两者中唯一能接收音频的，唯一能说话的，也是唯一背后有成熟语音技术栈——Thinker-Talker、TMRoPE、逐块流式处理和两个固定音色——支撑的。它也是两者中唯一一个有人大规模部署过的；当你试图在本季度把模型放进一个应用时，十九个月的社区量化与工具积累比一纸规格表更有价值。

作为交换，MiniCPM-V 4.7 所提供的是长得多的记忆，以及针对长视觉文档低得多的每 token 计算开销。262K 窗口和 3B 激活参数，与 7B 稠密模型上的 32K 窗口相比，是真正不同的工具——而对于面对数千张页面图像、截图或长视频转录文本的工作负载来说，更新模型的形态才是合适的。只是它无法成为那个接电话的模型。

这就是权衡，直说便是：深度对广度。旧模型覆盖更多义项。新模型覆盖更多页面。

两条截然不同的证据线索

在这里，不对称性朝相反的方向运作，而这一点值得精确说明。

Qwen2.5-Omni 的数据已经久到部分已经通过实际使用得到验证。一个已有十九个月历史、基准排名被广泛引用、拥有十年下游量化和庞大安装基数的模型，从任何正式意义上讲都算不上一个已被证实的可靠量，但它的各种主张已经有足够长的时间可供反驳，却始终未被反驳。尤其是内存数据，它们发布时是作为工程约束，而不是营销宣传，而且它们表现得也确实像工程约束。

MiniCPM-V 4.7 的数字已经公布两周，却没有任何外部验证。该模型于 10 月 6 日悄然上线，没有附带任何文档，而模型卡、许可证和性能声明部分则是在 10 月 12 日才补齐。至今仍没有评测表格，没有技术报告，也没有任何第三方公布过结果。唯一有真实公开数字的地方是单独的 DSpark 草稿检查点，其“每步接受令牌数”数据来自 OpenBMB 自己，而该实验室并未为母模型公布这些数据。

所以，对新模型，正确的姿态是：把架构当作已知（它就在配置文件中），把发布当作真实（权重以六种格式存在），并把每一个性能数字都当作一个等待第二意见的说法。最后这一点并不是永久状态。它只是10月13日当时的状况。

运行其中任何一个，以及路由器的用途

这两个文件都由你自己提供服务。MiniCPM-V 4.7 35B-A3B 和 Qwen2.5-Omni 都不在 OrcaRouter 的托管目录中，本文中的任何内容都不应被解读为我们声称会对它们进行路由——MiniCPM-V 4.7 是一个两周前发布的检查点，要以非量化方式运行它，你需要两个加速器；而 Qwen2.5-Omni 是一个 2025 年的开放权重模型，其实际归宿是你自己运营的 vLLM 实例。

路由器的价值恰恰体现在这条线的另一侧。大多数运行自托管视觉模型的团队仍然需要托管模型，来应对本地模型无法处理的场景——长程推理、工具调用，以及 MiniCPM-V 4.7 不接受的音频输入。OrcaRouter 把 200 多个托管模型放在一个密钥之后，按各家供应商的标价原样透传，不收取我们自己的加价，并在供应商服务质量下降时自动故障转移，这意味着添加那第二个模型只是一次路由变更，而不是再签一份合同。与 MiniCPM 模型最接近的托管形态是 Qwen3.6 35B A3B——总计 35B、激活 3B、262K 上下文，支持文本-图像-视频输入——价格为每百万输入 token 0.25 美元、每百万输出 token 1.48 美元，这是衡量自托管究竟能为你省下多少的一个合理标尺。

哪一个，什么时候

如果你需要任何音频或语音功能，或者想要一个已有十九个月部署历史的模型，又或者 32K token 以及一分钟视频 60 GB 的上限符合你的预算，那就选 Qwen2.5-Omni。它的局限性已知且有文档记录，而在你要交付上线时，这反而是一项优势。

如果你的问题是长视觉上下文和文本输出，如果你想要宽松许可证，并且如果你愿意做早期采用者——那就选 MiniCPM-V 4.7 35B-A3B，因为早期采用者正是你会成为的。没有第三方运行过它，端侧宣称尚未被复现，基准测试也不存在。作为交换，你得到的是一个有文档记录、可量化、多运行时支持的模型，拥有 262K 上下文窗口和一套看似合理的效率故事，而你将亲自发现这个故事是否成立。

能改变答案的是:一份来自 OpenBMB 的基准测试表,或一个从 DSpark 草稿中复现出的接受长度——这仍是在该系列上获得外部数字的最省力途径。不会改变答案的是更多时间。十九个月并没有让 MiniCPM-V 4.7 获得听觉能力,而路线图上也没有任何迹象表明它即将到来。