AI 音乐生成这两年热度一直很高，但多数开源模型的成品停留在"片段"级别：一段 30 秒的旋律、几句清唱，或者一首结构散乱的 demo。能生成完整歌曲、有前奏有副歌有间奏、人声和编曲都像样的开源方案，少之又少。想要一首能直接用的歌，通常还是得依赖 Suno、Udio 这类闭源服务。
MiniMax 在 8 月放出的 Music 3 把这条线往前推了一大截。它支持生成最长 5 分钟的完整歌曲，输入歌词和音乐描述，就能得到结构完整、人声有表现力、编曲层层推进的成品。架构上用了 8B 全局模型加 0.6B 局部模型的分层设计，配合 Flow Matching 连续合成，输出 32kHz 立体声。更难得的是，官方给出了 8GB 显存就能跑的本地部署方案，SGLang-Omni、diffusers、ComfyUI 三个生态都支持。
MiniMax 在音乐生成这条赛道上已经迭代了多个版本。今年 4 月发布的 Music 2.6 主打国风曲目的"呼吸感"，把二胡颤音、笛子停顿、古筝扫弦这些演奏细节做进了模型。Music 3 则把重心转向整曲结构和开放权重——这次不只是 API，模型权重完整开放，开发者可以搬回自己的机器上跑。从"能用 API 调"到"能本地部署"，这个转变对创作者和开发者来说意义完全不同。
五分钟完整歌曲
先明确一个概念：Music 3 生成的是"整首歌"，不是"一段音乐"。官方演示里，它可以生成包含前奏、主歌、预副歌、副歌、桥段、间奏、尾奏的完整结构，时长最长 5 分钟。模型在长序列上维持音乐主题、节奏、人声特性和编曲推进的一致性，而不是前后风格割裂的片段拼接。
这个能力对内容创作者的意义很直接。短视频配乐、游戏场景音乐、播客片头、虚拟偶像的原创曲目，以前要么用素材库剪辑，要么请人作曲。现在输入歌词和风格描述，几分钟就能拿到一首结构完整的歌，不满意可以改描述重新生成。
音乐生成的难度在长程一致性上体现得最明显。30 秒的片段可以靠局部采样糊弄过去，但 5 分钟的歌，副歌旋律要重复得有变化，桥段的情绪要铺垫到位，尾奏要收得住。Music 3 用 8B 全局模型专门建模这种长程结构，这是它和"片段生成器"的本质区别。
歌词是生成的核心输入之一。Music 3 支持在歌词里直接标注段落结构——[Intro]、[Verse]、[Chorus]、[Bridge]、[Outro] 这些标签写在对应歌词行前面，模型就会按标签安排歌曲段落。想要先安静铺垫再爆发，把 [Pre-Chorus] 和 [Chorus] 标签用好，编曲的张力就能出来。
官方给的参考示例很直观：一段"[Verse] 晨光穿过松林 / 每一条安静的街道都属于你和我 / [Chorus] 世界开始轻柔地呼吸"的歌词，配上一句"温暖的声学流行歌、亲密的女声、指弹吉他"的描述，生成的就是一首结构完整、情绪递进的成品。歌词段落标签加音乐描述，就是 Music 3 的全部控制入口。
双 LLM 分层架构
Music 3 的架构和常见的单一大模型音乐生成器不同，它把"全局结构"和"局部细节"拆给两个模型各管一段。
全局模型（Global LLM）有 8B 参数，初始化自 Qwen3-8B。它逐帧预测音乐 token 的第一层语义码本，负责整首歌的长程结构和语义推进——调性、节奏、段落走向这些"大局"归它管。局部模型（Local LLM）只有 0.6B 参数，负责每一帧内剩余的声学码本，把人声的细微质感、乐器的纹理细节这些"局部"补全。
为什么拆成两个而不是合并成一个？因为音乐生成的信息密度不均匀。全局结构变化慢，用大模型建模能保证旋律、和声、节奏的长期一致性；声学细节变化快但模式相对固定，小模型就够用，还能省下大量推理成本。这种"大模型管大局、小模型管细节"的分工，是 Music 3 在质量和速度之间找到的平衡点。
训练分两步走：先把全局模型的 embedding 和输出层适配到音乐语义 token 上，然后两个模型联合训练，共同建模全部 8 层 RVQ 码本。这种分层设计的好处是，结构建模用大模型保证质量，细节建模用小模型控制成本，参数花在刀刃上。
音乐 tokenizer 用的是 8 层残差向量量化（RVQ）：第一层语义码本有 16,384 个条目，承载核心音乐语义；剩下 7 层声学码本各有 1,024 个条目，表示残差声学细节。训练时先优化语义码本，再联合训练全部 8 层。tokenizer 是训练时的中间产物，推理时合成波形走的是连续隐藏状态路径，并不依赖离散 token 解码器。
Music 3 分层架构：8B Global LLM 建模长程结构，0.6B Local LLM 补全声学细节，Flow Matching 融合连续隐藏状态合成波形
连续隐藏状态合成
Music 3 在从 token 到波形这一步做了个与众不同的选择：不用离散 token 直接解码，而是把两个 LLM 的最终隐藏状态融合起来，用连续表示去合成音频。
合成路径是这样的：Global 和 Local LLM 的隐藏状态先做融合，送入 2.4B 参数的 Flow Matching 模块，生成 Flow-VAE 的连续潜变量，再由 123M 参数的 Flow-VAE 解码器还原成 32kHz 立体声音频。Flow-VAE 的架构改编自 MiniMax Speech，针对音乐的动态范围和频谱特性重新训练过。
为什么要用连续隐藏状态而不是离散 token？离散 RVQ token 在量化过程中会丢信息，而 LLM 的连续隐藏状态保留了更丰富的声学信息——人声的发音细节、乐器的纹理、时序的连续性都在里面。融合隐藏状态做合成，理论上能比纯 token 解码还原出更细腻的声音。这也是 Music 3 声称"富有表现力的人声"的技术底气。
这套"离散建模 + 连续合成"的组合在音频生成里越来越常见。离散 token 的好处是适合语言模型自回归建模，结构性强；连续表示的好处是声学保真度高，细节损失少。Music 3 把两者串起来：结构用离散 token 建模，音质用连续状态还原，各取所长。它输出的 32kHz 16-bit 立体声 WAV 也是成品级格式，不是随便丢个低码率文件。
歌词与描述的精细控制
Music 3 接受两个互补的输入：歌词和音乐描述。歌词定义唱什么，音乐描述定义怎么唱、用什么乐器、什么风格。
官方推荐的描述格式是 Structured Caption，分三部分。Global Metadata 写全局信息：曲风、子流派、BPM、调性、音阶、情绪走向、收听场景、制作风格。Vocal Details 写人声细节：性别、音色、演唱风格、和声、伴唱、人声效果。Arrangement 写编曲：主奏和副奏乐器、各段落乐器演进、律动、贝斯、打击乐、织体、空间效果。三段写清楚，模型不仅能跟随整体风格，还能跟随歌曲随时间的发展。
描述写详细了效果确实不一样。比如"一首温暖的声学流行歌，亲密的女声，指弹吉他和轻柔钢琴，逐渐推进到宽广的最终副歌"，比干巴巴一句"流行歌"可控性强得多。仓库还附带了一个 music-caption-rewriter 技能，可以把一句简短描述自动扩写成完整的 Structured Caption，省去手写三段式结构的功夫。
这个技能本身就是个有意思的细节：MiniMax 把"写描述"这件事也做成了可复用的工程能力，说明他们清楚 prompt 质量对音乐生成效果的影响有多大。一段三部分的 Structured Caption，比一段自由文本能传达的信息密度高一个量级。
本地部署与三端支持
Music 3 的部署路径比预期友好。最轻量的方式是 diffusers 的 ModularPipeline，全精度推理 24GB 显存内可跑；开 CPU 自动卸载大约 22GB；再叠加分层流式卸载，8GB 显存的显卡也能跑起来，代价是速度慢一些。对个人创作者来说，一张消费级显卡就能把整首歌的生成搬回家，不用再按生成次数付费。
生产环境可以用 SGLang-Omni 提供服务，走 OpenAI 兼容的音频接口。服务需要两张 CUDA GPU：一张跑 Qwen3 和 8 层 RVQ 自回归生成，另一张跑 Flow Matching 和波形解码。ComfyUI 用户也有官方工作流，节点化操作，不需要写代码。
生成接口是标准的文本转语音格式：歌词放 input 字段，音乐描述放 instructions 字段，response_format 指定 wav，max_new_tokens 控制音频帧数（每秒 25 帧），模型在合适位置会输出音频结束 token 提前收尾。整个流程对用过 OpenAI 音频接口的开发者来说几乎没有学习成本。官方还提供了完整的可复现示例，从歌词、描述到生成参数一应俱全，照着跑就能得到参考音频。
限制要提前说清楚：目前只支持非流式生成，文本 prompt 上限 5000 token，音频生成上限 9000 个声学帧（约 6 分钟）。段落标签和音乐描述提供的是"生成控制"而非"严格保证"——生成结果的 BPM、调性、乐器、歌词、结构不一定每条都精确匹配描述，可能需要多次生成挑效果好的。
开源生态与许可
模型权重已经在 HuggingFace 和 ModelScope 放出，GitHub 仓库提供推理代码。许可用的是 MiniMax-Music3 Community License，这里要特别提醒：网上有些报道说它是 Apache 2.0，实际 LICENSE 文件是自定义社区许可。商用条款包括：使用该模型的产品界面需要显示"MiniMax-Music3"字样；如果你的产品和服务年营收合计超过 2000 万美元，需要联系 MiniMax 获取书面授权。个人使用、学习研究、年营收门槛内的商用都没有问题，但超过门槛的团队要提前规划。
生态集成方面，diffusers 官方管线已经可用（PR 合并前需从指定 commit 安装），SGLang-Omni 支持服务化部署，ComfyUI 官方教程也上线了。三个入口覆盖了从研究调试到生产服务的完整链路。官方 Demo 页面还按人声、编曲、地域风格分了类，中国风、国风流行、民谣这些细分类型都有示范音频，可以直观感受模型的音色和编曲水平。
总结与展望
MiniMax Music 3 的定位很清楚：把 AI 音乐生成从"生成片段"推进到"生成完整作品"。分层 LLM 架构解决长程结构问题，连续隐藏状态合成解决音质问题，Structured Caption 解决可控性问题，三件事凑齐，5 分钟整曲才真正成为可用的产品能力。
局限也要坦诚说。段落标签不是严格保证，复杂编曲指令可能执行不到位；长音频生成的稳定性还需要更多社区验证；8GB 显存方案是"能跑"而不是"跑得快"，实时交互场景还有距离。另外社区许可的 2000 万美元营收门槛，对创业团队是个需要留意的边界。和主流的 Suno、Udio 相比，Music 3 没有官方公布的盲测对比数据，具体听感如何，建议去官方 Demo 页面听完示范音频再下判断——人声质感、编曲丰富度、结构完整度这几个维度，耳朵最诚实。
但方向已经很明确：当开源模型能生成完整歌曲、本地可部署、细节可控时，音乐创作的生产力工具格局会被重写。接下来值得关注的是多轨分离、人声编辑、流式生成这些方向——MiniMax 在这条赛道上的迭代速度，从 Music 2.6 到 Music 3 只隔了四个月。
获取方式
- • GitHub 代码仓库：https://github.com/MiniMax-AI/MiniMax-Music3
- • HuggingFace 模型：https://huggingface.co/MiniMaxAI/MiniMax-Music3
- • 官方 Demo：https://minimax-ai.github.io/music3-demo/
- • SGLang-Omni：https://github.com/sgl-project/sglang-omni