🤖 AI

Transferable Latency Prediction for Fast LLM Screening on Heterogeneous Edge Devices

本論文は、最小限のキャリブレーションで、ヘテロジニアスなエッジデバイス間における正確かつ転移可能なLLMデプロイメント・スクリーニングを可能にするため、静的なモデル記述子と動的なハードウェア・テレメトリを適応的に融合する、ランタイム認識型のレイテンシ予測フレームワークを提案する。

原著者： Xiaolong Tu, Vinod K. Mishra, Venkat R. Dasari, Anu G. Bourgeois, Haoxin Wang

公開日 2026-07-27

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Xiaolong Tu, Vinod K. Mishra, Venkat R. Dasari, Anu G. Bourgeois, Haoxin Wang

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

携帯型ゲーム機で遊ぶのに最適なビデオゲームを選ぼうとしている場面を想像してみてください。あなたは、小さなパズルアドベンチャーから、広大で壮大なロールプレイング・エピックまで、膨大なゲームライブラリを持っています。しかし、ここには落とし穴があります。あなたのコンソールは少し気難しいのです。長時間プレイすると熱くなりますし、バッテリーの消耗も激しく、さらに、持ち方や時刻によってゲームの動作が変に変わってしまうことがあります。どのゲームがスムーズに動くかを確認するために、すべてのゲームをダウンロードしてテストしようとすれば、ダウンロードを待つだけで一日が終わってしまい、しかもその半分はクラッシュしたりラグが発生したりすることに気づくだけでしょう。あなたは、ゲームの説明文とコンソールの現在の「機嫌」を見るだけで、どれが実際に動作するかを推測する方法を必要としています。これは、まさにスマートフォンの世界における人工知能（AI）が直面している問題です。

科学者たちは、巨大なクラウドサーバーにデータを送る代わりに、デバイス上で直接動作する「大規模言語モデル（LLM）」――物語を書いたり、質問に答えたり、問題を解決したりできる超スマートなAIの脳――を実行しようとしています。これはプライバシーや速度の面では素晴らしいことですが、予測に関しては悪夢です。あるAIモデルは一つのスマートフォンでは完璧に動作しても、見た目が似ている別のスマートフォンではフリーズしてしまうことがあります。なぜでしょうか？それは、AIの速度が、質問の長さ、スマートフォンの温度、残りのバッテリー量、さらにはAIを実行するための特定のソフトウェアといった、混沌とした要素の混合によって決まるからです。もし、実際に試す前にAIがどれくらいの速さで動くかを予測できなければ、動かない可能性のあるモデルのテストに、膨大な時間とエネルギーを浪費することになります。ここで、「未来を予測する」という物語が登場します。

AIの速度を見通す水晶玉

この論文では、ジョージア州立大学と陸軍研究ラボのチームが、AIの速度のための「水晶玉」を構築しました。彼らはこれをランタイム・アウェア（実行時認識型）レイテンシ予測フレームワークと呼んでいます。これを分解してみましょう。「レイテンシ」とは、何かが起こるまでにかかる時間のことを指す、単なる専門用語です。「ランタイム・アウェア」とは、システムが単にAIのスペック（紙の上での性能）を見るだけでなく、AIが動作している最中に起きていることに注目することを意味します。そして「転移可能（トランスファラブル）」とは、この水晶玉が一種のデバイスから別の種類のデバイスへと移動しても機能することを意味します。

研究者たちは、自分のお気に入りの味を見つけるために、世界中のあらゆるアイスクリームの味を試そうとするのは、あまりにも非効率的だと気づきました。代わりに、新しいデバイスと新しいAIモデルを見たときに、「おい、この組み合わせなら、おそらく10秒ほどで回答が出るはずだ」と言えるようなシステムを目指したのです。

水晶玉の仕組み

