Ming-3.0-audio-flash 在其自家模型卡發布前六週就已推出

一個 1260 億參數的音訊語言模型自 2026 年 9 月 3 日起就能從 Hugging Face 下載，而它交出的成績是 22 次下載與 8 個讚。直到本週，附在該儲存庫上的唯一說明仍是一張過時的卡片，它自稱「Ming Audio V3」，並說該儲存庫「目前記錄的是 ASR 路徑」。Ming-3.0-audio-flash 是它現在使用的名稱。權重並不新。2026 年 10 月 13 日至 19 日期間到來的是，讓一個沒參與訓練的人也能使用某個檢查點所需的一切：一份終於宣稱支援 128K 上下文的設定、一次重新上傳，讓一個影片—語言—音訊模型在 Transformers 5 程式碼路徑上變成純音訊模型、一個含兩段參考音訊的語音包，以及該儲存庫有史以來第一份真正的模型卡。inclusionAI 完全沒有宣布這些。沒有第三方發表過該模型的任何一項數字，所以以下所有內容不是直接從提交歷史讀出，就是引用自廠商自己的評估圖像——這也是為什麼值得在一開始就說：模型是九月的，只有文件是這週的。 像這次發布這類版本背後、已有記錄的 AI 故障與代理程式事件，都收集在 OrcaRouter AI Incident Archive，其中每一條記錄都附有自己的來源、嚴重性、信心等級與爭議旗標。

改變了什麼，以及何時改變

提交記錄異常清晰易讀，而且它訴說了一段模型卡並未交代的故事。該儲存庫建立於 2026 年 9 月 3 日 11:49 UTC，裡面只有一個檔案，一個.gitattributes。九分鐘後，25 個 safetensors 分片、總計 257 GB，在一個標題為「Add files using upload-large-folder tool」的提交下進駐——這是訓練團隊推送檢查點的標準印記，而非產品團隊為發表會所做的鋪排。隨附的 README 宣告 Apache 2.0，為該儲存庫標上automatic-speech-recognition標籤，並告訴你要以trust_remote_code=False來實例化模型。

接著，這個儲存庫沉寂了六週。當它再次有動靜時，它在七天內動了四次。

• 10月13日 12:17 UTC —「上傳 config.json。」一個檔案，而且是有趣的那一個：max_position_embeddings 從 8,192 變成 131,072。儲存庫中其他東西都沒變，所以有兩天，這個 repo 對外宣稱支援 128K 上下文，卻沒有任何建模程式碼能使用它。

• 10 月 15 日 09:35 與 09:40 UTC —「移除已棄用的檔案」之後接著「上傳更新後的模型」。權重佈局沒有改變，但有 46 個檔案被重寫，第一個分片從 10.64 GB 降到 9.77 GB。設定中的音訊 model_type 從 bailing_moe_v3_vl_audio 改為 bailing_moe_v3_audio，一個殘留的 video_patch_token 被刪除，宣告的 transformers_version 從 4.56.2 跳到 5.14.1，而 auto_map 新增了 AutoModel 與 AutoProcessor 項目，這些項目先前並不存在。在同一次推送中，README 與 examples/ 資料夾消失了——接下來四天，該儲存庫完全沒有模型卡。

• 10 月 17 日 11:44 UTC —「新增語音預設。」一個 voice_presets/ 資料夾出現，內含 US_James.wav、灵楷.wav，以及一個 voice_prompts.json，其中保存了它們的逐字稿。

• 10 月 19 日 11:35 UTC 起——「新增模型卡」，接著是資源，然後是十幾個微調導覽與連結對齊的小型提交，最後在 13:20 UTC 以「新增 Tiny 模型連結」結束。這就是重新命名模型、將授權中繼資料改為 MIT，並新增那張 8,259 位元組、描述完整音訊語言模型而非 ASR 路徑的模型卡的提交。它所取代的 README 已於四天前被刪除；再前一版是九月的版本，標題為「Ming Audio V3」，並宣告採用 Apache 2.0。

還有第二個值得了解的儲存庫。Ming-3.0-audio-tiny與 flash 模型在同一時刻建立，時間是 9 月 3 日 11:45 UTC，並在 10 月 19 日獲得相同的處理。它是較小的兄弟：總參數量 9.3B，其中 2.7B 為活躍參數，MIT 授權，四個分片合計約 21 GB，下載次數為三次。

