判斷：先排查模型、上下文、記憶體交換與執行緒限制，再決定是否換伺服器。 若低延遲或高併發是硬性要求，單純換成 CPU 伺服器通常不是解法，應評估 GPU 推理或外部模型 API。
適合正在使用 Ollama CPU-only 推理、但回應時間無法接受的開發者：可依序定位設定和負載問題。
也適合自託管 AI 應用或知識庫的小型團隊：可判斷應用、模型與推理服務是否需要拆開部署。
準備從 VPS 遷移的技術負責人，則可先用監控資料確認擴容是否對症。
最後更新於 2026 年 10 月 23 日；版本及操作說明已對照 Ollama 官方發布記錄、Ollama 官方文件與 Docker 資源限制文件。社群討論只反映使用者遇到的問題，不作為效能測試證據。
先判斷 Ollama CPU 推理太慢是正常邊界還是異常
CPU-only 推理不能直接以 GPU 的互動速度作為預期。CPU 需要處理模型運算，權重讀取和記憶體頻寬也會影響生成；提示內容變長時，前處理與上下文相關負擔可能增加。因此，單看「生成很慢」不足以判定伺服器故障，更不足以得出「核心不夠」的結論。
Ollama 官方在 2026 年 6 月 5 日發布的 0.30 更新公告，介紹了透過 llama.cpp 改進效能與 GGUF 相容性；這是版本更新資訊，不代表 CPU 推理有保證，也不能據此認定它是目前最新版本。排查時應以實際使用的版本與 官方發布記錄為準。
純 CPU 模式為何會比預期慢？ 先確認模型是否適合 CPU 使用，再比較固定條件下的輸出時間。如果模型本身過大，或請求包含不必要的長上下文，換一台同樣以 CPU 執行的伺服器未必能消除瓶頸。
開始調整前，先固定模型、提示詞、上下文設定及輸出長度，避免把不同工作負載的測試結果混在一起。每次只改一項，並記下首個輸出出現前的等待時間、完整生成時間、記憶體使用量、swap 狀態和 CPU 使用情形。Ollama 的生成 API 可回傳 load_duration、prompt_eval_duration、eval_duration、prompt_eval_count 及 eval_count 等欄位，能幫助區分載入、提示詞處理和生成階段；欄位說明見 Ollama 生成 API 文件。沒有同硬體的公開測試或本站實測時，不應把估算寫成固定的 tokens/s 數值。
| 觀察到的現象 | 優先檢查 | 下一步 |
|---|---|---|
| 第一次請求特別慢，後續請求改善 | 模型載入時間、磁碟讀取及模型是否仍在記憶體 | 對照 API 的載入時間；分開記錄冷啟動與已載入狀態 |
| 提示內容變長後，等待時間明顯增加 | 上下文設定、提示詞長度及提示詞處理時間 | 用相同模型和輸出設定縮短提示詞再測 |
| 執行期間記憶體吃緊，系統開始使用 swap | 可用記憶體、模型大小、KV cache 與其他服務 | 暫停非必要服務或縮小模型；觀察 swap 是否停止增加 |
| 一個請求尚可，多個請求時排隊 | 同時執行的工作、應用服務和推理是否共用 CPU | 將單請求與併發情境分開復測，評估拆分服務 |
| CPU 使用率高，但生成仍無法接受 | 模型計算負載、可用執行緒、記憶體頻寬和延遲要求 | 先測小模型與較短上下文；低延遲若是硬要求，評估其他推理方案 |
第二步：先減少模型與上下文的負擔
模型檔案大小只是記憶體規劃的起點，不等於執行時的完整需求。模型權重之外，還要預留執行環境、KV cache 及 Ollama 和其他服務所需的記憶體。上下文越長，KV cache 所需空間也可能增加；實際數值取決於模型結構、快取精度與使用的上下文設定，不能只由檔案大小推算。量化格式及模型結構的差異可參考 llama.cpp 的模型文件。
先換小模型，還是先增加記憶體？ 若系統記憶體仍充足、沒有持續使用 swap，而單次推理本身就慢，先用較小模型或適合任務的量化版本測試，通常比直接擴充記憶體更容易驗證效果。若模型載入後可用記憶體不足、swap 活躍，或模型與其他必要服務無法同時留在記憶體中，才把增加記憶體列入候選方案。
可用下列方式粗估權重用量：
權重估算值 ≈ 參數量 × 量化位元數 ÷ 8
以 7B 參數、4-bit 作為純計算示例，權重估算約為 3.5 GB；這是依公式計算的近似值，不是執行時總記憶體，也不代表任何特定模型實測。實際佔用還要加上模型格式資訊、執行開銷與 KV cache。4-bit 數值只是示範估算方式，不是對特定模型品質、許可條款或 CPU 速度的建議；下載前仍要確認模型授權符合用途。
| 調整選項 | 可能適用的情況 | 如何確認調整是否有效 |
|---|---|---|
| 改用較小模型 | CPU 計算負擔過重，任務可接受較小模型能力 | 固定提示詞與輸出長度，對照完整生成時間和答案品質 |
| 選擇合適量化版本 | 權重佔用偏高，且模型有符合需求、授權清楚的量化選項 | 記錄實際記憶體用量，並用相同輸入比較輸出結果 |
| 縮短上下文 | 請求常帶入大量歷史對話或檢索片段 | 減少與任務無關的內容，觀察提示詞處理時間及記憶體變化 |
| 增加可用記憶體 | 載入模型後仍需使用 swap，或必需服務無法與模型共存 | 確認模型與必要服務能否同時載入，並再次檢查 swap |
| 拆開推理與應用服務 | 多個服務爭用資源，單獨推理時表現較穩定 | 分別測單服務與整體工作負載，確認瓶頸是否轉移 |
第三步：檢查記憶體、swap 與模型是否完整載入
較長上下文會拖慢生成嗎？ 可能會，尤其請求帶入大量對話歷史、檢索片段或提示文字時；但不應僅憑上下文較長就判定它是唯一原因。將上下文縮短後，用相同模型、相同輸出設定重測，並比較提示詞處理時間及記憶體使用量，才能看出這項調整是否真正改善了瓶頸。
檢查時把三種問題分開處理：
- 記憶體不足：模型、KV cache 與其他服務需要的空間超過可用記憶體，可能導致載入受阻或系統開始使用 swap。
- 磁碟交換：觀察系統是否持續讀寫 swap。若縮小模型或停止其他服務後 swap 明顯減少，應先處理記憶體壓力，而不是先增加 CPU 核心。
- CPU 計算受限：如果記憶體充足、沒有持續 swap，但 CPU 長時間忙碌，才進一步檢查模型計算量、執行緒和工作負載。
模型載入時間也要和生成時間分開記錄。第一次請求耗時較長，可能包含載入；後續請求變快，並不等於生成本身已符合互動需求。若模型無法留在記憶體中，應先確認是否有其他程序佔用資源，再決定調整模型或部署方式。
第四步：核對 Docker 的 CPU 配額與執行緒
Docker 裡執行緒怎麼檢查？ 先確認容器實際獲得的 CPU 配額、CPU 集合和宿主機可用資源，再檢查容器內的程序是否受到限制。容器能看到的 CPU 資源，不一定等於宿主機全部資源；Docker 文件說明了 CPU 與記憶體限制的行為，應依實際使用的容器設定及 cgroup 版本判讀：Docker 資源限制說明。
可照以下次序核對：
- [ ] 以容器監控資料觀察 CPU、記憶體及限制值，並與宿主機資源使用情形對照。
- [ ] 檢查 Compose 或容器啟動設定是否明確限制 CPU 數量、CPU 集合或記憶體。
- [ ] 確認 Ollama 的執行緒設定沒有超出容器實際可用資源；不要把單一社群案例中的設定值當成通用最佳值。
- [ ] 每次只調整一項資源限制或執行緒設定，再以同一模型及同一測試輸入重跑。
- [ ] 若容器內外的資源資訊不一致，先辨認 cgroup 版本與限制來源，再修改設定；不要只因核心數看起來偏少就直接增加配額。
Ollama 的 Docker 部署說明可用來核對容器啟動方式及相容的設定：Ollama Docker 文件。環境版本或底層推理後端更新後，重新檢查相關配置項，不要假設過往參數在新版本中仍有相同作用。
第五步：拆開單請求、多服務與併發問題
同一台機器上的工作負載可能包括應用平台、向量檢索、Embedding、資料庫及模型推理。單次生成變慢，與多個請求排隊，並不是同一個問題；模型載入慢也不一定能靠增加 CPU 核心解決。
可按負載逐項復測：
- 單請求生成慢：停掉非必要服務，以固定模型和輸入測試；再比較小模型或短上下文。
- 多請求時排隊：單獨測一個請求與實際使用情境，記下等待情況，確認是否因 CPU、記憶體或其他服務爭用造成。
- 載入時間長：分開比較模型載入和生成階段，檢查模型是否反覆載入及磁碟讀取情形。
- 整體服務互相影響：先暫停向量庫、Embedding 或應用服務中的非必要工作，再逐一恢復，觀察瓶頸在哪個組合中出現。
如果只有推理服務單獨運作時表現可接受，但與應用和知識庫同機後明顯惡化，拆分部署可能比把所有服務放到更大的同一台伺服器更容易控制。反過來說，若核心問題是單個模型在 CPU 上無法達到要求的延遲，拆分服務不會把 CPU 推理變成 GPU 推理。
最後一步：用持續測試結果決定是否升級
不要用未經驗證的固定百分比或核心數門檻作為升級標準。先建立基線，再看同一工作負載下的記憶體壓力、swap、CPU 飽和持續時間、請求排隊情形和實際可接受的等待時間。若縮小模型、調整上下文、排除容器限制後，仍持續超出應用能接受的延遲，才評估增加資源、拆分服務或改用其他推理路徑。
| 測試結果 | 優先決策 | 升級前要確認 |
|---|---|---|
| 小模型或短上下文已能滿足任務 | 先保留 CPU-only 方案 | 模型能力、答案品質與實際延遲是否都可接受 |
| swap 持續出現或模型與必要服務無法共存 | 評估更大記憶體或拆分服務 | 是否能避免模型載入後擠壓應用與資料服務 |
| 容器配額限制了可用資源 | 修正容器配置並重新測試 | 宿主機是否有足夠資源，限制是否來自部署設定 |
| 單機 CPU 長時間忙碌，延遲仍不合要求 | 比較 CPU 擴容、外部模型 API 或 GPU 推理 | 增加 CPU 資源是否真的符合延遲與併發目標 |
| 需求是高併發、低延遲或模型訓練 | 不要把 CPU 伺服器當成 GPU 替代品 | 另行評估具備合適 GPU 的方案或 API |
從 VPS 轉移到獨享伺服器是否有幫助，取決於 VPS 的限制是否正好是瓶頸：共享 CPU 配額、記憶體不足或其他租戶造成的資源爭用，可能讓長時間推理更難預測；但換成獨享 CPU 伺服器，仍不會讓模型獲得 GPU 加速，也不能保證符合高併發低延遲要求。若基線測試顯示需要固定的獨享 CPU 與記憶體資源，可先到 SFP Cloud 方案頁核對目前可選規格、計費週期及產品資料，再依實際工作負載決定是否遷移。
較合適的做法，是先保留測試紀錄：模型與量化版本、上下文設定、容器資源限制、記憶體與 swap 使用情形，以及每次測試的等待時間。若結果證明目前方案受共享資源或記憶體容量限制，且工作負載適合 CPU，獨享 AMD 伺服器才值得納入比較；SFP Cloud 下單頁可供核對可選方案。若真正需求是 GPU 推理、模型訓練或高併發低延遲，則應改評估 GPU 方案或外部模型 API，而不是單靠更換 CPU 伺服器。