125M钢琴续写模型开源

1.25亿参数，把钢琴续写塞进本地设备

一款参数量仅为 125M（1.25亿） 的钢琴自动续写模型于今天（2026年8月20日）公开，作者将它定位为可以在设备端运行的 MIDI 续写系统：用户先弹出一段钢琴旋律，模型随后预测接下来的音符、节奏与演奏事件，而不是等待云端生成一首完整歌曲。

**钢琴自动续写是根据已有钢琴片段预测后续演奏事件的生成任务。**它更接近编辑器里的代码补全，而不是输入一句提示词、几十秒后拿到成品歌曲的 Suno 式体验。前者服务于创作过程，后者交付的是结果。

这款模型真正值得关注的地方并不是「AI 会弹钢琴」——类似能力已经出现多年，而是它把参数规模压到了 1.25 亿，并明确强调 on-device，也就是在用户自己的电脑或移动设备上完成推理。对于音乐生成而言，这条路线比继续堆叠几十亿参数更接近一个可嵌入宿主软件、可以实时交互的生产力工具。

不过，**125M 只是模型参数规模，不等于完整应用的安装包大小，也不能直接证明生成质量。**截至8月20日，目前公开材料没有给出与其他钢琴生成模型统一口径的困惑度、续写偏好测试、首音延迟或每秒生成事件数，因此外界暂时无法用一组跑分判断它究竟有多会写音乐。

它生成的是MIDI，不是最终音频

**MIDI 是用于描述音符、力度、时值和控制信号的符号化音乐协议。**它记录的不是44.1 kHz或48 kHz采样率下的声音波形，而是诸如「按下中央C、力度为80、持续半拍、踩下延音踏板」这样的演奏指令。

这一差别决定了125M模型为什么有机会在本地运行。音频模型需要处理高密度声学信息，包括音色、混响、空间感、噪声和不同乐器的叠加；MIDI模型只需要处理经过高度压缩的音乐事件，信息带宽低得多。

以一分钟钢琴演奏为例，原始立体声音频可能包含数百万个采样点，而符号化表示通常只需要记录有限数量的按键、松键、力度、时间间隔和踏板事件。模型不必学习三角钢琴琴弦如何共振，也不必直接合成录音棚级音色，只需要回答一个更聚焦的问题：这段音乐接下来应该怎么弹。

**这是一种主动缩小问题边界的工程选择。**125M模型放弃了人声、歌词、多乐器编配和最终音频渲染，换来更低的推理成本、更快的交互速度，以及部署在数字音频工作站、电子琴和移动设备中的可能性。

典型的MIDI续写流程可以拆成四步：

1. 将用户输入的音符、时值、力度和踏板事件编码成离散序列；
2. 模型读取已有上下文，预测下一个音乐事件；
3. 按自回归方式持续生成后续事件；
4. 由本地软音源或硬件合成器把MIDI渲染成可听见的钢琴声音。

**自回归生成是逐个预测下一个事件，并把已生成结果继续作为输入的生成方式。**它与大语言模型逐个生成文本Token的工作方式相似，只是这里的Token可能代表音高、时间偏移、力度或踏板状态。

这种设计也意味着，实际体验不只取决于模型权重。事件如何编码、采样温度如何设置、一次续写多长、宿主如何处理节拍和和弦约束，都会直接影响结果。如果事件切分过细，序列会变长并拖慢推理；如果切分过粗，演奏又容易失去人类钢琴家的速度变化和力度细节。

125M到底有多轻

**参数量是衡量模型权重规模的基础指标，但端侧部署还要同时考虑精度格式、运行时和上下文缓存。**在不计算激活值、缓存及框架开销的情况下，125M模型仅权重部分的理论占用大致如下：

| 权重精度 | 单参数占用 | 125M权重理论体积 | 适合场景 | |---|---:|---:|---| | FP32 | 4字节 | 约500 MB | 桌面端调试、兼容性优先 | | FP16/BF16 | 2字节 | 约250 MB | GPU、NPU或较新的桌面设备 | | INT8 | 1字节 | 约125 MB | CPU与移动端量化推理 | | 4-bit | 0.5字节 | 约62.5 MB | 存储和内存受限设备 |

**上述数字只是理论权重体积，不是实测内存占用。**模型运行时还需要加载计算图、激活值、事件上下文和采样逻辑，部分量化格式也会增加缩放参数与元数据。因此，4-bit版本并不意味着一个完整应用只占62.5 MB。

