为什么值得读

全长歌曲生成比短音频难很多。TTS 只要把一句话说自然，音乐生成只要给出一段氛围，任务边界都相对清楚；但一首歌要同时满足歌词、段落、旋律、伴奏、人声、情绪和长程结构。你可以把它想成一个乐队现场排练：主唱要跟歌词，鼓和贝斯要稳住结构，编曲要有层次，制作人还要保证整首歌听起来不散。

论文把行业里的两条路线讲得很直白：mixed token 路线像把整支乐队混成一条总谱，整体协调更容易，但人声和伴奏细节会互相遮蔽；dual-track token 路线像分开写人声谱和伴奏谱，音质细节更清楚，但序列变长、全局规划更难。

LeVo 2 的回答不是二选一，而是分层：先用混合 token 写全曲骨架，再用双轨 token 修人声和伴奏细节；训练上也不是把所有偏好塞进一个 DPO，而是先 SFT、再 offline DPO、再 semi-online DPO、最后模块化扩展。

（图源：论文 Figure 1。LeVo 2 的整体架构与三阶段训练范式。）

一句话讲清楚

LeVo 2 是一个混合 LLM-Diffusion 全长歌曲生成系统：4B 参数 LeLM 负责用离散 token 规划歌曲结构和分轨细节，扩散式 Music Codec 负责把 token 还原成 48 kHz 音频；训练上用审美打分器贯穿预训练、SFT、DPO 和推理，让模型先学会「唱对」，再学会「唱得更像歌」。

流程可以简化成：歌词 / 风格 / 参考音频 → Mixed Semantic LM 写全局骨架 → Track-Specific LM 并行补人声与伴奏 token → Music Codec 重建完整歌曲。

作者与单位

论文作者包括 Shun Lei、Huaicheng Zhang、Dapeng Wu、Yaoxun Xu、Lishi Zuo、Wei Tan、Hangting Chen、Guangzheng Li、Jianwei Yu、Zhiyong Wu、Dong Yu。论文正文给出的单位信息为：Tsinghua-CUHK Joint Research Center for Media Sciences, Technologies and Systems，Shenzhen International Graduate School, Tsinghua University；Tencent；Wuhan University；Hong Kong Polytechnic University。正文还说明 Shun Lei 的部分工作在 Tencent 实习期间完成。

这里值得注意的是单位组合本身：它不是单纯的学术 demo，而是带有明显工业系统味道的全链路工作，包含数据处理、审美评估、偏好训练、模型权重与推理代码发布。

核心问题：为什么歌曲生成特别容易「顾此失彼」

如果只看指标，歌曲生成像是很多任务的叠加：音质、旋律、编曲、结构、歌词对齐、风格跟随、情绪控制、乐器控制。但训练时这些目标不一定同向。例如只优化歌词对齐，模型可能变得更保守；只优化音乐性，歌词幻觉可能回潮。

论文的判断很务实：问题不只是「模型不够大」，而是多目标对齐会发生冲突。DPO 是什么：Direct Preference Optimization，不显式训练奖励模型，而是用「好样本 / 差样本」成对数据直接调整模型偏好。它很适合偏好对齐，但如果把歌词、prompt、一致性、音乐性同时混在一起，梯度很容易互相拉扯。

另一半困难来自数据。歌曲生成长期受制于高质量数据稀缺和标注噪声：能拿到的多是长尾、带噪的自动标注。只用它训练，模型能拟合大盘分布，却学不到贴近人类偏好的 musicality prior；而不可靠的风格、段落与歌词标注，又会直接喂出歌词幻觉和不稳定的可控性。换句话说，这不是单靠堆算力能解决的问题，而要在训练流程里给「审美」和「对齐」各自留出专门的位置。

所以 LeVo 2 的核心问题可以写成一句工程题：

怎样让模型先稳定唱对，再逐步唱好，而且不在最后补音质时破坏前面学到的结构和可控性？

方法怎么做：先总谱，再分轨，再后期制作

理解 LeVo 2，可以先用一个录音棚类比：Mixed Semantic LM 像制作人先写一张总谱，决定旋律、节奏、段落和人声伴奏的关系；Track-Specific LM 像分轨工程师，把总谱里的意图分别落到人声轨和伴奏轨；Music Codec 像最后的渲染与混音系统，把离散 token 变回可听的完整音频。

