企业官网建设流程全解析

在跑完RNN、LSTM，甚至试过几轮WaveNet风格的生成之后，我最终把谱曲项目的主干架构换成了基于Transformer的音乐大模型。原因并不复杂：音乐不是一句一句念出来的文本，而是一种长程结构极强的时间序列，前奏里的一个动机可能在副歌里以变奏形式重新出现，和弦的推进往往跨越几十上百拍。只用局部窗口或循环记忆很难把这种“远处的东西”稳稳抓住，而Transformer的自注意力机制天然就是为这种跨位置的关联设计的。

这篇文章不是纯理论科普，是我自己从零搭建一套Transformer音乐生成系统的实操总结：MIDI怎么变成Token、模型怎么选、训练参数怎么调、生成出来的东西为什么有时候听起来像在“蹦迪”、又该怎么补救。如果你正打算入门AI谱曲，或者已经在做序列生成，这篇能帮你少走不少弯路。

1. Transformer凭什么能在音乐任务里站住脚

1.1 音乐序列的“长程依赖”对RNN类型模型的挑战

早期做音乐生成，主流的做法是用LSTM或者GRU这类循环网络，把旋律当成一串时间步序列，每输入一个音符就更新一次隐状态。这种方法在短乐句上效果尚可，但一旦音乐到了几十秒甚至几分钟的规模，问题就很明显：前面第10小节的旋律线索，要在第80小节才被重新引用，循环网络隐状态携带的信息早就在传递过程中打折甚至丢失了。

音乐本身又偏偏是特别讲究“伏笔”的。织体结构、调性布局、主题回归全都是在长距离上建立的。用循环网络生成的曲子经常会出现一种典型听感：短句顺畅，乐句之间却没有发展逻辑，像是若干段独立旋律的机械拼接。我当时在项目里越跑越觉得不对劲，生成的片段单独听都还说得过去，连起来就是一首“缝合怪”，这是模型的记忆机制决定的，很难靠调参彻底解决。

1.2 自注意力如何同时看到前后文

Transformer解决这类问题的思路很直接：不按时间顺序一步一步往后“记”，而是让序列中任意两个位置直接建立联系。

自注意力机制所做的，就是为序列里的每个Token计算出它跟其他Token的关系权重，权重越大，说明当前音符越需要参考那个位置的上下文。比如副歌里的一个长音，它的注意力权重可能大部分集中在小节开头的主和弦音上，而不是紧挨着的装饰音。这种“跨位置直达”的能力，让模型在处理音乐时比RNN更有全局视野。

多头注意力又把这件事做了多次并行，每个头负责从不同子空间捕捉关系：有的头可能在关注节拍位置，有的头在关注和弦内音的共性，有的头在关注“这个音之后通常跟哪类音”。这些信息叠在一起，模型对音乐结构的表征就会比单向量循环更细腻。

这里也要说实话：Transformer不是魔法。它的全局视野来自平方级复杂度——序列长度翻一倍，计算量涨四倍。正因如此，后面会讲怎么在Token序列长度、模型规模和可训练成本之间做平衡。

1.3 位置编码与音乐调性的隐性联系

自注意力本身没有“先后顺序”的概念，比如序列里(1, 2, 3)跟(3, 2, 1)在模型看来如果没有位置信号就是同一种输入。所以Transformer需要位置编码，把“这是第几个Token”的信息注入进去。

我测试过几种位置编码方案，有一个体会在这个项目里特别深：音乐跟文本不同，它会移调，也经常有模进和重复片段。无论C调还是G调，旋律轮廓应该被模型识别为同类的模式。绝对位置编码在某些情况下会让模型太依赖“第几拍”而非“相对第几拍”，导致换个调性后生成结果变得明显不一样。相对位置编码对音乐生成更友好，因为它强调的是“这个音跟那个音在时间上的距离”，而不是“这个音到底在第100拍还是第300拍”。如果你的框架支持相对位置编码或旋转位置编码，优先用它们。

2. 先解决输入问题：音乐Token化的几种实用做法

