YuE 音乐生成大模型：从歌词到整歌的本地部署实操

1. 先把 YuE 说清楚：它到底解决了什么问题

YuE 这个项目第一次刷到我面前时，我本能地把它归到"又一个音乐生成玩具"那一类——毕竟这两年音频生成模型见得太多了，能哼两句旋律、能凑出 30 秒伴奏的一大把。但真正点进去看它跑出来的样例，我的判断被推翻了一半：它输出的是带人声、带完整编曲、带主歌副歌结构的整首歌，而且歌词是你自己写的，可以中文也可以英文，还能通过提示词指定风格、性别、情绪和主奏乐器。

这件事的价值，只有当你在内容生产一线待过才会真正体会到。以前要产一首原创 BGM 加人声演唱，哪怕是最轻量的做法，也要走"作曲—编曲—录唱—混音"四道工序，外包报价动辄四位数，周期按周算。而 YuE 把这条路压缩成"写歌词 + 写风格提示词 + 等几分钟"。它不是把某个环节的效率提升 20%，它是把"从零到有一首歌"的门槛直接砍到了会写字就能上手。

这篇文章我打算按一个真实使用者的路径来写：YuE 的技术路线为什么这么设计、本地怎么把它跑起来、歌词和提示词具体怎么写、显存不够怎么办、生成出来人声糊了怎么调。适合三类人看——想拿它做视频配乐的内容创作者、想研究音频大模型技术路线的工程师、以及想把它嵌进自己产品里做功能验证的产品同学。前两类偏操作的细节我会写得细一些，第三类关注的点我也会单独拎出来讲。

1.1 从"生成 30 秒伴奏"到"唱完一整首歌"，中间隔着什么

如果只是生成一段纯器乐 loop，问题相对好办：模型只需要在音频的声学空间里采样，学到"钢琴听起来像钢琴""鼓点应该落在拍子上"就够了，没有语义约束，随便弹错也不会有人觉得不对。

一旦引入人声和歌词，麻烦立刻升级成三个维度。第一是语义对齐：模型要知道"这一小节唱的是哪几个字"，一个字都不能多不能少，否则听感上就是明显的跑调感。第二是长程结构：一首歌有主歌、副歌、桥段、结尾，副歌通常会重复两到三次，旋律要能呼应，这不是随机采样能"碰"出来的，模型必须对两分钟以上的时间跨度有记忆。第三是跨模态耦合：歌词的节奏和音符的时值是绑死的，一个字占几个音、哪里拖长、哪里断句，音频流和文本流必须同步推进。

传统做法是把这三件事拆开，交给不同的子模型串行处理，链条一长误差就累积。YuE 的路线选择很直接——不拆，把音乐和歌词当成同一条序列里交替出现的两种 token，用一个自回归语言模型一次性预测到底。这个选择后面的所有设计，包括窗口长度、码本排布、分阶段训练，都是在为它服务。

1.2 能力边界清单：能做什么、做不到什么

先把预期摆正，能省掉很多无效调试。我按实际用下来的体感列了个表，你可以对着看自己的需求是否在射程内。

这张表里最容易被新手忽视的是最后两行。很多人第一反应是"那我拿它生成伴奏再自己唱"，实际上输出的是已经混好人声的成品，要拿去二次处理得靠分离工具，音质会再掉一层。想清楚这一点，能省掉不少方向性浪费。

2. 技术路线拆解：它凭什么能把歌词"唱准"

这一节我想稍微讲深一点，因为后面调参时的很多"玄学"，根子都在这里。理解了它的生成机制，你调repetition_penalty、调段数、调提示词的时候，心里会有一张地图，而不是纯靠试。

2.1 双流交错：把歌词和音频塞进同一条序列

YuE 的核心抽象是"两条轨道"。一条是歌词轨道，把文本按字或子词切分后转成 token；另一条是音频轨道，把音频波形经过神经音频编解码器量化成一串离散 token。这两条流在序列里交替出现，模型做的还是那件最朴素的事——预测下一个 token。

