Mac 上 Ollama 很慢?檢查載入、上下文與記憶體
Ollama 可能因為模型仍在載入、提示詞具有較大上下文、部分模型在 CPU 上執行,或 Mac 處於記憶體壓力而變慢。這些情況需要不同的調整。刪除已下載的模型可以釋放磁碟空間,但不會自動讓目前正在產生回答的模型變快。
比較冷載入與第二次請求
保持模型、提示詞與設定不變。先執行一次簡短請求,然後在模型仍保持載入時重複一次。如果只有第一次請求很慢,載入就是有用的線索。如果兩次產生都很慢,應調查執行與記憶體。記錄這項比較,不要只把一次回應當成基準。
Ollama 的API 文件在完成的回應中提供個別計時欄位,例如 load_duration、prompt_eval_duration 與 eval_duration。這些欄位可區分載入、讀取提示詞與產生輸出。不要拿不同模型、上下文大小或提示詞的 token 速率互相比較,彷彿它們測量的是同一項變更。
分段量測單一本地請求
若本機伺服器使用一般連接埠,下列請求會回傳單一 JSON 回應,讓計時欄位更容易檢視。將 MODEL_NAME 替換為 ollama list 中已安裝的本地模型,不要用雲端模型進行這項比較。此請求會執行推論並消耗資源,但不會刪除模型資料。
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 常見問題說明了 PROCESSOR 欄位。它可能顯示 GPU、CPU 或兩者拆分。硬體指南記錄了 Apple GPU 上的 Metal 加速。如果你原本預期某個本機模型會使用 GPU,執行結果比根據 Mac 名稱所做的假設更有用。
也要確認請求送往你正在檢查的本機伺服器。前端可能指向另一台主機或雲端模型。在這種情況下,本機的 ollama ps 輸出並不描述該遠端請求。
先縮小上下文,再歸咎於模型大小
模型檔案只是記憶體需求的一部分。較大的上下文需要額外記憶體,並行請求也會增加工作量。Ollama 的上下文長度文件說明了依硬體而定的預設值與應用程式的上下文控制項。不要假設每個安裝的預設值都相同。
進行受控測試時,使用簡短提示詞、單一請求,以及仍包含該測試所需資訊的較小上下文。如果完整的程式設計任務之後需要更多上下文,請還原到足以保留其意義的程度。一個默默遺失必要指示的較快回答,並不是成功的最佳化。
只有在作為獨立比較時,才嘗試較小的模型或量化。這會同時改變資源用量與回答品質。保留幾個具代表性的問題,以便評估較快的選項是否仍然有用。
測試脈絡變更但不使其永久生效
對於簡短的診斷提示,API 接受每次請求的脈絡選項。在前述請求中,於 options 內與 num_predict 並列加入 "num_ctx":4096,並使用支援該脈絡的本地模型。這是範例測試大小,不是所有模型或程式設計工作的建議設定。
保持模型與提示不變,然後用 ollama ps 檢視執行中的模型並比較記憶體壓力。不要縮小大型對話的脈絡後就假設答案仍包含每一項指示。先比較一個能容納的小型任務;之後再用足以容納其輸入的脈絡測試實際工作負載。
常見問題與專門的脈絡長度頁面對預設值的描述不同,因此本指南不依賴通用預設值。應用程式設定、前端或請求層級選項也可能影響執行中的值。若已安裝版本在 ollama ps 中回報 CONTEXT,請將該值與 PROCESSOR 並列記錄,而不是從模型檔案大小推測。
較低的記憶體讀數不是唯一的成功條件。任務仍須以可接受的答案完成,且 Mac 其餘部分必須保持可用。若較小的脈絡遺漏重要事實,或變更沒有可重現的差異,請移除測試選項並還原先前可用的設定。
產生期間觀察整台 Mac
開啟活動監視器 › 記憶體,在產生期間觀察記憶體壓力,而不是只在回應完成後才看。Apple Silicon 使用共享系統記憶體,因此其他應用程式也有影響。模型在磁碟上放得下,並不代表它能在你的其餘工作負載旁舒適地運作。
儲存工作並關閉不必要的繁重任務,然後重複相同請求。如果記憶體壓力改善且變慢情況隨之改變,你就有了有用的線索。記憶體壓力指南說明了如何解讀 Mac 的指標,而不把每個快取位元組都視為浪費。
卸載閒置模型而不刪除它
首先等待任何使用該模型的請求完成。若要釋放不再需要且已載入的模型,請使用 ollama stop,後面接上 ollama ps 中的確切名稱:
ollama stop MODEL_NAME
執行命令前請取代 MODEL_NAME。這會從記憶體卸載模型。它不會刪除已下載的檔案,而下一次請求可能再次付出載入成本。因此,在每次請求之間反覆卸載模型可能讓體驗變慢。
如果實際限制是磁碟空間,請另外參閱AI 模型清理指南檢視已儲存的模型。保留本機建立的模型,以及任何你無法可靠地再次下載的項目。就效能而言,一次只比較一項變更,並讓結果與相同工作負載保持關聯。
搭配伺服器日誌調查不一致
若本地請求仍然緩慢,或處理器分配不如預期,Ollama 的疑難排解指南指出 Mac 伺服器日誌位於 ~/.ollama/logs/server.log。閱讀測試時間附近的內容,尋找載入失敗、記憶體配置問題或所選的執行後端。若伺服器是手動啟動,對應訊息可能在其終端機中。
記錄 Ollama 版本、確切模型標籤、脈絡、處理器分配以及主導計時結果的階段。分享日誌節錄前,請檢查其中是否含有私人提示與本地路徑。不要僅因為某個 GPU 或伺服器環境變數出現在舊的最佳化文章中就更動多個變數;日誌應先指出變更要處理的不一致。