2.1 把MIDI事件变成Token序列的最基础方案

Transformer只能处理离散Token序列，所以第一步是把MIDI文件翻译成“音乐Token语言”。

最直接的方案是把MIDI事件拆成一个接一个的既有时序，比如：按下某个音、松开某个音、音持续了多久、力度是多少。具体到实现，我经常用的是事件式编码：一个音符被拆成“音高事件”和“时值事件”，配合专门的“小节线事件”作为结构的锚点。

# 伪代码示意：MIDI事件到Token序列 def midi_to_tokens(midi_score): tokens = [] for note in midi_score.notes: tokens.append(onset_to_token(note.start)) # 起拍位置 tokens.append(pitch_to_token(note.pitch)) # 音高 tokens.append(duration_to_token(note.duration)) # 时值 tokens.append(velocity_to_token(note.velocity)) # 力度 tokens.append(phrase_boundary_token()) # 乐句结束 return tokens

这样每个Token代表一种离散属性，模型只需要预测“下一个Token是什么”。音高、时值、力度如果直接作为原始数字输入会有两个问题：数字大小本身没有语义，而且模型难以表达“这个音符类别的概率分布”。所以要做成词典映射，比如把所有可能的音符时值按粒度枚举成一个词表。词表大小通常在几千到一万多Token之间，对Transformer来说完全可控。

2.2 加入小节线、速度、调性信息：结构化Token的意义

如果只把“音高+时值+力度”编码成序列，模型能学到旋律的一些统计规律，但很难学到真正的篇章结构。节拍重音在哪、调性转变发生在哪个位置，这些东西对音乐组织极其重要，却在最基础的Token方案里丢失了。

我在项目里参考了业内比较常见的一种做法：在序列中显式插入小节线Token、速度Token和调性Token，让模型不是靠猜去理解这些结构性信息。小节线Token的作用尤其明显，它相当于文本里的段落标记，允许模型在每个小节开始时“重置”注意力分布，更容易记住和弦功能和节拍位置。

调性信息也可以作为前缀Token拼在序列开头。比如整段曲子建立在某个调上，就把“调性标记”放在序列最前面，之后再跟真正的音符Token。这样做之后，生成结果的调性稳定性提升了不少，不再那么频繁出现“上一句还是大调、下一句莫名其妙变成了无调性”的尴尬。

2.3 Token序列拼接与数据增强的实操建议

在做训练集时，文件里的曲子不见得都很干净：有前奏、间奏、尾奏，还有大量休止符。休止符必须保留，它是音乐的一部分，不是噪声。但休止时间过长会造成大量重复Token，浪费上下文窗口。

我的做法是：先按四小节或八小节切音乐片段，再拼接成固定长度序列。切分时尽量保证片段从强拍开始，不要从小节中间截断，否则模型会学到很多“半截句”，生成时容易在奇怪的位置开始乐句。

训练阶段我会做数据增强：在同一调内把整段旋律上下平移几个半音，模拟移调；再把速度整体放慢或加快一点，模拟不同演绎。这种方式几乎不花钱，却能让模型对“绝对音高”的注意力下降，转而更多依赖“相对音高关系”，这对音乐生成泛化很有帮助。

3. 搭建Transformer谱曲模型的完整训练流程

3.1 数据清洗：决定模型上限的一步

很多新手一上来就急着跑模型，其实最终生成质量的60%以上在数据准备阶段就定了。我踩过最大的坑是数据重复：同一个MIDI文件的不同版本、同一首歌的多个转录文件混在一起，训练集和验证集之间大概率会出现重复片段，最后验证Loss好看得离谱，上线后却一塌糊涂。

清洗流程我会按顺序做：

• 去除打击乐轨道：绝大多数旋律生成实验不需要鼓轨，保留会干扰模型对音高关系的学习。
• 去除音轨少于两个或音符数过少的空洞文件。
• 按曲目级别去重，而不是按片段级别去重：把同一曲目名下的所有MIDI文件归为一组，只保留一份。
• 切片时再做一次重复检查，确保窗口内没有完全相同或高度相似的片段。

