Towards Distributed Inference of LLMs on a P2P Network
本論文は、ローカルなラジックスツリーと非同期的なピアメタデータを活用することで、中央集権的な調整やKVキャッシュの転送を必要とすることなく、最長一致するプレフィックスを持つノードへリクエストをルーティングし、推論レイテンシを低減する、ピアツーピアLLMサービングのための分散型かつプレフィックスキャッシュを意識したルーティングスキームを提案する。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
あなたは、物語を書いたり、質問に答えたり、問題を解決したりする人々を助ける、膨大な知識のライブラリ（大規模言語モデル）を運営していると想像してください。誰かが質問をするたびに、ライブラリは回答を始める前に、そのリクエストの最初の部分について「考える」プロセスを経なければなりません。この「考える」フェーズは時間がかかり、多くのエネルギーを消費します。
しかし、多くの場合、多くの人々は全く同じ言葉で始まる質問を投げかけます（例：「猫についての物語をここに書きます...」や「この文章をフランス語に翻訳してください」など）。賢いライブラリであれば、それらの冒頭の言葉に対する「思考」が終わった後、その作業を一時的なノート（KVキャッシュと呼ばれます）に保存し、次の人のために再実行する必要がないようにします。これは**プレフィックス・キャッシング（Prefix Caching）**と呼ばれます。
問題点：「一つのライブラリ」によるボトルネック
従来のセットアップでは、多くの棚（ノード）を持つ一つの巨大な図書館の建物があるかもしれません。新しい人がやってくると、中央のマネージャーがその人をどの棚に送るかを決定します。
- 問題点： もしマネージャーが、ある人を棚Aに送ったとしても、その人の質問のための「思考」が棚Bに保存されていた場合、棚Aは最初からやり直しをしなければなりません。マネージャーは、ノートがどこにあるのかを確認するために、絶えずすべての棚をチェックしなければなりません。もしマネージャーが忙しくなったり、故障したりすると、ライブラリ全体が遅くなってしまいます。
- 代替案： 一部のライブラリでは、棚Bから棚Aへノートを瞬時にコピーしようとします。しかし、これらのノートは非常に巨大になることがあり（本棚全体を移動させるようなもの）、特に棚同士が離れている場合、移動させるための時間と帯域幅を大量に消費してしまいます。
解決策：ピア・ツー・ピアの「ゴシップ」ネットワーク
この論文は、このライブラリを動かすための新しい方法を提案しています：中央のマネージャーは存在しません。 代わりに、すべての棚（ノード）が自分自身の司書であり、彼らは互いに直接会話をします。
その仕組みを、簡単な比喩を使って説明します：
1. 「ラジックス木（Radix Tree）」（司書の心の地図）
すべての司書は、最近答えた質問と保存したノートのメンタルマップ（ラジックス木）を保持しています。
- 例： 司書のアリスは、「ケーキの焼き方」に関するノートを持っていることを知っています。司書のボブは、「自転車の修理方法」に関するノートを持っていることを知っています。
2. 「ゴシップ」（アンチ・エントロピー）
中央のボスがすべてに指示を出す代わりに、司書たちはゴシップ（噂話）をします。数秒ごとに、彼らは隣人に対して簡潔な要約をささやきます。「ねえ、さっき『製菓』に関するノートを保存したよ」
- 彼らは重いノート（実際のデータ）を送るのではなく、自分が扱ったトピックの小さなリストだけを送ります。
- これはバックグラウンドで行われるため、実際の作業を遅らせることはありません。
3. 意思決定（ルーティング）
新しい顧客が「チョコレートケーキの作り方」のようなリクエストを持ってやってきたとき、最初にその顧客を見た司書は、自分のメンタルマップを確認します。
- 彼らはこう尋問します：「他に『製菓』に関するノートを持っている人は誰か？」
- もし隣人から「ボブが『製菓』のノートを持っている」という話を聞けば、彼らは顧客をボブに送ります。ボブは「考える」部分をスキップして、すぐに答えに到達できます。
- もし彼らのマップが少し古かったり（情報の鮮度が落ちていたり）して、間違った人に送ってしまったとしても、それは致命的なことではありません。間違った人は、最初から「考える」作業を行うだけです。答えは常に正しくなりますが、単に少し時間がかかっただけです。正確さは失われません。速度だけが影響を受けます。
4. 混雑への対応（ホットスポット）
もしみんなが「製菓」について知りたがったらどうなるでしょうか？ ボブは「製菓のスペシャリスト」となり、過負荷になります。
- システムには安全弁があります。ボブが忙しくなりすぎると、彼は他の司書たちに「満杯です！」とささやきます。
- すると、他の司書たちはしばらくの間、製菓のリクエストをボブに送るのをやめ、最初から「考える」作業を行う他の誰かにリクエストを送るようにします。
実験の結果が示したこと
研究者たちは、一般的な知識のデータセット（MMLU）を使用して、4人の「司書」がいるコンピュータ・シミュレーションでこのアイデアをテストしました。
- 高速なネットワークの勝利： 司書たちが素早くゴシップできる場合（ネットワーク遅延が低い場合）、このシステムはルーティングを行わない場合よりもはるかに高速です。思考の作業を再利用することで、多くの時間を節策できます。
- 低速なネットワークの敗北： もしゴシップに時間がかかりすぎる場合（ネットワーク遅延が高い場合）、リクエストを適切な人物に送るためにかかる時間が、自分で作業を行う時間よりも長くなってしまいます。
- 専門化： システムは自然に「スペシャリスト」を生み出します。あるトピックが人気になると、一つのノードが最終的にそのトピックに関するすべてのノートを蓄積し、その特定のトピックにおいて超高速になります。しかし、ノートが大きくなりすぎると、システムはスペースを作るために古いノートを自動的に排除するため、スペシャリストは時間の経過とともに変化していきます。
結論
この論文は、分散型AIシステムにおいて、重い中央のボスや高価なデータ転送は必要ないことを示唆しています。代わりに、ノードが自分が何を知っているかという軽量なマップを共有する、分散型のゴシップベースのシステムを使用できます。
- メリット： レジリエンス（回復力）が高く（一つのノードが壊れても他のノードは動き続けられる）、拡張性に優れ、大量のデータ移動を回避できます。
- デメリット： ネットワークが高速であり、かつ質問に多くの重複がある場合（多くの人が似たようなことを聞いている場合）にのみ効果を発揮します。ネットワークが遅かったり、質問がすべてユニークなものである場合、システムはあまり恩恵を受けられません。
要するに、これはプレイリストを共有する友人たちのグループのようなものです。一人がリスト全体を管理するのではなく、全員がどんな曲を持っているかを教え合います。もしあなたが特定の曲を聴きたければ、その曲を持っている友人に頼みます。もし彼らが持っていなければ、自分で再生するだけです。少し乱雑かもしれませんが、みんなが同じヒット曲を聴いているときは、非常にうまく機能します。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。