この投稿では Stefanos Laskaridis, Kleomenis Katevas, Lorenzo Minto そして Hamed Haddadiによる対応を紹介します。Machine Learning Researcherである Stefanos Laskaridis による文章の日本語訳です。

TL;DR（要約）: ハイパースケールモデルの新時代を迎えつつある現在、プライバシーと持続可能性を維持するために、AIをローカルでホストする能力を備えることは不可欠となります。本研究は、コンシューマーエッジにおける大規模言語モデル（LLM）の展開可能性を測定する初めての研究であり、クラウドではなくスマートフォンやエッジデバイス¹で異なるサイズのモデルを実行する可能性を探求します。

はじめに

Llama-3、Mixtral、ChatGPTのような大規模な言語モデルは、機械学習のあり方に革命をもたらし、（Brave Leoを含む）インテリジェント・アシスタント、クリエイティブライティング、エージェントベース・オートメーション（例：LeoのBrave Searchの統合）など、以前は考えられなかったユースケースを可能にしました。同時に、私たちのポケットの中のデバイスは、ますます高性能になり ²、これまで以上に強力なシステムオンチップ（SoC）を統合しています。このトレンドに基づき、ユーザーのプライバシーを守るという我々の真のコミットメントを維持しながら、私たちはLLMのデバイス上での展開について、実現に向けた研究を続けます。

このために、Braveリサーチチームは、オンデバイスでLLMを実行した場合のレイテンシー、精度、メモリ、エネルギーへの影響を測定するために、BLaDEと名付けた独自のLLMベンチマークインフラを構築しました。同時に、これらのモデルは往々にして大きすぎることを認識しており、私たちはエッジデバイスを活用してローカル実行を増強することで、コンシューマーのスマートデバイス上での実行を強化させます ³。これは、最新のBYOM（Bring Your Own Model）セルフホスティング・オプションによって導入可能です。

私たちの経験ではGenAIのエコシステムはますます大きくなるなか、デバイス上でのローカル展開はまだ初期段階にあり、デバイス間で非常に不均一なままです。LLMをデバイス上に展開することは可能ですが、特に中位層のデバイスでは、レイテンシー、快適性、精度に目立った影響が生じます。しかし、ハードウェアやアルゴリズムのブレークスルーにより、実行コストやユーザーの体感品質（QoE）が大きく変わる可能性があります。同時に、SLM（スモール・ランゲージ・モデル）⁴が徐々に登場し、特定のダウンストリーム・タスク向けに調整されつつあります。

Braveリサーチ・端末調査

BLaDE（BatteryLab Device Evaluation）は、パフォーマンスとエネルギー測定のためにモバイル機器とのインタラクションを自動化できる最先端のベンチマーク基盤です。ニューラル・タスクにも、より一般的なブラウザ・タスクにも使用することができます。MELTは、様々なデバイス上のニューラル・ワークロードのベンチマークを担当するコンポーネントです。

MELTはサーバー・クライアント・アーキテクチャーをベースとし、中央の調整プロセスが以下のような責務を担います。

• ベンチマーク・スイートの実行を管理する;

• 接続されたデバイスへのジョブのスケジューリングとディスパッチ;

• アプリケーションと下流のインタラクションを制御する;

• 稼働時間、温度、エネルギー消費量の監視;

• ダウンストリームタスクで関心のあるイベントをトレースし、関連するデバイスの動作をキャプチャする.

この目的のために、以下のコンポーネントが統合されています。

• コーディネーターの役割を担う Raspberry Pi 4 8GB;

• パッケージ構築用の Mac Mini;

• Monsoon パワーモニター をRaspberry Pi GPIOアドレサブルリレーに接続し、各モバイルデバイスの電源を制御;

• USB 電源をデバイスと通信し、選択的に無効にするプログラマブルな YKUSH USB スイッチャブル・ハブ;

• Flir Oneエッジワイヤレスカメラ と、デバイスの温度を監視するための特注の赤外線温度計（MLX90614ベース）;そして最後に

