一張生成的標題卡,標題為{{1}}'Ming-3.0-audio-tiny'{{/1}},副標題為{{2}}'一顆 GPU、131,072 個 token、七週大的權重'{{/2}},並有三行簡短文字寫著{{3}}'9.3B 總計/2.7B 活躍'{{/3}}、{{4}}'兩個 safetensors 分片,17.7 GB'{{/4}} 與 {{5}}'模型卡與設定檔日期為 2026 年 10 月 16–19 日'{{/5}};頁腳寫著{{6}}'事實來自 inclusionAI 的 Hugging Face 儲存庫與 GitHub 部署設定檔;目前沒有獨立基準測試。'{{/6}}
Engineering & Research

Ming-3.0-audio-tiny 現在單張 GPU 就能跑了——而它的設定終於標示為 128K

作者

Elias Hawthorne

發佈日期

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

位於Ming-3.0-audio-tiny 背後的檢查點自 2026 年 9 月 3 日起即可下載——兩個 safetensors 分片、17.7 GB,在儲存庫本身建立九分鐘後推送。直到本週之前,幾乎所有告訴你如何執行它的東西都不存在。2026 年 10 月 16 日至 19 日間,inclusionAI 取代了九月隨附的設定,把具有 8,192 token 視窗的影片-語言-音訊變體,換成一個宣稱具備 131,072 的音訊專用版本,加入了產生語音的 Talker,加入了兩段參考語音片段及其轉錄稿,並且——在儲存庫整整三天完全沒有模型卡的期間之後——寫了一份模型卡。這些文件指向的程式碼於 10 月 15 日抵達 GitHub,放在一個以更大同系列模型命名的儲存庫中,也就是 Ming-3.0-audio-flash,而且它為 tiny 模型帶來了三種部署設定檔,而 tiny 模型從未有過這些。沒有人宣布任何這些事。所以值得回答的問題不是有什麼新東西,因為權重已經七週大,且與它們落地那天位元組完全相同。而是讀者現在能執行什麼上週一還不能執行的東西,以及當他們這麼做時,準確度要付出什麼代價。 像這次發布背後的已記錄 AI 故障與代理程式事件,都收集在 the OrcaRouter AI Incident Archive,其中每一條目都附有自己的來源、嚴重程度、信心等級與爭議標記。

變更了什麼,以提交日期為準

Hugging Face 的提交紀錄短得可以完整讀完,而它的形態極不尋常:九月有三次提交,接著三週毫無動靜,然後四天內出現六次。

• 9月3日 11:45 與 11:49 UTC — 儲存庫已建立,隨後兩個分片在「Add files using upload-large-folder tool」下上傳。隨附的 README 標題為「Ming Audio V3」,宣告採用 Apache 2.0,並為該儲存庫標上 automatic-speech-recognition,且表示該儲存庫「目前記錄 ASR 路徑」。

• 9月17日 — examples/ 資料夾會被刪除。在此之後,儲存庫只剩下權重、自訂建模程式碼與一份簡短說明卡,別無其他。

• 10月16日 08:14 至 08:20 UTC——影響重大的那一次。 config.json 被重寫:max_position_embeddings 在文字主幹上從 8,192 變成 131,072,transformers_version 從 4.56.2 變成 5.14.1,且 audio_config.model_type 從 bailing_moe_v3_vl_audio 變成 bailing_moe_v3_audio——這個視訊-語言-音訊類型已不再描述該模型。在同一次推送中,auto_map 新增了它原先沒有的 AutoModel 與 AutoProcessor 項目,processor_config.json 出現了,而 talker/ 目錄樹也隨之到來:一個 1.4 GB 的語音模型、一個 1.6 GB 的 VAE、一個 CAM++ 說話者編碼器、用於英文與中文的文字正規化有限狀態轉換器。在同一次推送中,舊的 README 也被移除——接下來三天,該儲存庫完全沒有模型卡。

• 10月17日 11:44 UTC——「新增語音預設。」兩個參考 WAV 檔,US_James.wav 和 灵楷.wav,外加一個內含其確切逐字稿的 JSON 檔。

• 10月19日 10:36、11:44 及 11:49 UTC — 三次清理與上傳提交。

