2026 Ollama 0.34.0でDeepSeek-R1を実行：タスク終了後もメモリが解放されない場合は？

OllamaのAPIでは、keep_alive=0を指定するとモデルを直ちにアンロードできます。公式API仕様で確認できるこの動作を、まずは作業単位の止血に使います。ただし、Ollama 0.34.0でDeepSeek-R1のメモリが解放されない場合、これは漏れの修復ではありません。今週はメモリ上限を広げたり、コンテキストを何度も短くしたりする前に、Runnerのプロセス識別子、macOSのメモリプレッシャー、次回の冷却時間を記録してください。

対象読者

バッチ処理の開発者は、ジョブの終了処理にモデル回収を組み込みたい方が対象です。AI Agentの開発者は、アンロードが会話やツール呼び出しを壊さないか確認する必要があります。技術責任者は、冷却時間、成功率、障害時のノード交換費用を比較して容量を決めます。

※最終更新：2026年9月15日。OllamaのAPI仕様、macOSのログ案内、AppleのMetalメモリ定義、公開Issueの状態を基準に確認しています。Ollamaのリリース状況やIssueの修正状態は、アップデート時に再確認してください。

常駐と解放を分けるメモリの見方

タスク終了後にアクティビティモニタの使用量が下がらなくても、それだけでメモリリークとは断定できません。Ollamaでは、モデルの重み、KV Cache、ファイルマッピング、Runnerのプロセスヒープが別々の形で見えるためです。モデルが実行一覧に残っているなら、公式の常駐設定による待機の可能性があります。

Apple SiliconではCPUとGPUが統合メモリを共有します。AppleはMetalデバイスの統合メモリを、CPUとGPUが同じメモリを利用する仕組みとして説明しています。Appleの統合メモリ定義に照らすと、GPU専用メモリだけを見て「空きがある」と判断するのは危険です。

確認は単独の数値ではなく、同じ時系列で行います。

ollama ps
pgrep -alf 'ollama|runner'
vm_stat

ollama psからモデルが消えていても、Runnerのプロセスが残っている場合があります。反対に、モデルが残っていても、待機中でメモリ使用量が安定しているなら、すぐに異常と判断する必要はありません。macOSのメモリプレッシャー、スワップ活動、Runnerの識別子を同じ時刻に記録してください。アクティビティモニタのメモリプレッシャー説明では、使用済みメモリだけでなくシステム全体の圧力を見る考え方が示されています。

注意：モデル一覧から消えたことは、物理メモリが同じ量だけ戻ったことを意味しません。ファイルマッピングやmacOSのキャッシュが残るため、プロセス終了、メモリプレッシャー、次回ロードの3点で判定します。

増加源を変数別に切り分ける

コンテキストを短くしても改善しない場合、増加源がKV Cacheとは限りません。次の3変数を一度に変えず、別々の小さな再現で比較します。

• 同じ入力長のまま、リクエスト数だけ増やす。
• リクエスト数を固定し、コンテキスト長だけ変える。
• 入力条件を固定し、同時実行数だけ変える。

コンテキスト長に比例するならKV Cacheが候補になります。リクエスト数に比例してRunnerのヒープが増えるなら、リクエスト終了後の回収処理やランタイム側の保持を疑います。同時実行数にだけ反応するなら、共有サービスのキュー、バッファ、Agentのツール呼び出しが関係している可能性があります。

公開されているmacOSとMetal Runnerのヒープ増加Issueには、API上のモデル使用量が安定していてもプロセス側のヒープが増えるケースがあります。ただし、この報告はOllama 0.32.15と別モデルを前提にしたコミュニティ事例であり、DeepSeek-R1またはOllama 0.34.0について公式に同じ不具合が確認されたことを示すものではありません。DeepSeek-R1での判断は、実際の入力系列を使った最小再現が必要です。

アンロード操作と確認手順

keep_alive=0は、APIリクエスト単位でモデルを直ちにアンロードする指定です。次のように指定できます。

curl http://localhost:11434/api/generate \
  -d '{
    "model": "deepseek-r1",
    "prompt": "作業終了処理",
    "keep_alive": 0
  }'

この設定はモデルの常駐を止めるだけで、Runnerのヒープ増加やMetal側の異常状態を修復するものではありません。回答の状態、ollama ps、pgrepの結果を順に保存し、アンロード後に同じモデルを再度呼び出します。次回のロードが正常に完了するか、前回と同じRunner識別子が残るか、メモリプレッシャーが改善するかを比較します。

手動で停止する場合は、モデル名を確認してから実行します。