• Table 1に示されている、バッテリー・バイパスの手順を経た一連の モバイル・デバイス.

並列して、コーディネータはEthernetで Nvidia Jetsonボード と同じネットワークに接続され、SSHでアクセスできます。Jetsonは、SysFSプローブを通じて電力と温度のメトリクスを提供することができます。

MELT ワークフロー

Figure 1bは、MELTの測定ワークフローを示しています。MELTのインフラストラクチャーは以下のコンポーネントで構成されています。

1. Model Zoo, ダウンロードと編纂／量子化を担います。Table 2のモデルを使用しました。

2. Evaluator, 変換/量子化によるモデルの精度劣化を評価する役割を担います。Table 4のデータセットを使用しました。

3. Builder, 各ベンチマークスイートのバックエンドのコンパイルを担当します。Table 3でllama.cpp, MLC-LLMという名前で表示されています。

4. Runner, 各デバイス上でのLLMのデプロイメント、自動化、ランタイムを担います。統合されたデバイスはTable 1に表示されています。

5. Monitor, 実行時のリソースとエネルギー消費をきめ細かく監視します。

結果のハイライト

以下に、我々の分析結果の中で最も興味深いものと、それを踏まえたデバイス上でのデプロイや、今後の製品研究の方向性をお伝えします。

デバイスあたりのスループットとエネルギー

Figure 3は、会話設定で使用された場合の、さまざまなデバイス上のさまざまなモデルのプレフィルと生成のスループットを示しています。プリフィルとは、実際の生成を開始する前の入力トークンの準備と処理（トークン化、埋め込み、KV キャッシュの生成など）を意味し、生成とは、出力トークンの自己回帰的な生成（つまりデコード）を意味します。スループットはトークンの取り込み/生成の速度を表し、単位はトークン/秒です。

Figure 4は、さまざまなモデル、デバイス、フレームワークの組み合わせについて、生成されたトークンあたりの放電レートを示しています。これはmAh/トークンで表されます。

考察： 私たちは、モデルによってデバイス性能の面でかなり異質な状況が生じることを目撃しました。典型的なコンピュート・バウンドであるプリフィル演算は、典型的なメモリー・バウンドであるジェネレーション・レートよりもはるかに高い値となりました。MLC-LLMは一般的にllama.cppと比較して高い性能を提供しますが、モデルの移植性を犠牲にします。意外なことに、4ビット・モデルは3ビット・モデルよりも高速に動作しましたが、その代償としてメモリ消費量が増加し、一部のモデルでは実行中にメモリ不足に陥りました。最後に、MetalでアクセラレーションしたiPhoneは、OpenCLでアクセラレーションしたAndroid携帯よりも高いスループット・レートを示しました。

オンチップメモリとオフチップメモリ間のトラフィックは大量のエネルギーを消費するため、エネルギー的には、より大きなネットワークはより大きな放電レートを提供します。例えば、Zephyr-3B（4ビット量子化）をMLC-LLM上のS23に、iPhone ProをMLC-LLM上に、iPhone 14 Proをllama.cpp上に配置した場合、バッテリーがなくなるまで平均542.78回、490.05回、590.93回のプロンプトが表示されます。最後に、CPU実行ではエネルギー効率が低かったのですが、これは推論実行の待ち時間がアクセラレーション実行に比べて長かったためと考えられます。 

経験の質

実際の環境では、デバイス上で大きなモデルを実行すると、ユーザーエクスペリエンスに悪影響を及ぼし、デバイスが不安定になったり、使用できなくなったりする可能性があります。考慮すべき点は大きく分けて以下の3点です。

1. デバイスの応答性 は、LLM推論の実行時におけるデバイスの一般的な安定性と信頼性を指します。デバイスの応答性に影響を与える要因としては、長いモデルのロード時間、アプリケーションを停止させるメモリ不足のエラー、デバイスの再起動が挙げられ、デバイスを再起動することで事実上DoSを引き起こしました。

