コンテキスト長を伸ばすと、メモリは「長さに比例して」増える：Ollama・LM Studio・llama.cppの設定を、公式資料で確かめる

3行でいうと

コンテキスト長を大きくすると、必要なメモリが増えます。Ollamaの公式文書も、そう明記しています。
KVキャッシュの増え方は、長さに比例します。Qwen3-8Bなら、1トークンあたり144KiBです。
OllamaでもLM Studioでも、読み込んだ後に実際の長さを確かめる方法が用意されています。
モデルの最大長と、設定した長さは別の値です。設定した長さが、メモリを決めます。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書やモデルカードを読んでまとめたものです。計算の数字は、設定ファイルの値から僕らが計算したものです。

先に結論

「コンテキスト長」は、AIが一度に見渡せる文章の長さです。単位は「トークン」で、文字を機械が数えるための断片です。長さを増やすと、AIが会話の途中で取っておく計算結果（KVキャッシュ）が、長さに比例して増えます。モデル本体の大きさは変わりません。

Ollamaの公式文書は、「コンテキスト長を大きくすると、モデルを動かすのに必要なメモリが増える。使えるVRAMがあるか確かめること」と書いています。VRAMはグラフィックス用のメモリのことで、Appleシリコン搭載のMacでは、CPUとGPUが共有するメモリ（ユニファイドメモリ）が、その役目を兼ねます。

見立てです。普段のチャットなら、既定値のままでも足りることが多いと思います。長い資料を読ませる、コーディング用の道具につなぐ、といった使い方で、初めて伸ばす必要が出ます。伸ばすときは、一気に最大にせず、段階的に上げるのが安全です。

前提：二つの「長さ」を分けて考える

同じ「コンテキスト長」という言葉が、二つの意味で使われます。

モデルの最大長：そのモデルが対応できる上限です。モデルカード（配布ページの説明書き）に書かれています。
設定した長さ：読み込むときに、自分で決める値です。メモリを実際に使うのは、こちらです。

たとえばQwen3-8Bのモデルカードは、標準で32,768トークン、YaRNという拡張を使うと131,072トークンまで検証した、と書いています。一方、同じ配布ページの設定ファイル（config.json）には、max_position_embeddingsが40,960とあります。どの数字を「最大」と呼ぶかは、資料によって違います。モデルカードの文章を、先に読むのが確実です。

仕組み：増えるのは「会話の記憶」の分だけ

メモリに載るものは、大きく二つです。

モデル本体（重み）：読み込んだ時点で決まります。長さを変えても、増えません。
KVキャッシュ：読んだ文章について計算した結果の置き場です。長さに比例して増えます。

1トークンあたりのKVキャッシュは、「2×層数×KVヘッド数×ヘッド次元×1要素のバイト数」で決まります。Qwen3-8Bの設定ファイルは、層数が36、KVヘッド数が8、ヘッド次元が128です。標準の精度（16ビット、2バイト）だと、1トークンあたり147,456バイト、つまり144KiBです（僕らの計算です）。

僕らの計算です。32,768トークンなら約4.8GB、40,960トークンなら約6.0GBで、本体の約16.4GB（BF16の場合）とは別に必要です。

Qwen3-8Bの長さ別KVキャッシュ

僕らの計算です。1トークン147,456バイト（BF16、16ビット）として、GBは10の9乗バイトです。

設定した長さ	16ビット（標準）	8ビット（約半分）	4ビット（約4分の1）
4,096	0.60GB	約0.3GB	約0.15GB
8,192	1.21GB	約0.6GB	約0.3GB
32,768	4.83GB	約2.4GB	約1.2GB
131,072	19.33GB	約9.7GB	約4.8GB

8ビットと4ビットの列は、Ollamaの公式文書が「f16に対して約2分の1、約4分の1」と書いているのを、そのまま当てはめた概算です。実際の大きさは、実装によって少し違うはずです。131,072の行は、YaRNの拡張が前提の計算上の数字で、この記事では確かめていません。

