文章目錄
▌ 這篇文章在講什麼
我花了整個上午，讓 AI 助理幫我 debug 一個本地 LLM 效能異常。六輪下來沒解決，最後靠一個三字參數位置錯誤找到根因。這是那次事件的完整記錄——以及我從中整理出來的 Debug SOP。
現象：200 字的文件，為什麼要跑 30 分鐘？
測試場景很單純：6 筆文件，每筆約 200–300 字，交給本地模型做結構化評分。正常情況下，這種規模的任務應該在幾分鐘內完成。
實際結果是：每筆 140–150 秒，6 筆合計接近 30 分鐘。
硬體監控數字正常，GPU 在線，模型已載入顯存。從表面看，系統沒有任何問題。
六輪 Debug，每輪都沒打到點
我請 AI 助理協助排查。接下來發生了一段很典型的「AI 時代 Debug 迴圈」：
加入串流顯示
開啟 streaming 看推理過程，確認模型在思考但速度正常
調整 API 參數
加入 /no_think、format=json、num_predict 限制——速度沒有改善
重構雙模式
建立 fast / debug 切換機制，但 think 參數寫死在錯誤位置，實際仍在背景全速推理
多模型會診
同時詢問三個 AI，搭配硬體監控數據交叉驗證，才找到真正的瓶頸層
單一參數修正
將 think=False 移至 API top-level，單筆從 140 秒降至 11 秒
Root Causes：三個錯誤，一個比一個隱蔽
RC-1｜Silent Misconfiguration（隱性失效參數）
think=False 必須是 API 的 top-level 參數，放進 options dict 不會報錯，但完全無效。
❌ 錯誤寫法
options={"think": False}
✅ 正確寫法
ollama.chat(..., think=False)
影響：decode tokens 從 6 暴增至 2048，耗時放大 20 倍。
RC-2｜Pipeline Stall + Observability Trap（管線阻塞與觀測誤導）
stream=True 加上逐 token flush，讓 GPU 每產生一個 token 就要等 Python I/O。
最危險的是：監控畫面顯示 tok/s 正常、GPU VRAM 正常，但 GPU LOAD 接近 0%。三個指標同時出現才能確診是 Pipeline Stall。
RC-3｜未建立 Baseline（缺乏性能基準）
每次優化都直接跑六筆批次驗證，每輪等待 20–30 分鐘。如果一開始先跑一筆最小測試建立基準，整個 debug 過程可以從六七輪壓縮到兩輪以內。
修正結果
| 指標 | 優化前 | 優化後 |
|---|---|---|
| 單筆耗時 | 140 秒 | 11 秒 |
| 批次耗時（6筆） | 30 分鐘 | 3 分鐘 |
| 加速倍數 | — | 12.7 倍 |
整理出來的 Debug SOP
這次事件結束後，我把流程整理成一份跨專案通用的 SOP，核心是五個步驟：
先建立單筆最小基準——用最簡單的輸入跑一次，記錄 prefill / decode / tok/s，這是所有後續比較的起點。
每次只改一個變數——改完立刻跑單筆測試，確認有效再進行下一個，禁止同時調多個參數。
查 API 文件，不假設參數行為——AI 給的建議需要驗證，參數的正確位置以官方文件為準。
讀取 response 內部計時——prefill / decode / eval_count 三個數字是診斷的核心，不是看表面耗時。
判斷瓶頸所在層級——模型層、GPU 層、Pipeline 層、架構層，方向不對則優化完全無效。
▌ 這次事件最大的啟示
在 AI 輔助開發的時代，開發者的核心能力正在轉移：從「會寫程式」變成「能驗證 AI 給的答案是否正確」。
這次六輪繞圈的代價，換來一份通用 SOP 和一本踩雷清單。這是 AI 工具幫不了你的部分——判斷力，還是要靠自己走過。
Mr. τ｜風雲網通系統
專業 IT 系統整合顧問 · 20 年 SMB 基礎設施經驗 · 協助企業建立可落地的 AI 知識系統
Comments