改动一 · 输入侧

Music 3.0 把一句话换成一份分段说明书

既然病根是描述太粗，那就把描述做细。Music 3.0 不再用一个全局标签概括整首歌，改成一份按时间轴分段写清楚的结构化描述（Structured Caption），分三块：

这份说明书细到什么程度？官方 demo 页每首歌都附了完整描述，光英文就 700 多词。下面这段是其中一首都市灵魂乐的真实片段，还只是「人声细节」那一块的一部分：

Vocal Style: The delivery is marked by a conversational,
behind-the-beat phrasing... The bridge requires a dramatic
shift to a "whisper-singing" technique, utilizing heavy
vocal fry and breathy tail-offs to convey extreme proximity.

Harmony/Backing Vocals: The choruses are bolstered by tight,
three-part male harmony stacks... panned hard left and right
to envelop the lead.

注意它的形容词全都带着可执行的落点：说「气声呢喃」的同时交代了在桥段用、说「三层男声和声」的同时交代了硬声像左右分开。不是「感人」「高级」这种没法执行的空话。模型能照着做，是因为这份描述本身已经是一张施工单。

改动二 · 结构

歌词里的方括号是真的结构开关

说明书管住了每段的血肉，整首歌的骨架又由谁来定？答案在歌词那一侧。

歌词里写 [Intro]、[Verse]、[Pre-Chorus]、[Chorus]、[Post-Chorus]、[Bridge]、[Instrumental]、[Solo]、[Outro] 这类方括号标记，模型把它当结构指令执行，决定这首歌几段、什么顺序、哪儿留纯器乐，而不会把「Verse」两个字唱出来。这是使用者最容易搞错的地方：方括号是可执行的，歌词正文只传递情绪、不传递结构。你想让歌从主歌转到桥段再回副歌，自己在歌词里排。

配套

官方还开源了 1000 个模板和一个扩写技能

但普通人写不出 700 词的专业说明书，这正是这套输入格式的门槛所在。官方的解法是配一个扩写系统：你写一句大白话，它用专业音乐术语给你扩成完整说明书。

这个「模板库」不是个抽象说法，它就摆在 GitHub 仓库里：1000 个纯文本模板文件，按 18 个流派家族分类，民谣、EDM、嘻哈、爵士、金属、灵魂福音、东亚抒情、乡村美国风等等。扩写逻辑本身也做成了一个 Agent 技能开源，一行命令装：

npx skills add MiniMax-AI/MiniMax-Music3 --skill music-caption-rewriter

它的检索方式做过 Agent 的人会眼熟：技能里明令禁止扫全部 1000 个模板，也禁止建数据库、算向量、调外部 API。它走的是一层层收窄，先读一张流派路由表，定位到一两个家族；再看家族索引里的简卡对比；最后只完整读取选中的最多 3 个模板，而且三个各司其职：

对不打算装模型、只是想把提示词写好的人来说，这 1000 个模板本身就是一份能直接抄的编曲提示词资料库。

机制 · 核心

两个模型分工：一个记整首，一个只管一帧

输入侧的两件事都说完了，模型内部又凭什么撑得住五分钟？先得知道声音在模型里是怎么存的。

音频没法直接喂给语言模型，得先切成一格一格的音频帧（这里是每秒 25 帧），每一帧再用 8 层码本编码（官方叫残差矢量量化，RVQ）：第 1 层用一本 16384 个码字的大字典，只管这一帧的核心语义和结构，什么和弦、什么段落、唱的什么字；第 2 到 8 层各用 1024 个码字的小字典，一层层往上叠声音的细节残差，音色、泛音、空间感。

两个模型，一个记得住整首，一个只管眼前这一帧

知道了声音怎么分层，分工就顺理成章了：

为什么要这么分？让一个 80 亿参数的大模型同时操心整首歌的走向和每一帧的泛音细节，既浪费又容易乱，它的注意力被拉扯在两个尺度上。把细节甩给一个 6 亿参数的小模型逐帧补，大模型就能专心记住五分钟前发生了什么。长距离的稳定性和局部的丰富度，这样才能同时保住。

MiniMax Music 3.0 官方架构图。自下而上四层：最底是输入（左边紫框 Structured Caption，右边绿框歌词）；往上是 Hybrid LM，深蓝色横条就是全局模型，它每帧吐出的隐状态往上走，经 C₀ 进局部模型，再逐层输出 C₁ 到 C₇；再往上两个 fusion 箭头把隐状态送进 Synthesis 层，经 Flow-Matching 和 Flow VAE Decoder 出音频。右侧红圆是停止标记，灰方块是隐状态。图片来源：MiniMax 官方发布博客。

