Google ML Drift公開、小さなモデルを作る立場から読んでみました
端末ごとに異なるGPUの言語を通訳するエンジン、そして判断だけを担う小さなモデルVons
ビジネスGoogleがオンデバイスGPUエンジンを切り出して公開しました
Google AI EdgeチームがML DriftをApache 2.0ライセンスで公開しました。携帯電話やノートパソコン、ブラウザの中のGPUでAIモデルを動かす演算エンジンです。GoogleのオンデバイスランタイムLiteRTの下でGPUアクセラレーションを担ってきた部品なのですが、今回単独のライブラリとしても使えるように公開されました。YouTubeショート、Googleフォト、Google Meet、ChromeのGemini Nano機能がすでにこのエンジンの上で動いているそうです。
この発表をVonsと結びつけて読むことになったのは、二つのプロジェクトが同じ層に触れているからです。私はVonsという小さな判断モデルを開発しています。大きなモデルが立てた計画の中で、いくつかの候補から一つを選ぶ、あるいは選ばないと答える部品です。モデルファイル64MiB以下、CPUとブラウザで動くことが設計目標です。つまりML Driftが手をつけている問題、すなわち「小さな機器のGPUでモデルをどう動かすか」が、Vonsの実行環境と直接重なっているのです。
今日はまずML Driftが何を解決したのかを説明し、その後Vonsを作る立場からこの発表がどう読めるかを書いてみます。
GPUごとに言葉が違う
データセンターでAIを動かすときは、同じ機種のアクセラレーターが並んでいます。どのチップで動くかを事前に把握し、それに合わせて最適化すればいいわけです。デバイス側は事情がまったく逆です。アプリを配布した瞬間、そのアプリがどの会社のGPUの、どのドライバーバージョンの上で動くかはわかりません。Androidは主にOpenCLとOpenGL ES、Appleのデバイスは Metal、ブラウザは WebGPU を使います。同じ計算をさせようとしても、GPUに話しかける言語が四つあるようなものです。
Googleの以前の解決策は、TensorFlow LiteのGPUデリゲート1でした。問題は、バックエンドごとにシェーダー2を別々に保守し、テンソル3をGPUのテクスチャやバッファにどう格納するかをバックエンド別のコードに固定していた点です。バックエンドが三つあれば、似たようなコードを三通り管理しなければなりませんでした。テンソルの次元も4次元までに縛られていたため、3次元空間データを扱うモデルのように5次元テンソルが必要な場合には、形を無理やり畳み込む回避策を使うしかありませんでした。
ML Drift: Next-Gen GPU AI/ML Inference at the Edge- Google Developers BlogGoogle AI Edge has introduced ML Drift, a high-performance, universal GPU compute framework designed to accelerate on-device AI and machine learning inference. By abstracting the complexities of hardwML Driftが示した答えは、四つの柱に整理できます。
テンソルの仮想化。 モデルが想定するテンソルの形と、GPUメモリに実際に配置される方式を分離しました。シェーダーはテンプレートとして一度だけ書き、どのGPUでどの格納方式を使うかは初期化段階でコードを生成しながら決めます。リポジトリの説明によれば、この共通シェーダー言語はUCL（Unified Compute Language）と呼ばれ、実行時にGLSL・MSL・WGSLへそれぞれ変換されます。通訳者を一人置いて、四カ国語に訳すような構造です。
生成モデルに合わせた実行。 対話型言語モデルは、一度答えを出す間に働き方が二度変わります。入力文をまとめて読み込むプリフィル4段階は演算量がボトルネックで、答えを一トークンずつ出していくデコード段階はメモリからデータをくみ出す速度がボトルネックです。ML Driftは段階が切り替わるたびにカーネルとデータ配置を入れ替え、デコード段階ではKVキャッシュ5の配置を畳み込み演算に合わせ、中間値をカーネル内で量子化することで不要なメモリの往復を減らすとのことです。
5次元テンソルとカスタム演算。 5次元テンソルを標準でサポートし、開発者がシェーダーを直接登録できるカスタム演算の枠組みを開放しました。ここにコーディングエージェント向けのSKILL.md案内書を併せて入れた点が目を引きます。エージェントがカスタムシェーダーを使い、登録し、検証するのに数分で済むというのがGoogleの説明です。
ブラウザの外のWebGPU。 もともとブラウザ用に書かれたWebGPUバックエンドを、ChromeのWebGPU実装であるDawnでコンパイルし、ブラウザの外でも動くようにしました。おかげでWindowsとLinuxでは、DirectXやVulkanを個別に相手にすることなく同じコードで動き、Macでは既存のMetalバックエンドを使います。Googleはこの部分をデスクトッププレビューと呼び、ローカルで動くコーディングエージェントを用途として挙げています。
グーグルが出した数字、こう読みます
成果の数値も一緒に公開されました。YouTube Shortsでは、映像分割ベースの効果をML Driftに移行したことで、AndroidとiOSの両方で平均フレーム遅延が最大40%減ったとのことです。Googleフォトは従来のGPUデリゲートより最大2秒速くなったといいます。Adobe LightroomやPhotoshopモバイルの被写体選択のような機能では端末内性能が最大30%、Snapchatレンズの顔・スタイル効果ではモデル遅延が30%改善したとのことです。Gemmaモデルのベンチマークでは、他のフレームワークよりメモリ負荷が最大12%少なかったといいます。
これらの数字は2点を踏まえて読む必要があります。ほとんどが「最大」です。どの端末、どのモデルで出た最高値なのかは発表文に書かれていません。そして比較対象はおおむねグーグル自身の従来エンジンです。メモリ12%は「他のフレームワーク」としか記されておらず、何と比較したのかはわかりません。
同じエンジンをめぐって出された数字を時系列で並べてみると、この点がより明確になります。2025年5月に公開されたML Driftの論文は、既存のオープンソースGPU推論エンジンより一桁レベル（order of magnitude）速いとしていました。グーグルが今年1月、LiteRTにML Driftを組み込んだ際に示した数値は、TFLite比でGPU性能1.4倍でした。そして今回の発表のアプリ別数値は30〜40%です。比較基準が変わるたびに、数字の大きさも変わっています。
数字よりも重く受け止めるべきなのは運用面の記述です。グーグルはTFLite GPUデリゲートに今後新機能を追加しないと発表しました。既存モデルはLiteRTのML Driftアクセラレータに移行してもそのまま動くとのことなので、事実上の世代交代の告知です。Android側は単独のLiteRTパッケージからすぐに使うことができ、Google Playサービス内のLiteRTにも近く搭載されるとのことです。ハードウェア面では、Arm、インテル、クアルコムが共同でカーネルを最適化したと明らかにしています。
Chromeについても一点触れておきます。ChromeはGemini Nanoを動かす内蔵AI API（Prompt、Summarize、Writer）にML Driftを組み込んだといいます。今年5月の102号で、Chromeがユーザーの同意なしに4GBのGemini Nanoをダウンロードする問題を取り上げましたが、そのモデルをノートパソコンのGPU上で実際に動かすエンジンが今回公開された形です。エンジンの公開とインストールへの同意は別の問題であり、今回の発表でその疑問が解消されるわけではありません。
Vonsはどこに立っているのか
ここで私のプロジェクトの話に移りますね。Vonsのリポジトリの冒頭に書いておいた一文は「Plan globally. Decide locally. Keep the host in control.」です。計画は大きなモデルが広く立て、決定は近いところで下し、実行の権限はそのモデルを呼び出すプログラム（ホスト）が握る、という意味です。
構造はこうなっています。フロンティアモデルのようなプランナーが現在の状態と、あらかじめ決められたいくつかの候補を渡します。Vonsはその中からひとつを選ぶか、選ばない（棄権する）かを構造化された形で返します。ツールを直接実行することはなく、モデル自身が出した確信度を実行の許可として扱うこともありません。実行、ポリシー、ユーザーの同意はすべてホスト側の仕事です。研究用コードには、一度にスコアを出すDirect採点器と、拡散（diffusion）方式でスコアを出す条件付きDiffusion採点器の両方が入っています。
実行環境も小さく設計しました。英語優先、モデルの資産サイズは64MiB以下を設計目標とし、CPU・WASM上で動作しつつWebGPUは任意にしています。TypeScript SDKはonnxruntime-webを使ってブラウザ内で推論します。WASMであれWebGPUであれ、宣言した方だけで動き、アクセラレータが使えないときに黙って別の方に切り替わることがないようにしました。Chrome拡張機能版も作り、9月25日にChromeウェブストアに提出していて、この記事を書いている時点では審査待ちです。
INLEVEL9/Vons · Hugging FaceWe’re on a journey to advance and democratize artificial intelligence through open source and open science.ただし、Vonsは0.1.0の研究プレビューです。学習済みの重みは配布しておらず、ブラウザでの遅延時間やメモリ使用量についても、まだ公開検証を経た数値はありません。リポジトリにも、測定していない値は0ではなく「なし」として読んでほしいと書き添えてあります。
二つのプロジェクトが交わる地点
同じ層を見ているからといって、同じ問題を解いているとは限りません。二つを並べてみると、まず違いが見えてきます。
| 区分 | ML Drift | Vons |
|---|---|---|
| 正体 | GPU演算エンジン | 判定モデルとSDK |
| 対象とするモデル | 映像エフェクトからGemma級生成モデルまで | 64MiB以下の小型採点器 |
| 答えようとする問い | このモデルをどのGPUでも高速に動かすには | この判断を大きなモデルの代わりに手元で下すには |
| 実行経路 | OpenCL・Metal・WebGPU・OpenGL ES | onnxruntime-webのWASM・WebGPU |
ML Driftが力を注いだ最適化の多くの部分、つまりプリフィル・デコードの切り替えやKVキャッシュの配置は、トークンを連ねて生成していく大きなモデルのためのものです。Vonsは候補を一度採点して終わるモデルなので、その最適化が直接効いてくることはありません。そして一般に、ごく小さなモデルではデータをGPUに移してカーネルを起動する固定コストが、計算そのものより大きくなることがあるため、GPUが常にCPUに勝つわけではありません。VonsがWebGPUを既定値ではなく選択肢にとどめているのには、こうした事情も関わっています。
逆に、ちょうどかみ合う地点もあります。Vons SDKにはコーディングエージェントに接続して使うローカルMCP6サーバーが含まれていますが、ここではWebGPUオプションがわざと塞がれています。ターミナルから起動した子プロセスは、ブラウザのWebGPUアダプタを取得できないからです。そのためVonsでWebGPUを使うには、ブラウザや拡張機能の中でSDKを直接呼び出す必要があります。
Oswarldの視点
私がいつも言っていることがあります。すべての人、すべての仕事に超知能が必要なわけではありません。仕事と環境に合ったモデルが別にあるのです。
私自身の作業方法もそのように分かれています。全体の計画とオーケストレーション、最初の設計図は今でもClaudeやGPT-6に任せています。一方、時間がかかって繰り返しの多い作業はDeepSeekやGLMに回しました。Vonsは、この分業をさらにもう一段下へ降ろす実験です。大きなモデルが候補を絞り込み、そのうちどれを選ぶかは端末内の小さなモデルが決め、実際に実行するかどうかはホストが決めます。
ML Driftの発表をこの観点から読むと、Googleは同じ分業をハードウェア側で行っていることになります。シェーダーを書く作業はSKILL.mdを持つコーディングエージェントに任せ、端末GPUの断片化のように小さなチームだけでは抱えきれない層は共用エンジンで覆いました。モデルを小さく作ること自体は作り手の役割ですが、そのモデルを数十種類のGPUで動かす仕事まで一人で背負わなくてよい道が、もう一つできたわけです。
ただし、エンジンが開かれたからといって決定権まで開かれるわけではありません。102号のChromeの事例で見たように、モデルがどれだけ簡単に端末に載るかということと、そのモデルが何をしてよいかを誰が決めるかということは、別の問いです。Vonsが確信度を許可として使わず、実行をホストに残したのも、この二つ目の問いに対する設計です。
おわりに
ML Driftは機器ごとに異なるGPUの言語を一つに通訳するエンジンで、Googleはこれを TFLite 以降の基本経路に定めました。小さなモデルを作る側にとって、この発表は性能の数字よりも、端末GPUへの道筋が一本に整理されつつあるという知らせとして読めます。
💬 読者さんの仕事の中で、大きなモデルを呼び出さずに端末内の小さなモデルが判断してもよさそうな作業があるとしたら、何でしょうか？コメントで聞かせてください。
📨 オンデバイスAIやエージェント設計に悩んでいる同僚がいれば、ぜひこの記事を共有してください。
参考資料と関連リンク
主要出典
- Google AI Edge Team, “ML Drift: Next-Gen GPU AI/ML Inference at the Edge”, 2026. ··· 今回の記事の一次資料です。アーキテクチャ変更、製品別の成果数値、TFLite GPUデリゲートのサポート終了告知は、すべてここから出ています。
- Google AI Edge, “google-ai-edge/ml-drift”, GitHub. ··· UCL、テンソル仮想化、対応バックエンド構成をまとめた公式READMEです。
- Jiuqiang Tang 他、 “Scaling On-Device GPU Inference for Large Generative Models”, arXiv:2505.00232, 2025.5. ··· ML Driftの設計を初めて公開した論文です。「一桁倍」という主張の出典です。
- Paul Krill, “Google’s LiteRT adds advanced hardware acceleration”, InfoWorld, 2026.1.28. ··· LiteRTにML Driftが搭載された際に出た「TFLite比1.4倍」という数値の出典です。
Vons
- Kwangseob Ahn, “inlevel9-com/Vons”, GitHub. ··· 研究プレビューの範囲と限界、論文・技術レポートへのリンクがまとめられています。
- “@vons/decision-sdk README”, GitHub. ··· WASM・WebGPUの選択方式と、MCPサーバーがWebGPUをブロックしている理由が記されています。
併せて読みたい過去号
- 102号「Chromeの4GB AIモデルが露呈させたインストール同意の問題」 ··· 今回公開されたエンジンがChromeの中で動かす、まさにそのモデルの話です。
- 178号「Kimi K3 2.8兆パラメータ、オープンウェイトなのになぜ動かせないのか」 ··· サーバーラックが必要な巨大モデルと、端末側に降りてくる小型モデルが逆方向に進む計算を扱いました。
📝 用語解説
각주
-
デリゲート（delegate）: モデル実行中の一部の演算をGPUなどのアクセラレーターに引き渡し、代わりに計算させるTensorFlow Liteの接続部品です。 ↩
-
シェーダー（shader）: GPU上で実行される小さなプログラムです。元々はグラフィック画面を描くために使われていましたが、今ではAI演算をGPUにさせるためにも使われています。 ↩
-
テンソル（tensor）: AIモデルが扱う多次元の数値のまとまりです。写真1枚なら縦・横・色の3次元、複数枚をまとめると4次元になる、といった具合です。 ↩
-
プレフィル（prefill）とデコード（decode）: 言語モデルが質問全体を一度に読み込む段階がプレフィル、答えを1トークンずつつなげて生成していく段階がデコードです。 ↩
-
KVキャッシュ（KV cache）: 言語モデルが以前に読み込んだ内容を再計算しなくて済むよう、中間結果を保存しておくメモリ領域です。文脈が長いほど大きくなります。 ↩
-
MCP（Model Context Protocol）: AIエージェントが外部ツールやデータに接続する方式を標準化した規約です。VonsのMCPサーバーは、エージェントがVonsに判断を要求する窓口の役割を果たします。 ↩
あなたの視点が次の号をつくります
この号で最も共感した点、あるいは違う経験をした点はどこですか。