https://www.engineer-labnote.top/tags/%E3%82%B3%E3%83%B3%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E9%95%B7/ Recent content in コンテキスト長 on 現役エンジニアのAI事情 Hugo ja-jp Sat, 12 Sep 2026 19:59:06 +0900 https://www.engineer-labnote.top/posts/202609121959-kontekisuto-chou-wo-noba-suto-hontou-ni-osoku-narunoka-num-c/ Sat, 12 Sep 2026 19:59:06 +0900 https://www.engineer-labnote.top/posts/202609121959-kontekisuto-chou-wo-noba-suto-hontou-ni-osoku-narunoka-num-c/ <img src="https://i.ibb.co/Cy634z1/74bb49610c76.png" alt="コンテキスト長を伸ばすと本当に遅くなるのか？num_ctxを2048〜65536まで実測してみた" style="width:100%;max-width:720px;height:auto;display:block;margin:0 auto;border-radius:8px;" /> <h2 id="きっかけコンテキスト長を伸ばすと遅くなるは本当か">きっかけ：「コンテキスト長を伸ばすと遅くなる」は本当か</h2> <p>前回の12B〜14B級比較記事で、最速だったGemma4-12B-Hereticについて「次はコンテキスト長を伸ばした際の速度劣化を見てみたい」と書いた。今回はその宿題を実際に検証してみた。</p> <p>一般に「コンテキスト長(num_ctx)を伸ばすとKVキャッシュが肥大化して遅くなる」というのは直感的に正しそうに思える。でも実際どれくらい、どこから遅くなるのかを実測したことはなかったので、2048から65536まで6段階で、短文生成・長文プロンプト処理の両方を実測してみた。</p> <h2 id="テスト内容">テスト内容</h2> <ul> <li>モデル: Gemma4-12B-Heretic(前回の12B〜14B級比較で最速だったモデル)</li> <li>num_ctxレベル: 2048 / 4096 / 8192 / 16384 / 32768 / 65536</li> <li>各レベルで2種類のテストを実施 <ol> <li><strong>短文プロンプト</strong>: 固定の短い質問文(約36トークン)を投げ、生成速度を計測(KVキャッシュの確保サイズ自体が生成速度に与える影響を見る)</li> <li><strong>長文プロンプト</strong>: num_ctxの約70%を埋めるダミー文章を投げ、プロンプト処理速度(prefill速度)を計測(実際にそのコンテキスト長を使い切った際の負荷を見る)</li> </ol> </li> </ul> <h2 id="生成速度伸ばすほど遅くなるわけではなく途中でむしろ速くなる">生成速度：伸ばすほど遅くなるわけではなく、途中でむしろ速くなる</h2> <img src="https://i.ibb.co/XvDKXWt/7286b76d3600.png" alt="num_ctx別の速度変化グラフ" style="width:100%;max-width:720px;height:auto;display:block;margin:0 auto;border-radius:8px;" /> <p>結果は予想を裏切るものだった。短文プロンプトでの生成速度は、num_ctx=2048〜4096では18 tok/s前後だったのが、8192〜32768では34〜38.5 tok/sまで<strong>約2倍に向上</strong>。ところが65536まで伸ばすと21.8 tok/sまで落ち込んだ。</p> <p>「コンテキスト長を伸ばすと単調に遅くなる」という直感は外れで、実際には**8192〜32768あたりが一番速い「スイートスポット」**になっていて、そこから大きく外れる(小さすぎても大きすぎても)と遅くなるという、山型のカーブを描いていた。</p> <p>小さい方(2048/4096)で遅かった理由ははっきりしないが、少ないKVキャッシュ確保でもGPU側の処理単位やバッチ調整に何らかのオーバーヘッドがあるのだと思う。大きい方(65536)で遅くなった理由は、VRAM使用量のグラフを見るとわかりやすい。</p> <h2 id="vram使用量65536だけ突出して増える">VRAM使用量：65536だけ突出して増える</h2> <img src="https://i.ibb.co/HfWjsxL6/ab98944f1955.png" alt="num_ctx別のVRAM使用量グラフ" style="width:100%;max-width:720px;height:auto;display:block;margin:0 auto;border-radius:8px;" /> <p>VRAM使用量は2048〜32768まではほぼ横ばい(8.6〜9.6GB)。ところが65536だけ13.6GBまで跳ね上がる。GPU1枚分(12GB)を超えるサイズで、この時点で単一GPUに収まらなくなり、2枚のGPUをまたぐ処理や何らかの追加オーバーヘッドが発生していると考えられる。生成速度が65536だけ大きく落ち込んだのは、このVRAM構造の変化と一致している。</p> <h2 id="プロンプト処理速度長いプロンプトほどバッチが効いて速くなる">プロンプト処理速度：長いプロンプトほど「バッチ」が効いて速くなる</h2> <p>同じグラフの中に、長文プロンプトの処理速度(prefill速度)も重ねてみた。こちらは生成速度とは違う挙動を示していて、プロンプトが長くなるほど基本的に処理速度(tokens/秒)は上がる傾向があった(2048時点で29.6 tok/s、32768時点で338.8 tok/sとpiークに)。</p> <p>これは、プロンプト処理(prefill)が複数トークンをまとめて並列処理できる工程である一方、生成(decode)は1トークンずつ逐次処理せざるを得ない工程だから、という技術的な理由で説明がつく。長いプロンプトほどGPUの並列処理能力を活かせて効率が上がるが、生成側はそうはいかない。65536だけプロンプト処理速度も245.9 tok/sへ落ちているのは、ここでもVRAM構造の変化(GPU分割等)の影響が出ていると見られる。</p> <h2 id="結論">結論</h2> <ol> <li><strong>「コンテキスト長を伸ばすと遅くなる」は単純には成り立たない</strong> — 実測では8192〜32768が一番速く、極端に小さい/大きい場合にむしろ遅くなる山型のカーブだった</li> <li><strong>VRAM使用量は32768までほぼ横ばい、65536だけ急増</strong> — 12GB(GPU1枚分)を超えるかどうかが速度低下の分水嶺になっていそう</li> <li><strong>プロンプト処理(prefill)と生成(decode)は別物として考えるべき</strong> — 長いプロンプトほどprefillは効率化するが、生成速度には別の要因(KVキャッシュ確保サイズ)が効いてくる</li> <li><strong>実用上は32768あたりまでなら気にせず使って良さそう</strong> — このモデル・この環境では、65536のような極端に大きいnum_ctxを指定しない限り、速度面のデメリットは小さい</li> </ol> <p>「大は小を兼ねない」とまではいかないが、num_ctxを闇雲に大きくしておけば安全というわけでもない、というのが実測しての発見だった。次は今回謎だった「小さいnum_ctxでなぜ遅いのか」「65536でのGPU分割の実態」あたりを、GPU使用率のログを取りながら深掘りしてみたい。</p>