Mixed Semantic LM 是什么：一个 36 层、hidden size 2048 的 decoder-only Transformer，预测混合 token，承担全局语义规划。论文把它称作一种 pseudo-CoT：不是文字推理链，而是歌曲结构上的「中间思考」。

Track-Specific LM 是什么：一个 12 层轻量模块，直接读取 Mixed Semantic LM 最后一层 hidden state，并行预测 vocal token 和 accompaniment token。这里不用离散 mixed token，而用 hidden state，是因为 hidden state 保留的信息更丰富。

Delay Pattern 是什么：Track-Specific LM 在预测第 t 步人声 / 伴奏 token 时，可以看到第 t+k 步的全局语义 hidden。直觉上，它像歌手提前看见下一小节的谱子，才知道当前这个音该怎样落到歌词和伴奏上。

这里有两个容易被忽略的设计选择。第一，分轨模型接收的是 Mixed Semantic LM 的最后一层 hidden state，而不是已经量化完的 mixed token。离散 token 像总谱上的最终符号，便于生成却会压掉一部分语境；hidden state 则还保留着模型对歌词、旋律走向和段落结构的连续判断。第二，双轨预测采用并行而不是交错展开，避免把序列长度再次放大。代价是分轨模型必须获得足够的未来语义，因此 delay pattern 不是装饰性的技巧，而是并行预测能够成立的上下文补偿机制。

这也解释了为什么去掉 delay pattern 后 PER 会从 8.55% 暴涨到 47.10%。问题并非 Codec 突然不会合成声音，而是人声轨在当前时刻看不到即将到来的语义转折，歌词音素、旋律和伴奏拍点失去共同参照。这个消融把分层架构的因果链条说得很清楚：全局规划必须不仅“先生成”，还要以足够丰富、略带前瞻的信息传给细节层。

（图源：论文 Figure 2。LeLM 的分层语言建模结构，核心是 Mixed Semantic LM 与 Track-Specific LM 的协作。）

Music Codec 则负责把 token 还原成音频。它基于 MuCodec 思路，在 48 kHz 音频上工作，先用 MuEncoder 和多套 VQ 得到 mixed / vocal / accompaniment 三路 token，再用 diffusion transformer 和 VAE decoder 重建波形。VQ 是什么：Vector Quantization，把连续音频表示映射成离散码本索引，方便语言模型像处理文字 token 一样建模。

把输入输出摆清楚也有助于理解。输入条件 C 有三种可选信息：歌词使用 Qwen2 的 BPE tokenizer 编码；3–10 秒的 audio prompt 经 Music Codec Encoder 抽取特征，用来确定音色与风格；此外还能输入风格、情绪和乐器等文本描述。目标端则把 48 kHz 单声道音频压成 25 Hz 的三路 token。这个帧率本身就是在「序列别太长」和「细节别丢太多」之间折中——一首 4 分半的歌换算成 token 已经是很长的自回归序列，全长歌曲最吃紧的地方恰恰就在这里。

（图源：论文 Figure 3。Music Codec 的编码与解码框架。）

被低估的主角：贯穿全流程的审美信号

这篇扩展版真正新增的主线，是一个基于 MuQ 表征、参考 SongEval 思路构建的自动音乐审美评估框架。它不是训练结束后才拿出来打分的工具，而是从预训练一路参与到推理。

预训练前，全部数据会先按审美分数排序，再切成 Top-5%、5–25%、25–50%、50–75% 和底部 25% 五档，并把 musicality tier 作为前缀条件交给模型。这样，模型不再只拟合一个「平均好听度」的混合分布，而是显式知道哪些样本代表更高的音乐性。训练长度也采用课程式安排，从短片段逐步拉到全长，并以约 50% 概率丢弃 prompt，避免模型过度依赖参考音频。

同一个打分器随后不断换岗：SFT 阶段用它筛出 top 0.5% 数据；偏好训练阶段用它判断候选歌曲的音乐性差距；推理阶段则通过 scale=1.5 的 musicality-aware CFG，把生成分布推向高审美档位。也就是说，LeVo 2 没有让预训练、后训练和推理各自使用一套互不相干的质量标准，而是用同一条审美信号把它们串了起来。