你實際上可以下載什麼

設定已發布，因此架構並不是什麼謎團。本週的變化在於，設定與程式碼終於一致。自訂建模檔案自首次上傳以來就一直存在於儲存庫中——modeling_bailing_moe_v3_audio.py 與 processing_bailing_moe_v3_audio.py 早在 9 月 3 日就都存在——但它們原本要載入的設定描述的是一個具有 8K 視窗的影片—語言—音訊模型，而模型卡還告訴你要用 trust_remote_code=False 來實例化它，這與自訂程式碼所需正好相反。10 月 15 日重新上傳的版本則是：audio_config.model_type 讀取為 bailing_moe_v3_audio、影片 patch token 已移除、宣告的執行階段為 transformers_version 5.14.1，且 auto_map 除了原本一直都在的兩個項目外，還註冊了 AutoModel 與 AutoProcessor。

• 大小 — 語言模型為 25 個 bfloat16 safetensors 分片，總計 256 GB，另有一對 3 GB 的 Talker 與 VAE，位於 talker/ 之下。微型模型約 21 GB，分為四個分片。

• 主幹 — 42 層、隱藏大小 2,560、512 個專家且每個 token 有 8 個啟用、詞彙量 157,184。根據模型卡，總計 126B，每次推論步驟有 6.5B 啟用。

• 音訊塔 — 採用 Whisper 風格的編碼器，具備 32 層、寬度 1,280、20 個注意力頭、128 個梅爾頻帶，以及 3,000 幀的音訊上下文。音訊 token id 為 157,168。

• 上下文 — 131,072 個位置。在 9 月 3 日的設定中它是 8,192，而首次將其提高的 10 月 13 日設定仍自稱為 bailing_moe_v3_vl_audio，且仍帶有影片 patch token；乾淨的純音訊版本則是 10 月 15 日的那個版本。

• 輸出 — 文字，或透過選用的 Talker 輸出文字加上合成語音。此卡指定了一個預設 IP 音色「灵小柔」，以及兩個預設參考音色「灵楷」與 US_James，其音訊與轉錄稿皆收錄於儲存庫中。

• 授權條款 — MIT。在 10 月 19 日之前為 Apache 2.0。請注意，儲存庫本身並未包含 LICENSE 檔案：MIT 聲明存在於卡片的中繼資料中，以及指向 GitHub 路徑的連結中，而儲存庫中實際存在的唯一授權條款文字，屬於隨附的語言識別模型，該模型位於 talker/data/。

快速入門目前尚未解決

這是打算評估該模型的讀者首先需要了解的內容，而它並不在模型卡中。模型卡的安裝區塊會複製 github.com/inclusionAI/Ming-3.0-audio-flash。該 URL 目前無論是從網頁還是 API 存取，都會回傳 HTTP 404。模型卡在其之上建立的每個路徑也同樣如此：examples/transformers_audio.py、examples/transformers_thinker_talker.py、docs/voices.md、scripts/serve_vllm_omni.sh、scripts/serve_sglang.sh，以及 requirements-transformers.txt。

那些在 Hugging Face 儲存庫中也都不存在。它沒有 examples/ 目錄——較早的一個已於 9 月 17 日刪除——也沒有 scripts/，沒有 docs/，而且在 talker/ 之外沒有 requirements 檔案。它確實具備的是直接以 Transformers 載入模型所需的一切，模型卡也以 Python 片段記載了這一點：AutoProcessor 搭配 use_fast=False、AutoModelForCausalLM 採用 bfloat16 並搭配 device_map="auto"、trust_remote_code=True，以及音訊透過 processor(messages) 傳入，並將 audio_feats 轉型為模型的 dtype。

所以誠實的狀況是：模型可以載入，服務腳本目前並不存在，讀者無從閱讀，而模型卡描述的是一個尚未發布的儲存庫。這並不是醜聞——文件比程式碼推送早幾小時上線很常見——但這確實意味著下方兩份部署配方無法被稽核，只能被引用。任何評估此檢查點的人都應規劃走 Transformers 路徑，並應先閱讀 modeling_bailing_moe_v3_audio.py，再啟用遠端程式碼，而模型卡本身也如此建議。

