第一次听到 YuE 这个名字很多人的第一反应是这是粤语的拼音吗或者是不是某个人的姓。如果你最近在开源音乐生成这个圈子里刷得比较多那它大概率指的就是那套把整首歌当成序列来预测的开源音乐基础模型。名字取自乐读音是 yuè跟月亮没关系。它要解决的问题也很直接过去我们手里那些文本生音乐的模型能给你一段三十秒的氛围配乐、一段鼓点循环但你让它唱出一句完整的中文歌词它做不到。YuE 想干的事情是把歌词到成曲这条链路一次性跑通——你给歌词、给风格标签它给你一首带人声、带伴奏、有主歌副歌结构的完整歌曲。这篇文章不是官方文档的翻译稿。我会按我自己踩过的顺序来讲先把它到底在干什么讲清楚再说它内部那条两阶段生成管线是怎么设计的然后是本地怎么把它跑起来、prompt 怎么写才出片、实测里遇到的那些坑人声糊、时间轴对不上、显存直接爆分别是怎么回事最后聊拿到 wav 之后怎么跟后期流程衔接。不管你是做音乐的、做算法的还是纯粹想拿它做点东西玩看完应该能直接上手。1. YuE 到底生成什么把整首歌当作 token 序列来预测1.1 它和 MusicGen 那一类模型的分水岭在哪先把最容易混淆的地方说清楚。文本生音乐这个赛道里早几年的模型基本都聚焦在器乐上。你给它一句 lo-fi hip hop with rain它给你一段两分钟的纯伴奏没有唱词。这不是技术不行而是人声这个东西在音频建模里的难度要高一个数量级——它同时要求音高准确、咬字可辨、节奏跟伴奏对齐还要在一首歌的尺度上保持整段演唱的一致性。YuE 的分界线就画在这里。它的目标输出是带人声的完整歌曲而不是一段音乐氛围。这件事听起来只是多了个人声轨道实际上对模型的要求完全不同模型必须学会把文本歌词映射到时间轴上的演唱上还要在唱的同时把伴奏铺在下面两者节奏要锁在一起。这也是为什么 YuE 这类模型出来的东西你第一次听会觉得居然真在唱但细听又会觉得咬字有些含糊——它是在两条完全不同的模态之间做对齐难度摆在那儿。判断一个音乐生成项目值不值得投入我一般看三点输出是不是带人声、结构能不能控制、权重是不是开放。前两点是能力问题第三点是工程问题。YuE 在这三点上给出的答案都是肯定的这也是它在开源圈子里讨论度一直不低的原因。1.2 三种任务模式其实对应三种不同的使用场景把 YuE 当成一个只能写歌的黑盒是浪费。它的能力实际上可以拆成三种模式每种模式对应的使用场景完全不同。第一种是歌词成曲也就是输入一段带结构标记的歌词文本加一组风格标签模型直接产出整首歌。这是最常用、也是最出圈的模式。适合的场景是自己写了词但不会编曲、不想花时间找伴奏的人或者需要批量产出 demo 用来筛选旋律走向的创作者。第二种是音乐续写。给模型一段已有的音频作为前文让它往后接。这个模式在实际工作里的价值被低估了——你可以拿一段自己喜欢的、已获得授权的伴奏开头让模型顺着这个调性和速度往下写出来的东西至少在风格上是一致的。做播客片头、短视频背景音乐的时候这个模式比从零生成好控制得多。第三种是纯器乐生成。把歌词位置留空或者只给风格标签模型会走器乐路线。这条路出来的结果不一定是 YuE 最强的部分但胜在速度快、可控性高适合需要大量素材的场景。提示三种模式最好分开测试不要用同一套参数反复横跳。我一开始图省事把歌词模式和续写模式混在一个脚本里跑结果参数相互污染排查了很久才发现是输入格式本身没对齐。1.3 底座是 LLaMA 系的解码器这一点决定了它的全部脾气YuE 的技术底座并不神秘它走的是把音频变成离散 token然后用语言模型去预测下一个 token这条路主干是一个 LLaMA 系的 Transformer 解码器。理解了这一点它后面所有的设计取舍就都能解释通了。为什么选语言模型这条路因为歌词本身就是文本文本的建模方法已经很成熟。把音频也离散化成一套 token 词表之后歌词和音频就变成了同一种东西——都是 token 序列。模型不再需要处理文本到波形这种跨模态映射而是退化成序列到序列这个已经被研究透的问题。这是过去几年音频生成领域一个很关键的思路转向。但代价也很明显。一个 LLaMA 系模型它的强项是几千到几万 token 的上下文。而一首四分钟的立体声歌曲如果按常见音频编解码器的压缩率算下来token 数量可以达到几十万这个量级。这个长度远远超出了普通 Transformer 能舒服处理的范围也直接催生了下一节要讲的两阶段设计和滚动缓存机制。你在使用中遇到的很多怪现象追到根上都是这个长度问题导致的。2. 两阶段生成管线拆解7B 定骨架、1B 补细节2.1 Stage 1 和 Stage 2 各自在忙什么YuE 的推理管线不是单模型的它分成两个阶段这是理解它行为的关键。Stage 1是一个规模较大的语言模型承担的是作曲和编曲决策的角色。它接收歌词文本、风格标签以及可选的参考音频输出的是粗粒度的音乐 token 序列。你可以把它理解为一位快速写谱的编曲人整体结构在哪、主歌什么时候进、副歌怎么走、风格是大调还是小调这些长程决策在这一阶段被定下来。Stage 2则是一个规模小得多的模型负责在 Stage 1 的结果上做精修。它不去改变宏观结构只专注于把音色细节、人声的细腻程度、高频部分补上去。它的工作更像是混音师在已有工程上做局部调整。为什么要拆成两步因为一次性直接生成高保真的完整长音频序列长度和计算量会同时失控。把结构决策和细节填充解耦之后第一阶段可以在一套相对粗糙但序列更短的表示上把整首歌的骨架铺完第二阶段再在这套骨架上做局部精细化。这个思路在图像生成领域其实很常见——先出一个低分辨率的 latent再逐步 refine而不是一步到位画出一张高清图。从资源消耗角度看这个拆分也是有意义的。Stage 1 的模型大、跑得慢但它处理的 token 数相对少Stage 2 的模型小、跑得快但要处理更密的 token。总体算下来比单模型直接硬扛要划算。2.2 长序列问题是怎么被绕过去的这是我们前面留下的坑一首歌几十万 token模型怎么处理得过来YuE 的思路可以概括为两方面。一方面是多码本的音频表示把音频在时间上做较大粒度的压缩之后再用若干层级的码本来补足细节。粗粒度和细粒度分开建模粗的那层负责长程结构细的那层负责音质。这样 Stage 1 面对的序列长度就被压到了一个可以处理的量级。另一方面是滚动式的 KV 缓存。Transformer 在自回归生成时每一步都要看前面所有已经生成的 token这就是 KV 缓存。序列一长缓存直接把显存吃干。滚动窗口的做法是只保留最近一段的缓存更早的历史信息被压缩或者丢弃。代价是模型对很久之前那一段的记忆会变弱收益是它终于能连续生成几分钟的音频而不崩。理解了这一层你就能预判一个现象越到后面歌曲的一致性越可能掉。前面铺的结构模型记得清楚到了三分钟以后早期定的调性和主题可能会漂。这不是玄学是滚动窗口的必然结果。2.3 从 token 到 44.1kHz 立体声解码这一环两阶段跑完之后你手上拿到的还是一堆 token得有一个声码器把它们变回波形。YuE 的输出是 44.1kHz 的立体声 wav这个采样率对音乐场景来说是够用的——它比语音领域的 16kHz、24kHz 高出不少能做到这个规格说明整个音频编解码链路是按音乐而不是按语音来设计的。但这不代表它出来就是成品级的音质。44.1kHz 只是采样率它决定的是一秒钟采多少个点不代表内容本身有多干净。我在实测里明显感觉到人声部分高频会有一种被压过的感觉尤其是齿音和爆破音听起来不够透。这跟音频编解码器的量化损失直接相关——把连续的波形离散成有限词表里的 token这个过程中必然有信息丢。Stage 2 的精细化和后面的声码器只能尽力补补不回来就是补不回来。注意拿到 wav 之后不要急着调 EQ 去补高频。频段是补不回来的硬拉只会把底噪一起拉上来。正确的做法是接受它是一条 demo 级别的音轨用后期的定位来放大它的优势而不是把它当成录音棚成品去修。3. 本地跑通 YuE 的环境账本显存、依赖与最小命令3.1 24GB 是底线24GB 能跑和24GB 跑得舒服是两回事官方给出的显存门槛大致在 24GB 这个档位也就是一张 4090 或者 A10 这个级别的卡。但这个数字要辩证看。24GB 能跑前提是你的参数设得很保守生成时长短、分段数少、batch size 压到 1、KV 缓存不设太大。如果你把生成时长拉到四分钟以上又想一次性出完整首很容易就在 Stage 1 那一步直接爆掉。我自己的经验是24GB 卡上做单首完整歌曲的生成需要配合分段策略把整首歌拆成几段分别生成再拼而不是指望一口气吐出来。40GB 和 80GB 的卡上情况会宽松很多可以用更大的 batch、更长的单段长度整体迭代效率高一个档次。所以如果你是在做批量生成卡的选择直接决定了你的产出节奏。另外磁盘也要提前算好两组模型权重加起来体量不小加上输出音频和中间缓存我一般会预留 100GB 以上的空间避免跑到一半写满盘。硬件档位典型可用策略适合的场景24GB 消费级卡短段生成 分段拼接batch 压到 1个人试玩、单曲实验40GB 数据中心卡单首完整生成中等 batch小批量 demo 产出80GB 及以上长时长单段、较大 batch、并行多首批量素材生产、微调实验3.2 依赖安装里最卡人的三个环节环境搭建这段我想说点实在的。YuE 的依赖列表本身不算长但有几个环节特别容易把人卡住。第一个是注意力加速库的编译。这类库通常需要和你的 PyTorch 版本、CUDA 版本严丝合缝地对应版本对不上就是编译报错。我建议先用nvcc --version和python -c import torch; print(torch.__version__, torch.version.cuda)把两个版本号确认为一致再动手装。安装的时候记得带上--no-build-isolation让它复用当前环境里已经装好的 torch否则它可能自己拉一个不同版本下来越装越乱。# 先确认版本对齐再考虑安装加速库 nvcc --version python -c import torch; print(torch.__version__, torch.version.cuda) # 复用当前环境的 torch 进行安装避免依赖被替换 pip install flash-attn --no-build-isolation第二个是音频解码相关的系统依赖。这类库经常依赖底层的音频读写组件如果你的系统里缺了会在导入阶段就报错而不是在推理时报错容易让人误以为是模型问题。遇到导入失败先看错误信息里有没有提到具体的音频库名字缺什么补什么。第三个是模型权重下载。Stage 1 和 Stage 2 是分开的两组权重加上音频编解码器本身的权重加起来的下载量不小。我建议提前把下载脚本挂上用后台跑中途断了能续传。千万别在推理脚本里现场拉权重一旦网络抖动就是一次白等。3.3 最小可用的一条命令长什么样把环境弄干净之后第一次跑我不建议直接上完整歌曲。用两三行歌词、短时长的配置先把链路走通一遍确认每一步都能出东西再去调参。推理脚本的参数形态大致是这样的思路指定 Stage 1 和 Stage 2 的模型路径、指定风格标签文件和歌词文件、设定生成的段数和 batch、指定输出目录。不同版本的脚本参数名会有出入具体以你拉下来的官方示例为准。python infer.py \ --stage1_model /path/to/stage1 \ --stage2_model /path/to/stage2 \ --genre_txt ./prompt/genre.txt \ --lyrics_txt ./prompt/lyrics.txt \ --run_n_segments 2 \ --stage2_batch_size 1 \ --output_dir ./output参数里的run_n_segments是控制生成段数的段数越多总时长越长显存占用也越大。第一次跑就设成 2出来半分钟左右的音频确认能正常出声、人声能听清再往上加。提示第一次跑通之后把当时的完整命令、参数和输出文件一起存成一个记录文件。YuE 这类模型的结果随机性比较大你很难保证第二次能复现出完全一样的配置留个记录能省下大量回溯时间。4. 歌词与风格标签怎么写才能出片4.1 结构标记是你能控制歌曲走向的唯一手段这一节是我踩坑最多的部分也是我认为区分能用和用得好的关键。歌词文件不能只是一坨文字它需要结构标记。模型靠这些标记来判断什么时候该进主歌、什么时候该起副歌。常见的标记就是[verse]、[chorus]、[bridge]、[intro]、[outro]这一类。你写得越清楚出来的歌曲结构越接近你的预期。[intro] [verse] 走过那条街口 灯光还亮着 谁在低声说着 从前的承诺 [chorus] 如果时间可以 慢一点走 我想再看看 那年的路口 [outro]我强烈建议每一段都显式标出来不要省。省略标记之后模型会自己猜结构结果往往是副歌提前出现、或者整首歌平铺直叙没有起伏。另外标记之间要留空行让解析的时候能清楚区分段落边界。还有一个细节每行歌词的长度要控制。中文的话一行控制在 8 到 12 个字之间是比较舒服的区间。太短了会显得拖沓模型可能把单字拉得很长太长了会被挤成快节奏咬字直接糊成一团。我试过把一整句话二十多个字塞进一行出来的结果是那段被压缩得几乎听不出词。4.2 风格标签的粒度和顺序都有讲究风格标签是另一条控制线。它的写法直接影响模型往哪个方向走。第一个原则是用英文标签。这不是崇洋而是训练数据里风格描述大概率是英文为主用英文标签命中的概率高得多。你写流行、女声、钢琴和写 pop, female vocal, piano 出来的结果差距可能非常明显。第二个原则是控制在五到八个标签之间。标签太少模型没有约束出来的东西随机标签太多各个条件会互相打架最后得到一个四不像。我一般按这个顺序组织整体曲风在前、人声特征居中、主要乐器随后、情绪词收尾。pop, ballad, female vocal, piano, strings, emotional, slow tempo第三个原则是主动指定人声性别。如果你不写模型会随机决定跑三次可能两次是女声一次是男声。写成 male vocal 或 female vocal 能大幅提升一致性但也不是 100% 稳——这个模型的随机性就是比较大后面我会专门讲怎么应对。4.3 采样参数温度、核采样和引导强度怎么取舍参数调优这块我按重要性排个序。引导强度可能是最影响贴不贴 prompt的一个参数。它调高会让输出更紧贴你的风格标签和歌词但调太高会让音频变得干硬、不自然甚至出现失真。调低则自由发挥空间大但可能完全跑偏。我的经验是在中间偏低一点的位置找一个平衡宁可稍微松一点也不要太紧。温度控制随机性。温度低结果稳定但容易重复温度高有惊喜但也容易乱。做单曲精修的时候我会调低让它稳定复现一个方向做素材批量生成的时候会调高多出几个不同版本再挑。重复惩罚这个参数在音乐生成里比在文本生成里更重要。音乐天然有重复结构副歌就是要重复的所以惩罚给太重会把该重复的地方也压掉整首歌变得散给太轻又会出现一段旋律无限循环停不下来。这个参数需要针对你的歌曲结构单独试。参数调高的效果调低的效果我常用的策略引导强度更贴 prompt但音色变硬更自由但容易跑偏中等偏低优先保自然度温度更多变化也可能更乱稳定但容易重复精修调低批量调高重复惩罚减少循环但结构可能变散保留重复但可能停不下来按歌曲结构单独试5. 实测踩坑记录从人声糊到显存爆炸的完整排查5.1 中文咬字含糊这是压缩损失不是参数问题这是我遇到的第一个、也是最难绕开的问题。生成出来的中文歌人声音色是对的旋律也是对的但咬字就是有一种含着东西唱的感觉尤其是声母部分听上去含糊。我一开始以为是参数没调好试了提高引导强度、换标签写法、甚至换了不同的歌词写法效果都不明显。后来才想明白这个问题的根因在音频编解码这一层把连续波形离散成有限词表里的 token这个过程本身就有信息损失。中文的声母信息集中在很短的瞬态里压缩之后首当其冲被削掉的就是这部分。能做的缓解手段有限。一是把歌词写得字正腔圆一些避免太多连读和口语化的吞音二是降低演唱速度给每个字更多的时值模型有更多 token 去表达一个音节三是在后期用修音工具做人工干预。指望通过调参彻底解决我个人认为不现实。5.2 时间轴对不齐的三种典型表现时间轴问题是第二类高频故障具体表现有三种。第一种是副歌提前。你明明在歌词里把[chorus]放在第二段模型却在第一段就把它唱出来了。这通常是因为结构标记没写清楚或者段落之间的歌词长度差异太大模型自己做了重排。第二种是某一段被吞掉。整首歌里有一段歌词完全没有对应的演唱直接跳到下一段。这种情况我遇到最多的是发生在段落特别短的时候比如只有一两行的过渡段。第三种是结尾拖长。歌已经唱完了后面还挂着十几秒的纯伴奏或者静音。排查的思路其实很统一先确认结构标记的解析是否正确再看段落长度是否均衡最后才是调参数。我自己的经验是把每段歌词的行数控制在四到六行段落之间长度差别不要太大能显著减少时间轴漂移。至于结尾拖长最简单的办法是后期手动裁掉不用跟模型较劲。5.3 显存爆炸的完整排查链路显存溢出是我踩得最惨的一次这里完整讲一下当时的排查过程因为它很典型。现象是跑 Stage 1 跑到大概一半的时候直接崩报显存不足。我第一反应是卡不行差点就去租更大显存的机器。但停下来想了一下同样的卡跑短片段是没问题的说明不是卡的绝对容量问题而是跟序列长度相关。顺着这个方向排查第二站是生成段数。段数越多Stage 1 需要维持的 KV 缓存越长占用是线性增长的。我把段数从 5 降到 3能跑完了但确实没有解决根本问题。第三站是单段长度。这个参数和段数是乘法关系两个一起放大会直接把占用顶上去。我发现自己之前只调了段数没动单段长度等于只解决了一半。第四站才回到批量大小。Stage 2 的 batch size 我一开始设得比较大想着小模型跑得快可以多吃点。但 Stage 2 处理的是更密的 tokenbatch 一大占用的峰值会非常陡。压到 1 之后就稳了。最终的结论是把生成拆成多次短段每次跑完就落盘然后再拼接。这样做牺牲的是段与段之间的连贯性但换来的是稳定跑完。对于做素材来说这个交换是划算的。注意显存溢出最好在 Stage 1 阶段就控制住不要指望 Stage 2 能救。Stage 1 一旦崩前面生成的 token 全部作废重跑的成本远高于一开始就保守配置。5.4 结果随机性大怎么把它变成优势同一个 prompt、同一组参数、同一个种子跑出来的结果仍然可能差得挺远。这一点刚上手的时候会让人很挫败但用久了会发现它其实是个机会。我的做法是批量跑多个版本再人工筛选。同一份歌词跑五到八次出来的可能是抒情版、摇滚版、民谣版虽然平均质量参差但偶尔会蹦出一个超出预期的版本。对于创意工作来说这种抽卡式的产出方式某种意义上比稳定但平庸的输出更有价值。代价是时间成本。所以要提前规划好什么时候用精调参数求稳定什么时候用放宽参数求多样。我一般把前者留给已经确定方向的歌把后者留给还在找感觉的阶段。6. 拿到音频之后分轨、修音、拼接与合规6.1 分轨和响度处理是必经的两步生成出来的 wav 是一整条立体声混音人声和伴奏搅在一起。如果你想做人声替换、想单独调整伴奏第一步必须是分轨。分轨工具这几年已经很成熟把人声、鼓、贝斯、其他乐器拆成四条甚至更多轨道的方案不少。拆完之后你会发现一个规律YuE 生成的人声轨道往往比真实录音的人声要薄一些因为它的高频在生成阶段就有损失。这就回到我前面说的那点——接受它是 demo 级别不要试图用 EQ 硬补。响度是另一件必须做的事。模型输出的响度普遍偏低而且不同片段之间的响度不一致。批量生成之后如果不做统一拼接起来会很难听。我的习惯是统一归一到流媒体平台常用的响度标准这一步用免费的响度分析工具就能做。6.2 多段拼接的接缝怎么处理如果你是按前面说的分段生成再拼接缝就是一个绕不开的问题。两段音频在拼点上的调性、速度、相位都可能对不上直接硬接会有一声明显的咔。我的处理顺序是先做速度对齐确保两段的 BPM 一致再做调性检查如果差半个音整段会非常别扭最后在拼点做交叉淡化用几十毫秒的淡入淡出把接缝抹平。这套流程听起来麻烦但做熟之后每首歌也就几分钟的事。还有一种更省事的做法在生成的时候就让相邻两段共享一小段重叠区拼接的时候用重叠部分做对齐。这个思路在音频拼接里很常见效果比硬切好不少。6.3 版权和合规上必须自己心里有数这一块我不想说得太教条但有几点必须提醒。第一模型的训练数据来源在开源音乐生成领域一直是有讨论的话题不同项目的处理方式不一样。你自己要用生成结果做什么需要提前想清楚用途和边界。第二纯 AI 生成的音频在不同平台上的政策不一样。有的平台要求标注有的有限制。发布之前先看清楚你目标平台的规定别等作品做完了才发现不能发。第三如果你在生成时用了参考音频那这段参考音频本身必须是你有权使用的。这一点很容易被忽略尤其是做续写的时候随手拿一段网上下载的伴奏做种子风险是实实在在的。第四署名和二次创作的边界。你自己的歌词、自己的编曲思路加 AI 的生成结果这个组合的署名方式目前行业里还没有统一标准保守一点总没错。7. 想把它用得更深还能往哪几个方向走7.1 用轻量微调把风格固定下来基础的 prompt 控制只能做到大致往某个方向走如果你有一个非常具体的风格想要靠标签描述是很难写准的。这时候可以考虑做轻量微调。思路是准备一批风格统一的音频素材用低秩适配这类参数高效的微调方法在已有的权重上挂一个小规模的适配层。这样的好处是训练成本低、不容易把原模型的能力训坏而且不同的适配层可以随时切换等于给你自己攒了一套风格库。需要提醒的是微调这件事对数据质量的要求高于对数据量的要求。二三十条干净、风格一致的素材效果往往比几百条杂七杂八的素材好。我见过不少人一上来就堆几百小时的数据结果模型学了一堆互相矛盾的东西反而不如不微调。7.2 把它当素材生成器而不是成品生成器这是我在用了几个月之后最大的心态转变。一开始我总想着让模型直接给我一首能发的歌结果是反复调参、反复失望。后来我改了用法把 YuE 当成一个能快速产出旋律灵感的工具一次跑十个版本从里面挑出两三段有意思的动机然后用常规的编曲手段把它们发展成完整的作品。这个用法下模型的质量缺陷就不再是致命问题了。它的人声糊、时间轴漂、结尾拖长这些在素材的定位下都可以接受因为你本来就要人工干预。真正有价值的是它能在几分钟内给你十个你原本想不到的旋律方向这个是人力做不到的。我把这个定位分享给几个做独立音乐的朋友反馈都还不错。有人把它当写歌卡壳时的破局工具有人专门用它生成副歌的候选旋律然后自己填词重新编曲。这个模型最大的价值可能不在于它能生成什么而在于它能帮你跳出自己的思维定式。7.3 参数和流程都值得沉淀成自己的模板最后说个习惯上的事。YuE 这类模型的可复现性不算好同一个配置跑两次结果可能差很多。所以我强烈建议把每次成功跑通的完整参数组合记录下来歌词文件、标签文件、段数、batch、采样参数、种子全部存成一个独立的目录。积累到十几个模板之后你会发现某些参数组合在特定风格上是稳定的这时候就不需要每次从头试了。我自己现在有三套常用模板一套用于抒情慢歌一套用于节奏感强的流行一套用于器乐背景各自的参数边界都摸得比较清楚出片效率比刚上手的时候高了好几倍。最后分享一个我踩过几次坑才总结出来的小经验先确定歌词再调风格最后调参数。很多人是反过来的拿到模型先调参数找感觉歌词随便写两句结果调出来的参数根本不适用于真正的歌词。顺序对了返工能少一大半。