企业官网建设流程全解析

很多人第一次注意到 YuE，都是被三个词勾住的：开源、整首歌、能跑在自己机器上。我也一样。当时我手上正好有个小项目需要"人声加伴奏"一起出来的原创音乐，商业在线服务按首计费不说，成品还不太好拆开做二次处理，所以看到 YuE 能把一段写好分段的歌词直接唱成一首完整的歌，第一反应是"这要是真能稳定跑通，能省我一大笔事"。结果从拉代码到真正产出一首自己愿意留档的歌，前前后后折腾了将近两周，踩的坑远比想象中多——显存炸过、依赖编译卡过、生成的歌副歌重复到像卡带、还有一次整整跑了四十分钟最后发现歌词参数写错了。

这篇就把这两周的东西全部摊开讲：YuE 到底是什么、它为什么要吃这么多显存、环境怎么搭、提示词怎么写、出来的东西为什么总"差一口气"，以及那些散落在 issue 区和群里、官方 README 不会写的细节。不管你手上是一张 24G 的卡，还是只有一张 12G 的老伙计，看完至少能判断自己该不该下场、下场之后第一步该干什么。

1. 先把 YuE 是什么讲清楚：它和"AI 编曲"不是一类东西

1.1 它做的是歌词到整首歌，而不是给你配个伴奏

市面上的音乐生成工具大致分三类：一类是输入一句话描述、吐出一段纯器乐；一类是给一段旋律、帮你编曲加鼓加贝斯；还有一类是翻唱式的音色转换。YuE 属于第四类，也是最少见的一类：输入是带结构标记的歌词和一组风格标签，输出是同时包含人声与伴奏的完整歌曲，时长可以拉到几分钟，有前奏、主歌、副歌、间奏、尾声的完整段落推进。

这个差异听起来很小，实际上难度差了一个数量级。纯器乐生成只需要在"音色空间"里做合理采样，错了也不明显，一段糊的合成器铺底没人会挑刺。但一旦要把人声加进来，模型就必须同时处理三件事：歌词文本到音素的映射、音素到音高与节奏的对齐、人声与伴奏在时间轴上的耦合。这三件事里任何一件没做好，听感就是"这个人唱歌跑调""歌词含糊听不清""伴奏和人声像两条平行线"。所以你拿 YuE 生成的歌，评价标准不应该是"像不像 AI 生成的音乐"，而应该是"能不能听清在唱什么、段落是不是立得住"。

从使用者的角度看，YuE 的输入其实就两块，最好分开准备：

• lyrics 文件：歌词正文，配合[start]、[verse]、[chorus]、[bridge]、[inst]、[end]这类结构标签来划分段落。
• genre 文件：一行风格描述，用英文小写词、逗号分隔，比如速度感、性别音色、编曲乐器、情绪走向这几类词各挑一两个。

把这两样东西喂进去，模型自己决定旋律怎么走、和弦怎么铺、鼓点怎么打。这也是它和"模板编曲"最大的区别：它不是在已有素材库里拼贴，而是在生成新的音频 token 序列，所以同一份歌词跑两次，出来的旋律是两条完全不同的曲子。这一点后面讲参数和种子的时候还会提到，因为它直接决定了你的工作流应该是"批量抽卡"而不是"精修一条"。

1.2 两阶段生成加音频离散化：这套设计到底在权衡什么

要理解 YuE 为什么这么吃显存、为什么生成慢、为什么会有"接缝"，必须先把它的核心设计说清楚。它走的是现在主流开源音频生成模型的同一条路：先用一个音频编解码器把连续波形离散化成 token 序列，再让一个基于 Transformer 解码器结构的语言模型去预测这些 token。

关键在于"分层"这两个字。一段原始音频如果直接离散化成单一序列，信息密度太高，模型撑不住。所以编解码器会把音频拆成多个码本，可以理解成一帧音频同时用好几层来描述：第一层抓住最粗的东西——音高轮廓、节奏骨架、人声和伴奏的大致分工；越往后的层抓越细的东西——高频泛音、气声、齿音、镲片尾音。这和把一张图片先存成缩略图、再逐层补细节是一个思路。

