ローカルLLMモデル選定:コンテキスト長の最適化からパラメータ調整まで

基礎知識
2025.10.25

はじめに

ローカル或いはオンプレでのLLM運用が注目される中、実行環境を実用レベルに仕上げるには、「どのモデルを選び」「どのようなコンテキスト長（文脈長）・その他パラメータを設定するか」が重要です。

本稿では、モデル選定とコンテキスト長を中心としたパラメータ調整の手順を、初心者にも人気のOllama（以下「Ollama」）を題材として分かりやすく整理します。

モデル選定で押さえておくべき要素

ローカルでLLMでモデルを安定して動かすには、次の項目がポイントです。

  1. モデルのパラメータ数（例：7B・13B・70B）
     → モデルの知識量と精度を決める。
    大きいほど賢いが重く、メモリを多く使う。
  2. 量子化（例：q4・q5・q8）
     → モデルを軽量化する技術。
    少ないメモリでも動かせるが、わずかに精度が下がる。
  3. 最大コンテキスト長
     → AIが「どこまで前の話を覚えていられるか」。
    長くすると記憶力は増すが、速度が落ち、メモリを圧迫する。

パラメータ数と量子化

一般にパラメータ数が大きいモデルほど、より長い文脈を理解し、精度の高い出力を行えます。
しかしメモリの使用量も比例して増加するため、環境によっては動作が不安定になります。

この問題を緩和する手段が 量子化（Quantization） です。  
量子化とは、モデル内部で扱う数値の精度（例：16bit→8bit→4bit）を下げてデータを圧縮し、メモリ消費を約30〜60％削減する技術です。モデル毎に`q4`, `q5`, `q8` などの形式で配布されており、低スペック環境でも大きなモデルを実行できます。

ただし、量子化は数値精度を犠牲にするため、論理推論や計算系タスクではわずかに出力精度が落ちることがあります。

そのため、バランスを考える基本的な方針は下記のようになります。

  • 高精度を求める場合→ 非量子化モデルで短めのコンテキスト  
  • 長文処理や省メモリを重視する場合 → 量子化モデルで長めのコンテキスト

実行環境の制限

この記事を読んでいる方は、まずは自分の環境で動かしてみたいという方も多いでしょう。
ローカルでのLLM実行には、環境の制限が大きく影響します。

  1. ハードウェア構成（CPU／GPU）
     - CPUのみ：低速だが省メモリ。短文処理や検証用に向く。
     - GPU使用：高速処理が可能。CUDA（NVIDIA）、Metal（Mac）、ROCm（Linux）など環境により異なる。
  2. メモリ容量（VRAM／RAM）
     動作可能なモデル規模を左右します。目安として、
     - 8 GB：8Bモデル＋8kコンテキストが限界
     - 16 GB：16k設定や13Bモデルも安定
     - 32 GB以上：32k超や高精度非量子化モデルが現実的

モデルの「ファイルサイズ」（例：7B q4が約4〜6 GB）と、実際に動作時に必要な「メモリ容量（VRAM／RAM）」は一致しません。モデルはロード時に内部構造（重み・キャッシュ・中間テンソル）を展開して処理するため、実際のメモリ使用量はファイルサイズの1.5〜3倍程度になるのが一般的です。

具体的な例を挙げると、ファイルサイズが4〜6 GBの量子化モデル（7B・q4）でも、実行時には約8〜12 GBのVRAMを使用します。また非量子化モデル（FP16など）はさらに重く、7Bで20 GB前後、13Bでは30 GB以上必要になるケースもあります。

2025年10月現在、個人向けに販売されているグラフィックカードは、VRAM16GB~24GB程度が上限です。ワークステーションやサーバー向けでは上位の商品もありますが、非常に高額で現実的ではありません。必要な場合は従量課金のクラウドサービスも検討しましょう。

実際に使う際は、以下の3点を基準に判断すると安全です。

  1. ファイルサイズ × 2〜3倍 をVRAMの目安にする
  2. GPUメモリが足りない場合は量子化版（q4〜q5）を選ぶ
  3. メモリに余裕がない場合はコンテキスト調を小さく設定し、負荷を抑える

この制約を理解しておくと、「モデルを入れたのに起動しない」「応答が途中で止まる」といった典型的なトラブルは避けられます。

コンテキスト長とは？

LLM（大規模言語モデル）は、前述の「どの規模・品質のモデルか」に加えて、「どれだけ過去の文脈を参照できるか（コンテキスト長）」とによって、実務で使えるかどうかが大きく変わります。