清洗完再看音高分布。如果数据里高音区特别多、低音区很少，模型生成的旋律也会偏向高音区。这一步可以通过移调增强和分布均衡来缓解。

3.2 选择模型规模：先跑小模型，再谈“大”

标题里的“大模型”更多是一种技术路线的称呼，并不是说个人训练条件就一定要堆几千亿参数。我在谱曲项目里是从一个很小的Decoder-only模型起步的：6层TransformerDecoder、8个注意力头、隐藏维度512，参数总量大概在几千万到一亿之间。这个规模在单卡环境下就能训练，足以验证Token化方案对不对。

小模型跑通之后，再根据显存和训练时间逐步加层数、加宽度。如果一开始就堆一个几十亿参数的模型，很容易把时间全耗在调试数据上，反而什么都没学到。先用小模型把Pipeline调到稳定，再放大，是所有序列生成项目的通用路径。

3.3 训练超参数配置与显存瓶颈的处理

我常用的Decoder-only音乐生成模型配置如下，这是经过几轮实验后比较稳的一组起始值：

训练时我会开启混合精度。对音乐Token这种离散预测，fp16训练稳定度通常够用，能省下接近一半的显存，把Batch Size再往上抬一截。CPU方面瓶颈主要在数据加载，MIDI解析虽然不算重，但如果每个Step都实时解析，还是会拖慢训练速度。我习惯先把全部MIDI一次性离线转成Token序列落地成二进制文件，训练时直接加载Token数组，省掉实时解析的损耗。

3.4 推理采样的参数组合与试听过程

训练完之后进入生成阶段，解码方式对听感的影响极大。只用贪心解码（每步取概率最高的Token）生成出来的旋律往往非常“平”，缺少变化和惊喜。纯随机采样又容易失控。我最后固定用“Top-K + Top-P + 温度”的组合：

• 温度调低（比如0.6到0.8）：分布变尖锐，生成更稳定。
• Top-K限制在40到80：避免在每一步都允许极低概率的离谱Token被选中。
• Top-P再加一道过滤：比如只从累计概率90%的Token里抽，进一步缩小候选范围。

条件允许的话，我会一次采样十几条，然后全部渲染成MIDI或音频听一遍，不只看Loss。Loss下降和听感变好不是一回事，这一步是工程问题也是审美问题。

3.5 训练到试听的完整Pipeline总结

完整流程一句话概括：清洗MIDI、离线Token化、切定长序列、划分验证集、用小规模TransformerDecoder做自回归训练、生成Token序列、转回MIDI事件、渲染成音频试听。我自己建议把这条Pipeline里的每一步都做成可复用的脚本，因为有了一次能跑通，后面换数据集、换模型规模、换Token方案都会快捷很多。

4. 谱曲训练中最容易被忽视的四个陷阱

4.1 验证集切分不当带来的“超预期Loss”

先说这个常见陷阱。最初我的数据切分比较简单：把全部Token序列随机打散，取10%做验证集。结果验证集的Loss低得让我一度以为模型已经逼近完美，直到我用一段训练时没见过的MIDI做生成测试，才发现输出质量远不如验证集指标暗示的那么高。原因很简单：同一首曲子的片段被切分后，一部分进了训练集，一部分进了验证集，模型本质上是“见过”验证集的。

这件事的教训是：数据切分必须按曲目做，而不是按片段做。同一个MIDI文件的所有片段只能属于训练集或验证集之一，不能两边都有。做严格规范的切分之后，验证Loss会升到真实水平，但也只有这样才能让人相信模型真的有泛化能力。

4.2 Loss正常但生成音乐缺乏结构感

另一种情况是模型训练得很好，指标漂亮，生成的单句旋律也流畅，但整段听起来还是“散”：每个句子是漂亮的，句子之间没有逻辑，听不出明确的段落起伏，更接近“即兴碎句”而非一首完整的作品。

