Ming-3.0-audio-flash vs InternLumina U2：两艘安静的船，截然相反的文书

这两个模型都是在没有新闻稿的情况下发布的，而相似之处也大致到此为止。Ming-3.0-audio-flash于2026年9月3日以259 GB的权重形式出现在 Hugging Face 上，几乎没有任何文档，直到10月19日才获得一份真正的模型卡。InternLumina-U2则走的是相反路线：上海人工智能实验室于2026年9月1日发布了推理代码和项目页面，承诺将发布权重，随后又以针对特定硬件的文件夹形式交付了权重。一个团队先推送了产物，六周后才给出解释。另一个团队先写好说明，让你等待产物。两者都没有发布公告，都没有独立基准测试，也都不能替代彼此——一个负责听，另一个负责看和画。这类比较背后有据可查的 AI 故障和静默发布事件，都收录在OrcaRouter AI Incident Archive，其中每条记录都带有自己的来源、严重程度、置信等级和争议标记。

这让它同时成为关于两件事的比较：两种关于开放多模态模型用途的不同押注，以及两种发布它的不同习惯。后半部分比听起来更有用，因为正是这些书面材料告诉你，能否在周二把它部署上线。以下内容全部来自这两个代码仓库及其模型卡。Ming 的数字来自 inclusionAI 自己；InternLumina 的数字来自 Shanghai AI Lab，其自家模型卡将其标注为“初步的、部分结果”。目前尚无第三方对二者进行评分。

两条发布时程，并排对照

日期是这里最客观的证据，所以从它们开始。

• 2026 年 9 月 1 日 04:03 UTC — GitHub 仓库 InternLM/InternLumina-U2 被创建。十三分钟后，一个同名 Hugging Face 仓库出现，其中包含 .gitattributes 文件和一份 README 占位文件。当天的发布内容是代码：一个按任务分节的驱动程序脚本、一份英文和中文 README，以及一份路线图。

• 2026年9月3日 11:45 和 11:49 UTC — inclusionAI 创建了 Ming-3.0-audio-tiny和Ming-3.0-audio-flash，均发布在 Hugging Face 上。九分钟后，25 个分片抵达 flash 仓库。随附的 README 标题为“Ming Audio V3”，仅描述了 ASR 路径。

• 2026年10月13日至19日——Ming 仓库在七天内发生四次变动：一项将上下文从 8,192 提升到 131,072 的配置、一次移除视频语言变体的重新上传、一个语音预设文件夹，最后是模型卡、资产以及 MIT 重新许可。 inclusionAI/Ming-3.0-audio-flash于10月15日出现在 GitHub 上。

2026年9月24日之后的某个时候——internlm/InternLumina-U2 在 Hugging Face 上不再是存根，并新增了两套检查点目录树，ascend/ 和 nvidia/，每套各七个分片，总存储约 67.6 GB，每个硬件目录树约 33.8 GB。该仓库最后修改于 9 月 24 日。没有重写模型卡，没有包含具体数字的基准测试表，也没有技术报告。

模式反过来了，实际后果也反过来了。Ming 的权重从九月初起，任何愿意读配置文件的人都能运行；而它的文档根本不存在。InternLumina 的文档从第一天起就有；它的权重却没有，而当权重终于发布时，发布内容中并没有模型卡所承诺的对比表。

每个模型实际上是为了做什么而构建的

Ming-3.0-audio-flash 是一个原生音频语言混合专家模型：总参数量为 1260 亿，每次推理步骤激活 65 亿参数；音频编码器和投影器馈入一个 42 层主干，该主干包含 512 个专家、每个 token 激活 8 个专家；词汇表包含 157,184 个 token；音频塔采用 Whisper 风格，32 层、宽度 1,280、128 个 mel bin。输入为音频加文本指令。输出为文本，或通过可选的 Talker 模块输出文本加合成语音；该模块内置中文语音，仓库中提供两段参考音频片段。声明的上下文长度为 128K，模型卡中的服务配置为八块 80 GB H800 以张量并行运行。

