Ming-3.0-audio-flash 在自己的模型卡发布前六周就已上线

一个拥有 1260 亿参数的音频语言模型自 2026 年 9 月 3 日起就可从 Hugging Face 下载，而它的成绩单只有 22 次下载和 8 个赞。直到本周，附在该仓库上的唯一说明还是一张过时的卡片，它自称“Ming Audio V3”，并称该仓库“目前记录的是 ASR 路径”。Ming-3.0-audio-flash 是它现在使用的名称。权重本身并不新。2026 年 10 月 13 日至 19 日期间到来的，是让一个检查点能被并非训练它的人使用所需的一切：一份终于声称支持 128K 上下文的配置，一次重新上传——它在 Transformers 5 代码路径上把视频-语言-音频模型变成了纯音频模型，一个包含两段参考音频的语音包，以及该仓库有史以来第一张真正意义上的模型卡。inclusionAI 对这些只字未宣。没有任何第三方发布过该模型的任何一项数据，因此下面的一切要么直接读自提交历史，要么引自厂商自己的评估图片——这也是为什么值得在开头说明：模型来自九月，而只有文档来自本周。 像这次发布这样的发布背后那些有记录的 AI 故障和智能体事件，都收录在 OrcaRouter AI Incident Archive 中，其中每个条目都带有各自的来源、严重程度、置信等级和争议标记。

发生了什么变化，以及何时发生

提交日志清晰得不同寻常，而且讲述了一个模型卡没有讲述的故事。该仓库创建于 2026 年 9 月 3 日 11:49 UTC，其中只有一个文件，即 .gitattributes。九分钟后，25 个 safetensors 分片、总计 257 GB，出现在一条标题为“使用 upload-large-folder 工具添加文件”的提交下——这是训练团队推送检查点的典型标志，而不是产品团队为发布造势的做法。随附的 README 声明采用 Apache 2.0，给仓库打上 automatic-speech-recognition 标签，并告诉你要实例化模型时使用 trust_remote_code=False。

随后，这个仓库沉寂了六周。当它再次有动静时，它在七天内变动了四次。

• 10月13日 12:17 UTC —“上传 config.json。”只有一个文件，而且正是有趣的那个：max_position_embeddings 从 8,192 变为 131,072。仓库中其他内容没有任何变化，因此有两天时间，仓库对外宣称支持 128K 上下文，却没有任何建模代码能够使用它。

• 10月15日，09:35 和 09:40 UTC——“Remove deprecated files”，随后是“Upload updated model”。权重布局没有变化，但有 46 个文件被重写，第一个分片从 10.64 GB 降至 9.77 GB。配置中的音频 model_type 从 bailing_moe_v3_vl_audio 变为 bailing_moe_v3_audio，一个残留的 video_patch_token 被删除，声明的 transformers_version 从 4.56.2 跃升至 5.14.1，并且 auto_map 新增了此前不存在的 AutoModel 和 AutoProcessor 条目。在同一次推送中，README 和 examples/ 文件夹消失了——在接下来的四天里，该仓库完全没有模型卡。

• 10月17日 11:44 UTC —“添加语音预设。”voice_presets/ 文件夹出现，包含 US_James.wav、灵楷.wav 以及一个 voice_prompts.json，其中保存着它们的转录文本。

• 10月19日 11:35 UTC 起——“添加模型卡”，然后是资产，接着是十几个打磨导航和链接对齐的小提交，最后于 13:20 UTC 以“添加 Tiny 模型链接”结束。正是这个提交重命名了模型，将许可证元数据改为 MIT，并添加了那张 8,259 字节的模型卡，描述的是完整的音频语言模型，而不是一条 ASR 路径。它所替换的 README 已于四天前被删除；再往前那个九月份的版本标题为“Ming Audio V3”，并声明采用 Apache 2.0。

还有第二个值得了解的仓库。Ming-3.0-audio-tiny与 flash 模型在同一时刻创建，即 9 月 3 日 11:45 UTC，并在 10 月 19 日经历了同样的处理。它是更小的兄弟版本：总参数 9.3B，激活参数 2.7B，MIT 许可，分为四个分片，总计约 21 GB，已有三次下载。

