Ming-3.0-audio-flash 對決 InternLumina U2：兩艘靜默之船，截然相反的文件作業

這兩個模型都是在沒有新聞稿的情況下發布的，而相似之處大致也僅止於此。 Ming-3.0-audio-flash 於 2026 年 9 月 3 日以 259 GB 的權重登上 Hugging Face，幾乎沒有任何說明文件，直到 10 月 19 日才獲得一份真正的模型卡。 InternLumina-U2 則相反：Shanghai AI Laboratory 於 2026 年 9 月 1 日發布了推論程式碼與專案頁面，承諾會提供權重，之後才以依硬體區分的資料夾形式釋出。其中一組團隊先推出成品，六週後才提供說明。另一組則先寫好說明，讓你等到成品。兩者都未發布任何公告，也都沒有獨立基準測試，且彼此不能替代——一個能聽，另一個能看與畫。 像這類比較背後有紀錄的 AI 失敗案例與低調發布事件，都收錄在 OrcaRouter AI Incident Archive 中，每一筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。

這使得這件事同時是在比較兩件事：對開放多模態模型的用途所下的兩種不同賭注，以及發布這類模型的兩種不同習慣。後半部分比聽起來更有用，因為真正能告訴你能否在週二就把這東西部署上線的，是那些文件資料。以下所有內容都來自這兩個儲存庫及其模型卡。Ming 的數字是 inclusionAI 自己的；InternLumina 的數字是 Shanghai AI Lab 的，而且它自己的模型卡把它們標為「初步、部分結果」。尚未有第三方對兩者進行評分。

兩個發佈時程，並排對照

日期是這裡可取得的最客觀證據，因此就從它們開始。

• 2026 年 9 月 1 日 04:03 UTC — GitHub 儲存庫 InternLM/InternLumina-U2 建立完成。十三分鐘後，一個同名的 Hugging Face 儲存庫隨之出現，裡面只有一份 .gitattributes 和一份 README 佔位檔。當天發布的是程式碼：一支驅動腳本，每個任務各有一個區段，一份中英文 README，以及一份路線圖。

• 2026 年 9 月 3 日 11:45 與 11:49 UTC — inclusionAI 建立了 Ming-3.0-audio-tiny 與 Ming-3.0-audio-flash 於 Hugging Face。九分鐘後，25 個分片進入 flash 儲存庫。隨附的 README 標題為「Ming Audio V3」，且僅描述了 ASR 路徑。

• 2026年10月13日至19日 — Ming 系列儲存庫在七天內歷經四次變動：一項將上下文長度從 8,192 提升至 131,072 的設定、一次移除影片語言變體的重新上傳、一個語音預設集資料夾，最後則是模型卡、相關資產以及改以 MIT 授權。inclusionAI/Ming-3.0-audio-flash 於10月15日現身 GitHub。

• 2026 年 9 月 24 日之後某時 — internlm/InternLumina-U2 在 Hugging Face 上不再只是空殼，並新增兩棵檢查點樹，ascend/ 與 nvidia/，各有七個分片，總儲存空間約 67.6 GB，每個硬體樹約 33.8 GB。該儲存庫最後修改於 9 月 24 日。沒有卡片改寫、沒有含數字的基準測試表，也沒有技術報告。

這種模式反了過來，實際後果也同樣反了過來。Ming 的權重自九月初起，只要願意讀設定檔的人就能運行；它的文件卻不存在。InternLumina 的文件從第一天就存在；它的權重卻沒有，而當權重終於發布時，發布內容也沒有模型卡所承諾的比較表。

每個模型實際上是被打造來做什麼的

Ming-3.0-audio-flash 是原生音訊語言混合專家模型：總參數量 1,260 億，每次推論步驟啟用 65 億個參數；音訊編碼器與投影器饋入 42 層主幹，主幹具備 512 個專家、每個 token 啟用 8 個；詞彙表有 157,184 個 token；Whisper 風格音訊塔為 32 層、寬度 1,280，並有 128 個梅爾頻帶。輸入為音訊加上文字指令。輸出為文字，或透過可選的 Talker 模組輸出文字加合成語音；該模組內建中文語音，儲存庫中另有兩段參考音訊片段。宣告的上下文長度為 128K，而模型卡上的服務設定為八張 80 GB H800，以張量平行方式運行。