• 10 月 19 日 13:19 UTC ——「新增 Ming-3.0-audio-tiny 模型卡。」8,514 位元組,也是該儲存庫歷史上第一份描述語音與音訊模型、而非 ASR 路徑的文件。

GitHub 這邊有自己的時間線,而且開始得比較晚。inclusionAI/Ming-3.0-audio-flash 建立於 10 月 15 日 03:50 UTC——比權重問世晚了六週——而且直到 10 月 19 日 14:53 UTC 還在推送。它有八顆星、一個 MIT 授權檔案,以及一個 deploy/ 目錄,裡面有六個 YAML 設定檔,其中三個以名稱指向那個微型檢查點。並沒有 inclusionAI/Ming-3.0-audio-tiny 這個儲存庫;該 URL 會回傳 404,而微型模型的程式碼放在 flash 儲存庫裡,與它的兄弟模型並列。

設定重寫才是真正的重點。

上下文長度欄位變成 16 倍,這種變更不是表面性的,就是結構性的;而在這個案例中,其餘差異內容顯示它是結構性的。九月時,儲存庫在目錄樹中提供了 modeling_bailing_moe_v3_audio.py 與 processing_bailing_moe_v3_audio.py,但其設定所描述的音訊塔類型是 bailing_moe_v3_vl_audio——這是影片語言建置留下的殘留——而其模型卡要求你使用 trust_remote_code=False 來實例化模型,而這並不是自訂建模檔案想要的做法。十月的設定是第一個宣告類型、宣告執行環境與程式碼路徑彼此一致的設定。

• 主幹 — 24 層、隱藏層维度 1,536、16 個注意力頭、128 個路由專家(每個 token 有 8 個啟用)與一個共享專家、專家中間層维度 512、第一個稠密層位於索引 1、路由縮放因子 2.5、詞彙表 157,184。

• 注意力 — MLA,KV 潛在向量寬度為 512、查詢潛在向量寬度為 256,rope_theta 6,000,000,partial_rotary_factor 0.5。低秩 KV 形式正是 131,072 個 token 的視窗在單張顯示卡上還說得過去的原因:快取儲存的是潛在向量,而不是每個注意力頭的鍵與值。

• 音訊塔 — 32 層、寬度 1,280、20 個注意力頭、3,000 幀的上下文與 128 個梅爾頻段(mel bins),下採樣器的卷積核為 [3,3,3]、步長為 [2,2,2]。音訊 token id 157,168。

• 規模 — 總計 9.3B 參數,每個 token 啟用 2.7B,全程採用 bfloat16,宣告對應 Transformers 5.14.1。

• 輸入與輸出 — 輸入音訊加文字指令;輸出文字,或透過選配的 Talker 輸出文字加合成語音。中文與英文,包括口音與方言,依卡片所示。

設定重寫不會做的是加入任何權重。儲存庫中的四個 safetensors 檔案——兩個 Thinker 分片、Talker、VAE——在我檢查過的每個修訂版本中,大小都相同,一路回溯到最初上傳的版本。這是對未變更檢查點的說明文件與封裝變更,這正是為什麼從 8,192 到 131,072 的躍升值得信賴:沒有人重新訓練任何東西,因此這項聲稱可以透過載入模型並要求長上下文來驗證,而不是憑信心接受。

還有一份文件資料仍不一致。該儲存庫頂層的 Hugging Face pipeline 標籤寫的是text-to-speech,而模型卡本身的摘要卻稱它是能接受指令並回傳文字或語音的音訊語言模型。這個標籤是 Talker 成為最近才被更動的能力後留下的殘餘,而這種事除了按任務篩選 Hub 的人之外,對誰都不重要。

文字用一顆 GPU,語音用兩顆

這正是 tiny 模型之所以名符其實的地方,而它之所以可見,只因為部署設定檔現已公開。Flash 模型的文字設定檔執行於 devices: "0,1,2,3,4,5,6,7",並搭配 tensor_parallel_size: 8——八張 80 GB 顯示卡,這是在配置任何快取之前,256 GB 的 bf16 權重所強制要求的。tiny 模型本身有三個設定檔,其中兩個只要一張卡。

