Ming-3.0-audio-tiny 现在只需一块 GPU 即可运行——其配置终于标明 128K

名为Ming-3.0-audio-tiny 的模型背后的检查点自 2026 年 9 月 3 日起即可下载——两个 safetensors 分片，17.7 GB，在仓库本身创建九分钟后推送。直到本周才出现的，几乎是所有说明如何运行它的内容。2026 年 10 月 16 日至 19 日，inclusionAI 替换了九月随仓库发布的配置，将带有 8,192 token 窗口的视频-语言-音频变体，改成声称支持 131,072 的纯音频版本，添加了用于生成语音的 Talker，添加了两段参考语音片段及其转写文本，并在仓库整整三天没有模型卡之后，补写了一份。这些文档指向的代码于 10 月 15 日出现在 GitHub 上，所在仓库以更大的同系列模型 Ming-3.0-audio-flash 命名，并且它带有三个面向 tiny 模型的部署配置，而这些配置 tiny 模型此前从未有过。没有人宣布其中任何一项。所以值得回答的问题不是有什么新东西，因为权重已有七周之久，且与它们落地当天逐字节一致。而是读者现在能运行哪些上周一还无法运行的东西，以及他们这样做时在准确率上要付出什么代价。 像这次发布这样的版本背后，有记录的 AI 故障和智能体事件，都收集在 OrcaRouter AI Incident Archive 中，其中每条记录都带有自己的来源、严重程度、置信等级和争议标记。

改动了什么，以提交日期为准

Hugging Face 的提交日志短得可以完整读完，而它的形态却很反常：九月有三个提交，之后三周一片空白，接着四天里冒出六个。

• 9月3日 11:45 和 11:49 UTC — 仓库被创建，随后两个分片在“Add files using upload-large-folder tool”下加入。随附的 README 标题为“Ming Audio V3”，声明采用 Apache 2.0，将仓库标记为 automatic-speech-recognition，并表示该仓库“目前记录了 ASR 路径”。

• 9月17日 — examples/ 文件夹被删除。此后，该仓库仅包含权重、自定义建模代码和一张简短说明卡，别无其他。

• 10月16日 08:14 至 08:20 UTC——关键的一次。config.json被重写：max_position_embeddings在文本骨干上从 8,192 变为 131,072，transformers_version从 4.56.2 变为 5.14.1，audio_config.model_type从bailing_moe_v3_vl_audio变为bailing_moe_v3_audio——那个已不再描述该模型的视频-语言-音频类型。在同一次推送中，auto_map新增了此前没有的AutoModel和AutoProcessor条目，出现了一个processor_config.json，并且talker/目录树也到来了：一个 1.4 GB 的语音模型、一个 1.6 GB 的 VAE、一个 CAM++ 说话人编码器，以及用于英语和汉语的文本规范化有限状态转换器。旧的 README 在同一次推送中被移除——在接下来的三天里，该仓库完全没有模型卡。

• 10月17日 11:44 UTC —“添加语音预设。”两个参考 WAV，US_James.wav 和 灵楷.wav，外加一个包含其精确转写文本的 JSON 文件。

• 10月19日 10:36、11:44 和 11:49 UTC — 三次清理和上传提交。

• 10 月 19 日，13:19 UTC — “添加 Ming-3.0-audio-tiny 模型卡。”8,514 字节，并且是仓库历史中第一份描述语音与音频模型而非 ASR 路径的文档。

GitHub 那边有自己的时间线，而且开始得更晚。inclusionAI/Ming-3.0-audio-flash 创建于 10 月 15 日 03:50 UTC——在权重存在六周之后——并且直到 10 月 19 日 14:53 UTC 仍在推送。它有八个星标、一个 MIT 许可证文件，以及一个 deploy/ 目录，其中包含六个 YAML 配置文件，其中三个按名称是针对 tiny 检查点的。没有 inclusionAI/Ming-3.0-audio-tiny 仓库；该 URL 返回 404，而 tiny 模型的代码与它的同级模型一起位于 flash 仓库中。

配置重写才是真正的重点

上下文长度字段扩大为原来的 16 倍，这种变化要么是表面性的，要么是结构性的；而在本例中，diff 的其余部分表明它是结构性的。9 月，该仓库将 modeling_bailing_moe_v3_audio.py 和 processing_bailing_moe_v3_audio.py 发布到了代码树中，但其配置描述了一个类型为 bailing_moe_v3_vl_audio 的音频塔——这是视频语言构建遗留的产物——并且其模型卡要求你使用 trust_remote_code=False 实例化模型，而这并不是自定义建模文件所期望的做法。10 月的配置是首个让声明类型、声明运行时和代码路径三者一致的配置。

