MiniMax-Music3 開放權重已推出：Repo 顯示的內容與尚未確認的部分

MiniMax-Music3，這款開放權重的音樂生成模型，於2026-08-13出現在Hugging Face上，隸屬於MiniMaxAI組織之下，沒有論文、沒有發布部落格文章、也沒有基準測試報告——只有權重、一份README，以及一則簡短社群貼文，稱其為「下一代、可投入生產」的文字轉音樂模型。截至撰寫本文時，該儲存庫約有25次下載和60個讚，這就是低調發布的樣貌。這是一篇「目前已知資訊」的報導：以下所有標示為「來自儲存庫」的內容，都直接取自模型卡和檔案；所有尚未確認的部分，也都會如此標示。

首先，日期更正

此模型系列有兩個發行版本，將它們區分開來會很有幫助。託管 API 模型music-3.0於2026 年 7 月 16 日在 MiniMax 平台上線，定價為每生成一首長度不超過五分鐘的曲目 0.15 美元，並提供附速率限制的免費方案。以MiniMax-Music3之名發行的開放權重版本，在將近一個月後的 2026 年 8 月 13 日登陸 Hugging Face。廠商尚未明確說明開放檢查點是否與驅動 API 的權重相同——這項等價關係是本清單上未經確認的項目之一——但 README 描述了相同的五分鐘全曲能力和相同的結構化文字描述控制介面，因此它們至少屬於同一世代。

儲存庫實際包含的內容

MiniMax-Music3 是一種混合分層架構，而 README 對其組成部分的描述異常具體。一個8B 參數的 Global LLM（由 Qwen3-8B 初始化）逐幀預測第一個殘差向量量化碼本，並承載歌曲的長程結構：主題、節奏、人聲特徵、編曲推進。一個0.6B 參數的 Local LLM預測每一幀內其餘的聲學碼本。與其純粹從離散 token 解碼，一個Flow Matching 模組（2.4B 參數）融合兩個 LLM 的最終隱藏狀態，並合成連續潛在表示，再由一個Flow-VAE 解碼器（123M 參數）轉換為 32 kHz、16-bit 的立體聲音訊。

The tokenizer is an eight-layer RVQ stack: the first semantic codebook holds 16,384 entries; the seven acoustic codebooks hold 1,024 each. Training first optimizes the semantic codebook, then all eight jointly.

具體來說，儲存庫中包含了：四個 safetensors 分片中的語言模型權重，以及一個 48 分片的 Qwen 基礎骨幹，存放於qwen_7B/，Flow-VAE（flowmatching_vae.pth）、RVQ 深度解碼器、條件編碼器、聲碼器、調度器、分詞器檔案、一個 diffusers 模組化模型索引，以及一個附有參考音訊的端對端測試腳本。這是一個可運行的模型，而不是一個只提供權重的展示品。

控制面是有趣的部分。

輸入格式正是讓這項技術有別於「提示即祈禱」式音樂生成的關鍵。MiniMax-Music3 接收歌詞以及一組音樂描述。README 建議採用結構化的說明文字，包含三個部分：整體後設資料（流派、子流派、BPM、調性、音階、情緒鋪陳、聆聽情境、製作規格）、人聲細節（性別、音色、演唱風格、和聲、背景和聲、效果處理），以及編曲（主要與次要樂器、段落層級的樂器演變、律動、貝斯、打擊樂、織體、空間效果）。

歌詞可接受明確的區段標籤——[Intro]、[Verse]、[Pre-Chorus]、[Chorus]、[Bridge]、[Instrumental]、[Solo]、[Outro]——因此能確切告訴模型副歌落在何處、橋段中發生什麼事。這種結構控制等級，多數消費級音樂生成器即使有，也只能透過事後編輯來達成。託管 API 也以參數的形式提供相同的控制：一個 is_instrumental 旗標、一個 lyrics_optimizer（用於自動歌詞），以及一個涵蓋 MP3、WAV 或 PCM 的音訊設定，支援 16/24/32/44.1 kHz 與 32/64/128/256 kbps。

經營自己的成本

就 2026 年的標準而言，這並不算一個重量級模型。README 指出，全精度可放入 24 GB 的 VRAM，啟用自動 CPU 卸載後生成約需 22 GB，而將語言模型逐層串流載入則可進一步降至能在 8 GB 顯示卡上執行。文件中記錄了三種部署路徑：SGLang-Omni（一個一行式的 sgl-omni serve 指令）、diffusers 模組化 pipeline（整合 PR 為 huggingface/diffusers#14456，撰寫本文時尚未合併），以及ComfyUI。

