2026 Ollama 0.34.0 執行 DeepSeek-R1：任務結束後記憶體不釋放怎麼辦？

先不要繼續提高記憶體上限，也不要只靠反覆縮短上下文；若 Ollama 0.34.0 的 Runner 佔用會隨請求累積，應在批次或作業邊界使用 keep_alive=0 或停止模型暫時止血，再用進程識別、macOS 記憶體壓力與下一次冷載入結果確認是否真的回收。Ollama 0.34.0 執行 DeepSeek-R1 後記憶體不釋放，並不等於已經證明底層洩漏；持續 Agent 仍不穩定時，優先考慮進程隔離或獨立算力節點。

批次開發者應把模型回收納入作業生命週期；AI Agent 工程師要評估卸載是否破壞會話與工具呼叫；技術負責人則要在冷載入成本、任務完成率與擴容方式之間作容量決策。

最後更新於 2026 年 9 月 15 日。本文的版本與 API 語義依官方文件及相關社群 Issue 複核；若 Ollama 後續發布記憶體回收修補，或 Issue 關聯至明確修補程式，應重新驗證本文結論。

先分清楚：模型留在記憶體，不等於發生洩漏

請求結束後，Ollama 仍保留模型，最常見的第一個原因是官方 keep_alive 行為。API 文件確認，模型可以在請求完成後繼續駐留；將 keep_alive 設為 0，則要求模型立即卸載。這個參數只控制模型的駐留生命週期，不能證明或修復 Runner 堆積問題，語義可對照 Ollama API 的 keep_alive 說明。

在 Apple Silicon 上，模型權重、KV Cache、檔案映射、Metal 工作集與進程堆都可能反映在同一套統一記憶體中。Apple 對 hasUnifiedMemory 的定義，說明 CPU 與 GPU 共用記憶體；Metal 的推薦最大工作集指標則是資源管理參考，不是「程式一定會在這個數值自動釋放」的上限。可先閱讀 Apple 對統一記憶體的定義 及 Metal 工作集指標說明。

因此，至少要分開觀察以下四件事：

• ollama ps 中模型是否仍處於運行或駐留狀態；
• Runner 進程是否仍存在，以及其 PID 是否更換；
• macOS 的記憶體壓力、交換活動是否惡化；
• Ollama 服務日誌是否出現重新建立 Runner、Metal 錯誤或異常退出。

活動監視器的單次讀數只能說明某一刻的系統狀態。Apple 的 活動監視器記憶體壓力說明 建議把記憶體壓力與交換活動一起看，而不是只盯著「記憶體」欄位。

Ollama 請求結束後為甚麼仍佔用大量 Mac 記憶體？
如果模型仍在 keep_alive 駐留期，權重與相關資源沒有立即消失是預期行為；如果模型已從運行列表消失，但宿主進程或 Runner 的 PID 仍持續增長，才需要進一步排查回收失效。統一記憶體不足通常會伴隨壓力升高、交換活動增加或新請求失敗；請求量增加後進程堆持續累積，則是另一條調查路徑，兩者不能用同一個調參方案處理。

不要先假定縮短上下文就是答案

若縮短上下文後記憶體仍會上升，增長源可能不是 KV Cache。成本分析時，我們會把負載拆成三個變數，逐次只改一項：

• 上下文長度：輸入內容與輸出上限是否同步增加；
• 請求量：單一模型連續處理更多請求後，Runner 堆是否仍上升；
• 並發度：同時進入的請求數提高時，是否出現額外工作集或佇列累積。

這種拆分比「把上下文砍半」更能判斷方向。DeepSeek-R1 的結果必須用實際請求序列重現，不能把其他模型的觀測直接套用。公開的 Ollama macOS／Metal Runner 堆增長 Issue 涉及 Ollama 0.32.15 與其他模型，社群仍未關閉；它只能作為排查線索，不能寫成 Ollama 0.34.0 或 DeepSeek-R1 已獲官方確認的同一洩漏。

