一张生成的标题卡,标题为“一小时语音,两张账单”,用于 Ming-3.0-audio-flash 与 Gemini 3.8 Live 的对比。四个标签分别写着“收听 $0.30”“说话 $1.08”“双向 $1.38”和“自托管需 8 台 H800”。左侧面板标为“Gemini 3.8 Live”,显示一个计量表盘,说明文字为“按分钟计费”;右侧面板标为“Ming-3.0-audio-flash”,显示一叠八张 GPU 卡,说明文字为“按机器计费”。
Guides & Insights

Ming-3.0-audio-flash 对比 Gemini 3.8 Live:开放权重、八块 GPU,以及一份你真正算得清的账单

作者

Magnus Corvin

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

将连续音频输入 G​emini 3.8 Live一小时,按 G​oogle 公布的目录价计算为 0.30 美元。音频输出一小时为 1.08 美元。双向语音会话中,两个方向都持续整整一小时,为 1.38 美元。 Ming-3.0-audio-flash 完全没有按分钟计价的价格,因为根本没有可购买的端点:它是一个以 MIT 许可发布的 1260 亿参数混合专家检查点,其成本就是你使用八块 H800 一小时的成本。整个比较就这两句话,而这两个系统之间几乎所有其他差异都由此而来。像此次发布这类发布背后的已记录 AI 故障和智能体事件,均收录在 OrcaRouter AI Incident Archive,其中每条记录都带有各自的来源、严重程度、置信度等级和争议标记。

这些日期很重要,因为这不是一次发布。inclusionAI 于2026年9月3日将 Ming-3.0-audio-flash 的权重发布到 Hugging Face,却对此只字未提。在长达六周的时间里,这个仓库实际上只是一个装满分片的文件夹:没有服务代码,没有示例,也没有可用的模型卡。GitHub 仓库于10月15日创建,vLLM-Omni 和 SGLang 配置、语音预设以及重写后的模型卡在10月15日至10月19日之间陆续上线;截至本文撰写时,Hugging Face 页面显示下载量为22次。Gemini 3.8 Live 则不同,它是一个稳定且已正式可用的 Live API 模型,Google 将其描述为低延迟语音智能体的默认选择。其中一个是今天下午就能调用的产品。另一个本周才变得可运行,而且仍然没有运营方。

这两个系统实际上是什么

G​emini 3.8 Live 是 Live API 背后的托管流式模型。该 API 接受 16 kHz 的原始 16 位 PCM 音频、最高每秒一帧的图像以及文本,并返回原始 24 kHz PCM 音频。G​oogle 的 Live API 文档称语言覆盖范围为 70 种语言。你打开会话、进行流式传输,就能收到返回的音频;没有检查点,无需预留 GPU,也无需阅读许可证。

Ming-3.0-audio-flash 从更字面的意义上说是一个音频-语言模型。音频编码器和投影器为专家混合语言骨干网络提供输入,可选的 Talker 将模型的文本输出转换为语音。输入是音频加文本指令。输出是文本,或带合成语音的文本。模型卡将中文和英文列为主要语言,“包括各种口音和方言”。许可证为 MIT。

• 参数 — Ming:总计 126B,每次推理步骤激活 6.5B(Hugging Face 侧边栏另称 128B,卡片未解释这一差异)。G​emini 3.8 Live:未披露。

• 语言 — Ming:中文和英语。G​emini 3.8 Live:根据 Live API 文档,支持 70 种语言。

• 输入 — Ming:音频和文本指令。Gemini 3.8 Live:音频、图像、文本。

• 输出 — Ming:文本,可选语音。Gemini 3.8 Live:音频,并通过同一会话提供文本。

• 许可证 — Ming:权重与代码采用 MIT 许可。Gemini 3.8 Live:商业 API 协议。

• 价格 — Ming:没有价目表;你为 GPU 付费。G​emini 3.8 Live:每百万音频输入 token $3.00,或每分钟 $0.005;每百万音频输出 token $12.00,或每分钟 $0.018;文本输入每百万 $0.75,输出每百万 $4.50。

