ModelDock
日
EnglishEN简体中文中日本語日

大きい、しかし遅い：LLM エージェントの最適コンテキストウィンドウ

要旨

長文脈大規模言語モデルは、通常、対応する最大コンテキスト長と decode スループットで評価される。しかし対話的エージェントでは、これらの指標だけではシステム性能を十分に説明できない。エージェントのセッションが長くなるにつれ、より長いコンテキストを prefill 中に処理する必要があり、実測 prefill スループットは文脈長とともに低下することが多い。したがって、モデルやハードウェアが保持できる最大コンテキストでエージェントを動かすことは、総タスク完了時間を短くするのでなく、長くする可能性がある。圧縮は解決策に見えるが、それ自体にコストがある。コンテキストを要約または縮約し、その結果の作業コンテキストを、モデルの推論状態を再構築するために再び prefill しなければならない。この相反するコストは、時間を最小にする作業コンテキスト閾値の存在を意味する。

本稿は、長期実行 LLM エージェントにおけるこのトレードオフの簡単なモデルを示す。固定された作業量に対して圧縮閾値を上げると、圧縮とコンテキスト再構築の頻度は減る一方、劣化した長文脈 prefill スループットの下で行う計算量は増える。一般的な prefill 劣化の形では、総タスク完了時間は作業コンテキスト閾値に対して U 字形になる。さらに、エージェント harness が通常利用のテレメトリーから、ハードウェア、モデル、量子化、バックエンド固有の prefill 劣化関数を学ぶ受動的推定法を提案する。得られた関数は、専用ベンチマークなしに時間最小化の圧縮閾値を推定できる。この枠組みは最大コンテキスト容量と最適作業コンテキストを分け、コンテキスト管理をモデルの公称ウィンドウに対する固定比率ではなく、実行時スケジューリング問題として扱うべきことを示す。

1. 序論

コンテキストウィンドウの急速な拡大は、大規模言語モデルの進歩における重要な次元となった。現代のモデルは数十万、時には数百万 token のコンテキストウィンドウを支える。したがってエージェント harness は、より大きい利用可能コンテキストを無条件に望ましいものとして扱いがちである。一般的な戦略は、会話履歴をモデル最大コンテキストの 80% のような固定比率まで増やし、その後で初めて履歴を圧縮または要約することである。

この方法は、コンテキスト容量とコンテキスト効率を暗黙に同一視している。

長時間動くローカルエージェントでは、この二つは大きく乖離しうる。

エージェントはコンテキストを保存するだけではない。それを処理しなければならない。作業コンテキストが成長すると、prefill はエンドツーエンド遅延のますます重要な成分となる。さらに重要なのは、prefill スループット自体が文脈の成長とともに低下しうることである。したがって、100,000 token で動くエージェントは、30,000 または 50,000 token で動く同じエージェントより、追加作業の各単位の処理にかなり長い時間を使うことがある。

Decode スループットだけではこの影響を捉えられない。毎秒 50 token を生成できるローカルモデルでも、長いエージェントセッションでは、生成前にコンテキストを処理する時間の比率が増えるため、徐々に遅く感じられることがある。

当然の対応は、より頻繁に圧縮することだ。しかし圧縮は無料ではない。従来のモデルベースの圧縮手順は、それ自体が大きな推論を必要としうる。決定論的または CPU ベースの手法で安価に圧縮しても、縮約後の作業コンテキストは推論状態を再構築するため再度処理されなければならない。過度に頻繁な圧縮は、最小限の実用的作業コンテキストを繰り返し再構築し、大きな計算を無駄にしうる。

ここには二つの反対向きの力がある。

作業コンテキスト閾値を上げると、圧縮と再構築の頻度は減る：

\[ H \uparrow \quad\Rightarrow\quad \text{圧縮と再構築が少なくなる}. \]

同時に、モデルはより長く、より遅いコンテキストで作業時間の大きな割合を過ごすことになる：

\[ H \uparrow \quad\Rightarrow\quad \text{長文脈 prefill コストが大きくなる}. \]

この相反する力が内部最適を生むと考える。与えられたモデル、ハードウェア構成、推論バックエンド、圧縮戦略に対し、期待タスク完了時間を最小にする作業コンテキスト閾値が存在する。

これを 最適作業コンテキスト と呼ぶ。

区別は根本的である：

\[ C_{\max} \neq C_{\mathrm{optimal}}. \]

最大コンテキスト \(C_{\max}\) はシステムが収容できるものを表す。最適作業コンテキストは、システムがどこで動くべきかを表す。