即便如此，125M仍然处在相对友好的端侧区间。以公开的 MusicGen Small 为参照，后者约有3亿参数，并基于EnCodec离散音频Token生成音乐；125M钢琴续写模型的参数量约为其 41.7%，减少了约 58.3%。更重要的是，两者解决的问题不同：MusicGen面向音频结果，这款新模型面向钢琴事件补全，不能只按参数量判断谁更强。

| 模型或产品路线 | 参数规模 | 输入 | 输出 | 主要能力 | 本地部署成本 | 获取成本与许可 | |---|---:|---|---|---|---|---| | 125M钢琴续写模型 | 1.25亿 | 已有钢琴MIDI片段 | 后续MIDI事件 | 钢琴旋律与演奏续写 | 较低，量化后理论权重可低至约62.5 MB | 作者宣布开源，具体许可证仍应以仓库文件为准 | | MusicGen Small | 约3亿 | 文本或参考旋律 | 离散音频Token及音频 | 文本生成音乐、旋律条件生成 | 中等，音频解码链路更复杂 | 权重可下载，模型卡标注CC-BY-NC 4.0，非商业许可 | | 云端成品歌曲生成器 | 通常不公开 | 文本、歌词或参考音频 | 完整音频 | 人声、编曲、混音一体化生成 | 用户设备要求低，但依赖网络 | 多为免费额度加订阅制，价格随平台变化 |

**这张表说明，125M模型与主流成品歌曲生成器不是直接替代关系。**它不会凭一句「写一首忧伤的爵士钢琴曲」就自动交付混音完成的音频，也没有证据表明它具备歌词理解、人声合成或跨乐器编配能力。

它更像音乐制作软件中的智能伴奏员：创作者弹四到八小节，让模型提出下一段；对结果不满意就回退、重采样，或者保留其中两小节再自行修改。对于专业用户，这种可编辑的中间结果通常比不可拆分的最终音频更有价值。

端侧生成的价值首先是交互，而不是省服务器钱

**端侧音乐生成是在用户本地硬件上完成模型推理，而不把创作内容持续上传到远程服务器。**它带来的第一项优势是低交互延迟，因为实时演奏无法容忍一次补全等待十几秒。

代码补全产品已经证明，生成模型一旦进入实时工作流，速度的重要性会迅速上升。音乐创作对节奏更敏感：一个在用户停顿后立刻给出两小节建议的模型，可能比一个等待30秒、但能生成完整作品的模型更适合作曲；延迟会打断演奏状态，而生成质量的小幅差异反而可以通过编辑修正。

**本地推理的第二项价值是隐私和作品控制。**未发表的旋律、商业配乐草稿和游戏原声动机都可能属于敏感资产，设备端处理可以减少素材上传与服务端留存带来的顾虑。对影视、游戏和广告制作团队而言，这不是附加卖点，而可能是能否采用工具的前提。

**本地推理的第三项价值是离线可用。**电子琴、现场演出设备、教学平板和插件宿主并不总有稳定网络连接，一个轻量模型可以被放入数字音频工作站插件、智能钢琴或便携式创作设备中。

但「可在设备端运行」仍然需要更严格的测试。模型是否支持纯CPU推理、在Apple Silicon或常见NPU上的首音延迟是多少、连续生成一分钟会占用多少内存、量化后是否明显破坏节奏稳定性，这些问题都比一句on-device更能决定产品价值。

轻量模型最难的不是短旋律，而是长结构

**音乐生成的核心难点是同时维持局部悦耳与长期结构。**模型很容易在几秒内写出听起来合理的音符，却可能在一分钟后丢失调性、重复同一型态，或者无法回到之前出现过的主题。

钢琴MIDI虽然比音频简单，但并不意味着任务容易。模型至少需要处理以下关系：

• 左右手在不同音区的协同；
• 和弦进行与旋律音之间的约束；
• 节拍、切分音和自由速度变化；
• 延音踏板造成的跨事件依赖；
• 主题重复、变奏、转调和段落收束；
• 从用户演奏风格延续到生成片段时的一致性。

**参数变小通常会加剧容量与上下文之间的矛盾。**125M模型可能足以学习常见音型、和声走向和局部风格，但要记住较长主题并完成奏鸣曲式级别的发展，仍需依赖更好的数据、事件表示、位置编码和生成控制，而不能只靠参数规模。

