引言
"用符号作曲，用声音创作。"（Compose in symbols. Create in sound.）
这是「每日一个开源项目」系列的第 241 篇。今天的项目是 YuE2 —— 一个统一符号音乐生成与音频音乐生成的开源基础模型，由香港科技大学（HKUST）、M·A·P、Tokenwave.AI、NYU、Stanford、MBZUAI、NOIZ、ACE Studio 等多个机构联合研发，12,280 颗 Star，GitHub Trending 日榜第一，Hugging Face 全站趋势榜最高第 3 名，Text-to-Audio 分类趋势榜第 1 名。
市面上大多数 AI 音乐生成工具是"黑盒"：你给一句风格描述和一段歌词，它直接吐出一段音频，中间发生了什么、能不能改、改哪里，用户完全看不见也碰不着。YuE2 的核心主张恰恰相反——先生成一份人类和 Agent 都能读懂、能检查、能修改的旋律和弦乐谱（符号化的"作曲计划"），再把这份乐谱渲染成完整的歌曲音频。这意味着音乐生成第一次有了一个可以被插手干预的"中间产物"，而不是一次性的端到端黑箱输出。
你会学到什么
- "符号规划 + 音频渲染"两段式架构：为什么先生成乐谱再渲染音频,而不是直接端到端生成波形
- 零样本翻唱（Zero-shot Cover）是如何在不针对翻唱场景单独微调的情况下实现的
- Agent Skill 驱动的多轮音乐编辑工作流：怎么通过对话修改和声、旋律、速度甚至整个乐段的编曲
- 快速上手：从一条 pip 命令到生成第一首歌
- 项目在 WildSongBench 基准上和 Suno v5/v6、Mureka 9 等商业系统的实测对比数据
前提知识
- 对 Python 环境管理（venv/pip）有基本经验
- 了解 ABC 记谱法或简单的乐理概念（旋律、和弦、调式）会更容易理解符号规划的产出,但不是必需
- 本地运行需要支持 BF16 的 NVIDIA GPU，建议了解基本的显存需求概念
项目背景
概述
YuE2 是 YuE 项目的第二代演进（第一代 YuE 的代码、文档和许可证仍保留在 YuE-v1 分支）。它用一个 AR-NAR 混合 Transformer（Mixture-of-Transformers）骨干网络，先以自回归（Autoregressive）方式预测乐谱和语义 Token，再用 Flow Matching 方式生成声学潜变量（Acoustic Latents），最后由 VAE 解码器输出立体声音频。这套架构同时支撑了三种场景：从零创作、翻唱已有歌曲、以及对已生成作品的迭代式编辑——三者唯一的区别只是"乐谱从哪来"（YuE2 自己生成 / 从录音转写得到 / 人工或 Agent 编辑过的版本）。
项目同时还发布/维护了多个配套模型：MERT2（音乐理解表征模型）、SheetSage2（音频转乐谱的转录模型）、以及用于评测的 WildSongBench 数据集——形成了一套相对完整的"理解-生成-评测"音乐 AI 工具链，而不是一个孤立的生成模型。
作者 / 团队
- 开发方: multimodal-art-projection (M·A·P) 组织，联合香港科技大学（HKUST）、Tokenwave.AI、纽约大学（NYU）、斯坦福大学（Stanford）、MBZUAI、NOIZ、ACE Studio 等多个机构
- 主要语言: Python
- 代码许可证: Apache 2.0；模型权重许可证: CC BY-NC 4.0（附加创作者权限条款）
- 创建时间: 2025-01-23
- 当前状态: 活跃开发中，2026 年 9-10 月密集发布 YuE2、SheetSage2 两份技术报告
项目数据
- ⭐ GitHub Stars: 12,280+
- 🍴 Forks: 1,409+
- 📄 许可证: 代码 Apache 2.0 / 模型权重 CC BY-NC 4.0 + 附加条款
- 📅 创建时间: 2025-01-23
- 🏆 2026 年 9 月 14 日 GitHub Trending 全语言日榜第一；Hugging Face 全站模型趋势榜最高第 3（9 月 17 日）；Text-to-Audio 分类趋势榜第 1（9 月 20 日）
- 👥 核心贡献者：a43992899（143 次提交）领衔，hf-lin（24 次）、Yiming-Liang、instr3 等多名贡献者
- 🏷️ Topics: audio-generation, foundation-models, music-generation, style-transfers, voice-cloning 等
快速上手
环境要求
Linux · Python 3.12 · 支持 BF16 的 NVIDIA GPU，24GB 显存。YuE2 直接输出 48kHz 立体声音频，不经过量化压缩。模型文件首次使用时会从 Hugging Face 自动下载。
命令行一键生成
git clone https://github.com/multimodal-art-projection/YuE.git
cd YuE
python3.12 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install .
python examples/generate.py --output outputs/first-song
打开 outputs/first-song/audio.flac 即可听到结果。输出目录里还会保留生成过程中的乐谱、语义 Token、声学潜变量、生成参数和所用的模型标识——这是"白盒"设计在产物层面的直接体现，每一步中间结果都被保留下来可供检查。
Python API
import json
from pathlib import Path
from yue2 import YuE2Pipeline
request = json.loads(Path("examples/song.json").read_text(encoding="utf-8"))
with YuE2Pipeline.from_pretrained("m-a-p/YuE2-3B", device="cuda") as pipe:
song = pipe(**request)
song.save_artifacts("outputs/my-song")
print(song.truncated)
生成管线暴露了四个阶段化的 API：plan() → generate_semantic() → synthesize() → decode()，每一步都可以单独调用、检查甚至替换。cot（Chain-of-Thought，这里特指符号规划）参数控制规划深度："full" 生成可编辑的旋律+和弦完整计划（新歌默认值）；"melody" 只生成旋律计划、伴奏自由发挥（翻唱推荐）；"off" 直接从歌词和风格描述端到端生成，跳过符号规划阶段。
核心剖析
符号规划：把"黑盒生成"变成"白盒可编辑"的关键一步
这是 YuE2 整个设计里最核心的理念。传统的端到端音乐生成模型（包括大多数商业产品）从歌词和风格描述直接跳到音频波形，中间过程不可见也不可控——想改一个音符，等于要重新生成整首歌,而且无法精确指定改哪个地方。YuE2 的做法是在"歌词+风格"和"最终音频"之间插入一个显式的中间产物：用 ABC 记谱法表示的旋律与和弦乐谱。
这份乐谱是真正意义上的"白盒接口"：人或 Agent 可以直接读取它、在编辑器里查看，甚至用音乐软件播放预览，确认整体结构和走向之后再决定是否渲染成音频。README 用一个具体的多轮编辑案例展示了这一点的威力——演示中的《The Last Train》经历了 9 个步骤、14 个版本的迭代，从中文流行乐一路改成带萨克斯独奏的英文爵士,每一个版本的对话记录、乐谱、提示词和歌词都完整保留可供回放对比。这种可追溯、可回放的编辑历史，在端到端黑盒模型上是结构性不可能实现的。
零样本翻唱：不用专门微调,照样能把一首歌改头换面
翻唱（Cover）场景通常需要针对性的微调才能做好，但 YuE2 给出的方案是复用同一个通用生成模型，不做翻唱专项微调。具体流程是：先用配套的 SheetSage2 转录模型把源录音转成旋律 ABC 乐谱,审阅、修改之后,配上新歌词或目标风格,用 cot="melody" 模式（且乐谱里不带和弦符号,留给伴奏自由适配新风格）重新生成。
项目给出的量化结果很有说服力：在 948 首作品上测试，带完整乐谱的 YuE2 翻唱达到 0.647 CLEWS mAP（衡量翻唱是否保留了源曲身份特征的指标），而不提供乐谱直接生成的对照组只有 0.006——差距接近两个数量级。这组数据同时也说明了符号规划层本身的价值：不是"模型更大所以翻唱更准"，而是"有没有显式乐谱约束"这件事本身决定了翻唱是否成功。
Agent Skill：让对话式编辑成为音乐创作的默认工作流,而不是花活
YuE2 提供了一个专门的 yue2-music Agent Skill，教会 Agent 如何生成歌曲和纯音乐、转录和翻唱录音、编辑 ABC 乐谱、检查音乐性不变量（比如编辑后旋律音高、起始时间是否被意外破坏）以及组织听感对比。README 明确推荐搭配 GPT-6 Astra 作为执行 Agent，但强调 YuE2 本身仍然承担谱曲和音频生成的核心工作——Skill 只是把"调用 YuE2 的正确方式"打包给 Agent，而不是替代 YuE2 的生成能力。
一个值得注意的细节是纯音乐（Instrumental）工作流的具体实现：默认流程是"YuE2 生成完整乐谱 → 把人声声部的音符挪到器乐声部 → 渲染"，而不是单独训练一个"纯音乐模型"。音频翻唱转纯音乐时，辅助工具会在转换乐谱时保留原始人声音符的音高、起始时间和持续时长，并记录声部重叠的部分——但 README 也坦诚地指出，这一步之后仍然需要人工听感检查，确认没有人声"漏音"、旋律保真度是否足够，没有把这个环节包装成全自动零风险的黑箱。这种"工具只能做到这一步，剩下交给人耳判断"的边界说明，是比空泛宣传更可信的工程态度。
跟商业系统摆在同一张表里对比：诚实到会标注"差距可能不显著"
YuE2 没有回避和 Suno、Mureka 等头部商业系统的直接对比，在 WildSongBench（192 条提示词、全自动评测）上给出了一张完整的排行表：
| 系统 / 配置 | SongBench 均分 ↑ | PER（音高错误率）↓ |
|---|---|---|
| YuE2 (best-of-8) | 6.9632 | 9.79% |
| Mureka 9 | 6.9377 | 11.69% |
| Suno v5 | 6.8721 | 8.10% |
| YuE2 | 6.7316 | 8.44% |
| Suno v5.5 / v4.5 / v6 | 6.56 ~ 6.72 | 5.80% ~ 7.58% |
| YuE 1（上一代） | 4.9165 | 36.38% |
YuE2（best-of-8，即从 8 个候选里挑最优）在这套评测里拿到了 17 个评测配置中最高的 SongBench 均分，而标准单次生成的 YuE2 也排在 Suno v5 之后、Mureka 9 之前的第四位。但紧接着的说明值得注意：README 直接写道"排名因指标而异，最高几个均分之间的微小差距并不构成统计显著性"——没有因为自己拿到了榜首就回避这一点,这种在自己最漂亮的数据旁边主动标注"别太当真"的做法,比单纯晒排名第一要诚实得多。相比第一代 YuE（SongBench 均分仅 4.9165），这一代在不到两年内的进步幅度也相当可观。
项目地址与资源
- 🌟 GitHub: multimodal-art-projection/YuE
- 📄 技术报告: YuE2 arXiv / SheetSage2 arXiv
- 🎧 在线演示与试听: map-yue2.github.io
- 🚀 免费在线体验: yue.noizai.net（NOIZ 托管，无需安装）
- 🗳️ 盲听投票竞技场: Music Arena
- 🤗 模型: YuE2-3B / MERT2 / SheetSage2
- 📊 评测数据集: WildSongBench
- 🎛️ 生态集成: ComfyUI 官方工作流、NOIZ 的推理加速套件 YuE2-Turbo、Maestro 本地创作工具
- 💬 社区: Discord
总结
YuE2 回答了一个 AI 音乐生成领域长期被忽视的问题：生成质量追上商业系统固然重要，但如果创作过程始终是一次性的黑箱输出,用户永远只能"重新抽卡"而不能"精确修改",这件事本身就限制了 AI 音乐工具真正进入专业创作流程的可能性。
三点值得注意：
把符号乐谱作为显式的中间产物，是这个项目区别于大多数端到端音乐生成模型最本质的设计选择。 这不只是一个技术细节，而是直接决定了"音乐生成"能不能从一次性抽卡升级为可迭代、可追溯的创作过程——9 步 14 版本的编辑演示证明了这件事在实践中是可行的，而不只是理论上好听的说法。
零样本翻唱 0.647 对 0.006 的量化对比，证明了符号规划层的价值不是锦上添花,而是决定性的。 很多项目在介绍架构创新时很难给出一个干净的、能证明"这个设计选择真的有用"的对照实验，YuE2 用近两个数量级的差距回答了这个问题。
在自己拿到评测榜首的同一张表格旁边主动标注"差距可能没有统计显著性"，以及对纯音乐转换环节"仍需人工听感复核"的坦诚说明，体现了一种少见的工程克制。 这种自我约束在强调打榜数据的 AI 生成模型项目里并不多见，也是判断一个项目的实测数据是否可信的重要信号。
如果你对"AI 生成的音乐能不能像代码一样被检查、被修改、被版本化"这个问题感兴趣，或者想找一个真正支持编辑而非一次性生成的开源音乐模型，YuE2 的符号规划架构和配套的 Agent Skill 工作流值得认真体验一下。
探索 PrimeSkills —— 精选 AI agent 和技能工具，每一个都经过真实工作流验证。没有炒作，只有真正好用的工具。
访问我的个人主页，获取更多见解和有趣的产品。
