LFM3-Omni-2B 对比 Ming-3.0-audio-tiny：以堆栈替代方案对阵专用模型

两个模型都被宣传为小型，都能出声回答，除此之外几乎毫无共同点。LFM3-Omni-2B是 Liquid AI 推出的 21.7 亿参数稠密检查点，可接收文本、图像、视频和音频，并返回文本或 24 kHz 语音。Ming-3.0-audio-tiny是 inclusionAI 的 93 亿参数混合专家模型，每步激活 27 亿参数，可接收音频和文本，并返回文本或 44.1 kHz 语音。一个试图取代整套助手技术栈，另一个则试图成为尽可能最好的耳朵。专才模型和通用模型可以共用一个密钥。一个端点请求按规则路由，若某条路径失败则自动故障转移。

这个命名让事情变得比本应更复杂。在 Ming 家族中，“Tiny”指的是它相对于 Ming-3.0-audio-flash 的定位，而不是它的绝对规模：它的总参数量为 9.3B，是 Liquid 模型参数量的四倍多。而 LFM3-Omni-2B 并不是一个硬生生加上视觉能力的音频模型——它是一个恰好带有音频通路的通用多模态模型。逐项对比对两者都不公平。按它们所承担的任务来比较，才是唯一有意义的比较。

每一个实际上是什么

Ming-3.0-audio-tiny 是一个原生音频语言模型：由音频编码器和投影器为稀疏 MoE 语言主干提供输入，并设有一个独立的 Talker 阶段，在你需要时生成语音。它支持中文和英文，包括口音和方言，并支持基于参考音频片段和转录文本进行声音克隆。其权重采用 MIT 许可，可在 Hugging Face 和 ModelScope 上获取；社区已有针对 MLX 和 GGUF 的量化版本，并且有一个可用的 ROCm 演示，展示了基于它构建的低延迟语音助手。该仓库于 2026 年 9 月初上传，模型卡和配置在 10 月中旬更新，这时它才真正变得可用。

LFM3-Omni-2B 则是相反的构建方式。它采用单一稠密主干，配备视觉编码器、因果音频编码器和用于语音输出的 LiquidCodec，并经过训练，使一组权重能够处理四种输入模态和两种输出模态。它于 2026 年 10 月 27 日作为 Liquid 六模型 LFM3 系列的一个分支发布，没有单独公告，也没有独立评估。模型卡报告了 2.17B 参数、32,768 个 token 的上下文以及 LFM Open License v1.0。

• 架构——2.17B 稠密任意到任意模型，对比总参数 9.3B、每 token 激活 2.7B 的稀疏 MoE，外加独立的语音 Talker。

• 输入 — 文本、图像、带配乐的视频、16 kHz 音频，对比仅音频和文本。

• 语音输出 — 通过 LiquidCodec 实现 24 kHz，流式传输速度快于实时；相比通过 Talker 的 44.1 kHz 单声道，并提供命名预设音色和克隆功能。

• 语言 — 相较中文和英语，支持 16 种文本语言和 19 种语音区域设置，包括方言。

• 上下文 — 卡片上标明为 32,768 个 token，而卡片上未标明上下文窗口；已发布的配置描述了 131,072 个 token 的位置预算。

• 许可证 — LFM Open License v1.0，设有收入门槛，与 MIT 相比。

• 占用空间 — 约 4.3 GB（BF16），而 BF16 下约为 21 GB；采用 int8 专家量化后降至约 12.5 GB。

真正重叠的那两行

跨实验室的基准测试表大多只是做样子，因为每个实验室都选自己的评测框架。这里的重叠足够小，可以准确说明：有两个数据集同时出现在两家厂商的报告中，而且两者都是音频任务，其方法学相当标准。

• 英语 ASR 词错误率 — LFM3-Omni-2B 为 6.36，Ming-3.0-audio-tiny 为 4.36。越低越好，Ming 领先两个绝对百分点，错误率大约低三分之一。

• VoiceBench — 64.73 对 74.29。Ming 在语音指令遵循和语音助手行为方面领先 9.6 分。

在两者都衡量的任务上，专用模型胜出，而这是预期结果。Ming 将 27 亿活跃参数用于听和说。LFM3-Omni-2B 将 21.7 亿活跃参数同时用于听、说、看和读。一个不把容量分成四份的模型，在它所专注的那一种能力上理应更好，而事实也确实如此。

Ming 报告而 LFM3-Omni-2B 未报告的，是一份更长的清单：中文 ASR 字符错误率 3.79、方言字符错误率 10.29、BigBenchAudio 99.20、MMAU 75.90、MMAU-Pro 56.42、长音频准确率 56.39 和 BFCL-v3 Audio 79.80。对于这个规模的模型来说，这些是很强的数字，而且它们描述的是一个专门在音频推理上接受评估的系统，而不是多模态表格中的一列。Liquid 卡片中最接近的对应项是音频理解 MMAR 51.40 和工具调用得分 52.20——但该工具调用基准与 BFCL-v3 Audio 不是同一项测试，把这两个数字并排放在一起，正是本博客旨在避免的那类比较。

这场对决无法定论的基准