你实际能下载什么

配置已公开，因此架构并不神秘。本周发生变化的是，配置和代码终于一致了。自定义建模文件自首次上传以来就一直在仓库中——modeling_bailing_moe_v3_audio.py 和 processing_bailing_moe_v3_audio.py 两者在 9 月 3 日就已经都存在了——但它们本应加载的配置描述的是一个具有 8K 窗口的视频-语言-音频模型，而模型卡却让你用以下设置来实例化它：trust_remote_code=False，这与自定义代码所需正好相反。10 月 15 日的重新上传是这样一个版本：其中 audio_config.model_type 读取为 bailing_moe_v3_audio，视频补丁 token 已不存在，声明的运行时是 transformers_version 5.14.1，并且 auto_map 注册了 AutoModel 和 AutoProcessor，与一直存在的两个条目并列。

• 大小 — 语言模型由 25 个 bfloat16 safetensors 分片组成，总计 256 GB；另有 3 GB 的 Talker 与 VAE 组合，位于 {{2}}talker/{{/2}} 下。talker/微型模型约 21 GB，分为四个分片。

• 主干网络 — 42 层，隐藏维度 2,560，512 个专家，每个 token 激活其中 8 个，词表大小 157,184。根据模型卡，总计 126B，每次推理步骤激活 6.5B。

• 音频塔——一个 Whisper 风格的编码器，具有 32 层、宽度 1,280、20 个注意力头、128 个梅尔频带，以及 3,000 帧的音频上下文。音频 token id 为 157,168。

• 上下文 — 131,072 个位置。在 9 月 3 日的配置中，它是 8,192，而 10 月 13 日的配置首次将其提高，却仍自称 bailing_moe_v3_vl_audio，并且仍带有视频 patch token；干净的纯音频版本是 10 月 15 日的那一版。

• 输出——文本，或通过可选的 Talker 输出的文本加合成语音。该卡片指定了一个默认 IP 音色“灵小柔”，以及两个预设参考音色“灵楷”和“US_James”，它们的音频和转写文本都位于仓库中。

• 许可证 — MIT。在 10 月 19 日之前，它一直是 Apache 2.0。请注意，仓库本身不包含 LICENSE 文件：MIT 声明存在于卡片的元数据以及指向 GitHub 路径的链接中，而仓库中实际存在的唯一许可证文本属于一个随附的语言识别模型，该模型位于 talker/data/。

快速入门目前仍未解决

这正是计划评估该模型的读者最先需要看到的部分，而卡片中并未包含。卡片的安装块会克隆 github.com/inclusionAI/Ming-3.0-audio-flash。该 URL 如今无论是通过网页还是 API 访问都会返回 HTTP 404。卡片在其基础上构建的每一个路径也同样如此：examples/transformers_audio.py、examples/transformers_thinker_talker.py、docs/voices.md、scripts/serve_vllm_omni.sh、scripts/serve_sglang.sh以及 requirements-transformers.txt。

这些在 Hugging Face 仓库中也都不存在。它没有 examples/ 目录——早先的一个已于 9 月 17 日删除——没有 scripts/，没有 docs/，也没有位于 talker/ 之外的 requirements 文件。它确实包含的是直接用 Transformers 加载模型所需的一切，模型卡也将这一点记录为一段 Python 代码片段：AutoProcessor 搭配 use_fast=False，AutoModelForCausalLM 以 bfloat16 加载并使用 device_map="auto"，trust_remote_code=True，以及通过 processor(messages) 传入音频，并将 audio_feats 转换为模型 dtype。

所以坦白说，现状是：模型可以加载，但目前并不存在可供读者阅读的服务脚本，而模型卡描述的是一个尚未发布的仓库。这算不上丑闻——文档比代码推送早几个小时落地是常事——但这确实意味着下面两种部署方案无法被审计，只能被引用。任何正在评估这个检查点的人都应计划采用 Transformers 路径，并且应在启用远程代码之前阅读 modeling_bailing_moe_v3_audio.py，模型卡本身也这样建议。