ollama ps
ollama stop deepseek-r1
ollama ps
pgrep -alf 'ollama|runner'

Ollama.appを使っている場合と、ターミナルからollama serveで起動している場合では、停止対象が異なります。手動起動なら、起動したターミナルと親プロセスを確認してから終了します。Ollama.appを再起動する場合は、実行中のリクエストがないことを確認し、ログを保存してから行います。macOSのログ確認方法は、Ollama公式トラブルシューティング案内に沿ってください。

回収後も古いRunnerが残り続ける、Metalエラーが繰り返される、再ロード直後に同じ異常が出る、という場合は、サービス全体の再起動へ進みます。ただし定期的な強制終了を本番環境の標準修復策にはしません。失敗した入力、Runnerの識別子、ログ、再ロード結果を保存し、アップデートや隔離構成の判断材料にします。

冷却境界と共有処理の設計

すべてのリクエストでアンロードすると、メモリ問題を冷却問題へ置き換えることになります。DeepSeek-R1の再ロードに時間がかかる環境では、最初の応答遅延、キューの滞留、モデル切り替えによる失敗が増えます。ロード時間と回収量に一般的な閾値を設定せず、実際のリクエスト系列で測定してください。

バッチ処理なら、1ジョブごとではなく、関連する入力をまとめた作業境界で回収する設計が候補です。連続対話やAgentサービスでは、会話の途中でアンロードするとツール呼び出しが失敗したり、別の呼び出しが重複ロードを開始したりします。共有モデルでは、呼び出し元が残っていないことをキューで確認してから停止します。

最低限、次のチェックを作業終了フックに組み込みます。

• [ ] 実行中のリクエストとツール呼び出しがないことを確認する
• [ ] Runnerのプロセス識別子、メモリプレッシャー、スワップ活動を記録する
• [ ] keep_alive=0または停止操作を、作業境界で一度だけ実行する
• [ ] ollama psとRunnerのプロセス状態を再確認する
• [ ] 同じモデルを再ロードし、冷却時間とタスク成功を記録する
• [ ] 失敗時は再試行を一度の経路に集約し、無制限の再ロードを防ぐ
• [ ] 問題が再現した場合はログを保存してからサービスを再起動する

APIサービスでは、ヘルスチェックが成功していても、共有Runnerのヒープが増えていないとは限りません。バッチ処理では、アンロード後の次回ジョブが完了するかを重点的に確認します。回収頻度を決めるなら「何分ごと」ではなく、キューが空になる、作業単位が終了する、冷却後の再試行が成功する、といった状態を条件にします。

継続運用を止める判断

次の4項目が悪化するなら、内核パラメータや実験的な環境変数を追加する前に構成を見直します。

1. タスク完了率が下がる。
2. 復旧のための再起動が増える。
3. 冷却と再ロードが処理時間を押し上げる。
4. 障害時にノードを切り替えられない。

AppleはMetalの推奨ワーキングセットサイズを、アプリケーションが効率よく扱える作業集合の目安として定義しています。Metalのワーキングセット指標は、Runnerのリークを直接診断する値ではありません。したがって、単一のメモリ割合だけで安全性を判定せず、処理完了、回収、再ロード、復旧の4つを評価します。

Ollamaのバージョン更新やIssueの修正が確認できるまでは、DeepSeek-R1の最小再現を保存しておくと比較が容易です。長文容量の見積もりが必要な場合は、DeepSeek-R1向けMac容量の検討記事も併せて確認できます。

3つの運用案とコスト評価

今週の実行順は、実リクエストの記録、keep_alive=0による作業境界回収、同一モデルの再ロード、そして失敗時の分離評価です。回収しないと処理が続かない状態が繰り返されるなら、ローカル調整の問題ではなく、隔離と交換を含む容量設計の問題になっています。

現在のMacでそのまま運用する方法は、物理メモリを他の作業と共有し、Runnerの異常が開発環境全体へ波及しやすく、復旧中は処理も止まるという欠点があります。一般的なクラウド環境へ移す方法も、Metal依存の検証、接続経路、Mac固有のツール互換性を別途確認しなければなりません。

一方、短期の検証や負荷試験なら、独立したMac算力ノードをレンタルして、冷却時間と故障時の交換手順まで含めて試すほうが判断しやすい場合があります。JexMacのMacレンタル料金と利用条件を確認し、まず自分のDeepSeek-R1リクエストで「実行、アンロード、再ロード」の対照を取ってください。長期の安定負荷や物理インターフェースが必要な用途は自購入が適しますが、頻繁な回収でしか継続できないAgentやバッチなら、独立ノードへの分離を検討する段階です。