YuE2-3B:把乐谱做成接口的开源歌曲生成模型
yue2
m-a-p 的开源歌曲生成模型,3B 参数,权重 CC-BY-NC-4.0,歌词加风格 prompt 直出带人声与伴奏的 48kHz 立体声完整歌曲。本站把它列为音频域音乐方向的开放权重梯顶,依据是同代开源模型里几乎唯一的组合:开放权重加可编辑的中间表示。一条 AR-NAR Mixture-of-Transformers 主干先写 ABC 记谱(旋律与和弦)与语义 token,再用 flow matching 生成声学 latent、VAE 解码,所以乐谱是能被人和 agent 读改的产物,而不是只能重抽的黑箱;三档 cot(full / melody / off)分别对应作曲、翻唱与直出,官方 agent 编辑 demo 是 9 步 14 版把中文流行改成英文爵士。跑分口径要读准:WildSongBench 192 条 prompt 上 best-of-8 的 SongBench 均分 6.9632 高于 Suno v5 的 6.8721 与 v6 的 6.5562,但那是 8 候选选优对单次交付;MuLan 与 AllMusicCaps 两项风格文本对齐仍输给 Suno v5,PER 8.44% 也落后于 Suno v6 Wild 的 7.45% 与 MiniMax Music 3 的 6.27%。成本是它最实的优势:RTX 4090 24GB 上一首 3.6 分钟的歌 71 秒生成、峰值 11.18GiB,H800 加 vLLM 并发 32 达 373 首每小时。边界:非商业许可;翻唱的身份保持几乎全靠外部乐谱(不给谱 CLEWS mAP 塌到 0.006);跑分用 legacy VAE 而默认发的是新 VAE;技术报告未出、盲听榜尚无结果。置信度 C(厂商宣称),本站未复算。
- 置信度
- 厂商宣称
- 只有官方模型卡/发布会,无独立复测
- 关键指标
- WildSongBench SongBench 均分(best-of-8)
- 厂商宣称 · 2026-09
- 成熟度
- 研究
- 研究 → 演示 → 产品 → 生产
我们的判断我们给它 C 档(厂商宣称)。WildSongBench 这套基准、192 条 prompt、九项指标的协议说明与全精度 CSV 都公开发布,透明度远高于一般厂商稿,这是它比同档条目更可信的地方;但基准由模型作者自己运营、跑分由作者自己提交,本站没有复算过任何一个数字,也没有做过盲听,所以按契约 §13.5 不能升成 A。best-of-8 与 Suno 的单次交付是不同口径这一点,官方写在协议里,我们照原样转述,不替它抹平。
它值得进音频域梯顶的理由不是「跑分第一」,而是开放权重 + 可编辑中间表示这个组合在音乐生成里几乎是唯一的。Suno、Eleven Music、MiniMax Music 都是服务:你能改的只有 prompt 与分段,想换一段和声只能重抽。YuE2 把 ABC 乐谱暴露成产物,于是「重新配和声」「把中文流行改成英文爵士」「让 solo 引用一段既有旋律」这些需求第一次变成可版本化的编辑操作,而不是抽卡。官方那条 9 步 14 版的 agent 编辑链是这条路线最有说服力的证据 —— agent 能改乐谱,意味着音乐生成第一次接得上本站 harness 域里那套「读产物、改产物、再渲染」的工作流。加上单卡 24GB / 71 秒出一首 3.6 分钟的歌,自托管成本落在个人工作站量级,这是闭源服务给不了的。
选型时要认清三条硬边界。许可是 CC-BY-NC-4.0,非商业;任何商用产品要么谈授权要么换服务,这条不能靠「跑分高」绕过去。翻唱依赖外部乐谱:不给谱时身份保持指标塌到 0.006 mAP,所以「AI 翻唱」这条产品线的真实前置条件是一套能用的转写链路(SheetSage2 + ASR 取词),而不是模型本身。咬字仍是短板,PER 8.44% 落后于 Suno v6 Wild 的 7.45% 与 MiniMax Music 3 的 6.27%,歌词密集的段落要先试听再上生产。另外注意跑分口径:6.9632 出自 YuE2-Vae-legacy,默认发的 YuE2-Vae 听感更好但基准分更低,复现跑分与本机试听听到的不是同一个解码器。技术报告未出、训练数据无从核验,这两条我们与「盲听榜尚无结果」一并计进 C 档。
它解决的问题:让音乐生成的中间态变成可编辑的乐谱
YuE2-3B 是 multimodal-art-projection(m-a-p)的开源歌曲生成模型,给歌词与风格 prompt,直接出带人声与伴奏的完整歌曲,48kHz 立体声,权重以 CC-BY-NC-4.0 公开。它与本站已收的音乐模型最大的区别不在音质,而在中间表示:同一条 AR-NAR 主干先写出 ABC 记谱(旋律 + 和弦)与语义 token,再由 flow matching 生成声学 latent,最后过 VAE 解码成音频。乐谱因此是一个能被人读、被人改、被 agent 改的接口,而不是一个只能重新抽卡的黑箱。
这一设计直接决定了它的三种用法:cot="full"(旋律 + 和弦规划,默认)、cot="melody"(只规划旋律,官方推荐用于翻唱)、cot="off"(不生成符号规划直接出音频)。还能传入自己的 ABC,或用 pipe.plan() 只拿规划、改完再 generate_semantic() → synthesize() → decode() 分阶段跑。
WildSongBench:赢在哪几把尺子上,又输在哪几把
官方在 192 条 WildSongBench prompt 上与 17 个设置对比(2026-09-12 版),SongBench 平均分是主指标:
| 模型 | 开放 | Musicality ↑ | SongBench Avg ↑ | MuLan ↑ | AllMusicCaps ↑ | Q3O ↑ | PER ↓ |
|---|---|---|---|---|---|---|---|
| YuE2 (best-of-8) | 是 | 6.2666 | 6.9632 | 0.5051 | 0.3980 | 4.7009 | 9.79% |
| YuE2(两候选取低 PER) | 是 | 5.9075 | 6.7316 | 0.5068 | 0.4054 | 4.6819 | 8.44% |
| Suno v5 | 否 | 5.9918 | 6.8721 | 0.5428 | 0.4353 | 4.5907 | 8.10% |
| Suno v6 / v6 Wild | 否 | 5.6558 / 5.5644 | 6.5562 / 6.4195 | 0.4916 / 0.4999 | 0.4305 / 0.4316 | 4.6258 / 4.5898 | 7.58% / 7.45% |
| Mureka 9 | 否 | 6.0488 | 6.9377 | 0.4394 | 0.4102 | 4.6368 | 11.69% |
| LeVo 2 / ACE-Step 1.5(开源同代) | 是 | 5.4590 / 5.1588 | 6.3247 / 6.0118 | 0.3542 / 0.4372 | 0.2680 / 0.3869 | 3.9458 / 4.5809 | 26.12% / 7.46% |
要读准三件事。一,best-of-8 是抽 8 个候选再按 Musicality → Q3O → PER 选优,不是单次生成质量;与 Suno 的单次交付比,这是不同口径,官方在协议里写明了,但选型时不能把它当成「同样算力下赢 Suno」。二,它并没有赢下所有尺子:MuLan 与 AllMusicCaps 这两个量「音频与风格文本对齐」的指标上 Suno v5 明显更高(0.5428 / 0.4353 对 0.5051 / 0.3980),YuE2 的优势集中在 Musicality、SongBench 综合分与 Q3O(prompt 遵循)。三,PER 8.44%~9.79% 不是这批模型里最低的,Suno v6 Wild 是 7.45%,MiniMax Music 3 低到 6.27% —— 咬字清晰度仍然是开放模型的短板。
翻唱那一组(SHS100K,948 首 × 2 风格 × 2 seed = 每法 3792 首)更能说明符号规划的作用:YuE2 带完整乐谱时 CLEWS mAP 0.647 / Hit@1 71.3%,去掉和弦降到 0.598 / 67.3%,完全不给乐谱则塌到 0.006 / 0.3%,而同代开源 ACE-Step 1.5 只有 0.024。也就是说「保住原曲身份」这件事几乎全部由外部传入的乐谱承担(由 SheetSage2 转写得来),模型本身不做音频到身份的隐式记忆。这既是能力也是边界:你有谱才翻得了。
速度与显存:单卡 24GB 能跑,这是它与闭源服务最实的差别
| 配置 | 模式 | LM tokens/s | 生成 / 出音频 | 峰值显存 |
|---|---|---|---|---|
| RTX 4090 24GB(HF 包,PyTorch + CUDA graphs + FlashAttention) | full | 139.48 | 71.04s / 214.85s(3.6 分钟歌) | 11.18 GiB |
| RTX 4090 24GB | off | 121.07 | 57.91s / 196.88s | 11.09 GiB |
| H800 80GB + vLLM 0.19,AR 并发 16 | full | 2418.63 | 340.38 首/小时 | 78.66 GiB |
| H800 80GB + vLLM 0.19,AR 并发 32 | full | 3231.74 | 373.53 首/小时 | 76.61 GiB |
门槛写得很直白:Linux、Python 3.10+、24GB NVIDIA GPU(需 BF16)、24GB 可用主机内存,不量化;最大上下文测试峰值 14.08 GiB,一次一首。服务端那一档是独立的 vLLM 运行时,373 首/小时是热态批吞吐,不是单请求延迟,两个数字别混着读。
agent 编辑:官方 demo 是一条 9 步 14 版的修改链
官方把「用 agent 改歌」做成了一等公民:The Last Train 从中文流行一路改到英文爵士,加现代和声与萨克斯 solo,并让 solo 围绕两遍完整的《小星星》展开 —— 9 个回合、14 个版本,每一步的对话、乐谱、prompt、歌词与成品音频都公开可听。工程含义是:agent 拿到的不是「再生成一次」的按钮,而是 score.abc + 原 prompt + 歌词这三样可读可改的产物,再交给 YuE2 渲染。严格重新配和声时官方要求 agent 保持旋律音高与节奏不变,并把长音逐个对到新和弦上检查。
边界:许可、VAE 口径与尚未发布的技术报告
- CC-BY-NC-4.0 是非商业许可。跑分再高也不能直接用在商用产品里;要商用得单独谈授权,或者选 Suno / Eleven Music 这类付费即授权的服务。这是它与本站音频域里所有闭源条目最硬的一条区别。
- 跑分用的是 YuE2-Vae-legacy,默认发的是 YuE2-Vae。官方说明:legacy 在基准上 musicality 更高,新版听感更好。所以表里的 6.9632 与你在本机默认配置下听到的东西不是同一个解码器,复现跑分必须显式传
vae="m-a-p/YuE2-Vae-legacy"。 - 技术报告尚未发布,官方让引用前代 YuE(arXiv 2503.08638)。训练数据构成、数据规模、后训练细节目前无从核验。
- 盲听榜仍在收集:Music Arena 是与闭源模型并排的匿名偏好投票,尚无结果;自动指标与人耳偏好在音乐上历来分歧不小,这一票没出来之前,「超过 Suno」只是基准口径的说法。