オンデバイスでのピアノ・オートコンプリートのための 125M パラメータ モデルの学習

125MパラメータのTransformerモデルが、モバイルハードウェア上でリアルタイムにピアノ演奏をオートコンプリートできるようになりました。iPhone 15では、毎秒約108音符の速度を達成しています。RollTabというアプリで実装されたこのプロジェクトは、最適化されたMIDI表現、徹底したデータクリーニング、そして学習後の好みの最適化（preference optimization）に焦点を当てることで、比較的小規模なモデルでも高品質な音楽的継続が可能であることを示しています。

リアルタイム推論のための最適化されたMIDI表現

MIDIモデリングにおける主な技術的課題は、連続的な音楽イベントを、推論速度や音楽的な一貫性を損なうことなく、Transformerが予測可能な離散的なシーケンスに変換することです。

Note-On/Note-Offを超えて

従来のMIDI表現では、多くの場合、個別の NOTE_ON と NOTE_OFF トークンが使用されます。しかし、小規模なリアルタイムモデルは、しばしば「ドリフト」に悩まされます。これは、ノートオフ・トークンを出し忘れてしまい、音が鳴り続けてしまう（hanging notes）現象です。文法マスクされたトークンストリーム（例：[NOTE_ON, PITCH, VELOCITY]）は構文的な妥当性を保証しますが、1つの音楽的な音符ごとに複数のTransformerパスを必要とするため、生成速度を低下させます。

シングル・トークン音符表現

スループットを最大化するため、最終的なモデルは、Transformerが一度に1つの完全な音符を進行させる表現を使用しています。各音符は、以下の5つのカテゴリカルなフィールドの組み合わせとして表現されます：

• Event Type: (例：NOTE, PAD, BOS, EOS)
• Pitch: 128 MIDIピッチ
• Delta Onset: 前の音符のオンセットからの経過時間（4分音符あたり24ステップに量子化）
• Duration: 音符の長さ（量子化済み）
• Velocity: 音符の強さ

フラットなトークンストリームではなく、各フィールドには独自の埋め込み（embedding）があります。最終的な音符トークンは、これらの埋め込みの合計です。モデルは各フィールドに対して個別の出力ヘッドを持ち、小さなネストされたデコーダーによって、同じ音符内の後続のフィールドが、同じ音符内の先に予測されたフィールドを条件として利用できるようにしています。このアーキテクチャにより、コストの高いTransformerバックボーンは、1つの音符につき1回だけ実行されます。

データエンジニアリングと拡張

モデルの性能は、量よりもデータの質によって決まりました。開発者は、データセットを元のサイズの5倍に拡大すると、実際には性能が低下することを発見しました。これは、徹底したクリーニングの重要性を浮き彫りにしています。

データセット・パイプライン

学習セットは、数十万のMIDIファイル（約3億の音符イベント）で構成されており、主にパブリックドメインのクラシック音楽に焦点を当てています。クリーニング・パイプラインには以下が含まれます：

• ピアノに特化した素材をフィルタリングし、病的なマルチトラック混合を削除すること。
• 全域的な移調や一様なテンポ変更を無視するフィンガープリントを使用して、重複を除去すること。
• 同じ楽曲の別バージョンを、リークを防ぐために同じデータ分割（data split）に含めること。

サステイン・ペダルへの対応

モデリングの問題を単純化するため、サステイン・ペダル・イベントは削除されました。その代わりに、サステインは前処理において音符の長さに組み込まれています。つまり、サステイン・ペダルが踏まれている間にキーが離された場合、音符の長さはペダルが離された時間まで延長されます。

ライブ入力のための拡張（Augmentation）

人間のライブ入力は不完全であるため、モデルはタイミングやベロシティのエラーに対して堅牢であることを確らすために、拡張（augmentation）を用いて学習を行いました：

• 全域的な移調と一様なテンポ・スケーリング。
• 音符の長さ（duration）とベロシティのジッター。
• プロンプト・ノートの欠落。

学習と最適化戦略

このモデルは、RMSNorm、rotary positional embeddings (RoPE)、および SwiGLU/MLP ブロックを特徴とするデコーダーのみのTransformerです。

スケジュール・サンプリング

学習（モデルが正解のピッチを「見る」状態）と推論（モデルが自身の予測を「見る」状態）のギャップを、埋めるために、開発者はスケジュール・サンプリングを実装しました。モデルに自身の予測したピッチを徐々に的に与える確率を（最大50%まで）高めることで、バリデーション・ロス（validation loss）は増加したものの、ロールアウトの品質が向上しました。

Direct Preference Optimization (DPO)

DPOは、継続（continuation）の信頼性を向上させる最も重要な要因でした。開発者は、Gemini 3.5 Flash を用いて、生成された継続のペアワイズ評価（pairwise evaluation）を実行し、2つの基準でスコアリングを行いました：出力がプロンプトに従っているか（continuation score）と、その一般的な音楽的品質（sounds-good score）がどれくらい優れているかです。

評価者が一貫して同意する「コンセンサス」データセットと、0.01から0.03の $\beta$ 値を使用することで、モデルの好みの確率は、ベースとなる事前学習済みモデルと比較して69.05%に跳ね上がりました。

オンデバイス・デプロイメント

モデルは Core ML にエクスポートされ、iOS デプロイメントのために INT8 に量子化されました。On-device での性能を継続的に管理するため、アプリは直近の384音符を保持し、制限にreached 達した際、KV キャッシュを rebuild します。

コミュニティ・インサイトと批判

このプロジェクトは、技術的な実行力とオンデバイスでの性能については称賛されましたが、音楽家やAI研究者たちの間で、音楽的即興の性質に関する議論を巻き起こしました。

"The results strike me as comparable or worse than you could get with a Markov model... you need to either set up a pipeline to decompose music into harmonic sequences and melodic sequences, or develop a better dataset." — @rajivayyangar

"I can'|t imagine that anyone actually wants to learn about harmony, about voicing, and voice leading... They want to just press some keys and declare that they made what the computer generated." — @bubblegumcrisis

他のユーザーは、モデルをマルチパート・アカンパニメント（例：バロック様式）に対応させるために拡張するか、あるいはプロフェッショナルな音楽制作のための VST/Max 4 Live デバイスとして統合することを提案しました。