• 文字與 ASR、vLLM-Omni — 單一階段,於裝置:"0",張量平行大小 1,max_model_len 131,072,max_num_batched_tokens 32,768,gpu_memory_utilization 0.92,取樣溫度為 0.6,最多輸出 65,536 個 token。

• 完整音訊含語音輸出——兩個階段。Thinker 在裝置:"0" 位於卡片的 0.78 比例處,而 Talker 在裝置:"1" 位於 0.18 比例處,且 Talker 階段上限為一個輸出 token、溫度為 0.0,因為它不會產生文字。

• ASR 重現 — 僅 thinker 的管線,外加 10-gram 不重複 logit 處理器,音訊限制為每個提示一個片段,max_model_len 131,072,temperature 0.0,輸出 32,768 個 token。那就是廠商取得辨識數據時所用的設定,若你打算進行比較,值得完全照抄。

• SGLang — 單一 GPU、單一可見裝置,僅文字輸出。卡片明確指出此路徑不提供語音輸出。

那些設定檔是檔案,不是散文,而且它們在 flash 儲存庫的 deploy/ 目錄中可見——六個 YAML 設定檔,其中三個是以那個微小檢查點命名的。

A screenshot of the deploy directory in the inclusionAI/Ming-3.0-audio-flash GitHub repository, listing six YAML deployment profile files, three of which carry the tiny model's name.

請如實解讀記憶體數字。0.92 是指派給該階段的那張顯示卡的佔比,並非硬性要求:Thinker 的分片總計 17.74 GB,因此權重可放進一張 24 GB 的顯示卡,還剩下約 6 GB 給快取與活化值使用。0.92 的保留量是為了同時容納 131,072 個 token 的視窗與 32,768 個 token 的批次而估算,而若調低 max_model_len,它就會下降。你無法在單一張卡上做到的,是產生語音,因為 Talker 及其 VAE 是第二個行程,擁有第二組權重——在計入 CAM++ 編碼器與轉導器之前,就已佔 3 GB——而參考設定檔會分配專屬裝置給它們。文字在一張 GPU 上,出聲對話在兩張上:這就是如實的算術,而且這和同系列產品的八張 GPU 屬於不同的預算項目。

下載的內容實際上是什麼?

該儲存庫總計 20.78 GB。Thinker 為 17.74 GB,分成 9.55 GB 與 8.19 GB 兩個分片;Talker 增加 1.40 GB,其 VAE 為 1.56 GB,說話者編碼器為 28 MB,其餘則由分詞器與正規化器檔案構成。廠商並未發布任何量化版本、更小的檢查點或 GGUF 轉換檔,因此除非你自己進行量化,否則 bf16 的數值就是下限。

• 載入 — AutoProcessor.from_pretrained(..., trust_remote_code=True, use_fast=False) 以及 AutoModelForCausalLM.from_pretrained(..., dtype=torch.bfloat16, device_map="auto", trust_remote_code=True)。模型卡本身的程式碼片段接著會手動將 audio_feats 轉換成模型的 dtype,這點稍微透露了處理器路徑並非優先考量。

• ASR 契約——經過驗證的提示詞要求模型說出所說的語言,並在語言標籤與轉寫內容之間放置一個 Tab 字元。如果你正在建置評估測試框架,那個 Tab 就是你的解析器。一般性的「轉寫這段」指令並不是 inclusionAI 所測量的設定。

• 語音 — vLLM-Omni 的預設是內建語音「灵小柔」,而模型目錄隨附兩個參考預設「灵楷」與「US_James」,並附有逐字稿。語音複製需要一段參考 WAV 及其精確逐字稿;卡片警告,不能在單一請求中同時結合內建語音選擇與參考音訊片段。

• 授權 — MIT 出現在模型卡的中繼資料,以及 GitHub 儲存庫的 LICENSE 中,標註日期為 2025 年。請注意缺少了什麼:Hugging Face 儲存庫本身並沒有 LICENSE 檔案。實際上存在於其中的唯一授權文字,屬於 talker/data/ 底下一個隨附的語言識別模型。MIT 的聲明是真的,但它只差一次點擊,位於一個以另一個模型命名的儲存庫中。

• 熱度——截至本週,三次下載、五個讚。flash 模型則有 22 次下載、八個讚。這兩個數字都不是品質的證據;兩者都證明,一次沒有卡片、沒有公告的九月上傳並沒有傳開。

基準圖片,以及缺少的那一欄

有三張 PNG 位於 assets/,承載了這次評測,而這三張全都是 inclusionAI 自己跑的。供應商以星號標示自我評測的項目,並註明比較模型是在其自身提示與解碼設定下重現,因此它們的數字可能與官方報告不同。就我所見,這個檢查點尚未有獨立評測發布——沒有競技場條目,也沒有第三方分數——這意味著以下每一個數字,都是供應商在描述自己的模型。這不是忽略它們的理由;而是把它們當作設計需求書、而非最終定論來讀的理由。

有用的比較是 tiny 與其同系列模型,因為兩者跑的是同一套測試框架。在辨識方面,較小模型略遜一籌;在長音訊推理方面,則遜色許多。

• 中文 ASR 平均 — Ming-3.0-audio-tiny 的字元錯誤率為 3.79,相較之下 Ming-3.0-audio-flash 為 3.45。數值越低越好,因此 tiny 落後 0.34 個百分點。

• 英語 ASR 平均 — 4.36 對 3.69。方言平均 — 10.29 對 9.40。

• BigBenchAudio — 99.20 對 99.40。實際上不相上下,也是唯一一列看不出大小差異的項目。

• MMAU — 75.90 對比 82.00。MMAR — 67.70 對比 74.40。MMSU — 73.06 對比 78.82。MMAU-Pro — 56.42 對比 66.41。

• 長音訊準確度 — 56.39 對比 66.30。LongAudioSpan — 35.45 對比 41.12。長音訊 Chain 分數 — 10.56 對比 12.31。

• 口語互動 — URO-Bench-Pro 54.15 對比 81.92,暴跌 27.8 分。VoiceBench 74.29 對比 86.74。SpeechFCEval 69.80 對比 82.60。

• 工具呼叫 — BFCL-v3 Audio 79.80,相較於 81.40。音樂 — MuchoMusic 58.07,相較於 65.65。

方言列是有趣的例外,因為 tiny 並非全面落敗。它在安徽(5.42 對 5.76)、東北官話(4.21 對 4.28)、江蘇(11.44 對 12.15)、陝西(5.81 對 6.00)、山東(10.17 對 10.69)和雲南(11.28 對 11.53)勝過它較大的同系列模型,卻在客家話(24.08 對 16.51)、閩南語(14.15 對 12.84)和上海話(12.49 對 11.15)大幅落後。一個 2.7B 激活參數的模型在十五個方言列中拿下六列,對上一個 6.5B 激活參數的模型,這是整份評估中最有利的一點,卻被埋在表格中間,讓平均值把它掩蓋掉。

有兩個缺口值得說明,因為它們可被核實,而卡片並未指出。第一,辨識圖中有五列完全沒有 tiny 數值——AISHELL-4、AliMeeting 與 AMI 的語者分離(speaker-diarization)與串接最小排列(concatenated minimum-permutation)列都印成破折號。tiny 模型在「誰在何時說話」上的表現如何,並未公開。第二,文字智慧圖有四欄,且沒有任何一欄是 tiny 模型:其欄位是 Ming-3.0-audio-flash、Qwen3.8-Omni Flash、Qwen3.5-Omni Plus 與 Qwen3.5-Omni Flash。卡片的評估章節說下方數據包含兩種 Ming 變體的結果,這對兩張音訊圖來說是真的,對文字圖則不然。如果你需要知道 tiny 主幹模型能否進行推理對話,inclusionAI 並沒有告訴你。

A generated scoreboard comparing Ming-3.0-audio-tiny and Ming-3.0-audio-flash across six dimensions: Chinese ASR average 3.79 versus 3.45, dialect average 10.29 versus 9.40, MMAU 75.90 versus 82.00, long-audio Chain score 10.56 versus 12.31, URO-Bench-Pro 54.15 versus 81.92, and text GPU requirement one versus eight; a footer reads 'All figures inclusionAI's own evaluation; no independent scores exist.'