A screenshot of Google's Gemini API pricing page for the Live models, showing the model IDs gemini-3.8-live, gemini-3.8-live-extended-thinking and gemini-3.1-flash-live-preview, described as low-latency audio-to-audio models optimised for real-time voice agents, and a paid-tier price table in US dollars per one million tokens whose input column begins at $0.75 for text and $3.00 for audio.

音频小时数计算,正确做法

上面那些按分钟计算的数字才是值得牢记的,而且大多数对比也恰恰在这里出错:它们向读者报 token 价格,可读者根本不知道一分钟语音会消耗多少 token。改用按分钟计费的价格吧,因为 Google 直接公布了这些价格。

• 仅收听,一小时——60 分钟按 $0.005 计算为 $0.30。

• 仅口语,一小时——60 分钟按 $0.018 计算为 $1.08。

• 完整双向一小时 —— 1.38 美元,不含任何文本 token 或工具调用。

• 一千个双向小时 — $1,380。

A generated two-column card titled 'The same hour, two ways'. The 'Gemini 3.8 Live' column reads input audio $0.30 per hour, output audio $1.08 per hour, two-way session $1.38 per hour, 1,000 hours $1,380, concurrency per session, hardware none. The 'Ming-3.0-audio-flash' column reads no rate card, cost basis GPU hours, full profile 8 x 80GB H800, text only 4 GPUs, concurrency set by your scheduler, hardware you own it. The footer reads 'Gemini rates per Google Live API pricing. Ming serving profile per inclusionAI repository.'

现在来看 Ming-3.0-audio-flash 上的同一小时。根据该仓库自己的部署说明,支持完整 128K 上下文并带语音输出的参考服务配置是跨八块 80 GB H800 GPU 的张量并行。四块 GPU 可运行一个经过验证的 SGLang 配置,但该配置仅支持文本输出。因此,诚实的自托管对比是八块 GPU 对一次按量计费的会话。按假设的每 GPU 小时 2 美元计算,一小时的容量成本为 16 美元——而且这是整块 GPU 的成本,你可以将其分摊到并发请求上,而不是一次对话。在十个并发流下,每对话成本降至每小时 1.60 美元以下;在一百个并发流下,降至 0.16 美元以下。这些是算术推算,不是实测,并且忽略了利用率、批处理效率,以及一个拥有 6.5B 激活参数的 126B 模型在短音频片段上不会占满八块 H800 这一事实。

交叉点确实存在,但并不在人们以为的地方。当并发对话数量低于约十二个时,G​emini 3.8 Live 比租用八块 H800 更便宜,也比购买它们便宜得多。超过这一数量后,并且假设你能让批次保持满载,开源检查点在原始算力成本上胜出——这正是开放权重的全部经济论据,也是为什么应该记住的数字是八块 GPU 这一要求,而不是参数数量。

“音频理解”在每一方分别意味着什么

Gemini 3.8 Live 专为对话而构建。它的职责是听懂你、快速作答,并处理轮流发言。Google 的模型列表将其定位为默认的 Live 模型,“适用于大多数低延迟语音代理体验,且没有推理延迟”——这句话说的是延迟预算,而不是音频分析的深度。

Ming-3.0-audio-flash 针对的是另一项任务。这张卡片的五大亮点是:跨方言、口音、噪声和多说话人录音的复杂语音识别;长音频理解;对非语音声音、声学场景和音乐的感知;对音频内容的推理;以及带可选合成回复的语音交互。这是一份转录与分析清单,外加一个生硬附加的聊天模式,而不是一份语音智能体清单。

实际后果是:如果你的产品是一个必须在 400 毫秒内响应的电话智能体,那么 Gemini 3.8 Live 才是符合这种需求的产品形态,而 Ming-3.0-audio-flash 不是,无论基准测试分数如何。如果你的产品是“导入一段 90 分钟的电话会议,告诉我谁说了什么,并标出首席财务官语气发生变化的那一刻”,那么 Ming 的模型卡描述的正是你的任务,而 Live API 描述的是另一项任务。

