企业官网建设流程全解析

1. YuE 到底能干成什么事：先把预期摆正

去年年底刷到这个叫 YuE 的项目时，我第一反应是"又一个生成十几秒氛围音的玩具"。真正跑起来之后发现判断错了——它接的是歌词和风格标签，吐出来的是一首带人声、带伴奏、有主歌副歌结构的完整歌曲，长度能到两三分钟。这件事在开源模型里并不常见，之前大多数音乐生成方案要么只做纯器乐，要么只做人声哼唱片段，把"整首歌"当作一次生成目标的并不多。

YuE 的定位可以这样理解：它想做的事情，相当于给歌词配上一整个编曲团队加一个主唱。你给它一段带结构标记的歌词，再给它几个风格关键词，它会自己决定前奏多长、主歌用什么律动、副歌怎么推上去、间奏插在哪，最后把人声和伴奏一起生成出来。这个过程不需要你懂乐理，也不需要你会用宿主软件，但需要对"歌"这件事本身有一定感觉，否则出来的东西大概率是一堆听起来像歌的音频噪声。

我把它的适用人群分成三类。第一类是独立创作者和小型内容团队，手上有词、有想法，缺的是编曲和演唱资源，用 YuE 快速做出 demo 版本，再决定要不要真金白银投入制作。第二类是研究者和开发者，关心的是音乐这种长序列、多轨、强结构的数据怎么用语言模型的范式去建模，YuE 的架构设计本身就值得拆。第三类是做互动产品和工具的人，想把"输入一句话、输出一首歌"这种能力嵌到自己的应用里，需要评估它的推理成本、生成稳定性和二次开发难度。

需要提前说清楚的边界：YuE 生成的是"能听的歌"，但不是"能直接发的歌"。人声会有细节上的模糊感，混音层次不可能跟专业制作比，偶尔还会出现咬字含糊、段落突然结束这类问题。把它当作一个高效率的创意草稿机，心态就对了；指望它一次输出直接上架，那基本会失望。下面我会从架构逻辑、环境搭建、实操流程、参数调优到踩坑排查，把这一整套走一遍。

1.1 它和普通"AI 音乐"工具的本质差别

市面上不少音乐生成工具走的是"文本到音频"的端到端路线，输入一句描述，模型直接吐一段波形或者一段音频编码。这条路线的优点是自由度大，缺点是长程结构完全不受控——你没法告诉它"第二段副歌要升半个调"或者"这里给我留四拍空的"。YuE 走的是另一条路：把歌词当作结构骨架，用自回归的方式一个 token 一个 token 地"写"出音乐，这跟大语言模型写文章在思路上是同源的。

这个差别的实际意义很大。因为歌词里的[verse]、[chorus]、[bridge]这些标记，在模型眼里就是显式的分段指令。你可以精确控制一首歌有几个主歌、几个副歌、哪里放间奏。哪怕你不写任何标记，整段歌词也会被当作连续文本处理。这种"文本驱动结构"的设计，是我认为 YuE 值得花时间研究的最主要原因。

另一个关键设计是人声和伴奏分开生成。传统做法要么一起生成（容易糊成一团），要么先做伴奏再往里塞人声（人声和伴奏的节奏对不齐）。YuE 的做法更像是让模型分别"唱"一遍、"弹"一遍，最后再合起来。这样做的好处是两方面都能各自优化，坏处是合成环节如果没对齐好，会出现人声和伴奏略微错位的听感。

1.2 支持的语言与风格范围

从模型卡和实际测试看，英语和中文（普通话）的效果最稳，日语、韩语也有对应版本，粤语在部分模型上有支持。这里必须提醒一句：中文的效果明显比英文弱一档，尤其是在咬字清晰度和声调准确性上。我测试同一段歌词分别用英文和中文写，英文版本的完成度通常明显更高。如果你的歌必须用中文，建议歌词写得更口语化、句子更短，给模型减少一点发音推断的负担。

