Ming-3.0-asr-tiny 對比 Moonshine 250M：一個模型從不停止聆聽，另一個則要等你說完才開始

有一個命名問題必須先釐清，因為它會改變這場比較的性質。Moonshine 發佈三個檢查點——Tiny 34M、Small 123M 與 Medium 245M——而 Moonshine 250M 是社群對這條產品線頂端型號的簡稱，該檢查點的儲存庫名稱是 moonshine-streaming-medium，而其 safetensors 索引實際上總計 265,898,112 個參數。Moonshine 組織裡沒有任何檔案名叫 250M。那個模型是英語串流語音辨識器，配備滑動視窗編碼器與自迴歸解碼器，為筆電或手機打造，於 2026 年 1 月以 MIT 授權釋出。 Ming-3.0-asr-tiny 是一個 88.7 億參數的中英雙語辨識器 ，其權重於 2026 年 10 月 14 日未經公告出現在 Hugging Face 上，圍繞 Whisper 形狀的編碼器與 128 專家混合專家解碼器構建，設計成一次讀取整段音訊。它們不是同一市場中的競爭對手。它們是對「辨識器何時可以開口」這個問題的兩種不同答案。 本文稱為 Moonshine 250M 的檢查點記錄於 Moonshine Streaming Medium 模型卡，其中 safetensors 索引回報 265,898,112 個參數，而模型卡標示為 245M。 像這次這樣的釋出背後，有紀錄的 AI 故障與代理事件收集於 OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。

那個問題才是有用的框架，而且它產出的決策比一張準確率表格更乾淨俐落。Moonshine 250M 在音訊還在傳入時就逐字輸出，算力約 0.1 到 1 TOPS。Ming-3.0-asr-tiny 則要等你给它一個完整檔案才會輸出任何東西，而屆時它產出的轉錄完全沒有時間戳。

每一個實際上是為了做什麼而打造的

Moonshine 的架構是對常見串流折衷的一種刻意反轉。編碼器是具備有界局部注意力、且完全沒有位置嵌入的滑動視窗 Transformer——模型卡稱之為 ergodic——前兩層與最後兩層的視窗設定為 (16, 4)，中間層則為 (16, 0)，帶來約 80 毫秒的前瞻。位置資訊由編碼器之後的適配器注入，送入帶有 RoPE 的標準因果解碼器。音訊前端以 50 Hz 運作，使用簡單的時域運算，而非梅爾頻譜圖。

解碼器是自迴歸的，而 Moonshine 說明了這帶來的代價：即使首個 token 的時間很短，完整輸出延遲仍會隨轉錄長度增加。這是此設計誠實的限制，也是在比較串流宣稱時應牢記的一句話。串流意味著最初的詞語很快出現；並不表示最後一個詞會按比例地快速出現。

Ming 不支援串流，它的卡片也明白寫著：內附的範例不接受串流輸入。長音訊可以透過引數分塊，以配合 8,192 個位置的上下文，但把檔案分塊並不等同於接收即時串流，而設定中的輸出格式欄位被設為plain。Ming 改而做的是攜帶上下文。它接受熱詞或前一段對話回合，作為轉錄提示的一部分，並且在十五個中文方言測試集上接受評估——湖南、閩南、粵語、川渝、上海、安徽、東北、河南、湖北、江蘇、客家、陝西、山東、天津、雲南。Moonshine 僅支援英文，完全沒有這些。

這兩個參數數量，以及它們為何不同

值得深究的細節，因為這正是那種會悄悄破壞比較表的東西：Moonshine 自己的模型卡將 Medium 列為 245M 參數、14 個編碼器層與 14 個解碼器層、768 維編碼器與 640 維解碼器。同一儲存庫中的 safetensors 索引回報 265,898,112。差距約 2,100 萬，約百分之八點五，而且這不是捨入誤差——這是只計入主幹與計入隨附出貨所有內容之間的差別。

Ming 在更大規模下也有同樣的問題。其索引報告 8,865,800,992 個參數；其圖表將該模型標為 8.6B-A2B，這是總計 86 億、每個 token 約有 20 億啟用參數的簡寫。該標籤比索引少了約 2.7 億。

• 總參數量 — Ming-3.0-asr-tiny 8.87B（索引）對比 Moonshine 250M 266M（索引）；廠商標示為 8.6B 與 245M。

• 每個 token 的啟用參數——Ming 約為 2B，因為每一步會從 128 個專家模型中路由 8 個。Moonshine 則是全部 266M，屬於稠密模型。

• 編碼器 — 32 層、1,280 維、20 個注意力頭、128 個梅爾頻帶，Whisper 架構，對比 14 層遍歷式滑動視窗 Transformer、768 維、50 Hz 前端。

• 解碼器 — 24 層、128 個專家、自迴歸；相較之下，14 層、稠密、自迴歸。

• 延遲模型 — 整段音訊輸入，轉錄結果輸出，不支援串流；相較之下，約有 80 毫秒的前瞻，且在音訊仍在傳入時就能產生第一個 token。

• 輸出 — 純轉錄文字，沒有時間戳記，也沒有說話者分離；相較於來自自迴歸解碼器的轉錄文字，而該解碼器在卡片中也沒有時間戳記路徑。

• 語言 — 中文與英文，外加 15 組中文方言測試集；相較之下僅有英文。

• 授權 — 兩者皆採用 MIT，並在 Ming 的儲存庫中保留隨附的 Apache-2.0 標頭。

準確度，但附帶條件是它們從未在同一段音訊上接受測試

