1. 这篇论文到底在解决什么问题翻这篇论文的时候我的第一反应是音乐生成这个方向在 Jukebox 之前其实已经被 NLP 领域的进展“吊打”很久了。图像那边有 GAN、VAE 玩得风生水起文本那边 GPT 系列一路高歌唯独音频尤其是带人声、带编曲的完整音乐始终卡在“生成容易、生成得有意义很难”这个坎上。Jukebox 是 OpenAI 在 2020 年放出来的一个生成式音乐模型标题全称是Jukebox: A Generative Model for Music它做的事情简单说就是给定艺术家、风格和一段歌词模型能直接输出一整首可以听的歌包含人声、乐器、旋律甚至是混音后的成品。这个工作最戳我的地方是它把音乐生成拉回到了“压缩 自回归”这套已经被文本验证过的范式上。论文里反复强调的一个观点是音频不是不能用自回归模型而是直接对原始波形做自回归太贵了所以要先找到一个好的“压缩表示”再在这个表示上做生成。这个思路听起来直白但真正把方案落地到“能生成 4 分钟以上完整歌曲”的级别Jukebox 是第一个。它的价值不只是“多了一个能唱歌的模型”而是给后来的 AudioLM、MusicLM、Stable Audio 这些工作铺了一条路。这篇论文适合谁读我觉得三类人最值得花时间做生成模型的人尤其是关注自回归范式如何处理高维连续信号的人做音乐 AI 或音频理解的人想搞清楚“音频的离散表示到底怎么设计”以及所有好奇“GPT 那套东西能不能用来做音乐”的人。我自己读完最大的感受是Jukebox 不是一个“开箱即用”的工具它更像一份实验报告告诉你把语言模型里的 trick 搬到音频上哪些管用、哪些失效、哪些需要额外设计。这篇文章我会把模型架构、关键技术选择、我复现和阅读时踩过的坑以及它对后续工作的影响全部摊开来说。2. 三个核心组件VQ-VAE、Sparse Transformer 和歌词条件注入Jukebox 的整体架构可以拆成三个大块先是一个多尺度的 VQ-VAE把原始音频压成离散 token然后是一个 Sparse Transformer负责在 token 空间里做自回归生成最后是一套条件注入机制把歌手、风格、歌词这些信息喂给模型。这三个组件缺一不可分开看每个都不算全新但合在一起就形成了 Jukebox 的竞争力。2.1 VQ-VAE 怎么把音频“翻译”成 token音频的问题在于它太“密”了。一张 256x256 的图片像素点也就六万多个而一段 4 分钟的 CD 音质歌曲44.1kHz 采样率下是超过一千万个采样点。直接在这上面做自回归哪怕用再大的模型计算量也是天文数字。所以 Jukebox 的第一步是先用 VQ-VAE 把波形压成一个紧凑、离散的表示。VQ-VAEVector Quantized Variational Autoencoder的思路说起来不复杂编码器把连续的音频帧映射到一个离散的 codebook码本里的某个向量索引解码器再根据这些索引把音频“还原”出来。这样一段音频就变成了一串整数序列和文本 token 的性质是一样的之后就可以交给 Transformer 去建模。Jukebox 在这里做了一个很关键的设计它没有用单一级别的 VQ-VAE而是用了多尺度的 VQ-VAE。具体来说论文用了两种分辨率一种是 32 倍下采样适合建模低频结构比如和声、节拍另一种是 128 倍下采样适合建模高频细节比如音色、人声的细微起伏。这两个级别的 latent 是同时被建模的生成的时候先从粗粒度开始再逐步细化到细粒度。这个设计的动机非常直接音乐是有层次结构的旋律和鼓点的变化频率差异很大用单一尺度要么丢掉细节要么让模型去管太多细枝末节导致顾不过来。2.2 codebook 大小和压缩率的选择逻辑论文里对 VQ-VAE 的配置写得比较清楚但有几个参数我觉得值得细说。比如 codebook 的大小论文里用的尺寸是 8192 和 2048前者对应粗粒度级别后者对应细粒度级别。这个数字不是拍脑袋定的codebook 太小每个 token 能表达的信息有限模型就需要更长的序列才能覆盖整首歌计算成本反而上去codebook 太大则会让 VQ-VAE 的训练变得不稳定因为梯度在大量离散候选之间分配容易导致很多 codeword 闲置不更新。压缩率的选择也一样。32 倍和 128 倍这两个数字放在 44.1kHz 下意味着每秒音频分别对应大约 1378 个和 344 个 token。即便用了较高的压缩率一段 4 分钟的歌曲在粗粒度级别仍然有大约 8 万个 token这个序列长度对于 Transformer 来说依然是不小的压力。我一开始读到这个数字的时候有点意外不是已经压缩了吗怎么序列还是这么长后来想明白了音乐本身的信息量就在那里不可能压得太狠否则可听性会崩。Jukebox 能在这么长的序列上稳定训练和采样靠的是下一节要讲的 Sparse Transformer。2.3 稀疏注意力Jukebox 的算力救星如果直接用标准的 self-attentionJukebox 根本跑不起来。原因很简单8 万个 token 的全连接注意力矩阵规模是 8 万乘 8 万就是 64 亿个元素单层就这么大乘以几十层显存直接就爆了。Jukebox 用的是 Sparse Transformer 里的两种稀疏注意力模式行注意力row attention和列注意力column attention。这两种模式的设计思路是把注意力计算从“每个位置要看所有位置”改成“每个位置只看一小部分但设计合理的位置”。具体到 Jukebox 里它综合了多种稀疏模式有局部的滑动窗口注意力让每个 token 只关注附近一定范围内的 token用来捕捉旋律的局部连续性和乐句的平滑过渡也有跨序列的全局注意力让某些特定位置可以访问整个序列的信息确保全局结构不会丢。同时Jukebox 还利用了音乐的多尺度结构在多个不同分辨率的 latent 序列上联合计算注意力允许模型在同一层内同时处理粗粒度的整体结构和细粒度的音色细节。我最早看 Sparse Transformer 论文的时候觉得这有点为了稀疏而稀疏但在 Jukebox 这个场景里它确实是唯一可行的路。这里我补充一个读论文时容易忽略的点稀疏注意力模式的选择不是随意的它隐含了模型对数据结构的先验假设。比如局部窗口注意力假设相邻 token 之间的依赖是最紧密的这在音乐里基本成立因为音符之间的过渡是平滑的而全局注意力则负责把“这首歌的主题是不是在副歌里重现了”这类跨时间距离的信息引进来。Jukebox 的这两个假设和音乐本身的特性是对齐的。2.4 歌词和条件信息是怎么“喂”进去的Jukebox 一个很吸引人的能力是给定歌词生成歌曲。这在技术上并不简单因为歌词和音乐的对齐关系非常松散。同一句歌词可能在一首歌里唱 5 秒在另一首歌里拖 10 秒有些地方是纯间奏歌词根本不出现。Jukebox 的处理方法是用一个文本编码器把歌词编码成向量序列然后通过 attention 机制让音频侧在生成时能“看到”歌词信息但不是逐字强对齐而是让模型自己学会什么时候该参考哪段歌词。这个设计很聪明它没有去强行做强制对齐而是把对齐的问题也交给模型去隐式学习。除了歌词歌手和风格这些条件信息是通过 embedding 向量注入的。每个艺术家有一个可学习的 embedding每种风格也类似。论文实验了 20 个左右的艺术家和若干风格模型在生成时可以根据这些 embedding 决定输出的大致走向比如你给了 Frank Sinatra 的 embedding生成的歌声就会更偏向爵士和复古的滤镜感给了 Katy Perry 的 embedding编曲就会更流行、更有节奏感。这里我个人的一个体会是Jukebox 对条件信息的利用并不像现在的扩散模型那样精细它的本质还是“把条件作为前缀拼在序列里”这种很粗的方式。但即便如此实验已经证明模型能够学习到 singer 的声线差异说明自回归模型的条件注入机制虽然简单效果却足够可靠。后来的很多工作其实还在沿用这套做法。3. 训练方法和两个阶段的生成流程方法论讲完最想聊的是 Jukebox 怎么训练以及它采样的时候是怎么把 8 万个 token 变成一首能听的歌的。这一部分我读了一些原始论文和后来社区复盘的技术博客把流程重新梳理了一遍这里做一个比较完整的总结。3.1 第一步训练 VQ-VAE 重建音频Jukebox 的训练是分阶段的不是端到端一起训。第一阶段只训 VQ-VAE输入原始音频输出重建后的音频中间把音频编码成离散 token 再解码回来。训练的损失函数包括重建损失、codebook 的 commitment loss以及一个小比例的 adversarial loss 和 perceptual loss——后者主要用来提升重建音频的主观听感避免重建结果听起来像“被强压过的 MP3”。这个阶段训练完成之后VQ-VAE 的编码器就变成了一个“音频转 token”的工具解码器是“token 转音频”的工具。它们的参数在第二阶段会被冻结住不再参与更新。这样做的原因和迁移学习一样把表示学习的问题和序列建模的问题解耦。如果两端同时训模型的收敛会极其困难因为两条梯度路径会互相干扰。3.2 第二步在 token 空间上训练先验模型第二阶段的任务是训练 Sparse Transformer让它学会 token 序列的分布。输入是 VQ-VAE 编码器产出的离散 token 序列输出是下一个 token 的概率分布。这一步和训练 GPT 几乎没有区别唯一的不同是输入是超长序列所以用上了稀疏注意力和分层的建模方式。分层的生成是 Jukebox 最有特色的地方。它训练了一个先验模型来自回归地生成粗粒度 token然后另一个先验模型在粗粒度 token 的条件下生成细粒度 token。你可以把这两个 token 级别理解成先决定“整首歌的结构框架”比如主歌、副歌、间奏怎么排再进行局部的细修比如某个和弦的具体音色和人声的细节质感。这种两级 pipeline 的方式从设计上规避了“一刀切分辨率”的尴尬。在训练细粒度模型时Jukebox 还做了个很有意思的 trick它不是只输入粗粒度 token 当作条件而是会随机遮挡一部分细粒度 token强迫模型学会“在信息不完整时也能做预测”。这个思路我在读的时候觉得特别眼熟——这不就是 BERT 的 mask 思想用在自回归上吗。实践证明这种带噪训练让细粒度模型在采样时稳定了很多因为它不再完全依赖前面的 token 一直对到结尾而是可以容忍生成过程中的一些意外偏差。3.3 采样阶段从粗到细最后合成波形生成一首歌的过程可以粗略分成三步给定条件歌手、风格、歌词先用先验模型生成粗粒度 token 序列把粗粒度 token 作为条件再用细粒度模型生成细粒度 token 序列把两个层级的 token 拼起来交给 VQ-VAE 解码器得到最终的原始波形。这中间每一步的采样都有讲究。粗粒度 token 的采样直接决定了整首歌的走向如果粗粒度崩了后面再怎么细化都是白费。所以论文里在采样时使用了 top-k 采样和 temperature 控制让输出在“多样性”和“稳定性”之间取一个平衡。细粒度阶段则相对“机械”一些因为它的任务是补全细节而不是做创造性的决定这时候 temperature 要调低否则会产生大量听起来很毛糙的噪声。实际跑过采样的人可能会有这种体验temperature 稍微调高一点人声就会开始“漂”像是喝多了的人在唱歌稍微调低一点虽然稳定但会变得很无聊所有的歌都像是同一个模板套出来的。Jukebox 论文给出的经验是粗粒度阶段 temperature 控制在 0.98 附近细粒度阶段可以更低一些。这个数值仅供参考根据数据集和先验模型的拟合程度最优点会浮动。3.4 数据准备音乐生成项目的隐形重活Jukebox 论文里提到它用了大约 120 万首歌曲来训练而且是从网络上抓取的原始音频和对应的歌词。这部分工作量其实被严重低估了我甚至觉得它占了整个项目的一半以上。首先原始音频的格式千奇百怪采样率不统一、时长差异大、响度不一致必须全部做标准化预处理否则即使是最简单的模型也学不到一致的模式。其次很多歌的音频和歌词是对不上的有的歌词缺句、有的一首歌被分成了好几个文件清洗起来需要大量的脚本和人工校验。论文里提到用了一个自动对齐的流程但它也只负责粗对齐真正的质量控制还是靠数据规模和训练的鲁棒性去兜底。我自己在做类似项目的时候有一个很深的感受音频 AI 项目的数据管线远比模型结构更消耗时间。Jukebox 之所以能成功不光是模型设计得好更因为它在数据层面砸了足够多的资源。这一点在论文里是轻描淡写的但我劝所有想复现或者借鉴 Jukebox 的人把时间预算的一半留给数据处理。4. 实操复现与踩坑细节那些论文没写明白的地方Jukebox 的官方代码是开源了的虽然它的训练代码因为依赖太重用了 TPU、特定的环境库版本几乎没办法在普通的 GPU 机器上完整跑起来但推理和采样部分是可以折腾通的。下面是我实际跑代码、看 issue、翻社区讨论时积累下来的一些经验可能比论文本身更有参考价值。4.1 环境配置的隐性要求Jukebox 代码仓库对环境的约束非常严格尤其是涉及到 CUDA、PyTorch 和 mpi4py 的版本匹配。我一开始试图用最新的 PyTorch 版本去跑结果在一堆依赖报错里浪费了整整一个周末。后来发现老老实实按照 requirements.txt 里锁的版本来配置环境反而是一路最顺畅的方案。有一个点特别值得提醒就是 Jukebox 的训练代码是依赖 mpi4py 做多机多卡通信的。如果你只是想用单卡跑一下推理可以跳过 mpi4py 的配置但直接 import jukebox 的时候它会检查这个依赖所以最简单的办法是把它一并装上哪怕不真的用它。另一个常见问题是模型的权重文件是放在 S3 上的官方脚本会自动下载但国内网络访问 S3 有时候不稳定。社区里已经有人把权重转存到了其他网盘或者在 Hugging Face 上重新打包过可以直接去搜“jukebox weights”。4.2 VQ-VAE 可视化先看压缩效果再碰生成我强烈建议第一次上手的朋友先不要急着生成歌曲而是先拿几段音频跑一下 VQ-VAE 的编解码流程对比一下原始音频和重建音频的差别。这个过程能让你直观地感受到压缩带来的信息损失大致知道 model 能保留什么、丢了什么。我自己试过的结果是重建后的音频和原始音频相比低频部分保留得相当好鼓点、贝斯这些都很扎实但高频的一些泛音会有“模糊化”的感觉像是罩了一层纱。尤其是镲片的声音原来的清脆感会打一些折扣。这个现象其实是 VQ-VAE 训练中比较典型的“高频信息瓶颈”codebook 的容量有限时模型优先保住感知上更重要的中低频。如果想要改善高频重建质量可以尝试在 VQ-VAE 的训练损失里加大 adversarial loss 的权重或者提高细粒度 codebook 的大小。但注意这个改动会连锁影响后面先验模型的训练成本如果不是特别在意音质细节不建议一上来就动。4.3 条件嵌入的维度选择论文里对歌词、歌手、风格的 embedding 维度其实没有给得很细只是模糊地说“each is embedded into a vector”。我翻了源码之后才确认歌词是通过一个预训练的 BERT 模型编码成 768 维的向量然后经过一个线性层映射到模型的 hidden size。这里有一个需要注意的点歌词编码器是单独预训练的它和音频模型之间是“冷连接”。也就是说音频侧模型只能通过 attention 去参考歌词向量但无法反过来影响歌词向量的生成。这带来的后果是如果歌词语义和音乐风格有冲突比如一段悲伤的歌词配上了一个欢快的编曲模型只会机械地把两个信息拼在一起很难做深度的情感调和。我不建议在入门阶段去改歌词编码这部分的结构因为冻结预训练模型的 weight 能节省大量训练资源而重新端到端训练歌词编码器的成本几乎等于把整个项目重新跑一遍。这种高投入低回报的事情除非有明确的业务需求否则踩一次就够了。4.4 采样时的加速手段Jukebox 的官方采样过程非常慢。在单张 V100 上生成一首 4 分钟的歌曲需要大约 2 到 3 个小时。这个速度在实际项目中是完全不可用的所以社区里有一些加速的手段简单整理如下第一降低采样率。Jukebox 支持在采样时指定较低的采样率比如 22.05kHz 甚至 11.025kHz这样 VQ-VAE 解码器要处理的帧数会大幅减少速度提升非常明显。代价是输出音频会缺失一部分高频信息听起来更“闷”。第二采样长度裁剪。如果做实验只是为了验证条件控制的效果比如对比不同歌手的 embedding 带来的差异没必要生成整首歌。把时长限制在 20 到 30 秒足以听到明显的人声风格差异但耗时可以从小时级降到分钟级。第三使用半精度。把模型权重和计算切到 FP16可以在不损失太多音质的前提下获得大约 30% 到 40% 的速度提升。需要注意的是BN 和某些层在 FP16 下会有数值稳定性的问题但 Jukebox 整体是卷积和 attention 为主实测下来问题不大。这些加速手段不是为了走捷径而是为了“能跑起来做实验”。毕竟如果一次采样要等三个小时你根本没法快速迭代验证自己的思路AI 项目最怕的就是这个。5. Jukebox 的已知短板和遗留问题任何一篇有分量的论文都会包含对自身局限性的讨论Jukebox 也不例外。搞清楚它哪里做不好比知道它哪里做得好看得更透彻。5.1 音乐连贯性局部好全局弱Jukebox 生成的结果在“局部乐句”上是挺像样的但整体结构经常出问题。比如它可能在一首歌的前 30 秒重复了 8 遍同样的副歌旋律或者歌曲进行到一半突然风格突变像是 MIDI 文件被随机切碎了再接起来。这个问题的根源本质上是自回归模型的“短视”——每个 token 的生成只看到前面的内容但序列太长之后靠 attention 很难把 8 万个 token 之前的全局信息有效地引到当前生成位置。局部窗口注意力的设计更是加重了这种短视局部是稳了全局却飘了。后来的一些工作比如 MusicLM 用扩散模型替代了自回归很大程度就是为了解决这个长程结构问题。扩散模型在生成时可以对整首歌同步进行去噪天然更容易保持结构一致性。5.2 歌词生成的质量参差不齐Jukebox 的歌词和旋律对齐做得一般尤其是在歌曲的后半段经常出现“歌词已经唱完了旋律还在继续”的情况。更常见的问题是发音质量不稳定有些单词会被唱得含混不清甚至被吞掉。我见过一个最典型的失败案例用户在条件里输入了一首英文诗Jukebox 生成的结果里人声部分只在某些句子上能听出是在“说英语”其他部分更像是无意义的音节串。这说明歌词编码器对模型的控制力是偏弱的它更像是“氛围提示”而不是“逐字指令”。这和语言模型里可控文本生成遇到的问题本质是同一个——条件信息没有以足够强的形式注入。5.3 训练成本过高不适合中小企业复现Jukebox 的训练使用了数百块 TPU训练时长和资源消耗都是天量。论文里虽然没有明确公布总成本但按同期的其他 OpenAI 项目来估算单次完整训练的云资源费用应该在数十万美元量级。这个成本决定了一件事Jukebox 更多是“研究范式验证”而非“工程落地模板”。如果你想在资源有限的情况下做音乐生成其实有更便宜的路径。比如直接在 token 级别用当前更流行的自回归模型如基于 EnCodec token 的 AudioLM或者使用 latent diffusion 架构在 Relative 较低的资源下训练出可用的模型。6. Jukebox 的后续影响和遗产读一篇论文最好带着“它在科学史上占什么位置”的视角去看。Jukebox 的影响并不在于它本身被大规模应用而在于它证明了几件事这几件事在它之后的很多模型里都能看到影子。最直接的继承者是 Google 的 AudioLM。AudioLM 的框架是“学一个音频 tokenizer 在 token 上学语言模型”本质上就是 Jukebox 的 VQ-VAE Sparse Transformer 路线。只不过 AudioLM 在 tokenizer 部分换了更先进的 SoundStream在序列建模部分换成了更精简的 Transformer 变体。你可以说 AudioLM 是 Jukebox 的“现代化重制版”它在语义和声学两个层级上建模音频和 Jukebox 的两级 VQ-VAE 设计有异曲同工之处。再往后是 MusicLM它用 AudioLM 作为 backbone加上了文本条件实现了“用一句话描述就能生成一段音乐”。这个能力在 Jukebox 里已经有了雏形——Jukebox 已经支持用歌词文本做条件只是它的文本输入必须得是歌词而且是逐句对应的整体还是“填词谱曲”的逻辑做不到 MusicLM 那种抽象的语义理解。但整个条件生成的设计思路一脉相承。还有一条线是 Stable Audio 和 AudioLDM 这类扩散模型。它们没有直接使用 Jukebox 的自回归框架但都沿用了“先压缩音频到潜在空间再在潜在空间上生成”的想法这正是 Jukebox 最核心的贡献。VQ-VAE 变成了更顺滑的 autoencoder扩散模型替代了自回归 Transformer但分层压缩的想法没有变。Jukebox 在音乐生成史上的位置有点像 GPT-2 在文本生成史上的位置它不够完美、不够高效但它让后来的人看到了这条路是可行的并且技术上的核心障碍都在“可解决”的范围内。这种“范式证明”的作用有时比实际的模型效果更有价值。7. 最后一个建议如果你要读这篇论文重点关注什么我建议在读 Jukebox 论文时不要花太多时间纠结在模型效果的好坏上更值得关注的是三个“设计决策”的推理过程第一为什么用 VQ-VAE 而不是连续的 autoencoder因为这个决策直接决定了后面所有 token 化建模的可行性理解了它你再去读 AudioLM 的 SoundStream 就没有任何障碍了。第二为什么用两级分辨率而不是单级这是对音乐信号本质的洞察——音乐是分层的。这种对信号结构的判断是数据建模中最重要也最稀缺的能力。第三为什么条件注入要用 attention 而不是拼在输入里这个选择意味着模型需要学习“什么时候听条件、什么时候不听”是一种更灵活的约束方式。后来的很多多模态生成模型都沿用了这种设计。读论文不只是为了知道“别人做了什么”更是为了理解“别人为什么这么做”。Jukebox 作为一个把语言模型方法成功迁移到音乐领域的标杆工作它的推理过程和实验细节对任何做生成模型的人来说都是很好的思维训练材料。