• 主干 — 24 层，隐藏维度 1,536，16 个注意力头，128 个路由专家，每个 token 激活其中 8 个，并设 1 个共享专家，专家中间维度 512，首个稠密层位于索引 1，路由缩放因子 2.5，词表大小 157,184。

• 注意力——MLA，使用 512 维 KV 潜变量和 256 维查询潜变量，rope_theta 为 6,000,000，partial_rotary_factor 为 0.5。低秩 KV 形式正是单卡上 131,072 token 窗口尚可成立的原因：缓存存储的是潜变量，而不是每个头的键和值。

• 音频塔——32 层，宽度 1,280，20 个头，3,000 帧上下文和 128 个 mel 频带，下采样器的核为 [3,3,3]，步长为 [2,2,2]。音频 token id 为 157,168。

• 规模 — 总参数 9.3B，每 token 激活 2.7B，全程使用 bfloat16，并针对 Transformers 5.14.1 声明。

• 输入与输出——输入为音频加文本指令；输出为文本，或通过可选的 Talker 输出文本加合成语音。支持中文和英文，包括口音和方言，具体以卡片为准。

配置重写并不会添加任何权重。仓库中的四个 safetensors 文件——两个 Thinker 分片、Talker、VAE——在我检查过的每个修订版本中大小都相同，一直追溯到最初上传。这是对未更改的检查点所做的文档和打包变更，这正是 8,192 到 131,072 的跃升值得信赖的原因：没有人重新训练任何东西，因此这一说法可以通过加载模型并要求长上下文来检验，而不是靠信仰接受。

还有一处文档信息仍不一致。该仓库顶层的 Hugging Face pipeline 标签显示为 text-to-speech，而模型卡自身的摘要却称其为音频语言模型，可接受指令并返回文本或语音。这个标签是遗留产物，因为 Talker 是最近才被改动过的能力；这种事除了按任务筛选 Hub 的人之外，对谁都不重要。

文本用一块 GPU，语音用两块

这正是 tiny 模型名副其实之处，而它之所以可见，只是因为部署配置现在已公开。flash 模型的文本配置运行在devices: "0,1,2,3,4,5,6,7" 上，并带有 tensor_parallel_size: 8——八张 80 GB 显卡，这是在分配任何缓存之前，256 GB 的 bf16 权重所迫需的配置。tiny 模型自身有三个配置，其中两个只要求一张卡。

• 文本与 ASR，vLLM-Omni —— 在 设备：“0” 上以单阶段运行，张量并行大小为 1，max_model_len 为 131,072，max_num_batched_tokens 为 32,768，gpu_memory_utilization 为 0.92，采样温度为 0.6，最多输出 65,536 个 token。

• 带语音输出的完整音频——分为两个阶段。Thinker 在 devices: "0" 上，占整卡的 0.78；Talker 在 devices: "1" 上，占 0.18；Talker 阶段限制为一个输出 token，温度设为 0.0，因为它不生成文本。

• ASR 复现——一条仅 thinker 的流水线，额外加装了 10-gram 不重复 logit 处理器，每个提示仅限一段音频，max_model_len 131,072，temperature 0.0，32,768 个输出 token。这就是厂商取得其识别数值时所采用的配置；如果你打算进行比较，值得完全照抄。

• SGLang — 单 GPU、单个可见设备、仅文本输出。该卡片明确指出，此路径不支持语音输出。

这些配置文件是文件，而不是文字描述，它们可在 flash 仓库的 deploy/ 目录中看到——共有六个 YAML 配置文件，其中三个以那个微型检查点命名。

请如实解读这些内存数字。0.92 是你把该阶段指向哪张卡时所占的份额，而不是硬性要求：Thinker 的各分片总计 17.74 GB，因此权重能装进一张 24 GB 的卡，还剩下大约 6 GB 用于缓存和激活。0.92 的预留是按同时容纳 131,072 个 token 的窗口加上 32,768 个 token 的批处理来设定的；如果你调低 max_model_len，它就会下降。在单张卡上做不到的是生成语音，因为 Talker 及其 VAE 是第二个进程，带有第二套权重——在 CAM++ 编码器和各 Transducer 之前就有 3 GB——而参考配置给它们分配了独立设备。文本在一块 GPU 上，出声对话要两块：这就是如实的算术，而且这与兄弟型号的八卡配置是另一项预算。