モデルによって、層数やKVヘッド数は違います。使うモデルのconfig.jsonで、層数（num_hidden_layers）、KVヘッド数（num_key_value_heads）、ヘッド次元（head_dim）を確かめると、同じ式で計算できます。

数字や設定：三つの道具の、公式の書き方

Ollama

Ollamaの公式文書（Context length）には、メモリ量ごとの既定の長さが載っています。

使えるVRAM	既定のコンテキスト長
24GiB未満	4k
24〜48GiB	32k
48GiB以上	256k

同じ公式の文書でも、FAQのページには「既定は4096トークン」と書かれています。二つのページで食い違っているので、どちらが新しいかは確認できていません。確実なのは、読み込んだ後に ollama ps で実際の値を見ることです。公式文書の例では、CONTEXTの列に131072と表示されています。

設定の方法は、公式文書では次のとおりです。

アプリの設定画面にあるスライダーで変える。
サーバー起動時に、環境変数 OLLAMA_CONTEXT_LENGTH を指定する（例：64000）。
対話中に /set parameter num_ctx 4096 と打つ。
API（他のソフトからAIを呼ぶ窓口）の呼び出しで、options の num_ctx に値を渡す。
Modelfile（モデルの設定ファイル）に、PARAMETER num_ctx を書く。

公式文書は、Web検索、エージェント（AIが自分で道具を使いながら作業する仕組み）、コーディング用の道具のように、長い文脈が要る作業には「少なくとも64000トークン」を設定するよう勧めています。

また、ollama ps の PROCESSOR 列で、モデルがGPUに全部載っているかを確かめられます。「100% GPU」なら全部GPU、「48%/52% CPU/GPU」のような表示は、一部がCPU側にあふれている状態です。

メモリを節約する方法も、FAQにあります。

フラッシュアテンション（メモリを節約しながら注意の計算をする方式）は、対応していれば自動で使われます。環境変数 OLLAMA_FLASH_ATTENTION で、強制的にオン・オフもできます。
OLLAMA_KV_CACHE_TYPE で、KVキャッシュの精度を選べます。f16が既定です。q8_0は約半分のメモリで精度の低下は非常に小さく、q4_0は約4分の1で、長い文脈ほど低下が目立つことがある、と書かれています。ただし、これはフラッシュアテンションが有効なときの話で、全モデルに共通の設定です。

LM Studio

LM Studioでは、モデルを読み込むときの設定画面で、コンテキストの長さを選びます。「モデルごとの既定値」の文書によると、My Modelsのモデル横にある歯車アイコンから、そのモデルの既定の長さやフラッシュアテンションの使用を保存できます。

コマンド（lms）なら、次のとおりです。公式文書の例です。この記事では、実行していません。

lms load <model_key> --context-length 4096
lms load --estimate-only <model_key>

2行目の --estimate-only は、読み込まずにメモリの見積もりだけを表示します。公式文書によると、見積もりには、コンテキストの長さ、フラッシュアテンション、画像を読む機能の有無が反映されます。文書の例では、gpt-oss-120bの推定がGPUメモリ65.68GBと表示されています。

REST API（HTTPでLM Studioを操作する窓口）の読み込み命令にも、context_length、flash_attention、offload_kv_cache_to_gpu（KVキャッシュをGPU側に置くか）という項目があります。後ろの二つは、LM Studioのllama.cppベースのエンジンでだけ効く、と書かれています。

「同時に処理する数」も関係します。LM Studioの文書では、Max Concurrent Predictions（同時実行数）の既定は4で、読み込み時に変えられます。この設定とメモリの関係は、文書には書かれていませんでした。

llama.cppの関係する設定

llama.cppのサーバーのREADMEから、関係する項目を拾いました。

項目	公式の説明（要約）
-c, --ctx-size	文脈の大きさ。既定は0で、モデルから読み取る
-fa, --flash-attn	on / off / auto。既定はauto
-ctk, -ctv	KVキャッシュのK側・V側のデータ型。既定はf16。q8_0、q4_0なども選べる
-kvo, --kv-offload	KVキャッシュのオフロード（GPU側に置くこと）。既定は有効
-fit	空きメモリに収まるよう、未指定の引数を調整する。既定はon
-fitt, --fit-target	--fitが残す余白。既定は1024MiB
-fitc, --fit-ctx	--fitが下げられる最小の長さ。既定は4096
-np, --parallel	同時に扱うスロット（会話の席）の数。既定は自動