建議建立最小重現：固定同一組提示詞、輸出限制與請求順序，先單一請求，再執行連續批次，最後才加入並發。每個階段記錄 Runner PID、進程記憶體、記憶體壓力、交換活動和服務日誌。若只有並發提高才增長，應先檢查佇列與共享模型生命週期；若單一請求也會累積，則應保留版本、模型摘要和日誌，避免在沒有證據時覆寫系統參數。

第一步：依啟動方式記錄卸載前狀態

Ollama.app、手動啟動的服務，以及由 API 管理的模型，觀察角度並不完全相同。先執行：

ollama ps
pgrep -alf 'ollama|runner'

再取得服務日誌。若使用 macOS 應用程式，應保留 Ollama 的診斷資料；若是手動啟動，則把啟動終端機輸出導向檔案。官方 Ollama macOS 日誌與故障排查文件 可作為收集路徑參考。

記錄的重點不是某個固定記憶體數值，而是卸載前後是否出現以下變化：模型列表消失、Runner PID 結束、宿主進程重新建立、記憶體壓力下降，以及下一次請求是否重新載入模型。

第二步：在作業邊界使用 keep_alive=0

API 呼叫可以把 keep_alive 放在請求內容中：

curl http://localhost:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "deepseek-r1",
    "prompt": "完成本批次任務後回傳摘要",
    "keep_alive": 0
  }'

這只表示該次請求完成後要求卸載。完成後再次執行：

ollama ps
pgrep -alf 'ollama|runner'

若使用命令列方式，也可以在確認沒有其他請求後停止模型：

ollama stop deepseek-r1

API 的 keep_alive=0 與命令列停止模型，目的都是控制模型退出駐留；它們不保證已經釋放所有宿主進程、檔案映射或 Metal 資源。官方 API 文件中的 模型卸載語義 應與實際回應及進程狀態一併核對。

keep_alive=0 能不能解決 Ollama 記憶體洩漏？
不能直接這樣下結論。它可以縮短模型駐留時間，對批次作業而言是可逆的止血手段；若卸載後 Runner 仍存活、宿主進程不降，或下一批次重載後持續累積，則只能說駐留已被排除一部分，不能說底層洩漏已修復。

第三步：用三層證據確認是否真的回收

模型從 ollama ps 消失，只代表 Ollama 不再把它列為運行模型，並不等於 macOS 已恢復全部可用記憶體。驗證時要同時保留：

• 服務層：卸載 API 的回應、ollama ps 前後結果；
• 進程層：Runner 與宿主 Ollama 的 PID、進程是否退出或重新建立；
• 系統層：活動監視器的記憶體壓力、交換活動與可用記憶體變化。

接著重新執行同一批次的一個請求，觀察是否出現冷載入、是否成功完成，以及新 Runner 是否沿用或更換 PID。若卸載後舊 Runner 沒有退出，或 Metal 後端已進入錯誤狀態，應先保存日誌，再安排完整服務重啟；不要在還有請求時直接強殺進程。

Ollama 卸載模型後怎樣確認記憶體真的釋放？
至少要看到模型運行列表、Runner 進程和系統記憶體壓力三者的變化；單看其中一項不足以確認。尤其在統一記憶體架構下，檔案映射或快取的回收時序可能與模型列表更新不同步，Apple 的 Metal 工作集文件也不把指標定義成即時釋放保證。

每次請求都卸載，可能把洩漏變成冷載入成本

對單次批處理而言，在整批作業完成後回收通常比每個請求後回收更合理；對連續對話與 Agent 服務而言，逐請求卸載會讓下一次工具呼叫重新載入模型，還可能中斷上下文或造成重複冷載入。這裡沒有可適用所有 Mac、模型與請求序列的通用秒數或記憶體門檻，載入耗時和回收幅度必須以相同環境的實測記錄為準。

我們建議按四個邊界評估：

• 單次請求：只適合彼此完全獨立、且下一次請求沒有低延遲要求的任務；
• 批次：適合固定工作量的離線處理，完成後回收並記錄下一批次冷載入；
• 專案：適合同一模型長時間服務同一工作流，作業結束才回收；
• 佇列空閒期：適合 API 服務，在確認沒有等待中的請求後再卸載。