本稿はこの点を推定する簡潔な解析枠組みを作り、エージェント harness が通常利用から受動的に学べる実用的機構を提案する。

2. 実行時コストとしてのコンテキスト長

作業を行いながらコンテキストを蓄積する長期実行エージェントを考える。\(c\) を現在の作業コンテキスト長とし、

\[ S(c) \]

を文脈長 \(c\) における、毎秒 token 単位の prefill スループットとする。

有用な一次の経験モデルは

\[ S(c) = \frac{S_0}{1+c/K}, \]

である。ここで \(S_0\) は短文脈 prefill スループット、\(K\) は文脈長に伴う劣化率を制御する。

\(K\) はコンテキスト長の劣化スケールと解釈できる。

\[ c=K, \]

のとき、モデルは

\[ S(K)=\frac{S_0}{2}. \]

を予測する。したがって \(K\) が大きいほど、文脈の成長時に prefill スループットをよりよく保持するシステムである。

この関数形は論旨に必須ではない。実際には \(S(c)\) は観測された実行時データからノンパラメトリックに推定できる。ここでは最適化の構造を明瞭にするため解析形を用いる。

無限小のコンテキスト量 \(dc\) を処理する時間は

\[ dt=\frac{dc}{S(c)}. \]

よって、空の推論状態から長さ \(H\) のコンテキストを構築する時間は

\[ I(H) = \int_0^H\frac{dc}{S(c)}. \]

上の劣化モデルでは、

\[ I(H) = \frac{1}{S_0} \left( H+\frac{H^2}{2K} \right). \]

二次項が重要である。コンテキスト自体は線形に伸びても、後方の token は次第に不利な prefill 条件で処理されるため、累積処理コストは超線形に伸びうる。

3. 圧縮を伴う安定エージェント運用

十分長く動き、安定した圧縮機構に達したエージェントを考える。

\[ R \]

を圧縮後に保持するコンテキストとする。\(R\) は、指示、タスク状態、最近の対話履歴、関連ツール状態、継続運用に必要なその他の情報を保持する最小実用的作業コンテキストである。

\[ H>R \]

を圧縮閾値とする。

安定運用の一周期は

\[ R \rightarrow H \rightarrow \text{圧縮} \rightarrow R. \]

となる。一周期でエージェントが次の圧縮までに行う新規有効作業は

\[ H-R \]

token である。

しかし圧縮後には、その結果のコンテキストを再び処理しなければならない。そのためシステムは約 \(R\) token の作業状態を再構築するコストを繰り返し払う。

この再構築コストが最適化の中心である。これがゼロなら、時間最小の戦略は継続的に圧縮し、できるだけ小さいコンテキストを維持することになる。再構築を含めると、小さすぎる閾値は非効率になる。

4. 有効作業単位当たりの時間

まず、圧縮表現を作る計算コスト自体は無視できると仮定する。これは、GPU 推論に比べ実行時間が小さい決定論的または CPU ベースの圧縮を近似する。

一つの完全周期は、空の推論状態から \(H\) までコンテキストを処理し、そのコストは

\[ T_{\mathrm{cycle}}(H) = = I(H) \frac{1}{S_0} \left( H+\frac{H^2}{2K} \right). \]

である。しかしこの周期が生む新規有効作業は

\[ H-R \]

token だけである。

したがって新規作業一単位当たりの平均 prefill 時間は

\[ J(H;R,K) = \frac{ H+\frac{H^2}{2K} }{ S_0(H-R) }. \]

これが中心目的関数である。

\[ H\rightarrow R, \]

では分母がゼロに近づく。システムは大きな保持コンテキストを繰り返し再構築しながら、ほとんど新規作業を達成しない。よって平均コストは非常に大きくなる。

反対の極では、\(H\) を増やすと再構築コストをより多くの新規作業に償却できるが、周期のより大きな部分が prefill スループットの劣化した文脈長で起きる。

その結果の目的関数は U 字形である。

最適圧縮閾値は

\[ H^* = \arg\min_{H>R}J(H;R,K). \]

微分すると

\[ H^* = R+\sqrt{R^2+2KR}. \]

直ちにいくつかの含意が得られる。

第一に、最適閾値は最大コンテキスト容量の固定比率ではない。

第二に、最適閾値は最小保持作業コンテキスト \(R\) に依存する。

第三に、機械固有の劣化パラメータ \(K\) に依存する。