YuE 把这个结构用在了生成流程上，于是就有了它的两阶段设计：

这套拆法的好处是显存压力可以被切分：如果一张卡同时装不下两个阶段，你可以让它们分时复用显存，先跑完 Stage 1 把结果落盘，再加载 Stage 2 接着做。代价是速度。坏处也很明显——Stage 1 一旦把旋律走歪了，Stage 2 只会忠实地把歪掉的旋律补得更清楚，它没有任何"纠正"能力。所以我的经验是：调试阶段把注意力全部放在 Stage 1，Stage 2 的近实时试听留到风格基本确定之后再做。

还有一点必须提前知道：长音频是分段自回归生成的。模型一次只处理一个上下文窗口，跑完一段之后用上一段的尾部作为条件继续往下推。单段大致对应三十秒上下的音频，你要一首两分钟的歌就得设成多段连续跑。段与段之间靠上下文衔接，衔接得不好就会在段落交界处出现"接缝"——鼓点突然断一下、人声气息接不上、和声变了调。后面第 5 章专门讲这个问题怎么缓解。

2. 跑 YuE 之前，先把显存和时间的账算明白

2.1 官方推荐线和实际占用区间

先给结论：24G 显存是一条舒服线，16G 是能跑的底线，12G 及以下建议先别急着折腾。这里的数字不是拍脑袋，是由两个阶段模型的大小、上下文长度、以及推理时的中间激活共同决定的。

我这边的实测感受是，单张 24G 的卡跑默认配置，峰值占用落在 20G 到 23G 这个区间波动，具体取决于你设的段数、每段的最大生成长度、以及 Stage 2 的批大小。段数越多、单段越长，注意力计算里的键值缓存就越占地方，峰值也就越靠上。如果你把 Stage 2 的批大小调到比较大的值想加速，很可能就在这一步炸显存，因为它是按批处理全部时间帧的。

时间账也得算。一首两分钟出头的歌，在 24G 卡上从 Stage 1 到 Stage 2 跑完，我的体感是接近十分钟量级；如果是十六七 G 的卡加上权重卸载，同样一首歌可能要往三十到五十分钟走。这个成本直接决定了你的工作流该怎么设计：不要一条一条地精修，而应该一次准备好五到十条不同风格的 genre 加歌词组合，晚上挂机批量跑，第二天早上挑。这是我在折腾掉一整个周末之后才想明白的事。

另外提醒一句：磁盘空间要留够。模型权重是分好几个仓库下下来的，加上中间产出的 token 文件、分段音频、最终合并的 wav，一个项目目录轻松吃掉几十 G。别等到跑到一半才发现磁盘满。

2.2 显存不够时的三条退路，按性价比排序

如果手头确实只有一张中小显存的卡，也不是完全没戏，只是要接受复杂度上升。我把可行的路子按性价比从高到低排一下。

第一条，两个阶段拆开跑。这是最推荐的。先只加载 Stage 1 的模型，把整首歌的粗粒度 token 生成完并落盘，然后把 Stage 1 的权重释放掉，再加载 Stage 2 继续。这样做的好处是不需要任何额外的量化或改写代码，配置里就能开关。代价是模型加载时间翻倍，而且中间结果要占磁盘。我个人认为在 16G 卡上这是唯一真正可用的方案。

第二条，开启权重卸载。把暂时用不到的层放到内存里，用到的时候再搬回显存。这让 12G 级别的卡理论上也能跑，但速度掉得非常狠，而且对内存容量有要求，最好有 32G 以上系统内存兜底。我试过一次，跑到第三段的时候我直接放弃了——生成的每一步都在等数据搬运，完全失去了迭代节奏。

第三条，降低单段长度和段数，改用"多次短跑拼长歌"。这不是官方的参数，而是一种使用策略：把一首长歌拆成几首短歌分别生成，再用音频编辑软件手动对拍拼接。要求是你得自己控制调性和速度的一致性，否则拼出来会像两首歌硬粘在一起。这条路的成功率取决于你对音乐本身的理解，纯技术手段解决不了。

