Ollamaのnum_ctxが反映されないときは？接続先・API・実行値の確認手順

Ollamaでコンテキスト長を変えたのに以前の値で動くときは、数字をさらに大きくする前に、普段のアプリが使う接続先とAPIを確かめよう。同じサーバー、同じモデルに短い要求を送り、直後の ollama ps または /api/ps を見る。その値と、アプリに戻って要求した後の値を比べると、設定を直す場所を絞れる。

対象は、すでにOllamaでローカルモデルを動かしている人だ。以下は2026年10月12日に確認した公式資料と利用者本人の公開報告に基づく手順で、編集部によるOllama実機検証は行っていない。クラウドモデルの設定変更は扱わない。

設定画面の数字と、実行中の数字を分けて見る

コンテキスト長は、モデルが一度に扱う情報の枠の大きさだ。単位は文字数ではなくトークンで、質問だけでなく、アプリが送る指示や履歴、資料もこの枠を使う。

OllamaアプリではSettingsの「Context length」から変更できる。ただし、画面で選んだ値だけでは、別のアプリがその長さで要求しているかは分からない。

画面の文字を拡大して読む

画像の中を縦・横にスクロールできます。

元の画面を別タブで開く →

利用条件全文（英語）

普段のアプリから短い質問を送ったら、Ollamaを動かしている環境のターミナルで次を実行する。モデルは読み込み後しばらくするとメモリから外れるので、生成中か生成直後に確認したい。

ollama ps

見るのはモデル名、CONTEXT、PROCESSORだ。CONTEXTは割り当てられた長さで、使い終えたトークン数ではない。PROCESSORの 100% GPU はモデルがGPUへ読み込まれていることを表し、GPU使用率が常時100％という意味ではない。コンテキスト長の公式案内（英語）、GPU配置とモデルの保持時間（英語）

モデルの紹介ページや ollama show に書かれた対応長、Modelfileに保存された設定、実際に読み込まれた長さは、別々に確認する。たとえばモデル情報の context_length を読んでも、現在その長さで動いていると確認したことにはならない。実行値を読むAPIは /api/ps だ。モデル情報のAPI（英語）、実行中モデルのAPI（英語）

リモート接続なら、確認先も同じサーバーにする

アプリが別PCやDocker内のOllamaを使っている場合、手元の ollama ps が別のサーバーを見ていないか確認する。まずアプリの設定で、接続先URL、モデル名とタグ、接続方式を控える。http://localhost:11434/v1 のように末尾に /v1 がある設定は、OpenAI互換APIを使っている手掛かりになる。

WindowsのPowerShellでは、次のように接続先を明示して一覧を読める。これはローカルの標準構成の例だ。別サーバーを使っているなら、利用中の接続先に合わせる。新たにネットワーク公開を有効にする必要はない。

$base = 'http://127.0.0.1:11434'

# 保存されているモデル名とタグ
(Invoke-RestMethod "$base/api/tags").models |
  Select-Object name, digest

# メモリへ読み込まれているモデルと割り当て
(Invoke-RestMethod "$base/api/ps").models |
  Select-Object name, context_length, size, size_vram, expires_at

$baseには /v1 や /api を付けず、サーバーのアドレスとポートまでを書く。この変数が指定するのはHTTP通信の接続先だけで、ollamaコマンドの接続先は変わらない。CLI側は OLLAMA_HOST も確認する。モデル名が出なければ、同じ接続先へアプリからもう一度質問し、すぐ読み直す。context_length が返らない版では、空欄を4,096などの既定値で埋めず、Ollamaの版とログを確認する。保存済みモデルのAPI（英語）

「既定では何Kか」を先に決めつけないことも大切だ。確認時の公式Context lengthはVRAMに応じた4,096・32,768・262,144トークンを案内する一方、FAQには4,096、Modelfileの表には2,048という記述がある。設定の有無も含めて、読者の環境で使われた数字を優先しよう。Context length（英語）、FAQ（英語）、Modelfile（英語）

APIへ直接送った後と、普段のアプリに戻った後を比べる

