ロングコンテキスト対応ローカルLLM 2026：128K・256K・1Mモデル比較

コンテキスト長とは、モデルが1回のリクエストで保持できるトークンの最大数です。プロンプト、文書、これまでの会話、モデルが書く回答の合計を指します。 1トークンは英語で約0.75語に相当するため、128Kトークンは約10万語、256Kトークンは約20万語です。

公称のウィンドウは、モデルのアーキテクチャが対応する最大値です。実用的なウィンドウは、タスクで回答の精度が保たれる長さであり、それより短くなります。

長いウィンドウは、コードベース全体、契約書、長い文字起こし、書籍の章、ツール出力がたまっていくエージェントのセッションで重要です。Ollamaのドキュメントは、エージェント、Web検索、コーディングツールには64,000トークン以上を推奨しています。

お使いのマシンでの上限は、モデルのウィンドウ、その長さでKVキャッシュが必要とするメモリ、その長さでモデルがどれだけ確実にテキストを使えるか、の3つで決まります。以降のセクションで順に説明します。

いくつもあります。Ollamaライブラリでは、Qwen3.5、Qwen3.8、Gemma 4（12B以上）が256K、NVIDIA Nemotron 3 Nano 30Bが1M、Llama 4 Scoutが10Mと記載されています。 2026年より前に公開されたモデルの多くは128Kまでです。

表はモデルカードまたはOllamaライブラリに記載のウィンドウを示します。YaRNなどの長文脈拡張は、ベンダーが文書化したオプションで、追加の設定とメモリが必要です。

Llama 4 Scoutは10Mトークンと記載されていますが、モデルカードのロングコンテキストのベンチマークは128Kのウィンドウで報告されており、Ollamaのダウンロードは67 GBです。Llama 4 Maverickは1Mと記載されていますが、ダウンロードが245 GBでサーバー級のハードウェアが必要です。

Ollamaのタグによってウィンドウサイズが異なる場合があります。qwen3:8bとqwen3:14bは40K、qwen3:4bとqwen3:30bは256Kと記載されています。計画を立てる前に、モデルのOllamaページでコンテキストの値を確認してください。

長いコンテキストに必要なメモリは、モデルの重みとKVキャッシュの合計であり、KVキャッシュはウィンドウだけでなくアーキテクチャに依存します。 KVキャッシュはコンテキスト内の全トークンのアテンションのキーと値を保存し、重みとは別に確保されます。

トークンあたりのKVバイト数 = 2（キーと値）× フルアテンション層の数 × KVヘッド数 × ヘッド次元 × 1値あたりのバイト数（既定のf16キャッシュでは2）。Llama 3.1 8Bでは 2 × 32 × 8 × 128 × 2 = 131,072バイト（128 KiB）/トークンで、128Kトークンでは16 GiBとなり、ダウンロードサイズ4.9 GBの3倍以上です。

新しいアーキテクチャはこのコストを下げています。Gemma 4はほとんどの層でスライディングウィンドウ注意を使い（12B、26B、31Bでは1,024トークンのウィンドウ）、gpt-ossは2層に1層で使い（128トークン）、Qwen3.5とQwen3.8は4層のうち3層でGated DeltaNetの線形アテンションを使い、Nemotron 3 Nanoは52層のうちアテンション層が6層だけです。ウィンドウとともに増えるのはフルアテンション層だけです。

以下の値は各モデルの公開されている構成から計算したもので、実測ではありません。ランタイムは計算用バッファを追加し、キャッシュの実装も異なるため、実際の使用量はollama psで確認してください。

KVキャッシュを量子化すると小さくなります。Ollamaのドキュメントによると、q8_0はf16の約半分、q4_0は約4分の1のメモリで済み、q4_0では精度が小〜中程度低下します。

まずメモリで選びます。必要なコンテキストでの重みとKVキャッシュの合計が収まり、OSとランタイム用に2〜3 GBの余裕が必要です。 以下は上の表からの計算であり、品質ランキングではありません。ロングコンテキストの精度はベンチマークしていません。

公称のウィンドウはアーキテクチャ上の上限であり、品質の保証ではありません。 Liu et al.（2023）は、言語モデルは関連するテキストが入力の先頭か末尾にあると最も正確に答え、中間にあると精度が下がることを示しました。これが「Lost in the Middle」効果です。

RULER（Hsieh et al.、2024）は、いずれも32Kトークン以上をうたう17モデルを検証し、32Kで十分な性能を保ったのは約半数でした。NoLiMa（Modarressi et al.、2025）は128K以上をうたう13モデルを検証し、32Kでは11モデルが短いコンテキストでのスコアの50%を下回り、GPT-4oは99.3%から69.7%に低下しました。

これらの研究は、このガイドのほとんどのモデルより前のものです。傾向の裏付けとして読み、ここに挙げたモデルのスコアとしては読まないでください。自分で確かめるには、長いプロンプトの10%、50%、90%の位置に事実を1つ隠し、言い換えた質問で尋ね、32K、64K、128Kで繰り返します。

精度が重要な場合は、重要な指示や事実をプロンプトの先頭か末尾に置くか、関連する箇所だけを取得するか（下のRAGの節を参照）、長い文書を重なりのあるセクションに分けて処理してください。

Ollamaの既定のコンテキストはVRAMで決まります。24 GiB未満で4Kトークン、24〜48 GiBで32K、48 GiB以上で256Kです。 アクティブなコンテキストを超えた入力は切り捨てられるため、長い文書の冒頭をモデルが見られなくなります。

コンテキストは、Ollamaアプリのスライダー、環境変数OLLAMA_CONTEXT_LENGTH、ollama run内の/set parameter num_ctx、Modelfile、APIのnum_ctxオプションで設定できます。結果はollama psで確認してください。

LM Studioでは、My Modelsを開き、モデルの歯車アイコンをクリックして、コンテキストサイズとFlash Attentionを設定します。llama.cppでは、-cがコンテキストサイズ（0ならモデルから読み込み）、-faがFlash Attention、--cache-type-kと--cache-type-vがKVキャッシュの量子化を制御します。

OllamaがKVキャッシュを量子化するのはFlash Attentionが有効なときだけで、設定は全モデルに共通です。OLLAMA_KV_CACHE_TYPE=q8_0はf16の約半分、q4_0は約4分の1のメモリで済みます。

使う場合があります。Petrov et al.（2023）によると、同じテキストでもトークナイザーによって、ある言語では別の言語の最大15倍のトークンが必要になることがあります。 日本語、中国語、韓国語、アラビア語のテキストが影響を受けるかどうかは、モデルのトークナイザー次第です。

ページ数を、英語の「1トークン＝0.75語」の規則でトークン数に換算しないでください。使うモデルでトークンを数えてください。ollama run <model> --verboseは、応答の後にプロンプトのトークン数を表示します。

トークナイザーはモデルファミリーごとに異なるため、ウィンドウの予算は言語ごと、モデルファミリーごとに見積もってください。

答えが大きな文書集合のごく一部の箇所にあるならRAG、モデルがひとまとまりの文書全体にわたって推論する必要があるならロングコンテキストを使います。

RAG（検索拡張生成）は、最も関連する断片を取得します。合計で数千トークン程度のことが多く、プロンプトを短く保てます。ロングコンテキストは、契約書の条項やコードベースの呼び出し関係のような、分割すると切れてしまう相互参照を保てます。

両方を組み合わせる構成も多くあります。断片ではなくセクション全体を取得して、32K〜128Kのウィンドウに入れます。ローカルの選択肢はローカルRAGツールのおすすめ、手法はRAGの解説をご覧ください。