你在钢琴上弹出《致爱丽丝》的开头，手机接过旋律，继续往下弹。它不用把演奏上传云端，也不用等远处的服务器回应。这正是 RollTab 想做的事：把一个 125M 参数的音乐模型放进 iPhone 或 iPad，让它像“钢琴版 GitHub Copilot”一样实时续写演奏。值得看的不只是模型够小，而是作者怎样重新整理音乐，才让小模型跟得上人的手。
本文数据和效果均来自作者本人文章，尚无论文、代码、模型权重、标准基准或第三方复现。
先把演奏变成模型能读的东西
模型处理的不是录音，而是 MIDI。MIDI 不保存声音波形，而是记录琴键的音高、按下与松开时间、力度等演奏事件。Transformer——一种根据上下文预测序列后续内容的神经网络——可以像续写文字一样，预测接下来会出现哪些 MIDI 事件。
难点是怎样把这些事件交给模型。
一种直观做法，是把“按下琴键”“松开琴键”和“时间前进”分别写成 token，也就是模型能够识别和生成的基本单位。但作者称，小模型容易在这种表示下逐渐失去状态：忘记生成松键事件，留下持续不消失的音，或者记不清哪些琴键仍处于按下状态。
另一种做法把一颗音拆成音高、力度、时长等多个步骤。状态更清楚了，速度却慢下来：生成一颗音大约需要 Transformer 连续运行四次，还会更快耗尽模型能够回看的上下文。
一次生成一整颗音
作者最终把每颗音表示为四项信息：音高、与上一颗音起点的时间差、持续时间和力度。休止不再需要单独的“时间前进”事件；下一颗音晚多久出现，就直接写进它的时间差信息里。和弦中的多颗音则共享零时间差，并按音高排序。
可以把它理解为填写一张音符卡片。模型不再先写“这是音符”，再逐格填写音高、力度和时长；昂贵的 Transformer 主干每颗音只运行一次，随后由较小的解码部分补齐各字段。作者报告称，较大版本在 iPhone 15 上可生成约 108 notes/sec，也就是每秒约 108 颗音符。不过这个数字没有披露量化方式、上下文长度、生成设置和设备负载，因此不能直接当作端到端延迟或音乐质量指标。
延音踏板也被提前折进音符时长：踏板按下时，即使琴键已经松开，音符仍延长到踏板抬起；若同一音高先被再次弹下，旧音会提前结束。这样会丢掉明确的踏板动作，却把模型要预测的内容收窄到音高、起点、时长和力度。
小模型为什么值得看
作者用 14 次实验迭代这个项目，并称提升最大的三个因素是改进 MIDI representation（MIDI 表示方式）、积极清洗训练数据，以及加入 DPO post-training。DPO（Direct Preference Optimization，直接偏好优化）是在训练后用成对偏好样本校准模型，让它更倾向于人们认为更好的输出。
数据处理同样围绕任务做减法。公开 MIDI 文件可能同时包含旋律、和弦、贝斯、鼓和弦乐；这个项目只做钢琴续写，因此作者主要保留类似钢琴的材料，并移除或削弱其他声部。
这套取舍指向一种不同于云端音乐生成的产品形态：模型不必一次生成完整作品，而是在演奏发生时快速回应。端侧推理——直接在手机或乐器旁的设备运行模型——还能减少对网络连接的依赖，并让演奏数据留在本地。作者称，配套应用 RollTab 已免费提供给连接 MIDI keyboard 的 iPhone/iPad 用户；但免费不等于开源。
局限与未知
- 材料在数据集部分被截断，训练数据的规模、完整来源和清洗标准尚不清楚。
- 作者没有披露模型架构细节、DPO 偏好数据如何构造，也没有给出音乐质量评测或对照实验。
- “实时”和“最大提升”都是作者自述。现有材料能说明设计思路与运行速度主张，还不足以证明它比其他方案更好听、更稳定。