108个音符每秒。不是云端服务器集群在满载运转，而是安静地跑在一部iPhone 15上。当行业还在卷千亿参数、拼算力账单时，有人反着来，用不到两千万的轻量模型和一台手机，硬生生捏出了钢琴界的“GitHub Copilot”。说实话，这反差感直接把预期拉满了。
开发者花了近一年，跑了14轮实验，终于让AI能实时“接话”你的琴键。不依赖网络，不卡顿，直接上手。项目叫RollTab，免费开放给带MIDI键盘的苹果设备。但别急着下APP，这背后是一场与数学表示法、数据噪音和人类审美底线的硬仗。
咬碎MIDI的骨头
音乐是抽象的，但Transformer只认离散符号。MIDI文件存的不是声波，是一连串事件：按键触发、力度变化、延音踏板切换、乐器替换。怎么把它们切成模型能嚼碎的词？
一开始，作者试了最粗暴的映射。每个音符属性独立成token，结果词汇表直接爆炸。128个音高乘128种力度，光Note_On就干出1万多个组合。小模型根本扛不住，参数一多就漂移。弹着弹着音符悬空了，要么忘了关，要么彻底乱套。
换语法掩码约束？结构严谨了，但推理太慢。一个真实音符要拆成四次自回归步骤，上下文窗口瞬间被吃干。老实讲，端侧实时生成，不能靠堆复杂度。最终破局的是“打包”：把音高、起奏时间差、时长、力度压进一个完整的NOTE token。不用单独发TIME_SHIFT指令，沉默就是下一个音符的延迟。一次前向传播，推进一整组音符。速度直接飙到108 notes/sec，人耳根本追不上。
数据越“脏”，AI越“聪明”
表示法定稿只是入场券。训练大模型都信奉“数据为王”，但这回恰恰相反。作者扒遍公开数据集，筛古典乐，写清洗脚本。几万份文件，3亿个音符事件。他试过把数据量放大5倍，结果模型反而变笨。有意思的是，干净的数据切片，永远比盲目的规模堆砌更有效。
训练目标也踩了坑。传统交叉熵只能预测“下一个音是什么”，但音乐续写哪有唯一解？作者转用Gemini做pairwise评估，让AI对比两段续写谁更连贯。这招成了转折点。配合DPO（直接偏好优化），β值微调至0.03，模型从“偶尔灵光”变成“稳定输出”。偏好胜率直接跳到69%。
更反直觉的是Scheduled Sampling。训练时故意喂模型自己预测的错误音高，验证集Loss明明上升了，实际生成质量却大幅提升。个人觉得，这就像练琴不只看节拍器准不准，得适应自己手指偶尔的抢拍或拖沓。过度拟合完美数据，反而会让模型失去现场感。
跑在手机里的“隐形琴键”
模型再强，跑不起来也是纸上谈兵。作者把PyTorch导出Core ML，权重量化到INT8。首启慢？Apple的runtime会自己编译优化。上下文超过512？截留最近384条，重建KV缓存继续推。RoPE位置编码本来想玩环形缓冲的花样，Core ML不暴露QKV矩阵，算了，能用就行。
这套逻辑切中了当下AI落地的死穴：云侧延迟高、隐私敏感、算力门槛厚。端侧模型虽然参数缩水，但响应是毫秒级的。你按下C4，它半秒内给出和弦走向。不等你犹豫，节奏已经推着往下走。
“Almost a year ago, I started tinkering with an idea: connect my MIDI piano to my phone, play something, and have AI autocomplete the song for me.”
没有华丽的论文包装，只有实打实的工程妥协。视频里那台跑着模型的旧手机，风扇没转，电量没掉，只有琴声在流淌。
算法替手，还是替脑？
很多人担心，AI接歌会不会剥夺即兴的快乐？评论区一位古典钢琴家点破了核心：“生成成本归零后，剩下的全是品味。”探索可能性，然后果断砍掉那些走不通的死胡同，这才是创作的内核。AI能帮你更快撞墙，也能偶尔扔出一块璞玉。
作者也没回避翻车现场。Mirostat降低了重复，却让旋律断裂；自蒸馏没提效；绝对评分不如相对打分。他甚至坦言，短提示（4个音）最难猜，16个音以上才靠谱。这项目远非完美，循环偶尔出现，离成熟产品还有距离。但它像极了早期LLM的模样：粗糙，有毛边，但生命力旺盛。
当指尖落下，屏幕亮起，代码与五线谱开始共舞。我们到底是在用AI辅助肌肉记忆，还是在邀请一个不懂乐理却懂概率的搭档？或许答案不在参数里，而在下一次你按下琴键时，愿意交出多少控制权。
【锐评】：端侧模型不拼算力拼克制，AI接管的是重复劳动，留给人的是选择权。
参考链接：
https://simedw.com/2026/08/20/midi-autocomplete/