InternLumina-U2 是一个 160 亿参数的稀疏混合专家模型，激活参数为 10 亿；它被构建为扩散语言模型，而不是自回归语言模型——它并行细化整个序列，而不是从左到右逐个生成 token。其视觉表示完全离散：来自苹果 AToken 分词器的八个视觉 token 码本，在输入侧每个位置拼接成一个主干 token，在输出侧则按码本逐个预测。这种设计的目的在于统一：文本问答、图像理解、图像编辑、文本到图像生成、视频理解和 3D 理解都在 LLaDA-2.0 扩散主干上，通过同一词表和同一套权重运行。

把这两段描述放在一起读，比较就会归结为一句话。Ming-3.0-audio-flash 是一个规模很大的专才，深入处理单一模态。InternLumina-U2 是一个通才，总参数量不大，力求把五件事都做得够用。两种设计都不是对彼此的妥协；它们是对不同问题的回答。

把每一个都转换成词元，这才是真正的区别。

如果只看参数量，你会得出 Ming 是那个模型的八倍的结论。这种解读在两个方向上都是错的，原因在于两者各自暴露的接口。

• 输入 —— Ming-3.0-audio-flash：音频与文本。InternLumina-U2：文本、图像、视频帧与 3D 资产。

• 输出 — Ming-3.0-audio-flash：文本，可选语音。InternLumina-U2：文本、图像、编辑后的图像；无音频、无视频、不支持 3D 生成。

• 解码 — Ming-3.0-audio-flash：基于 157,184 个 token 词表的自回归。InternLumina-U2：基于离散多码本视觉词表的块扩散。

• 总参数与激活参数 — Ming-3.0-audio-flash：总参数 126B，激活参数 6.5B。InternLumina-U2：总参数 16B，激活参数 1B。

• 磁盘上的权重 — Ming-3.0-audio-flash：约 259 GB，分布在 25 个分片中，外加一个 Talker 和一个 VAE。InternLumina-U2：仓库中为 67.6 GB，拆分为两个硬件树，每个树包含七个分片，各约 33.8 GB。

• 许可证 — 两者在精神上都与 MIT 相近，但实际上不同：Ming-3.0-audio-flash 根据其卡片采用 MIT，InternLumina-U2 根据其仓库和卡片采用 Apache-2.0。

• 独立评估——两者均无。

硬件，而这正是两者分歧最为剧烈之处

InternLumina-U2 最值得关注的工程亮点并不在架构本身，而在其后端方案。该仓库同时提供了 Ascend 目录树和 NVIDIA 目录树，实验室表示训练、评估和推理均已适配华为 NPU 与 NVIDIA GPU，并在两者之间实现了算子级数值对齐。对于采购流程涉及非 NVIDIA 加速器的人来说，这是一个真正的差异化优势，而且它可以在文件树中核查：两个完整的检查点目录，各自带有独立的配置、分词器和并行方案。

Ming-3.0-audio-flash 没有这样的说法。它的参考配置是八块 80 GB H800s；其经验证的替代方案是四 GPU 的 SGLang 配置，仅返回文本。仓库中没有 NPU 路径，而总参数 9.3B、激活参数 2.7B 的小号同门，正是任何无法投入一整个节点的人的答案。

在当代意义上，这两个模型都是部署项目，而不是 pip 安装。InternLumina 自己的材料明确表示，生成路径并非标准做法：block-diffusion 生成 API 并不是 Transformers 的 generate 接口，AToken 分词器需要 FlashAttention，而且 3D 流水线要求 Blender 4.5 在分词化之前先将 GLB 资产渲染成视图。Ming 的路径更常规—— AutoProcessor 加上 AutoModelForCausalLM 并设置 trust_remote_code=True——但内存下限高出八倍。

供应商的数据说明了什么，以及它们无法说明什么

这两张表无法相互比较，因为这两个模型没有任何一项共同的基准测试。这不是在回避问题，而是证据的真实形态。