注意：不管用哪条退路，都建议先用一首三十秒左右、歌词只有主歌加副歌的短样本做全流程验证，确认环境没问题再上长歌。我见过太多次"直接跑三分钟的歌，一小时后报错"的浪费。

3. 从零跑通第一次推理的完整链路

3.1 依赖安装：最大的拦路虎往往不是模型

环境这一步，真正会卡住人的通常不是 Python 包版本，而是和注意力加速相关的那个编译型依赖。它需要本地有完整的编译工具链，编译过程本身很吃 CPU 和时间，而且在部分系统上会因为编译器版本、头文件路径、CUDA 版本不匹配而直接失败。

我的做法是先不管加速库，用原生注意力把流程跑通一次。这一步的意义是分清楚"环境问题"和"模型问题"——只要原生注意力能跑出音频，说明你的 CUDA、PyTorch、音频编解码器依赖全都是通的。之后再去装加速库，装失败了也只是慢，不是不能用。顺序反过来的话，编译报错和显存报错会混在一起，排查起来非常痛苦。

具体操作上，我的流程是：建一个干净的虚拟环境、按官方要求锁好 PyTorch 与 CUDA 的对应版本、装齐音频处理相关的依赖、最后再单独处理加速库。音频处理这块别偷懒，编解码和重采样都依赖它，缺了会在读取参考音频时抛出很难懂的异常。

还有一个容易被忽略的点：推理脚本对工作目录是敏感的。有些路径是相对路径，站在仓库根目录跑和站在推理子目录跑，模型权重找不到、提示词文件找不到的报错方式完全不一样。我的习惯是每次都在推理脚本所在的目录下执行，提示词文件用相对路径指过去，这样换机器的时候只要目录结构一致就能直接复现。

3.2 权重下载与目录组织

权重是分仓库的：Stage 1 一个大模型、Stage 2 一个小模型、外加上采样模型，另外音频编解码器通常也是单独的一份。加起来体积很可观，而这类模型仓库的文件往往是大文件，普通下载方式很容易中断。

我踩过的坑是：不同语言的模型是分开的仓库，比如英文线、日韩线、中文线各有一条 Stage 1 权重。你按英文线下的权重去唱中日韩歌词，出来的效果会明显发闷、发音含糊。所以第一件事是确定你的歌词主要是什么语言，然后只下对应的那一条线，别贪多。下完之后，把所有权重放在统一的模型目录下，目录名保持一致，这样切换模型只要改一个参数。

另外，模型文件的完整性一定要校验。我曾经因为一次断点续传导致的半个文件，折腾了整整一晚上，报错信息指向的是张量形状不匹配，完全看不出是下载的问题。教训就是：下载完先看文件大小对不对，再去跑推理。

3.3 一条能复现的推理命令

环境通了之后，第一次推理别去改任何默认参数。先用官方仓库自带的提示词样例跑一遍，验证整条链路，然后再换成自己的歌词。命令的形态大致是这样，参数名以你本地拉到的版本为准：

cd inference/ python infer.py \ --cuda_idx 0 \ --stage1_model <你的Stage1模型路径> \ --stage2_model <你的Stage2模型路径> \ --genre_txt ../prompt_examples/genre.txt \ --lyrics_txt ../prompt_examples/lyrics.txt \ --run_n_segments 2 \ --stage2_batch_size 4 \ --output_dir ../output \ --max_new_tokens 3000 \ --repetition_penalty 1.1 \ --seed 42

几个参数我逐个说说含义。run_n_segments是跑几段，每段大致对应三十秒上下的音频，跑两段差不多能凑出一分钟的成品。max_new_tokens是单段生成的最大长度，设小了段落会提前结束，设大了会白跑多余步数。repetition_penalty是重复惩罚，这个是最容易影响听感的旋钮之一，设得太低会出现副歌一字一句反复唱同一句，设得太高则旋律会变得很跳跃、不连贯，我一般从 1.1 开始上下试。

seed一定固定住。因为生成过程是采样的，不固定种子的话，你每次调试参数都在换一首全新的歌，根本分不清是参数起了作用还是运气好。我的调试原则是：固定种子改一个变量，跑三遍看是否稳定，这样调出来的结论才可信。

