# Mac 上 Ollama 很慢？檢查載入、上下文與記憶體

> 利用 Ollama 執行階段與計時資訊，區分冷載入、上下文大小與記憶體壓力，並在不刪除模型的情況下卸載閒置模型。

Published: 2026-10-22 | Updated: 2026-10-25

Ollama 可能因為模型仍在載入、提示詞具有較大上下文、部分模型在 CPU 上執行，或 Mac 處於記憶體壓力而變慢。這些情況需要不同的調整。刪除已下載的模型可以釋放磁碟空間，但不會自動讓目前正在產生回答的模型變快。

## 比較冷載入與第二次請求

保持模型、提示詞與設定不變。先執行一次簡短請求，然後在模型仍保持載入時重複一次。如果只有第一次請求很慢，載入就是有用的線索。如果兩次產生都很慢，應調查執行與記憶體。記錄這項比較，不要只把一次回應當成基準。

Ollama 的[API 文件](https://docs.ollama.com/api/generate)在完成的回應中提供個別計時欄位，例如 `load_duration`、`prompt_eval_duration` 與 `eval_duration`。這些欄位可區分載入、讀取提示詞與產生輸出。不要拿不同模型、上下文大小或提示詞的 token 速率互相比較，彷彿它們測量的是同一項變更。

## 分段量測單一本地請求

若本機伺服器使用一般連接埠，下列請求會回傳單一 JSON 回應，讓計時欄位更容易檢視。將 `MODEL_NAME` 替換為 `ollama list` 中已安裝的本地模型，不要用雲端模型進行這項比較。此請求會執行推論並消耗資源，但不會刪除模型資料。

```bash
curl -sS http://localhost:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{"model":"MODEL_NAME","prompt":"Explain what a file cache does in two sentences.","stream":false,"options":{"num_predict":128}}'
```

在模型維持載入的情況下再次執行相同請求。停用串流後，終端機會在完成後顯示回應，因此這道命令是用來取得回傳的計時欄位，而不是用肉眼計時第一個 token。若請求失敗，保留其錯誤並停止比較，不要將缺少的欄位解讀為零。

| 回傳欄位 | 如何使用 |
| --- | --- |
| `load_duration` | 比較首次與重複載入時間 |
| `prompt_eval_count` 與 `prompt_eval_duration` | 查看處理了多少輸入及其成本 |
| `eval_count` 與 `eval_duration` | 比較相同工作負載的輸出產生情形 |
| `total_duration` | 將整體請求成本與各組成計時並列 |

文件記載的持續時間單位為奈秒。將持續時間除以 1,000,000,000 即可得到秒數。若要計算輸出速度，將 `eval_count` 除以 `eval_duration / 1,000,000,000`，前提是持續時間為正值。例如，生成 `100` 個 token 耗時 `5,000,000,000` 奈秒，也就是 5 秒，速度便是每秒 `20` 個 token；這不是任何 Mac 或模型的實測結果。

不要將輸出token數除以總持續時間，然後稱之為純生成速度。那會包含載入與輸入處理。也要留意重複的提示是否使用快取輸入，因為較快的第二次請求可能同時反映模型已預熱與提示重複使用。保留完整回應，而不是只報告最漂亮的數字。

## 查看實際載入了什麼

在終端機中檢查目前狀態：

```
ollama ps
```

[Ollama 常見問題](https://docs.ollama.com/faq)說明了 `PROCESSOR` 欄位。它可能顯示 GPU、CPU 或兩者拆分。[硬體指南](https://docs.ollama.com/gpu)記錄了 Apple GPU 上的 Metal 加速。如果你原本預期某個本機模型會使用 GPU，執行結果比根據 Mac 名稱所做的假設更有用。

也要確認請求送往你正在檢查的本機伺服器。前端可能指向另一台主機或雲端模型。在這種情況下，本機的 `ollama ps` 輸出並不描述該遠端請求。

## 先縮小上下文，再歸咎於模型大小

模型檔案只是記憶體需求的一部分。較大的上下文需要額外記憶體，並行請求也會增加工作量。Ollama 的[上下文長度文件](https://docs.ollama.com/context-length)說明了依硬體而定的預設值與應用程式的上下文控制項。不要假設每個安裝的預設值都相同。

進行受控測試時，使用簡短提示詞、單一請求，以及仍包含該測試所需資訊的較小上下文。如果完整的程式設計任務之後需要更多上下文，請還原到足以保留其意義的程度。一個默默遺失必要指示的較快回答，並不是成功的最佳化。

只有在作為獨立比較時，才嘗試較小的模型或量化。這會同時改變資源用量與回答品質。保留幾個具代表性的問題，以便評估較快的選項是否仍然有用。

## 測試脈絡變更但不使其永久生效

對於簡短的診斷提示，API 接受每次請求的脈絡選項。在前述請求中，於 `options` 內與 `num_predict` 並列加入 `"num_ctx":4096`，並使用支援該脈絡的本地模型。這是範例測試大小，不是所有模型或程式設計工作的建議設定。

保持模型與提示不變，然後用 `ollama ps` 檢視執行中的模型並比較記憶體壓力。不要縮小大型對話的脈絡後就假設答案仍包含每一項指示。先比較一個能容納的小型任務；之後再用足以容納其輸入的脈絡測試實際工作負載。

常見問題與專門的脈絡長度頁面對預設值的描述不同，因此本指南不依賴通用預設值。應用程式設定、前端或請求層級選項也可能影響執行中的值。若已安裝版本在 `ollama ps` 中回報 `CONTEXT`，請將該值與 `PROCESSOR` 並列記錄，而不是從模型檔案大小推測。

較低的記憶體讀數不是唯一的成功條件。任務仍須以可接受的答案完成，且 Mac 其餘部分必須保持可用。若較小的脈絡遺漏重要事實，或變更沒有可重現的差異，請移除測試選項並還原先前可用的設定。

## 產生期間觀察整台 Mac

開啟**活動監視器 › 記憶體**，在產生期間觀察記憶體壓力，而不是只在回應完成後才看。Apple Silicon 使用共享系統記憶體，因此其他應用程式也有影響。模型在磁碟上放得下，並不代表它能在你的其餘工作負載旁舒適地運作。

儲存工作並關閉不必要的繁重任務，然後重複相同請求。如果記憶體壓力改善且變慢情況隨之改變，你就有了有用的線索。[記憶體壓力指南](https://mole.fit/tw/blog/mac-memory-pressure-explained)說明了如何解讀 Mac 的指標，而不把每個快取位元組都視為浪費。

## 卸載閒置模型而不刪除它

首先等待任何使用該模型的請求完成。若要釋放不再需要且已載入的模型，請使用 `ollama stop`，後面接上 `ollama ps` 中的確切名稱：

```
ollama stop MODEL_NAME
```

執行命令前請取代 `MODEL_NAME`。這會從記憶體卸載模型。它不會刪除已下載的檔案，而下一次請求可能再次付出載入成本。因此，在每次請求之間反覆卸載模型可能讓體驗變慢。

如果實際限制是磁碟空間，請另外參閱[AI 模型清理指南](https://mole.fit/tw/blog/how-to-remove-ai-tool-leftovers-mac)檢視已儲存的模型。保留本機建立的模型，以及任何你無法可靠地再次下載的項目。就效能而言，一次只比較一項變更，並讓結果與相同工作負載保持關聯。
## 搭配伺服器日誌調查不一致

若本地請求仍然緩慢，或處理器分配不如預期，Ollama 的[疑難排解指南](https://docs.ollama.com/troubleshooting)指出 Mac 伺服器日誌位於 `~/.ollama/logs/server.log`。閱讀測試時間附近的內容，尋找載入失敗、記憶體配置問題或所選的執行後端。若伺服器是手動啟動，對應訊息可能在其終端機中。

記錄 Ollama 版本、確切模型標籤、脈絡、處理器分配以及主導計時結果的階段。分享日誌節錄前，請檢查其中是否含有私人提示與本地路徑。不要僅因為某個 GPU 或伺服器環境變數出現在舊的最佳化文章中就更動多個變數；日誌應先指出變更要處理的不一致。

---

Canonical HTML page: https://mole.fit/tw/blog/ollama-slow-on-mac
Blog index for agents: https://mole.fit/tw/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt