AuK 對比 AuK-Flash：32 個採樣步數還是 4 個，以及為何學生有時會贏

這兩個檢查點的大小均為 6.122 GB。兩者皆以 MIT 許可證發布。兩者都由同一個需另行下載的 30 億參數指令編碼器，以及同一個 637 MB 的 VAE 驅動。AuK與AuK-Flash在你所配置的方面幾乎沒有任何差異——但在一件你每次呼叫時都會感受到的事情上截然不同：取樣器的運行次數。AuK 是騰訊混元團隊與上海交通大學、南洋理工大學的學術共同作者於 9 月 9 日在 Hugging Face 上發布的 15 億參數開放權重語音生成與編輯基礎模型，它在無分類器引導強度 2.0 下進行 32 次函數評估。AuK-Flash 是經過蒸餾的學生模型，在完全關閉引導的情況下僅進行 4 次評估，號稱可獲得 4.5 倍的牆鐘加速。顯而易見的解讀是：Flash 是當延遲比品質更重要時你所選擇的經濟艙座位。但這種解讀是錯的，而廠商自己的評測表格恰恰反駁了它：在技術報告的正面對決欄位中，Flash 在 MMAE-Speech 的編輯比率指標、SpeechEditBench 的副語言學欄位、英文指令跟隨、聲學編輯的說話者相似度，以及全部四個增強感知品質欄位中都拿下最高分。它不是降級，而是另一種取捨；你想要哪一邊，取決於你實際上在執行的是這兩種任務中的哪一種。

它們之間實際上有什麼不同？

去掉行銷包裝，選擇就歸結為一個設定檔。AuK 的執行環境是一個混合整流流 Transformer——雙流 MMDiT 區塊饋入統一單流 DiT 區塊——以 bfloat16 Euler 求解器運行，24 kHz、64 維潛在變數，50 Hz。AuK-Flash 運行相同的架構，加上一個蒸餾取樣器，由一致性初始化加上任務路由的 Decoupled DMD 產生。所有其他組件都是共用的。

• 採樣步數 — AuK：32 次函數評估，可配置。AuK-Flash：4 次，固定。

• 無分類器引導— AuK：scale 2.0，可調。AuK-Flash：無（CFG=0）。

• 檢查點大小 — AuK：auk_base.safetensors，大小為 6.122 GB。AuK-Flash：auk_flash.safetensors，大小為 6.122 GB。以 MB 為單位完全相同。

• 共用執行環境 — 一個 637 MB 的 VAE 加上 Qwen/Qwen2.5-Omni-3B 編碼器，需分別下載，並由兩者共用。

• 宣稱速度 — AuK-Flash：在硬體、時長與批次大小相同的條件下，真實執行速度比 32-NFE 教師模型快 4.5 倍。

• 授權 — 兩者均採用 MIT 授權，這回總算名副其實。

完全相同的檢查點大小，正是重新定義整個比較的關鍵細節。蒸餾變體通常以較小的體積換取速度。AuK-Flash 並未更小。你不會節省磁碟空間，不會節省傳輸時間，而且——因為編碼器和 VAE 是共享的，DiT 的寬度也相同——選擇學生模型並不會實質節省 VRAM。Flash 唯一回報給你的資源，是時間。不過還是值得指出一個預算陷阱：模型名稱中的「1.5B」描述的是擴散骨幹，而磁碟上的檔案大小為 6.122 GB。請按檔案大小預先規劃儲存空間。

AuK-Flash 真正勝過完整模型的地方

這就是「distilled = worse」這種直覺錯判的部分，而這點在報告表格中橫跨數個彼此無關的任務族群都成立。先從感知層面看。在 DNS Challenge 增強集合上，Flash 的 UTMOS 為 4.05，AuK 為 3.86；在 CHiME-4 上為 3.91 對 3.72；在 Libri2Mix 上為 4.03 對 3.87；在 VCTKSR 上為 4.05 對 3.93。Flash 也在四個集合中的兩個贏下辨識錯誤率欄位，CHiME-4 的 WER 為 7.84 對 7.98，VCTKSR 的 WER 為 2.92 對 3.06。人類評分的自然度是學生模型持續領先的唯一軸線，而報告也明確如此說明：完整模型提供更強的語言準確度與編輯忠實度，而 Flash「往往提供更好的感知品質」。

這些勝利不僅限於增強。在 MMAE-Speech 的編輯比率指標上——即編輯是否落在預期幅度——Flash 得分 13.85，而 AuK 為 12.44。在 SpeechEditBench 的副語言欄位上，比分是 39.25 對 38.50。在 InstructTTSEval 的英文描述轉語音任務中，比分是 82.40 對 81.60，與該行的最佳基線持平。在 Ming-Freeform 套件的聲學編輯中，它保持了該系列中最高的說話者相似度，中文 0.79、英文 0.75，而基礎版本分別為 0.78 和 0.74。換句話說，保留說話者身份是四步所能換來的成果之一——報告自身的總結是，完整模型提供較低的平均辨識錯誤率，而 Flash 則能更好地保留說話者身份。如果你正在進行語音轉換、配音或增強工作，且音色比詞彙錯誤更重要，那麼學生模型是更好的選擇。

