コンテキスト長

きっかけ：「コンテキスト長を伸ばすと遅くなる」は本当か 前回の12B〜14B級比較記事で、最速だったGemma4-12B-Hereticについて「次はコンテキスト長を伸ばした際の速度劣化を見てみたい」と書いた。今回はその宿題を実際に検証してみた。 一般に「コンテキスト長(num_ctx)を伸ばすとKVキャッシュが肥大化して遅くなる」というのは直感的に正しそうに思える。でも実際どれくらい、どこから遅くなるのかを実測したことはなかったので、2048から65536まで6段階で、短文生成・長文プロンプト処理の両方を実測してみた。 テスト内容 モデル: Gemma4-12B-Heretic(前回の12B〜14B級比較で最速だったモデル) num_ctxレベル: 2048 / 4096 / 8192 / 16384 / 32768 / 65536 各レベルで2種類のテストを実施 短文プロンプト: 固定の短い質問文(約36トークン)を投げ、生成速度を計測(KVキャッシュの確保サイズ自体が生成速度に与える影響を見る) 長文プロンプト: num_ctxの約70%を埋めるダミー文章を投げ、プロンプト処理速度(prefill速度)を計測(実際にそのコンテキスト長を使い切った際の負荷を見る) 生成速度：伸ばすほど遅くなるわけではなく、途中でむしろ速くなる 結果は予想を裏切るものだった。短文プロンプトでの生成速度は、num_ctx=2048〜4096では18 tok/s前後だったのが、8192〜32768では34〜38.5 tok/sまで約2倍に向上。ところが65536まで伸ばすと21.8 tok/sまで落ち込んだ。 「コンテキスト長を伸ばすと単調に遅くなる」という直感は外れで、実際には**8192〜32768あたりが一番速い「スイートスポット」**になっていて、そこから大きく外れる(小さすぎても大きすぎても)と遅くなるという、山型のカーブを描いていた。 小さい方(2048/4096)で遅かった理由ははっきりしないが、少ないKVキャッシュ確保でもGPU側の処理単位やバッチ調整に何らかのオーバーヘッドがあるのだと思う。大きい方(65536)で遅くなった理由は、VRAM使用量のグラフを見るとわかりやすい。 VRAM使用量：65536だけ突出して増える VRAM使用量は2048〜32768まではほぼ横ばい(8.6〜9.6GB)。ところが65536だけ13.6GBまで跳ね上がる。GPU1枚分(12GB)を超えるサイズで、この時点で単一GPUに収まらなくなり、2枚のGPUをまたぐ処理や何らかの追加オーバーヘッドが発生していると考えられる。生成速度が65536だけ大きく落ち込んだのは、このVRAM構造の変化と一致している。 プロンプト処理速度：長いプロンプトほど「バッチ」が効いて速くなる 同じグラフの中に、長文プロンプトの処理速度(prefill速度)も重ねてみた。こちらは生成速度とは違う挙動を示していて、プロンプトが長くなるほど基本的に処理速度(tokens/秒)は上がる傾向があった(2048時点で29.6 tok/s、32768時点で338.8 tok/sとpiークに)。 これは、プロンプト処理(prefill)が複数トークンをまとめて並列処理できる工程である一方、生成(decode)は1トークンずつ逐次処理せざるを得ない工程だから、という技術的な理由で説明がつく。長いプロンプトほどGPUの並列処理能力を活かせて効率が上がるが、生成側はそうはいかない。65536だけプロンプト処理速度も245.9 tok/sへ落ちているのは、ここでもVRAM構造の変化(GPU分割等)の影響が出ていると見られる。 結論 「コンテキスト長を伸ばすと遅くなる」は単純には成り立たない — 実測では8192〜32768が一番速く、極端に小さい/大きい場合にむしろ遅くなる山型のカーブだった VRAM使用量は32768までほぼ横ばい、65536だけ急増 — 12GB(GPU1枚分)を超えるかどうかが速度低下の分水嶺になっていそう プロンプト処理(prefill)と生成(decode)は別物として考えるべき — 長いプロンプトほどprefillは効率化するが、生成速度には別の要因(KVキャッシュ確保サイズ)が効いてくる 実用上は32768あたりまでなら気にせず使って良さそう — このモデル・この環境では、65536のような極端に大きいnum_ctxを指定しない限り、速度面のデメリットは小さい 「大は小を兼ねない」とまではいかないが、num_ctxを闇雲に大きくしておけば安全というわけでもない、というのが実測しての発見だった。次は今回謎だった「小さいnum_ctxでなぜ遅いのか」「65536でのGPU分割の実態」あたりを、GPU使用率のログを取りながら深掘りしてみたい。