尚未有人解决的基准问题

Ming-3.0-audio-flash 在其代码库中提供了三个基准评测面板:语音识别、音频智能和文本。所有数值均为百分比,除非标有向下箭头,否则越高越好;标有星号的结果为团队自行评测。代码库还补充说明,对比模型的结果是在 inclusionAI 自有评测设置下复现的,可能因提示词、解码设置、模型版本和流水线而与这些模型的官方报告有所不同。

那份说明异常坦率,这也意味着这些图表不能用来将 Ming 与 G​emini 3.8 Live 进行排名。数字存在于图像中,而不是 README 文本里,而且 G​oogle 没有为 3.8 Live 发布可比的音频理解套件。没有任何第三方排行榜同时给两者打过分。任何人向你展示把这两个模型并排放在一起的柱状图,都是在一根轴上用厂商的说法搭建出来的,而另一根轴上则什么都没有。

今天唯一诚实的说法是:Ming-3.0-audio-flash 只有厂商自己跑出的数字,没有独立数据;Gemini 3.8 Live 有生产环境的实绩,却没有公开发布的音频推理基准。在采购决策唯一重要的那个维度——证据——上,这是平局。

OrcaRouter 适合用在何处,又不适合用在何处

Ming-3.0-audio-flash 不在我们的平台上。我们不会假装它在:如果你想运行它,就克隆仓库,安装它指定的 vLLM-Omni 或 SGLang 分支,并自备 GPU。在这个对比中,路由器的价值在于决策的另一面——也就是当你已经决定让某个托管音频模型处理你的实时流量时,问题就变成选哪个托管模型、按什么价格、以及会话失败时采用什么回退方案。这是一个跨一个密钥背后的 200 多个模型,按提供商目录价且不加价,因此供应商调价当天就能传到你这里,而不必等到下一次合同续约。

对于正在测试某个开放音频检查点是否值得承载生产流量的团队来说,有用的模式是保留托管路径作为回退方案,并将流量逐步迁移到自托管的 Ming 上。自动故障转移正是让这种迁移可逆、而不是一场赌博的关键。

选择

如果你需要在本季度将语音智能体投入生产、需要支持两种以上语言、需要在同一流中处理图像,或者预计并发对话少于十二路,就选择 G​emini 3.8 Live。按分钟计费很低,运维负担为零,而且模型稳定并有完善文档。

如果你需要自己拥有权重、需要在本地或气隙环境中运行、需要 MIT 许可条款、主要使用中文和英文工作,并且拥有八块 H800 或一个能为你提供八块 H800 的调度器,那就选 Ming-3.0-audio-flash。要做好自己评估的准备,因为没有人替你做过。要做好工具链才发布几天的准备,因为事实就是如此。还要预料到模型卡会在你使用期间不断变化:它最后一次提交就是本文写作当天。

还有第三种情况,而且它是最大的一种。如果你还不知道自己属于那两者中的哪一种,那你还没准备好选择按量计费的 API 还是八卡 GPU 部署。先把你自己的音频跑一百个小时的托管模型,衡量你实际需要怎样的准确率,再让这个数字决定开放检查点是否值得上机架。

A screenshot of the inclusionAI Ming-3.0-audio-flash model card on Hugging Face, showing the text-to-speech and automatic-speech-recognition tags, English and Chinese, the headline 'Hear clearly. Understand deeply. Act intelligently.', and a model summary table listing the developer as inclusionAI, the model type as a native audio-language mixture-of-experts, and 126B total parameters with 6.5B activated per inference step.

看什么

真正会改变这一比较的并不是基准测试,而是运营方。一旦有服务商把 Ming-3.0-audio-flash 挂在兼容 OpenAI 的端点后面、按小时标价,八张 GPU 的那套说法就不再是读者要操心的问题,而每小时 1.38 美元也就有了竞争对手。在此之前,诚实的总结是:Google 卖的是一分钟,而 inclusionAI 白送的是一台机器,只有当你已经拥有那台机器时,两者才谈得上可比。