ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Jukebox模型解析:从VQ-VAE到Sparse Transformer的音乐生成范式

Jukebox模型解析:从VQ-VAE到Sparse Transformer的音乐生成范式 Jukebox: A Generative Model for MusicOpenAI在2020年放出的那篇音乐生成论文到现在仍然是我愿意推荐给每一个做生成式模型的人反复读的工作。那会儿AI写歌基本还停留在生成一段MIDI旋律的阶段大家讨论最多的是序列模型能不能学会和弦走向几乎没人觉得模型可以直接在原始音频上端到端生成一首带人声、带歌词、带编曲的完整歌曲。Jukebox第一次把这件事做了出来用一个大号Sparse Transformer配合分层VQ-VAE完成了从文本条件到原始音频的生成闭环。这篇笔记不是把论文从头到尾翻译一遍。我更想拆开讲讲它背后的设计动机为什么非要把音频先变成离散符号为什么要用三层编码而不是一层条件信息到底怎么注进去才有效读完以后有哪些值得今天继续参考、哪些已经被后续工作淘汰的思路。如果你在做音频生成、文本条件生成或者单纯好奇让模型唱一首歌这种能力是怎么实现的这篇应该能帮上忙。1. 读这篇论文之前先搞懂它要解决什么难题1.1 音乐生成与语音生成的本质差异我当时做语音合成的时候一个明显感受是让模型说一句今天天气不错很容易但让它哼出一段带和弦走向的旋律难度直接翻了好几倍。原因很实在语音本质上是内容驱动的一段话对应的音素序列可以精确对齐到时间轴上韵律和情感是锦上添花。但音乐不是这样。音乐里同时存在很多层信息节奏、和声、旋律、音色、歌词、声部之间的配合每一层都互相咬合。哪怕只是几秒钟的鼓点它也有明确的节拍结构一段钢琴独奏音符之间的强弱变化、踏板时机、泛音衰减全都会影响听感。语音模型只需要把字符→声学特征这个映射学好音乐模型要学的则是多层结构如何同时演化。这从建模目标上就比语音复杂得多。更麻烦的是时间跨度。一句话通常几秒钟一首歌动辄两三分钟放到采样率32kHz的音频里就是几百万个采样点。那时候Transformer虽然在文本上已经很强但文本序列的长度和音频序列的长度完全不是一个量级。Jukebox这篇论文的核心贡献其实就是在怎么把长音频塞进自回归模型这件事上给出了一个当时看来最完整的答案。1.2 从MIDI到原始波形符号生成与音频生成的路线之争在Jukebox之前AI音乐生成的主流做法是符号生成让模型输出MIDI序列或者乐谱再用外部音源库把人声和乐器渲染出来。这条路看起来聪明实际上有很多隐性限制。MIDI本质上是一种高规格的抽象它把旋律、和弦、力度记录成离散事件但它完全不包含音色和录音环境的信息。同一个音符用钢琴弹和用吉他弹MIDI码是一样的听感却天差地别。模型生成了一段MIDI古典乐渲染出来也还是电子味很重的假钢琴顶多算作曲辅助工具离生成音乐差得远。Jukebox换了一个思路直接在原始波形上建模。它不生成音符而是生成用于表示音频信号的离散编码再通过解码器还原成波形。这样做的好处是模型可以直接学到吉他扫弦时的那一下摩擦声、人声在高音区的撕裂感这些真实录音里才有的细节。代价也很明显音频数据比MIDI数据长了几个数量级解码难度很高。Jukebox等于用一个先压缩、后生成的方案把这条路真正跑通了。这也是我说它选题刁钻的原因——它不是在给已有的MIDI生成模型打补丁而是重新定义了问题本身。2. Jukebox的整体框架一个压缩-建模-生成三阶段范式2.1 为什么不能直接在波形上跑Transformer可能有人会问既然要直接建模原始音频那把波形采样点直接当序列喂给Transformer不就行了理论上可以实际上不行。32kHz采样率意味着每秒32000个采样点。一首4分钟的歌就是768万个数值点。就算把数值离散化这个长度也远远超出了当时Transformer能处理的范围——普通self-attention的时间复杂度是序列长度的平方几百万长度的序列算到宇宙毁灭也算不完。另一个问题是波形采样点之间包含大量冗余信息。临近的采样点高度相关大部分能量集中在低频部分何况音乐里有大量重复的节奏型和音高模式。让模型在这么原始的数据上直接学规律效率非常低就像一个学生要背一整本字典才能读懂一句话完全是舍近求远。所以Jukebox的设计思路非常清晰先用一个神经编解码器把音频压缩成较短序列再在这个序列上做生成。就像写文章之前先列提纲而不是一字一句地对着发音器官建模。这个先压缩、后生成的思路后来成了音频生成领域的标准范式几乎所有主流模型都在沿用。2.2 两条流水线VQ-VAE负责压缩Sparse Transformer负责生成Jukebox整体上可以拆成两条独立的流水线。第一条流水线是VQ-VAEVector Quantized Variational Autoencoder向量量化变分自编码器。它负责把原始音频送进编码器输出一串离散的编码token反过来给定这串token解码器也能重建出近似原始音频的波形。这套编解码器训练好以后就固定住了它相当于一套音频的词典把声音转换成模型方便处理的离散符号。第二条流水线是若干个Sparse Transformer论文里叫prior。它们是真正的生成模型。prior不直接接触波形只负责学习离散token序列的分布给定前面的token和条件信息预测下一个token是什么。生成音乐的过程就是先让prior一步步采样出一串离散token再把token交给VQ-VAE的解码器让它还原成音频。这两条流水线的分工非常明确VQ-VAE解决连续到离散的转化问题Transformer解决离散序列的概率建模问题。这个设计妙在哪它把一个几乎不可能一步到位的任务从文本直接生成几十万长度的波形拆成了两个可分别优化的问题。VQ-VAE只需要让重建误差足够低Transformer只需要让token序列足够合理两者互不干扰训练起来也更稳定。这个瓶颈设计的思路后来也被图像生成领域大量借鉴。3. VQ-VAE三层编码如何把声音翻译成离散记号3.1 从连续波形到离散码本VQ-VAE的核心机制VQ-VAE的核心思想我习惯用一个查字典的比喻来理解。编码器读入一段音频输出一个连续向量。这个向量不会直接被使用而是先在一个码本codebook里找一个和它最接近的向量用这个向量的编号来代替它。码本是预先定义好的一组向量集合每个编号对应一个代表性的声音片段。这样一来无论编码器输出的向量有多连续、多细微最终都会被转换成码本里某个离散编号。Transformer处理这种离散编号就像处理语言里的单词一样顺手。Jukebox的VQ-VAE在标准版本上做了不少工程化改进。比如码本使用起来经常存在死码问题——有些向量几乎没被选中浪费容量。论文里通过随机重置使用频率低的码本来提高利用率再比如训练时引入承诺损失commitment loss让编码器的输出不要偏离码本向量太远。这些细节单独看不大但组合起来对重建质量影响很明显。如果你之后去做音频编码类的工作这几招依然用得着。3.2 三层结构的用意不同粒度捕捉不同音乐信息Jukebox没有用单层VQ-VAE而是设计了三个层级的编码器每一层都在不同的时间粒度上对音频进行离散化。层级对应关系每秒编码token数负责的信息粒度底层bottom每64个采样点一个token约500个音色、瞬时细节、高频质感中层middle每128个采样点一个token约250个乐句、短时旋律、节奏模式顶层top每256个采样点一个token约125个段落结构、和声走向、宏观编排三层编码各有一个独立的码本。最底层每秒产生的token最多保留的信息最细致顶层每秒产生的token最少负担全局结构的刻画。这个设计直接对应了现实录音的特性一首歌既需要有具体音色这种微观细节也需要有段落推进这种宏观结构单一层级的编码很难同时兼顾两件事。训练的时候论文采用了一种由粗到精的层次关系底层先学会重建原始波形然后在中层、顶层的训练中引入低层级的编码结果作为辅助条件。这样每一层都专注捕捉前面层级没表达好的剩余信息尽量避免重复劳动。我当时读到这个地方的时候脑子里蹦出来的类比是先画轮廓再上色最后加高光和纹理细节每一笔都只修正当前还不够清楚的区域。3.3 码本训练中的工程细节和重建质量VQ-VAE训练里有个容易踩的坑梯度怎么从码本选择这个不可导操作传回编码器。标准做法是用straight-through estimator直接把解码器回传的梯度原样复制给编码器虽然数学上不严谨但实践效果很好。Jukebox还配合使用了指数移动平均EMA来更新码本向量让码本更新更平滑。重建质量上Jukebox牺牲了一部分高频细节来换取可控的序列长度。32kHz本身在音乐里不算高清但论文的实验说明在这个采样率下三层编码已经能把一首歌的骨干信息保留住人声、旋律、鼓点都还能认出来。如果采样率再拉高到44.1kHz甚至96kHz序列长度会进一步暴涨当时的Transformer也扛不住。可以说这个采样率的选择是在信息保真度和可计算性之间做出的明确取舍。4. Sparse Transformer和分层先验长序列自回归的两个关键设计4.1 局部加稀疏注意力几万个token怎么处理编码完成之后接下来要面对一个现实问题即便压缩成了token序列长度依然相当可观。顶层每秒125个token一首4分钟的歌是3万个token底层每秒500个token同一首歌是12万个token。这么大的序列普通Transformer根本算不了。Jukebox采用的是Sparse Transformer里提出的稀疏注意力机制。它不再让每个位置都能注意到序列里的所有其他位置而是用几种固定的注意力模式叠加每个位置只注意到一部分经过设计的位置。这样做至少在两个点上打动了当时的我第一个是计算复杂度。稀疏化以后序列长度对计算量的影响从平方级降到了可以接受的范围几万token才真正变得摸得着。第二个是归纳偏置。音乐是有强局部结构的数据。一个音符主要和它前后的音符发生关系远处的联系可以通过多层网络逐步传递。与其让模型在无限大的注意力空间里自己找规律不如用稀疏模式先替它做一层结构筛选。论文里用的注意力模式是行、列、局部窗口的组合大致可以理解为每个token既能关注到附近一段窗口内的细节又能跳过一些位置注意远处有规律分布的锚点。这就像你看一幅大壁画既要低头看眼前这一小块的精美笔触也要退几步看看整面墙的构图。这个混合模式在长序列建模上非常有效后来很多做长文档、长音频的模型都沿用了类似思路。4.2 分层先验先生成骨架再填充血肉如果说稀疏注意力解决的是序列太长算不动的问题那分层先验hierarchical prior解决的就是长程结构怎么保持的问题。Jukebox训练了三个独立的先验模型top-prior、middle-prior、bottom-prior。生成的时候顺序非常明确top-prior先生成顶层token序列相当于先定下这首歌的整体骨架然后middle-prior把顶层token作为输入生成中层token相当于在骨架基础上补充乐句和节奏最后bottom-prior在中层token的条件下生成底层token把音色、细节这些血肉填上。这个设计优雅在什么地方它把一个超长序列的自回归问题拆成了几个不同长度、不同难度的问题。顶层序列最短只有底层的四分之一长度模型更容易学会宏观结构底层序列虽然长但因为有了高层token做条件它需要从头猜的熵大大降低模型可以把精力集中在局部细节上。每个先验只需做好自己这一层的事整个系统的成功率反而更高。我读到这里的时候想这套思路其实可以迁移到很多生成任务上。比如长文本生成先让一个模型写章节大纲再让另一个模型在每个大纲下扩写段落再让第三个模型去润色句子——每级模型任务更单纯互相配合比一个模型硬闯要稳。Jukebox虽然是个音频模型但它的拆解思路比具体模型结构更值得学。综合来看Sparse Transformer和分层先验是相辅相成的前者让长token序列在技术上算得动后者让长程音乐结构在质量上靠得住。少了任何一个Jukebox都跑不到最终效果。5. 艺术家、流派、歌词条件生成是怎么注入的5.1 元数据条件与歌词条件的不同处理路径Jukebox真正的亮点不只是能生成音乐而是能根据指定的艺术家风格和流派来生成甚至可以让它演唱指定的歌词。这里牵涉到条件信息如何注入的问题做法很值得细看。对于艺术家和流派这类元数据论文的处理方式很直接把艺术家、流派表示成向量类似离散标签的嵌入然后通过一个映射网络转换成条件向量把它加到Transformer的输入表示上。模型在训练时看过大量艺术家A流派B音频的组合推理时你给它某个从没在训练集里出现的艺术家标签或组合方式它也能举一反三把对应风格迁移到生成结果里。歌词条件就复杂多了这也是Jukebox和当时其他音乐生成模型拉开差距的地方。它不只是让模型念歌词而是让模型在特定时间点唱出对应的词。具体做法是歌词先被转换成音素序列再利用一个外部工具做强制对齐把每个音素落到音频的时间轴上让它和音频的特征序列逐帧对齐。这个对齐结果会被当作条件输入到各个层级的先验模型中。我当时看到这步操作的时候心里挺佩服的。因为歌词和音乐的关系天然是局部对齐的模型不需要知道整首歌的歌词只需要知道当前这一小段音频应该对应什么音素。把歌词磨成时间对齐的音素序列本质上就是给模型提供一种逐帧的发音提示让它不用从零开始学词和声音怎么对上这件事学起来才更高效。5.2 歌词的对齐与音素化让模型会唱词的关键步骤更具体地说Jukebox把歌词条件设计成了层级递进的模式所有层级的先验都能看到歌词条件不过顶层更多利用歌词来把握段落结构比如副歌在哪里、主歌在哪里底层则用歌词来控制当前那一小段音频要发什么音素。这种分工使得模型唱出来的词整体节奏基本能跟着句子走虽然咬字不算完美但能清楚地听出它在唱什么。这里也有一个值得注意的坑歌词对齐的质量直接决定了生成人声能不能跟上节拍。如果对齐误差大了模型会在这个时间点唱错词或者拖拍子。Jukebox的歌词长句处理偏弱更长、更口语化的句子容易出现词和节拍脱节这也是论文里公开承认的限制之一。不过站在论文阅读的角度Jukebox在条件注入上的设计给了我一个深刻印象条件信息不是一股脑塞给模型就完事而是要针对信息的性质做预处理。标签类信息适合全局注入序列类信息适合按时间对齐注入。这套先分析条件再设计注入方式的思维在今天做多模态生成模型时依然适用。你去看后来MusicLM的文本条件、AudioLM的语义token条件本质上都在做类似的时间对齐和条件融合。6. 论文付出的算力代价与实验结论6.1 模型配置与训练成本Jukebox不是一个每人都能复现的模型这一点论文里也没遮掩。它的训练语料大约有100万首歌曲最大版本的模型参数量达到50亿在当时的GPU集群上也需要训练数周。对普通研究团队来说这个成本几乎是不可接受的这也是这篇论文后来被一些人评价为炫技的主要原因。从工程角度看这个算力消耗主要烧在三个地方VQ-VAE要在大规模音频上做重建训练三个先验模型各自独立训练每个先验模型都要在长序列上跑自回归。训练一次大模型的成本可能比一个小团队一整年的云计算预算还高。这也是为什么Jukebox的官方代码仓库虽然开放了权重但真正拿它来做二次开发的人远少于研究其架构思路的人。不过换个角度看算力成本高这件事本身也是论文的一部分信息它告诉我们在那个时间点高质量的音乐生成就是需要用这么大规模的资源去堆。这个结论后来被证明是对的但要到几年后通过VAE改进、量化技术升级和更高效的后端大家才把成本压到一个相对能接受的范围。6.2 它能生成什么样的音乐质性与量化评估从生成结果看Jukebox的听感是能听出音乐感但明显不是录音室水平。它能生成结构和风格相对完整的片段比如一首钢琴曲可以有明确的A段B段交替一首流行歌可以有前奏、主歌、副歌的推进鼓点和贝斯的配合也有模有样。在论文的人耳评测里部分片段甚至让听众误以为是真实录音尤其是在风格比较模式化、打击乐占主导的音乐上它的以假乱真率更高。造成这种反差的原因不难理解风格化强的音乐比如说唱、电子乐它们的模式更规整、更依赖重复模型学起来相对容易而古典乐或爵士乐这种强依赖演奏细节和复杂互动关系的音乐模型生成的细节就会漏出马脚。Jukebox相当于建立了一个通才模型什么风格都能来一点但每一种风格都算不上精通。我记得当时官方放出来的demo里有些歌曲的前几秒非常惊艳尤其在音色渲染和人声的质感上能听出远超此前所有模型的味道但继续听下去长程结构的松散和高频细节的丢失就逐渐暴露。这个局部惊喜、整体露怯的观感是几乎所有端到端音频生成模型都会经历的阶段Jukebox只是把这条路第一个踩了出来。6.3 我注意到的几个明显短板站在今天回看Jukebox的缺陷其实非常明确。第一是音质天花板。VQ-VAE把32kHz音频压缩成离散token再重建高频细节和空间感损失明显整体听感带着一层罐头味。第二是长程结构控制力不足。它能保持十几秒内的局部连贯但整首歌三四分钟的完整结构和情绪起伏它就抓不太住了。第三是歌词发音不够精准尤其在快速说唱或复杂句子时咬字容易变得含混。第四是推理速度慢自回归逐token生成很长序列生成一首歌要花费大量时间。这些短板在我自己拿官方权重做小规模测试时感受特别深。你听一个几秒的小片段会觉得AI音乐好像真的来了但当你听完整首4分钟的歌新鲜的兴奋感会被疲惫感取代。模型确实学会了音乐的一些表面语法却还没学会好听的音乐为什么好听这件事。不过话说回来这篇论文从来不是为了证明AI音乐已经完美而是为了证明端到端生成音乐这条路能走。从这个意义上它的实验结论是成功的。7. 读完Jukebox之后我对音乐生成技术走向的判断7.1 它启发了哪些后来者Jukebox发出来之后的几年很多主流音频生成模型都能看到它的影子。Google的AudioLM把音频分成语义token和声学token两段处理本质上延续了分层离散表示自回归生成的思路MusicLM在AudioLM基础上加入了文本条件用两层模型分别处理粗略结构和精细细节Meta的MusicGen则用EnCodec作为神经音频编解码器配合Transformer做自回归生成。这些工作各自的实现细节都做了大幅改进但架构上的血统都能追溯到Jukebox那个先压缩、再分层生成的范式。更值得注意的是扩散模型后来进入音频领域之后音乐生成的质量有了质的飞跃。像Stable Audio这类工具已经能做到在语义控制下生成高采样率的完整音乐。但扩散模型同样需要先经过一个高质量的音频解码器把波形压缩成隐变量这个压缩-生成-重建的整体闭环和Jukebox的框架完全同构。可以说Jukebox最大的遗产已经不在具体模型参数里而在整个领域对音频生成应该怎么做的共识里。7.2 回头看Jukebox最大的贡献不是音质而是范式如果只盯着Jukebox的音质很容易低估这篇论文的价值。但我读完后觉得它最重要的贡献是确立了三个原则第一在原始音频空间做端到端生成是可行的不需要依赖MIDI或符号表示第二用多层级离散编码把全局结构和局部细节分开建模可以显著降低长序列自回归的难度第三条件信息要有针对性地预处理和注入元数据走全局条件序列信息走时间对齐条件。今天你再去看任何一篇音频生成领域的重磅论文基本都能在这三个原则里找到位置。Jukebox完成的是从0到1的验证后来的工作大多在做从1到10的打磨。如果你现在想入门音频生成我的建议是先拿Jukebox当坐标系它让你知道这套范式从哪儿来、各组件为什么存在、瓶颈在哪里。理解了这个坐标系再看MusicGen、AudioLM、Stable Audio这些新工作很多东西就是顺理成章的递进。最后说点个人体会。我自己读这类大模型论文最怕的就是被参数量和算力数字糊住眼睛。Jukebox恰恰是那种必须剥开数字看设计的论文50亿参数不是重点重点是它怎么把这50亿参数安排到不同的层次和功能模块里256块V100烧几周不是重点重点是它证明了原始音频生成这条路值得烧钱。以后你再回头看2020年这个时间点会庆幸有这么一篇论文把音乐生成从符号世界里拽了出来一脚踹进了原始音频时代的门口。
返回列表