可检查的是分词契约，而卡片对此规定得异常具体：经过验证的 ASR 提示词要求模型说出所讲的语言，并在语言标签与转录文本之间放置一个制表符。如果你正在编写评估框架，那么这个制表符就是解析器。通用的“转录这个”提示词并不是供应商测量时所采用的配置。

inclusionAI 发布的表格，包括它丢失的列

三张 PNG 图片位于 assets/中，承载了评估。其中的每个数字都来自 inclusionAI 自己的运行结果；星号标记的是厂商标注为自评的条目，且其中没有任何内容被第三方复现。Artificial Analysis 发布音频排行榜，但没有收录该模型的条目。没有竞技场评分，没有独立 Elo，也没有第二方意见——因此，请将以下内容视为厂商在描述其自己的模型，而事实也正是如此。

语音识别图表是本案最有力的部分，而它在该模型显然专为发力的维度上表现强劲。在其中文测试集上取平均，flash 模型报告为 3.45，而 Qwen3.8-Omni Flash 为 3.54，Gemini 3.8 Flash 为 9.83；在英文上，则分别为 3.69 对 4.02 和 5.05。在方言上，差距急剧扩大：

• 方言平均分 — Ming-3.0-audio-flash 9.40，Seed2.0 Lite 13.01，Qwen3.8-Omni Flash 11.58，Gemini 3.8 Flash 48.41。

• 闽南语——12.84，而同样这三项分别为 49.95、28.08 和 81.62。

• 上海话——11.15，相较 26.32、21.10 和 88.64。

粤语——4.09 对 6.64、4.76 和 42.62。这一项与 Qwen3.8-Omni Flash 接近打平，并大胜 Gemini 3.8 Flash。

• 湖北 —— 9.46，对比 11.35、7.75 和 48.24。Qwen3.8-Omni Flash 在这一行胜出，而厂商还是把它印了出来。

湖南——8.76，对比 20.30、17.11 和 71.39。

一旦任务不再是转写，同一幅图景就没那么乐观了。在说话人分离上，AISHELL-4 报告 flash 模型的分离错误率为 8.58，而 Qwen3.8-Omni Flash 为 2.80；AliMeeting 上为 8.66 对 3.40；AMI 上为 25.29 对 MiMo-V2.6 Pro 的 11.16。如果你的问题是“谁在什么时候说话”，而不是“说了什么”，这就不是厂商自家表格所推荐的模型。AMI 上的长音频拼接最小排列字符错误率也说明了同样的情况：flash 模型为 39.62，而 MiMo-V2.6 Pro 为 30.91，Qwen3.8-Omni Flash 为 23.19。

音频智能这一图景正是论证变得薄弱的地方。模型在关键行上获胜——BigBenchAudio 99.40、MMAU 82.00——但几乎在所有需要跨长录音进行推理、而非描述短录音的任务上都退让了。

• LongAudioSpan — 41.12，而 Seed2.0 Lite 为 50.26，Qwen3.8-Omni Flash 为 66.40。

长音频 Chain 得分——12.31，而 Qwen3.8-Omni Flash 为 34.54，其思考模式为 48.70，Gemini 3.8 Flash 为 49.63。在厂商选择公布的这项指标上，这是四倍的差距。

MMAR — 74.40，对比 Seed2.0 Lite 的 77.70。MMSU — 78.82，对比 82.10。AudioMarathon — 68.41，对比 70.06。

• 工具调用 — BFCL-v3 Audio 为 81.40，相比之下 Seed2.0 Lite 为 75.08，Gemini 3.8 Flash 为 86.68。

文本基准测试最不令人意外，也最有用，因为它们说明了这个模型不是什么。在通用推理上，flash 模型在几乎每一行都低于与之比较的 omni 模型：GPQA Diamond 为 82.45，而 Qwen3.8-Omni Flash 为 91.00；MMLU-Pro 为 80.00，而后者为 87.70；IFBench 为 59.00，而后者为 81.50；LiveCodeBench v6 为 79.90，而后者为 92.60；AA-LCR 为 73.90，而后者为 80.00。其骨干是一个激活参数为 6.5B 的音频专家，却顶着 126B 的参数总量，而文本表格正是它从外部看起来的样子。如果你想要一个既能听会议、又能写后续代码的模型，inclusionAI 自己的数据表明，你不应指望这个模型承担后半部分。