ここからは、自分だけが使っているローカル環境で、他のアプリによる要求を止めて確認する。共有サーバーなら管理者と調整してから進めたい。別の要求が同時に入ると、どの設定でモデルが読み込まれたのかを追いにくい。

Ollama独自APIで、一回だけ設定を指定する

Ollama独自の /api/generate では、options の中に num_ctx を置く。次は、前の手順と同じ $base にある保存済みモデルを、8,192トークンで確認する例だ。8,192は切り分け用の値で、どのモデルやPCでも最適・安全という意味ではない。現在より大きくする場合は、モデルの対応長とメモリの余裕を確かめる。

$model = Read-Host '先ほどの一覧にあるローカルモデル名とタグ'
$body = @{
  model = $model
  prompt = 'Reply with OK.'
  stream = $false
  keep_alive = '5m'
  options = @{
    num_ctx = 8192
    num_predict = 16
  }
} | ConvertTo-Json -Depth 5

$result = Invoke-RestMethod -Method Post `
  -Uri "$base/api/generate" `
  -ContentType 'application/json; charset=utf-8' `
  -Body ([System.Text.Encoding]::UTF8.GetBytes($body))

(Invoke-RestMethod "$base/api/ps").models |
  Where-Object name -eq $model |
  Select-Object name, context_length, size, size_vram

最後の一覧が空の場合は、名前の表記も含めて /api/ps の全件を読み直す。ここでは回答の良し悪しを測らない。num_predict = 16 は生成を短く区切るための指定で、推論を行うモデルでは本文の回答が出る前に終わる場合もある。重要なのは、要求後の context_length がどうなったかだ。独自APIでのnum_ctx指定（英語）、Generate API（英語）

この結果を控えたら、普段のアプリから同じモデルへ短い質問を送り、もう一度 /api/ps を読む。

• 直接送ると指定した長さになり、アプリ経由で変わる：アプリの接続先、モデル名、送信する設定を調べる
• 直接要求しても指定した長さにならない：要求の内容、モデル固有の設定、モデルの再読み込みを確認する
• 値は反映されるが回答がおかしい：設定の問題と、入力内容・読解の問題を分けて調べる

この比較は原因を絞る手順で、アプリだけに不具合があると断定するものではない。読み込み済みモデルの状態をそろえる必要がある場合は、利用中の要求を終えてから対象モデルをアンロードし、同じ要求で読み込み直す。ollama stop モデル名:タグ はメモリから外す操作で、保存済みモデルの削除ではない。CLIも同じサーバーに接続していることを先に確かめよう。CLIリファレンス（英語）

優先順位は、サーバー全体から個別の要求へ

2026年9月4日のIssue #18229（英語）には、Modelfileで65,536トークンを指定していたのに16,384トークンで読み込まれるという利用者の報告がある。投稿者は当初、環境変数がModelfileを上書きすると考えていたが、共同開発者の指摘を受けて訂正した。投稿者の説明では、原因はクライアントが送る要求単位の設定だった。

同じスレッドで示された優先順位は、次の順に個別の指定が優先されるというものだ。

1. サーバーの既定値
2. OLLAMA_CONTEXT_LENGTH
3. Modelfileの num_ctx
4. API要求の設定

つまり、OLLAMA_CONTEXT_LENGTHは全クライアントを縛る上限として扱えない。アプリや事前読み込み用のスクリプトが独自APIへ options.num_ctx を送っていないかまで確認する。ollama psだけでは、その値を選んだ設定元までは分からない、というのがこの報告の重要な点だ。

OpenAI互換APIでは、モデル側に設定を持たせる

接続先が /v1/chat/completions の場合、独自APIのJSONをそのまま使わない。公式のOpenAI互換案内は、コンテキスト長を指定したModelfileで別名のモデルを作り、APIからその名前を呼ぶ方法を示している。max_tokensを増やす方法とも別だ。OpenAI互換APIの設定手順（英語）

例として、テキストファイル Modelfile.context-check を次の内容で作る。YOUR_MODEL:TAG は保存済みのローカルモデル名へ置き換える。

FROM YOUR_MODEL:TAG
PARAMETER num_ctx 8192

同じPowerShellで、未使用の別名を付けて作成する。次の例はCLIにも $base の接続先を渡し、処理後に元の設定へ戻す。Modelfile.context-check を保存したフォルダーで実行する。

$previousHost = $env:OLLAMA_HOST
try {
  $env:OLLAMA_HOST = $base
  ollama create context-check-8k -f Modelfile.context-check
} finally {
  if ($null -eq $previousHost) {
    Remove-Item Env:OLLAMA_HOST -ErrorAction SilentlyContinue
  } else {
    $env:OLLAMA_HOST = $previousHost
  }
}

アプリで指定するモデル名も context-check-8k へ変え、短い要求の後に /api/ps を確認する。元のモデル名のまま送ると、作成した設定を確かめたことにならない。比較後はアプリを元のモデル名へ戻せる。新しい別名はローカルに残るため、不要なら後で整理する。

関連するPR #16825（英語）は、/v1側で num_ctx を独自APIへ渡す変更案だ。2026年10月12日の確認時点ではOpenで、取り込み済みとは確認できない。「修正案がある」と「手元の配布版で使える」は分けて考えたい。9月7日には別の利用者も、独自APIでは設定が反映されるのに、互換APIでは反映されず調査に時間がかかったとコメントしている。

Modelfileを用途別に持つ使い方は、制作現場の報告にも見られる。Mauno_k氏は2026年9月1日のX投稿で、Ollamaと qwen3-vl:8b を使う動画用プロンプト作成の試行を紹介し、Modelfileに num_ctx 16384 を指定した構成を公開している。これは設定を用途とモデル名にひも付けた一例で、16,384トークンが最適だったことや、OpenAI互換APIを試したことを示す報告ではない。本人の制作投稿（英語）

反映された後に、メモリと回答を確認する

CONTEXTが増えたら、次に PROCESSOR と待ち時間を見る。長いコンテキストは、過去のトークンに対応する計算結果を保持するKVキャッシュなどのメモリ負担を増やす。モデルがCPUとGPUへ分かれるようになった場合は、変更前と比べて許容できる速度かを確認したい。モデル本体のファイル容量だけでは、この負担は判断できない。メモリとコンテキスト長の案内（英語）

ただし、size_vramはOllamaが返す実行中モデルの値で、PC全体の空きVRAMではない。OSやGPUの監視画面も併用し、ほかのアプリが使っているメモリを含めて見る。APIの prompt_eval_count も入力のトークン数であり、設定可能な枠の大きさを表す値ではない。実行中モデルの項目（英語）、生成結果の項目（英語）

一つの要求なら動くのに、複数のアプリから使うとメモリ不足になる場合は、同時実行数も調べる。OLLAMA_NUM_PARALLEL を増やすと並列に扱うコンテキスト用のメモリも増えるため、コンテキスト長と同時に変更すると影響を見分けにくい。並列リクエストの公式説明（英語）

サーバーの環境変数を直す場合は、Ollamaを実際に起動する場所で設定する。Windowsの常駐アプリ、Linuxのサービス、Dockerでは設定箇所が違う。開いているPowerShellに変数を追加するだけでは、すでに動いている常駐アプリへは渡らない。変更前の値を控え、利用中の処理を終えてから、その起動方法に合った手順で再起動する。OS別の環境変数設定（英語）

最後に、実際に困っていた資料と質問へ戻る。資料の冒頭・中盤・末尾から答えが分かる質問を用意し、原文と回答を照合する。これは長さを変えた後の確認方法の提案で、数値が反映されただけでは資料全体を正確に読めたとは判断できない。値が合っていても必要な情報を答えないなら、アプリが資料を送っているか、履歴の整理で情報を落としていないか、検索で必要箇所を取り出せているかを次に見る。

問い合わせや再確認のために残す記録は、次の5点で十分に役立つ。

• Ollamaのサーバー版と、モデル名・タグ
• アプリが使う接続先とAPI経路
• どこに、いくつの num_ctx を設定したか
• 直接要求した直後と、普段のアプリから要求した直後の実行値
• 同じ入力での回答、待ち時間、CPU/GPUへの配置

この順で確かめれば、「長さが足りない」「指定した値が使われていない」「反映されたがメモリが足りない」を分けて、次の変更を選べる。