这个设计的好处是，歌词和音频的时序对齐变成了结构上天然成立的事情。因为在训练数据里，某一帧音频旁边就是它对应的那个字，模型学到的是"看到这几个字的 token，后面该接一段什么样的声学 token"。它不需要额外的对齐模块，也不需要强制时长约束，对齐是数据本身教出来的。

坏处也很明显：序列会变得非常长。音频 token 的密度本身就高，再乘上多个码本，一条两分钟的歌序列长度轻易上万，直接把常规语言模型的上下文窗口撑爆。这就引出了后面两节要讲的两个工程手段——码本交错排布和分阶段扩窗。

2.2 多码本怎么排布，为什么这个顺序很关键

音频编解码器一般用残差矢量量化（RVQ）的思路：第一层码本描述音频的粗轮廓，第二层补细节，第三层再补残差，层层叠加才能还原出高保真波形。假设有 8 层码本，那么每一个时间帧其实对应 8 个 token，而不是 1 个。

这 8 个 token 怎么线性排在序列里，是个要命的问题。有两种排法：一种是"按层排"，先把第一层所有帧写完，再写第二层；另一种是"按帧交错"，每一帧的 8 个 token 紧挨着写，然后跳进下一帧。

YuE 选的是后面这种交错排布。原因很实在：同一帧的 8 个 token 是强相关的，它们描述的是同一个时刻的声音。放在相邻位置，模型预测时能直接看到同帧的其他层信息，生成出来的音质明显更稳。如果按层排，预测第二层第 500 帧的时候，需要回忆很久以前的第一层第 500 帧，长距离依赖一多就容易失配，听觉上表现为金属感、爆音或者人声发虚。

到了长上下文阶段，还会引入 patch 机制：把连续几帧的同一层 token 打包成一个组合单元。这么做的目的纯粹是压缩序列长度，让两分钟的音频能塞进窗口。代价是时间分辨率变粗，所以它只在后期阶段启用，前面阶段还是老老实实逐帧建模。

2.3 三阶段课程训练：短窗学音色，长窗学结构

一次性让模型在超长序列上训练，既训不动也训不好。YuE 用的是课程学习的思路，分三段递进。

第一阶段窗口最短，模型专注局部：这一小段音频该是什么音色、字的发音该怎么起头、鼓点该怎么落。它学到的是"微观质感"。第二阶段把窗口拉长一些，模型开始能记住几小节之内的旋律走向，懂得一句唱完该接下一句。第三阶段用最长窗口，模型才有机会看到整首歌的骨架，学会"副歌在这里要回来了""结尾要收住了"。

这个分层逻辑对使用者的启示是：你给模型的段长参数，实际上是在选择让它用哪个阶段的"视角"来补全音乐。段太短，模型只看得到局部，出来的东西像流水账，一遍遍重复同样的动机；段太长，又容易在后半段失去连贯性开始发散。后面实操部分我会讲怎么找这个平衡点。

3. 环境准备：显存、依赖与权重的那些事

真正动手之前，先把硬件这条线摸清楚。YuE 的模型规模不小，我见过太多人兴冲冲下载了几十个 G 的权重，跑起来第一秒就 OOM，然后开始怀疑人生。

3.1 显存门槛怎么估，别拍脑袋

官方给出的建议是单卡 24GB 起步，这个数字不是随口说的。7B 参数量的主模型用 bf16 加载，光权重就吃掉大约 14GB；推理时还要缓存 KV（键值对），序列越长这部分越大；再算上音频编解码器的解码开销和中间激活值，20GB 上下是常态。如果还要开批量加速，24GB 会很快见底。

估算的时候有个经验公式可以记：显存占用大致等于权重体积乘以 1.3 到 1.6，再叠加与序列长度成正比的 KV 缓存。如果你打算生成的歌曲接近两分钟，建议按 1.6 这个系数预留，别卡着底线跑，中途爆掉比一开始就慢更让人崩溃。

还有一点容易被忽略：卡上跑的其他进程会抢占显存，尤其是浏览器、本地大模型服务、视频编辑软件。跑之前用显卡监控工具确认一下空闲显存，比看总容量靠谱得多。

3.2 依赖安装：版本对齐比装得多重要

