Ming-3.0-audio-flash 與 MiniCPM-V 4.7：一個聽得見的模型，和一個能放進你口袋的模型

如果你要在Ming-3.0-audio-flash與MiniCPM-V 4.7 35B-A3B之間做選擇，無論你平常權衡的是哪個面向，答案都不接近，因為它們爭奪的不是同一個位置。一個是 1260 億參數的音訊語言混合專家模型——活躍參數 65 億——由 inclusionAI 於 2026 年 9 月 3 日上傳，並在六週後補上文件，其參考配置需要八張 80 GB GPU。另一個是 352 億參數的稀疏視覺語言模型，OpenBMB 於 2026 年 10 月 6 日晚上丟上 Hugging Face，完全沒有模型卡，10 月 12 日才發布模型卡，並宣稱能在 iPhone 17 Pro Max 上以約 3 GB 記憶體每秒解碼超過 13 個 token。一個負責聽，並待在機架裡。另一個負責看，且能放進手掌中。它們值得放在同一頁的原因，是兩者都在同樣的六週內由中國實驗室低調推出，都是開放權重，且都正被那些架構中恰好只有一個位置的團隊評估。這類比較背後的已記錄 AI 故障與部署事故，都收集在OrcaRouter AI Incident Archive，其中每一條紀錄都附有自己的來源、嚴重程度、信心等級與爭議標記。

決策規則先講在前，接著是支持它的證據。如果輸入是音訊——通話、會議、方言、音樂、你需要驗證的生成配音——只有其中一個模型能開始處理。如果輸入是圖像、文件、圖表、螢幕截圖或視訊影格，就只有另一個模型能開始處理。兩者的重疊之處是一條能同時處理兩者的管線；在那條管線裡，它們是兩個階段，而不是兩個候選。以下每個數字都是廠商回報的：inclusionAI 的數字來自其自家評測圖像，OpenBMB 的數字來自 10 月 12 日發布的一張卡片，而兩者都尚未被第三方重現。

各自拒絕做的事

要看出差異最快的方法，就是列出每個型號不接受的事項，因為規格表本來就是為了隱藏這一點而寫的。

• Ming-3.0-audio-flash 不會查看任何東西。它的輸入是音訊與文字指令；儲存庫中沒有影像編碼器，設定中沒有視覺塔，且自 10 月 15 日重新上傳移除影片語言變體及其 patch token 後，就沒有影片路徑。若某個影格很重要，這個模型對它也是視而不見。

• MiniCPM-V 4.7 35B-A3B 不會聽任何東西。它被標記為 image-text-to-text，其處理器可處理影像與視訊影格，而在 70.4 GB 的權重中，任何地方都沒有音訊塔、沒有 ASR 路徑，也沒有 TTS 頭。WAV 檔案不是它能夠表示的一種輸入。

• Ming-3.0-audio-flash 不會生成影像、編輯或 3D 資產。它在文字以外的選用輸出是語音，經由具備內建語音與參考語音的 Talker 模組產生。

• MiniCPM-V 4.7 35B-A3B 不會說話。它會讀取頁面並以文字回答。若要加入語音功能，就得另外外掛獨立的語音合成器，而這是不同的產品決策。

這就是整個比較的全貌。其餘的一切——上下文、稀疏性、授權條款、硬體——相較於兩者的模態集合並不相交這一點，都只是次要的。

兩種截然不同的稀疏方式

兩個模型都是混合專家（mixture-of-experts）架構，而這個詞掩蓋了截然相反的工程賭注。

Ming-3.0-audio-flash 之所以稀疏，是因為它極其龐大：42 層、隱藏維度 2,560、512 個專家且每個 token 選用 8 個、總參數 126B、啟用參數 6.5B，另外還有 Whisper 風格音訊編碼器，32 層、寬度 1,280、128 個梅爾頻段。稀疏性為這個原本無法訓練也無法服務的模型換來吞吐量，但換不來小體積。25 個 bfloat16 分片，加上一對 Talker 與 VAE，在磁碟上約占 259 GB，而廠商的 128K 服務設定檔是跨八張 80 GB H800 的張量平行。

