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

Liquid AI 的 LFM3-Audio-2B今早成為一行指令即可下載的模型。ollama run lfm3-audio 會下載 2.1 GB，並啟動一個 20 億參數模型，該模型可接收文字或音訊，並以文字、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 模型的定價條目。

本週有三件作品讓這個模型呈現在讀者面前：

• 權重 — Hugging Face 上的 LiquidAI/LFM3-Audio-2B，採用 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 tokens，涵蓋輸入加上輸出。這不是發表報導中反覆提到的 256K 數字：那個數字屬於文字模型 LFM3-1.7B。音訊分支自己的頁面寫的是 32K。

• 語言 — 18 種，列為 19 個語言地區，因為英文出現兩次，分別為英式與美式變體。即時 ASR 僅支援英文；翻譯以英文為目標或來源時效果最佳。

• 授權 — LFM Open License v1.0，年營收低於 1,000 萬美元可免費商用，超過該門檻則需付費商業授權。

• 佔用空間 — 以 Ollama 版本計為 2.1 GB。

其中兩列值得停下來想一想。上下文數字正是摘要之後會錯上好幾個月的那個，因為系列文章一開頭寫的是 256K，而音訊卡卻悄悄寫著 32K。至於語言數量，其實是地區設定數量換了個說法：十九個條目、十八種語言，由英文的兩個變體補上差額。這兩者都不是醜聞，但都會改變你對使用者承諾的內容。

一個指令，以及與卡片相矛盾的欄位

ollama run lfm3-audio 真的就是整個設定流程。頁面把這個模型標上 tools、audio 和 2b 標籤，而模型表格正上方的 readme 寫著它接受文字或音訊，並以文字、語音或兩者回應。模型表格卻與此不符：兩個標籤都把輸入列為「Text」，上下文則是一條破折號。

值得認真看待，而不是把它當成渲染怪癖而忽視。Ollama 自 2026 年 4 月的 v0.20 起便支援音訊輸入，當時 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 的差距則不然——UTMOS 0.6 分的變動遠超出那個範圍。站得住腳的解讀是，Liquid 把這一代的精力花在生成能力上：更好的語音、更好的音訊推理，以及一個在底層編碼器更換時仍守住表現的 ASR 前端。我們沒有找到任何一列結果的第三方重現，因此在有人發表重現結果之前，請把這個排序視為假設。

為什麼編解碼器比模型更長壽

LiquidCodec 是本次發布中，除了 checkpoint 之外值得關注的部分。它把 80 毫秒的語音壓縮成 12 個離散 token，可解碼回 24 kHz 並支援串流，而 Liquid 測得它在 M4 Max 的單一 CPU 執行緒上約達 87 倍即時速度。因果編碼器讓系統能在語音進行期間就進行預填充，而不是等到語音結束後才做，這正是「最低可達 50 毫秒」首個 token 延遲數據的由來。

那兩個數字是這次發布中最常被引用、卻最難以重現的內容。兩者都是在指名 Apple 硬體上由供應商提供的測量結果，沒有測試框架、沒有音訊集，也沒有百分位數。它們描述的是最佳情況。手機、Raspberry Pi 或共享的 x86 VM 都達不到這些數字，而發布說明中也沒說實際上會達到什麼。

執行階段支援對一個問世僅一天的模型而言異常廣泛：Transformers 5.20.2 或更新版本並搭配 trust_remote_code、BF16 checkpoint 使用 vLLM 與 SGLang、GGUF 使用 llama.cpp、Apple silicon 上使用 MLX 4-bit、可攜性則用 ONNX Runtime，並可在單一 GPU 上進行微調。必須特別鎖定的正是自訂程式碼需求。LFM3-Audio 會從自身模組載入，並從獨立的 audio_tokenizer 目錄讀取 codec 權重，因此未鎖定版本的環境無異於一張隨時會上門的支援工單。

本機語音與託管端點對比

一個 2B 音訊模型只要 2.1 GB，之所以值得注意，是因為另一種方案會按每一秒音訊向你收費。自架主機是固定成本——用你已經擁有的機器、一次下載，沒有按分鐘計費。託管端點則是每 token 的邊際成本，而且完全沒有維運負擔。

請精確說明每一方各自涵蓋的範圍。託管式文字轉語音——也就是我們所路由的那類，例如 gpt-4o-mini-tts，每百萬個 token 輸入 $0.60、輸出 $12.00，或 gemini-2.5-flash-preview-tts 的 $0.50 與 $10.00——只把文字轉成語音，別無其他功能。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 pull request 中，但 Omni 在音訊之上加入了視覺功能，是兩者中投入較大的。如果工作內容是一通電話、會議錄音或語音指令，Audio 是負責較小工作的較小模型。如果工作涉及一邊聆聽一邊觀看某物，那就是 omni 分支。

它可以轉錄直播嗎？

目前還無法透過 llama.cpp 使用。該合併請求將即時 ASR 列為後續工作，而模型卡明確指出，即使即時 ASR 日後推出，也僅支援英文。目前支援的做法是對錄音進行批次轉錄，上下文長度為 32K 個 token——這大約是規劃長檔案時需要考慮的長度上限，因為音訊 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 語音模型，說話能力比它所取代的模型更好，聆聽能力大致相當，而且尚無獨立見證者。對筆電上的原型而言，這樣就夠了。對正式生產的轉錄流程而言，這還不夠——而這兩句話之間的落差，正是推出與評估之間的距離。