Ming-3.0-audio-flash 对比 Gemini Omni 1.1 Flash：一个聆听，一个拍摄

把 Ming-3.0-audio-flash与 G​emini Omni 1.1 Flash放在一起比较，首先要诚实地说，你不能用其中一个替代另一个，因为它们做的是截然相反的工作，只是恰好共用了一个词。Ming-3.0-audio-flash 是 inclusionAI 的 1260 亿参数音频语言模型——每个 token 激活 65 亿参数——它接收音频和文本输入并返回文本，另有一个可选的 Talker 模块可以把答案说出来。其权重自 2026 年 9 月 3 日起就已在 Hugging Face 上，而模型卡直到 10 月 19 日才出现。G​emini Omni 1.1 Flash 是 G​oogle 的闭源视频生成模型，自 2026 年 8 月 27 日起正式可用，它接收文本或图像提示，返回带同步音频的短片，720p 输出每秒收费 0.10 美元。一个消费声音，另一个制造画面。如果一次搜索把你带到这里，期待看到一场正面交锋，那么有用的答案并不是谁胜出，而是你实际拥有的是这两种缺口中的哪一种。这类比较背后的已记录 AI 故障和厂商声明争议，都收录在 OrcaRouter AI Incident Archive 中，其中每条记录都带有各自的来源、严重程度、置信等级和争议标记。

这种混淆不是你的错。“Omni”已经成了一个营销词，泛指任何涉及不止一种模态的模型，而这两个模型正处在这个词的两端。G​emini 的 Omni 产品线是一个带有全模态输入的媒体生成器。Ming 的 3.0 产品线是一个带有可选语音输出的媒体读取器。两家厂商的表述都没有让这一区别变得容易看出，也没有第三方将二者相互基准测试，因为不存在可供基准测试的共同任务。下文所有内容都按来源标注：Ming 的数据是 inclusionAI 自己的，印在其模型卡和仓库中，且未经复现；G​emini 的数据是 G​oogle 的，来自发布材料和价目表，同样未经我们审计。

他们唯一重叠的那项工作

只有一个工作流会让两个模型同时出现在同一条流水线中，而且值得从那里开始，因为这是唯一一处比较能真正体现价值的地方：先做出一段片段，然后知道里面究竟有什么。

Gemini Omni 1.1 Flash 可生成十秒片段，并以十秒为增量将其延长至四十秒上限；它接受首帧和尾帧条件输入，因此你可以固定一个镜头的起始和结束画面；标准渲染为 720p，并可输出放大后的 1080p 和 4K 版本；还能将同步对白、音效和环境声直接烘焙进文件。它也接受音频以及最长三秒的参考视频作为输入。它做不到的是给你一份转录文本、一份说话人列表，或者回答“旁白到底声称了什么”。

Ming-3.0-audio-flash 负责另一半。其说明卡声称支持中文和英文的语音识别（包括口音和方言）、长音频理解、对非语音声音和音乐的感知、音频问答，以及文本输出并可选择语音回复。它接受 128K token 的上下文，而配置直到 10 月 13 日的一次提交将 max_position_embeddings 从 8,192 提高后才标明这一点。如果你的产品是一条生成的广告，且需要检查旁白中的合规声明，那么这两个模型是互补的步骤，而不是二选一。

这就是全部的重叠部分。在此之外，比较便不成立了。

每样东西要花多少钱，以及这些数字为什么没法比较

这正是大多数“vs”页面出错的地方，所以有必要把单位这件事讲得直白一些。

• G​emini Omni 1.1 Flash — 按生成的视频每秒计价。在 720p 下每秒 $0.10，与六月预览版持平；另有 360p 草稿档，价格约为前者的三分之一。标准质量下，一个四十秒的场景在计入重试之前，输出成本就已经是四美元；而多轮对话式编辑意味着，重试是常规流程，而不是例外。

• Ming-3.0-audio-flash —— 完全未定价，因为没有可供定价的托管端点。它由 25 个 bfloat16 分片以及一对 Talker 和 VAE 组成，大小约为 259 GB；厂商针对 128K 上下文给出的服务配置是，在八块 80 GB H800 GPU 上采用张量并行。其成本相当于一个节点，分摊到你在此节点上运行的任何负载上。

• 那个并不存在的比较——视频每秒美元成本，对比音频每小时 GPU 小时数。不存在换算汇率。任何给出这种汇率的人，都是在把租赁价格换算成资本成本，再把结果称为基准。

唯一能明确说清的一点是：Gemini 的价格是公开的、线性计费且可取消的；而 Ming 的价格则是一次性做出、之后必须长期承受的容量决策。对于下个月就要上线某个功能的团队来说，这一差异会在质量之前就决定问题的答案。

可用性，在唯一重要的意义上

Gemini Omni 1.1 Flash 只需一次 API 调用。它是由 Google 托管的模型，没有权重，没有自托管选项，也没有第二个供应来源；你要么从 Google 获得它，要么就得不到。OrcaRouter 不提供它，本文也不会假装并非如此。

