エッジエージェントとクラウドの協調：実行全体を制御する新しい設計

導入

エッジとクラウドの使い分けは、これまで「一つの問い合わせを端末で処理するか、クラウドへ送るか」というルーティング問題として語られることが多かった。しかし、複数段階の計画、ツール操作、観測結果に応じた修正を行う LLM エージェントでは、クラウドの関与は一度きりではない。実行の途中で何度も呼び出される可能性があり、そのたびにコスト、処理の流れ、外部へ出る情報の範囲が変化する。

研究の枠組み

この問題を調べるため、研究チームは EC2-Bench を提案した。ベンチマークには、デジタルワークスペース上で実際に実行できる 128 件の長期タスクが含まれる。評価軸は次の三つである。

• タスク性能：エージェントが目的を達成できるか
• 資源利用：エッジ推論やクラウド API 呼び出しに必要なコスト
• プライバシー露出：実行中にどの程度の情報がクラウドへ送られるか

エッジのみ、クラウドのみの構成に加え、外部ルーターがクラウド呼び出しを決める方式、エッジモデルが自ら助けを求める方式、クラウドが実行者ではなく助言者になる方式などを比較した。

主な発見

第一に、協調実行は性能、コスト、プライバシーの間で現実的な妥協点になり得る。クラウド専用構成は高い能力を利用できる一方、API コストと情報転送が増える。エッジ専用構成はデータ局所性に優れるが、モデル能力の制約を受ける。素材によれば、9B のエッジモデルを協調方式で利用した場合、フルクラウド実行の約 73% の性能を、クラウド API コスト約 15% で達成したという。

第二に、エッジモデルが強くなると、協調実行の性能はクラウド専用構成に近づき、方式間の差も小さくなる。ただし、プライバシー露出は自動的に減るわけではない。どの情報を、どのタイミングで、どの役割のクラウドモデルへ送るかという方針に強く依存するからだ。

第三に、望ましい協調方法そのものが変化する。弱いエッジモデルでは、外部のルーターによるクラウド制御や、クラウドへの直接実行依存が大きくなる。エッジモデルの能力が高まると、エッジ側が実行軌跡を管理し、クラウドには必要な場面で助言を求める構成が有利になる。

意義

この研究は、エッジ・クラウド協調を単純なモデル選択ではなく、実行軌跡全体を設計する問題として捉え直している。個人端末や企業の作業環境で重要なのは、ローカルモデルの規模だけではない。エージェントが「いつ助けを求めるか」「どの情報を最小限共有するか」「助言を受けた後に処理をローカルへ戻せるか」を判断できることも重要になる。

EC2-Bench の意義は、性能だけでなく、資源利用とプライバシーを同じ枠組みで測れる点にある。成功率が高くても、頻繁な API 呼び出しや過剰なコンテキスト送信を必要とする方式は、実運用に適さない可能性がある。今後は、エッジが状態と主導権を保持し、クラウドを限定的な助言者として使う設計を、より多様なタスクや端末条件で検証する必要がある。

出典：Hugging Face Daily Papers