这类音频大模型项目的依赖坑，九成出在版本不对齐上。比较稳妥的思路是先用 Conda 或虚拟环境隔离出一个干净空间，Python 版本选 3.10 或 3.11，然后严格按仓库里的依赖清单走。

conda create -n yue python=3.10 -y conda activate yue # 先装与显卡驱动匹配的 PyTorch，这一步不要照抄别人的版本号 pip install torch torchaudio --index-url https://download.pytorch.org/whl/cu121 # 再装项目依赖 pip install -r requirements.txt

注意：PyTorch 的 CUDA 版本必须和你的显卡驱动兼容，装之前先查清楚驱动支持的运行时上限。装高了不会报错，但会在第一次前向传播时抛出莫名其妙的运行时异常。

注意力实现的加速库（flash-attn 这类）经常是编译失败的重灾区。如果编译卡住或者报错，可以先跳过，用 PyTorch 自带的注意力实现跑通流程，确认模型能出声之后再回头优化速度。先求通，再求快，这个顺序别搞反。

3.3 权重怎么组织，目录结构要一次弄对

YuE 的推理通常需要两个模型协同：一个负责主生成阶段，参数量大；另一个负责后续阶段的精修，参数量小。两个都要下，缺一个跑不起来。

ckpt/ ├── stage1/ # 主生成模型，参数量较大 │ ├── config.json │ ├── model.safetensors │ └── tokenizer 相关文件 └── stage2/ # 精修模型，参数量较小 ├── config.json └── model.safetensors

下载完之后建议先做一次完整性检查：文件数量对得上、单文件体积和官方标注一致、没有下载中断产生的残缺文件。大文件下载中断是常事，残缺的 safetensors 加载时会报格式错误，但报错信息往往很含糊，容易让人误以为是代码问题。

4. 实操：从零跑出你的第一首歌

环境通了之后，真正的乐趣才开始。这一节我按"写歌词—写风格—跑命令—听结果"的顺序走一遍，每一步都说说为什么这么写。

4.1 歌词文件的格式，有三个硬性要求

YuE 对歌词文件是有格式约定的，不按格式写会直接影响生成质量，甚至让模型漏字、串行。

第一，用结构标签给段落分段。常见的标签是主歌、副歌、桥段、器乐段这几类，写成方括号包裹的形式，单独占一行。模型靠这些标签理解"这里该换情绪了"。如果你整篇写成一坨不带结构，生成出来的东西往往从头到尾一个调，没有起伏。

第二，段落内的句子要短。一行歌词尽量控制在一个呼吸能唱完的长度。长句会让模型在分配音符时左右为难，听感上就是赶拍或者吞字。

第三，[inst]这类纯器乐标签后面不要跟歌词。它的作用就是告诉模型这段只出伴奏，跟了文字反而会让它不知道该不该唱。

一个规范的歌词文件大概长这样：

[verse] 夜色落在窗台上面 风把灯影吹得很远 [chorus] 我还在这里等你 等一句没说完的话 [inst] [verse] 街角的咖啡凉了 杯子上的字也淡了 [chorus] 我还在这里等你 等一个不会来的夏天 [end]

提示：中英文不要混着写在同一段里。模型对语言的切换判断是基于上下文的，混写会让它在中途切换发音方式，听起来像是突然换了个人在唱。

4.2 风格提示词：短、具体、别贪多

风格提示词是决定"这首歌长什么样"的关键开关。我的经验是控制在三到六个关键词，覆盖四个维度：曲风、人声特征、主奏乐器、情绪或节奏。

比如要一首偏安静的民谣女声，写成：folk, female vocal, acoustic guitar, warm, slow tempo。想要电子舞曲：electronic dance, male vocal, synth lead, energetic, 128 bpm。

这里有个反直觉的点：提示词不是越详细越好。你写一大段散文式描述，比如"一首关于夏夜回忆的、带着淡淡忧伤的、伴奏以钢琴为主偶尔加入弦乐的抒情歌曲"，模型反而抓不住重点，可能把"忧伤"和"弦乐"当成互斥条件，输出一个四不像。原因是提示词在训练数据里对应的形式就是简短标签式的，你用超出分布的长描述，等于让它在没见过的输入形态上泛化。

