ComfyUI-Olm-YuE2：分阶段可控的AI音乐生成工作流

近期，音乐生成模型 YuE2 正式发布，为 AI 音乐创作带来了新的可能。开发者 o-l-l-i 基于此打造了一个名为 ComfyUI-Olm-YuE2 的自定义节点集，将 YuE2 深度集成进 ComfyUI 工作流。与市面上大多数「一键生成」的封装不同，这个项目刻意暴露了 YuE2 内部更多的中间环节，让创作者能够真正理解并干预音乐生成的每一步。

从「一键生成」到分阶段可控生成

作者在 Reddit 上的分享中坦言，最初只是想让 YuE2 在 ComfyUI 里「正常跑起来」，结果一头扎进去花了远超预期的时间。这份「超额投入」的成果，就是一个远比简单封装更有深度的集成方案。

当然，基础用法依然简单直接：你只需提供一个音乐风格描述和歌词，就能生成一首 48 kHz 立体声歌曲。但真正让这个项目脱颖而出的，是它把生成流程拆分成了四个清晰的阶段：

Plan（规划）→ Semantic（语义）→ Synthesize（合成）→ Decode（解码）

每一个阶段的中间结果都可以被检查、保存、复用乃至分支。这意味着你不再是把歌词丢进黑盒等结果，而是可以在 ComfyUI 标准工作流中，像调试代码一样逐步观察和调整音乐的生成过程。

为什么「暴露内部环节」很重要

作者明确表示，这个设计初衷是「为了学习」——他希望集成能展现 YuE2 之所以有趣的部分，而不是把一切都藏在一个 Generate 按钮背后。对于希望深入理解 AI 音乐生成原理的用户来说，这种可拆解、可观察的架构，价值远大于一个便捷但不透明的成品工具。

YuE2 的四阶段流程对应了现代音乐生成模型中常见的层级化架构思路：**Plan（规划）**阶段负责生成高层次的音乐结构蓝图，包括调性、段落安排等；**Semantic（语义）**阶段将文本与音乐规划转化为离散的语义 token 序列，捕捉旋律走向和和声轮廓；**Synthesize（合成）**阶段基于语义 token 生成更细粒度的声学 token，决定音色与细节表现；**Decode（解码）**阶段最终将声学 token 还原为可播放的音频波形。这种分层设计源自语言模型与音频编解码器（如 EnCodec）相结合的技术路线，与 Meta 的 MusicGen、字节跳动的 MusicGen 系列思路相近。将每层中间产物暴露出来，使得用户可以在不同抽象层次上介入创作，而不必每次都从头重跑整个计算密集型流程。

可编辑乐谱：ABC 记谱法与分支创作

项目最具特色的功能，是一个可选的乐谱编辑 UI（需在 ComfyUI 设置中启用）。它包含了几个颇为专业的组件：

• 在 ComfyUI 侧边栏中渲染五线谱记谱
• 原始 ABC 乐谱视图
• ABC 编辑器节点
• 先生成一个 plan，编辑乐谱，然后从修改后的版本继续生成

这套流程的意义在于打破了传统 AI 音乐生成「不可控」的痛点。你可以先让模型生成一个音乐规划，然后以 ABC 记谱法手动编辑其中的旋律或结构，再让生成流程从你修改过的版本继续推进。这种「人在环中」的创作方式，让 AI 从纯粹的生成器变成了可协作的乐器。

值得强调的是，这套乐谱 UI 是完全可选的。常规的节点执行和 API 工作流并不依赖它，这保证了自动化场景下的灵活性。

ABC 记谱法是一种基于纯文本的简谱格式，最初由 Chris Walshaw 于 1980 年代为民间音乐设计。它用字母 A-G 表示音符、用数字表示时值、用符号表示升降调，例如 A2 B c | d e f g 就能完整描述一段旋律。相比 MIDI 或 MusicXML，ABC 记谱法对人类可读且易于手动编辑，在民谣、传统音乐社区中广泛流通。将其引入 AI 音乐生成流程的优势在于：模型输出的音乐规划可以被直接以文本形式呈现给用户，用户无需专业符号乐理知识也能做基础的旋律修改——例如改变音高、调整节拍或替换某段乐句——然后将编辑结果重新送入下游的合成与解码阶段，从而实现对生成结果的精细干预。

工程细节：轻量依赖与环境兼容

熟悉 ComfyUI 生态的用户都知道，安装第三方节点最头疼的往往是依赖冲突。作者在这方面下了不少功夫，采取了相当克制的策略：

它复用 ComfyUI 自带的 Torch/Transformers，而不是安装 YuE2 官方钉死的依赖栈，只需要在干净的 ComfyUI 环境上额外安装 tiktoken 和 accelerate 两个包。

这种「不与现有环境打架」的设计哲学，大大降低了安装门槛和破坏现有环境的风险。测试环境为 CUDA v13.0 与 Python 3.13，并在全新安装的 ComfyUI 上验证过安装流程。

此外，作者还提供了多个示例工作流，覆盖分阶段生成、乐谱编辑、重载运行记录以及合成阶段的显存卸载（offloading）等场景，并且 plan 和 run 的产物都可以被保存复用。

显存与硬件需求：仍处实验阶段

作者非常诚实地标注了这个项目的实验性质。目前他只在一张 RTX 5090 上做过完整测试，README 中给出了实测的显存占用数据，以及对小显存显卡的粗略预期。

为了照顾显存有限的用户，项目内置了一个实验性的显存卸载机制（在工作流 06 中演示），能显著降低内存占用——但作者提醒，过程中仍会出现内存峰值。此外，他正在研究可选的量化方案以进一步节省显存，但坦言量化带来的内存节省与音频质量之间的权衡还需要测试，尤其是在合成阶段。

作者特别希望获得来自 16GB / 24GB 显卡以及不同 ComfyUI 配置的反馈。他也提到，在 Nodes 2.0 上手动测试过生成和乐谱检查器功能，基本可用但存在一些细微的视觉差异。

模型权重需自行下载

需要注意的是，项目本身不包含模型权重。README 详细说明了需要哪些 YuE2 文件以及它们应该放置的位置，用户需自行准备。

**显存卸载（VRAM Offloading）**是指在模型推理过程中，将暂时不参与计算的权重或中间激活值从 GPU 显存（VRAM）转移到系统内存（RAM）或磁盘，以换取在低显存硬件上运行大型模型的能力。代价是每次需要某层权重时必须将其重新搬回 GPU，产生额外的数据传输延迟，整体推理速度因此显著下降。模型量化则是将模型权重从 FP32 或 FP16 精度压缩为 INT8、INT4 甚至更低比特数的表示，可在几乎不损失（或可接受损失）质量的前提下将显存占用降低 2-4 倍。对于音频生成模型，合成阶段通常对量化误差最为敏感，因为细微的数值偏差会累积并影响音色的保真度，这也是作者特别点出该阶段权衡需要进一步测试的原因。

开源社区对 AI 音乐工具的深度探索

ComfyUI-Olm-YuE2 代表了开源社区对 AI 音乐生成工具的一种可贵探索方向：不满足于封装出一个「能用」的黑盒，而是把生成流程的每一环节都拆开、暴露、可编辑。对于研究者和进阶创作者而言，这种透明与可控的价值摆在眼前的事实。

项目仍处于早期实验阶段，作者也开放地欢迎 bug 报告、边缘案例和各类反馈。感兴趣的开发者可以前往其 GitHub 仓库 一探究竟。