ローカルLLMが長文で急に遅くなるのはなぜ？VRAMとコンテキスト長を確認

長い資料を渡した直後は、モデルが入力を処理します。その後、返答を順番に生成します。前者が入力処理（プロンプト処理）、後者が文章の生成です。

返答前の待ち時間には、入力処理以外にモデルの読み込みや、Think・reasoningの処理などが入る場合もあります。何も表示されていない時間を、すべてVRAM不足による停止と考えないようにしましょう。

同じモデルと設定で、合成した日本語のPC作業記録を長くして比較しました。Context Lengthの上限は32,768に固定。毎回モデルを読み直し、別の短い質問でウォームアップしてから測っています。

各条件3回の中央値です。モデルのロード時間とウォームアップは表に含めていません。出力は全回256トークンで終了させ、入力文のキャッシュ再利用がないことをエンジンログと照合しました。

長文条件では、入力処理に約6.07秒かかりました。一方、生成速度は137.2トークン/秒で、短い入力の139.8トークン/秒から桁が変わるような低下は起きていません。

つまり今回確認できたのは、「入力が長いほど返答前の待ちが増えた」ことです。どのモデルでも長文の生成速度が変わらない、という結論ではありません。

実際の入力長は、今回モデルに渡す文章の量。Context Lengthは、ロード時に設定する、扱える文脈の長さの上限です。会話履歴や指示文も文脈に入り、回答を生成する余地も必要です。

たとえば上限が32,768でも、短い質問を送るたびに32,768トークン全部を読むわけではありません。ただし、扱える上限を大きくすると、実行時に確保するメモリが増えることがあります。

そこで今度は、入力を489トークンに固定し、上限だけを変えてロード前後のGPUメモリを比べました。

RTX 4080 SUPERは毎回ロード前が0MiBで、上限8,192から65,536へ増やしたときの差は784MiB、約0.77GiBでした。短い入力でも、上限設定によってロード時の使用量が変わっています。

これはGPU全体の使用量です。特にRTX 5080は画面表示などにも使っているため、背景の使用量が動きます。LM Studio単独の使用量や、KVキャッシュだけの容量として読まないでください。MiB・GiBはメモリ容量の単位で、1GiB＝1,024MiBです。

モデル本体に加え、計算用の領域や、過去のトークンの計算結果を再利用するKVキャッシュなどもメモリを使います。文脈が長くなると、保持する情報の負担も変わります。

確保の仕方はモデル構造・実行エンジン・設定によって異なるため、「上限を2倍にすれば、PC全体の必要メモリも必ず2倍」といった計算はできません。今回の約0.77GiBという差も、ほかのモデルへそのまま当てはめないでください。

Windowsのタスクマネージャーで「パフォーマンス」からGPUを開き、専用GPUメモリと共有GPUメモリを見ます。今回のような単体グラボでは、専用側がグラボ上のVRAM、共有側がGPUからも利用するシステムRAMです。

共有側の表示が増えても、グラボに高速なVRAMが増設されたわけではありません。ただし、共有メモリが使われているだけで原因を確定しないこと。短い入力と長い入力で、遅くなる時刻と一緒に変化するかを確認します。

GPU Offloadが少ない構成では、モデルの一部をCPU側で処理する場合があります。これはGPUの計算を続けながらシステムRAMを利用する仕組みとは別です。「VRAMが埋まると、必ずその瞬間にCPU実行へ切り替わる」とは考えないでください。

NVIDIAはStable Diffusion向けの公式解説で、GPUメモリが不足した際の共有メモリへのフォールバックと、その速度低下を説明しています。ただし、今回のLM Studioでその現象が発生したことを示すものではありません。動作はドライバーやエンジンなどにも依存します。

原因を確認する前に、その退避機能を無効化するのはおすすめしません。メモリが足りないとエラーや停止になる可能性があります。まずは入力・上限設定・同時実行を小さくして比較しましょう。

今回、長文で増えたのは主に返答前の入力処理時間でした。短い質問でもContext Lengthの上限を増やすと、ロード時のGPUメモリ使用量は増加。実際の入力長と、扱える上限設定の両方を見るのがポイントです。

まず短い新規チャットと比較し、待ち時間と生成速度を分けて記録する。それからGPUの設定とメモリを確認しましょう。PCの構成を見直すのは、その後でも遅くありません。