另外，人声性别要明确写出来。不写的话，模型会从歌词的语义和训练数据分布里猜，结果常常在两段之间来回横跳，副歌突然换性别，非常出戏。

4.3 推理命令与核心参数解释

命令行的调法各家仓库略有差异，我拿一套常见的调用形式来讲，重点在参数含义，具体名字对照你手上的版本。

python infer.py \ --stage1_model ./ckpt/stage1 \ --stage2_model ./ckpt/stage2 \ --genre_txt ./genre.txt \ --lyrics_txt ./lyrics.txt \ --run_n_segments 2 \ --stage2_batch_size 2 \ --max_new_tokens 3000 \ --repetition_penalty 1.1 \ --guidance_scale 1.2 \ --seed 42 \ --output_dir ./output \ --cuda_idx 0

逐个拆一下。

run_n_segments控制生成多少个音频窗口然后拼接。设 1 就是一段，大约几十秒；设 2 到 3 能凑出一首完整的歌。段数越多总时长越长，但拼接处的衔接质量会下降，不是越多越好。

max_new_tokens是每段生成多少 token。它和段落时长成正比关系，你调小了，这一段会被提前截断，听起来像歌没唱完就掐了。这个值和段数的组合，决定了最终成品的时长，想控制长度主要就靠这两个参数。

repetition_penalty是抑制重复的强度。设成 1.0 相当于不惩罚，模型容易卡在一个动机里反复循环；设到 1.3 以上又会让旋律变得过于跳脱、失去统一感。1.05 到 1.15 是我实测比较舒服的区间。

guidance_scale是无分类器引导的强度，简单说就是"多大程度上听提示词的话"。设成 1.0 表示完全不加引导，模型自由发挥；往上调会越来越贴近提示词，但太高会牺牲音质，出现削波和噪声。1.1 到 1.3 是比较稳的范围。

seed固定随机种子。这一点非常重要，见后面的经验部分。

4.4 生成完之后该检查什么

拿到输出文件别急着发朋友圈，先按几个维度过一遍。

听三遍。第一遍听整体结构，主歌副歌有没有区分开，副歌是不是真的回来了。第二遍专门盯人声，有没有吞字、糊字、突然换音色。第三遍听伴奏，鼓点是不是稳的，有没有明显的节拍漂移。

用频谱工具看一眼波形。如果整体电平贴顶并且有平顶，说明削波了，得降引导强度或者换种子重生成。如果在拼接位置有明显的不连续突跳，说明段间衔接没做好，可以试着减少段数或者调整提示词让风格更统一。

如果输出的是多个分段文件而不是自动拼好的整曲，可以用音频处理库自己拼，注意在接缝处做短交叉淡化，能明显削弱"咔"的一声。

import numpy as np from scipy.io import wavfile rate, a = wavfile.read("seg1.wav") _, b = wavfile.read("seg2.wav") fade = int(rate * 0.05) # 50 毫秒交叉淡化 fade_out = np.linspace(1, 0, fade) fade_in = np.linspace(0, 1, fade) a_tail = (a[-fade:] * fade_out[:, None]).astype(np.int16) b_head = (b[:fade] * fade_in[:, None]).astype(np.int16) merged = np.concatenate([a[:-fade], a_tail + b_head, b[fade:]]) wavfile.write("final.wav", rate, merged)

5. 常见问题与排查速查

这一节是我出问题最集中的地方，整理成表方便你直接对照。

5.1 显存和性能类问题

有个细节值得单独说：长序列推理的显存峰值出现在后半段而不是开头。很多人跑前几秒看着显存还剩一大截，就放心大胆把段数拉满，结果到第二段才炸。做压力测试的时候，一定要跑到最长的那个配置再判断。

5.2 生成质量类问题

人声糊成一团是最常见的问题。先看是不是引导强度太高，往下调到 1.1 附近试试；再看提示词里有没有互相打架的描述，比如同时写了"清澈"和"失真"；最后考虑是不是段太长导致后半段模型开始发散。

