Ming-3.0-audio-flash 对比 MiniCPM-V 4.7：一个能“听”的模型，一个能装进口袋的模型

如果你要在Ming-3.0-audio-flash和MiniCPM-V 4.7 35B-A3B之间做选择，那么在你通常会权衡的任何维度上，这个决定都并不接近，因为它们争夺的并不是同一个位置。一个是拥有1260亿参数的音频语言混合专家模型——其中65亿为激活参数——由 inclusionAI 于2026年9月3日上传，并在六周后补充了文档，其参考配置需要八块80 GB GPU。另一个是拥有352亿参数的稀疏视觉语言模型，OpenBMB 于2026年10月6日晚在 Hugging Face 上发布时根本没有模型卡，直到10月12日才发布模型卡，并声称在 iPhone 17 Pro Max 上使用约3 GB内存即可实现每秒超过13个 token 的解码速度。一个用于聆听，安置在机架中。另一个用于观察，能握在手中。它们之所以值得放在同一页上讨论，是因为两者都是中国实验室在同样的六周内悄然发布的，都是开放权重，而且都正被那些架构中恰好只有一个位置的团队评估。 这类比较背后有据可查的 AI 故障和部署事故都收录在 OrcaRouter AI Incident Archive 中，每条记录都带有自己的来源、严重性、置信等级和争议标记。

先说决策规则，再给出依据。如果输入是声音——通话、会议、方言、音乐、一段需要核验的生成语音旁白——这些模型中只有一个能上手；如果输入是图像、文档、图表、截图或视频帧，则只有另一个能上手。两者的重合之处是一条同时处理这两类输入的流水线，而在这条流水线里，它们是两个阶段，而不是两个候选方案。以下所有数字均为厂商报告：inclusionAI 的数据来自其自己的评测图像，OpenBMB 的数据来自 10 月 12 日发布的一张模型卡，两者均未经第三方复现。

每个个体拒绝做的事

最快的办法是列出每款型号不接受的东西，因为规格表本来就是用来掩盖这一点的。

• Ming-3.0-audio-flash 不会查看任何内容。它的输入是音频和文本指令；仓库中没有图像编码器，配置中没有视觉塔，而且自 10 月 15 日重新上传移除了视频语言变体及其 patch token 以来，也没有视频路径。如果某一帧很重要，这个模型对此是看不见的。

• MiniCPM-V 4.7 35B-A3B 不会听任何东西。它被标记为 image-text-to-text，其处理器处理图像和视频帧，而在 70.4 GB 的权重中，任何地方都没有音频塔、没有 ASR 路径，也没有 T​TS 头。WAV 文件并不是它能够表示的一种输入。

• Ming-3.0-audio-flash 不会生成图像、编辑或 3D 资产。除文本之外，它的可选输出是语音，通过带有内置音色和参考音色的 Talker 模块实现。

• {{1}}MiniCPM-V 4.7 35B-A3B{{/1}} 不会发声。它读取页面并以文本作答。若要实现语音，你得外接一个独立的{{2}}语音合成器{{/2}}，这属于另一个产品决策。

这就是这场比较的全貌。其余的一切——上下文、稀疏性、许可、硬件——相较于模态集合互不相交这一事实，都是次要的。

两种截然不同的稀疏方式

两个模型都采用混合专家设计，而这个词背后隐藏着截然相反的工程押注。

Ming-3.0-audio-flash 之所以稀疏，是因为它极其庞大：42 层、隐藏维度 2,560、512 个专家且每个 token 选择 8 个，总参数 126B、激活参数 6.5B，另有一个 Whisper 风格的音频编码器，32 层、宽度 1,280、128 个 mel 频带。稀疏性为这个原本无法训练、无法提供服务的模型换来了吞吐量，但换不来小体积。25 个 bfloat16 分片加上一对 Talker 和 VAE，在磁盘上合计约 259 GB；厂商的 128K 服务配置是在八块 80 GB H800 上做张量并行。

MiniCPM-V 4.7 35B-A3B 的稀疏化出于相反的原因：存储参数为 352 亿，每个 token 路由 256 个专家中的 8 个，超过 40 个文本层采用三线性接一全注意力的模式，其后方是隐藏维度为 1,152 的 27 层视觉塔，该视觉塔插入文本堆栈的第 6 层。该设计所主张的并非集群上的吞吐量，而是手机上的可行性。OpenBMB 的 Lookahead Expert Scheduling 会预测下一层需要哪些专家，预取这些专家，并将加载与计算重叠——这种技巧只有在瓶颈是手机端内存带宽、而非数据中心的 FLOPs 时才会被发明出来。

• 总参数量 — Ming-3.0-audio-flash 126B；MiniCPM-V 4.7 35B-A3B 35.2B。

• 激活参数——6.5B，对比约 3B（256 个专家中的 8 个，外加一个共享专家）。

• 上下文 — 131,072 个 token，对比 262,144。

• 磁盘上的权重 — 约 259 GB，而 16 个分片合计为 70.4 GB。

• 参考硬件——八块 80 GB 的 H800，对比 iPhone 17 Pro Max 的每秒 13+ 个 token 和约 3 GB。

• 许可证 — MIT 与 Apache-2.0，二者均在各自的卡片中声明。

中文版作品实际上的不同之处

这两个模型都由中国的实验室构建，且都在中文方面最强，但它们擅长的领域不同，而厂商表格把这一点体现得格外清楚。

