이미지: Hacker News (200↑)
摘要
- 一个1.25亿参数的Transformer模型在iPhone15上实现每秒约108个音符的实时生成。
- 训练数据扩大5倍后性能反而下降,最终依靠数十万个精选MIDI文件完成模型训练。
- 经过DPO后训练后,被评为优于原模型的比例超过69%。
- 모델 크기
- 1억 2,500만 파라미터(125M) 트랜스포머
- 기기 성능
- 아이폰15에서 초당 약 108개 음 생성
- 학습 데이터
- 수십만 개 MIDI 파일, 약 3억 건 노트 이벤트
- 데이터 스케일링 실험
- 데이터 5배 확장 시 오히려 성능 저하
- DPO 후 선호도
- 기존 모델 대비 69% 이상 우위(쌍대 평가)
- DPO 베타값 스윕
- 0.01·0.03은 개선, 0.10은 성능 저하
- 컨텍스트 길이
- 학습 시 최대 512 노트, 실사용 시 최근 384 노트 유지·재구성
- 앱 심사 기간
- 첫 버전 승인까지 11일 소요
只需在钢琴上弹几个音符,AI就能接续演奏
在MIDI键盘上弹奏几小节短旋律后,iPhone屏幕背后运行的模型会实时接续演奏剩余部分。Hacker News用户名为simedw的独立开发者训练了一个1.25亿参数(125M)规模的Transformer模型,并免费发布了钢琴自动补全应用"RollTab",可在iPhone15上以每秒约108个音符的速度生成音乐——这一速度已超过人类实际演奏的极限。
这种方式可以类比开发者熟悉的工具。就像GitHub Copilot以几行代码或注释为提示词补全剩余代码一样,该模型以用户在键盘上弹奏的几个音符为提示词,续接完成整段乐曲。不过与Copilot作为调用用户自选第三方模型(GPT、Claude、Gemini等)的窗口型产品不同,RollTab运行的是开发者亲自训练的模型,且完全在设备本地运行。这意味着所有推理都在iPhone内部完成,无需与服务器通信。
该开发者透露,历时近一年、经过十四次实验才达成这一成果。"Think GitHub Copilot, but for piano"——他在博客文章开头写下的这句话,概括了该项目的目标。
如何切分MIDI数据才能让模型学会
MIDI文件并非录制的声音,而是"按下琴键""松开琴键""踩下踏板"等一系列事件的记录。将这些事件转换为Transformer可读取的令牌序列的过程中,出现了最大的难题。为每个音符单独生成"开始"和"结束"事件的方式,常常导致模型忘记结束信号,使音符持续鸣响不止,这一问题在接近实时运行的小型模型中尤为突出。
经过多次试错,开发者最终选择了一次性表达单个音符的方式。每个音符同时携带与前一个音符的时间间隔(delta_onset)、音高、时长、力度这四个分类值,将原本Transformer骨干网络需要针对每个字段运行四次的过程,缩减为每个音符仅运行一次。他解释称,这一设计变更正是实现每秒108个音符速度的关键所在。延音踏板也未被单独设为事件,而是在预处理阶段将踏板踩下的时间反映到音符的实际时长中,以此简化处理流程。
数据重质不重量——扩大5倍反而变差
最终数据集主要收集了版权已过期的古典音乐MIDI文件,共计数十万个文件、约3亿条音符事件。开发者也曾尝试将数据量扩大约5倍,但结果模型的质量反而下降。他得出的结论是:精选和清洗数据的重要性超过单纯增加数据量。
尝试处理音乐生成模型的项目不止这一个。MiniMax发布音乐模型,仅凭歌词5分钟生成完整曲目
通过偏好学习提升完成度
续写乐曲并非只有一个正确答案的问题。在留出曲目中仅将下一个音符设为"正确答案"进行学习的交叉熵方式,虽然能教会模型基本的音乐语法,但在生成实际听起来自然的完整曲目方面存在局限。为弥补这一点,开发者利用Gemini 3.5 Flash建立了一套评估体系,对两个补全版本进行成对比较,判断哪一方更优,并利用这些偏好数据进行了DPO(直接偏好优化)后续训练。评估时将"对提示词的接续程度"与"音乐性本身是否优秀"分开考量,并以前者作为DPO的核心信号。
应用DPO后,在成对评估中被选为优于原有基础模型的比例超过69%。调整β值进行实验的结果如下:
| β值 | 结果 |
|---|---|
| 0.01 | 模型性能提升 |
| 0.03 | 模型性能提升(最佳区间) |
| 0.10 | 相较原模型偏移过度,性能下降 |
开发者表示,在众多存在噪声的偏好判断中,仅保留评估者判断一致的"共识数据集"在此次实验中取得了最佳结果。
如何在iPhone上实现实时运行
完成的模型经PyTorch转换为Core ML格式,并将权重量化为INT8。开发者透露,应用首次运行时,由于Core ML运行时需要针对设备硬件对模型进行优化,速度会略慢。模型训练时的上下文长度上限为512个音符,但为支持更长的演奏会话,系统采用了当上下文接近上限时,仅保留最近384个音符、并从该点重新构建上下文的方式。
据悉,App Store审核首个版本花费了11天才获批。目前支持top-k、top-p、min-p、XTC、top-h、Mirostat v2等多种采样方式供用户自选的新版本正在等待审核中。这些采样选项是决定模型在选择下一个音符时如何调节多样性与稳定性的设置参数。
如何使用
RollTab面向拥有MIDI键盘及iPhone或iPad的用户免费发布。根据原文披露的信息,使用方法较为简单。首先通过有线或无线方式将MIDI钢琴连接至iPhone或iPad。然后启动RollTab应用,在键盘上短暂弹奏几个音符。这几个音符即成为提交给模型的提示词,模型会据此在设备本地自动生成后续部分。
据原文介绍,作为提示词输入的音符数量会影响生成质量。在开发者的听感评估中,4个音符的提示词因上下文不足而效果最差,8个音符略有改善,而输入16至32个音符时,模型对整体走向的把握更为稳定。举例来说,弹奏一首喜爱曲目的开头几小节,即可获得延续该风格的即兴变奏;在即兴演奏卡壳时稍作停顿,模型也会提示接下来的发展方向。
编辑视角
这个项目所展示的是:即便不是大型研究机构,只要将一个具体问题钻研到底,也能产出实用的成果。Aria、Moonbeam、MIDI-GPT等既有的符号化音乐生成研究,大多以大规模模型和研究基础设施为前提。该开发者透露,他是在完成开发之后,才将自己的方案与Aria、Moonbeam、MIDI-GPT等既有论文进行比较——这一顺序本身就颇有意思。他并非先吸收既有文献,而是先亲自碰壁重新发现问题,再回过头去做验证。
处理过此类小型设备端模型的人应该都熟悉这样一种规律:"数据越多越好"的期待往往会落空。该项目中数据扩大5倍反而导致性能下降的案例再次证明,无论是文本模型、图像模型还是音乐模型,"精选的少量数据优于未经清洗的大量数据"这一原则并不因领域而异。
对于正在研究设备端生成模型的国内团队而言,这个案例值得关注的有两点:其一,DPO等基于偏好的后续训练方法不仅适用于语言模型,对具有时间序列特性的生成任务同样有效;其二,Core ML量化、上下文重构等部署阶段的细节打磨,与模型设计本身同样能左右实际使用性能。这也意味着,花在部署流水线上的时间实际上可能比复现论文本身更长。
预计未来数月内,会有更多独立开发者项目尝试以类似方式将狭窄的创作领域(作曲辅助、歌词续写、编舞序列等)搬到设备端运行。随着Core ML等同类设备端运行时的量化工具不断简化,在智能手机上实时运行1亿参数级别模型的门槛正在降低。
评论