彼らのシステムの秘訣は、単に静的な事実を見るだけではないという点にあります。車の走行速度を予想しようとしている場面を想像してください。「静的」な予想であれば、車のエンジンのサイズや重量だけを見ます。しかし、「ランタイム・アウェア」な予想であれば、天気や交通状況、さらにはドライバーが眠くなっていないかまでをもチェックします。

研究者のシステムは、同時に2つのことを行います：

静的パス（Static Path）: セットアップの「身分証明書」を見ます。これには、モデルのサイズ、スマートフォンやガジェットの種類、設定などが含まれます。
動的パス（Dynamic Path）: デバイスが動作している間の「鼓動」を監視します。チップがどれくらい熱くなっているか、プロセッサがどれくらいの速さで回転しているか、メモリがどれくらい使用されているかなどを追跡します。

システムはAIの作業を、二部構成のレースのように2つのフェーズに分けます：

プリフィル・フェーズ（Prefill Phase）: これはAIがあなたの質問を読み取り、思考をまとめる段階です。通常、これは短時間で爆発的な動きを見せるスプリント（短距離走）のようなものです。
デコード・フェーズ（Decode Phase）: これはAIが答えを、一語一語書き出していく段階です。これは、より長く、一定のペースで行われるジョギングのようなものです。

これら2つのフェーズを別々に扱い、「身分証明書」の情報と「鼓動」のデータを組み合わせることで、システムはよりスマートな予測を構築します。彼らは「ゲート・フュージョン（門による融合）」メカニズムを使用しました。これは、状況に応じて、静的な事実に耳を傾けるべきか、あるいはライブの交通状況に耳を傾けるべきかを判断する、賢い交通信号のようなものです。

キャリブレーションの魔法

ここで最も重要なトリックがあります。システムは、最初から完璧というわけではありません。もしPixel 8で学習させたシステムをPixel 8 Proで使おうとした場合、2つのスマートフォンはわずかに異なるため、数値が狂ってしまう可能性があります。

これを修正するために、研究者たちは**キャリブレーション・セット（校正セット）*を使用します。これは、いわば「試乗」のようなものです。新しいデバイス上でAIを数回（おそらく6回から20回程度）実際に走らせ、それが実際に*どのように振る舞うかを確認します。システムは、これらの少数の実測結果を用いて、水晶玉を微調整し、予測を新しいデバイスの現実へと適合させるのです。

このキャリブレーションの効果は劇的です。キャリブレーションなしでは、Pixel 8 Pro上でAIが「デコード（回答の書き出し）」にかかる時間を予測した場合、そのスコア（ $R^2$ と呼ばれるもの）は -1.085 となり、予測はデタラメでした。これは、ランダムに推測するよりも悪い結果であることを意味します。しかし、ほんの少しのキャリブレーションを行っただけで、そのスコアは 0.927 まで跳ね上がり、ほぼ完璧になりました。それは、ぼやけた写真を、わずかな調整だけでクリスタルクリアな鮮明な写真へと変えるようなものです。

システムのテスト

チームは、このアイデアが特定のスマートフォンだけの偶然の産物ではないことを証明するために、さまざまなガジェットでテストを行いました。使用されたのは以下の通りです：

Pixel 8 および Pixel 8 Pro: モダンなスマートフォンを代表する、今回の主役です。
Jetson Nano: ロボットやドローンによく使われる、非常に小さなコンピュータです。
Orange Pi 5 Pro: シングルボードコンピュータの一種です。
RTX 3090: ハイエンドのゲーミングPCによく搭載されている強力なグラフィックスカードです。

彼らは、同じAIモデルであっても、巨大なグラフィックスカード上では非常に高速（毎秒64.38トークン）に動作する一方で、小さなOrange Pi上では極めて低速（毎秒8.42トークン）になることを発見しました。これは、モデルの性能だけで速度を推測することはできず、デバイスを知る必要があることを証明しています。

なぜこれが重要なのか：スクリーニング・プロセス