风格方面覆盖得挺广，流行、摇滚、金属、嘻哈、爵士、乡村、古典、电子、R&B 这些常见类型都能识别。但要注意，风格标签是"提示"不是"开关"，标签写得多不代表风格更准，反而可能互相干扰。我试过同时写pop, electronic, dreamy, female vocal四个标签，出来的是四不像；只写dreamy synth pop反而干净得多。这个规律在后面调优章节会展开讲。

2. 架构拆解：一首歌是怎么被一点点"写"出来的

理解架构不是为了炫技，而是为了知道哪些参数能调、哪些调了也没用。YuE 的整体思路可以类比成"两个接力选手"：第一个选手负责把歌的主体框架跑出来，第二个选手负责把细节补上并衔接成完整成品。官方把两个阶段分别叫 Stage-1 和 Stage-2，前者是一个 7B 量级的模型，后者只有 1B 左右。

为什么这么拆？因为长音频的自回归生成计算量是随长度平方级增长的。如果一整首歌都用 7B 模型硬跑，显存和时间都撑不住。拆成两段之后，Stage-1 只需要专注于"把结构和内容生成对"，Stage-2 专注于"把细节和衔接做好"，各自的计算预算都能控制住。这个思路在做长文本生成时也常见：先规划大纲，再逐段扩写。

2.1 音频是怎么变成模型能读的 token 的

这是整个方案里最容易被忽略但最关键的一环。原始波形是每秒四万多个采样点，直接喂给模型不现实。所以需要用音频编解码器把波形压成一串离散 token，模型在这串 token 上做自回归预测，最后再解压回波形。YuE 用的是一套面向音乐设计的编解码方案，能把 44.1kHz 立体声压到大约每秒 50 个 token 的量级。

这个压缩率意味着什么？一首三分钟的歌大概对应九千个 token 左右。对比一下，同样长度的一段中文文本大概也就一两千个 token。所以音乐生成的"序列长度"其实比文本生成还要长，这也是它显存吃紧、速度偏慢的根本原因。理解了这一点，你就能明白为什么减少分段数、降低生成长度能显著提速——它直接砍的是 token 数量。

另外，YuE 用了一个音乐理解模型来提供额外的条件表示。简单说就是让模型在生成的时候"知道自己在做什么类型的音乐"，而不是纯粹从歌词字面出发。这部分在推理阶段是内置的，不需要你额外配置，但它解释了为什么风格标签对结果影响这么大。

2.2 人声与伴奏的分离式生成

前面提到人声和伴奏是分开生成的，这里补充一下为什么这个设计让调参变得更有意思。因为两条轨道独立生成，模型各有各的随机性来源。你固定随机种子之后会发现，同一个种子跑两次，伴奏可能几乎一样，但人声的细节会有差异——反过来也一样。

实际操作中这个特性有两个用法。第一种是"锁定伴奏换人声"：找到一版你满意的伴奏，记下种子和参数，然后在歌词或人声相关的提示上做微调，反复生成，挑一个人声版本更顺耳的。第二种是"人声旋律参考"：部分版本支持传入一段音频片段作为提示，让生成结果在风格或旋律走向上贴近参考，这个在做人声续写或者风格迁移时很有价值。

不过要提醒一句，分离式生成也会带来一个副作用：人声和伴奏的响度平衡是模型自己决定的，有时候人声会被埋得很深。这个问题目前没有特别好的参数直接控制，只能靠多生成几版挑，或者后期用均衡和压缩把中频拉起来。

2.3 文本、歌词、音频三条序列的对齐逻辑

一次完整推理里其实有三条信息流在同时起作用：风格标签构成的文本条件、歌词构成的结构条件、以及 Stage-1 输出的音频 token 序列。Stage-2 要做的事情，就是在这三者之间建立对应关系，把 Stage-1 生成的分段内容拼接平滑，同时避免出现明显的接缝。