下载内容里究竟有什么

该仓库总计 20.78 GB。Thinker 为 17.74 GB，分成 9.55 GB 和 8.19 GB 两个分片；Talker 增加 1.40 GB，其 VAE 为 1.56 GB，说话人编码器为 28 MB，分词器和归一化器文件则构成剩余部分。厂商没有发布任何量化版本、更小的检查点或 GGUF 转换，因此除非你自己进行量化，否则 bf16 的这个数字就是下限。

• 加载 — AutoProcessor.from_pretrained(..., trust_remote_code=True, use_fast=False) 以及 AutoModelForCausalLM.from_pretrained(..., dtype=torch.bfloat16, device_map="auto", trust_remote_code=True)。模型卡自带的代码片段随后手动将 audio_feats 转换为模型 dtype，这是一个小迹象，表明处理器路径并未被优先考虑。

• ASR 约定——经验证的提示词要求模型说出所讲的语言，并在语言标签与转写文本之间放一个制表符。如果你在构建评测框架，那个制表符就是你的解析器。泛泛的“转写这段内容”指令并不是 inclusionAI 所测量的那套配置。

• 音色 — vLLM-Omni 的默认音色是名为灵小柔的内置音色，模型目录还附带两个参考预设：灵楷和 US_James，并配有对应的转写文本。声音克隆需要一段参考 WAV 及其精确转写文本；卡片提示，不能在同一个请求中同时使用内置音色选择和参考音频片段。

• 许可证 — MIT 位于卡片元数据中，也位于 GitHub 仓库的 LICENSE，其日期为 2025 年。注意缺少了什么：Hugging Face 仓库没有自己的 LICENSE 文件。它内部实际唯一的许可证文本属于位于 talker/data/ 下的一个捆绑语言识别模型。MIT 声明是真实的，但它只隔一次点击，位于以另一个模型命名的仓库中。

• 增长情况——截至本周，三个下载和五个点赞。轻量版模型有 22 个下载和八个点赞。这两个数字都不能说明质量如何；它们只能说明，一个没有卡片、也没有公告的九月上传内容没能传播开来。

基准图片，以及缺失的那一列

三张 PNG 位于 assets/ 中，承载了评测结果，而且这三张图均来自 inclusionAI 自己的运行。该厂商用星号标注自评条目，并说明对比模型是在其自己的提示词和解码设置下复现的，因此这些模型的数字可能与其官方报告不同。我未能找到任何已发布的、针对该检查点的独立评测——没有竞技场条目，也没有第三方评分——这意味着下文中的每一个数字都是厂商在描述自己的模型。这并不是忽视它们的理由；而是应把它们当作设计简报而非裁决来阅读的理由。

与自家同门模型相比，有意义的对比很少，因为两者运行的是同一套测试框架。在识别任务上，较小模型略逊一筹；在长音频推理上，则差距很大。

中文 ASR 平均——Ming-3.0-audio-tiny 的字符错误率为 3.79，而 Ming-3.0-audio-flash 为 3.45。数值越低越好，因此 tiny 落后 0.34 个百分点。

英语 ASR 平均值——4.36 对 3.69。方言平均值——10.29 对 9.40。

• BigBenchAudio — 99.20 对 99.40。实际上基本持平，也是唯一一行没有体现出规模差异的。

• MMAU — 75.90，对比 82.00。MMAR — 67.70，对比 74.40。MMSU — 73.06，对比 78.82。MMAU-Pro — 56.42，对比 66.41。

• 长音频准确率 — 56.39 对比 66.30。LongAudioSpan — 35.45 对比 41.12。长音频链得分 — 10.56 对比 12.31。

• 口语交互——URO-Bench-Pro 为 54.15，对比 81.92，骤降 27.8 分。VoiceBench 为 74.29，对比 86.74。SpeechFCEval 为 69.80，对比 82.60。

• 工具调用 — BFCL-v3 Audio 为 79.80，对比 81.40。音乐 — MuchoMusic 为 58.07，对比 65.65。

方言行是最有意思的例外，因为 tiny 并非一概落后。它在安徽（5.42 对 5.76）、东北官话（4.21 对 4.28）、江苏（11.44 对 12.15）、陕西（5.81 对 6.00）、山东（10.17 对 10.69）和云南（11.28 对 11.53）上胜过更大的同系列模型，却在客家话（24.08 对 16.51）、闽南语（14.15 对 12.84）和上海话（12.49 对 11.15）上大幅落后。一个激活参数为 2.7B 的模型，在与激活参数 6.5B 的模型对比时，能在 15 个方言行中拿下 6 个，这是整个评估中最有利的一点，却被埋在表格中间，被平均值掩盖了。