究極の目標は、単に速度を予測することではなく、時間を節約することです。例えば、100種類の異なるAIモデルがあり、自分のスマートフォンに最適なものを選びたいとします。このシステムがなければ、100個すべてをダウンロードしてテストしなければなりません。しかし、このシステムがあれば、100個すべての速度を瞬時に予測できます。

研究者たちは、**パレート最適化（Pareto optimization）**と呼ばれる戦略を使用しています。これは、簡単に言えば「スイートスポット（最適解）」を探す方法です。彼らは、高速であり、かつスマートなモデルを求めています。もしモデルAがモデルBよりも遅いのに、それほど賢くないのであれば、モデルAは役に立ちません。システムは悪い選択肢を排除し、実際にテストすべき最高の候補の短いリストを残してくれます。

テストにおいて、このスクリーニング・プロセスは、最高のモデルを候補に残すことに成功しました。例えば、Pixel 8 ProからPixel 8へ移行する場合、システムは候補の半分をフィルタリングしましたが、絶対的なベストモデルは依然としてリストに残っていました。

分かったこと（と分からなかったこと）

この論文は、この手法がAIの導入をより速く、より安価にするための強力なツールであることを示唆しています。彼らが得た結論は以下の通りです：

静的な推測だけでは不十分である: モデルのサイズを知るだけでは、特定のスマートフォン上でどれくらいの速さで動作するかを伝えることはできません。
キャリブレーションが鍵である: 予測を別のデバイスにコピー＆ペーストすることはできません。予測を修正するために、わずかな実データが必要です。
フェーズ（段階）が重要である: AIの「読み取り」部分と「書き出し」部分を別々に扱うことで、予測の精度は大幅に向上します。

しかし、著者たちは、これはあくまで出発点であると注意深く述べています。彼らの最高の結果はPixelスマートフォンで得られたものであり、JetsonやOrange Piなどの他のデバイスでも動作することを示しましたが、これらに対して完全で深いトレーニングをまだ行っていないことも認めています。また、強力なコンピュータ上では、小さなモデルが必ずしも大きなモデルより速く動くとは限らないという奇妙な現象もあり、彼らのシステムはその現象を説明するのに役立つことも指摘しています。

要するに、この論文は、時間を浪費したりバッテリーを消耗したりすることなく、自分のガジェットでAIがいかに速く動作するかを推測するための、巧妙で柔軟な方法を提示しています。それは、混沌とした推測ゲームを、計算に基づいたデータ駆動型の意思決定へと変え、私たちが最高のAI体験を得られるよう支援するものです。

技術要約：ヘテロジニアスなエッジデバイスにおける高速LLMスクリーニングのための転移可能なレイテンシ予測

問題提起

大規模言語モデル（LLM）を、ヘテロジニアスなエッジデバイス（例：スマートフォン、シングルボードコンピュータ、組み込みGPU）にデプロイすることは、低レイテンシ、プライバシー保護、および接続制約のあるアプリケーションにおいてますます重要になっています。しかし、特定のデバイスに対して、特定のデプロイ要件の下でどのモデルが適しているかを判断することは、依然として重大なシステム上のボトルネックとなっています。

LLMの推論レイテンシは、単なる静的なモデルアーキテクチャやハードウェア性能のみによって決定されるわけではないという点が、核心的な課題です。それは以下の要素の複雑な関数となります：

静的要因： モデルアーキテクチャ、パラメータ規模、量子化フォーマット、およびハードウェア仕様。
動的要因： プロンプト長、生成トークンの振る舞い、動的電圧・周波数スケーリング（DVFS）、ハードウェア利用率、メモリプレッシャー、およびサーマルスロットリング。
実行フェーズ： LLM推論は、プリフィル（prefill）（プロンプトの処理とKVキャッシュの構築）と、デコード（decode）（自己回帰的なトークン生成）という、異なるレイテンシ特性とハードウェア挙動を示す明確なフェーズで構成されます。