可以檢查的是斷詞契約，而這張卡對它的規定異常具體：經驗證的 ASR 提示詞要求模型說出所講的語言，並在語言標籤與轉錄文字之間放一個定位字元。如果你正在撰寫評估測試框架，那個定位字元就是解析器。一般的「轉錄這個」提示詞並不是廠商所量測的配置。

inclusionAI 所發布的表格，包括它遺失的欄位

三張 PNG 圖像位於 assets/，承載了本次評估。圖上的每個數字都是 inclusionAI 自己的執行結果；星號標示的是供應商標為自我評估的項目，且其中沒有任何一項由第三方重現。Artificial Analysis 有發布音訊排行榜，但沒有這款模型的條目。沒有競技場分數、沒有獨立 Elo，也沒有第二方意見——因此請把以下內容讀作供應商在描述自家模型，而這正是它的本質。

語音辨識這張圖是整份論證最有力的部分，而它最強的地方，正是這款模型顯然專為其打造的面向。以其中文測試集平均而言，Flash 模型回報 3.45，相較之下 Qwen3.8-Omni Flash 為 3.54、Gemini 3.8 Flash 為 9.83；在英文上則為 3.69，對比 4.02 與 5.05。在方言上，差距急遽擴大：

• 方言平均 — Ming-3.0-audio-flash 9.40、Seed2.0 Lite 13.01、Qwen3.8-Omni Flash 11.58、Gemini 3.8 Flash 48.41。

• 閩南語 — 12.84，對比同一組三者的 49.95、28.08 與 81.62。

• 上海話 — 11.15，對比 26.32、21.10 和 88.64。

• 粵語 — 4.09 對 6.64、4.76 和 42.62。這一項與 Qwen3.8-Omni Flash 接近打成平手，並大勝 Gemini 3.8 Flash。

• 湖北 — 9.46 對比 11.35、7.75 與 48.24。Qwen3.8-Omni Flash 在這一列中勝出，而廠商還是把它印了出來。

• 湖南 — 8.76，相較於 20.30、17.11 與 71.39。

同一張圖在任務不再只是轉寫時就沒那麼好看。在說話者分段（diarization）上，AISHELL-4 回報 flash 模型的 diarization error rate 為 8.58，而 Qwen3.8-Omni Flash 為 2.80；AliMeeting 為 8.66 對 3.40；AMI 為 25.29 對 MiMo-V2.6 Pro 的 11.16。如果你的問題是「誰在何時說話」而不是「說了什麼」，這就不是廠商自家表格所推薦的模型。AMI 上的長篇串接最小排列字元錯誤率也說明同一件事：flash 模型為 39.62，MiMo-V2.6 Pro 為 30.91，Qwen3.8-Omni Flash 為 23.19。

音訊智慧這張圖，正是整體論證開始顯得單薄的地方。模型在掛頭牌的幾列上勝出——BigBenchAudio 99.40、MMAU 82.00——但接下來，幾乎在所有需要跨長段錄音推理、而非描述短段錄音的任務上，都節節失守。

• LongAudioSpan — 41.12，相較於 Seed2.0 Lite 的 50.26 與 Qwen3.8-Omni Flash 的 66.40。

• Long-audio Chain 分數 — 12.31，相較之下，Qwen3.8-Omni Flash 為 34.54、其思考模式為 48.70，而 Gemini 3.8 Flash 為 49.63。在廠商選擇公布的這項指標上，這是四倍的差距。

• MMAR — 74.40，相較於 Seed2.0 Lite 的 77.70。MMSU — 78.82，相較於 82.10。AudioMarathon — 68.41，相較於 70.06。

• 工具呼叫 — BFCL-v3 Audio 為 81.40，相比之下 Seed2.0 Lite 為 75.08，Gemini 3.8 Flash 則為 86.68。

文字基準測試是最不令人意外、也最實用的，因為它們說明了這個模型不是什麼。在一般推理上，Flash 模型在幾乎每一列都低於與之比較的 Omni 模型：GPQA Diamond 82.45，對上 Qwen3.8-Omni Flash 的 91.00；MMLU-Pro 80.00，對上 87.70；IFBench 59.00，對上 81.50；LiveCodeBench v6 79.90，對上 92.60；AA-LCR 73.90，對上 80.00。其骨幹是一個 6.5B 活躍參數的音訊專家，卻披著 126B 參數量的外衣，而文字表格就是它從外部看起來的樣子。如果你想要一個既能聽懂會議、又能寫後續程式碼的模型，inclusionAI 自己的數字說明，你不該指望這個模型扛下後半段。