見立てです。-c を指定しない場合と、指定した場合とで、--fit の動きが変わりうると読めます。READMEは「未指定の引数」を調整すると書いているからです。細かい挙動は、この記事では確かめていません。自分で長さを決めたいときは、-c で明示するのが、分かりやすいと思います。

また、スロットが複数あると、KVキャッシュの置き場は共有されます。READMEは、-kvu（統一KVバッファ）を、スロット数が自動のとき既定で有効と書いています。1席あたりの長さは、--kv-unified-per-slot で指定できます。

選び方・判断の基準

見立てです。

まず、使いたい作業に必要な長さを見積もる。短い質問なら4,096〜8,192で足りることが多く、長い文書や道具の連携では、Ollamaの勧める64,000が一つの目安になる。
次に、モデル本体＋KVキャッシュが、メモリに収まるかを計算する。32GBのMacなら、OSなどが使う分を引いた残りが、実際に使える量になる。
足りなければ、(a) 長さを下げる、(b) KVキャッシュを8ビットにする、(c) 本体をより小さい量子化（ファイルを小さくする圧縮）にする、の順に試す。
読み込んだ後、Ollamaなら ollama ps で、GPUに載っているか、設定どおりの長さかを確かめる。LM Studioのコマンドやエンジンを使う場合は、REST APIの読み込み命令に echo_load_config を付けると、実際に適用された設定が返る、と公式文書にある。

僕らの計算です。Qwen3-8Bを4ビット相当（約4.9ビット、本体は約5GB）で、32,768トークンの文脈にすると、本体5.0GBとKV4.8GBで合計約9.8GBです。KVを8ビットにすると、約7.4GBまで下がります。本体を16ビットで読み込む場合の約21.2GBに比べて、大きく余裕ができます。ただし、量子化後のビット数は、別のモデルの値を流用した概算です。

よくあるつまずき

長さを最大にして、読み込みに失敗する：Ollamaの公式文書が、必要なメモリは増える、と注意しています。まず小さい値で動かしてから上げてください。
設定したつもりが、反映されていない：Ollamaには設定の道が複数あります（アプリ、環境変数、対話、API、Modelfile）。どれが効いているかは ollama ps で確かめます。
一部がCPUにあふれて、遅くなる：PROCESSOR列が「100% GPU」でないなら、メモリが足りていません。長さかKVキャッシュの精度を下げます。
モデルの最大長を超えて設定する：モデルカードの範囲を超えると、品質が落ちるおそれがあります。Qwen3のカードは、YaRNは固定の倍率で働くので、短い文章では性能に影響しうる、と注意しています。
KVキャッシュを4ビットにして、長い文脈で答えが乱れる：Ollamaの公式文書が、q4_0は長い文脈で低下が目立つことがある、と書いています。

気をつけること

Ollamaの既定値は、公式文書の二つのページで食い違っています（VRAM量別の表と、4096トークン）。実際の値は、手元で確かめてください。
24GiB未満のとき4kという表は、VRAMについての記述です。Appleシリコンのユニファイドメモリが、どう当てはまるかは、公式文書では確認できていません。
計算の表は、標準の精度のKVキャッシュと、設定ファイルの値からの概算です。実際のメモリ使用量は、エンジンの実装、バッチの大きさ、他のアプリの使用量で変わります。
モデルによっては、見る範囲を区切る方式（スライディングウィンドウ）などで、KVキャッシュの増え方が違います。上の式は、標準の注意機構が前提です。
フラッシュアテンションやKVキャッシュの量子化の既定値、対応状況は、版によって変わります。2026年10月8日に読んだ文書の内容です。
8ビット・4ビットの「約半分・約4分の1」は、Ollamaの文書の言い回しをそのまま使いました。精度への影響は、モデルや用途で違います。

出典

更新履歴

2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した