SSD Nodes Learn 🎉 VPS $5.50/月〜
ガイド Matt Connor著者 Matt Connor ・更新日 2026-08-13

Ollamaのコンテキスト長をnum_ctxで設定する方法

Ollamaで長いプロンプトが途中で切れる原因は、小さいデフォルトのコンテキスト長です。num_ctxをリクエスト単位またはサーバー全体で設定し、増量前にKVキャッシュのRAM使用量を確認します。

num_ctx の役割と、長いプロンプトが途中で切られた理由

Ollama のコンテキスト長は、読み込んだモデルが一度にメモリへ保持できるトークン数です。num_ctx がその値を設定するオプションです。Ollama は、モデルが公称する最大値を大幅に下回るデフォルト値を選択します。そのため、長いプロンプトはモデルが読む前に途中で切られます。発生しても、応答からは分かりません。

Ollama のモデルライブラリでは、Llama 3.1 8B のコンテキストウィンドウは 128k と記載されています。ただし、標準のサーバーでその値が使われるわけではありません。Ollama の公式ドキュメントでも、ページによってデフォルト値が異なります。FAQ では 4096 トークン、Modelfile のリファレンスでは num_ctx のデフォルト値が 2048、コンテキスト長のページ では利用可能な VRAM (video RAM) に応じて、24 GiB 未満では 4k、24 GiB 以上 48 GiB 未満では 32k、それ以上では 256k と説明されています。これらは、それぞれ一部のビルドでは正しい値でした。ここから得られる実用的な教訓は、どのページの記載も、この記事も含めてそのまま信頼せず、実行中のサーバーから実際の値を確認することです。

切り捨ては、モデルが応答を返し、その内容も自然に読めるため、気付きにくい問題です。応答は入力の末尾を基に生成されています。文書の前半を欠いた要約は、性能の低いモデルによるものに見えます。しかし、実際にはコンテキストウィンドウが小さいことが原因である場合が多いです。

実際にサーバーが適用した Ollama のコンテキスト長を確認する

どのビルドでも使える確認方法は prompt_eval_count です。これは、サーバーが処理したと報告するプロンプトトークン数です。コンテキストに収まらない量を送ると、この数値は上限で止まります。

sudo apt update && sudo apt install -y jq
LONG=$(python3 -c "print('the quick brown fox jumps over the lazy dog. ' * 2000)")
jq -n --arg p "$LONG" '{model:"llama3.1:8b", prompt:$p, stream:false, options:{num_ctx:4096}}' |
  curl -s http://localhost:11434/api/generate -d @- |
  jq '{prompt_eval_count, prompt_eval_duration}'

このプロンプトは約 18,000 語あり、4096 トークンを大幅に超えています。そのため prompt_eval_count は実際のトークン数に近い値ではなく、4096 前後になります。サーバーが残りを破棄したためです。"num_ctx":16384 を使って再度実行すると、カウントは増加します。ビルドによって切り詰めの代わりにエラーを返す場合も、より明確に示される同じ結果です。

ollama ps

ビルドによって表示される CONTEXT 列には、現在ロードされているモデルが使用しているコンテキスト長が表示されます。その隣の PROCESSOR 列には、モデルの配置状況が表示されます。GPU のない VPS では 100% CPU が通常です。GPU 搭載サーバーで 30%/70% CPU/GPU のように分割されている場合、重みとキャッシュが VRAM に収まらなくなっています。通常の原因は、num_ctx が大きすぎることです。

journalctl -u ollama --no-pager | grep -i n_ctx | tail -n 5

推論ランナーは、n_ctx を含む行にコンテキストサイズを表示します。正確な文言はリリースによって変わるため、その行が見つからなくても、名称が変更された可能性があると考えてください。何らかの事実の証明とはみなさないでください。

num_ctx を設定する場所は 4 つあります

リクエスト内。 /api/generate または /api/chat に "options": {"num_ctx": 16384} を送信します。これは他の設定より優先され、その呼び出し 1 回にだけ適用されます。値が読み込み済みモデルの設定値と異なる場合、サーバーは先にモデルを再読み込みします。この処理はレスポンスの load_duration で確認できます。値がほぼ 0 から数秒単位に跳ね上がります。

対話セッション内。 ollama run 内で /set parameter num_ctx 16384 と入力します。この設定はそのセッション中だけ有効です。