Ming-3.0-audio-flash 正好相反：权重以 MIT 许可发布，从 Hugging Face 下载，在你自己的硬件上运行，任何地方都没有端点。让它可部署的代码比权重晚六周出现。GitHub 仓库 inclusionAI/Ming-3.0-audio-flash 创建于 2026 年 10 月 15 日，如今包含三个纯文本和 Talker 配置文件的部署 YAML、两个示例客户端、一份 150 KB 的语音指南和一个 cookbook notebook。vLLM-Omni 的主分支尚未包含 Ming-3.0 音频语言适配器；审核中唯一的 Ming-3.0 集成针对的是 7.9B 语音合成检查点，而不是这个检查点。因此，如今切实可行的路径是启用远程代码的 Transformers，模型卡对此有说明，而这是评估模型的好方法，却是运行服务的糟糕方式。

还有第三种值得点名的不对称。G​emini 的模型已在一个带有变更日志的产品线中发展了十八个月；Ming-3.0-audio-flash 只有 22 次下载，且没有独立评估。低调上传并不是弱点的证据——它说明供应商尚未决定要销售它——但这确实意味着你在 Ming 一侧的风险在于文档和支持，而不是能力。

质量：可以声称什么，以及由谁声称

在这个对比中，只有一方拥有可以写进句子里的数字，而这些数字属于供应商。

在 inclusionAI 自己的评测图像上，Ming-3.0-audio-flash 报告的中文语音识别平均错误率为 3.45，而 Gemini 3.8 Flash 为 9.83——请注意，这里指的是 Gemini 3.8 Flash，即通用多模态模型，而非本文中的 Omni 视频模型；在有关此次发布的报道中，两者常被混为一谈。在方言方面，厂商的差距进一步拉大：平均为 9.40，而同一 Gemini 参照为 48.41。同样的图像在其他方面则不那么乐观。AMI 上的说话人分离错误率为 25.29，而 MiMo-V2.6 Pro 为 11.16；长音频 Chain 得分为 12.31，而 Qwen3.8-Omni Flash 为 34.54，Gemini 3.8 Flash 为 49.63。这些均为自报数据，凡由厂商自评之处均带星号标注，且未经复现。

对于 Gemini Omni 1.1 Flash，在音频理解这一维度上根本没有什么可引用的，因为 Google 不会为视频生成器发布 ASR 分数。它的主张涉及回看上下文、分辨率、帧控制和音频同步。用这些去评判一个转写模型，无论从哪个方向看都是范畴错误。

产生这个页面的命名陷阱

在像这样的每一次对比中，三个 G​oogle 模型都会被混为一谈。G​emini Omni 1.1 Flash 用于生成视频。G​emini Omni Flash（六月预览版）是它的前身。Gemini 3.8 Flash 是通用多模态模型，inclusionAI 实际对标的正是它。一块写着“Ming 对 G​emini”的记分牌，却不说明这里的 G​emini 是哪一个——是拿转写模型去对比视频生成器，还是对比文本模型，全看当天是哪种情况。如果你拿着这样一张表过来，在用它做决定之前，先核对列标题。

OrcaRouter 在这里的实际立场

这两个模型我们都不提供。G​emini Omni 1.1 Flash 由 G​oogle 托管，不在我们的目录中；Ming-3.0-audio-flash 是开放权重，也不在我们的目录中。我们提供的是这类流水线周边的文本层——在 G​emini 生成之前写出镜头清单的提示词、之后读取 Ming 转录文本的合规检查，以及二者之间的路由。

这个说法比模型页面通常宣称的要小，但它是真实的。如果团队正在构建上文所述的先生成再审核循环，那么这两个模型调用分别受不同的合同、不同的计费和不同的故障模式约束；把文本这一半放在一个覆盖 200 多个模型、0% 加价的 API之后意味着你支付的就是供应商标价，因此供应商降价当天就能生效，并且自动故障转移覆盖的是未固定到特定模型的调用。它并不覆盖标题中提到的两个模型中的任何一个，暗示它覆盖了会是不诚实的。

你应该选哪一个

如果你需要画面，那就没什么可犹豫的：就是 Gemini Omni 1.1 Flash，每秒 0.10 美元，今天就能用，但要注意上限是四十秒，每延长一次都得再跑一遍。如果你需要弄清楚一段录音里到底有什么——一场会议、一通电话、一段方言口音很重的采访、一段你必须核实的生成片段——Ming-3.0-audio-flash 凭它自身的数据就是一个值得认真考虑的候选，而且你可以把它跑在自己已经付费的硬件上。

唯一真正需要抉择的，是两者都需要的团队，而对他们来说，顺序很重要。生成侧应基于托管模型来构建，因为它的价格已知，容量则由别人操心。监听侧应基于开放权重做原型，因为检查点今天就能加载，即便其服务方案已是六周前的旧事；也因为一个在发布 README 之前就交付了 259 GB 权重的供应商，是那种你可以检视其模型、而非只能信任其模型的供应商。这两者都不是在对另一方下注。