最有价值的观点：不要把所有偏好塞进同一个锅里煮

这篇论文最值得记住的，不是某一个模块名，而是训练顺序。

LeVo 2 的后训练分三步：SFT 先用 top 0.5% 高质量数据收窄生成分布；offline DPO 用 150k 歌词 × 每条 8 个候选样本，重点修歌词幻觉和 prompt 一致性；semi-online DPO 每 100 步同步当前模型重新采样，重点提升音乐性，并要求 winning sample 不能重新出现歌词幻觉。

Semi-online DPO 是什么：不是每一步都在线采样的昂贵 RL，也不是一次性固定数据的 offline DPO，而是周期性用更新后的模型生成新候选，让偏好数据跟着模型能力一起往前走。

偏好对的构造也体现了这种分工。offline DPO 从约 150k 条歌词出发，每条采样 8 个候选，再按歌词对齐、prompt 一致性等指标分层配对，先处理相对容易自动判断的可控性问题。到 semi-online 阶段，模型每训练 100 步就同步一次权重并重新生成候选；只有 musicality gap 至少达到 0.2、且优胜样本没有歌词幻觉的样本对才会进入训练。这个门槛很关键：它防止模型为了“更好听”重新牺牲已经修好的歌词正确性。

为什么不能一开始就 semi-online？因为尚未完成可控性校准的模型会不断采出带歌词错误的新数据，在线更新只是更快地追逐一个不稳定分布。论文中直接使用 semi-online DPO 时 PER 反弹到 11.68%，正好说明“数据更新得更及时”不等于“优化方向更正确”。先用固定的大规模偏好对把基本边界钉住，再让动态采样追随模型能力，才是这套调度真正稳的原因。

真正的洞见：LeVo 2 把「可控性」和「音乐性」拆成先后两个优化阶段，避免它们在同一个偏好目标里互相抵消。

这个负面结果尤其关键：单维 DPO 确实会跷跷板。只打歌词对齐时 PER 能到 8.98%，但 OVL 掉到 4.77；只打 prompt 一致性时 Genre / Emotion 好看，但 OVL 掉到 4.71。直接上 semi-online DPO，PER 反而反弹到 11.68%。这些不是边角消融，而是在告诉读者：偏好训练的顺序本身就是能力上限的一部分。

最后才轮到音质。模块化扩展会冻结已经对齐好的 Mixed Semantic LM，只训练 Track-Specific LM，保证补细节时不破坏前面学到的结构和可控性。这里还有一个有意思的 acoustic augmentation：训练时故意让 Codec 只运行 2–4 步扩散，先重建出偏糊的音频，再重新抽取 mixed token 作为输入，逼分轨模型学会从粗糙骨架中恢复人声和伴奏细节。

这套做法的可迁移价值在于：当一个生成任务既要求「内容正确」又要求「体验出色」时，多目标往往会在同一个损失里打架。LeVo 2 的答案不是继续叠目标，而是把目标沿训练时间轴排队，再用冻结和模块化扩展锁住已经获得的能力。相比单纯扩大模型，这更像一份可以迁移到长语音、长视频和多轨音频生成的系统方法。

关键结果：开源第一，但不是无边界地「打败商业」

主结果可以分三层看。第一，LeVo 2 的 Overall Musicality 为 5.48，高于所有开源基线：ACE-Step 1.5 为 4.76，LeVo v1 为 3.71。

而且这不是只赢一个总分：Melody 6.12、Arrangement 6.42、Structure 6.11、伴奏音质 SQ-A 7.10、人声音质 SQ-V 6.53，六个主观维度在开源阵营中全部领先，并超过论文所测 MiniMax Music 2.5+ 的对应六维。相对 v1 接近 +1.8 的 OVL 提升，也说明这不是一次轻量迭代。

第二，歌词对齐更亮眼：PER 为 8.55%，低于 LeVo v1 的 13.55%、YuE 的 20.09%、ACE-Step 1.5 的 19.35%，也低于论文评测中的 Suno v5 12.40 和 Mureka v8 9.96。

第三，Emotion 控制分数为 8.72，与 Mureka v8 并列最高。