InternLumina-U2 是一個 160 億參數的稀疏混合專家模型，其中 10 億為活躍參數；它被建構為擴散語言模型，而非自迴歸模型——它會平行精煉整個序列，而不是由左至右逐一輸出詞元。其視覺表徵完全離散：來自 Apple AToken 分詞器的八個視覺詞元碼本，在輸入端會串接成每個位置一個主幹詞元，在輸出端則逐碼本進行預測。這項設計的重點在於統一：文字問答、圖像理解、圖像編輯、文字轉圖像生成、影片理解與 3D 理解全都透過相同的詞彙表與相同的權重，在 LLaDA-2.0 擴散主幹上運行。

把這兩段描述放在一起讀，比較就會凝練成一句話。Ming-3.0-audio-flash 是專才，體量極大，並深入處理單一模態。InternLumina-U2 是通才，以總參數量來說很小，並試圖把五件事都做得尚可。這兩種設計都不是對另一方的妥協；它們是對不同問題的回答。

把每一個都轉換成 token，這才是真正的差別。

如果你只看參數數量，就會得出「Ming 的規模是該模型的八倍」這個結論。這種解讀在兩個方向上都是錯的，而原因在於兩者各自對外暴露的介面。

• 輸入 — Ming-3.0-audio-flash：音訊與文字。InternLumina-U2：文字、圖像、影片幀與 3D 資產。

• 輸出 — Ming-3.0-audio-flash：文字，可選語音。InternLumina-U2：文字、圖像、編輯後的圖像；不支援音訊、不支援影片、不支援 3D 生成。

• 解碼 — Ming-3.0-audio-flash：在 157,184 個詞元的詞彙表上進行自迴歸。InternLumina-U2：在離散多碼簿視覺詞彙表上進行區塊擴散。

• 總參數量與啟用參數量 — Ming-3.0-audio-flash：總參數 126B，啟用參數 6.5B。InternLumina-U2：總參數 16B，啟用參數 1B。

• 磁碟上的權重 — Ming-3.0-audio-flash：約 259 GB，分佈於 25 個分片，外加一個 Talker 與 VAE。InternLumina-U2：儲存庫中為 67.6 GB，分成兩套硬體樹，各含七個分片、約 33.8 GB。

• 授權 — 兩者在精神上都與 MIT 相近，但實際上不同：Ming-3.0-audio-flash 依其卡片為 MIT，InternLumina-U2 依其儲存庫與卡片為 Apache-2.0。

• 獨立評估——兩者皆無。

硬體，而這正是兩者分歧最大之處

InternLumina-U2 最有趣的工程主張不是架構，而是後端故事。該儲存庫同時附帶 Ascend 目錄樹與 NVIDIA 目錄樹，實驗室表示訓練、評估與推論都已適配華為 NPU 和 NVIDIA GPU，並且兩者之間在運算子層級達成了數值對齊。對於採購流程會經過非 NVIDIA 加速器的人來說，這是真正的差異化優勢，而且可在檔案樹中查證：兩個完整的檢查點目錄，各自都有自己的設定、分詞器與平行化方案。

Ming-3.0-audio-flash 並沒有這回事。它的參考組態是八張 80 GB H800；其經驗證的替代方案是僅回傳文字的四 GPU SGLang 組態。儲存庫中沒有 NPU 路徑，而總參數 9.3B、啟用參數 2.7B 的迷你同系列模型，正是無法投入一整個節點的人的解方。

就當代意義而言，這兩個模型都屬於部署專案，而非 pip 安裝。InternLumina 自家資料明確指出，其生成路徑並非標準做法：block-diffusion 的 generate API 並不是 Transformers 的 generate 介面，AToken 分詞器需要 FlashAttention，而 3D 管線預期由 Blender 4.5 將 GLB 資產算繪成視圖後再進行分詞。Ming 的路徑較為常規——AutoProcessor 加上 AutoModelForCausalLM，並搭配 trust_remote_code=True——但記憶體下限高出八倍。

供應商數字能說明什麼，以及它們無法說明什麼

這兩張表無法互相比較，因為這兩個模型沒有任何一項共同的基準測試。這不是推託；這是證據如實的樣貌。