モデルには、それぞれ固有の最大サポートコンテキスト長が存在します。（例：32 k・128 kなど）。

ローカルLLM環境でモデルを実行する際には、ユーザーがコンテキスト長のパラメータを明示的に設定できます。

適切な設定の目安

用途別に、文脈長の目安を以下に示します（あくまで出発点）。

用途推奨コンテキスト長 (トークン数)
短文QA・チャット4 k〜8 k
コードレビュー・中長文解析8 k〜16 k
大規模ドキュメントの要約・分析16 k〜32 k

必要十分な文脈長をまず意識し、極端に大きくせず運用コストを抑えるのが現実的です。

デフォルト設定は必ず見直す

Ollamaでは、モデルファイル（Modelfile）内の PARAMETER num_ctx により既定の文脈長（コンテキスト長）が設定されています。

多くのモデルではこの値が 4096トークン（約数千文字）程度と短く、実務で使うには不十分なことが多いです。

そのため、長文要約や会話履歴を維持したい場合は、コンテキスト長を明示的に指定するのが基本です。

少なすぎると「物忘れ」リスク

コンテキスト調が小さすぎると、AIがすぐに文脈を忘れてしまいます。

  • プロンプトが切られる（truncating input prompt）
    入力全体のトークン数が上限を超えると、先頭部分が自動的に削除される。
    これにより、AIが前の会話や指示を参照できなくなる。
  • 会話の継続性が失われる
    長文タスクやチャットで過去の内容が抜け落ち、回答が途切れる・矛盾する。

多すぎると「考え込む」リスク

コンテキスト長を必要以上に大きくすると、次のような影響があります。

  • 応答速度の低下／レイテンシ増加
    コンテキストが長いほど参照トークン数が増え、処理時間が延びる。
  • メモリ圧迫による不安定化
    文脈保持のために作られる「KVキャッシュ」が巨大化し、VRAMやRAMを圧迫。
    場合によってはメモリ不足で応答が止まる。
  • モデル読み込み時間の増加
    初期化時に必要なリソースが増え、ロード直後の応答が遅くなる傾向。

Ollamaでのパラメータ調整の流れ

Ollama設定画面の “Context length” スライダーは、アプリ全体で使用する num_ctx の目安・初期設定値を示しています。ただし、実際に有効となる最大文脈長は、モデルがサポートする仕様とハードウェアメモリ状況によって決まります。

注意点と実用アドバイス（2025年10月時点）

  • 実際の有効範囲はモデル側の対応上限によって決まります。
    たとえば：
    • Llama 3系 → 約8k〜16kまで
    • Mistral系 → 約32kまで
    • Qwen 2.5系 → 128k以上対応
  • デフォルトは4kが設定されていますが、最近のモデルでは少なめの値。すべてのモデルが安全に動作する下限と考えられます。
  • スライダーを上げても、モデルが非対応の範囲は自動で切り捨てられます。
    • 例：Llama3で256kを設定しても、実際には16k前後しか使用されません。
  • スライダーを下げると、モデルの性能よりも短く制限されます。
    • 例：128k対応モデルでも、8kに設定していれば8k分しか文脈を保持しません。
  • 実際には、スライダーを8k〜16k程度に設定しておき、各モデルに合わせて個別調整するのがお勧めです。

ステップ１：ベースのプロンプトで速度／品質をチェック

まず代表プロンプト数本（例：10件）を用意し、モデル×標準 num_ctx（例えば8 k）で「速度（応答までの時間）」「生成速度（tokens/秒）」「品質（結果妥当性・修正不要率）」を計測します。

ステップ２：コンテキスト長 num_ctx を変えて再計測

同じモデルで、文脈長を8 k→16 k→32 kと順に変更して速度・品質の変化を観察。「品質が明らかに改善」なら長くする価値あり、改善が少なければ8 k固定に戻す、という方針が効率的です。

ステップ３：改善が見られなければモデル変更も

もし「品質改善が文脈長だけでは得られない」「速度が極端に落ちる」なら、そこで実用上十分であれば終了、不十分であればモデルをひとつ上げる（例：8 B→12 B）ことを検討します。ステップ1から同様に速度とメモリのバランスを見ます。

参考：Modelfileを用いたカスタムモデル化

頻繁に使う設定が決まったら、Modelfileでカスタムモデルを作っておくと運用が楽です。例えば： 

FROM llama3.1:8b-instruct
PARAMETER num_ctx 16384
PARAMETER temperature 0.1

