投稿する
マガジン
著者：アソバース編集部公開：更新：約8分で読めます

Ollamaで「メモリが足りない」と出る・極端に遅いときの切り分け手順

AIを使いこなす

Claudeで執筆し、GPTで自動校閲・修正しています。

ノートPCの横で、並んだ木片を一つ取り除いて負担を減らす様子。
記事の内容をもとに制作したAI生成イメージです。実際の製品画面や検証結果の写真ではありません。

結論から言うと、原因はたいてい「モデル本体の大きさ」「コンテキスト長」「同時に載っているモデルや並列リクエスト」のどれかで、まず ollama ps を見れば絞り込めます。設定を変えずに済むものから順に試すのがコツです。モデルの入れ替えは、最後の手段にしてください。 この記事では、症状から原因候補を引く表と、負担の軽い順の対処リストを示します。画面や数値は私が実機で試したものではなく、公式ドキュメントの記載をもとに整理しています。

この記事の目次
  1. 最初に `ollama ps` で現状を見る
  2. 症状別の原因候補（判断表）
  3. 負担の軽い順に試す対処リスト
  4. 量子化とモデルサイズの選び方
  5. それでも直らないとき：ログを見て質問する

最初に `ollama ps` で現状を見る

モデルを動かした直後（応答が返っている最中か直後）に、別のターミナルで次を実行します。ollama ps はロード済みモデルの一覧なので、ロードに失敗して何も表示されない場合は、末尾の手順でログを確認してください。

ollama ps

Ollama公式FAQによると、表のPROCESSOR列は 100% GPU（GPUに全部）、100% CPU（システムメモリに全部）、48%/52% CPU/GPU のような分割表示になります。CONTEXT列には割り当て済みのコンテキスト長が出ます（コンテキスト長の公式ページ）。

メモ欄として次の3点を控えてください。

  • PROCESSORのCPU割合
  • CONTEXTの値
  • 同時に表示されているモデルの数

CPUの割合が大きいほど遅くなりやすい、というのは私の見立てです。GPUのメモリに収まらない分がCPU側に回っている可能性を疑います。

症状別の原因候補（判断表）

  • 起動時や初回応答でエラーになる、疑う原因：モデルが大きすぎる、確認すること：モデルのサイズと自分のGPU/メモリ容量
  • 最初は動くが、長い文章を入れると落ちる・遅くなる、疑う原因：コンテキスト長が大きい、確認すること：ollama ps のCONTEXT
  • 2つ目のモデルを呼んだら遅くなった、疑う原因：複数モデルの同時ロード、確認すること：ollama ps に複数行あるか
  • 複数のアプリやタブから使うと重い、疑う原因：並列リクエストによるメモリ増、確認すること：OLLAMA_NUM_PARALLEL の設定
  • 動くが常に遅い（PROCESSORがCPU寄り）、疑う原因：GPUに載り切っていない、またはGPUが検出されていない、確認すること：PROCESSOR列の割合とログ

FAQによれば、並列数を増やすとメモリ要件も増えます。たとえば「2Kコンテキスト×4並列は8Kコンテキストになる」という説明があります。コンテキストと並列数は別々の設定に見えて、メモリの面では掛け算で効いてくる、と覚えておくと切り分けが楽です。

負担の軽い順に試す対処リスト

上から順に、1つ変えるたびに ollama ps で変化を確かめてください。一度に複数を変えると、何が効いたのか分からなくなります。

  1. 他のアプリを閉じる: ブラウザの重いタブ、動画編集、ゲームなど、GPUやメモリを使うものを止めます。設定変更が要らないので最初に試します。
  2. ロード済みの別モデルを外す: ollama ps に不要なモデルが残っているなら、ollama stop モデル名 で解放します。FAQでは、モデルをメモリに保持する時間（OLLAMA_KEEP_ALIVE）の既定は5分です。保持時間を短くしたい場合は、OLLAMA_KEEP_ALIVE を短くします。ただし、APIの keep_alive 指定があれば、そちらが優先されます。
  3. 並列数を確認する: OLLAMA_NUM_PARALLEL を上げていたら戻します。FAQ記載の既定は1です。
  4. コンテキスト長を下げる: コンテキスト長の公式ページによると、既定値はVRAMに応じて変わり、24GiB未満なら4kです。現在のCONTEXTが4096より大きければ、まず4096へ下げて比較します。アプリの設定スライダー、または環境変数で指定します。次はmacOS/Linuxのシェルでサーバーを手動起動する場合の説明用の例です。既存のOllamaを終了してから実行します。
   OLLAMA_CONTEXT_LENGTH=4096 ollama serve