在 inclusionAI 的評測圖中，Ming-3.0-audio-flash 回報中文 ASR 平均錯誤率 3.45、英文平均 3.69、方言平均 9.40、MMAR 74.40 與 BigBenchAudio 99.40。同一批圖也顯示它的落後之處：AMI 語者分離錯誤率 25.29，對比 MiMo-V2.6 Pro 的 11.16；長音訊 Chain 分數 12.31，對比 Qwen3.8-Omni Flash 的 34.54。它的文字基準測試是這張評測卡最弱的部分——GPQA Diamond 82.45、MMLU-Pro 80.00、IFBench 59.00——這正是 6.5B 活躍參數的音訊專家模型被要求以自然語言文字進行推理時的樣子。

InternLumina-U2 的模型卡報告 ChartQA 86.52、CharXiv-DQ 83.65、MathVision 33.22、HallusionBench 62.15、VideoMME 51.26、MVBench 59.74、3D MM-Vet 41.8、DPG-Bench 87.10 以及 GenEval 0.81——但隨後又自相矛盾，因為專案頁面自己的表格顯示 LLaDA2.0-Uni 在 GenEval 為 0.89，優於那個聲稱要超越它的模型。模型卡最顯眼的但書「初步、部分結果。完整比較表將出現在即將發布的技術報告中」時至今日仍然成立。目前沒有技術報告。

兩組數字合起來看，呈現的是互補的優勢與一個共同的弱點：兩者都尚未被訓練它們的實驗室以外的任何人重現。

哪一個，給哪位讀者？

如果你的產品涉及語音——具方言涵蓋範圍的會議轉錄、客服中心音訊、口語回答、配音——Ming-3.0-audio-flash 是兩者中唯一適用的，而且坦白說，也是同類中唯一有公開且如此具體方言數據的開放權重模型。請以一個節點來規劃，或先從小型同系列模型開始，並接受它較弱的長音訊評分。

如果你的產品涉及影像——文件閱讀、圖表問答、編輯、3D 資產描述，或是一個既能讀又能畫的單一模型——那麼 InternLumina-U2 是唯一適用的選擇；如果你不打算採用 NVIDIA，Ascend 體系確實是值得考慮的理由。請預期要和 tokenizer 搏鬥。

如果你兩者都需要，就代表你正在執行兩個模型，而真正有趣的問題會變成營運層面的問題：兩個檢查點、兩套工具鏈、兩組授權條款，卻只有一個多模態產品。這正是 2026 年底開放權重工作的常態，也是路由機制存在的原因。

狹義而言的路由層

OrcaRouter 兩個 checkpoint 都不提供。Ming-3.0-audio-flash 和 InternLumina-U2 都是你自己執行的開放權重模型；兩者都不在我們的目錄中，也不會出現在對我們 API 的呼叫裡。我們提供的是周邊的文字工作：為影像編輯指令定調的提示詞、把 Ming 轉錄稿整理成結構化筆記的摘要器，以及判斷送進來的素材該交給這兩個模型當中哪一個的分類器。

最後那一塊特別值得點名。同時處理語音與視覺的管線，最後會面臨一個路由決策——音訊送往 Ming 節點，影像送往 InternLumina 節點——而這個決策就像任何其他模型呼叫一樣。讓它透過以 0% 加價提供超過 200 個模型的單一 API，供應商牌價會直接透傳，並讓調度器與其他一切共用同一把金鑰。自動容錯移轉在這裡也很重要，不是為了自架的檢查點，而是為了為它們提供輸入的分類步驟：如果路由器的模型降級，備援應該改用另一個模型，而不是一條中斷的管線。

這些都不會讓一個 259 GB 的檢查點變成託管服務，若暗示並非如此，會造成誤導。

接下來要看什麼

對 Ming-3.0-audio-flash 而言，缺少的部分是儲存庫中的授權檔案（MIT 目前位於模型卡中介資料中），以及音訊語言路徑的服務整合；vLLM-Omni 支援前一代 Ming，並且已有針對 7.9B T​TS 模型的開啟中拉取請求，但針對 126B 讀取器則尚未合併任何內容。對 InternLumina-U2 而言，缺少的是技術報告及其承諾的完整表格；在那之前，與 LLaDA2.0-Uni 對比的 GenEval 列是任何人唯一能查核的跨模型比較，而它對較新的模型並不有利。

這兩次發布的共同點，比任何一處落差都更有用。兩家實力堅強的實驗室發布了規模可觀的開放權重多模態模型，卻沒告訴任何人。這並不代表模型不好——這代表發布公告已變成可有可無，而儲存庫如今才是主要來源。去讀它。