AI News JAPAN

世界のAIニュースを最速で把握できるメディア

Advertisement

LLM推論コストを大幅削減するメモリ層「Galahad」、arXivに論文公開

公開:2026年10月3日, 最終更新:2026年10月3日

30秒サマリー

  • 実運用データの98.7%はモデルが既読のトークンであり、推論コストの大半が「再計算」に浪費されていることが判明
  • Galahadはテキストの注意計算状態(KVキャッシュ)を保存・再利用し、LLMの文書読み込みを一回限りのコストにする
  • 97,000トークンのコーパスでの実験で、正答率・速度・消費電力のいずれも大幅に改善された

何が起きたか

Sietse Schelpe氏は2026年9月30日、arXivにLLMサービングのステートレス問題を解決するメモリ層「Galahad」に関する論文を公開した。論文はまず、トランスフォーマーモデルがトークンごとに実行できる計算量に上限がある(Vishal Sikka氏の先行研究 arXiv:2507.07505 が指摘)という制約を前提とし、そのコスト上限の中でどれほどの計算が「既読テキストの再計算」に費やされているかを問題提起している。7つの実世界データセットを調査した結果、プロンプトトークンの98.7%がモデルにとって既読のテキストであったとされる。

GalahadはvLLM・SGLang等のLLM推論ランタイム向けメモリ層であり、「Taliesin」と「Blaise」という2コンポーネントで構成される。Taliesinはテキストブロックのキーバリュー(KV)状態を保存し、同一バイト列を含む次のリクエスト時にそれを再利用することで、再計算を回避する。Blaiseは文書自体を保持し、質問に関連するセクションのみをモデルに渡す仕組みだ。

97,000トークンのコーパスに100の事実を埋め込んだ想起テスト(Gemma 4 31B使用)では、Taliesin単体でコーパス全体への注意計算が可能になり、100問中98問に正解(1問あたり3.0秒・572ジュール)した。Galahad非使用時は最後の12,000トークンしか保持できず、100問中10問の正解にとどまり、9.3秒・2,754ジュールを要した。Blaiseを追加すると1問あたり約668トークンの読み込みで100問全問正解となり、処理時間0.59〜0.64秒・消費エネルギー200〜213ジュールを達成した。チューニング済みのRAGFlowパイプラインは同テストで77問正解だったと報告されている。コーパスの保存は一回限りのコスト(約100秒・28キロジュール)であり、13問以降で消費エネルギーが回収できるとしている。

再現性・信頼性の観点では、復元されたKV状態はビット単位で元の状態と一致し、262,144の出力ロジットがすべて一致したと報告されている。また、テストした30モデル全てでvLLMとの互換性が確認され、チェックを通過しないロードは再計算にフォールバックする「フェイルクローズ」設計を採用している。

原典ハイライト

論文の核心は「LLMサービングがステートレスであるために、同じテキストを何度も再計算している」という非効率の定量化と、それをKVキャッシュの永続化で解決するGalahadの実装・評価にある。実験ではGalahad(Taliesin+Blaise)が正答率・速度・エネルギー効率の全面でRAGFlowを上回った。

出典: arXiv cs.CL(論文)

So What?(なぜ重要か)

編集部の見立てでは、この研究が示す意義は二点ある。第一に、LLM推論コストの大半が「既読テキストの再計算」という構造的な無駄から生じているという定量的な根拠が示された点。第二に、KV状態の永続化というアプローチが、精度・速度・省エネルギーを同時に改善できることを実験で示した点だ。ただし本論文はarXivプレプリントであり、査読を経ていない点には留意が必要。

日本企業への示唆

社内文書検索・カスタマーサポート・法務レビューなど、同一の大規模文書コーパスに繰り返しクエリを発行するユースケースを持つ日本企業にとって、このアーキテクチャは推論コストとレイテンシを抑制する有力な候補となり得る。vLLM等のオープンソースランタイムを自社で運用しているチームは、Galahadの実装動向を継続的に追うことが望ましい。また、RAGの精度・コスト両面での限界を感じている組織は、KVキャッシュ永続化という代替アプローチの検討材料として本研究を参照できる。ただし査読前論文であり、本番導入前には独自検証が不可欠。

背景・経緯

LLMのトランスフォーマーアーキテクチャは本質的にステートレスであり、リクエストをまたいで計算状態を保持しない。そのため、同一文書に対する2回目以降の問い合わせでも、冒頭から全トークンを再計算する。論文はVishal Sikka氏(元Infosys CEO)による先行研究(arXiv:2507.07505)が指摘する「トークン当たりの計算量の上限」という制約を出発点に、その限られた計算バジェットを再計算で消費することの非効率を問題として設定している。