LFM3-Omni-2B vs Ming-3.0-audio-flash：一部手机对阵一整机架

在基准测试还没开口之前，物料清单就已经决定了这场对比的走向。Ming-3.0-audio-flash拥有 1260 亿参数，BF16 权重约 259 GB，其参考服务配置基于 80 GB H800 做张量并行——128K 配置下用四块，长音频导致内存不足时用八块。LFM3-Omni-2B拥有 21.7 亿参数，以普通 BF16 权重形式发布，设计目标是能在手机上运行。两者都能接收音频输入，也都能出声回答。其中一个是数据中心资产，另一个是可以塞进应用里的功能，而它们几乎其他所有差异都源自这一事实。

它们的发布同样没有太多仪式感。Liquid AI 于 2026 年 10 月 27 日在单篇帖子中宣布了 LFM3 系列，LFM3-Omni-2B 是其中六款 2B 级模型之一；其代码仓库自 10 月 21 日起就已公开。inclusionAI 于 2026 年 9 月 3 日上传了 Ming-3.0-audio-flash，几乎没有任何文档，直到六周后的 10 月 19 日才发布真正的模型卡。两家厂商都没有独立基准测试，而且这两款模型都没有可按 token 租用的托管端点。

在模型上添加嘴部的两种方法

架构差异不在于规模大小，而在于音频所在的位置。

Ming-3.0-audio-flash 会尽可能长时间地让音频保持为音频。一个 Whisper 风格的编码器——32 层、宽度 1,280、128 个 mel 频带——将声音转换为一种表示，再输入到一个 42 层的混合专家骨干网络；该网络拥有 512 个专家，每个 token 选择其中 8 个。语音通过可选的 Talker 模块返回，该模块内置中文语音，并支持参考片段语音提示。宣称的上下文长度为 128K，而配置直到 10 月 13 日的一次提交将位置嵌入从 8,192 提高到 131,072 后，才声称这一数字。

LFM3-Omni-2B 将所有内容都分词为单一流。视频以每秒 2 帧采样，每个 2×2 图像块成为一个语言 token，音频经过 LFM3 因果音频编码器进入与文本相同的 128,000 token 词表。语音输出为 24 kHz 的 LiquidCodec；音频输入为 16 kHz 单声道。整个模型位于 32K 窗口内。

这是一种关于压缩的论证，而且正反两面都成立。LFM3-Omni-2B 的方法让一个 2.17B 模型能在手机端可行——所有东西都是同一种 token，所以所有东西都以同一种方式变得便宜。Ming 的方法则让一个 126B 模型能在不丢弃韵律的情况下记住一小时的录音。两者都不是免费的午餐。

值得并列对比的数字

• 总参数量 — LFM3-Omni-2B 为 2.17B 稠密模型；Ming-3.0-audio-flash 为 126B，采用 512 专家混合架构。

• 活跃参数——每次推理步骤约为 2.17B，相比之下为 6.5B。

• 磁盘上的权重——只有几 GB，而 bfloat16 分片加上 Talker 约为 259 GB。

• 参考硬件——一部手机、笔记本电脑或边缘板，相对于在 128K 配置下以张量并行运行的四个 80 GB H800；当长音频耗尽内存时，则为八个。

• 上下文 — 32K token（涵盖输入和输出），而声明的为 128K。

• 语音输出 — 24 kHz LiquidCodec，支持 19 种语音语言区域；Ming 通过 Talker 返回文本或文本加语音，内置音色并支持参考片段克隆。

• 许可证 — LFM Open License v1.0，一种以收入为门槛的许可证，与 MIT 许可证相对。

• 价格——双方都没有按 token 计价的价格，因为两家厂商都不为这些检查点出售推理服务。

活动参数不是速度表

人们很容易把“6.5B active”与“2.17B dense”放在一起解读，并得出结论：Ming 每 token 的成本只高出三倍。这种解读在两个方向上都是错的。

混合专家模型消耗的是内存带宽，而不只是算术。要从 126B 参数中服务 6.5B 激活参数，就意味着每一层都要把专家权重搬进缓存；而在批大小为 1 时——这正是语音助手所处的运行场景——这几乎相当于每生成一个 token 都要读取 259 GB 中的很大一部分。八卡 H800 配置并不是为实现峰值吞吐量而给出的建议；它是容纳这些权重所必需的配置。拥有 2.17B 参数的 LFM3-Omni-2B 面临相反的问题：没有稀疏性红利，但也没有需要换入换出的东西，而这恰恰是让手机端方案可行的配置特征。

实际结果是，这两个模型具有不同的扩展曲线。随着批处理规模增大，Ming 的每 token 成本会降低，这适合需要处理大量录音通话队列的转写流水线。LFM3-Omni-2B 的每句话成本大致保持不变，这适合批大小为 1、延迟预算为几百毫秒的实时对话。

1260亿能买到什么

