125M のモデルを iPhone でピアノ補完に走らせた — オンデバイス推論を運用者目線で読む

まず結論 — real-time はモデルサイズではなくレイテンシで決まる

結論から書きます。2026 年 8 月 20 日に公開された simedw さんの記事は、125M（1.25 億）パラメータの小さな言語モデルを iPhone のオンデバイスで走らせ、MIDI キーボードで弾いたフレーズの続きをリアルタイムに補完する、という事例でした。数字でいうと iPhone 15 でおよそ毎秒 108 ノートを生成できる。演奏に追いつく速度です。

この事例の面白さは「小さいモデルでもここまでできる」ではなく、「リアルタイム性はモデルサイズではなくレイテンシ（応答までの遅延）で決まる」という運用の原則をきれいに見せている点にあります。ピアノの補完は、音を出した次の瞬間に返ってこないと使いものになりません。ネットワークを一往復させた時点で成立しない。だからクラウドの巨大モデルではなく、手元で動く 125M が正解になる。この記事は、その損得を運用者目線で読み直すものです。

何を作ったのか — 125M で MIDI 補完、iPhone 15 で毎秒 108 ノート

作られたのは、デコーダのみの Transformer（GPT と同じ系統の生成モデル）を 125M パラメータで組み、MIDI ピアノの演奏を先読みして続きを生成するモデルです。構成は RMSNorm・回転位置埋め込み（RoPE）・causal self-attention・SwiGLU という、いまの小型言語モデルでは定番の部品を素直に並べたもの。奇をてらった構造ではありません。

面白いのはトークンの設計です。音符を「鍵盤を押す」「離す」の 2 イベントに分けると、小さいモデルでは時間がずれていく「ドリフト」が起きたそうです。そこで著者は 1 音を NOTE(pitch, delta_onset, duration, velocity) という 1 トークンにまとめ、音高・前の音からの間隔・長さ・強さの 5 つの属性を別々の埋め込みにして足し合わせる形にしました。和音は間隔をゼロにした複数ノートで表し、時間は 4 分音符あたり 24 段階で量子化する。1 回の推論で必ず 1 音ぶん進む設計です。地味ですが、この「1 パス 1 音」がリアルタイム補完の速度を支えています。

なぜクラウドではなくオンデバイスなのか — レイテンシの壁

オンデバイスを選ぶ理由は、コストでもプライバシーでもなく、まずレイテンシです。演奏の補完は数十ミリ秒の遅れも許されない用途で、ネットワーク往復（一般に数十〜数百ミリ秒）が入った瞬間に破綻します。だから 108 ノート/秒を手元で出せることが、そのまま製品として成立するかどうかの分岐点になります。

同じ「小さく手元で」という流れは、私が以前読んだ ローカル LLM が 75% パリティに届いた話 や、0.2B の画像インペインティングが 10B 級に並ぶ Moebius の事例 でも見えていました。モデルが「小さく賢く」なる方向は、2026 年に入ってはっきり加速しています。ピアノ補完はその延長線上で、しかも「レイテンシが厳しいほどオンデバイスが有利になる」という条件を一番わかりやすく満たすタスクだと言えます。

ただしオンデバイスにはただ乗りできない税金もあります。著者は、アプリ起動時に Apple のランタイム最適化が走って「いらだつほど遅い」と書いていました。推論そのものが速くても、初回のコールドスタートは別勘定になる。これは私も身に覚えがあります。このサイトの音声合成を VOICEVOX でローカルに回しているのですが、Docker の起動順を一度しくじって動画生成が静かに 4 日止まったことがありました（launchd で自動化を回す罠）。手元で動かす速さの裏には、必ず「立ち上げの面倒」がくっついてきます。

小さくても効く工夫 — 33M / 64M / 125M の選び方

小さいモデルを実用にする鍵は、パラメータ数を盛ることではなく、データの掃除とサイズの見極めでした。著者は 33M・64M・125M の 3 サイズを訓練し、中間の 64M が最大サイズにほぼ並ぶ品質を出したと報告しています。端末に載せる側からすると、この「どこで頭打ちになるか」を測った事実そのものが価値です。

学習データは、数十万の MIDI ファイルから集めた約 3 億のノートイベント。ただし量を追うより、掃除と重複除去を徹底したことが効いたそうです。むしろノイズの多い大きなデータを足すと結果が悪化した、という報告もありました。端末で INT8（8 ビット整数）に量子化して載せる前提だと、モデルは小さいほど扱いやすい。だからこそ「データを綺麗にして小さいモデルで頭打ちまで持っていく」戦略が、オンデバイスと相性が良いわけです。推論は PyTorch から Core ML に書き出し、重みを INT8 に量子化。学習時は 512 音の文脈で、推論では直近 384 音を残して KV キャッシュを組み直す、という運用になっています。

「validation loss が下がった」を信じなかった話

このプロジェクトで一番運用者に刺さるのは、検証ロス（validation loss、学習の途中で測る誤差）が当てにならなかったという告白です。著者は、検証ロスが良くても実際に生成させた演奏の質とはずれる、と気づいて評価のやり方を変えました。数字が下がったことと、良い音楽になることは、別だったわけです。

そこで採ったのが DPO（Direct Preference Optimization、良い出力を選ばせて学習させる手法）です。1 つのフレーズに複数の続きを生成させ、それを Gemini 3.5 Flash に二択で評価させ、勝ち負けのデータで学習する。β を 0.03 に設定した結果、ベースモデルで 24.55% だった「好まれる率」が、合議での DPO 後には 69.05% まで上がりました。ここで大事なのは、ロス曲線ではなく「実際に生成物を回して人（や別モデル）が良し悪しを判定する」評価に切り替えた判断です。

これは AI を運用する側にそのまま効く教訓です。指標が良くなったことを成果と取り違えると、現場で外す。私が AI 生成コードを静的スキャンで検証する話 で書いた「動いた ≠ 正しい」と同じ構図で、ピアノ補完では「ロスが下がった ≠ 良い演奏」でした。何を最終指標に置くかを間違えなければ、小さいモデルでも十分戦える、ということでもあります。

私ならどこにこの発想を借りるか — operator の線引き

私がこの事例から持ち帰るのは、「レイテンシが厳しく・検証は生成物で・データは掃除で稼ぐ」タスクなら、小さいモデルをオンデバイスに置く選択が現実解になる、という線引きです。ピアノ補完は極端な例ですが、同じ条件を満たす用途は身近にもあります。

たとえばエディタ上の補完、手元のログの異常検知、オフラインで動く必要のある入力補助。どれも「往復を待てない」「正解が機械的に確かめにくいので生成物で評価する」「学習データを綺麗にすれば小さくても足りる」という顔をしています。逆に、最新の仕様知識が要る調査や、一発勝負で最高精度が欲しい設計判断は、いまもクラウドの巨大モデルに任せたほうが安い。境目はタスクの性質で決まり、モデルが育つたびに少しずつオンデバイス側へ動いていくはずです。

125M でピアノが弾ける、という見出しは派手ですが、運用者が受け取るべきは「サイズの数字」ではありません。レイテンシの制約と、評価をどこに置くか。この 2 つを自分の手で決められる人にとって、小さいモデルは道具箱の中でどんどん使いやすくなっています。

なお、この記事は AI が下書きを書き、私が公開前に確認・編集して出しています。元記事のコードを手元で動かしたわけではないので、数字は著者の報告に基づく引用として読んでください。