跑到一半的时候，日志里会刷每一段的进度。这个阶段最容易出现的两个状态是：进度长时间不动（在算注意力）和显存占用缓慢爬升（键值缓存在累积）。如果你的显存曲线是单调上升然后崩，说明段数设多了，需要往回砍。

4. 提示词才是成品率的分水岭：genre 和 lyrics 怎么写

4.1 genre 标签：写三到六个词，别写作文

genre 这一行是整首歌的"总基调"，它决定了模型往哪个方向采样。我一开始犯的错是把想到的词全堆上去，写了一长串风格形容词，结果出来的东西四不像——因为它同时在往五六个互相冲突的方向拉。后来改成只写三到六个词，每一类最多一个，效果立刻稳定了。

我通常按这四类来挑：

• 速度与律动：慢、中速、快、摇摆感
• 人声音色：男声、女声、明亮、沙哑、气声
• 编曲骨架：木吉他、钢琴、弦乐、合成器、失真吉他
• 情绪走向：温暖、忧郁、激进、梦幻

这四类里各挑一个最符合你目标的词，就是一行很干净的 genre。举个例子，想要一首温暖的女声民谣，写成"慢速、女声、原声木吉他、温暖"这样的组合就够了，用英文小写、逗号分隔。

还有一个经验性判断：风格词越具体，出歌的方差越小，但也越容易平庸；越抽象，偶尔会出惊喜，但废片率更高。如果你要的是稳定交付，选具体词；如果是在探索，可以放开一点，但一定要配合固定的种子做对比。

注意：genre 里不要写具体的歌名、人名、品牌名，也不要写模仿某个特定作品。这类提示在实际使用中既不稳定，也容易带来不必要的麻烦，纯风格描述才是有效输入。

4.2 lyrics 文件：结构标签不是装饰，是给模型的路标

歌词这部分，很多人以为只要把歌词贴进去就行，其实结构标签的作用非常大。模型是靠这些标记来判断"现在该进副歌了""这里是纯器乐间奏""这里该收了"。你把标签写清楚，段落推进就立得住；标签乱了，整首歌会变成一条没有起伏的直线。

我的写法是：

[start] [verse] 第一段主歌歌词，一行一句 第二行 [chorus] 副歌第一句 副歌第二句 [verse] 第二段主歌 [chorus] 重复副歌 [inst] [end]

几个细节值得说。第一，[inst]用在间奏，这是让歌曲有呼吸感的关键。我早期完全不写间奏，出来的歌就是人声从头唱到尾，听得非常累。加上一段纯器乐段之后，整首歌的层次马上不一样了。第二，副歌可以重复写两遍，模型会倾向于用相似但略有变化的旋律处理，这符合真实歌曲的习惯，但如果你把副歌歌词写得一模一样又完全不改，重复惩罚设得太低时就容易唱成复读机。第三，每一行的长度尽量别差太多，长短句交错太剧烈的时候，模型对齐音节会比较吃力，容易出现吞字。

还有一个我很晚才发现的问题：分行方式会影响节奏切分。同一句话写成一行和拆成两行，出来的断句位置是不一样的。所以如果你对断句有明确想法，就用换行去强制它，这比在歌词里加标点更有效。

4.3 用参考音频锚定风格：ICL 模式的实际用法

除了纯文本提示，YuE 还支持给一段参考音频作为风格锚点，也就是常说的上下文学习模式。它的作用不是"翻唱"，而是让模型从参考片段里提取音色、编曲密度、混响感这些风格特征，再套到你的新歌词上。

用法上要注意几点。参考音频要短，一般控制在一段三十秒以内，太长了会挤占上下文窗口，而且容易把参考里的具体内容"带"过来。截取的位置最好是副歌或者编曲最满的那一段，因为那一段的风格特征最集中，用主歌开头的清唱片段去锚定，得到的结果往往偏单薄。