这也解释了为什么歌词的写法这么重要。如果歌词段落长度差别极大，比如一段主歌两行、一段副歌十行，模型在分配时间的时候就会失衡，容易出现某一段被拖得特别长。我建议每段歌词控制在四到六行，段落之间行数基本对齐，这样生成出来的结构最规整。这个规律不是官方文档写的，是我自己反复试出来的，后面还会细讲。

注意：不同版本的模型在分阶段策略上有调整，具体实现以官方仓库的代码为准。上面讲的逻辑是我在实际使用中总结出的理解模型，用来指导调参足够用，但不代表官方设计文档。

3. 环境准备：硬件门槛、依赖安装与权重管理

先说硬件。官方建议的显存是 24GB 级别，我用一张 24GB 的卡实测，跑两分半左右的歌、分成三段生成，显存占用峰值大概在 20GB 上下，还有余量。如果用 16GB 的卡，需要把分段数调小、把批量降到 1，并且开一些显存优化选项，速度会明显变慢但能跑通。8GB 的卡基本不用考虑本地跑 Stage-1 的 7B 模型，除非你接受 CPU 卸载带来的十几倍时间成本。

生成耗时方面要有心理预期。在 24GB 卡上，一首两分半的歌端到端大概十几分钟。这个时间包含 Stage-1 的逐 token 生成和 Stage-2 的细化，其中 Stage-1 占大头。如果换成批量推理框架来加速 Stage-1，速度能提升不少，但显存占用会上去，是个典型的取舍。

3.1 依赖安装：把坑先填了

环境这块有几个反复踩的坑，我直接给一套比较稳的流程。核心依赖是 PyTorch、音频处理库、以及用于音频编解码的解码器组件。PyTorch 版本建议用较新的稳定版，老版本可能在算子支持上出问题。

# 创建独立环境，Python 版本建议 3.10 或 3.11 conda create -n yue python=3.10 -y conda activate yue # 安装 PyTorch（以 CUDA 12.1 为例，按你的驱动版本调整） pip install torch torchaudio --index-url https://download.pytorch.org/whl/cu121 # 安装项目依赖 pip install -r requirements.txt # 音频编解码与后处理相关 pip install soundfile librosa numpy scipy

几个容易卡住的地方。第一，某些编解码器组件在安装时会去拉预编译包，如果你的网络环境不稳定，这一步会反复失败，建议提前把对应的 whl 文件下好。第二，librosa在部分系统上会因为底层音频库缺失而报错，Ubuntu 系直接装系统包就能解决。第三，如果你打算用批量推理框架加速，注意它和 PyTorch 版本之间有比较强的绑定关系，先装框架再装 PyTorch 的顺序更保险。

3.2 权重下载与目录规划

权重文件不小，Stage-1 的 7B 模型加上 Stage-2 的 1B 模型，再加音频编解码组件，总共十几个 GB。我建议单独开一个目录管理，不要跟其他项目的缓存混在一起，否则清理的时候很容易误删。

# 建议的目录结构 models/ ├── YuE-s1-7B/ # Stage-1 主体模型 ├── YuE-s2-1B/ # Stage-2 细化模型 ├── xcodec/ # 音频编解码组件 └── muq/ # 音乐理解表示组件

下载方式各版本不太一样，有的提供脚本一键拉取，有的需要手动从模型仓库下载。不管用哪种方式，下完之后建议做一次完整性检查，确认文件大小和清单一致。我就遇到过权重下到 90% 中断、加载时报维度不匹配的情况，排查了半小时才发现是文件不完整。

4. 跑通第一首歌：从歌词文件到成品音频

准备工作做完，接下来是最有成就感的部分——把第一首歌跑出来。整个流程分成三步：写歌词文件、写风格提示、跑推理命令。听起来简单，但每一环都有细节。

4.1 歌词文件怎么写

歌词文件的格式很直接，就是纯文本，用方括号标记段落结构。常见的标记包括主歌、副歌、桥段、间奏、尾声这几类。下面是一个我常用的模板：

