Ollama 上的 LFM3-Audio-2B：更好的语音，同样的耳朵

Liquid AI 的 LFM3-Audio-2B今早只需一条命令即可下载。ollama run lfm3-audio 会拉取 2.1 GB，并启动一个 2B 参数模型；该模型可接收文本或音频，并以文本、24 kHz 语音或两者兼有的形式作答。该模型本身发布仅一天——它于 2026 年 10 月 27 日作为六款模型组成的 LFM3 家族的一员推出。10 月 28 日的新变化在于交付方式，而首先值得了解的一点就在 Liquid 自己的基准测试表中：与 LFM2.5-Audio-1.5B（即它所取代的型号）相比，语音质量大幅提升，音频理解几乎翻倍，而英语语音识别则完全没有提升。

本文剩余部分将今天可核查的内容与不可核查的内容区分开来。音频分支只获得了家族博客文章中的一段内容和一个模型卡——并没有单独的“Introducing LFM3-Audio”发布公告——而且我们在任何地方都找不到该模型的独立基准测试结果。除非句中另有说明，下文中的每个数字都来自 Liquid。

发布了什么，以及公告内容有多单薄

Liquid 10 月 27 日的文章《推出 LFM3：面向专用智能的每一种模态》宣布了六个基于 LFM3-1.7B-Base 训练的 2B 级模型：文本、视觉、音频、全模态，以及从视觉和全模态分支专门化而来的两个决策模型。音频是四个模态分支之一，却只占了一段——UTMOSv2 的提升、50 毫秒的首 token 时间数据、87× 实时编解码器。没有专门针对音频的文章，没有音频基准博客，Liquid 定价页面上也没有任何 LFM3 模型的价格条目。

本周，三件作品将模型呈现在读者面前：

• 权重 — LiquidAI/LFM3-Audio-2B 位于 Hugging Face 上，依据 LFM Open License v1.0 发布，并附有包含完整对比表的模型卡。

• llama.cpp — PR #31257 于 10 月 27 日合并，新增 LFM3-Audio-2B 和 LFM3-Omni-2B。它使音频编码器卷积和编解码器保持未量化，通过 TTS 标志提供男声或女声，并将实时 ASR 标记为后续 PR，而非本次合并的一部分。

• Ollama — lfm3-audio，2.1 GB，标签为 latest 和 2b，显示 19 次下载，截取时显示“一小时前更新”。页面标题显示有五个模型；已发布两行。

Ollama 的上架条目是最重要的，因为它是唯一一条不以阅读模型卡为起点的途径。而且它出现时没有任何形式的公告——没有帖子，没有更新日志，模型自己的卡片上也没有任何指向它的内容。

规格表，包括几乎所有人都抄错的那个数字

• 参数 — 总计 2B，基于 LFM3 主干，搭载自研因果音频编码器和 LiquidCodec 分词器

• 输入 — 文本，或以 16 kHz 采样的音频

• 输出 — 文本、24 kHz 语音，或交错的文本和语音

• 上下文 — 32K token，涵盖输入加上输出。这不是发布报道中反复提到的 256K 这个数字：那个数字属于 LFM3-1.7B，也就是文本模型。音频分支自己的页面写的是 32K。

• 语言 — 18 种，但列为 19 个区域设置，因为英语出现了两次，分别为英式英语和美式英语变体。实时 ASR 仅支持英语；翻译在英语与其它语言之间互译时效果最佳。

• 许可证 — LFM Open License v1.0，年收入低于 1000 万美元可免费商用，超过该门槛则需付费商业许可证。

• 占用空间 — 作为 Ollama 构建版本时为 2.1 GB。

其中两行值得停下来想一想。上下文数字是摘要会在好几个月里都搞错的那个，因为家族宣传帖主打的是 256K，而音频卡上却悄悄写着 32K。语言数量则是伪装成语言数量的区域设置数量：十九个条目、十八种语言，多出来的工作量由英语的两个变体承担。两者都不算丑闻，但都会改变你向用户承诺的内容。

一条命令，以及那个与卡片相矛盾的字段

ollama run lfm3-audio 确实就是全部配置。页面给这个模型打上了 tools、audio 和 2b 标签，而模型表格正上方的 readme 说它可以接收文本或音频，并以文本、语音或两者兼有的方式回应。模型表格却与此不一致：两个标签都把输入列为“Text”，上下文列则是一个短横线。