這32個步驟仍然有其存在的價值

基礎模型的優勢恰好集中在您預期擴散模型在擁有更多採樣預算時會表現出色的地方：任何輸出必須在語言上正確的任務。

在 Seed-TTS-Eval 上，AuK 的平均 WER 為 2.65，而 Flash 為 2.85；說話者相似度則為 0.795 對 0.790。該平均值的內部離散程度比平均值本身更具參考價值。兩者在英文測試集上幾乎持平——1.02 對 1.03——但在中文上有所區別，1.02 對 1.10；而在困難中文子集上差異更明顯，5.91 對 6.43。中文正是額外步驟發揮作用的地方。

同樣的模式也出現在指令遵循上。在 InstructTTSEval 的中文描述轉語音任務中，差距相當懸殊：AuK 為 83.37，Flash 為 78.80。報告指出，基礎模型在該評測套件的全部三項中文指標上均領先，而 Flash 的「主要優勢在於其更強的英文 DSD 成績」。區分高下的是語言，而非架構。

{{1}}編輯保真度最能區分兩者的高下。{{/1}} {{2}}在 SpeechEditBench 上，AuK 的內容編輯準確度為 91.83，Flash 則為 87.50——這是整個比較中單項差距最大的一處。{{/2}} {{3}}聲學編輯的結果幾乎同樣懸殊：37.07 對 30.26。{{/3}} {{4}}在 Ming-Freeform 套件中，AuK 在幾乎所有關鍵指標上都報出更低的 WER：{{/4}} {{5}}全中文編輯是 3.09 對 3.34，{{/5}} {{6}}全英文編輯差距更大，為 3.96 對 4.84。{{/6}} {{7}}如果你的產品需要改寫他人錄音中的文字——歌詞修改、內容替換、插入與刪除——{{/7}} {{8}}32 步模型才能讓轉錄內容保持真實可靠，{{/8}} {{9}}而這 8× 的步數差異值得為此付出。{{/9}}

根據報告自己的數據，兩個模型在情感編輯方面仍然很弱：SpeechEditBench 的準確率，AuK 為 9.94，Flash 為 6.29。這不是蒸餾偽影。這是一類還沒有人解決的任務，而挑選學生模型並不會讓你在這件事上比現在更糟。

4.5倍是抽樣數值，不是端到端的數值。

這是頭條速度提升背後所隱藏的算術，也是你在將架構投入 Flash 之前，最需要理解的一件事。

AuK-Flash 執行 4 個取樣步驟，而 AuK 執行 32 個。也就是步驟數少了 8 倍。供應商報告的牆鐘時間快了 4.5 倍。這兩個數字之間的差異，來自取樣迴圈周圍的一切，而其中以編碼器為主：這是一個 Qwen2.5-Omni-3B 多模態模型，兩個檢查點都會載入，且每次請求都必須執行。該編碼器的大小大約是擴散骨幹的兩倍，而且其成本是固定的。Flash 無法加速它，因為 Flash 不是它的一部分。

所以這說法誠實的版本是這樣：{{1}}4.5×{{/1}}是在匹配條件下擴散部分能獲得的加速，而你端到端的增益會取決於取樣迴圈在實際耗時中佔據的比例。如果你執行的是長篇生成，其中{{3}}多個潛在幀上的32個步驟{{/3}}佔主導，那麼結果會接近已發表的數字。如果你的工作負載是帶有大量指令預處理的短片，或者你在批次處理小型請求，那麼每次呼叫的更大比例會停留在共享編碼器上，你實際的加速會明顯小於{{2}}4.5×{{/2}}。在讓延遲預算依賴這個數字之前，先衡量你自己的混合工作負載。{{4}}目前還沒有人公布那個端到端的數字{{/4}}——包括供應商在內，他們{{5}}完全沒有報告任何絕對延遲數據或VRAM需求{{/5}}。

用作者自己的話來說，蒸餾的代價是什麼

這份技術報告異常坦率地指出了學生在哪裡會出錯，而這些失敗模式對部署者來說比基準測試表更有用。

教師引導目標原來才是問題所在。在一致性分支中使用 CFG 目標「可能會讓少步學生接觸到過度飽和的預測」，作者表示這會導致過衝與可聞的削波。另外，統一的解耦 DMD 排程「會降低多說話者與人聲分離的品質」，部分學生輸出會退回到未處理的混合音訊——蒸餾過程抹去了模型原本應執行的分離功能。任務路由 DMD 是文中描述的解決方案，也正是報告刻意將該特定弱點限定於統一變體的原因。如果語音分離是你流程中的核心環節，那麼在你信任它之前，這一段就是你要拿來測試的基準。

