作者： Ollama 模型常駐記憶體：設定 keep_alive
Ollama 預設閒置 5 分鐘後卸載模型，下一次請求會再次支付完整載入時間。設定 keep_alive，讓模型在重新啟動後仍維持常駐。
為什麼 Ollama 會在幾分鐘後卸載模型？
Ollama 會在最後一個請求完成後，讓模型繼續載入記憶體 5 分鐘，之後才釋放模型。下一個請求必須再次從磁碟讀取權重，並將其映射至 RAM 或 VRAM，因此第一個 token 產生前會先停頓。這就是為什麼聊天 UI 或程式碼代理一開始反應很快，閒置一段時間後，再傳送下一則訊息時又變慢。這不是故障，而是閒置計時器已到期。
此計時器稱為 keep_alive。它以模型為單位，且每次請求完成後都會重新計時。正在處理請求的模型不會被卸載，因為伺服器只會讓沒有作用中請求的模型逾時卸載。截至 2026 年 8 月，預設值為 5 分鐘，且適用於此伺服器載入的每個模型。
keep_alive有兩個設定位置：個別請求，或伺服器預設值。systemd drop-in 可讓伺服器預設值在重新啟動後仍然保留。本指南假設 Ollama 已經以服務形式執行。若尚未執行，請先參閱 在 VPS 上安裝 Ollama，再返回本指南。
目前有哪些模型常駐，以及何時到期？
ollama psNAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3:8b 500a1f067a9f 6.6 GB 100% GPU 4096 4 minutes from now輸出為空表示目前沒有載入任何模型，因此下一個請求需要完整載入模型。PROCESSOR 會顯示權重所在的位置。100% GPU 和 100% CPU 表示清除狀態。像 25%/75% CPU/GPU 這樣的分割表示模型無法完整放入 VRAM，因此部分模型會在處理器上執行，生成速度也會較慢。
UNTIL 是倒數計時，會列印例如 4 minutes from now 這樣的相對時間。若模型載入時使用負值 keep_alive，則會列印 Forever。伺服器正在卸載模型的短暫期間，會列印 Stopping...。
不同版本的欄位集合可能不同，因此應讀取標頭，不要在腳本中依欄位數量判斷。若要自動化處理，請查詢 API：
curl -s http://localhost:11434/api/ps每個項目都包含 expires_at（例如 2026-08-09T14:38:31.83753Z 這樣的絕對時間戳記），以及 size_vram，表示該模型目前位於 GPU 記憶體中的部分。size_vram 為 0 表示模型在 CPU 上執行。
實際重新載入的成本
不要靠猜測。Ollama 會在每個回應中回報載入時間，欄位為 load_duration，單位是奈秒。
sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'第一次呼叫會載入模型，因此 load_duration 的數值很大。除以 1000000000，即可換算為秒。第二次呼叫會在模型仍駐留記憶體時執行，因此回報的數值小得多。這兩個數值之間的差距，就是計時器逾時後每位使用者都必須承擔的成本，也是變更 keep_alive 的主要原因。若要查看這段暫停前後的生成速度，請參閱如何在自己的主機上測量每秒 token 數。
在單次請求中讓 Ollama 模型維持載入於記憶體
在請求中傳送 keep_alive。請求完成後，這項設定會套用至該模型。
curl -s http://localhost:11434/api/chat -d '{
"model": "qwen3:8b",
"messages": [{"role": "user", "content": "hello"}],
"keep_alive": "30m"
}'支援以下 4 種值格式：
- duration 字串：
"30m"、"24h"、"90s" - 純數字，視為秒數：
3600 - 負值
-1或"-1m"，表示完全不設定閒置逾時 0，表示請求完成後立即卸載
請求中的值會覆寫伺服器預設值，無論覆寫方向為何。這點比表面上更重要：用戶端自行傳送的 keep_alive，會優先於伺服器上的任何設定。
您也可以在不產生任何內容的情況下載入模型。只傳送模型名稱即可。伺服器會載入模型，並以 "done": true 傳回空回應。
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'重新開機或拉取新模型後，請執行這個命令。如此一來，第一個實際使用者請求就不必等待模型載入。CLI 也能透過旗標執行相同操作：
ollama run --keepalive 30m qwen3:8b "hello"使用 OLLAMA_KEEP_ALIVE 預設載入模型
伺服器啟動時會讀取 OLLAMA_KEEP_ALIVE，並將其套用至未自行指定值的所有模型。它接受與請求欄位相同的格式，因此 30m、3600 和 -1 都可使用。
關鍵在於環境變數必須設定在哪個環境中。在 SSH 工作階段執行 export OLLAMA_KEEP_ALIVE=30m 不會產生作用，因為套件安裝會以獨立使用者身分，透過 systemd 服務執行伺服器，並使用該服務自己的環境。登入 shell 與該服務彼此不共用環境。這是設定看似未生效的最常見原因。
讓設定在重新啟動後持續生效：使用 systemd drop-in
sudo systemctl edit ollama.service編輯器會以 2 個註解標記開啟檔案。請在這 2 個標記之間輸入內容：systemd 會捨棄你寫在第 2 個標記下方的所有內容。
[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"儲存後會寫入 /etc/systemd/system/ollama.service.d/override.conf。這是 drop-in，而不是修改套件提供的 unit，因此 Ollama 套件升級並取代 ollama.service 時，不會影響你的設定。如果你不熟悉 drop-in 和 unit file，請參閱systemd 服務與 timer 指南，其中說明相關操作方式。
sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment最後一個命令會顯示服務實際執行時使用的環境。如果該行缺少 OLLAMA_KEEP_ALIVE=30m，表示 drop-in 未生效。原因幾乎都是缺少 [Service] 標頭，或是在標記下方輸入內容。重新啟動會卸載所有已載入的模型，因此下一個請求會重新載入模型。請使用上方的 preload 呼叫預先載入模型。
模型常駐的成本
ollama ps 中的 SIZE 欄位表示整個閒置期間都會保留的記憶體，而不只是處理請求時使用的記憶體。採用 4-bit 量化的 8B 模型約需 5 到 6 GB。27B 模型則是另一個層級；在決定讓模型常駐前，值得先計算僅使用 CPU 的 VPS 執行模型所需的記憶體。將 keep_alive 設為 -1，就等於永久決定讓模型的優先級高於該主機上的所有其他工作。在小型 VPS 上，這會直接排擠資料庫、Web 應用程式與建置工作。
請查看實際數值，不要只相信估算值。模型載入後執行一次，然後在 ollama stop 後再次執行：
free -havailable 欄位表示 kernel 仍可分配給新程序的記憶體。在 NVIDIA GPU 主機上，nvidia-smi 會在 VRAM 中呈現相同的情況。主機耗盡記憶體時，kernel 會終止某個程序以回收資源：
sudo dmesg -T | grep -i "out of memory"列出 ollama 的行表示模型伺服器成為受害者。列出資料庫名稱的行表示模型勝出，而你在意的服務遭到終止。這兩種結果都源自相同的決定：在沒有餘裕的主機上設定過長的 keep-alive 期間。
這裡有兩項容易忽略的成本。較長的 context length 會保留較大的 KV cache（key value cache，也就是模型在生成期間為每個 token 保留的 attention 狀態），而這項快取會計入常駐大小。將 OLLAMA_NUM_PARALLEL 設為大於 1 的值，會為每個平行 slot 各保留一份快取。如果計畫讓同一個模型服務多位使用者，應依 slot 數量配置記憶體，而不是只依權重大小配置。
合理的預設值是：在具備充足餘裕的主機上執行單一模型時，可使用 -1。共用主機則應設定涵蓋請求間隔的視窗，例如 30m，讓你停止工作後記憶體能夠回收。
立即卸載模型
ollama stop qwen3:8b此命令不會輸出任何內容，模型也會從 ollama ps 中消失。指定未載入的名稱時，會回傳 couldn't find model "qwen3:8b" to stop。API 格式是不帶提示詞的請求，並將 keep_alive 設為 0：
curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'回應會包含 "done_reason": "unload"。請使用此方法，不要重新啟動服務。systemctl restart ollama 也會釋放記憶體，但會卸載其他所有已載入的模型，並終止目前正在執行的請求。
在一台伺服器上執行多個模型
OLLAMA_MAX_LOADED_MODELS會限制同時保持載入的模型數量。截至 2026 年 8 月，預設值為每個 GPU 3 個模型；僅使用 CPU 的主機則為 3 個模型。此限制計算的是模型數量，但真正的限制是記憶體。因此，第二個大型模型可能在達到 3 個模型之前很久就因記憶體不足而無法載入。
要求載入新模型時，如果可用記憶體不足，排程器會卸載其中一個已載入的模型以釋出空間。排程器會優先選擇目前沒有處理請求的模型，也可能移除計時器尚未到期的模型，包括使用 -1 載入的模型。因此，負值 keep_alive 表示不設定閒置逾時。它不會固定模型權重，以阻止其他模型提出載入要求。
此決策會以 debug 層級寫入日誌。在相同的 drop-in 中加入第二行 Environment="OLLAMA_DEBUG=1"，重新啟動服務，然後監看日誌：
sudo journalctl -u ollama -f如果在觸發請求旁看到「卸載 runner 以釋出空間」的訊息，表示這兩個模型無法在此機器上同時運作。解決方式是減少此主機上的模型數量，或為必須快速回應的模型設定較長的保留時間，並為較少呼叫的模型設定 0。
不受下一個版本影響的指引
Ollama 經常發布新版本，預設值也會變動，因此請以目前使用的 build 為準，不要只記憶版本號：
ollama --version
ollama serve --helpollama serve --help會列出該 build 實際讀取的環境變數，其中包括 OLLAMA_KEEP_ALIVE。有兩項規則在各版本中都維持不變，可以放心依據這些規則設定。請求中的值會覆寫伺服器預設值。此外，無論設定檔宣告應載入什麼，ollama ps才是實際載入內容的依據。
如果由編輯器或 agent 控制伺服器，請先確認該用戶端傳送的內容，再判斷問題是否出在伺服器。將 coding agent 指向自有的 Ollama 伺服器說明這些請求設定所在的位置。
FAQ
Ollama 為什麼會在 5 分鐘後卸載模型？
5 分鐘是預設的 keep_alive，也就是 Ollama 在請求完成時啟動的閒置計時器。計時器到期後，伺服器會釋放模型權重，因此下一個請求必須從磁碟重新載入模型，而這段重新載入時間就是您感受到的停頓。若只要對單一請求延長時間，請在 JSON body 中傳送 "keep_alive": "30m"；若要套用至整個伺服器，請設定 OLLAMA_KEEP_ALIVE 環境變數。
如何讓 Ollama 模型永久保留在記憶體中？
使用負值：在請求中設定 "keep_alive": -1，或在伺服器中設定 OLLAMA_KEEP_ALIVE=-1。接著，ollama ps 會在 UNTIL 欄位顯示 Forever。這只會移除閒置計時器，不會有其他影響。如果又請求其他模型，且記憶體不足，scheduler 仍會卸載這個模型以騰出空間。
為什麼 OLLAMA_KEEP_ALIVE 沒有生效？
先確認設定位置。執行 systemctl show ollama --property=Environment。如果輸出中沒有這個變數，表示伺服器根本沒有收到它，因為您在 shell 中匯出的變數不會傳遞給 systemd 服務。請使用 sudo systemctl edit ollama.service 設定，然後執行 sudo systemctl daemon-reload 和 sudo systemctl restart ollama。另一個原因是 client 在請求中自行傳送 keep_alive，這會覆寫伺服器的預設值。
如何在不重新啟動 Ollama 的情況下釋放記憶體？
ollama stop qwen3:8b 會立即卸載該模型，同時讓伺服器及其他已載入的模型繼續執行。使用 API 時，請傳送不含 prompt 且包含 "keep_alive": 0 的請求，回應會包含 "done_reason": "unload"。使用 ollama ps 確認，輸出中應不再列出該模型。