Moonshine 的模型卡指出，Medium 在八個英語資料集上的平均 WER 為 6.65：AMI 上為 10.68，Earnings-22 上為 11.90，GigaSpeech 上為 9.46，LibriSpeech test-clean 上為 2.08，test-other 上為 5.00，SPGISpeech 上為 2.58，TED-LIUM 上為 2.99，VoxPopuli 上為 8.54。其訓練資料約為 300,000 小時的語音。

Ming 在其英文公開集上報告平均 WER 為 3.99——LibriSpeech clean 與 other、Multilingual LibriSpeech、FLEURS English、Common Voice 15 English 與 VoxPopuli——而其中文集上的平均 CER 為 3.55。以未公開數量的資料訓練。

人們會忍不住把 3.99 和 6.65 並列，然後宣稱 Ming 在英文上更準確。別這麼做。五個英文資料集中有兩個不同，彙總方式也不同，Moonshine 的模型卡並未公布能明確對應到 Ming 那五個資料集的逐集細分，而且兩家廠商都沒有對彼此跑過評測。在雙方都有報告的那一個資料集——VoxPopuli——Ming 在其內文中根本沒有公布逐集的英文數字，只有平均值，因此即使只有這一個重疊項，也無法從模型卡進行比較。這裡的每個數字都是廠商自行報告，且未經重現。

在沒有共用測試集的情況下，能說的只是結構性的判斷。Moonshine 是一個 2.66 億參數的稠密模型，以 30 萬小時的英語訓練而成。Ming 是一個 88.7 億參數的混合專家模型，約有 20 億活躍參數，訓練資料並未由其說明，並在中英雙語上評估，且方言成分很重。擁有十七倍活躍參數且具語言模型先驗的模型，在困難的英語音訊上應該更準確；若非如此反而令人意外。這是來自架構的預期，而非測量結果。

部署現實出現分歧之處

Ming 需要一台配備 CUDA GPU 的 Linux 機器，並具備 Python 3.12、PyTorch 2.11.0、torchaudio 2.11.0、Transformers 5.12.1、fla-core 0.5.2，以及 trust_remote_code=True 來載入它自己的建模程式碼。權重以 BF16 格式計約 17.7 GB，分成兩個分片。有一條 SGLang 服務路徑，固定於特定的 adapter commit，這顯示廠商預期它要透過 API 執行，而不是在桌機上運行。

Moonshine 250M 的目標是低於 1 GB 的記憶體用量，以及大約 0.1 到 1 TOPS 的算力。它可透過專為邊緣裝置設計的 Moonshine Voice 框架執行，也可透過 Transformers 執行；而說明卡上明確指出，Transformers 這條路徑尚未實作完全高效的串流處理——它依賴 flash-attention 的滑動視窗支援。如果你想要這套架構所承諾的串流行為，那麼能真正提供這種行為的是框架這條路徑。

儲存庫正是 checkpoint 系列真正看得見的地方：橫跨 Tiny、Small 與 Medium 家族的二十四個標籤，外加卡片上告訴你、若想要真正串流就該使用的框架。這是 Ming 尚未具備的維護故事，也是這個選擇的實務面。

整段比較用兩句話就能說完：一個模型打從設計上就是要待在裝置裡、讓人忘了它的存在，另一個則是要從 GPU 上提供服務，還附帶一份熱詞清單。

中文優先團隊實際上應該做什麼

如果你的產品是英文即時字幕或語音指令，Moonshine 250M 能勝任 Ming 完全做不到的工作，而無論準確率差距最後是多少，都不太可能比 Ming 無法處理即時串流這件事更重要。串流不是日後才加到一個讀取整段片段的架構上的功能；它是編碼器本身的特性。

如果你的產品是中文語音、某種地區方言，或是事後才產出轉錄稿、而人名正確性至關重要的批次處理流程，那麼這兩者之中只有 Ming 真正解決了這個問題——而它才問世五天，下載次數還在兩位數。誠實的建議是：用你自己的音訊做一場對比測試，以命名實體召回率而非字元錯誤率來評分，因為那正是 Ming 被打造時所針對的軸線。

對於進行該對比評測的團隊而言，營運上的問題不在模型，而在管線串接：兩套技術堆疊、兩組相依性、兩組憑證，而且若不建置測試框架，就無法用相同流量比較兩者。OrcaRouter 並不託管這兩個模型——Ming-3.0-asr-tiny 與 Moonshine 250M 是自架的開放權重——但它確實將 200 多個託管模型置於同一組 API 金鑰之後，並具備自動容錯移轉，因此你用來評分的託管基準，無須第二份合約就能與你的自架候選方案並列。供應商定價以 0% 加成原樣傳遞，這正是當你比較每小時音訊成本而非每 token 成本時，真正重要的數字。

值得關注的未解問題

Ming 的模型卡表示，熱詞只是提示，不是保證，而且輸出是文字，沒有字詞級時間戳或說話者分離。Moonshine 的模型卡則指出，其解碼器在短音訊或嘈雜片段上可能憑空生成詞語並重複詞句。兩者都誠實說明失效模式，這比大多數模型卡做得到的還多；而且兩者正從相反兩端描述同一個根本取捨：能產出流暢文字的自迴歸解碼器，有時會產出流暢但並非實際說出的文字。

真正能為這項比較定案的，不是基準測試，而是使用情境。用你自己音訊中的同樣二十分鐘，分別跑這兩個模型——一半即時、一半批次，一半英文、一半非英文——決策就完全不再取決於參數量。在那之前，對這場較量的正確描述是：其中一個模型是為了持續聆聽而打造，另一個則是為了仔細閱讀而打造；而較小那個模型的名字，只是行銷上對某個檢查點的簡稱，那個檢查點實際上擁有 2.66 億個參數。