大規模言語モデルに200,000トークンを処理させるのは高コストで遅くなりがちです。コンテキストが長くなるほど、コストは急速に膨らんでいきます。清華大学とZ.aiの研究者らは、IndexCache と呼ばれる技術を開発し、スパース注意（sparse attention）モデルにおける冗長な計算を最大75%削減しました。その結果、当該コンテキスト長において、最初のトークンまでの時間（time-to-first-token）が最大1.82倍高速化され、生成スループットが1.48倍高速化されました。
この技術は、DeepSeek Sparse Attention アーキテクチャを用いるモデルに適用できます。最新の DeepSeek 系および GLM 系のファミリが含まれます。これにより、企業は、本番規模で長いコンテキストを扱うモデルに対して、より高速なユーザー体験を提供できる可能性があります。この能力は、7440億（7,44B）パラメータの GLM-5 モデルでの予備テストにより、すでに実証されています。
DSAのボトルネック
大規模言語モデルは自己注意（self-attention）メカニズムに依存しています。これは、文脈内のすべてのトークンと、それ以前のすべてのトークンとの関係をモデルが計算し、次のトークンを予測するプロセスです。
しかし自己注意には深刻な制約があります。計算量は系列長に対して二次的に増大します。拡張されたコンテキストウィンドウを必要とするアプリケーション（例：大規模文書の処理、複数ステップのエージェント的ワークフロー、長いチェーン・オブ・ソート推論など）では、この二次スケーリングにより推論速度が遅くなり、計算コストとメモリコストが大きくなります。
スパース注意は、このスケーリング問題に対する原理的な解決策を提供します。すべてのトークンと、それ以前のすべてのトークンとの関係を計算するのではなく、スパース注意は最も関連性の高いトークンの部分集合だけに対して、各クエリが注意を向けるよう最適化します。
DeepSeek Sparse Attention（DSA）は、この考え方を非常に効率的に実装したもので、最初に DeepSeek-V3.2 で導入されました。どのトークンが最も重要かを判断するために、DSAはモデルの各層に軽量な「lightning indexer module（ライトニング・インデクサ・モジュール）」を導入します。このインデクサは、すべての先行トークンをスコアリングし、主要なコア注意（core attention）メカニズムが処理する小さなバッチを選択します。これにより、DSAは重いコア注意計算を二次（quadratic）から線形（linear）へと削減し、大幅にモデルを高速化しつつ出力品質を維持します。
しかし研究者らは、残っている欠陥を見つけました。DSAのインデクサ自体は、各層ごとに依然として二次的な複雑性で動作しているのです。インデクサは主要な注意処理より計算コストが低いものの、コンテキスト長が伸びるにつれて、これらのインデクサを実行する時間が急激に増大します。これにより、特に、プロンプトが最初に処理される初期の「prefill（埋め込み）段階」でモデルが大きく遅くなります。
IndexCacheによる注意のキャッシュ
インデクサのボトルネックを解決するため、研究チームは重要な特性を見出しました。DSAモデルがデータを処理する際、インデクサが選択する重要トークンの部分集合は、連続するトランスフォーマ層を通過していく間、驚くほど安定しています。DSAモデルに対する実証テストでは、隣接する層は選択したトークンの70%から100%を共有することが分かりました。
この層間冗長性を活用するために、研究者らは IndexCache を開発しました。この技術では、モデルの層を2種類に分けます。少数の「完全（F）層」はインデクサを保持し、トークンを能動的にスコアリングして、キャッシュすべき最も重要なものを選びます。残りの層は「共有（S）層」となり、インデクシングを行わず、直近の前方にあるF層が生成したキャッシュ済みのインデクスを再利用します。
推論時、モデルは単に層の種類を確認します。F層に到達すれば、新しいインデクスを計算してキャッシュします。S層であれば、計算をスキップしてキャッシュされたデータをコピーします。
注意のボトルネックに対処しようとする最適化手法は幅広く存在し、計算された注意値が保存される KVキャッシュの圧縮 によってそれを軽減しようとします。標準的なKVキャッシュ圧縮のようにメモリ使用量を縮小するのではなく、IndexCacheは計算のボトルネックを攻撃します。
「IndexCacheは、従来のKVキャッシュ圧縮や共有の技術ではありません」と論文の共同著者であるユシ・バイ（Yushi Bai）はVentureBeatに語りました。「層間でインデクスを再利用することでこの冗長性を取り除き、メモリ使用量のフットプリントだけでなく計算を削減します。これは既存のアプローチと補完関係にあり、それらと組み合わせることもできます。」
研究者らは、IndexCacheを導入するための2つのアプローチを開発しました。（なお、IndexCacheは最新のDeepSeekモデルや最新のGLMモデル群のように、DSAアーキテクチャを使用するモデルにのみ適用されることに留意する価値があります。）
再学習が現実的でない、またはコストが高すぎるような、市販のDSAモデルを扱う開発者向けに、彼らは「貪欲層選択（greedy layer selection）」アルゴリズムに依拠する学習不要（training-free）の方法を作成しました。少量のキャリブレーションデータセットをモデルに通すことで、このアルゴリズムは重みの更新なしに、F層とS層の最適な配置を自動的に決定します。実証的な証拠では、貪欲アルゴリズムは元のモデルの下流性能を維持したまま、インデクサの75%を安全に削除できることが示されています。
自前の基盤モデルを事前学習したり、強く微調整したりするチーム向けに、研究者らは、層間共有をネイティブにサポートするようネットワークパラメータを最適化する、学習を考慮した（training-aware）版を提案しています。このアプローチでは、学習中に「multi-layer distillation loss（多層蒸留損失）」を導入します。保持される各インデクサに対し、以降にそのインデクサが担当するすべての層で高い関連性を持つ、コンセンサス（合意）されたトークン部分集合を選択する方法を学習させます。
本番モデルでの実世界的な高速化
IndexCacheの影響を検証するため、研究者らはそれを、300億（30B）パラメータの GLM-4.7 Flash モデルに適用し、標準的なベースラインと比較しました。
コンテキスト長200Kでは、インデクサの75%を削除したことで、prefillレイテンシが19.5秒から10.7秒へと大幅に短縮され、1.82倍の高速化が得られました。研究者らは、これらの高速化はより長いコンテキストではさらに大きくなると見込んでいます。
モデルが応答を生成するデコーディング段階では、IndexCacheにより、200Kのコンテキスト境界でのリクエストあたりスループットが1秒あたり58トークンから86トークンへと向上し、1.48倍の高速化が得られました。サーバーのメモリがリクエストで完全に飽和している場合、総デコードスループットは最大で51%増加しました。
エンタープライズのチームにとって、こうした効率化による効果はそのままコスト削減につながります。「ROIの観点では、IndexCacheはさまざまなシナリオで一貫したメリットを提供しますが、効果が最も目立つのは、RAG、文書分析、エージェント型パイプラインのような長コンテキストのワークロードです」とバイ氏は述べました。「これらの場合、少なくとも約20%の導入コスト削減と、ユーザーが体感するレイテンシの同程度の改善が確認できます。」さらに、非常に短いコンテキストのタスクでは、その効果はおよそ5%程度だということも付け加えました。
注目すべきことに、これらの効率化によるメリットは推論能力を損なうことはありませんでした。学習不要の手法でインデクサの75%を除去した30Bモデルは、長コンテキストのベンチマークにおける元のベースラインの平均スコアに匹敵し、49.9（元の50.2に対して）でした。非常に複雑なAIME 2025の数学推論ベンチマークでは、最適化されたモデルは実際に元のベースラインを上回り、91.0に対して92.6を獲得しました。
チームはまた、生産規模の7,440億パラメータのGLM-5モデルに対して予備実験を実施しました。訓練不要の手法でそのインデクサの75%を削除すると、10万トークン超のコンテキストにおいて少なくとも1.3倍の速度向上が得られました。同時に、モデルは長いコンテキストのタスクにおいて、ほぼ同一の品質平均を維持しました。
IndexCacheを本番環境へ導入する
今日から訓練不要のアプローチを実装したい開発チームにとって、このプロセスはシンプルですが、慎重なセットアップが必要です。貪欲探索アルゴリズムは自動的に最適な層の構成を見つけますが、その構成の品質は、処理されるデータに依存します。
「発見された層の共有パターンが実際のワークロードに一致するように、校正用のデータとしてドメイン固有のデータを使うことを推奨します」とBai氏は述べました。
一度校正が済むと、この最適化は本番環境に対して非常に導入しやすくなります。オープンソースのパッチは、主要な配信エンジン向けにすでに