2. 持続性能 とは、複数の推論リクエストの実行時間を通して同じ性能を提供するデバイスの能力を指します。我々の実験では、持続的な負荷の下での性能は安定しておらず、変動していることに気づきました。このような動作の理由には、DVFS、サーマルスロットリング、異なる電力プロファイル、および潜在的な同時作業負荷が考えられます。

3. デバイスの温度 は、デバイスの性能だけでなく、ユーザーの快適性にも影響されます。最近のデバイスは様々な形状がありますが、多くの場合受動的に冷却されています。そのため、放熱は主に特定の素材の使用によって促進され、熱管理はOSによって管理されます。iPhone 14 ProのZephyr-3B（4ビット）モデルで1回フルに会話した後、消費電力によって温度は不快なレベルまで上昇し、47.9℃に達しました。

考察： LLM推論作業負荷の実行可能性は、展開可能性を示唆するものではないと考えられます。

量子化の精度への影響

今日のLLMのサイズはとても大きいです。同時に、ほとんどのデバイスに搭載されているメモリは6～12GB程度です。つまり、このようなモデルをデバイス上に展開することは、通常、圧縮によってのみ可能なのです。量子化は、重みと活性度を表現する精度を下げる圧縮技術です。しかし、これは精度を犠牲にします。我々は、4つの自然言語タスク（HellaSwag、Winogrande、TruthfulQA、ARC-{E,C}）の精度に対する、異なるモデルアーキテクチャとサイズ、量子化スキーム、精度の影響を測定しました。

考察： 最も明らかな性能差は、モデル・アーキテクチャとパラメータ・サイズに由来し、この性能差はデータセット間で持続します。量子化スキームに関しては、ビット幅がモデルサイズだけでなく精度にも相関していることは明らかです。より大きなモデル（≥7Bのパラメータ）では、AWQ ⁵とGPTQ ⁶が、モデルサイズが大きくなることを犠牲にして、わずかに良いパフォーマンスを示しました。

エッジデバイスへのオフロード

LLMのQoEと精度はデバイス上で実行されることによって影響を受けることが先に証明されたため、我々はコンシューマーエッジで近くのデバイスに計算をオフロードする代替モデルを検討します。例えば、専用のアクセラレーター（例えば、エッジAIハブ）または別のエッジデバイス（例えば、スマートテレビやハイエンドルーター）です。このため、このパラダイムの実行可能性を確認するために、Nano（中位層）とAGX（上位層）という2つのJetsonデバイスを採用しました。

考察： 全体として、生成スループットは同等のモバイル・ランタイムを大幅に上回り、このランタイムはより長時間持続することも可能であると考えられます。Zephyr-7B（4ビット）の場合、平均スループットはプリフィルで3.3倍、世代で1.78倍高く、同時に、エネルギー効率はデバイスのTDPと同じ方向に動いていることがわかります。

重要なポイント

この研究は、iOSとAndroidの両方のエコシステムにおいて、大規模言語モデルを消費者向けモバイルデバイスに展開することの可能性と課題を明らかにするものです。ハードウェアの進歩や量子化などのアルゴリズムのブレークスルーが期待される一方で、現在のところデバイスへの実装はレイテンシ、デバイスの安定性、エネルギー消費に影響を与えます。ローカル・エッジ・デバイスに計算を委ねることで、パフォーマンスとエネルギー効率を向上させることができます。ローカルAIを実用化し、ユーザーのプライバシーを保護し、持続可能性を高めるためには、ハードウェアとソフトウェアの両方における継続的な技術革新が不可欠です。

詳細について

この関連論文は、30th Annual International Conference on Mobile Computing and Networking (ACM MobiCom'24)に採用されました。

こちらで詳細をご覧いただけます: https://arxiv.org/abs/2403.12844 

MELTのコードベースはこちらでご覧いただけます。 https://github.com/brave-experiments/MELT-public.

参照