MiniCPM-V 4.7 35B-A3B 之所以稀疏，原因正好相反：它儲存 352 億個參數，每個 token 會從 256 個專家中路由 8 個；文字層超過 40 層，採用三層線性注意力對一層全注意力的模式，並位於一個隱藏維度為 1,152、插入文字堆疊第 6 層的 27 層視覺塔之後。這項設計所主張的不是叢集上的吞吐量，而是手機上的可行性。OpenBMB 的 Lookahead Expert Scheduling 會預測下一層需要哪些專家、預取這些專家，並讓載入與運算重疊——這種技巧只有在瓶頸是手機的記憶體頻寬、而非資料中心的 FLOPs 時才會被發明出來。

• 總參數量 — Ming-3.0-audio-flash 126B；MiniCPM-V 4.7 35B-A3B 35.2B。

• 活躍參數 — 65 億，對比約 30 億（256 個專家中的 8 個，外加一個共享專家）。

• 上下文 — 131,072 個 token，對比 262,144。

• 磁碟上的權重 — 約 259 GB，相較之下分佈於 16 個分片的僅 70.4 GB。

• 參考硬體 — 八張 80 GB H800 對比 iPhone 17 Pro Max，達到每秒 13+ 個 token，約 3 GB。

• 授權條款 — MIT 對比 Apache-2.0，兩者皆在各自的卡片中載明。

中文作品實際上不同之處

這兩個模型都由中國實驗室打造，且兩者在中文方面都最強，但它們擅長的領域不同，而廠商提供的表格讓這一點格外清楚。

Ming-3.0-audio-flash 正是在語音變得困難的地方最強。在其自行公布的評測圖表中，它回報中文 ASR 平均錯誤率為 3.45，方言平均為 9.40——粵語 4.09、上海話 11.15、閩南語 12.84、湖北話 9.46、湖南話 8.76——而 Gemini 3.8 Flash 在方言平均上的參考值為 48.41。同一批圖表顯示，它在說話者分離（speaker diarization）上落後（AMI 25.29，MiMo-V2.6 Pro 為 11.16），在長音訊推理上也落後（Chain 分數 12.31，Qwen3.8-Omni Flash 為 34.54）。因此，誠實的解讀是：它在有口音的轉錄上表現出色，在判斷誰說話以及錄音整體含義上則表現普通。

MiniCPM-V 4.7 35B-A3B 在密集視覺中文任務上表現最強：OCRBench 91.20、OCRBench_v2 68.47、OmniDocBench v1.6 94.24、CCOCR 81.14、MMMU 80.22、MathVista 88.00、CharXiv reasoning 75.60、TextVQA 84.99——全部出自 OpenBMB 自家的圖表，全都未經重現驗證，而且其中數列標註為以些微差距勝過 35B 級別的 Qwen 與 Gemma 模型。其機制在於視覺塔採用了 4x/16x 混合的 token 降採樣：16x 會合併 token 以換取速度，4x 則保留四倍數量的 token 以維持細節；而這項設定必須同時傳給 processor 與 generate()，否則兩者會不一致。

因此，中文能力上的重疊既有限又真實：一份附有語音備註的掃描中文文件，就是一個需要兩個模型處理的問題，而兩個模型都無法處理另一半。

將其中任何一個投入正式環境的成本

這些並不是可以互相比較的數字，而硬要假裝它們可以相比，正是這類文章常見的謬誤。