评估此类模型也不应该只看训练损失。真正有意义的测试至少应包含三类指标：机器指标用于检查音高分布、节奏重复和调性一致性；音乐家盲测用于评价可用性；系统指标则记录首个事件延迟、生成速度、峰值内存和功耗。

**目前缺少统一基准，是这次开源最明显的信息缺口。**如果作者后续只展示精心挑选的试听片段，而不给随机种子、输入MIDI和量化前后对照，外界很难判断模型是在稳定续写，还是偶尔抽中一个好结果。

开源不等于已经可以商用

**开源模型是公开代码或权重、允许外部检查和运行的模型，但具体使用边界由许可证决定。**开发者不能只看到下载按钮，就默认模型可以放进收费插件或商业游戏。

这次项目是否允许商用、是否要求署名、训练数据是否具有再分发授权，都应以项目仓库中的LICENSE、模型卡和数据说明为准。如果只公开推理代码而不公开权重，或者公开权重却没有明确许可证，其可复用程度会明显下降。

训练数据的版权来源同样不能被轻描淡写。MIDI不包含原始录音，并不意味着它天然没有版权风险；作曲本身、人工转录结果和特定演奏版本都可能受到保护。一个真正适合生态采用的项目，应该说明数据集构成、过滤规则、授权范围及退出机制。

MAESTRO一类公开钢琴演奏数据集提供了相对清晰的研究基础，它包含对齐的钢琴音频与MIDI演奏数据，适合训练和评估符号音乐模型。但即便使用公开数据集，开发者仍需分别检查数据集许可、模型许可和输出使用条款，三者不能混为一谈。

它更适合成为插件，而不是独立生成网站

**125M钢琴续写模型最合理的产品形态，是嵌入现有创作软件的功能组件。**它可以被放进钢琴卷帘窗、MIDI编辑器、智能乐器或教学软件，让用户在原有时间轴里接受、拒绝和局部重写生成结果。

对数字音频工作站而言，一个实用流程可能是：用户选中四小节MIDI，指定续写长度和随机程度，模型在本地生成三个候选版本；用户保留其中一个版本的右手旋律，再让模型重写左手伴奏。整个过程无需导出音频，也不会破坏后续编辑能力。

对音乐教育而言，模型还可以生成终止式、伴奏型或不同难度的后续段落。不过，教学场景要求生成结果符合明确乐理规则，单纯「听起来不错」并不够，产品需要加入调性、和弦、音域和指法约束。

对现场演奏而言，125M规模也提供了想象空间，例如根据演奏者最近几小节生成回应乐句。但这一场景对延迟和稳定性要求最高：一次卡顿、错拍或无限循环，都会比普通离线生成更明显。

这不是音乐大模型的缩小版，而是一条不同路线

**端侧钢琴续写的意义，在于证明音乐生成不必都以完整歌曲和云端超大模型为终点。**当行业不断追求人声更真、编曲更满、成品时长更长时，125M模型选择把生成能力拆成一个可控、可编辑、可本地运行的步骤。

这条路线短期内不会挑战一体化音乐生成平台，因为用户面对的是MIDI，需要自己选择音源、处理结构并完成混音。它的用户也不会是只想一键生成背景音乐的人，而是愿意进入钢琴卷帘窗、修改音符并掌控作品结构的创作者。

**这款模型当前最大的优点是边界清楚，最大的短板是证据还不够。**1.25亿参数确实为端侧部署留下了空间，但没有标准化质量评测、硬件延迟数据和明确许可信息，就还不能把「能运行」直接等同于「能生产」。

更值得观察的是后续生态：是否有人把它量化到INT8或4-bit，是否出现VST/AU插件，是否支持和弦与调性约束，以及模型能否在普通笔记本CPU上做到接近实时的连续补全。如果这些环节补齐，它可能不只是一个Show HN实验，而会成为轻量音乐模型进入实际工作流的样板。

参考来源

• AudioCraft GitHub 仓库：Meta开源音频生成框架，包含MusicGen的代码、模型说明与相关技术资料。
• MusicGen Small 模型卡：提供约3亿参数MusicGen Small的模型架构、适用范围及许可证信息，可用于对比音频生成路线。
• MAESTRO Dataset GitHub 仓库：公开钢琴演奏音频与MIDI对齐数据集的项目说明，展示符号音乐模型常用的数据基础。