Transformer搭建音乐生成模型：从MIDI Token到AI续写钢琴曲-北京尧图网络

把一段旋律丢给程序让它接着往下写还要补上像模像样的和声与节奏——AI谱曲这个方向过去几年换过好几批“主角”从隐马尔可夫到RNN再到如今各种音乐生成Demo背后的真正主力Transformer。这篇是这个系列的第五篇前面几期聊过MIDI格式、数据清洗、RNN/LSTM方案的局限性这期直接进入正题拆一个基于Transformer的音乐大模型该怎么搭、怎么训、怎么让它产出一段真正能听的钢琴片段。如果你有Python基础、自己跑过一点深度学习代码完全可以照着这套思路把管线搭起来如果你之前主要做NLP那更合适这篇相当于一份“语言模型如何迁移到符号音乐”的实操笔记。整个项目的关键点其实只有三个Token化设计、结构选型、采样策略。把这三件事想明白后续往多轨、和弦、可控生成这些方向扩展都会顺很多。1. 整体设计为什么把MIDI变成“乐谱语言”喂给Transformer先说一个很多新手容易绕进去的问题为什么放着现成的音频不用非要把音乐转成MIDI token直接对波形建模不是更“AI”吗理论上确实可以但实操里很难受。音频是连续信号一个小时的钢琴曲采样率高得惊人模型要学的东西里有一大半是声学细节而不是音乐结构。而且生成出来的音频你很难控制想改某个音、想让它从某个和弦继续接下去几乎没有可操作性。MIDI不一样它本身就是离散符号哪个音、什么时候响、响多久、多大力。这天然就是语言模型最擅长的“序列预测”问题。把MIDI事件变成token再把“预测下一个token”当成训练目标标准Transformer那一套东西就能直接搬过来用。1.1 为什么不是RNN/LSTM音乐需要跨越长距离的结构音乐不是一串随机音符而是有主题、有发展、有段落复现的结构。比如回旋曲的主题在开头出现隔了十几小节又回来一首歌的主歌和副歌往往共享素材只是换了情绪和编排。这种长距离依赖恰恰是RNN最不擅长的事。RNN的问题在于它靠一个“隐状态”一路往下传前面的信息传了十几个小节早就衰减得差不多了除非从头到尾反复“背诵”否则很难在副歌出现时精准响应开头那几句旋律。LSTM加了个门控机制能比RNN好一点但本质还是线性扫描训练也只能一个时间步一个时间步地串行推又慢又憋屈。Transformer的自注意力机制不一样它让序列里任意两个位置的token都可以直接建立联系。模型在第500个token的位置依然能“看到”第20个token那里出现的旋律动机然后主动做呼应。用生活里的例子类比RNN像是一个人用临时记忆念长句子念到后半句早忘了开头说的啥Transformer像是把整张乐谱摊在桌上写作业想回看哪小节就回看哪小节。所以做音乐生成尤其是需要跨小节的动机发展、主题复现这类结构的任务Transformer几乎是“天生对口”的方案。这也是为什么“基于Transformer的音乐大模型”能成为当前AI谱曲事实上的主流技术路线。1.2 整体管线从MIDI到Token再回到音频整个系统的闭环并不复杂核心是从“生成音频”转换成“生成token序列”。实际项目里我一般分成五个阶段数据准备拿到一批MIDI文件解析出来再做清洗——去掉鼓轨、修正错误音长、统一节拍分辨率。Token化把一个一个音符事件转换成离散token序列。这是最关键的设计环节直接影响模型能不能学到音乐的逻辑。训练把token序列喂给一个因果TransformerDecoder-only架构用“预测下一个token”的交叉熵损失去训练。生成给定一小段旋律作为“种子”让模型一步步预测后续token直到预测出结束符号或达到设定长度。后处理把生成的token序列解析回音符事件、写出MIDI文件再通过音源渲染成音频或导入DAW里看谱。你会发现这套流程的本质是把音乐生成重新定义成了一个自回归语言模型问题。所以NLP里面积累的那些生成技巧——温度采样、top-p截断、重复惩罚——几乎都能平移到音乐生成上省掉大量重复造轮的功夫。1.3 模型不必“大”到离谱先搞清楚瓶颈在哪这两年“大模型”三个字被炒得很热一听到音乐大模型很多人第一反应是“是不是得上几十亿参数”。我可以负责任地说如果你只是用公开MIDI数据集做一个Demo几千万参数的Transformer已经能生成很完整、很舒服的钢琴段落了。原因有两个。第一MIDI序列本身的信息密度没有自然语言文本那么高。一首钢琴曲的token序列展开来看结构其实很规律音符之间的模式和词法远比文本更容易被中等规模的模型掌握。第二模型太大但数据不够时会迅速过拟合生成出来的结果全是复读机式的碎片和“背课文”式的片段。反而是尺寸适中的模型配合好的Token化设计效果让人惊喜。我自己的实验参考是embedding维度384、Transformer层数6到8层、注意力头数8个序列长度512个token。这个规模在单卡上训练很轻松生成效果已经足够支撑一个像样的自动作曲小工具。真正值得花时间的是下面的Token化设计那才是决定模型天花板的环节。2. 核心环节拆解从Token化到采样生成的关键实操2.1 Token化让MIDI变成Transformer能读的“单词”Token化是整个项目里最容易被低估的一步。很多新手直接把“音高”当作token一个音高对应一个编号生成出来就是一堆单调的音符毫无音乐性。问题在于音乐里一个音符不只是“哪个音”还包括力度、时值、在节拍里的位置。这些属性拆得越细致模型能学到的音乐感就越丰富。我用的是一种事件式编码大致类似论文里常见的REMI思路。一个音符不是单个token而是拆成几个不同的属性tokenToken类型含义示例Pitch音高编号0到127Pitch_60表示中央CVelocity力度0到127Velocity_96表示较强奏Duration时值以tick为单位Duration_240表示一个四分音符按480 tick/拍TimeShift距离上个事件推进的时间TimeShift_120表示等待120个tickBar小节边界BAREOS序列结束EOS比如“中央C、力度80、持续四分之一拍”这个事件编码出来就是大约这样一串tokenPitch_60, Velocity_80, Duration_120, TimeShift_120为什么不直接把“音高力度时值”合成一个token编码因为组合空间太大数据会稀疏到没法学。拆成独立属性token之后模型可以分别学习音高的分布、力度的分布、时值的分布以及它们之间的组合规律。这就像英文单词用词根词缀拆开学比把每个变形都当成独立词要聪明得多。还有一个很多人第一次写时容易忘的事情休止符。休止不是额外的一种“事件”它本质上就是TimeShift堆叠。如果一个片段里你从不生成TimeShift那模型写出来的音乐就是“一串音符从头到尾不断气”毫无呼吸感。所以Token化方案里一定要让TimeShift足够灵活让模型自己学会在适当的时候“停一拍”或者“停半拍”。附一个把音符事件转成token的伪代码示意# 伪代码将MIDI事件转为token列表 def events_to_tokens(events): tokens [] for ev in events: if ev[type] note: tokens.append(fPITCH_{ev[pitch]}) tokens.append(fVELOCITY_{round(ev[velocity] / 16) * 16}) tokens.append(fDURATION_{ev[duration_ticks]}) elif ev[type] time_shift: tokens.append(fTIMESHIFT_{ev[shift_ticks]}) elif ev[type] bar: tokens.append(BAR) tokens.append(EOS) return tokens这样整个音乐就被翻译成了一维的token序列Transformer读起来和读句子没有区别。2.2 位置编码与注意力结构让模型“知道音符怎么排”Transformer没有天生的“顺序感”。你把同一组token顺序打乱喂进去注意力的计算结果其实差不多因为自注意力本身是“位置无关”的。所以必须把位置信息显式加进去。位置编码的选择上我推荐相对位置编码而不是普通的绝对位置编码。道理也很朴素对音乐来说一个音比前一个音高了多少、隔了多少拍比“这个音在整首曲子的第380个token处”重要得多。绝对位置编码会把模型绑死在某个调性或某个绝对时间上移调后泛化很差相对位置编码则让模型更关注间隔和相对高差这正是音乐结构里最核心的信息。至于结构选型这个项目直接采用Decoder-only的因果Transformer就对了。所谓“因果”就是每个token只能看到自己和之前位置的信息看不到未来。这恰好匹配生成过程预测下一个token时你手里只有过去的内容。用Encoder-Decoder或者双向注意力也不是不行但会引入额外的复杂度对于“生成”这个任务来说没必要。训练完之后有一个很值得做的直观检验把某个生成样本的attention矩阵画出来。我经常在副歌出现的位置看到模型“回头”去注意开头的主题区域这种可视化是模型确实学到结构的最直接证据。2.3 采样策略不要一个劲套用NLP默认参数模型训练完了生成时是从概率分布里采样的不是每次都选最大概率。如果用贪心解码生成结果几乎一定有严重的重复问题。音乐本身是大量重复的艺术模型很容易觉得“既然前面重复过后面继续重复一定没错”结果就是第八小节还在复读第一小节的音型。我在生成时最常用的三个参数是Temperature温度控制概率分布的平滑度。温度越低越保守越高越随机。音乐生成建议在0.8到1.1之间太低复读太高音符乱跳。Top-p核采样只从累计概率超过p的候选token里采样通常0.9到0.98。Repetition Penalty重复惩罚对已经出现过的token打分时除以一个惩罚系数推荐从1.2起步可以往上调到1.5。下面是一个简化版的采样逻辑融合了这三个机制def sample_token(logits, past_tokens, temperature1.0, top_p0.95, rep1.2): # 温度缩放 logits logits / temperature # 重复惩罚把已经出现过的token分数压低 for token in set(past_tokens): logits[token] / rep # 按概率取累计达到top_p的最小集合 sorted_logits, sorted_idx sort_descending(logits) cumulative_probs softmax(sorted_logits).cumsum(-1) remove_idx cumulative_probs top_p remove_idx[1:] remove_idx[:-1].clone() remove_idx[0] False logits[sorted_idx[remove_idx]] -float(inf) probs softmax(logits) return multinomial(probs, num_samples1)有个细节需要注意remove_idx[0] False这一行一定要留它保证概率最高的那个token永远会被保留不会因为核采样把最合理的候选意外删掉。实际使用的经验是先固定top_p再去调温度和重复惩罚不要三个参数同时乱动。否则出了问题你也分不清是哪一项引起的。我跑下来比较稳的起点是temperature0.9, top_p0.95, rep1.3之后根据试听效果微调。3. 完整复现路径数据清洗、训练配置与MIDI渲染3.1 数据准备宁可少而干净不要多而混乱数据是这种项目最大的分水岭。网上能找到的公开MIDI数据集不少优先选单钢琴轨、音乐结构清晰的曲目古典钢琴曲尤其合适。合成器音效轨、摇滚多轨、鼓点密集的MIDI更适合做别的项目在这里只会让模型学出一堆杂乱音堆。拿到MIDI文件后清洗清单可以照着这个执行去掉鼓轨、歌词事件、控制器消息只保留真正的音符事件。修正音高越界、负时值、重叠音等非法数据。统一tick分辨率比如每四分音符设为480 tick这样后面Token化时Duration和TimeShift的单位是统一的。过滤掉超长曲目比如超过几百小节的直接切出或丢弃否则输出序列长度波动太大。做移调增强把曲子随机上下移动三到五个半音。这样同样一首曲子能生成C大调、D大调等多个调性的版本数据量一下子多起来模型的调性泛化能力也更好。我踩过最深的坑是完全不做筛选把能找到的MIDI一股脑全喂进去。结果生成结果里经常出现“左手低音区突然蹦出个刺耳高音”这种奇怪现象原因很简单数据里混了大量MIDI内录文件轨道设计根本不符合正常演奏逻辑。后来我学乖了清洗完先随机抽几十首MIDI直接用DAW打开看piano roll肉眼确认是能读的谱子再进训练管线。这一步不能省。3.2 训练配置普通单卡也能跑出像样效果在这个项目里“大模型”的“大”主要体现在序列长度和训练数据而不是参数量。我个人推荐以下这套起步参数组合适配大部分8到15分钟曲库规模的数据集超参数建议值说明序列长度512 token约覆盖十几到几十小节的钢琴片段Embedding维度384中等容量单卡无压力Decoder层数6数据量小不建议加深注意力头数8标准比例head维度为48前馈层宽度1536约为embedding的4倍参数量约25M单卡可轻松训练学习率3e-4配合约1000步的warmupBatch Size64显存不够时用梯度累积训练轮数10到20观察验证集loss早停为什么序列长度定512 token在事件式编码下一个音符平均要三到四个token表示512个token大约是一段中等长度钢琴曲的十几小节。这个长度足以覆盖“主题发展再现”的基本结构又不会让训练数据切出来的样本过少。你要是把序列长度拉到1024显存压力翻倍普通消费级显卡就开始吃紧了但音乐结构的提升并不一定成正比。训练时还要注意一个细节同一batch里不同曲子长度不一致需要padding到相同长度。交叉熵损失计算时必须对padding位置用ignore_index-100之类的方式屏蔽掉否则模型会去学习预测那些没有任何意义的padding token验证集loss会非常难看。3.3 生成与渲染从“预测下一个token”到可听的MIDI训练完成之后生成阶段反而是最简单但最有成就感的环节。整个过程是这样的准备种子拿一首先前清洗过的曲子转成token后截取开头几十个token作为生成起点或者手工写一小段旋律转成token当种子。循环采样把种子序列丢进模型预测下一个token用我们前面说到的采样策略选token再把它拼接到序列末尾继续下一次前向计算。终止条件生成到EOS token或生成长度达到预设上限。解码把token序列转回音符事件TimeShift累加得到绝对时间Duration得到音符长度Pitch和Velocity直接还原。渲染输出标准MIDI文件用开源合成器挂钢琴音源导成WAV或MP3或者直接拖进DAW里打开看谱子、微调编曲。下面是一个简单的token解码伪代码逻辑# 伪代码把token序列转回note事件 def tokens_to_events(tokens): events [] tick 0 current_pitch None current_velocity 0 for token in tokens: token_type token.split(_)[0] if token_type PITCH: current_pitch int(token.split(_)[-1]) elif token_type VELOCITY: current_velocity int(token.split(_)[-1]) elif token_type DURATION: if current_pitch is not None: events.append({ pitch: current_pitch, velocity: current_velocity, start: tick, duration: int(token.split(_)[-1]), }) elif token_type TIMESHIFT: tick int(token.split(_)[-1]) return events实际代码里还要处理重音符、和弦、TimeShift与音符事件顺序的细节但核心逻辑就是上面这段。生成质量的评估我强烈建议不要只看loss。最可靠的办法是把生成的MIDI导入DAW把钢琴卷帘打开肉眼加耳朵一起过一遍。看音符是否合理地落在节拍强位上看旋律有没有起伏看结尾有没有收束感。音乐是好是坏很多时候人类一听就能判断比任何数值指标都直观。4. 踩坑实录训练与生成中的高频问题排查4.1 Loss不降速查先别调模型查数据和Token训练Loss一直不降新手第一反应是模型结构改错了但其实十有八九是数据或Token化的bug。先做一件事用一小批干净数据过拟合。比如只取20条清洗过的曲子训练几轮看模型能不能把训练集loss压到很低。如果过拟合都做不到大概率是Token化或数据解析出了问题比如TimeShift累加出错、Duration单位不统一、Pitch范围超出词表。这时候调模型结构纯属浪费时间。如果过拟合没问题但验证集loss一直横盘那就是数据本身的噪声太大或者序列切分方式不对。检查一下训练集和验证集是不是有重复的曲子、有没有混入轨道极其混乱的MIDI、Padding的loss是否屏蔽掉了。学习率也需要排查。学习率太大会让loss曲线像心电图一样反复跳太小声收敛得像蜗牛。我习惯用3e-4配合warmup起步如果明显不稳定降到1e-4。4.2 生成“复读机”重复和空洞的深层原因音乐生成里最高频的问题是开头还行越到后面越像原地踏步。这个现象的根源有两个。第一个原因纯粹是采样参数设置不对。温度太低、重复惩罚太低都会让模型倾向于重复概率高的历史token。先把rep调到1.3以上、温度调到0.9到1.0再试听绝大多数复读问题能缓解一半。第二个原因比较隐蔽模型本身太大训练数据又不够多导致它把训练集中的整段旋律“背”下来了。生成时会按照训练数据的习惯把某一段旋律原封不动地复读出来。这种情况光调采样参数没用需要减小模型容量、增加数据量、加正则化dropout和weight decay或者干脆换更早的checkpoint——早停的模型往往比训满epoch的模型生成更有创造性。4.3 听感乱、节奏无律动问题多半出在Token粒度与顺序如果你生成的钢琴曲听感不是“复读机”而是“一堆音符乱七八糟地砸下来”节奏感全无那问题大概率出在TimeShift粒度的设计上。我刚开始用每拍一个tick的粗粒度生成的曲子全是“机器人式”的齐整音符没有一个附点、没有一处延后听感非常机械。后来把时间分辨率改细到“每拍32个tick”模型才终于学会了一点“人类演奏”的微浮动。TimeShift粒度需要在词表大小和节奏精细度之间找平衡四分音符分解成32份左右是比较稳妥的选择。另一个容易忽视的是Token顺序。Pitch、Velocity、Duration、TimeShift这几个token的排列顺序不能乱。常见的事件顺序是先出现Pitch和Velocity然后是Duration最后用TimeShift把时间推进到下一个事件。如果你把TimeShift放在Duration前面模型很难理解“这个时长到底属于哪个音”生成的音符时长就会错位。保持一个稳定一致的编码顺序比模型调参重要得多。4.4 显存与速度问题几个立竿见影的土办法因为项目用的是Decoder-only Transformer训练和生成时序列长度直接决定显存占用。如果单卡跑不动优先级从高到低是序列长度先减半比如从512降到384甚至256看效果掉多少再决定要不要加回去。不要一上来就追求1024。梯度累积显存不够时把batch size拆成几小步效果几乎一致。半精度训练主流框架都支持bf16/fp16对Transformer收益非常明显显存减半、速度翻倍。sequence packing把多个短序列拼成一个长序列省掉padding开销训练吞吐更高。代价是注意力mask处理稍复杂第一版可以不做。如果这些都做完了还慢检查是不是在生成时没有复用历史token的KV缓存。音乐生成的序列不长KV cache优化可以后面再做但如果你想跑长序列的多轨生成这一步迟早要补上。最后整理一个快速排查表症状优先排查方向备选方案Loss不降Token化/数据解析bug调整学习率、warmup生成复读调高rep、温度减小模型、早停checkpoint节奏死板TimeShift粒度太粗丰富Velocity/Duration变化显存爆序列长度过长梯度累积、半精度训练听感混乱多轨数据混杂先单轨训练、加休止符这五个问题基本覆盖了一个Transformer音乐生成项目从第一版到能稳定出活儿的全过程。每一条我都自己踩过不止一遍写出来也是希望大家少走点弯路。最后分享一点个人体会在音乐生成这个方向模型的参数规模远没有看起来那么重要。我反复实验下来真正拉开效果差距的往往是最开始那个不起眼的Token化设计以及采样时你给模型戴上的那几条“规矩”。如果你也想像做一个能续写旋律的小工具建议先把这套管线在单轨钢琴上跑通再考虑加入多轨、和弦与可控生成。后面那几步几乎所有问题都可以从这一篇的思路里扩展出来。

Transformer搭建音乐生成模型：从MIDI Token到AI续写钢琴曲

相关推荐

STM32H743 FPU与CMSIS-DSP实现1024点FFT实战指南

DAG-GNN：用图神经网络与连续优化从数据中学习有向无环图

从GitHub PR到open-code-review：代码评审流程的自动化升级

更多资讯

开放式代码评审：从理念到落地的高效工程实践

SAP物料编号范围配置原理与实战避坑指南

diagram-design：从规范到组件，搭建统一图表设计体系

数码管识别为何不用OCR？OpenCV+轻量CNN实战方案

Docker入门实战：从镜像容器到Compose编排，解决环境一致性问题

DeskcommCRM实战：销售自动化配置、数据清洗与团队落地全记录

今日更新

悟空开源无代码平台实战：从实体建模到应用设计避坑指南

基于.NET9的多租户权限系统：数据权限与动态API落地实践

场地预约小程序毕设实战：SSM+微信小程序+MySQL数据库设计到避坑

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？