Ming-3.0-audio-flash 需要一整個節點。八張 80 GB H800 是廠商針對 128K 上下文的規格配置；經驗證的 SGLang 替代方案使用四張 GPU，且只回傳文字。總參數 9.3B、啟用參數 2.7B 的同系列型號 Ming-3.0-audio-tiny 可裝在一張大顯卡上，但其公布數據在相同表格上始終較差——long-audio Chain 為 10.56，對比 12.31；LongAudioSpan 為 35.45，對比 41.12；URO-Bench-Pro 為 54.15，對比 81.92——因此它是不同的產品，而不是更便宜的版本。

MiniCPM-V 4.7 35B-A3B 只需一部手機、一張 GPU，或者如果使用者自帶裝置，就完全不必付出成本。它擁有 Ming 所沒有的活躍生態系：GGUF、FP8、int4、GPTQ 與 AWQ 等變體在幾天內陸續發布，還有 DSpark 推測解碼草稿模型；除了 vLLM 與 SGLang 之外，也支援 llama.cpp 與 Ollama；主儲存庫已有 76,000 次下載與超過一千個讚。無論其他方面如何，這是一款其他人已經在實際運行的模型。

那個採用率差異是文中與決策最相關的事實，而且跟品質毫無關係。一個有 76,000 次下載的模型，背後已有社群踩過你遇到的 bug。一個只有 22 次下載的模型，就只有一個儲存庫和一張模型卡。

那麼它們在哪裡相遇？

在一種架構中：一個必須同時聽與看的應用程式。最明顯的例子是客服或合規流程——一段有方言使用者參與的華語錄音通話，加上來電者上傳的掃描表單，以及一份必須將兩者連結起來的摘要。Ming 負責轉錄音訊並回答有關音訊的問題；MiniCPM 負責讀取表單並擷取欄位。兩者都無法完成對方負責的那一半，而兩者之間的接合點是文字。

那個接合點是多數團隊最容易低估的部分。兩個開放權重檢查點，意味著兩次授權審查、兩套部署方案、兩種失效模式，還得多一次模型呼叫來決定哪份文件該送到哪裡。Ming 的路線是 Transformers 搭配 trust_remote_code=True，記憶體下限達數百 GB；MiniCPM 的路線則是筆電上的一個量化檔案。同一條管線的這兩半之間，在營運上的落差，比大多數相互競爭的模型之間的落差還要大。

路由層及其限制

OrcaRouter 並不託管這兩個檢查點。兩者都是你可以自行執行的開放權重，皆不在我們的目錄中，且本文任何句子都不應被解讀為端點供應要約。路由器真正觸及的是連結組織：判斷傳入資產是音訊還是影像並將其送往正確節點的分類器、為擷取設定框架的提示詞，以及把兩份輸出合併成一份報告的摘要器。

那些都是普通的文字呼叫，而把它們放到一個涵蓋超過 200 個模型、0% 加價的 API背後的道理很簡單——供應商牌價直接透傳，所以廠商降價當天我們這邊就生效，一把金鑰取代三份合約。路由 DSL正是貼合這個問題的部分：一條管線同時有音訊分支和圖像分支，這首先是路由問題，其次才是模型問題，而自動容錯移轉讓調度器在分類模型出狀況時仍保持運作，這是整條鏈中唯一不能失去的呼叫。

限制同樣簡單。路由不會讓 259 GB 的檢查點變得可託管，也不會讓手機大小的視覺模型變成 ASR 系統。

簡短版本

Ming-3.0-audio-flash 是野心更大的模型，也是目前較不實用的那一個：在方言中文語音辨識上，勝過同級中任何已公布數據的模型；但它沒有獨立驗證、沒有已合併的推論服務整合，而且硬體需求讓任何沒有 GPU 節點的人都難以使用。MiniCPM-V 4.7 35B-A3B 則是更成熟的產品：有模型卡、量化版本、框架支援、真正新穎的裝置端方案，以及社群。它同時也是視覺模型，這表示它做不到另一個模型之所以存在的那項任務。

按模態挑，比較起來只要三十秒。按野心挑，你會花上一個月，才發現那個野心最大的只有 22 次下載。