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 語音。一個試圖取代整套助理堆疊。另一個則試圖成為最極致的耳朵。 專才與通才可以共用同一把金鑰。單一端點 請求依規則路由，若某條路徑失敗會自動容錯移轉。

這樣的命名讓事情變得多餘地困難。「Tiny」在 Ming 系列中指的是它相對於 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 不同。

• 佔用空間 — BF16 下約 4.3 GB，相較之下 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 是兩者中唯一能觀察房間並加以談論的模型。

誰應該拿哪個？

如果你正在打造語音產品——轉錄、口語對話、聲音克隆、通話分析——且你不需要視覺功能，或願意搭配獨立的視覺模型，請選擇 Ming-3.0-audio-tiny。MIT 授權、現有的量化版本與兩點 ASR 優勢，使其成為風險較低的部署選擇；而其稀疏架構讓每個 token 的成本維持較低，儘管總參數量達 9.3B。

如果裝置有相機和麥克風，且限制條件是記憶體，就選擇 LFM3-Omni-2B。一個能看、能聽、能說的 4.3 GB 檢查點，與一個 21 GB 的音訊專門模型屬於不同類別的物件，再高的 ASR 準確率也無法彌補模型放不下的問題。要接受你買的是廣度，不是深度，而且附在它上面的每一項音訊數字都是廠商自行報告且未經重現。

兩份模型卡都沒告訴你的是：它們在同一個應用程式裡的表現如何。那項測試——同樣的音訊、同樣的裝置、同樣的延遲預算——兩家公司以外沒有任何一方做過。在測試完成之前，決策依據是範圍與授權條款，這些今天就能確定，而不是準確度，因為那還無法確定。