我自己用下来，这个功能在两种场景下最值：一是你手上有一段自己录的 demo，想让生成结果贴近你的音色和编曲习惯；二是你需要一批风格高度统一的歌，用同一段参考音频跑多条歌词，一致性会比纯文本提示好不少。

代价是速度。参考音频会显著增加上下文长度，生成变慢、显存占用变高。所以我的建议是先用纯文本调到一个满意的风格方向，再用参考音频做最后的一致性收敛，不要一上来就用它。

5. 生成完了不等于成品：接缝、上采样和导出

5.1 段落交界处的"断片"是怎么来的

分段自回归的机制决定了接缝问题的存在。每一段生成时，模型只能看到上一个上下文窗口里的内容，它不知道后面还有多长，也不知道整首歌的全貌。所以在段与段的交界处，经常出现几种典型症状：鼓组突然少了一件、贝斯线断了一下、人声气息被硬切断、和声走向跳了一下。

应对思路有三条，按优先级排：

我的实操习惯是把交界处的处理当成后期工作的一部分。真要把两段拼得天衣无缝，纯靠参数调是做不到的，最后往往还是要用音频软件在交界处做几毫秒的交叉淡化，或者干脆在交界处安排一个自然的鼓点过渡。接受"接缝需要人工收尾"这个事实，比死磕参数省时间得多。

5.2 上采样与导出：别在最后一步丢掉细节

生成出来的中间产物，采样率通常不是最终想要的成品标准。这时候需要过一遍上采样模型，把音频还原到更高的采样率和更完整的频响。这一步的意义是补回高频细节——没有它，成品听起来会有一种"隔着一层布"的闷感，尤其在人声的齿音和镲片上特别明显。

导出的时候有几个我的固定动作。第一，成品名带上关键参数，比如种子、段数、风格词，这样你回头想复现某一首的时候不用去翻日志。第二，分段音频和合并后的成品都要留，因为合并后的版本如果接缝不理想，你还能回到分段重新处理。第三，导出成无损格式再听，压缩格式在高频上的损失会掩盖掉一些你本来想判断的细节，尤其是判断人声有没有发闷的时候。

试听判断也是有技巧的。我的习惯是用手机外放先听一遍——如果在这个条件下人声还能听清、段落还能立住，说明混音层面基本没问题。很多人只在监听耳机里听，觉得挺好，一发出去就发现人声被伴奏盖住了。这是个很实用的土办法。

6. 踩坑清单：这些问题我全都遇到过

把高频问题整理成一张表，方便你按症状定位。

这里面我想单独说两个最耗时间的坑。

第一个是版本问题。我最初在一台机器上跑通了，换到另一台就各种报错，查了很久发现是 CUDA 和 PyTorch 版本组合不一样，导致音频编解码器在某个算子上的行为有细微差别。教训是：一旦找到了能跑的版本组合，把它记下来，换机器时整套照搬，不要"顺手升个级"。

第二个是变量不隔离。我前面提到过固定种子的重要性，但真正做到很难——手一痒就同时改了风格词、段数、重复惩罚三个东西，结果出来变好了也不知道是谁的功劳。后来我强制自己用一张表记录每次实验的变量和结果，看起来笨，但是唯一能积累经验的方法。音乐生成的主观性太强了，不记录下来，两周之后你只记得"好像调过什么"。

至于什么时候该放弃 YuE 这条路，我个人的判断标准是：如果你需要的是稳定批量交付、每一首都达到商用发行水准，那它现在的能力还不足以独立承担，更适合当灵感来源和草稿生成器；但如果你需要的是低成本、可迭代、能自己掌控全部数据的原创素材，那它值得你花那两周时间去摸清脾气。

最后分享一个我最近才用顺手的小技巧：先用极短的歌词跑几十条片段，只留副歌两到四句，用固定种子对比不同的风格词组合。这一步成本极低，每条几十秒就能出，挑出三五个满意的方向之后，再拿完整歌词去跑长版本。我用了这个方法之后，废片率大概降了一半——因为真正决定一首歌成败的，是副歌那八小节的旋律走向，而这件事只跟风格词和随机性有关，跟你写了两分钟还是三十秒的歌词关系不大。