机制 · 音质

最后一步跳过压缩，换气和余韵才留得住

但真正决定这首歌好不好听的，是最后这一步，而它最容易被跳过。

常规做法是：语言模型吐出一串离散码字，解码器照着码字还原成声音。问题出在「码字」这两个字上，码字是量化过的。本来连续的声波被压进有限的几个格子里，中间那些微妙的东西（换气、滑音、弦震完之后的余韵）在量化那一刻就丢了，后面再怎么解码也捞不回来。

Music 3.0 的做法是：推理的时候根本不加载那个离散解码器。它把两个语言模型最后一层的连续隐状态（hidden state），也就是还没被压成码字的原始高维信息，融合起来，直接送进一个 24 亿参数的 flow matching 模块，再由一个 1.23 亿参数的 Flow-VAE 解码成波形。

Flow-VAE 不是从头造的，架构从 MiniMax 自家的语音模型 MiniMax Speech 那边搬过来，按音乐的动态范围和频谱特点重训了一遍。

效果

16 段官方样曲，从上海爵士到福音金属

机制都讲完了，剩下的效果只能自己听。这也是这次发布唯一的证据，没有跑分，没有对比实验，就是 16 段样曲。下面这个试听台可以点风格标签换曲子，每首都附了它的真实输入描述，能直观看到「同一套模型，输入换一个，出来的东西完全不同」：

最后那首的输入指名要「50 到 70 岁的成熟父母辈嗓音、带台湾腔、不要年轻明亮的音色」。这种细到年龄段和口音的要求能不能兑现，正是「结构化描述」这套输入格式有没有用的实测。

其余七首

官方博客共放出 16 段音频，其中第 2 段与第 11 段的输入描述和歌词完全相同，实际不重复的是 15 首，本站已去重。全部音频直链自 MiniMax 官方 CDN。

许可证

年营收 2000 万美元以下，商用免授权

听着不错，我能不能拿去用？这次发布把「开源」写进了标题，可博客正文从头到尾没有一句涉及许可证，所以这一节的内容全部来自协议本文。

它叫 MiniMax-Music3 社区许可证，全文 7400 字节，开头那段措辞几乎照抄 MIT 许可证：免费使用、可以改、可以再分发、可以商用。附加条件只有四条：

对绝大多数个人创作者和中小团队来说，这四条里真正要动手的只有第一条：在界面上标一句模型名。

没有地域排除条款

同一家公司十天前刚发过一份完全不一样的协议。

协议末尾还写清了这个模型的血统：全局模型微调自 Qwen3-8B（Apache 2.0 协议），扩散部分改自 Stability AI 的 stable-audio-tools（MIT 协议），VAE 改自 Descript 的音频编解码器 DAC（MIT 协议）。

上手

8GB 显存能跑，但官方自己列了五条限制

既然许可证放行了，那机器这一关呢？这部分博客同样没写，全在模型卡里。

显存三档（说的是单卡这条路）

先说清楚这三档对应哪条路：用 diffusers 在一张卡上跑的情况。官方推荐的那条服务化路径要求不一样，下一段单说。

ComfyUI 那边另外提供了 INT8 量化版本的模型文件，专门给小显存的卡用，生成长曲子时还可以打开分块解码，把显存占用再压一截。

另外，HuggingFace 的模型页上已经挂着社区做好的 3 个微调版和 4 个量化版，不想自己转格式可以直接下现成的。

三条部署路子

官方自己写的五条限制

这份清单是厂商自己列的，含金量比任何效果描述都高：

最后这条把前面所有讨论都拉回地面：这套结构化描述让「说了算数」的概率高了很多，但它仍然是概率，不是把谱子输进音源库那种确定性执行。

两个模型分工：一个记整首，一个管一帧

声音先按每秒 25 帧切开，每帧再编成 8 层码本，第一层管骨架，其余 7 层管音色细节。这些帧顺次交给两个不同大小的模型处理。

跳过压缩这一步，换气和滑音才留得住

决定好不好听的是最后一步，而它最容易被压缩掉。

8GB 显存能跑，但模型卡自己写了限制

权重直接开源，显存门槛不算高，商用条件也宽，这次发布的边界，都写在 MiniMax 自己的模型卡里。