對大多數讀者來說，服務（serving）的敘事比架構更重要，因為它是「一個存在的模型」與「一個你能實際操作的模型」之間的差異。diffusers 路徑只需一次 from_pretrained 呼叫，就能產生一個 32 kHz 立體聲 WAV 檔案，這個檔案歸你所有、存放在你自己的磁碟上，沒有速率限制，也沒有按歌曲計費的機制。

實際上適用的授權條款

MiniMax-Music3 以「MiniMax-Music3 社群授權」發布，該授權在實務上相當寬鬆，但仍附帶條件。你可以使用、複製、修改及再授權軟體與權重；你必須在任何使用它的商業產品介面中顯著標示「MiniMax-Music3」；且若此類產品的年度總營收超過 $20 million USD，你需取得 MiniMax 的個別書面授權。另有一份可接受使用政策（附件A），涵蓋常見的禁止事項以及對機器生成內容的揭露要求。

在其底層，該模型是由來源更寬鬆的借用零件堆疊而成：Global LLM 是從 Qwen3-8B（Apache 2.0）微調而來，DiT-2B 流程元件修改自 Stable Audio 的程式碼（MIT），VAE 則修改自 DAC 音訊編解碼器（MIT）。因此，社群授權限制是疊加在 Apache/MIT 元件之上，而對多數商業使用者來說，實際上會感受到的約束是署名要求。

率先推出的託管路由

如果您完全不想自行操作權重，API 版本自 7 月 16 日起已上線。模型 ID 為 music-3.0（付費，每分鐘 120 次請求）和music-3.0-free（免費，每分鐘 3 次請求）均透過 api.minimax.io/v1/music_generation 提供，另有獨立的歌詞生成端點，每首歌收費 0.01 美元。輸出 URL 於 24 小時後過期，音訊也可以十六進位格式回傳以利串流 — 這項設計明顯是為了應用程式整合而非歸檔。

API 的定價為每首固定費用：每首生成歌曲 0.15 美元，最長五分鐘。免費方案採用相同模型，速率為 3 RPM，確實足以用於原型開發。如果你需要自托管容量，開放權重會徹底改變成本結構——你支付的是 GPU 費用，而不是每首歌的費用，按首歌計費的計算方式也就不存在了。

什麼尚未被確認

對我們所不知道的事物保持精確，是本文的要旨。

• 尚無獨立評估存在。上述所有能力聲明皆出自 MiniMax 自家的 README 與 API 文件。截至撰寫本文時，尚無第三方發表過聆聽測試、音樂品質基準測試，或與 Suno、Udio、Google 的 Lyria 3.5 進行正面比較。

• 開放檢查點與 API 檢查點。 供應商尚未說明 Hugging Face 上的權重是否為 music-3.0 背後的確切模型。在被告知其他情況之前，請假設為「同一世代」，但這尚未證實。

• 沒有論文，也沒有訓練資料聲明。沒有技術報告，README 也未描述訓練語料庫、其授權或來源稽核——這對任何發行商業音樂的人來說都是切身問題，因為封閉競爭對手的訓練資料立場已成為多年訴訟的主題。

• 沒有自架成本指引。 22 GB 的數字是記憶體，而非價格。尚未有人發布過這個模型在典型硬體上的每首歌 token 數或每小時生成吞吐量。

這對建構者為何重要

一個只有兩天的檢查點，除了實驗室之外還沒有人對它做過負載測試，而這正是具備自動故障轉移的路由發揮價值的時刻。路由層——就像 OrcaRouter 為 200 多個模型以供應商表價直接轉嫁方式運行的那種——讓你可以將測試路徑指向一個全新的開放權重模型，並在它停滯時回退到經過驗證的模型，而且不需要第二份合約，也不需要改任何程式碼。你可以把 MiniMax-Music3 這週當作實驗、下個月當作依賴，而底層管線在這兩種狀態之間不必有任何改變。

策略解讀更簡單。MiniMax 現在是少數同時為同一產品系列提供付費 API 與開放權重的音樂生成供應商之一。Suno 和 Udio 是封閉平台。Google 的 Lyria 3.5 是消費者應用程式的功能。如果開放檢查點在品質上接近 API 版本，那麼五分鐘長度、結構化文字描述控制，以及 22 GB 的部署佔用空間，使其成為可信賴的自架基礎——而這個類別在一週前還沒有可信賴的參與者。

接下來要看什麼

能把這個故事從「有趣的 repo」推向「持久的平台」的兩件事是：第一批獨立的聆聽測試（通常在開源音樂模型發布後幾天內就會出現），以及 diffusers 整合是否會合併——若合併，就能把 MiniMax-Music3 放進所有現有的 diffusers 音樂管線。另外也要留意論文、訓練資料聲明，以及託管 API 價格的任何變動——在直通路由器上，供應商降價當天就會生效，那一刻託管路線就會成為大多數團隊的明顯預設選擇。