第四に、短文脈スループット \(S_0\) は総実行時間をスケールするが、この簡略モデルでは最適点を決めない。絶対的 prefill 速度が異なる二つのシステムでも、相対的な劣化関数が同じなら同じ最適コンテキスト閾値を共有しうる。

5. 一般形

上の解析的劣化関数は説明には有用だが、実装には不要である。

経験的に観測された prefill 関数を

\[ \hat S(c). \]

とする。\(B(R)\) をサイズ \(R\) の圧縮後コンテキストを再構築する観測時間、\(F\) を圧縮そのものの計算コストとする。

すると、有効作業単位当たりの平均時間コストは

\[ J(H) = \frac{ B(R) + F + \int_R^H\frac{dc}{\hat S(c)} }{ H-R }. \]

最適閾値は

\[ H^* = \arg\min_{R<H\leq C_{\max}}J(H). \]

である。この表現は prefill 劣化の数学的形状を仮定しない。

また、観測関数 \(\hat S(c)\) を通じて、ハードウェア効果、推論エンジンの挙動、量子化 KV cache、モデルアーキテクチャ、その他の実装固有要因を自動的に取り込む。

6. 利用から最適コンテキストを学ぶ

専用のベンチマークは必要ない。

エージェント harness は通常運用中に、最適化関数を推定する情報をすでに観測している。各推論要求は

\[ (c_i,s_i), \]

という観測を生成でき、\(c_i\) はコンテキスト長、\(s_i\) は観測された prefill スループットである。

時間とともに、これらの観測は

\[ \hat S(c). \]

の経験的推定を与える。

Prefill の振る舞いは GPU だけの属性ではないため、測定は特定の実行時プロファイルに結びつけるべきである。有用なプロファイル識別子には

\[ \text{ハードウェア} + \text{モデル} + \text{重み量子化} + \text{KV 構成} + \text{推論バックエンド}. \]

が含まれる。例えば Q3 重みと Q4 KV cache から、Q4 重みと Q8 KV cache へ変えた場合は、通常、別プロファイルとすべきである。

観測値は 5K または 10K token 区間のような文脈バケットに集約できる。中央値のようなロバスト統計は、一時的なシステム負荷、異常なツール出力、cache 効果、並行プロセスによる汚染を減らせる。あるいは指数加重推定により、プロファイルをソフトウェアや実行時の変化へ徐々に適応させられる。

harness は圧縮後の実際の再構築遅延も観測し、\(B(R)\) を推定できる。

終了時、実行中の定期的な時点、または十分な観測数の後に、これらの統計を永続化できる。

次回起動時に harness は、実行可能な \(H\) の値で

\[ J(H) \]

を評価し、

\[ H^*. \]

を選ぶ。閾値はその後の実行時セッション中は固定されるため、不安定なオンライン方策変更を避けつつ、セッションをまたいで継続的に学習できる。

7. 容量認識からスループット認識の圧縮へ

既存のコンテキスト管理方策の多くは、容量認識として特徴付けられる：

\[ H=\alpha C_{\max}, \]

ここで \(\alpha\) は例えば 0.8 である。

この規則が答えるのは次の問いである：

モデルが容量上限に達する前に、どれだけのコンテキストを安全に消費できるか？

これは次の問いには答えない：

どの文脈長で、蓄積を続けることが作業状態を圧縮して再構築するより遅くなるか？

これらは異なる最適化目的である。

したがって三つの量を区別する：

\[ C_{\max} = \text{最大コンテキスト容量}, \]
\[ R = \text{最小実用的作業コンテキスト}, \]

そして

\[ H^* = \text{時間最適な圧縮閾値}. \]

モデルは 128K token を支えつつ、特定の機械で観測されたスループット最適閾値は 82K かもしれない。残りの容量は例外要求の余裕としてなお価値があるが、通常運用で消費する必要はない。

この区別は、ハードウェア構成が大きく異なり、prefill 劣化が GPU、ユニファイドメモリシステム、量子化戦略、推論バックエンド間で著しく異なりうるローカル推論で特に重要である。

8. 評価

この仮説は、固定作業負荷の長期エージェントタスクで検証できる。

各ハードウェア・モデル構成について、総有効作業負荷と出力要件を一定に保ち、圧縮閾値 \(H\) を変える。

例えば、エージェントに固定の累積作業負荷を処理させ、閾値を独立に

\[ 60K,\ 70K,\ 80K,\ 100K,\ 120K,\ 140K. \]

に設定する。