単純な解決策、すなわちすべての候補モデルをすべてのターゲットデバイス上で網羅的にベンチマークすることは、ランタイムのセットアップ、モデル変換、実行、およびテレメトリ収集のコスト due to に、極めて困難です。既存のレイテンシ予測器は、多くの場合静的な特徴量のみに依存しており、プラットフォーム固有のランタイム挙動、スケジューリング効果、およびバックエンド依存の実行の違いを捉えることができません。その結果、高価なターゲットデバイスでの実行を行う前に、候補モデルをスクリーニングできる、**ランタイムを考慮した（runtime-aware）かつ転移可能（transferable）**な予測フレームワークが必要とされています。

手法

本論文では、デプロイ指向のLLM選択のために設計された、ランタイムを考慮したレイテンシ予測フレームワークを提案しています。このシステムは、以下の4つのステージを通じて動作します。

1. 設定表現

各推論リクエストは、構成タプル $c = (m, d, r, p)$ としてモデル化されます。

$m$ : 学習済みモデル（ファミリー、サイズ、量子化）。
$d$ : デバイス（ハードウェアプロファイル、テレメトリ機能）。
$r$ : ランタイムバックエンドおよびプラットフォーム設定（例：MLC-LLM、PyTorch、CPU/GPU/NPU）。
$p$ : プロンプト/タスク構成（入力長、最大生成長）。

2. デュアルパス予測器アーキテクチャ

本フレームワークは、ゲート機構を介して融合される2つの補完的なブランチを持つ、転移可能な予測器を採用しています。

静的パス（Static Path）： デバイスプロファイル、モデル記述子、デプロイ設定などの安定した記述子を、静的埋め込み（ $S$ ）へとエンコードします。これは、実行前の期待される互換性を捉えます。
動的パス（Dynamic Path）： プロファイリング中に収集されたランタイムテレメトリトレースを処理します。決定的なのは、**フェーズを意識したモデリング（phase-aware modeling）**を適用している点です。
- プリフィル・トレースは、正規化されたフェーズ時間の下で整列され、疎でバースト的なハードウェア状態を再構成します。
- デコード・トレースは、自己回帰的な振る舞いを捉えるために、時間的順序を保持します。
- テンポラルエンコーダは、これらを動的埋め込み（ $D$ ）へと集約します。
ゲート融合（Gated Fusion）： 軽量なゲーティングネットワークが適応的な重み（ $w_s, w_d$ ）を計算し、 $S$ と $D$ を融合します。これにより、構成が安定しているときは静的情報に、ランタイムの変動が支配的なときは動的データにより依存するようにモデルを調整できます。
回帰ヘッド（Regression Head）： 予測されるプリフィルレイテンシ、デコードレイテンシ、および総レイテンシを出力します。

3. 転移とキャリブレーション

クロスデバイスのデプロイを扱うため、システムはキャリブレーションセットを使用します。少数のターゲットデバイスでの実行を測定することで、デバイス固有のバイアスを補正します。これにより、ソースで学習された予測器を、ターゲットデバイスのレイテンシスケールおよびランタイムレジームに適合させます。これには、網羅的なプロファイリングを必要としません。

4. パレートベースのスクリーニング

予測されたレイテンシは、モデルの精度（またはタスク品質）と組み合わされ、パレート最適化を実行するために使用されます。システムは、劣った候補（レイテンシが悪く、品質も低いもの）をフィルタリングし、応答性と出力品質のバランスをとった、コンパクトなパレート最適モデルの集合を特定します。

主な貢献

定式化： LLMのレイテンシ予測を、ハードウェア・ランタイム・モデル・プロンプトの構成問題として定義し、多様なデバイス、モデル、プロンプト、およびバックエンドにわたる予測を可能にしました。
アーキテクチャ： 静的な記述子と動的なテレメトリを統合し、フェーズを意識したモデリングによってプリフィル/デコードの振る舞いを分離し、適応的な埋め込み結合のためにゲート融合を使用する、ランタイムを考慮した転移可能な予測器を提案しました。
ワークフロー： キャリブレーションされた予測を使用して、ターゲットデバイスでの実行前に候補をフィルタリングする、デプロイ指向のスクリーニングワークフローを設計し、レイテンシと品質のトレードオフ分析をサポートします。
検証： Pixel モバイルデバイス、Jetson Nano、Orange Pi 5 Pro、および RTX 3090クラスの GPUにわたるマルチプラットフォーム・プロファイリング・パイプラインを構築し、モバイル予測の精度とヘテロジニアスなプロファイリングの網羅性を検証しました。