但论文的边界也要讲清楚：Suno v5 / Mureka v8 在整体 OVL 上仍略高，Suno v5 的 Genre 为 7.93，Mureka v8 为 8.14，而 LeVo 2 是 6.15；ACE-Step 1.5 的 Genre 也达到 7.21。论文把这部分差距主要归因于自动标注质量。

训练阶段的增益路径同样值得看。OVL 从 4.61（预训练）依次升到 5.02（+SFT）、5.12（+offline DPO）、5.37（+semi-online DPO），最终在模块化扩展后达到 5.48；PER 则从 11.09 降至 10.59、9.19、9.22，最后到 8.55。这里的分工基本符合设计：offline DPO 主要把歌词错误率从 10.59 拉到 9.19；semi-online DPO 则把 OVL 再抬 0.25，同时没有明显破坏歌词对齐。每一阶段只集中处理一种主要矛盾，正是渐进调度比混合优化更可信的地方。

（图源：论文 Table I / Table II。主结果与训练阶段演进。）

如果只看最终分数，读者可能会以为 LeVo 2 主要来自 scale。但 Table IV 更有意思：去掉审美引导，OVL 从 5.48 降到 4.92，比去掉模型 scaling 的 5.30、去掉数据 scaling 的 5.27 更伤；去掉 delay pattern，歌词对齐几乎崩盘。这说明论文的核心不是单点模型大小，而是「分层架构 + 审美引导 + 渐进后训练」一起起作用。

（图源：论文 Table III / Table IV。对齐策略与架构消融。）

生态定位：它站在开源歌曲生成的哪一格

从时间线上看，LeVo 2 延续了 LeVo v1 的分层思路，但这篇扩展版把重点放到训练调度、审美引导和更完整评测上。它的对手不是纯 TTS，也不是短文本音频生成，而是全长 song generation：YuE、SongGen、DiffRhythm 2、ACE-Step 1.5、HeartMuLa，以及黑盒商业系统 Suno / Mureka / MiniMax Music。

把这些路线放到一张地图上会更清楚：Jukebox 一系的 mixed token 胜在整体协调，却容易丢失分轨细节；YuE、SongGen 的 dual-track 或 interleaved token 换来更清楚的人声与伴奏，但序列更长、全局规划更难；DiffRhythm、ACE-Step 采用扩散路线，绕开离散 token 的部分限制，却仍要处理音素对齐与全长结构稳定性。LeVo 2 没有完全另起炉灶，而是把 mixed 与 dual-track 叠成两层：前者定骨架，后者修细节，再由扩散 Codec 还原波形。

在这个坐标系里，LeVo 2 的位置很明确：它不是最强的闭源产品替代品，但它是一个把完整歌曲生成系统拆开讲清楚、并且开放代码与权重的强开源基线。对研究者来说，它的消融比最终 demo 更有价值；对工程读者来说，官方仓库给出的模型版本、显存需求、RTF 和推理命令，让它不只是论文里的系统。

怎么上手 / 部署

官方仓库给出了安装、Docker、Hugging Face 下载和推理命令。下面只列论文与仓库中真实出现的关键路径，不补造参数。

pip install -r requirements.txt & pip install -r requirements_nodeps.txt --no-deps  

huggingface-cli download lglg666/SongGeneration-Runtime --local-dir ./runtime & mv runtime/ckpt ckpt & mv runtime/third_party third_party  

huggingface-cli download lglg666/SongGeneration-v2-large --local-dir ./songgeneration_v2_large & sh generate.sh ckpt_path lyrics.jsonl output_path

显存速查来自官方 README：SongGeneration-v2-medium 约 12G / 18G，SongGeneration-v2-large 约 22G / 28G，其中前者是不带 / 带 prompt audio 的显存区间；最大长度均为 4m30s，RTF(H20) 分别约 0.69 / 0.82。

踩坑提示也很直接：第一，运行前需要从 Hugging Face 下载 runtime 的 ckpt 与 third_party；第二，输入歌词要遵守仓库说明的结构标签和英文半角标点规则；第三，OOM 时官方提供了 --low_mem，不支持 Flash Attention 时可用 --not_use_flash_attn。

适合谁读：

更多语音与音频大模型论文精读，可在 acousticstack.com 查看完整周更列表。