有趣的问题不是哪个模型听得更好，而是单个全模态模型能否完成流水线无法完成的音视频推理。Ming-3.0-audio-tiny 完全没有视觉通路：它无法看着一帧画面描述正在发生什么，也无法在观看视频的同时回答关于该视频配乐的问题。LFM3-Omni-2B 两者都能做到，而 Liquid 报告的 Daily-Omni 70.09 和 WorldSense 47.10 正是针对这一能力。

那些数字在 Ming 的模型卡中没有对应项，因为 Ming 并不尝试这项任务。因此，这场对比归结为范围问题，而不是质量问题：如果你的应用是音频流的语音接口，那么 Ming 是能力更强的“耳朵”，且活跃计算量更小。如果你的应用是摄像头加麦克风加扬声器，那么 LFM3-Omni-2B 在做 Ming 无论规模多大都做不到的事，而音频上的差距就是你为摄像头付出的代价。

这项代价并不小。在语音接口上，英语词错误率相差两个百分点，就是一份能快速浏览的转录文本和一份你必须逐字纠正的转录文本之间的差别。如果音频路径是主打产品，而视觉只是附加功能，那么诚实的建议就是：音频使用 Ming，帧使用单独的视觉模型，即使这意味着要维护两个检查点。

内存账单比基准测试更能决定部署。

Ming-3.0-audio-tiny 在 BF16 下需要约 21 GB 权重，采用 int8 专家量化时约 12.5 GB；完整的音频输出部署可以将 Thinker 和 Talker 拆分到两块 GPU 上。LFM3-Omni-2B 需要约 4.3 GB。这不是一个小差别：它是单块中端 GPU 与一台必须提前规划的机器之间的差别，也是手机与服务器之间的差别。

对比结论会因你衡量的指标不同而反转。Ming 的 2.7B 激活参数让它在总规模不小的情况下，每 token 的成本依然很低，而这正是稀疏 MoE 的核心意义所在。LFM3-Omni-2B 是稠密模型，因此每个 token 都要付出完整的 2.17B 计算量——但整个模型只需一小部分显存就能装下，并且能在 Ming 根本无法运行的硬件上跑起来。

路由经济学在这里变得具体。OrcaRouter 按提供商标价原样传递，不收取任何加价，因此更便宜的专业模型和更昂贵的通用模型可以共用一个密钥，而无需另签合同；供应商调价当天就会反映到你的账单上，而不是等到下一次续约。目前 LFM3-Omni-2B 和 Ming-3.0-audio-tiny 都不在我们的目录中，因此这只是在说明平台如何定价，并不是声称你现在可以通过我们调用其中任一模型。但这两个模型所形成的模式——用便宜的专业模型处理常见情况，用通用模型处理困难情况——正是路由器存在的意义所在。

许可是个问题，这才是真正的分岔点

Ming-3.0-audio-tiny 采用 MIT 许可证。LFM3-Omni-2B 则适用 LFM Open License v1.0，这是一份自定义协议，其中设有收入门槛，由它决定商业使用是否需要另行安排。对于研究原型来说，这种差异只是学术层面的问题。但对于产品而言，这是法务部门首先会追问的一点，而且它能压倒任何规模的基准测试差距。

MIT 许可证也解释了为什么 Ming 已经拥有社区移植版本：MLX 构建、GGUF 量化、一个 ROCm 语音助手演示。它们之所以存在，是因为该许可证让这些变得容易，而它们也正是 Ming 如今能在 Liquid 从未测试过的硬件上部署的原因。LFM3-Omni-2B 于 10 月 27 日发布，下载量为 83 次，并且它只记录了一条仅用于文本输出的服务路径。它的生态系统尚不存在。

实际的差距非常明显。在音频准确性、每个活跃参数的内存效率、对中文及方言的语言覆盖、声音克隆和许可自由度方面，Ming-3.0-audio-tiny 是当下更稳妥的选择。在模态覆盖和原始体量方面，LFM3-Omni-2B 是两者中唯一能观察一个房间并谈论它的模型。

谁应该接哪一个

如果你正在构建语音产品——转写、语音对话、声音克隆、通话分析——并且要么不需要视觉能力，要么愿意搭配一个单独的视觉模型，那么请选择 {{1}}Ming-3.0-audio-tiny{{/1}}。{{2}}MIT 许可证{{/2}}、现有的量化版本以及在 ASR 上领先两个百分点的优势，使其成为风险更低的部署选择；尽管总参数量为 9.3B，其稀疏架构仍能降低每个 token 的成本。

如果设备同时有摄像头和麦克风，且约束是内存，就选择 LFM3-Omni-2B。一个能看、能听、能说的 4.3 GB 检查点，与一个 21 GB 的音频专用模型属于不同类别的对象；再高的 ASR 准确率，也无法弥补模型装不下这一点。要接受：你买的是广度，而非深度；并且它附带的每一个音频数字都是厂商报告的，且未经复现。

两份模型卡都没有告诉你的是，它们在同一个应用中的表现如何。这项测试——相同的音频、相同的设备、相同的延迟预算——尚未由这两家公司以外的任何人进行过。在它完成之前，决策依据的是范围和许可，这些今天就可以知道，而不是准确性，因为准确性目前无法得知。