可參考本站的2026 Mac mini M4 租賃交付驗收，把冷載入、重啟後可用性與任務成功率納入驗收，而不是只比較硬體規格。

並發與 Agent 服務必須先排空，再執行回收

共享模型的服務不能讓任一呼叫方自行觸發停止。某個任務在另一個請求仍使用模型時執行 keep_alive=0 或 ollama stop，可能造成工具呼叫失敗、重試風暴，或讓多個請求同時等待冷載入。

API 服務可採用以下順序：

• 將服務標記為排空狀態，不再接收新的工作；
• 等待目前請求與工具呼叫完成；
• 取得獨占作業鎖，確認佇列沒有待處理項目；
• 執行卸載，再檢查模型列表、Runner PID 和服務日誌；
• 以健康檢查請求驗證模型可以重新載入；
• 只有驗證失敗時才進入完整服務重啟與告警流程。

定時批處理則應在工作排程器中建立作業鎖，將「完成輸出」「保存錯誤證據」「卸載」「下次作業」分成可追蹤狀態。失敗重試不能無限重複冷載入；如果同一節點在重試期間持續增長，應把作業移到另一個隔離進程或替換節點。

持續執行 DeepSeek-R1 應該多久重啟一次 Runner？
不應用固定週期回答。應由任務完成率、Runner 是否持續累積、冷載入影響和失敗恢復結果決定；若尚未完成最小重現，定期強殺只是掩蓋證據。對多人共享的 Agent，應先採用排空、獨占鎖、健康檢查和失敗重試，再決定是否需要進程隔離。

用這份清單決定繼續本機、拆分作業或遷移

• [ ] 固定 DeepSeek-R1 請求序列，分開測試上下文長度、請求量與並發度。
• [ ] 在 keep_alive=0 或 ollama stop 前後記錄模型列表、Runner PID、宿主進程與服務日誌。
• [ ] 用活動監視器確認記憶體壓力與交換活動，而不是只看單次記憶體欄位。
• [ ] 以同一請求驗證卸載後的冷載入與任務完成結果。
• [ ] API 服務先排空佇列並取得獨占鎖，避免誤卸載其他呼叫方正在使用的模型。
• [ ] 若舊 Runner 未退出，保留故障證據後才進行完整服務重啟。
• [ ] 若必須頻繁回收才能維持穩定，計算冷載入成本與節點替換成本，不再優先覆寫實驗性系統參數。
• [ ] 對持續 Agent 或多人共享服務，測試隔離進程或獨立 Mac 算力節點。

評分時，我們會把「本機繼續運行」給予較高分的條件限定在：單一使用者、批次邊界清楚、卸載後能穩定重新載入，而且冷載入不影響交付。若只是把模型拆成較短上下文仍會累積，則應把「拆分作業」視為過渡方案；若需要頻繁重啟、任務會被中斷，或共享 Agent 無法安全排空，隔離節點的分數就高於繼續調參。

若要比較不同 Apple Silicon 節點的租用方式，可先閱讀Mac 節點配置比較指南，再按照實際請求批次做一次「運行—卸載—重新載入」對照。這比單看一個記憶體百分比，更能反映交付風險。

目前本機方案的三個真實限制是：統一記憶體讓 CPU、GPU 與 Metal 工作集共用同一資源池；單一 Ollama 服務中的 Runner 進程不一定能按模型列表消失同步退出；共享 Agent 若由任務自行卸載，還會增加冷載入與重試成本。若工作必須頻繁回收才能完成，繼續覆寫系統記憶體參數通常不是更穩妥的長期方案；租用 JexMac 的獨立 Mac 環境，則可以把批次、測試和故障恢復放到可替換節點上，先以短期週期驗證實際成本，再決定是否值得長期遷移。對需要固定高負載、實體介面或長期持有本機資料的團隊，自購 Mac 仍可能更合適；但臨時算力、版本驗證與隔離 Agent 測試，獨立雲端 Mac 通常更容易控制回收風險。可從JexMac 方案與租賃選項核對適合的交付方式。