各条件で測るものは：

  1. 総壁時計完了時間；
  2. 累積 prefill 時間；
  3. 累積 decode 時間；
  4. 圧縮イベント数；
  5. 累積コンテキスト再構築時間；
  6. コンテキスト長の関数としての有効 prefill スループット；
  7. タスク完了品質。

主予測は、圧縮閾値と総完了時間の U 字形関係である。

第二の試験では、経験的に観測された最小値と、受動的に学んだ過去テレメトリーから予測した閾値を比べる。

第三の試験では、スループット認識圧縮を、最大コンテキストの 50%、70%、80% のような固定比率ベースラインと比較する。

重要な結果は、システムが技術的により大きなコンテキストを支えられるかではない。そのコンテキストでの運用が総タスク生産性を改善するかである。

9. ローカル LLM ベンチマークへの含意

ローカル LLM 性能は decode スループットで要約されることが多い。この指標は有用だが、エージェント作業負荷には次第に不十分になっている。

対話的エージェントは prefill、ツール実行、コンテキスト蓄積、状態再構築、decode を繰り返す。セッションが長くなると、decode が高速のままでも prefill が遅延の主要因になることがある。

したがって毎秒 60 出力 token を出す GPU は、長文脈 prefill スループットを大きく高く保つ別の毎秒 45 token の GPU より、長期実行エージェントタスクを遅く完了することがある。

最大コンテキスト容量にも同じ測定問題がある。150K token を保持できるシステムが、150K token で動かしたとき必ずしも生産的とは限らない。

そこで、ローカルおよびエージェント推論の追加システム指標として 時間最適作業コンテキスト を提案する。

より広く、LLM エージェントのハードウェア評価は完全な作業負荷を考慮すべきである：

\[ T_{\mathrm{task}} = T_{\mathrm{prefill}} + T_{\mathrm{decode}} + T_{\mathrm{tools}} + T_{\mathrm{compaction}} + T_{\mathrm{reconstruction}}. \]

最終的に重要な性能の問いは、モデルが token をどれだけ速く出すかではなく、システムが有用な仕事をどれだけ速く完了するかである。

10. 議論

この枠組みは反直観的な結論を生む。十分なメモリがあっても、より大きいコンテキストウィンドウはエージェント生産性を下げうる。

これは大きなコンテキスト容量が望ましくないという意味ではない。大きな容量は柔軟性を与え、本当に大きな連続コンテキストを必要とする作業負荷を支え、オーバーフローへの安全余裕を作る。容量と運用点は分けて扱うべきである。

類比は他の計算資源にも似ている。プロセッサの最高クロック周波数が最も効率的な持続運転点とは限らず、割り当て可能な最大メモリ量がアプリケーションが継続的に消費すべき量とは限らない。

コンテキストも同様に管理された実行時資源として扱うべきである。

この視点は圧縮の役割も変える。圧縮はモデルが文脈上限に近づいた時だけ起動する緊急機構ではない。有利な性能領域に推論を保つため意図的に用いる、通常のスケジューリング操作になりうる。

最適方策は計算と情報の両方に依存する。積極的な圧縮は実行時を改善する一方、後で必要な情報を捨てることでタスク品質を下げうる。従って完全な最適化目的には、最終的に情報損失ペナルティを含めるべきである：

\[ J_{\mathrm{full}}(H) = J_{\mathrm{time}}(H) + \lambda L_{\mathrm{information}}(H), \]

ここで \(L_{\mathrm{information}}\) は圧縮により失った情報の期待下流コストを表す。

本稿で導いた純粋に時間最適な閾値は、最終的なコンテキスト管理目的への必要な第一歩である。

11. 結論

長いコンテキストは無料ではない。

長期実行 LLM エージェントでは、作業コンテキストを成長させると圧縮頻度は減るが、prefill スループットを徐々に劣化させうる。圧縮を積極的にしすぎると逆の問題が起き、システムは大きな最小作業コンテキストを繰り返し再構築することになる。

この相反するコストは時間最適な作業コンテキスト閾値を意味する。

圧縮閾値を最大モデルコンテキストの固定比率として選ぶ代わりに、エージェント harness は通常の推論テレメトリーから、関連する prefill 劣化関数と再構築コストを学べる。得られる閾値は実際のモデル、ハードウェア、量子化構成、バックエンド、作業負荷に固有である。

中心的な区別は単純である：

\[ \boxed{ \text{最大コンテキストは容量の性質である。最適コンテキストは性能の性質である。} } \]

長時間動く LLM エージェントでは、大きいほど常に速いわけではない。