在裝置上訓練 125M 參數模型以實現即時鋼琴自動補全

現在，一個 125M 參數的 transformer 模型可以在行動裝置硬體上即時補全鋼琴演奏，於 iPhone 15 上達到每秒約 108 個音符的速度。此專案透過名為 RollTab 的應用程式實現，展現了透過專注於優化的 MIDI 表示、積極的資料清洗以及訓練後的偏好優化，即使使用相對小型的模型也能達成高品質的音樂延續。

面向即時推論的優化 MIDI 表示

在 MIDI 建模中的主要技術挑戰，是將連續的音樂事件轉換為變壓器可預測的離散序列，同時不犧牲推論速度或音樂連貫性。

超越 Note-On/Note-Off

傳統的 MIDI 表示方式通常使用獨立的 NOTE_ON 和 NOTE_OFF 標記。然而，小型即時模型經常會出現「漂移」問題，即忘記發出 note-off 標記，導致音符懸掛。雖然語法遮罩的標記串流（例如 [NOTE_ON, PITCH, VELOCITY]）能確保語法正確性，但每首音樂音符需經過多次變壓器運算，導致生成速度變慢。

單一標記音符表示法

為最大化吞吐量，最終模型採用每次推進一個完整音符的表示方式。每個音符由五個分類欄位組成：

• 事件類型：（例如 NOTE、PAD、BOS、EOS）
• 音高：128 種 MIDI 音高
• 起始時間差：自上一個音符起始以來的時間（以每四分音符 24 步量化）
• 持續時間：音符長度（量化）
• 力度：音符強度

與平坦的標記串流不同，每個欄位都有獨立的嵌入。最終的音符標記是這些嵌入的總和。模型為每個欄位使用獨立的輸出頭，並搭配小型巢狀解碼器，讓後續欄位能根據同一音符中先前預測的欄位進行條件化。此架構使昂貴的變壓器主幹僅需每音符運行一次。

資料工程與增強

模型表現主要取決於資料品質，而非數量。開發者發現，將資料集擴大至原本的五倍反而導致性能下降，突顯了積極清洗的重要性。

資料集流程

訓練資料集包含數十萬個 MIDI 檔案（約 3 億個音符事件），主要聚焦於公有領域的古典音樂。清洗流程包括：

• 篩選以鋼琴為主的內容，並移除異常的多軌混合。
• 使用忽略整體移調與均勻節奏變化的指紋進行去重。
• 將同一作品的不同版本歸入同一資料分割，以防止資料洩漏。

處理延音踏板

為簡化建模問題，延音踏板事件已被移除。相反地，延音在預處理階段已內嵌至音符持續時間中：若某個琴鍵在延音踏板按下時釋放，則該音符的持續時間會延長至踏板釋放時間。

面向即時輸入的增強

由於即時人類輸入不完美，模型訓練時加入了增強技術，以確保對時間與力度錯誤的魯棒性：

• 全局移調與均勻節奏縮放。
• 持續時間與力度抖動。
• 丟失提示音符。

訓練與優化策略

該模型為僅解碼器的 transformer，採用 RMSNorm、旋轉位置嵌入（RoPE）以及 SwiGLU/MLP 模組。

排程採樣

為彌補訓練（模型看到真實音高）與推論（模型看到自身預測）之間的差距，開發者實作了排程採樣。透過逐漸提高模型接收自身預測音高的機率（最高達 50%），即使驗證損失上升，生成結果的品質仍有所提升。

直接偏好優化（DPO）

DPO 是提升延續可靠性最重要的因素。開發者使用 Gemini 3.5 Flash 對生成的延續進行成對評估，根據兩個標準打分：輸出與提示的符合程度（延續分數）以及整體音樂品質（聽起來好分數）。

使用「共識」資料集（評估者意見一致）與介於 0.01 到 0.03 之間的 $\beta$ 值，模型的偏好率從基礎預訓練模型提升至 69.05%。

裝置端部署

模型已匯出為 Core ML 並量化至 INT8 以供 iOS 部署。為處理超過 512 个音符訓練上下文的會話，應用程式會維護最近的 384 個音符，並在達到限制時重建 KV 快取。

社群見解與批判

儘管此專案因其技術執行與裝置端表現受到讚譽，卻也引發了音樂家與 AI 研究者之間關於音樂即興創作本質的辯論。

"這些結果給我的感覺與馬可夫模型的結果相當，甚至更差……你必須建立一個流程，將音樂分解為和聲序列與旋律序列，或開發更好的資料集。" — @rajivayyangar

"我無法想像有人真的想學習和聲、和弦配置與聲部進行……他們只想按幾個鍵，然後宣稱自己創造了電腦生成的東西。" — @bubblegumcrisis

其他使用者建議將模型擴展以支援多聲部伴奏（例如巴洛克風格），或整合為 VST/Max 4 Live 裝置，以供專業音樂製作使用。