[verse] Walking down the empty street tonight Neon signs are humming in the rain I keep your voice inside my pocket Like a coin I never want to spend [chorus] Say it louder, say it once again Every echo sounds like coming home Say it louder, let the city know We were never meant to be alone [verse] Morning comes and folds the shadows up Coffee going cold beside the phone I rehearse the words I never said Practicing a language of my own [chorus] Say it louder, say it once again Every echo sounds like coming home Say it louder, let the city know We were never meant to be alone [bridge] And if the silence takes the night I will hum the melody we lost [inst]

有几个细节必须强调。第一，副歌重复的时候把歌词原样再写一遍，不要写"副歌重复"，模型不理解这种缩写。第二，[inst]表示纯器乐段落，放在你想让编曲单独发挥的地方，通常放结尾当尾奏效果不错。第三，歌词行与行之间不要空行太多，一个段落内部连续写，段落之间空一行，这样模型更容易识别边界。

我测试下来，整首歌的歌词总行数控制在 20 到 30 行最合适。太短，模型没有足够信息撑满两分钟；太长，容易出现后半段敷衍或者结构塌陷。

4.2 风格提示词怎么写

风格文件是一行文本，用逗号分隔标签。我总结了三条经验。第一，标签数量控制在两到四个，超过五个效果反而下降。第二，把"整体风格"放前面，"细节点缀"放后面，比如indie folk, warm acoustic, male vocal，这样模型会先定基调再补细节。第三，人声类型明确写出来，male vocal、female vocal、duet都是有效标签，不写的话模型会随机决定，有时候会出现音色在中途变化的情况。

下面这个写法我用了很多次，稳定性不错：

dreamy synth pop, female vocal, 80s retro

对应的反面例子是这样的：

pop, rock, electronic, dreamy, sad, happy, female vocal, male vocal, fast, slow

后面这种写法里存在互相冲突的标签（快和慢、男声和女声、悲伤和快乐），模型会陷在中间地带，出来的东西模糊不清。

4.3 推理命令与参数详解

核心推理脚本通常接收模型路径、歌词文件、风格文件、输出目录这几类参数。下面是一条典型命令，参数名会随版本变化，用之前先用帮助命令确认一下：

python inference/infer.py \ --stage1_model ./models/YuE-s1-7B \ --stage2_model ./models/YuE-s2-1B \ --genre_txt ./prompts/genre.txt \ --lyrics_txt ./prompts/lyrics.txt \ --output_dir ./outputs/song_001 \ --run_n_segments 3 \ --stage2_batch_size 4 \ --max_new_tokens 3000 \ --temperature 1.0 \ --top_p 0.95 \ --repetition_penalty 1.1 \ --cfg_scale 1.5 \ --seed 42

逐个说这些参数的实际影响。run_n_segments控制生成几段，每段大约五十秒，三段差不多是两分半。这个是显存和时间的主要开关，卡不够就先降到两段。max_new_tokens是每段最多生成多少 token，太小会导致段落提前结束，太大浪费算力还可能生成一堆噪声尾巴，我一般设 3000 左右。

temperature和top_p控制随机性。温度高一点（1.0 到 1.2）出来的东西更有变化，但跑调风险也高；温度低一点（0.8 左右）更稳但容易平淡重复。cfg_scale是引导强度，调高会让结果更贴合风格提示，但太高会让整首歌变得僵硬，我试过 3.0 以上，副歌完全失去了起伏感。

repetition_penalty这个参数值得单独讲。音乐天生是重复的艺术，副歌就是要重复，所以这个值不能设太高，否则模型会刻意避开重复，反而破坏了歌曲结构。1.1 到 1.2 是比较安全的区间，超过 1.3 就开始出现奇怪的旋律跳跃了。

seed是最实用的参数。固定种子之后，同样的输入基本能得到同样的输出，这对于"微调一个参数看效果差异"这种对比实验非常重要。找到满意的版本后，把种子记下来，后续做局部调整时就有了参照系。