Modelfile 内。 この方法では値が名前付きモデルに組み込まれるため、クライアント側を変更しなくても、すべてのクライアントに適用されます。

FROM llama3.1:8b
PARAMETER num_ctx 16384
ollama create llama3.1-16k -f ./Modelfile
ollama run llama3.1-16k

サーバー上。 OLLAMA_CONTEXT_LENGTH は、独自の num_ctx を含まないすべてのリクエストに対するデフォルト値を設定します。systemd では、unit ファイルを直接編集せず、drop-in を追加します。

sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_CONTEXT_LENGTH=16384"
sudo systemctl daemon-reload
sudo systemctl restart ollama
ollama ps

他のユーザーが作成したクライアントをデバッグするときは、設定の優先順位が特に重要です。num_ctx を含むリクエストはサーバーのデフォルト値より優先されます。そのため、チャットフロントエンドやエージェントが独自に小さい値を送信すると、systemd の変更が気付かないうちに上書きされます。コーディングエージェントを Ollama サーバーに接続する場合は、サーバーを疑う前にクライアントが何を送信しているかを確認してください。

モデルの最大値をそのまま num_ctx に設定できない理由

Attention では、各トークンがそれ以前のすべてのトークンを参照します。先行するトークンについて計算した key と value は、新しいトークンごとに再計算しないよう保持されます。この保存領域が KV cache（key/value cache）です。モデルの読み込み時に num_ctx 全体の領域が確保され、会話の拡大に合わせて確保されるわけではありません。そのため、1 行のプロンプトでも、コンテキストを大きくするとその分のメモリが必要です。

DigitalOcean の推論コストに関するチュートリアルでは、計算式を次の 1 行で示しています。

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

2 は key と value を別々に数えるための値です。その他の数値は、使用するモデルの情報から確認してください。

curl -s http://localhost:11434/api/show -d '{"model":"llama3.1:8b"}' |
  jq '.model_info | {ctx: ."llama.context_length", layers: ."llama.block_count", heads: ."llama.attention.head_count", kv_heads: ."llama.attention.head_count_kv", embed: ."llama.embedding_length"}'

Llama 3.1 8B では、32 層と 8 個の key/value ヘッドが使われます。ヘッドの次元数は embed を heads で割った値です。ここでは 4096 / 32 = 128 となります。また、一部のモデルでは、この値が llama.attention.key_length として直接公開されています。デフォルトの cache では f16 の値が保持されるため、bytes_per_value は 2 です。したがって、2 32 8 128 2 は 131,072 bytes になります。これは、コンテキストの 1 トークンごとに 128 KiB の cache が必要ということです。コンテキスト長を掛けると、必要なメモリ量が具体的に分かります。

ChartLlama 3.1 8B at f16: KV cache and total RAM by context length, in GiB
The data behind this chart
[
  {
    "label": "4k",
    "kv_cache_gib": 0.5,
    "total_ram_gib": 5.1
  },
  {
    "label": "8k",
    "kv_cache_gib": 1,
    "total_ram_gib": 5.6
  },
  {
    "label": "16k",
    "kv_cache_gib": 2,
    "total_ram_gib": 6.6
  },
  {
    "label": "32k",
    "kv_cache_gib": 4,
    "total_ram_gib": 8.6
  },
  {
    "label": "64k",
    "kv_cache_gib": 8,
    "total_ram_gib": 12.6
  },
  {
    "label": "128k",
    "kv_cache_gib": 16,
    "total_ram_gib": 20.6
  }
]

これらの 6 行は、上記の式から算出した値であり、実測値ではありません。合計欄には、Ollama library が August 2026 に llama3.1:8b 用として掲載していた 4.9 GB のダウンロードサイズを加えています。これは 4.6 GiB に相当します。計算バッファーとサーバープロセス自体のメモリは含めていません。実際に必要な容量は、これを下回らないと考えてください。

重要なのは、増え方です。8k では cache は 1 GiB であり、weights と比べれば無視できる量です。モデルの最大値である 128k では 16 GiB になり、weights の 3 倍を超えます。合計は約 20.6 GiB です。そのため、4 GB VPS では、このモデルを実用的なコンテキスト長で読み込めません。8 GB VPS なら 8k で余裕があります。16 GB VPS なら、他の処理に必要な容量を残したまま 32k まで使用できます。weights が増えると、これらのしきい値もすべて上がります。8B モデルとより大きなモデルを比較する場合は、CPU のみの VPS で Qwen の 27B tag を使用した計算を見ると、8 GB から 64 GB の間では weights の後にコンテキスト用として残る容量がいかに少ないかが分かります。