这值得认真对待，而不是把它当作渲染怪癖而置之不理。自 2026 年 4 月的 v0.20 起，Ollama 就支持音频输入，当时 Gemma 4 带来了音频能力、`ollama transcribe` 命令以及 OpenAI 风格的 `input_audio` 部分。相关机制已经存在。尚未确认的是，它是否已为此检查点接通——音频标签是一种能力声明，而不是测试结果。如果你的计划以“把 WAV 管道输入 Ollama”开始，那么在围绕它进行设计之前，先用一个文件验证一下。

从另一边看，语音输出也呈现出同样的格局。llama.cpp 的合并暴露了一个 TTS 语音标志；Ollama 的页面没有记录任何等价项，而 readme 将语音输出描述为模型的属性，而不是 CLI 的功能。把每句话反过来看，结论依然成立：如今的终端路径只是一个语音模型中负责文本的那一半。全双工语音聊天需要走 Python 或 llama.cpp 路线。

Liquid 发布的记分牌

六个数字，其中四个有前代数值。它们全都来自 Liquid 的模型卡，没有具名测试集、没有评测框架，也没有方差。

• 英语 ASR，词错误率 ↓ —— LFM3-Audio-2B 为 6.23，而 LFM2.5-Audio-1.5B 为 6.13。持平，也是唯一没有变化的一行。

• 多语言 ASR，WER/CER ↓ — 6.03。未公布前代数值。

• 英语 TTS，UTMOSv2 ↑ — 3.83 对比 3.22。提升幅度很大；4.0 通常被视为接近人类水平的门槛。

• VoiceBench ↑ —— 73.13 对比 55.17。

• 音频理解，MMAR ↑ — 50.60 对 25.85。几乎翻倍。

• 语音工具调用，内部评估 ↑ — 58.50。无前代数据。

在同一张表的其余对比对象中，它是一个不错的小型模型，而非领先者。Voxtral Mini 3B 的 WER 为 5.51，NVIDIA Audex 2B 为 5.99，两者都优于 6.23。Qwen2.5-Omni 3B 在音频理解上取得 54.41，对比 50.60。Gemma 4 E4B 在工具调用上取得 72.40，对比 58.50；而 Liquid 自己的参数行把该 Gemma 标为 8B，对比本模型的 2B——“E4B”这一名称计算的是激活参数，而非总参数。诚实的总结是：有竞争力的 ASR、语音输出上的明显提升，以及对于 2B 而言扎实的音频推理——但并非任何一列中的纪录保持者。

6.23 对 6.13 的差距处于抽样噪声所能产生的范围内，不应被解读为性能回退。3.83 对 3.22 的差距则不是——0.6 分的 UTMOS 变化远超该范围。站得住脚的解读是，Liquid 这一代把精力花在了生成上：更好的语音、更好的音频推理，以及一个在底层编码器更换时仍守住阵脚的 ASR 前端。我们没有发现任何一行的第三方复现，因此在有人发表复现之前，应把这一排序视为假设。

为什么编解码器比模型更长寿

LiquidCodec 是本次发布中除检查点之外值得关注的部分。它把 80 毫秒的语音打包成 12 个离散 token，可解码回 24 kHz 并支持流式处理，Liquid 在 M4 Max 的单个 CPU 线程上测得约为实时速度的 87 倍。因果编码器使其能够在语音进行期间进行预填充，而不是在语音结束后才进行，这也是“低至 50 毫秒”的首 token 时间指标的来源。

这两个数字是本次发布中被引用最多、却最难以复现的内容。两者都是厂商在指定 Apple 硬件上测得的数值，既没有测试框架，也没有音频集，更没有百分位数。它们描述的是最佳情况。手机、Raspberry Pi 或共享的 x86 虚拟机都达不到这样的结果，而发布说明中也没有说明它们实际能达到什么水平。

对于发布仅一天的模型来说，运行时支持范围异常广泛：Transformers 5.20.2 或更高版本并启用 trust_remote_code，vLLM 和 SGLang 用于 BF16 checkpoint，llama.cpp 用于 GGUF，Apple 芯片上的 MLX 4-bit，ONNX Runtime 用于可移植性，以及单 GPU 微调。自定义代码这一要求才是需要锁定版本的关键所在。LFM3-Audio 从自己的模块加载，并从单独的 audio_tokenizer 目录读取编解码器权重，因此未锁定版本的环境迟早会变成一张支持工单。

本地语音与托管端点对比

一个 2B 音频模型只有 2.1 GB，之所以有意思，是因为替代方案会按每一秒音频向你收费。自托管有固定成本——一台你已经拥有的机器、一次下载，没有按分钟计费。托管端点则有按 token 计算的边际成本，且完全没有运维负担。