歌词漏字或者串行，八成是歌词格式问题。检查段落标签是不是单独占行、有没有多余空行、有没有中英文混排。还有一个隐蔽原因：歌词行太长。模型在分配音符时如果一行字数超出它训练时见过的常见范围，会倾向于跳过一部分。

旋律单调、副歌不回来，这通常是段数与提示词的配合问题。可以试着缩短单段长度，让模型用更"局部"的视角生成更多变化，同时在风格提示里加上节奏或情绪的区分词，给它一个"这里该不一样"的信号。

至于节拍漂移，这是自回归生成的通病。生成的段落越靠后，累积误差越大。实践中比较有效的做法是把长歌拆成两次生成，第二次用第一次的结尾片段作为参考音频，让模型接上去，比一口气生成到底要稳。

5.3 出片前的处理环节

原始输出直接拿去用往往差点意思。我一般的处理顺序是：先做响度归一化，把整体电平拉到统一标准，避免不同歌曲之间音量跳来跳去；再做一次轻微的动态压缩，让人声更突出；如果人声和伴奏的平衡不对，可以尝试做简单的人声分离，单独给人声加一点空间感效果，再混回去。

这里有个取舍：分离这一步一定会损失音质，因为分离模型本身是有损的。如果原始生成结果的人声已经足够清楚，宁可不动，别做无谓的二次加工。

6. 我踩过的坑和几条实用经验

最后这部分是我最想分享的内容，都是走弯路换来的。

6.1 提示词不要一次改太多

刚开始用的时候，我总犯一个毛病：生成结果不满意，就把风格提示、段数、随机种子全部换一遍，然后再听。结果好听是好听了，但完全不知道是哪个改动起了作用，下次遇到同样的问题还是不知道怎么办。

后来我改成单变量法：每次只动一个参数，其他全锁死。比如这一轮只调repetition_penalty，从 1.05 到 1.15 每隔 0.025 跑一次，对比着听。虽然多花点时间，但几轮下来你就能建立起"这个参数动多少、听感变多少"的直觉，这个直觉比任何教程都值钱。

6.2 种子和提示词要一起记录

这一点吃过的大亏最多。有一次我生成出一首特别满意的歌，关掉终端就睡了，第二天想复现完全做不出来——因为我不记得当时的种子，也不记得提示词里那几个词的具体顺序和大小写。

现在我养成一个习惯：每跑一次，把提示词全文、所有命令行参数、随机种子、输出文件名写进一个文本文件，跟音频放同一个目录。做多了之后这些记录还能当成一个小型素材库，要哪种氛围直接翻历史找，比重新试快得多。

顺便说一句，固定种子并不意味着结果完全不变。换个模型版本、换台机器、甚至换套依赖版本，同样的种子也可能出不同的结果。种子只保证在同一套环境里可复现，跨环境别指望。

6.3 把它接进自己的工作流

如果你不是只做一两个试验，而是要批量产内容，图形界面点来点去会很浪费时间。比较实际的做法是把推理脚本包一层，接成命令行批处理或者本地接口服务。

我的处理方式是：把"提示词模板 + 歌词文件 + 参数组"写进一个配置文件，用一个脚本遍历读取、逐个调用推理、自动做拼接和响度归一化，最后按日期归档输出。这样一次挂机就能出一批素材，人只负责最后的筛选和精修。

还有一个值得试的方向是用参考音频做风格延续。如果你已经有一首歌的副歌很满意，可以把那一段截出来作为参考输入，让模型基于它生成后续段落，风格一致性会比纯靠文字提示好很多。这个功能对做系列内容特别有用——比如一档播客的片头曲，希望能保持统一的听感但每期略有变化。

要说限制，最需要提醒的是输出内容的来源合规问题。模型是基于大量音频数据训练的，生成结果和你自己的原创歌词之间是什么关系，用在商业场景前最好自己心里有数，别拿着就跑。

我个人在实际操作中的体会是，YuE 这类工具真正的价值不在于"替代音乐人"，而在于让"有想法但不会乐器"的那批人能把脑子里的东西倒出来听一遍。它给你的是一张粗稿、一个方向、一个可以拿去跟人讨论的实物。至于要不要把它打磨成成品，那是另一个阶段的事——而那个阶段，目前还是得靠人。