YuE 这个名字最近在音频生成的圈子里被聊得挺多。我第一次注意到它是有人丢出来一段两分多钟的完整歌曲有前奏、主歌进副歌、有人声也有伴奏段落切换干净而且是在自己机器上跑出来的——不是某个云端服务生成完再下载。这对做音乐、做内容、做音视频工具的人来说意味着一个很实在的选项整曲生成这件事第一次有了能装在自己硬盘上的开源方案。YuE 的核心能力可以一句话概括给它一段歌词和一组风格描述它输出一首带人声和伴奏的完整歌曲而不是只给一段伴奏也不是只给一段朗读式的人声。适合谁三类人值得认真看看。第一类是做音乐科技产品、想在自己的工具链里塞一个作曲引擎的开发者第二类是自己写词但不会编曲、想把 demo 做出来的创作者第三类是想搞清楚长音频生成到底难在哪的技术爱好者。这篇文章我不打算把它讲成文档复读而是按我实际部署和使用的顺序把定位、原理、环境、提示词、参数、翻车记录一次讲透。1. YuE 到底是什么先把定位和边界划清楚1.1 它和常见的音频生成模型不是一回事很多人第一次接触音频生成用的是那种给一句描述出一段 30 秒氛围音乐的模型。这类模型很有用但它们的目标是产出一段好听的音频素材唱不唱歌、歌词对不对得上它们基本不管。YuE 的目标完全不同它要产出的是一首结构完整的歌输入是带段落标记的歌词和风格标签输出是人声轨 伴奏轨。这个差别听起来只是多了个歌词输入实际上工程难度差了一个量级。原因有三点我拆开说。第一是时长。30 秒的音频模型的上下文压力很小一首两三分钟的歌采样点是前者的好几倍。音频不像文本一个词就是一个 token一秒钟 16 kHz 的波形就是 16000 个数直接建模序列会爆炸。所以所有能生成长音频的方案第一步都必须解决把音频压缩成短 token 序列。第二是人声与伴奏的对齐。人声和伴奏在时间上必须严丝合缝早半拍晚半拍都会立刻听出来不对劲。如果模型把两者当成一路音频去生成很容易出现伴奏跟得上但人声飘了或者人声稳了但和声打架。第三是歌词与演唱的对应。歌词里一行字要唱多久、哪里断句、哪里拉长音这些在乐谱上是明确的但模型只有文本它得自己学会这几个字应该占一个小节。YuE 对这三个问题的处理方式构成了它整套设计的主线后面几节我会逐个拆。1.2 一张对照表看清楚各自适用场景为了让你少走弯路我把常见的几类方案放在一起对一下。注意这里的云端整曲服务指的是那类在线出整首歌、但模型和权重不公开的方案。维度YuE 这类开源整曲模型纯伴奏/氛围音频生成模型云端整曲生成服务输入带段落标记的歌词 风格标签文本描述 / 旋律片段文本描述 歌词输出人声轨、伴奏轨可分开拿单路音频通常无人声成品混音一般不分轨部署方式本地或自有显卡服务器本地即可门槛低只能在对方平台上用可控性高模型、参数、分轨都能改中主要靠提示词低接口给什么就用什么二次开发可以做微调、接进自己的产品可以做微调基本不行上手成本需要显卡和一点环境配置能力低最低适合场景工具集成、批量生产、研究配乐素材、氛围铺底快速验证创意我看完这张表之后的判断很直接如果你只是偶尔想做一首歌发朋友圈用在线服务更省事但如果你想把生成歌曲这件事变成自己产品里的一个功能或者想大批量产出、想控制每一轨那 YuE 这类开源方案的价值就出来了。1.3 别硬上的几种情况有三种需求我不建议用 YuE 去做硬上会浪费很多时间。一是要求接近专业录音棚的成品音质。YuE 的原始输出采样率不高官方配套了一个升采样环节把结果拉到常见的高采样率听感会明显改善但升采样是补出来的细节不是原本就有。要做正式发行级别的作品我建议把它当成编曲和演唱的草图后面拿分轨进 DAW 重混。二是要求任意语言的演唱。它的训练数据以中英文歌曲为主这两种语言的效果相对最好其他语种会明显吃力咬字容易含糊。三是要求逐句精确控制旋律。它是给定歌词和风格让模型自己编旋律不接受你指定这句要唱 do re mi。想控旋律得走另外的技术路线。2. 拆开看原理一首歌是怎么被切成一串 token 的2.1 双轨解耦把人声和伴奏当成两件事来建模这是 YuE 最核心的设计取向也是最值得学的一点。传统做法是把整首歌当成一路音频去建模好处是简单坏处是模型得同时学人声怎么唱和编曲怎么配两种分布混在一起长序列上很容易互相干扰。YuE 换了个思路把人声轨和伴奏轨拆成两条序列分别建模最后再合起来。你可以把它类比成录音棚的工作流程。真实录制时歌手在隔音间唱乐手在另一间弹两路信号分别进不同的轨道混音师最后按时间对齐。YuE 在模型层面复刻了这个结构——它让模型先分别学人声轨应该长什么样和伴奏轨应该长什么样这样每一路的建模压力小了很多风格也更稳定。代价是什么两轨必须严格对齐。如果人声和伴奏各自生成得都很好但时间轴偏了半秒结果就是废的。所以模型内部有一套结构标记类似[start]、[bar]、[sep]、[end]这类特殊 token来锚定时间位置让两条轨在生成时共享同一套时间坐标。你在写歌词时用的[verse]、[chorus]标记某种程度上是在帮它做这种对齐。2.2 X-Codec语义 token 管唱什么声学 token 管像什么前面说过一秒钟的原始波形数据量大到没法直接建模必须先压缩。YuE 用的压缩方案叫 X-Codec思路是把音频压成两层不同性质的 token。第一层是语义 token。做法是拿一个在大规模语音数据上预训练过的自监督模型把音频抽成特征再离散化成 token。这层 token 捕捉的偏语言层的信息发音、音素、音节边界、大致韵律。它不太关心音色好不好听关心的是这里发出了什么音。第二层是声学 token。做法是拿神经音频编解码器的多级量化向量捕捉音色、混响、演奏质感、高频细节这类听觉层的信息。它关心的是这个音听起来是什么质感。这个分层的思路在语音合成领域已经很成熟了先确定说什么再决定像谁在说。搬到音乐上就是先确定唱什么音再决定用什么音色唱。分层带来的直接好处是训练可以分阶段做。先让大模型专心学生成语义 token这是最难、最吃算力的一步再用一个相对小的模型学从语义 token 映射到声学 token。分工明确每一阶段的目标都更干净。坏处也在这里两阶段之间的误差会累积。我实测遇到过一个典型现象stage1 生成的语义序列是对的但 stage2 的音色映射没跟上听起来就像嘴里含着东西在唱。这种问题不是提示词能救的通常得靠调参或者换随机种子。2.3 两阶段生成先搭骨架再补血肉按官方放出和我在本地跑的配置整条链路大致是这样几步。第一步stage1 模型接收歌词和风格标签生成两轨的语义 token 序列。这一步决定了整首歌的骨架段落怎么排、旋律走向大概什么样、哪里进副歌、哪里留空当。这一阶段是主模型参数量最大。第二步stage2 模型拿 stage1 的输出把语义 token 逐段映射成声学 token。这一步决定音色和质感。它的参数量比 stage1 小很多跑起来快得多。第三步X-Codec 解码器把声学 token 还原成波形得到人声轨和伴奏轨两路音频。第四步升采样环节把低采样率的输出拉高。这一步是可选的但你如果在意听感基本都会开。四个步骤里第一步最慢也最吃显存第三步几乎是瞬时的。实际用的时候如果你的显卡吃紧可以考虑把 stage1 和 stage2 分两次跑中间结果落盘这样峰值显存压力会小一些。2.4 长曲一致性从哪来一首三分钟的歌最怕的是前 30 秒很像样后面开始跑偏。YuE 保证长曲一致性靠的是三招。第一招是分段生成 上下文携带。它不会一口气把整首歌生成完而是切段处理但段与段之间会把上一段尾部的 token 作为下一段的上下文输入。这样第二段知道前面唱到哪了不会突然换风格。第二招是风格锚点。你给的风格标签是全局生效的一段段生成时都会被带上避免风格漂移。第三招是参考音频引导可选。你截一段 10 到 30 秒的干净片段丢进去模型会用它作为音色和风格的锚让输出往那个方向靠。这一招效果很明显但也要注意版权问题别拿别人有版权的作品直接做商用素材。理解了这三招你就能明白为什么歌词断句和风格描述这两个看似外围的东西会这么大幅度影响结果——它们本质上是模型判断这是第几段接下来该往哪走的依据。3. 环境搭建从零到跑出第一段音频3.1 硬件与依赖清单先说硬件这是最容易劝退的一环。YuE 的 stage1 是十亿级别往上走的大模型对显存要求不低。下面是我自己这套和推荐配置的对照。项目我的配置说明GPU单卡 24 GB 显存跑 stage1 的必要条件实测峰值吃紧但不溢出系统内存32 GB权重加载和音频处理都需要余量磁盘预留 30 GB 以上模型权重 中间产物 输出音频Python3.10版本太新容易踩依赖坑PyTorch2.x 配对应 CUDA版本必须和显卡驱动匹配注意力加速库强烈建议装明显省显存、明显提速但编译常出问题ffmpeg必须处理参考音频、格式转换音频处理库常规那一套读写、重采样、拼接几个我踩过的点值得单独说。提示注意力加速库编译失败是高频问题别死磕。先跑通再说编译不过就退回默认注意力实现速度慢一点但结果一样。提示权重下载是几十 GB 级别的网络不稳会断。建议用支持断点续传的下载方式下载完记得核对文件完整性不完整的权重要么加载报错要么加载成功但生成结果莫名其妙。3.2 歌词文件的写法与风格提示词这是很多人第一次上手最容易忽略的部分。YuE 的输入是两个纯文本文件一个放歌词一个放风格标签。歌词文件的基本骨架长这样段落标记单独成行[verse] 夜色把街道收进口袋 我数着路灯慢慢走开 [chorus] 如果风还记得你的名字 就让它替我轻轻说一次 [instrumental] [verse] ...几个关键约定。段落标记用方括号包住单独占一行纯器乐段落用[instrumental]占位下面不要填词段落之间用空行隔开这会影响模型判断段落边界。风格标签文件就是一行逗号分隔的描述比如pop, female vocal, warm piano, soft synth pad, 92 bpm, sentimental, clean mix我建议按流派 编制 人声 速度 情绪 制作这个顺序写后面第 4 节会展开讲为什么。3.3 完整执行命令与参数逐条解读仓库里提供的推理入口大致是下面这个形态。参数名以你拉下来的版本为准跑之前先看一眼帮助信息我这里是常用的骨架python infer.py \ --cuda_idx 0 \ --stage1_model m-a-p/YuE-s1-7B-anneal-en-cot \ --stage2_model m-a-p/YuE-s2-1B-general \ --genre_txt genre.txt \ --lyrics_txt lyrics.txt \ --run_n_segments 2 \ --stage2_batch_size 4 \ --output_dir ./output \ --max_new_tokens 3000 \ --repetition_penalty 1.1 \ --seed 42每个参数我按实际作用解释一遍这比背文档有用得多。参数作用我的常用值调整逻辑cuda_idx指定使用的显卡编号0多卡时列多个编号能显著提速stage1_model骨架生成模型主线大模型决定了唱得像不像样别随便换stage2_model音色映射模型通用版决定音色质感影响咬字清晰度genre_txt风格标签文件路径genre.txt全局风格锚点lyrics_txt歌词文件路径lyrics.txt段落结构就是从这里读的run_n_segments生成段数先 1 后 2第一次跑务必设 1先验证风格stage2_batch_size第二阶段批大小4显存不够就往下调时间换空间output_dir输出目录./output每首歌单独建目录方便对比max_new_tokens单段 token 预算3000太小会截断太大会重复打转repetition_penalty重复惩罚1.1唱来唱去一个调就往上加seed随机种子42做 A/B 对比时固定住只改一个变量参考音频的用法是在上面基础上加几项指定音频路径和截取的时间区间--prompt_audio ./ref_clip.wav \ --prompt_start_time 0 \ --prompt_end_time 25这里有个非常实用的习惯第一次跑永远只用 1 段。因为完整一首歌跑一次可能十几分钟风格不对就是纯浪费。先用 1 段验证风格标签和歌词格式确认方向对了再把段数加上去。3.4 输出文件与后处理跑完之后输出目录里通常会有这几种东西人声轨、伴奏轨、混合好的成品以及中间的过程文件。我的处理流程是这样的。第一步先听伴奏轨。伴奏轨没有人声干扰能最快判断编曲风格对不对、速度稳不稳、有没有中途跑调。第二步再听人声轨。这里重点听咬字清晰度和节奏对不对得上伴奏。如果人声和伴奏之间有轻微错位在 DAW 里手动对一下时间轴往往能救回来。第三步看情况做后处理。常见的处理包括用均衡把人声的中高频稍微提一点把低频的浑浊感切掉对人声做轻度压缩让它更稳给伴奏加一点点侧链闪避让人声更突出。这些不是必须的但做过之后听感提升很明显。第四步保留分轨。这是开源方案相比在线服务的一大优势——你能拿到干净的人声轨和伴奏轨进 DAW 重新混音、加和声、换鼓组都行。4. 提示词与歌词工程决定成败的八成4.1 风格标签的三段式写法风格标签不是越长越好也不是写成一句自然语言指令。它不是聊天模型不擅长理解请让这首歌听起来温暖一些这种描述它吃的是训练数据里高频出现过的风格词。我的写法固定成三段。第一段写流派与编制pop、acoustic folk、city pop、synthwave 这类流派词加上主奏乐器比如 warm piano、clean guitar、synth pad。第二段写人声特征female vocal 或 male vocal可以再加气声、清亮、沙哑这类限定词。第三段写速度、情绪与制作取向92 bpm、sentimental、clean mix、wide stereo 之类。一个我常用的模板city pop, female vocal, bright electric piano, funky bass, 104 bpm, nostalgic, warm analog mix几个反例你应该避开。写一长串互相矛盾的标签比如同时写 aggressive 和 gentle模型会左右为难输出四不像。写太抽象的形容词比如 beautiful、amazing这些词在训练数据里没有稳定的指向基本等于没写。速度不给模型会自己猜猜出来可能和歌词的字数密度不匹配。4.2 歌词结构标记与行数控制段落标记是给模型的路标。常用的有[verse]、[chorus]、[bridge]、[outro]、[instrumental]。我实测下来能不能把这些标记用对直接决定了副歌能不能副起来。原因不复杂模型看到的标记序列本身就是结构先验。它见过大量带这种结构的歌知道[chorus]后面通常情绪更高、配器更满、旋律记忆点更强。你不标它就没有这个先验整首歌容易平铺直叙。行数是另一个坑。我的经验值是一行歌词控制在 8 到 12 个汉字在 90 到 105 bpm 这个区间里比较自然。超过 16 个字模型容易被逼着加快咬字结果是糊成一团。反过来一行只有三四个字它会拖长音如果不加控制就会显得拖沓。段落长度也要控制。一个[verse]写四行比较稳写八行就容易出现后半段开始敷衍的情况。副歌重复的部分可以直接把同样的歌词再写一遍[chorus]模型会理解为这段旋律重复这恰好是流行歌的基本结构。4.3 中文歌词的特殊坑中文歌词有几个英文歌词不会遇到的问题我一条条列出来。多音字。模型的发音来自它学到的语音分布遇到多音字会自己选一个读音未必是你想要的那个。稳妥的做法是换词或者靠上下文把读音暗示出来。语气词和口水词。啊哦吧这类词在演唱里很自然但写太多模型可能把它们当成独立的拍子来处理导致节奏拖沓。少量点缀就好。分行与乐句对齐。中文歌词的分行习惯是一个语义片段一行但乐句的划分是按小节的。如果两者不一致模型会优先照顾行结构出来的效果就是一句话唱完停顿半拍再唱下一句显得断断续续。写的时候可以自己在心里打拍子或者干脆先写英文歌词试出旋律再把中文填进去。不要在一个段里混中英文。除了说唱这种刻意混搭的场景混语言容易让模型在两套发音体系之间来回切咬字稳定性会下降。5. 参数调优与显存权衡5.1 真正影响结果的四个参数跑过几轮之后我发现大部分参数属于不用管真正影响结果的就那么几个。run_n_segments决定长度也决定一致性。段数越多总时长越长但段与段之间的一致性风险也越大。我的做法是每加两段听一遍一旦发现风格开始漂就回到上一档。repetition_penalty决定旋律会不会卡带。这个值我一般在 1.05 到 1.2 之间试。低于 1.05模型容易在同一段里重复同一个动机听起来像卡碟高于 1.2旋律会变得很跳、不连贯副歌的重复记忆点也没了。max_new_tokens决定单段的信息量。设小了一段还没唱完就被切断设大了模型在末尾容易进入不知道该唱什么的状态开始重复或者乱发出声音。经验做法是先按歌词行数估一个值跑一遍看结果裁在哪里再微调。seed是做对比实验的前提。想判断某个风格词有没有用必须固定 seed只改风格词。seed 一换你不知道结果是风格词带来的还是随机性带来的。5.2 显存不够时的几种降级方案不是每个人都有 24 GB 的卡。我整理了几条实际可走的降级路线按推荐顺序排。方案具体做法代价缩短时长段数降到 1 到 2先做短片段拿不到完整歌曲结构调小批大小把第二阶段的批大小降到 1 或 2生成时间明显变长两阶段分开跑stage1 跑完落盘再单独跑 stage2操作变麻烦但峰值显存下降降低精度用半精度加载个别情况下音质有轻微变化借力在线演示用现成的在线体验页验证效果只能试风格不能批量产出我的建议是如果你的定位是想做产品集成、要批量跑别在降级上抠太久算力成本该花就花如果只是想玩一玩、验证一下这个方向先用在线体验页跑几段听听觉得对路再考虑本地部署能省很多事。6. 常见问题排查速查表这一节是我自己踩坑之后整理的按现象归类遇到问题直接查表。6.1 生成结果层面的问题现象大概率原因处理方式人声和伴奏明显错位段落标记混乱模型没对齐时间轴检查段落标记是否单独成行、空行是否规范咬字含糊、像含着东西第二阶段音色映射没跟上换 seed或把重复惩罚调低一点重跑中途变成纯器乐没人唱歌词段数不够或[instrumental]用错位置补齐歌词段落检查器乐段标记主歌副歌听起来一模一样段落标记重复或风格描述太单一给副歌换情绪词检查标记是否写重旋律反复打转、像卡碟重复惩罚太低上调到 1.15 左右再试结尾突然切断歌词长度和段数不匹配增加段数或精简歌词行数整体发闷、高频缺失原始采样率偏低启用升采样环节风格完全跑偏风格标签矛盾或太抽象按三段式重写标签6.2 环境与依赖层面的问题现象大概率原因处理方式显存溢出批大小或段数过大降批大小、减段数或两阶段分开跑权重加载报错下载不完整或版本不匹配核对文件完整性确认模型版本注意力加速库编译失败编译环境不匹配直接退回默认实现不影响结果参考音频读不进来采样率或格式不支持先用 ffmpeg 转成标准格式再喂进去生成速度慢得离谱没启用加速库或用了 CPU确认实际用的是 GPU检查加速库是否生效6.3 几条不在文档里的实操心得先做短片段再做长曲。我见过太多人第一次就跑三分钟出来不满意又不知道是哪一步出的问题。正确顺序是一段验证风格两段验证段落过渡四段以上验证长曲一致性。每一步都过了再加长。每首歌单独建目录把输入文件一起存进去。风格标签和歌词文件版本一变结果就完全不同。不存输入过两周你自己都复现不出来。参考音频要挑干净的。有掌声、有说话声、有明显现场混响的片段会把噪声也当成风格特征学进去。截取的时候优先选纯器乐段或者干净的人声段。遇到好结果立刻记参数。风格标签、seed、段数、重复惩罚这四个值记下来比截图有用得多。7. 进阶玩法把它当成一个可组装的零件7.1 参考音频做风格与音色迁移前面提过参考音频这条路。用法是截一段 10 到 30 秒的干净片段指定起止时间模型会把这段的特征当成锚点。我实测下来参考片段的影响主要体现在三个方面音色的明亮度和厚度、混响的空间感、以及整体的编曲密度。它对旋律走向的影响相对小一些。也就是说你可以用同一份歌词、同一个 seed只换参考片段得到三首编曲思路相似但质感不同的版本。做 A/B 选型的时候特别好用。注意用别人的作品做参考音频只在你自己研究和试听的范围里用。要做公开发布或者商业用途务必换成自己录制的素材或者使用明确授权可用的音频。7.2 续写、局部重做与分轨二次利用续写的思路是把已有音频的尾部当作引导让模型往后接。这适合前面 40 秒很满意后面想重新来过的场景不用整首重跑。局部重做更实用。如果只是想换掉某一段副歌可以重新生成那一段然后把新片段拼回原来位置。拼接处做一点点淡入淡出基本听不出来。分轨二次利用是我最看重的部分。拿到干净的人声轨和伴奏轨之后可以做的事包括把人声送进修音工具稍微校一下音准给伴奏重新配一套鼓加一层和声垫在人声下面把伴奏的某一段剪掉做成桥段。这些操作在传统的音乐制作里都是常规流程YuE 输出的分轨让你能接进这套流程而不是只能接受一个成品混音。7.3 再往前一步微调与数据准备如果你有自己的曲库想让模型更贴近某种特定风格可以走微调这条路。常用的做法是在预训练权重上做轻量化适配用几百到几千首同风格的作品训练。数据准备上有几个关键点。音频必须干净有噪声的样本会教坏模型必须配上准确的歌词文本歌词和音频不对齐的样本比没有样本更糟风格标签要统一规范别同一类风格写出五种不同的写法。我建议先拿几十首做个小规模验证看风格是不是真的往你期望的方向偏再决定要不要扩量。注意训练数据的来源和授权必须自己确认清楚。数据来源有问题的模型后面做产品会遇到麻烦这一点比技术本身更值得花时间。最后分享一个我一直在用的习惯每次生成了一个自己满意的片段我都会把它单独存档标注好风格标签和参数慢慢攒成一个自己的风格库。时间长了之后你会发现这个库比任何提示词模板都好用——因为它是从你自己的审美里长出来的而不是从别人的模板里抄来的。想换风格的时候直接拿库里的片段当参考音频比重新写一遍标签快得多效果也稳得多。