アプリやsystemdサービスで動かしている場合の環境変数の設定方法は、公式FAQを参照し、設定後にOllamaを再起動してください。呼び出し元が num_ctx を指定している場合は、その値も確認します。大きくするほど必要メモリが増えるため、長文を扱う必要がなければ、入力や会話履歴を収められる範囲で小さくします。

  1. K/Vキャッシュを量子化する: FAQでは、Flash Attentionが有効な場合に OLLAMA_KV_CACHE_TYPE に q8_0 や q4_0 を指定できます。既定の f16 と比べ、K/Vキャッシュ部分の使用メモリはそれぞれ約半分、約4分の1になります。モデル全体のメモリがこの割合で減るわけではありません。Flash Attentionは対応するバックエンドとデバイスで自動的に使われます。全モデルに適用する設定で、精度への影響は用途で確かめる必要があります。
  2. 量子化の強いタグ、または小さいモデルに替える: 最後に、モデル自体を軽くします。

量子化とモデルサイズの選び方

同じモデルでも、タグによって容量が大きく違います。OllamaのLlama 3.2タグ一覧では、3Bモデルのサイズは次のとおりです（閲覧時点）。

  • 3b-instruct-q2_K、サイズ：1.4GB
  • 3b-instruct-q4_K_M（latest と同じ）、サイズ：2.0GB
  • 3b-instruct-fp16、サイズ：6.4GB

この表はファイル容量の比較で、品質の順位を示すものではありません。fp16を使っていてメモリ不足になるなら、まずq4_K_M前後を試し、用途に必要な品質を保てるか確認してください。逆に、すでにq4_K_M以下なら、量子化をこれ以上下げるより、パラメータ数の小さいモデルへ替えるほうが筋のよい場合が多いと考えます（これは編集上の見立てで、品質は実際に試して判断してください）。

モデルのファイル容量は、必要メモリを見積もる際の目安です。実際にはコンテキスト分のキャッシュなどが上乗せされるため、容量ぎりぎりのモデルは避けましょう。

それでも直らないとき：ログを見て質問する

原因が見えなければ、ログに理由が出ていないかを確認します。公式のトラブルシューティングに記載された場所は次のとおりです。

  • Mac: ~/.ollama/logs/server.log
  • Linux（systemd）: journalctl -u ollama --no-pager --follow --pager-end
  • Windows: %LOCALAPPDATA%\Ollama の server.log
  • Docker: docker logs <コンテナ名>

GPUが検出されずCPUに落ちている疑いがあるときも、同じページにNVIDIAやAMD向けの確認手順があります。

AIチャットやフォーラムで相談するときは、次の形でまとめて渡すと、回答が具体的になります。以下は説明用の例で、数値は架空です。

Ollamaで次の症状が出ます。
- 症状: 長い文章を貼ると極端に遅くなる
- モデル: （例）モデルA 8B q4_K_M
- PC: （例）VRAM 8GB / RAM 16GB
- ollama psの結果: PROCESSOR 40%/60% CPU/GPU, CONTEXT 32768
- 同時ロード数: 1、OLLAMA_NUM_PARALLEL: 未設定
- すでに試したこと: 他アプリを閉じた
負担の軽い順に、次に試すことを3つ教えてください。

ログを貼る場合は、ユーザー名やパス、社内情報が含まれていないか確認してから共有してください。

出典・参考資料

マガジン一覧に戻る