有两处缺口值得说明，因为它们可核查，而卡片并未指出。第一，识别图像中有五行完全没有给出 tiny 值——AISHELL-4、AliMeeting 和 AMI 的说话人日志行与拼接最小排列行均以破折号印出。无论 tiny 模型在“谁在何时说话”上表现如何，都未公开。第二，文本智能图像有四列，且没有一列是 tiny 模型：其列分别为 Ming-3.0-audio-flash、Qwen3.8-Omni Flash、Qwen3.5-Omni Plus 和 Qwen3.5-Omni Flash。卡片的评估部分称下图数据包含两个 Ming 变体的结果，这对两张音频图像成立，对文本图像则不成立。如果你想知道 tiny 主干能否进行推理对话，inclusionAI 并未告诉你。

这一周实际上为你换来了什么

10月16日之前，想测试这个检查点的读者需要下载 17.7 GB 的内容、一份描述具有 8K 窗口的视频语言模型的配置，以及一张指示他们加载自定义代码却不启用自定义代码的模型卡。10月19日之后，他们有了一份与其自身建模文件相匹配的配置、一个可以用未更改的权重来检验的 128K 宣称、三个具名部署配置方案（其中包含一个单 GPU 方案）、一个带转录文本的语音包，以及一张说明模型用途的模型卡。这些都不是新模型。所有这些，都是磁盘上的一个检查点与某个人能在一下午内评估的检查点之间的差别。

成本正是选型时被掩盖的那部分。在厂商自己的表格里，从 6.5B 激活参数模型换成 2.7B 激活参数模型，能把 GPU 用量降到原来的八分之一，代价是 URO-Bench-Pro 下降 27.8 分、VoiceBench 下降 10 分，以及长音频 Chain 分数下降约五分之一。对转写服务来说这是合理的取舍，对任何需要跨一小时音频进行推理的任务来说则很糟糕；而厂商把这两列并排印在一起，就是为了让你判断自己正在构建的是哪一种。

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

OrcaRouter 不提供 Ming-3.0-audio-tiny。它不在我们的目录中，我们无法为其提供端点，此处任何内容都不应被理解为有意提供该模型。对于围绕这样一个检查点构建的流水线来说，路由器的价值在于检查点之外的另一半工作。语音系统大部分是文本工作：决定向音频提问什么的提示词、将制表符分隔的语言标签转换为结构化输出的解析器、根据转录文本撰写的摘要，以及决定音频文件交给 2.7B 模型还是 126B 模型的分类。这些都是普通的文本调用，而一个覆盖200 多个模型、0% 加价的 API——按提供商目录价透传，因此供应商降价当天就会在我们这边生效——比起一摞供应商合同，接入起来要简单得多。自动故障转移能让你把一个新近有文档说明的模型接入流水线的某一部分，而不必把整条链路都押在它身上。

这条界线值得直白说明。你在自己的 GPU 上运行的 17.7 GB 检查点属于基础设施，而不是一次 API 调用。路由器路由的是调用。它不会把一个开放权重的音频模型变成托管模型，也不会把三次下载变成生产证据。

看什么

有三件事会改变这一局面，而且这三件事都是可核查的。第一，独立评分：一旦某个竞技场或第三方评估者列出这个检查点，27.8 个百分点的语音交互差距就不再是厂商的自我报告，而会成为一个数据点；在此之前，请注意同一厂商还公布了六行方言数据，其中较小的模型反而胜出。第二，LICENSE 文件位于 Hugging Face 仓库内，这将使 MIT 从卡片中的一个链接，变成采购流程实际读取的制品中的一项事实。第三，一个专门的小型 GitHub 仓库：如今，让单 GPU 声明成真的部署配置位于一个以更大模型命名的仓库中，这本来没问题，直到有人把它重命名。

在其中任何一项落地之前，准确的描述并不光鲜。与9月3日相同的权重，约18 GB的Thinker，一个131,072 token的窗口——它出现在配置里，而不是在检查点里；三个服务配置档，文本可装进一张卡，语音可装进两张卡；纸面上是MIT许可；五条它拒绝发布的参考行；以及一张比它所描述的配置晚三天的模型卡。这一周并没有让模型变得更好。它让模型变得清晰可读，而对于一个无人宣布的开放权重检查点来说，清晰可读就是全部产品。