4.4 输出文件与后处理

跑完之后输出目录里通常会有几个文件：完整混音、单独人声、单独伴奏。先听混音版判断整体，如果有地方不满意但整体还行，可以拿分轨文件做后期。我常用的后处理动作有三个：用均衡把 200Hz 到 500Hz 之间稍微压一点，人声会清晰很多；在副歌前做一个轻微的响度提升，让动态更明显；如果人声和伴奏有轻微错位，用对齐工具微调一下偏移量。

这些后期动作都不复杂，但效果提升明显。我的经验是，YuE 的原始输出大概能打 6 分，做一轮简单的均衡和响度处理后能到 7 分半，这个提升幅度比反复抽卡要划算得多。

5. 调优实战：从"能听"到"耐听"的几条经验

跑通之后就是调优了。这部分没有标准答案，我给的是自己反复试出来的规律，你可以当成起点。

5.1 歌词结构化的几个实战技巧

第一个技巧是让每段行数对齐。我最初写的歌词是主歌四行、副歌八行，结果生成出来副歌被硬拉长，节奏散掉了。改成主歌副歌都是四行之后，结构立刻紧凑了。原因前面讲过，模型是按歌词长度分配时间的，段落长度差异过大就会失衡。

第二个技巧是在歌词里控制音节节奏。同一段的每一行，音节数尽量接近。英文的话，四行都是七八个音节，出来的律动感明显比参差不齐的要好。中文的话，每行控制在七到十个字比较合适，太多字会挤，太少又会拖。

第三个技巧是避免生僻词和专有名词。模型遇到不认识的词会乱发音，人名、品牌名、缩写尤其容易翻车。我的处理方式是：核心词用常见词汇，实在必须用专有名词，就在旋律上给它安排一个短促的位置，减少模糊处理的暴露。

5.2 采样参数的取舍逻辑

参数调优里我有一个固定的排查顺序，按这个顺序能少走很多弯路：

这张表我贴在显示器边上用了很久，基本上九成的问题照着调就能解决。要强调的是，一次只改一个参数，改完固定种子跑一次做对比。同时改三个参数然后说"效果变好了"，你根本不知道是哪个起了作用。

5.3 抽卡策略：怎么挑出最好的那一版

音乐生成有很强的随机性，同一个配置跑十次，出来的质量方差可能相当大。我一般会分两轮筛选。第一轮用固定种子跑三到五次，快速听开头三十秒和第一段副歌，这两处不行直接淘汰，不用听完。第二轮对留下来的版本完整听一遍，重点听段落衔接处和人声咬字，这两处是问题最集中的地方。

有个提高效率的小技巧：把生成速度降下来换质量。具体做法是把分段数减少到两段先跑一遍探路，歌词和风格确认没问题之后，再用相同的种子和参数跑完整段数。这样能省掉大量在错误配置上浪费的时间。我最开始不懂这个，每次都跑满三段，一个下午只能试四五版，改成两段探路之后效率翻了一倍。

5.4 二次加工能救回多少

前面提过后期处理的价值，这里说得更具体一点。YuE 输出最常见的问题是三条：人声偏闷、动态不足、段落结尾突然。对应的处理方式分别是中高频适度提升、副歌前做响度包络、结尾加一段淡出。

我自己的处理顺序是：先听一遍标出所有问题位置，然后统一做均衡，再做动态处理，最后处理首尾的淡入淡出。整个流程在免费的音频编辑软件里十来分钟能搞定。这一步的价值在于，它能把"明显是 AI 生成"的听感减弱不少，因为 AI 生成的痕迹很多时候就藏在频响分布和动态曲线的规律性上。

提示：后期处理不要过度。我试过用比较激进的压缩和限幅，结果整首歌变得又扁又燥，反而不如原始输出。轻处理、保守一点，效果通常更好。

6. 常见问题排查速查表