このような設定で ollama create yourmodel-16k -f Modelfile すれば、毎回オプション指定せず使えるようになります。

補足：RAG（検索＋短文脈投入）との併用も検討

長文ドキュメントをそのままLLMに投げるより、検索（Retrieval）で関連チャンクを抽出し、8 k〜16 k程度の文脈で処理する方が速度・コスト・品質のバランスが良いです。

Ollama自体はRAGに対応していません、他のLLM実行環境を使うかLlamaIndexやLangChain等の外部ツールとの組み合わせが必要になります。

FAQ（よくある質問）

Q：コンテキスト長を最大サポート値（例：128 k）にすれば常に最強ですか？
A：いいえ。モデルの訓練時仕様・ハードウェア制約・応答速度などを鑑みると、最大値が必ずしも最適ではありません。むしろ「必要十分な文脈長」を探すべきです。

Q：num_ctxが小さいとどうなりますか？
A：プロンプトや過去会話が設定値を超えると、先頭側からトークンが切られます。例えば、「質問文が切れて出力がおかしくなった」という報告があります。

Q：他のパラメータも調整すべきですか？
A：はい。限定的ですが、num_predict（生成トークン数上限）・stopトークンなども影響します。詳しくはOllamaのAPIリファレンス等をご参照ください。

Metal（Mac）と CUDA／ROCm（Windows／Linux）のメモリ構造と速度の違い

AIモデルの実行速度は、GPUそのものの性能だけでなく「メモリの構造と帯域」に大きく左右されます。

Mac（Apple Silicon）はMetalによる統合メモリ構造（Unified Memory）、Windows／LinuxのGPUはCUDAやROCmによる独立メモリ構造（Discrete Memory）を採用しており、この違いがLLMでの動作特性にも直結します。

項目Metal（Apple Silicon）CUDA（NVIDIA, Windows/Linux）ROCm（AMD, Linux中心）
構造Unified Memory（統合メモリ）：CPUとGPUが同じメモリ領域を共有Discrete Memory（独立メモリ）：CPUとGPUが別のメモリを持つ同様に独立構造（Discrete）。CPU↔GPU間で明示的転送
転送コストCPUとGPU間で転送不要（共有）だが、帯域は共用PCIe経由でデータ転送が必要だが、GPU内部の帯域は極めて広い転送経路はCUDAと類似（PCIe経由）
メモリ帯域幅約200〜400 GB/s（例：M2/M3）約700〜1000 GB/s（例：RTX 4090 GDDR6X）約500〜900 GB/s（例：RX 7900シリーズ）
実効速度の特徴転送は速いが、GPU専用帯域がなく同時処理で帯域競合転送は遅いが、GPU内部での処理速度は非常に高速性能はCUDAに近いが、ソフト最適化がやや遅れる傾向
VRAM容量システムメモリと共有（最大64 GBなど）GPU専用VRAM（8〜24 GBなど）GPU専用VRAM（8〜24 GBなど）
Ollamaでの傾向大きなモデルも起動できるが、長文処理では帯域不足で遅くなることがある高速で安定。GPU負荷が高いモデルほど差が出るCUDAより若干遅いが、大型モデルも動作可能

  • Metal（Apple Silicon） は「転送コストがない代わりに、GPU専用帯域がない」。
    モデルのロードは速いが、長いコンテキストや高負荷処理ではCPUとGPUが帯域を取り合い、速度が落ちる。 軽量モデル＋中程度のコンテキスト（8k〜16k）向き。

  • CUDA／ROCm（Windows／Linux） は「転送コストがある代わりに、GPUが全力で動ける」。一度ロードすれば、長文処理や連続生成タスクで圧倒的に速い。大型モデル＋長文処理（16k〜32k以上）向き。

この構造差を理解しておくと、「なぜMacでは動くのに遅い」「なぜWindowsでは速いがメモリが足りない」といった現象の理由が明確になります。

まとめ

ローカルのLLM実行環境を実務レベルに仕上げるには、「モデル選定」「コンテキスト長設定」「速さ・品質・コストをバランスさせる」というプロセスが核心です。まずは8 k〜16 kあたりで速度と品質を測定し、必要に応じて文脈長を延ばす／モデルを上げる、という段階的アプローチを取ると、実運用でも迷わず進められます。

ぜひ、本稿をガイドとして、あなたのローカルLLM運用を最適化してください。

外部リンク

タイトルとURLをコピーしました