运行成本是多少

目前引用了两种服务配置，但二者都尚不可审计。用于 128K 上下文的参考 vLLM-Omni 配置，在八块 80 GB H800 GPU 上采用张量并行。经过验证的 SGLang 配置使用四块 GPU，并且仅返回文本。这些是厂商的配置，并非实测结果；而且在计入任何 KV 缓存之前，权重就已有 256 GB，因此不存在更小的版本——仓库在九月发布的 8K 配置不会改变内存下限，因为下限就是检查点本身。

实际解读是，这是一个集群模型，而不是工作站模型。四块 GPU 大致相当于一台正经 GPU 节点的成本；八块 80 GB 的 GPU 则完全是另一条预算线。Ming-3.0-audio-tiny对于任何想在不做出那种投入的情况下测试该系列的人来说就是答案——21 GB 和 2.7B 激活参数可以装进单张大显存显卡——但这个小模型是另一个检查点，在同一批表格上有着自己一贯更差的数据（长音频 Chain 得分 10.56 对 12.31，LongAudioSpan 35.45 对 41.12，URO-Bench-Pro 54.15 对 81.92，VoiceBench 74.29 对 86.74），而且厂商没有发布任何内容来证明其行为可以迁移。

值得计划进行集成的人注意：Talker 是可选的，并且是可分离的。模型卡将其描述为根据模型的输出生成语音，而预设位于它们自己的文件夹中，并带有自己的 requirements 文件，因此纯文本部署不必包含它。文档中记录的两个服务配置默认都返回文本。

路由器在哪些地方值得占有一席之地，在哪些地方又不值得。

OrcaRouter 不提供 Ming-3.0-audio-flash。它不在我们的目录中，我们无法为你提供它的端点，本文中的任何内容都不应被理解为提供该服务的要约。在以这类模型为核心的流水线中，路由器的价值在于模型之外的那一半。语音系统大部分是文本工作：决定向音频提问什么的提示词、把制表符分隔的语言标签转换成结构化输出的后处理、根据转写文本写出的摘要、GPU 节点饱和时运行的兜底方案。这些都是普通的文本调用，而一个 API 覆盖 200 多个模型，0% 加价——按提供商标价透传，因此供应商降价当天我们这边就会生效——比起四份供应商合同，接入起来更简单。自动故障转移让你可以把一个未经检验的新模型放到部分流量后面，而不必把整条路径都押在它上面。

这条边界值得直截了当地说明，因为这正是本文不以注册框收尾的全部原因：你在自己的八块 GPU 上运行的 259 GB 检查点属于基础设施，而不是一次 API 调用。路由器负责路由调用。它不会把集群模型变成托管模型，也不会把 22 次下载变成生产环境证据。

看什么

有三件事会改变局面，而且每一件都能以基准测试做不到的方式加以核验。第一，GitHub 仓库：当inclusionAI/Ming-3.0-audio-flash不再返回 404 时，服务脚本和语音指南就会变成真实可用的东西，上面两套部署方案也变得可审计。第二，独立评分：一旦 Artificial Analysis 或某个竞技场列出这个检查点，四倍的长音频差距就不再是厂商的自述，而开始成为一个数据点。第三，许可证文件：MIT 已在元数据中声明，而仓库中有一个LICENSE文件，就会让它成为事实而非声称——这一区别对任何其采购流程读取的是仓库而不是模型卡片的人来说都很重要。

在那之前，准确的描述并不光鲜。一个严肃的音频语言检查点：在有口音和方言的中文语音上最强，但根据其自己公布的数据，在长音频推理和说话人分离上较弱；纸面上是 MIT 许可，磁盘上约 259 GB，而且直到本周才有文档。六周的沉默不能证明任何事，只能说明 inclusionAI 先发布了权重，后补上了文档——但文档恰恰是告诉你自己正在下载什么的那部分，而现在，它终于可供阅读了。