実験結果

本フレームワークは、Pixel 8 および Pixel 8 Pro デバイスで評価され、Jetson Nano、Orange Pi 5 Pro、および RTX 3090クラスのハードウェアを用いたプロファイリング検証が行われました。

デバイス内予測： Pixel 8 において、フル予測器は、静的のみのベースラインと比較して、総レイテンシの $R^2$ を 0.953 から 0.960 へ、デコードレイテンシの $R^2$ を 0.957 から 0.973 へ向上させました。Pixel 8 Pro では、プリフィルレイテンシの $R^2$ を -1.383 から 0.966 へ大幅に改善しました。
クロスデバイス転移： キャリブレーションが不可欠であることが証明されました。キャリブレーションがない場合、転移後の $R^2$ 値はしばしば負の値となりました（例：Pixel 8 Pro $\to$ Pixel 8 の総レイテンシにおいて -0.974）。キャリブレーションを用いることで、 $R^2$ は 0.940 まで改善しました。
ヘテロジニアス・プロファイリング： レイテンシがデバイスおよびランタイムに強く依存することを結果は裏付けています。例えば、SmolLM2-1.7B モデルは、RTX 3090クラスの GPU では 64.38 tokens/s を達成しましたが、Orange Pi 5 Pro ではわずか 8.42 tokens/s でした。さらに、RTX 3090 においては、小さなモデルが必ずしも高速であるとは限らず、これはカーネルオーバーヘッドやメモリ挙動がパラメータ数によるスケーリングを支配する場合があることを示しています。
アブレーション研究： 静的な記述子だけではクロスデバイスの転移には不十分であること、およびキャリブレーションが予測を安定させるための最も重要な要因であることを確認しました。また、フェーズを意識したモデリングは、プリフィルレイテンシの予測において明確な利益を提供しました。
スクリーニング効率： 予測器は、最良の実行可能なモデルを保持しながら、候補モデルの集合を効果的に削減すること（テストされたシナリオにおけるフィルタリング比率は 0.333 および 0.500）に成功しました。

重要性と主張

本論文は、軽量なキャリブレーションを伴うランタイムを考慮した予測が、プロファイリングのコストを大幅に削減し、ヘテロジニアスなエッジプラットフォームにおけるレイテンシを考慮したLLMデプロイをサポートできると主張しています。

実用的な影響： 本フレームワークは、網羅的なベンチマークを予測的なスクリーニングプロセスに置き換えることで、モデル選択における「システムのボトルネック」に対処します。
ダイナミクスの必要性： 結果は、エッジデバイスのパフォーマンスを決定づける DVFS、サーマルスロットリング、およびランタイムスケジューリングの複雑な相互作用を捉えるには、静的なモデルだけでは不十分であることを示しています。
転移可能性： システムは、ソースデバイスで学習された予測器が、小さなキャリブレーションセットを使用することで、ターゲットデバイスに効果的に汎化できることを示しています。
デプロイ・ループ： 本研究は、レイテンシ予測を孤立した回帰タスクとしてではなく、限定的な測定を用いて意思決定を反復的に改善する、クローズドループ・デプロイメント・システムの構成要素として位置づけています。

著者らは、最も完全な予測結果は Pixel モバイルデータセットに基づいていること、その他のプラットフォームは主にプロファイリング検証のために使用されていることなど、限界についても述べています。今後の課題として、スループット、メモリ、およびエネルギーをレイテンシと共に共同で考慮するフレームワークへの拡張が挙げられています。