還有兩個限制是操作性的，而非統計性的。該管線的 Prompt Enhancer 會將關於速度、響度和音高的口語化措辭映射到一組固定的受支援數值，並在聲學推論執行前拒絕任何無法映射的內容——因此不支援的請求會提前失敗，而不是優雅地降級。此外，儲存庫僅接受 Qwen/Qwen2.5-Omni-3B 作為編碼器路徑；README 中說明目前不支援 Qwen3-Omni，因此較新的編碼器並非可直接替換的升級。ComfyUI 整合對來源與目標序列合計設有 30 秒的限制。

同時執行兩者才是預期的配置。

該儲存庫自身的多GPU範例將AuK放在一個裝置上，而將AuK-Flash放在另一個裝置上——分別是cuda:0和cuda:1——這清楚表明騰訊預期兩者共存而非相互競爭。對大多數生產級語音技術棧而言，這也是正確的答案，因為這兩個模型各自專精於互不重疊的領域。將重度編輯與中文語音請求路由到AuK；將增強、分離、英文指令遵循以及任何互動式請求路由到AuK-Flash。兩者載入相同的編碼器與相同的VAE，因此您只需為這份共享的運行時付費一次，即可在其後方切換檢查點。

這是在模型層的路由決策，與 OrcaRouter 在 API 層對託管模型所套用的形式相同。兩者今日交會之處，正是 AuK 自家管線中的接縫：Prompt Enhancer 需要一個OpenAI 相容的聊天端點，將粗略指令轉換成模型支援的詞彙，而可選的 ASR 後備方案則需要一條轉錄路徑。只要將其中任一者指向 OpenAI 相容的聊天端點，就能以一把金鑰橫跨 200 多個模型，供應商牌價以 0% 加價直接轉嫁，後端若失效則自動容錯轉移——這之所以重要，正是因為這是個釋出僅兩天、沒有託管 API 也沒有獨立重現的版本，你絕不會想讓未經驗證的相依元件掛在寫死的端點上。

不過，要清楚說明哪些是不可用的。AuK 和 AuK-Flash 目前皆未由任何託管推論供應商提供服務——Hugging Face 的卡片上直接寫明了這點——而且兩者也皆無法透過 OrcaRouter 路由。這從頭到尾都是一個自架的決定。

仍然未知的是什麼

這份發布幾乎所有內容都來自廠商報告。4.5× 的加速、WER 數值、SpeechEditBench 的各欄資料，以及 UTMOS 的各列數據，全部出自 AuK 團隊自己的技術報告 arXiv 2609.08936，提交日期為 9 月 8 日——沒有獨立重現、沒有第三方排行榜登錄、也沒有中立測試框架的結果。採用訊號同樣薄弱：截至 9 月 10 日，兩個 Hugging Face 儲存庫顯示過去一個月有 30 次下載，各自約有二十多個讚；而 GitHub 儲存庫顯示 217 顆星、12 個分支、3 位貢獻者。這是一次研究型發布，不是熱潮。

<img src="4.png" alt="騰訊混元 AuK GitHub 儲存庫 README 的截圖，顯示 2026 年 9 月 9 日開源公告以及 AuK 和 AuK-Flash 變體表格"> 這次發布本身安靜到值得直言不諱，因為很容易過度解讀。沒有混元公告、沒有部落格文章、沒有定價頁面，也沒有發布活動。供應商唯一註明日期的聲明是儲存庫 README 中的一行——[2026/09/09] We open-source AuK。Hugging Face 儲存庫的中繼資料顯示，這些 Spaces 早在 8 月中旬就已建立，權重檔案最後更新於 9 月 9 日和 10 日，因此打包發生在公告之前。從儲存庫可以得知：兩種變體均採用 MIT 授權的權重、一份技術報告、Hugging Face 和 ModelScope 可用的下載說明，以及一份有條理的工作清單。尚未確認的是：所報導的數字能否通過獨立測試框架、是否會出現託管端點，以及 Flash 檢查點在其他人運行過之後是否仍會是推薦的預設。

該選哪一個

如果你正在建構內容或歌詞編輯功能，或以任何形式提供中文語音服務，請採用 AuK 並接受這 32 個步驟。它在那方面的優勢相當大，在兩套獨立編輯套件中表現一致，而且正好是使用者會立即注意到的那種正確性失誤——轉錄稿中出現錯字。

如果你正在建置增強、分離、語音轉換，或任何需要人類等待輸出的功能，請選擇 AuK-Flash。它在取樣迴圈上的速度遙遙領先，在感知品質項目上明顯勝出，而且比它所蒸餾自的模型更能保留說話者身分。確實存在的品質差距集中在那些你大概不會執行的任務上。

如果你正在建構一個同時涵蓋兩者的語音產品，那就兩者都執行。相同的磁碟、相同的編碼器、相同的授權，只有一個設定差異——以及該儲存庫已經示範的部署模式。唯一值得等待的是你自己的端到端延遲量測：4.5× 是真實的，但它屬於取樣器，只有你的工作負載組合才能告訴你其中有多少會到達你的使用者。