inclusionAI 将其评估结果以图片而非表格形式发布，这本身就是一种表态，但数字仍清晰可读。在其自有的评测框架上，Ming-3.0-audio-flash 报告的中文 ASR 平均错误率为 3.45，英文为 3.69，在粤语、上海话、湖南话和闽南语上的方言平均值为 9.40，在 AISHELL-4 上的说话人分离错误率为 8.58。音频推理项包括 BigBenchAudio 的 99.40 和 MMAU 的 82.00。这些是厂商在其自有评测框架上给出的数字，星号标注的是自评行。尚无人复现这些结果。

厂商还是印出来的短板是长音频推理：Long-audio Chain 得分为 12.31，LongAudioSpan 为 41.12，在它自己的对比中都远远落后于托管模型。所以 126B 并非在“理解音频”上全面更强。它更擅长精确听清说了什么、带哪种口音、由哪位说话人所说——而在将长录音记在脑中并跨整段进行推理方面，明显差得多。

21.7亿能买到什么

LFM3-Omni-2B 报告的英语 ASR 词错误率为 6.36，多语言错误率为 6.72，TTS UTMOSv2 为 3.80，VoiceBench 为 64.73，MMAR 为 51.40，工具调用得分为 52.20。其音频输入上限为 16 kHz 单声道，这对语音来说没问题，但对音乐毫无用处。

不要忍不住拿 6.36 和 Ming 的 3.69 作比较。它们不是同一个测试。Ming 的英语平均分是在它自己的一套英语基准上计算出来的；Liquid 的 6.36 只是某一次评估中的一个数字，使用的是它自己的提示词和贪心解码。唯一站得住脚的说法是方向性的：Ming 的 ASR 很可能更好，因为一个 126B 的音频原生模型配上 Whisper 风格的塔结构，本来就有更大提升空间，也因为方言处理正是 inclusionAI 选择主打的方向。至于它究竟是好了两个点还是半个点，从这两张卡片上无从得知。

LFM3-Omni-2B 换来的并不是准确率，而是模型就运行在麦克风所在的地方。对于通话录音流水线来说，这无关紧要。但对于任何有实时用户参与的场景，这会改变整个架构：无需上传、无需往返、没有按分钟计费，音频也不会离开设备。

许可证正是那含蓄的差异所在

Ming-3.0-audio-flash 采用 MIT 许可证。这几乎是最宽松的许可了：允许商业使用、修改、再分发，没有营收门槛，也没有使用领域限制。LFM3-Omni-2B 以 LFM Open License v1.0 发布，这是 Liquid 应用于整个 LFM3 系列的家族许可证，属于设有营收门槛的许可证，而非经 OSI 批准的开源许可证。在基于它构建产品之前，请先阅读该许可证。对于低于该门槛的初创公司来说，差别只是理论上的；对于高于门槛的公司来说，MIT 值真金白银。

集成正是文书工作显露之处

Ming 的服务部署方案仍在推进中。inclusionAI 发布时的表述暗示，你今天就能用 vLLM-Omni 为这一系列模型提供服务；但仓库实际显示的是尚未合并的拉取请求——一个涉及 tts-tiny 检查点，另一个添加 audio-flash 支持。在这些合并之前，运行 Ming-3.0-audio-flash 意味着要在内存足够的机器上使用 Transformers，或者采用厂商文档所述的 SGLang-Omni 路径。这可行，但并不是一条 `pip install` 就能搞定。

LFM3-Omni-2B 的情况恰恰相反：一张记录了微调配方的 Hugging Face 模型卡，外加一个已经流入外界的 Ollama 构建版本。那个构建版本标称 125K 上下文，而模型卡上写的是 32K——这说明打包发布跑得比文档还快。如果你打算用它处理长音频，这个不起眼的细节就很要命。

如果这两种形态都不适合你，替代方案就是租用这项能力，而不是拥有它，而那属于另一项预算。OrcaRouter 正是这一选择中的托管侧——一个 API 覆盖 200 多个模型，按提供商标价零加价，并在提供商掉线时自动故障转移——而 LFM3-Omni-2B 和 Ming-3.0-audio-flash 目前都不在该目录中。诚实的说法是：本文讲的是两个需要下载的模型，而不是两个可以直接调用的模型。

谁应该选哪个

如果你有闲置的 GPU，音频是带口音、多说话人的中文或英文，并且任务是为长录音生成准确的转录或给出有理有据的回答，就选 Ming-3.0-audio-flash。MIT 许可证使其成为两者中更适合构建商业产品的选择，而 128K 上下文使其成为两者中唯一能一次性容纳一场会议的模型。

如果音频在边缘生成、用户正在等待，而且答案需要紧接着用语音返回，就选择{{1}}LFM3-Omni-2B{{/1}}。你要接受的是：换来一个能装进应用里的部署，代价是较小模型的准确率、更窄的语言列表，以及带有收入条款的许可证。

在考虑二者中的任何一个之前，先要问：音频去了哪里？如果答案是“哪里都不去”，那比较就结束了。