KV キャッシュが収まらない場合の動作

CPU のみの VPS では、プロセスのメモリ使用量がそのまま増加します。モデルの読み込み中と、長いリクエストの実行中に監視してください。

free -m
ps -eo rss,comm --sort=-rss | head -n 5

RSS（resident set size）はキロバイト単位で表示されます。free -m の使用済み swap が増え始めたら、コンテキストサイズを下げてください。swap 上にある KV キャッシュでは、生成の各トークンでキャッシュ全体を読み取る必要があるため、1 トークンあたり数秒単位で生成が停止します。

メモリを完全に使い果たすと、カーネルは最大のプロセスを選んで強制終了します。

sudo dmesg | grep -i "killed process"

Out of memory: Killed process 1234 (ollama) と表示される行は、指定したコンテキストサイズが収まらなかったことを示します。Ollama はそこまで進む前に拒否することが多く、その場合は、必要だったメモリ量と空いていたメモリ量を示すメッセージとともにリクエストが失敗します。

GPU を搭載したマシンでは、失敗の兆候が分かりにくくなります。レイヤーが system RAM にあふれ出し、ollama ps に CPU と GPU の分担が表示され、スループットが急激に低下します。低下幅はハードウェアによって異なるため、他人のマシンの数値を信頼せず、各コンテキスト設定で自分のマシンの 1 秒あたりのトークン数を測定してください。

プロンプトよりもPrefill時間の増加が速い

Prefillは、最初の出力トークンが現れる前に入力に対して行う処理です。各プロンプトトークンは、それより前にあるすべてのトークンを参照するため、処理量は入力長の2乗に比例して増加します。プロンプトを2倍にすると、最初のトークンが返るまでの待ち時間は2倍を超えて増加します。

測定結果はレスポンスに含まれるため、値をそのまま信頼する必要はありません。

jq -n --arg p "$LONG" '{model:"llama3.1:8b", prompt:$p, stream:false, options:{num_ctx:16384}}' |
  curl -s http://localhost:11434/api/generate -d @- |
  jq '{tokens: .prompt_eval_count, prefill_seconds: (.prompt_eval_duration/1000000000)}'

短いプロンプトで実行し、次に長いプロンプトで実行します。その後、それぞれのケースでトークン数を秒数で割ります。CPUのみのVPSでは、長いコンテキストを使用するリクエストの場合、通常Prefillが最も時間のかかる処理です。短いプロンプトから算出したtokens per secondの値では、長いプロンプトの場合の性能を予測できません。

この影響が最も大きくなるのは、同時実行時です。処理中の各リクエストには専用のキャッシュが必要です。そのため、上の図に示したメモリ使用量はサーバー全体ではなく、1リクエストあたりの値です。1つの長いリクエストがサーバーのリソースを占有し、短いリクエストが後ろで待機することがあります。OLLAMA_NUM_PARALLELは意図的に設定し、両方の数値を同時に増やす前に、自己ホスト型LLMが処理できる同時接続ユーザー数を確認してください。

小さいキャッシュに切り替えてコンテキストを確保する

bytes_per_value は、利用者が制御する設定です。Ollama の FAQ には OLLAMA_KV_CACHE_TYPE が記載されており、デフォルトは 2 bytes の f16 です。さらに、1 byte の q8_0 と、それより小さい q4_0 も記載されています。q8_0 に変更するとキャッシュが半分になるため、32k の行に必要な容量は 4 GiB ではなく 2 GiB になります。同じ FAQ には OLLAMA_FLASH_ATTENTION=1 も記載されています。量子化キャッシュを有効にするには、これを先に設定する必要があるビルドがあります。

[Service]
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

推測で済ませず、実際に確認してください。サービスを再起動し、前回と同じ num_ctx でモデルを読み込み、RSS を比較します。対応状況はモデルとバックエンドによって異なるため、設定を変更しても何も変わらない場合、その組み合わせは対象外です。ドキュメントにはこれらのオプションが記載されていますが、品質の向上は保証されていません。実際に使用する前に、q4_0 を独自のプロンプトでテストしてください。これらの設定が必要な理由でこのページを参照している場合は、Ollama と llama.cpp では公開方法が異なります。