Ming-3.0-audio-flash 恰恰在语音变得困难的地方最强。在其自己的评估图像上，它报告中文 ASR 平均错误率为 3.45，方言平均为 9.40——粤语 4.09、上海话 11.15、闽南语 12.84、湖北话 9.46、湖南话 8.76——而 Gemini 3.8 Flash 的参考值为方言平均 48.41。同样的图像显示，它在说话人分离上落后（AMI 25.29，而 MiMo-V2.6 Pro 为 11.16），在长音频推理上也落后（Chain 得分 12.31，而 Qwen3.8-Omni Flash 为 34.54）。所以诚实的解读是：在带口音的转写方面表现出色，在弄清楚谁在说话以及录音意味着什么方面表现平平。

MiniCPM-V 4.7 35B-A3B 在密集视觉中文任务上表现最强：OCRBench 91.20、OCRBench_v2 68.47、OmniDocBench v1.6 94.24、CCOCR 81.14、MMMU 80.22、MathVista 88.00、CharXiv reasoning 75.60、TextVQA 84.99——这些全部来自 OpenBMB 自己的图表，均未复现，且其中多行标注为以微弱优势击败 35B 级 Qwen 和 Gemma 模型。视觉塔的混合 4x/16x token 下采样正是其机制：16x 会合并 token 以提升速度，4x 则保留四倍数量的 token 以呈现精细细节；该设置必须同时传给 processor 和 generate()，否则两者会不一致。

因此，中文能力上的重叠范围既狭窄又真实存在：一份附有语音备注的扫描中文文档，就是一个需要两个模型共同处理的问题，而这两个模型都处理不了另一半。

将其中任何一个投入生产需要多少成本

这些数字根本没有可比性，而硬要假装它们可比，正是这类文章一贯的败笔。

Ming-3.0-audio-flash 需要占用一个节点。八块 80 GB H800 是厂商针对 128K 上下文给出的配置；经过验证的 SGLang 替代方案使用四块 GPU，且仅返回文本。总参数 9.3B、激活参数 2.7B 的同系列型号 Ming-3.0-audio-tiny 可装在一张大卡上，但其公开数据在相同表格上始终更差——长音频 Chain 10.56 对 12.31，LongAudioSpan 35.45 对 41.12，URO-Bench-Pro 54.15 对 81.92——因此它是另一款产品，而不是更便宜的版本。

MiniCPM-V 4.7 35B-A3B 的部署成本相当于一部手机、一块单卡 GPU；如果用户自带设备，则完全为零。它拥有一个 Ming 所没有的活跃生态：GGUF、FP8、int4、GPTQ 和 AWQ 变体在几天内发布，还有一个 DSpark 投机解码草稿模型，并获得 llama.cpp 和 Ollama 以及 vLLM 和 SGLang 的支持；主仓库有 76,000 次下载和超过一千个点赞。无论其他方面如何，这已经是一个其他人正在运行的模型。

这种采用程度上的差异是文章中与决策最相关的事实，而且它与质量毫无关系。一个下载量为 76,000 次的模型，拥有一个已经遇到过你这个 bug 的社区。一个下载量为 22 次的模型，只有一个代码仓库和一张模型卡。

那么他们在哪里见面？

恰好是在一种架构中：一个必须既能听又能看的应用。最明显的情形是支持或合规流程——一段方言使用者的普通话录音通话，加上来电者上传的扫描表单，以及一份必须把两者联系起来的摘要。Ming 转写音频并回答有关音频的问题；MiniCPM 读取表单并提取字段。两者都无法完成对方的另一半，而它们之间的连接是文本。

那个联接是大多数团队最容易低估的部分。两个开放权重检查点意味着两次许可证审查、两套部署方案、两种故障模式，以及多一次模型调用来决定哪个文档放到哪里。Ming 的路径是使用 Transformers 并设置 trust_remote_code=True，内存下限在数百 GB；MiniCPM 的路径则是笔记本电脑上的一个量化文件。同一条流水线两半之间的运维反差，比大多数竞争模型之间的反差还要大。

路由层及其局限

OrcaRouter 并不托管其中任何一个检查点。两者都是开放权重，由你自行运行，也都不在我们的目录中；这里的任何一句话都不应被理解为端点提供。路由器真正触及的是连接组织：判断传入资产是音频还是图像并将其发送到正确节点的分类器、为提取设定框架的提示词，以及将两路输出合并为一份报告的摘要器。

那些都是普通的文本调用，而把它们放在一个覆盖 200 多个模型、0% 加价的 API之后的理由很简单——按供应商标价透传，所以供应商一降价，我们这边当天就生效，一把密钥替代三份合同。路由 DSL正是契合这一特定问题的那一环：一条既有音频分支又有图像分支的流水线，在成为模型问题之前首先是一个路由问题，而自动故障转移能在分类模型出状况时让调度器保持存活，而这是整条链路里你唯一不能丢失的那次调用。

限制同样简单。路由并不能让 259 GB 的检查点实现托管，也不能让手机大小的视觉模型变成 ASR 系统。

简短版本

Ming-3.0-audio-flash 是更有野心、但如今也更不好用的那个模型：在同类中有公开数据的模型里，它的中文方言语音识别效果最好，却没有独立验证，也没有已合并的 serving 集成，而且硬件要求会让任何没有 GPU 节点的人无法使用。MiniCPM-V 4.7 35B-A3B 则是完成度更高的产品：有模型卡、量化版本、框架支持、真正新颖的端侧方案，以及一个社区。它同时还是视觉模型，这意味着它做不了另一个模型存在的目的所在之事。

按模态来挑选，比较只需三十秒。按雄心来挑选，你会花上一个月才发现，那个雄心勃勃的模型只有 22 次下载。