这一节是纯干货，都是我实际撞过的墙。

6.1 显存与速度类问题

显存溢出报错怎么办？按优先级依次尝试：减少分段数到 2，把 Stage-2 的批量降到 1，关闭不必要的缓存选项，最后考虑启用模型的分层加载。分层加载会让部分层在需要时才进显存，能省下不少空间，代价是速度下降明显。

跑得特别慢是正常的吗？在消费级 24GB 卡上跑两分半的歌十几分钟是正常范围。如果超过半小时，检查两件事：是不是在用 CPU 跑 Stage-1（用设备查询命令确认），以及是不是分段数设得太高。

能不能同时跑多个任务？不建议。音乐生成对显存的需求是峰值型的，两个任务并行会让两个都变慢甚至都爆显存。排队串行跑反而总时间更短。

6.2 音频质量类问题

人声听不清在唱什么。这是最常见的抱怨。三个处理方向：把歌词写得更简单口语化，把风格标签里加上明确的人声类型，以及在后期把中频提升一点。另外中文歌词的咬字问题天生比英文明显，如果对清晰度要求高，优先考虑英文版本。

生成到一半突然停了。大概率是max_new_tokens设小了，每段的 token 预算不够。调大一档再看。如果调大了还停，检查歌词是不是某一段特别长，导致 token 分配异常。

伴奏和人声对不齐。分离式生成的固有问题，偶发。处理方式是重跑一次换种子，或者用后期工具手动偏移对齐。频率不高的话不用太纠结。

整首歌听起来很"平"。通常是cfg_scale开太高了。降回 1.5 附近，temperature提到 1.0 左右，让模型多一点自发变化。

6.3 合规与使用边界

这部分我必须单独讲，因为很多人会忽略。生成音乐涉及几个层面的问题：训练数据的来源、生成结果的版权归属、以及用于商用时的风险。目前开源音乐生成模型在这几方面的法律边界都还比较模糊，不同地区的规则也不一样。

我的建议是：个人学习、研究、非商业的创意实验尽管放手去做；如果打算用于商业项目，务必先做两件事。第一，确认你所使用模型的具体许可条款，看清楚对生成结果的使用限制。第二，如果结果要公开发布，尽量加入足够的人工创作成分，让作品体现出你自己的编排、后期和歌词创作投入，而不是原样输出。这不仅是法律层面的稳妥做法，从作品质量角度看也更有价值。

另外，如果歌词是你自己写的，注意不要在歌词里嵌入任何真实人物的姓名、联系方式或者争议性表述。生成音频会被公开发布的话，这些内容会带来不必要的麻烦。

注意：以上是基于我个人经验的一般性提醒，不构成法律意见。涉及具体商用场景，请自行核实许可条款并咨询专业人士。

我在这个项目上花掉的时间，值不值

从第一次装环境到最后跑出自己满意的版本，我大概折腾了三个周末。前面一个半周末基本都在跟环境、权重和显存打架，真正有意思的部分是后面那一个半周末——不断改歌词、调标签、听结果、再改。这个过程有点像早期用扩散模型画图的那种感觉，你永远不知道下一次会出来什么，偶尔会有一版让你愣一下。

如果让我给刚上手的人一句建议：先把期望放在"做出一个有意思的 demo"，而不是"做出一首能发的歌"。YuE 最大的价值不在成品质量，而在于它把"从歌词到完整编曲"这段原本需要一整个团队才能完成的路，压缩到了一个下午。你可以用它快速验证一个创作想法到底成不成立，成立了再投入资源做真版本，这个效率提升是实打实的。

最后分享一个我自己一直在用的小习惯：每次生成都开一个带日期的输出目录，把歌词文件、风格文件、参数命令和种子一起存进去，再在目录里放一个纯文本笔记记下这一版的问题。攒到二十几个版本之后回头看，你会非常清楚地看到自己在哪些参数上绕了远路。这个记录习惯比任何调参教程都管用。