这个问题的根源通常是上下文长度不够，模型只看得到一两句旋律，根本看不到乐段之间的主题回归和展开。解决方式也很直接：把上下文长度从256提升到1024甚至2048，在长短不同的片段上训练模型。注意，增加上下文长度后训练时间会涨，但这是让模型“懂结构”最有效的投入。同时，前述结构化Token（小节线、调性标记）也要配合用，让模型有位置锚点可依，不然序列变长之后也一样容易漂移。

4.3 采样结果里的“僵尸音”与无调性乱跳

生成Token序列再转回MIDI后，经常会出现两类问题。

一类是“僵尸音”：音符时值非常短且力度很弱，数量还不少，听感上像一串乱码。这类音符本质上来自模型在某些低置信度位置的随机采样，当候选分布过于平坦时，模型只能随机挑一个Token。我一般会在后处理里做一个最小约束：过滤掉时值低于设定阈值的音符，或者把异常极端的力度值拉回正常范围。

另一类是无调性乱跳：前后两个音的音程跨度过大，甚至突破八度，听起来毫无旋律性。音乐当然允许跳进，但频繁乱跳就成了噪声。针对这个问题，我采用“软约束”：在采样阶段筛掉那些跟前一音符音高距离超过12个半音的候选，除非所有候选都超过这个范围。在纯自回归生成里，这类规则约束简单有效，能让输出立刻“像话”不少。

4.4 成本优化：混合精度、梯度累积和量化推理

个人开发者训练音乐Transformer最大的现实约束就是算力。混合精度我是默认开启的，单卡训练基本能稳定收敛。如果是单卡显存16G左右，上下文长度1024、模型隐藏维度512这个配置靠梯度累积也可以跑，只是速度慢一些。我一般先用小步数训练来做结构验证，确认代码没有问题，再投入长时间完整训练。

生成阶段的成本优化也有性价比更高的路径：把训练好的模型做量化推理，权重从fp16降到int8，音乐生成任务对量化敏感度明显低于图像生成，生成质量几乎无损，速度却能快不少。这也是为什么我建议在整个项目调试完成之前不要着急上太大的模型，先跑通再权衡。

5. 在这套框架之上还能做哪些进阶方向

5.1 融合和弦、歌词、风格等条件的可控生成

纯粹的“给一个开头，让模型自己续写”只是基础形态。把Transformer谱曲模型变成可控生成器，是更进一步的话题，做起来也非常有意思。

常规做法是条件注入：在一个Decoder-only模型里把“风格标签”“速度值”“和声进行序列”拼接到输入序列最前面，让模型学会在给定条件下生成音乐。比如给定一组和弦序列，模型需要生成一条能配得上该和弦的旋律。这种任务用Encoder-Decoder结构效果更好，Encoder读取和弦条件，Decoder自回归生成音符序列。

我在实验里观察到，条件生成比无条件生成更容易提早收敛，因为条件信息给了模型明确的“路径提示”，相当于从“自由联想”变成了“命题作文”。如果你想让AI真正能配合人创作，而不是只能炫技式地全程自动生成，这一步是必须走的。

5.2 与音频模型结合的框架思路

MIDI Token方案最大的限制是不包含真实音色和音效质感。后续可以考虑把Transformer生成的MIDI Token先转成乐谱信息，再交给音频合成模型去渲染，得到带真实乐器质感的音频。两个模型各司其职：前者管音乐性，后者管声学质感。

我个人的项目其实也在往这个方向演进。目前的做法是：用Transformer模型负责旋律、和声、结构的生成，然后接轻量级的合成渲染层。这个组合比直接端到端生成音频可控得多，也更容易调试和局部替换，适合个人开发者和中小团队。

最后分享一个我在项目里经常用的土办法：生成MIDI后不要急着拿原始输出当成品。先把音符力度整体做一次归一化，再把明显超出常用音域的高音和低音剪裁掉，最后用一小段旋律起始的“势能”检查一下是否存在大段重复。这套简单规则过滤掉的问题，比调整模型参数省力得多。AI谱曲的完整链路里，后处理占的权重一直都比很多人想象的要大。