運行所需的成本

文中引用了兩份服務設定檔，但兩者目前都尚無法稽核。針對 128K 上下文的參考 vLLM-Omni 設定檔，使用橫跨八張 80 GB H800 GPU 的張量平行化。已驗證的 SGLang 設定檔則使用四張 GPU，且僅回傳文字。那些是供應商的配置，而非實測數據；而且在尚未計入任何 KV 快取之前，權重就已達 256 GB，因此這件事沒有更小規模的版本——儲存庫在九月發布的 8K 設定也不會改變記憶體下限，因為下限就是檢查點本身。

實際解讀是：這是叢集模型，不是工作站模型。四張 GPU 大致就是一台正經 GPU 節點的成本；八張 80 GB 則是完全另一條預算線。Ming-3.0-audio-tiny正是給那些想在不作出這種承諾的前提下試用這個系列的人準備的答案——21 GB 與 2.7B 活躍參數可以塞進單張大卡——但這個小模型是另一個檢查點，在同樣的表格上有著自己一貫更差的數字（長音訊 Chain 分數 10.56 對 12.31，LongAudioSpan 35.45 對 41.12，URO-Bench-Pro 54.15 對 81.92，VoiceBench 74.29 對 86.74），而且廠商並未發布任何資料證明其行為可以轉移。

值得提醒任何規劃整合的人：Talker 是選用且可分離的。模型卡將其描述為從模型輸出產生語音，而預設集位於各自的資料夾中，並有自己的需求檔案，因此純文字部署不必攜帶它。兩個有文件記載的服務設定檔預設都會回傳文字。

路由器在哪些地方值得佔有一席之地，又在哪些地方不值得

OrcaRouter 並不提供 Ming-3.0-audio-flash。它不在我們的型錄中，我們無法為它提供端點，本文任何內容都不應被解讀為要約。在以這類模型為核心打造的流程中，路由器真正有用的是模型以外的那一半。語音系統大多屬於文字工作：決定要向音訊詢問什麼的提示詞、把以 Tab 分隔的語言標籤轉成結構化輸出的後處理、根據轉錄稿撰寫的摘要，以及在 GPU 節點飽和時執行的備援。這些都是普通的文字呼叫，而一個 API 就能以 0% 加價提供超過 200 個模型——供應商定價原樣傳遞，因此廠商降價當天我們這邊就會生效——接線起來比四份供應商合約更簡單。自動容錯移轉能讓你將未經證實的新模型放在部分流量之後，而不必把整條路徑都押在它身上。

這條界線值得直說，因為這正是本文不以註冊表單作結的全部原因：你在自己的八張 GPU 上執行的 259 GB 檢查點是基礎設施，不是 API 呼叫。路由器負責轉送呼叫。它不會把叢集模型變成託管模型，也不會把 22 次下載變成生產環境證據。

看什麼

有三件事會改變整體情況，而且每一件都能以基準測試無法做到的方式加以查核。首先，GitHub 儲存庫：當 inclusionAI/Ming-3.0-audio-flash 不再回傳 404 時，服務腳本與語音指南就會成真，上述兩套部署配方也將可供稽核。其次，獨立評分：一旦 Artificial Analysis 或某個競技場列出這個檢查點，四倍的長音訊差距就不再是廠商的自述，而會開始成為一個資料點。第三，授權檔案：中繼資料中宣告的是 MIT，而 LICENSE 檔案在儲存庫中會讓它成為事實而非聲明——對於採購流程是閱讀儲存庫而非模型卡的人來說，這項區別很重要。

在那之前，準確的描述仍是那個毫不光鮮的版本。一個正經的音訊語言檢查點模型，在帶口音與方言的中文語音上表現最強，依其自行公布的數字，在長音訊推理與說話者分離上偏弱，紙面上採 MIT 授權，磁碟上約 259 GB，而且直到本週才有文件。六週的沉默不能證明任何事，只能證明 inclusionAI 先發布權重、後發布文件——但文件才是告訴你正在下載什麼的部分，而現在它終於可供閱讀了。