context 長を決める手順

  1. /api/show から、モデルの最大コンテキスト、レイヤー数、key/value ヘッド数を確認します。
  2. 式を使ってトークンあたりのバイト数を算出し、必要なコンテキスト長を掛けます。
  3. 重みのサイズを加算して空き RAM と比較し、サーバーの他の処理用に少なくとも 1 GiB を残します。
  4. 値を設定してモデルを読み込み、ollama ps と prompt_eval_count で適用された値を確認します。
  5. free -m を監視しながら実際のワークロードを実行し、swap の使用が始まったらコンテキスト長を半分にします。

多くのジョブでは、一般に設定されているほど長いコンテキストは必要ありません。長いレポートの要約なら 16k で対応できます。5 つの文書チャンクを貼り付ける検索フロントエンドでも、8k を超えることはほとんどありません。ファイル全体を読み取るコーディングエージェントは、64k 以上を実際に必要とするケースです。この場合は、コンテキスト長に合わせてマシンの容量を決めるべきであり、その逆ではありません。サーバー自体を新しく構築したばかりなら、VPS 上で動作する Ollama のインストール から始め、モデルを正常に読み込めることを確認してからコンテキスト長を調整します。

FAQ

Ollama のデフォルトのコンテキスト長はいくつですか？

ビルドとハードウェアによって異なるため、推測せずに確認してください。Ollama の FAQ には 4096 トークン、Modelfile のリファレンスには num_ctx のデフォルトとして 2048、コンテキスト長のページには利用可能な VRAM に基づくデフォルトとして、24 GiB 未満では 4k、24 GiB 以上 48 GiB 以下では 32k、48 GiB 超では 256k と記載されています。CPU のみの VPS では、小さい値になります。ollama ps は、その列を持つビルドで適用されたコンテキスト長を表示します。API レスポンス内の prompt_eval_count を確認すれば、すべてのビルドで適用値を確認できます。

Ollama が長いプロンプトの先頭を無視するのはなぜですか？

プロンプトがコンテキストウィンドウより長かったためです。サーバーがモデルに渡す前にプロンプトを切り詰めますが、エラーは返されません。同じプロンプトを、より大きな num_ctx を指定して再送信し、レスポンス内の prompt_eval_count が増えるか確認してください。その値が変わらない場合は、クライアントとサーバーの間にある何かが num_ctx 自体を設定しています。チャットフロントエンドやエージェントフレームワークでは、これはよくあります。

大きな num_ctx には、どれだけ追加の RAM が必要ですか？

コンテキスト長に、トークンあたりのキャッシュコストである 2 * layers * kv_heads * head_dim * bytes_per_value を掛けて計算します。Llama 3.1 8B を f16 で使用する場合、1 トークンあたり 128 KiB です。そのため、32k トークンでは重みに加えて 4 GiB、完全な 128k では 16 GiB が必要です。キャッシュはモデルのロード時に確保されるため、プロンプトが短いままでも、大きな num_ctx を指定するとその分のメモリを消費します。

コンテキストウィンドウを大きくすると Ollama は遅くなりますか？

はい。理由は 2 つあります。プロンプトの長さの 2 乗に比例して prefill 処理が増えるため、長い入力では最初のトークンが出るまでの時間が、長さから予想する以上に延びます。また、大きなキャッシュがメモリを圧迫します。GPU マシンでは一部のレイヤーが system RAM に移され、CPU マシンでは swap が発生しやすくなります。実際には使い切らない大きな num_ctx でもメモリは消費しますが、prefill 処理の時間は増えません。

1 つのモデルに対して num_ctx を永続的に設定できますか？

はい。FROM llama3.1:8b と PARAMETER num_ctx 16384 を含む Modelfile を作成し、ollama create llama3.1-16k -f ./Modelfile を実行します。llama3.1-16k を要求するすべてのクライアントに対して、オプションを送信しなくてもそのコンテキスト長が適用されます。独自の num_ctx を含むリクエストがある場合は、そちらが優先されます。そのため、これは上限ではなくデフォルト値の設定です。

#ollama#llm#self-hosted-ai#memory#vps