会员专区

125M Transformer跑在手机上：端侧MIDI生成模型的实时推理设计

, , , , ,

摘要：125M参数Transformer可在iPhone上离线续奏MIDI。本文区分项目事实与工程推演，分析音符级Token、Core ML量化、KV Cache、冷启动、P99延迟和端侧音乐生成的质量边界。

端侧MIDI Transformer实时推理示意图 把“音乐生成”放进手机，未必需要在波形上硬算。开发者 SimEdw 的 RollTab 做了一个更适合端侧的选择：让用户用 MIDI 键盘弹几下，125M 参数的 decoder-only Transformer 接着演奏。原作者报告其在 iPhone 15 上约可生成 **108 个音符/秒**，模型完全离线运行。下面将明确区分项目已披露事实与通用工程推演。
端侧MIDI Transformer实时推理示意图
端侧MIDI Transformer实时推理示意图

关键不是模型大小，而是一个音符只跑一次主干

MIDI 保存的不是声音采样，而是音高、力度、起止时间、踏板等事件。最直观的 Token 化是 NOTE_ON / PITCH / VELOCITY / NOTE_OFF / TIME_SHIFT。它语法清楚，却会让一个音符消耗多个自回归步；小模型还容易漏掉 NOTE_OFF，产生“挂音”。

**【原项目事实】**最终表示为：

1
NOTE(pitch, delta_onset, duration, velocity)

每个音符含事件类型、音高、相对前一音符起点的时间差、时值和力度五个离散字段。各字段分别嵌入后相加，Transformer 主干每个音符只执行一次，再由多个输出头预测字段；一个小型嵌套解码器让后字段依赖先字段。和弦中的音符按音高排序，并令后续音符 delta_onset=0。时间按每四分音符 24 格量化；延音踏板在预处理时折算进时值，而不是作为独立事件。

这项表示同时解决三件事：减少自回归步数、避免 note-off 状态漂移、让“沉默”附着于下一音符，不再额外生成 TIME_SHIFT。代价是离散化损失，以及显式踏板动作被抹平。

自回归续奏与时序建模

**【原项目事实】**模型采用 RMSNorm、RoPE、因果自注意力和 SwiGLU，规模有 33M、64M、125M；输入提示通常为 4—32 个音符，16—32 个更可靠。模型逐音符采样，预测 pitch、delta、duration、velocity；训练时对字段间使用最高 50% 的 scheduled sampling，以缩小教师强制与真实滚动生成之间的偏差。上下文训练上限为 512 个音符，接近上限时保留最近 384 个并重建上下文。项目也承认短提示、循环重复仍是弱点。

RoPE描述的是序列位置，delta_onset描述的是音乐时间：前者帮助注意力区分第几个事件，后者表达节奏间隔。两者不能互相替代。音乐的动机、和声进行跨越多个音符，自注意力适于从提示中寻找重复与长程关系；但固定 512 音符窗口仍可能遗忘较早段落。

生成质量也属于实时系统

**【原项目事实】**最终训练集包含数十万份 MIDI、约三亿个音符事件。作者筛选钢琴材料，按密度与音域过滤，并用忽略整体移调、统一变速的指纹去重；盲目把数据扩大约五倍反而变差。基础训练对五个输出头求交叉熵，之后再以成对偏好做 DPO；其“共识”偏好数据版本在自动成对评测中，有 69.05% 的续奏胜过基础模型。

这提醒端侧团队：平均延迟达标不等于产品可用。若采样策略造成循环、突兀停顿或节奏失控，再快也不是“实时合奏”。质量回归应同时记录重复音高片段、音符密度、长停顿与提示衔接度，并保留人工听评；逐字段准确率只验证局部预测，不能代表数十步滚动后的音乐性。

端侧工程架构

1
2
3
MIDI键盘 → CoreMIDI事件 → 踏板/量化/排序 → 最近音符上下文
                                      ↓
音频合成器 ← 调度(delta、duration、velocity) ← 采样器 ← Core ML Transformer

**【原项目事实】**PyTorch 模型导出为 Core ML，并做 INT8 权重量化；首次启动较慢，因为 Apple 运行时会针对设备优化模型。125M 个权重若按 INT8 粗略估算，纯权重约 125 MB，实际包体还包括量化尺度、图结构和元数据。

**【通用工程推演】**INT8 的首要收益通常是减少包体与内存带宽，不保证所有设备都按整数算子执行，也不保证延迟等比例下降；需分别在 CPU/GPU/Neural Engine 上实测。Core ML 编译器可能完成常量折叠、布局变换及部分算子融合，但“RMSNorm+投影”“QKV+attention”等能否融合取决于导出图、系统版本和后端，原项目没有披露手工融合，不能把它写成既成事实。

KV Cache：能做，但接口形态决定收益

**【原项目事实】**作者在截断到 384 音符时重建 KV Cache，并称 Core ML 未直接暴露 Q、K、V，因此没有实现更精巧的移位位置或环形缓冲。

**【平台能力与推演】**Apple 从 iOS 18/macOS 15 起支持 stateful Core ML 模型，可把 KV 作为状态在多次预测间更新；也可把缓存显式设计成模型输入输出。这意味着后续版本可以采用固定容量 KV、滑动窗口或分块预填充，但需重新组织模型图，并承担缓存内存：其大小随层数、上下文和隐藏维度线性增长。逐音符只追加一个位置时，KV Cache 可避免重复计算历史 K/V；窗口切换时仍要处理位置、掩码和缓存覆盖，绝非“打开开关”即可。

性能与延迟预算

108 音符/秒对应约 9.3 ms/音符的吞吐倒数，但它不是严格的端到端单音延迟。真实链路还包括 MIDI 回调、Token 化、Core ML 调用、采样、事件调度和软音源音频缓冲。

**【工程目标推演】**可把模型单步目标设为 10 ms 左右，将输入至续奏事件排入调度队列控制在 20—30 ms；音频缓冲另行核算。和弦会瞬间产生多个音符，因此还要测 P95/P99、热机与冷机、长上下文、温控降频，而不能只看平均 notes/s。预先生成短小“前瞻队列”能抵抗抖动，却会降低模型对用户最新输入的响应性。

为什么 MIDI 比波形更适合端侧

同样一秒音乐，波形模型要生成数万采样点或大量声学 codec token，还要建模音色、混响与噪声；MIDI 只生成稀疏的乐符事件，把发声交给成熟软音源。于是序列更短、输出空间更结构化、结果可编辑，端侧功耗与延迟都更可控。代价也明确：它不能生成歌声、真实空间感或细腻触键音色，最终听感高度依赖合成器。

扩展方向

  1. 以 64M 蒸馏 125M，并针对 pitch/delta 等分头校准量化误差。
  2. 在 iOS 18+ 尝试 stateful KV Cache，对比显式缓存、滑窗重建与无缓存基线。
  3. 引入小节、拍号、和弦或段落摘要作为低频条件，缓解 512 音符窗口的结构遗忘。
  4. 用真实设备建立冷启动、P99 延迟、峰值内存、功耗和生成质量的联合回归集；4-bit 量化必须经过听感与滚动生成评测，不能只看逐字段损失。

参考资料

分享到