在 inclusionAI 的评测图像上，Ming-3.0-audio-flash 报告的中文 ASR 平均错误率为 3.45，英文平均为 3.69，方言平均为 9.40，MMAR 为 74.40，BigBenchAudio 为 99.40。同样的图像也显示了它的失分之处：AMI 说话人分离错误率为 25.29，而 MiMo-V2.6 Pro 为 11.16；长音频 Chain 得分为 12.31，而 Qwen3.8-Omni Flash 为 34.54。其文本基准是模型卡中最弱的部分——GPQA Diamond 82.45、MMLU-Pro 80.00、IFBench 59.00——这正是 6.5B 激活参数的音频专用模型在被要求用自然语言推理时的表现。

InternLumina-U2 的模型卡报告了 ChartQA 86.52、CharXiv-DQ 83.65、MathVision 33.22、HallusionBench 62.15、VideoMME 51.26、MVBench 59.74、3D MM-Vet 41.8、DPG-Bench 87.10 和 GenEval 0.81——但随后又自我拆台，因为项目页面自己的表格显示 LLaDA2.0-Uni 的 GenEval 为 0.89，优于那个声称要超越它的模型。模型卡最醒目的免责声明“初步、部分结果。完整对比表将出现在即将发布的技术报告中”至今依然成立。并没有技术报告。

把两组数字放在一起看，它们描述的是互补的优势和一个共同的弱点：两者都尚未被训练它们的实验室之外的任何人复现。

哪一个，给哪位读者

如果你的产品涉及语音——带方言覆盖的会议转写、呼叫中心音频、语音回答、配音——那么 Ming-3.0-audio-flash 是两者中唯一适用的；说实话，它也是同类中唯一公布过如此具体方言数据的开放权重模型。请按一个节点来规划，或者从更小的同系列模型起步，并接受它在长音频评分上较弱。

如果你的产品涉及图像——文档阅读、图表问答、编辑、3D 资产描述，或者一个既能读又能画的单一模型——那么 InternLumina-U2 是唯一适用的选择；而如果你不打算买 NVIDIA，Ascend 技术栈就是一个真正值得考虑的理由。做好和分词器较劲的准备。

如果你两者都需要，那你就是在运行两个模型，而有趣的问题就变成了运营层面的：两个检查点、两条工具链、两套许可条款，一个多模态产品。这就是 2026 年末开放权重工作的常态，也正是路由存在的原因。

狭义而言的路由层

OrcaRouter 并不提供这两个检查点。Ming-3.0-audio-flash 和 InternLumina-U2 都是您自行运行的开放权重模型；两者都不在我们的目录中，也不会出现在对我们 API 的调用中。我们提供的是外围的文本处理工作：为图像编辑指令构建提示词、将 Ming 转写稿整理成结构化笔记的摘要器，以及判断传入资产应交给这两个模型中的哪一个的分类器。

最后这一点值得单独说明。一条同时处理语音和视觉的流水线，最终会落到一个路由决策上——音频交给 Ming 节点，图像交给 InternLumina 节点——而这个决策本身就像任何其他模型调用一样。把它放在一个 API 覆盖 200 多个模型、0% 加价之后，供应商目录价原样透传，就能让调度器与其他所有环节共用同一个密钥。自动故障转移在这里同样重要，但并非为了那些自托管检查点，而是为了给它们提供输入的分类步骤：如果路由所用的模型性能下降，回退的应该是另一个模型，而不是一条坏掉的流水线。

这些都不能把一个 259 GB 的检查点变成托管服务，暗示并非如此会具有误导性。

接下来看什么

对于 Ming-3.0-audio-flash，缺失的部分是仓库中的许可证文件（MIT 目前位于模型卡元数据中）以及音频语言路径的服务集成；vLLM-Omni 支持上一代 Ming，并且已为 7.9B T​TS 模型提交了一个仍处于开放状态的拉取请求，但针对 126B reader 尚无任何内容被合并。对于 InternLumina-U2，缺失的部分是技术报告及其承诺的完整表格；在那之前，针对 LLaDA2.0-Uni 的 GenEval 行是任何人都能核对的唯一跨模型比较，而且结果并不利于较新的模型。

这两次发布共同拥有的一点，比它们各自的缺口都更有用。两家有实力的实验室发布了规模可观的开源权重多模态模型，却没有告诉任何人。这并不是模型很差的迹象——而是说明发布公告已经成了可选项，仓库现在才是主要信息来源。去读它。