這一週實際上為你帶來了什麼

在 10 月 16 日之前,想測試這個檢查點的讀者,面對的是 17.7 GB 的下載檔、一個描述具 8K 視窗之影片語言模型的設定檔,以及一張指示他們在未啟用自訂程式碼的情況下載入自訂程式碼的模型卡。到了 10 月 19 日之後,他們有了與自身模型檔案相符的設定檔、一項可對照未變更權重來測試的 128K 宣稱、三個具名部署設定檔(其中包含單 GPU 設定檔)、附有轉錄稿的語音包,以及一張說明模型用途的模型卡。這些都不是新模型。這一切都是磁碟上的檢查點與有人能在一個下午內評估的檢查點之間的差異。

成本是規格選擇所隱藏的那一部分。在廠商自家的表格上,從 6.5B 活躍參數模型換到 2.7B 活躍參數模型,能換來八分之一的 GPU 數量,卻要付出 URO-Bench-Pro 掉了 27.8 分、VoiceBench 掉了 10 分,以及長音訊 Chain 分數大約少了五分之一的代價。對轉錄服務來說,這是合理的取捨;對任何必須跨越一小時音訊進行推理的用途來說,這是不好的取捨;而廠商把兩欄並排印出來,好讓你決定自己正在打造的是哪一種。

A screenshot of the Ming-3.0-audio-tiny model card on Hugging Face, showing a download count of 3, a model size of 9B parameters, the summary table listing 9.3B total parameters with 2.7B activated per inference step and an MIT licence, the highlights list, the architecture note and the start of the Transformers quick-start section.

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

OrcaRouter 並不提供 Ming-3.0-audio-tiny。它不在我們的目錄裡,我們無法為它提供端點,此處任何內容也不應被解讀為這樣的要約。在以這類檢查點為核心建構的管線中,路由器真正好用的地方,是檢查點以外的那一半。語音系統大多是文字工作:決定要對音訊問些什麼的提示詞、把以 Tab 分隔的語言標籤轉成結構化輸出的解析器、依轉錄稿寫成的摘要,以及決定音訊檔要送往 2.7B 模型還是 126B 模型的分類。這些都是普通的文字呼叫,而一個 API 就能以 0% 加價取用超過 200 個模型——供應商定價原樣透傳,因此廠商一降價,我們這邊當天就生效——比起層層堆疊的供應商合約,接線起來要簡單得多。自動故障轉移讓你可以在管線的某一部分後面接上新近才有文件記載的模型,而不必把整條路徑都押在它身上。

這條界線值得說清楚。你在自己的 GPU 上執行的 17.7 GB checkpoint 是基礎設施,不是一次 API 呼叫。路由器負責路由呼叫。它不會把開放權重的音訊模型變成託管服務,也不會把三次下載變成正式環境的實證。

看什麼

有三件事會改變這幅景象,而且這三件全都可查證。第一,獨立評分:一旦某個競技場或第三方評測機構把這個檢查點列入榜單,那 27.8 個百分點的語音互動落差就不再是廠商的自述,而會變成一個資料點;在那之前,請留意同一個廠商也公布了六列方言數據,而在那些數據裡,較小的模型勝出。第二,Hugging Face 儲存庫裡的一份 LICENSE 檔案,這會讓 MIT 從卡片上的一個連結,變成採購流程真正會讀取的產出物中的一項事實。第三,一個 tiny 專屬的 GitHub 儲存庫:如今讓單一 GPU 宣稱成真的那些部署設定檔,放在一個以較大模型命名的儲存庫裡,這在有人把它重新命名之前都沒問題。

在那些其中一項真正落地之前,準確的描述並不光鮮。與 9 月 3 日相同的權重、約 18 GB 的 Thinker、一個 131,072 個 token 的視窗——它出現在設定檔裡,而不是在檢查點裡;三種服務設定檔,文字版可放進一張卡,語音版則要兩張;紙面上是 MIT 授權;五列它拒絕公開的參考資料;以及一張比它所描述的設定檔還年輕三天的模型卡。這一週並沒有讓模型變得更好。它讓模型變得可讀,而對於一個沒有人宣布的開放權重檢查點來說,可讀就是整個產品。