请准确说明双方各自覆盖什么。托管式文本转语音——也就是我们路由的那类服务，例如每百万 token 输入 $0.60、输出 $12.00 的 gpt-4o-mini-tts，或输入 $0.50、输出 $10.00 的 gemini-2.5-flash-preview-tts——只把文本转成语音，仅此而已。LFM3-Audio-2B 还能听、转写和翻译，并且在断网状态下运行。它们解决的是同一个语音智能体的不同两半。

LFM3-Audio-2B 不在 OrcaRouter 上。我们提供的音频模型是托管的语音端点，因此本月语音产品最诚实的拆分是：本地语音输入输出使用 Liquid 模型，而所有文本侧的内容都放在 一个端点支持 200+ 模型——按提供商标价 0% 加价，提供商出错时自动故障转移；如果你想把多个模型组合成一次调用，还有路由 DSL。这正是双运行时设置能够存活的原因：托管那一半一份合同，本地那一半一次下载。

本地那一侧的成本并非为零：2.1 GB 权重、一个需要保持存活的进程，而且没有 SLA。如果音频从不离开这栋楼，这个取舍很容易做。如果音频会离开，托管价格足够低，通常由运维负担来决定这个问题。

这周该由谁来运行它，谁又应当等待？

如果你想要在笔记本电脑上运行本地语音闭环，并且目前能接受在终端中以文本形式输出，那就运行它。如果你需要以某种语言输出语音，而你现有的托管语音在该语言上表现较弱或成本较高，那就运行它——十八种语言比大多数小型 TTS 模型提供的覆盖范围更广。如果你有一些不能离开本机的录音，并且想用一个模型同时得到转写和摘要，那就运行它。如果你正在制作语音工具调用的原型，并希望模型与工具运行在同一台机器上，那就运行它。

等等，如果 ASR 准确率就是产品本身。6.23 的词错误率算得上体面，但在 Liquid 自己的表格里仍落后于三个模型。等等，如果你今天就需要流式转写——实时 ASR 是一个后续的 llama.cpp PR，而且落地时仅支持英语。等等，如果你需要模型知道东西：模型卡推荐检索，并明确不推荐在这个规模下进行智能体编程或多步推理。还有，等等，如果你需要供应商 SLA，因为 Liquid 的定价页面列出的是 d1、d1-ultra 和 LFM2.5-24B-A2B，根本没有 LFM3 音频端点。

这次发布没有回答的三个问题

LFM3-Audio-2B 和 LFM3-Omni-2B 是同一个模型吗？

不。它们共享 LFM3 主干，并且都出现在同一个 llama.cpp 拉取请求中，但 Omni 在音频之上增加了视觉，是两者中更大的投入。如果任务是电话通话、会议录音或语音命令，Audio 就是承担较小任务的较小模型。如果任务需要在听的同时查看某物，那就是 omni 分支。

它能转写直播流吗？

目前还不能通过 llama.cpp 实现。该合并将实时 ASR 列为后续工作，模型卡也明确指出，即使实时 ASR 将来存在，也仅支持英语。目前受支持的路径是对录音进行批量转写，具有 32K tokens 的上下文——对于长文件，这大致是需要据此规划的长度上限，因为音频 token 和文本 token 共享这一预算。

它需要 GPU 吗？

不，而这正是 GGUF 构建的意义所在。2.1 GB 的 Ollama 产物在 CPU 上运行。87× 实时这一指标衡量的是编解码器，而不是语言模型，所以不要把它理解为你硬件上的端到端速度。Apple silicon 通过 MLX 或已合并的 llama.cpp 支持拥有最顺畅的路径；在 x86 上，预计 CPU 解码会成为瓶颈，在向任何人承诺延迟数字之前先进行测量。

什么会改变这一裁决？

三个信号，按重要性排序。第一，实时 ASR 后续功能在 llama.cpp 中落地——这会把一个批处理转写器变成可以接上麦克风使用的东西，而这正是大多数人真正想要的用例。第二，在标准数据集上跑一次独立的 WER 评估；在它出现之前，唯一能让这个模型的 ASR 保持可信的，就是一张厂商表格，拿它和厂商自家上一代模型作比较。第三，音频分支公开发布的 API 价格，这会告诉我们，Liquid 是打算把听觉能力作为服务来卖，还是继续走模型权重路线。

在那之前，准确的描述既范围有限又实用：一个你一分钟内就能下载的 2B 语音模型，它说得比它所取代的模型更好，听得大致一样好，而且还没有独立见证者。对于笔记本电脑上的原型来说，这已经够了。对于生产级转录流水线来说，这还不够——而这两句话之间的差距，正是发布与评估之间的距离。