一張生成的標題卡,寫著「LFM3-Omni-2B vs Ming-3.0-audio-flash」,副標題為「手機對機架」,圖中顯示一張標示 2.17B 參數和裝置端的手機卡片,旁邊是一張標示 126B 參數和 4x H800 的伺服器機架卡片。
Guides & Insights

LFM3-Omni-2B 對決 Ming-3.0-audio-flash:一支手機對上一座機架

作者

Elias Hawthorne

發佈日期

最新模型 · 20查看全部模型 →
基準測試:Artificial Analysis · 每日更新
返回全部文章

物料清單在基準測試還沒開口之前,就已經決定了這場比較。Ming-3.0-audio-flash有 1,260 億個參數,約 259 GB 的 bfloat16 權重,以及一套參考服務配置,建構在採 tensor parallel 的 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 之前,設定並未宣稱。

Screenshot of the inclusionAI/Ming-3.0-audio-flash model card showing 126B total parameters with 6.5B activated per inference step, audio and text inputs, text-to-speech and Safetensors tags, an MIT licence badge and 764 downloads last month.

LFM3-Omni-2B 會將所有內容符元化成單一流。影片以每秒 2 幀取樣,每個 2×2 影像區塊會變成一個語言符元,音訊則會經過 LFM3 因果音訊編碼器,進入與文字相同的 128,000 個符元詞彙表。語音輸出為 24 kHz 的 LiquidCodec;音訊輸入為 16 kHz 單聲道。整個模型位於 32K 視窗內。

Screenshot of the LiquidAI/LFM3-Omni-2B model card on Hugging Face showing 83 downloads last month, a 2B-parameter BF16 safetensors badge, 23 languages, the LFM1.0 licence, and the card text stating the model understands text, images, video and audio and answers in text and speech.

那是一套壓縮論證,而且有利也有弊。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,對比約 259 GB 的 bfloat16 分片,再加上 Talker。

• 參考硬體——手機、筆記型電腦或邊緣運算板,相較於用於 128K 配置、以張量平行方式運作的四張 80 GB H800;長音訊發生記憶體不足時則為八張。

• 上下文 — 涵蓋輸入與輸出的 32K token,相對於宣稱的 128K。

• 語音輸出 — 採用 24 kHz LiquidCodec,支援 19 種語音地區設定;Ming 會透過 Talker 回傳文字,或文字加上語音,並具備內建語音與參考片段複製功能。

• 授權條款 — LFM Open License v1.0,一種設有營收門檻的授權條款,對比 MIT。

• 價格 — 雙方都沒有按 token 計價,因為兩家廠商都沒有針對這些檢查點販售推論服務。

A comparison scoreboard for LFM3-Omni-2B and Ming-3.0-audio-flash listing 2.17B dense versus 126B MoE, 2.17B versus 6.5B active parameters, 32K versus 128K context, a few gigabytes versus about 259 GB of weights, phone or edge versus 80 GB H800s, and LFM Open v1.0 versus MIT.

使用中的參數不是時速表。

把「6.5B active」與「2.17B dense」並列來看,很容易就此得出「Ming 每個 token 的成本僅為三倍」的結論。這種解讀在兩個方向上都是錯的。

混合專家會消耗記憶體頻寬,而不只是算術運算。從 126B 中提供 6.5B 活躍參數,意味著每一層都要把專家權重移入快取,而且在批次大小為一——語音助理所處的情境——這幾乎等同於每個 token 都要讀取 259 GB 的一大部分。八卡 H800 的配置並不是峰值吞吐量的建議;而是容納權重所需的代價。LFM3-Omni-2B 在 2.17B 時有相反的問題:沒有稀疏性紅利,但也沒有東西需要置換,而這正是讓手機可行的配置。

實務上的結果是,這兩個模型的擴展曲線不同。Ming 會隨著批次處理而降低每個 token 的成本,適合用來消化大量錄音通話佇列的轉錄流程。LFM3-Omni-2B 則是每段話語的成本大致維持不變,適合批次大小為一、延遲預算只有幾百毫秒的即時對話。

這1,260億能買到什麼

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 的 serving 情況仍未底定。inclusionAI 的發布說法暗示,如今就能用 vLLM-Omni 服務這個模型家族;但實際上,儲存庫顯示的是尚未合併的 pull request——一個涵蓋 tts-tiny checkpoint,另一個加入 audio-flash 支援。在這些 PR 落地之前,要執行 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 上下文讓它是這對之中唯一能一次處理完整場會議的模型。

如果音訊是在邊緣端生成、使用者正在等待,而且答案需要立刻以語音回覆,就選 LFM3-Omni-2B。你要接受的是:換來一個能放進 App 裡的部署,代價是較小模型的準確度、較窄的語言清單,以及附有營收條款的授權。

在進行任何一項之前,先問:音訊會傳到哪裡?如果答案是「無處可去」,比較就結束了。