AI 系統最危險的時刻，往往不是模型無法回答，而是每個程式都「看起來還能跑」，直到整台電腦突然失去回應。
這起 macOS 記憶體耗盡事故揭示：穩定性不是換一台更大的機器，而是辨識疊加效應、設置資源熔斷，並讓系統知道何時該停止。
▋ Belief：事故通常不是單一程式造成，而是多個合理用量同時疊加
遇到電腦卡頓、記憶體壓力升高或應用程式被系統終止時，人們很容易把責任歸給最後開啟的那個軟體。但這次事故顯示，真正的根因不是「所有軟體同時壞掉」，而是 Effie 的異常記憶體成長、夜間 26B 本地模型排程，以及既有桌面程式的常駐基線同時發生。
[VERIFIED_SRC] 系統紀錄顯示，Python／OMLX 曾使用約 6.5GB；凌晨 01:40 載入 gemma4:26b-mlx 後，Ollama 用量由約 16.3GB 增至 20.6GB。另一方面，Effie 7.0.6 啟動不到一小時，實體 footprint 已達 13.3GB，而 vmmap 顯示其 MALLOC 配置達 25.1GB，其中 12.7GB 已換出。
系統不是被最後一根稻草擊倒；它是長期沒有量測每一根稻草。
macOS 面對記憶體不足時，會先壓縮記憶體，再把部分內容換頁到磁碟。這就像辦公桌塞滿後，先把文件壓進收納袋，再把更多箱子搬到倉庫；短時間內工作還能繼續，但每次取用都變慢，最後系統只能透過 Jetsam 終止部分程序來自保。
因此，單看「還有沒有空閒記憶體」不夠。還要一起觀察記憶體壓力、壓縮量、Swap、單一程序的成長速度，以及排程是否在使用者不注意時載入大型模型。真正可靠的根因分析，必須把時間線、程序、模型大小與常駐基線放在同一張圖上。
事故中的三層根因
- 異常成長：Effie 出現明顯記憶體洩漏跡象，歷史 Jetsam 紀錄最高甚至達 75.6GB。
- 排程尖峰：每日凌晨的 Wiki 編譯載入 16GB 級模型，使 Ollama 在短時間內持續擴張。
- 常駐基線：OMLX 預載 Qwen 9B 約占 5.8GB，再加上編輯器、知識工具與語言伺服器，系統在排程開始前就沒有太多緩衝。
▋ Desire：真正需要的不是「永不出錯」，而是可預測地降級
個人工作站與中小企業內部伺服器的共同限制，是資源有限、維運人力有限，而且同一台機器常同時承擔創作、辦公與 AI 推論。理想目標不該是每個任務永遠完成，而是重要資料不被破壞、使用者白天仍可工作，以及資源不足時系統會安全跳過。
這種設計稱為優雅降級。大型模型無法安全載入時，改用較小模型；記憶體指標無法讀取時，不冒險執行；輸出格式不合格時，不寫入正式知識庫。系統的成熟，不是它多勇敢地硬撐，而是它多清楚地知道自己的停止條件。
修復結果提供了什麼證據？
[VERIFIED_SRC] 修復後，Wiki 預設模型由 16GB 的 26B 模型改為 688MB 的 minicpm5-1b:latest，批次量由 5 降為 1，並加入至少 8GB 可回收記憶體及壓力等級不得高於 1 的執行前熔斷。記憶體壓力由 2 降至 1，壓縮記憶體由約 16GB 降至 3.4GB，未使用記憶體由約 91MB 回升至 9GB。
這組數字說明，最有效的處理不是只關掉一個程式，而是同時降低尖峰、縮小批次、移除不必要的常駐負荷，並在入口處阻止不安全任務啟動。Effie 已正常退出，但在版本修正前仍不適合長時間常駐；Swap 也不會立刻縮小，通常要由系統逐步管理，重新開機後才可能完全歸零。
成本面也要誠實評估。較小模型節省記憶體與等待時間，讓既有硬體可以繼續使用；代價則是 1B 模型的內容品質通常低於 26B 模型。這不是單純的效能勝利，而是一筆交換：以較低生成品質換取可用性，再用結構驗證與拒絕寫入來保護知識庫。
▋ Intention：建立五道資源治理防線
1，建立資源基線：選擇一般工作日與排程執行時段，記錄記憶體壓力、Swap、主要常駐程序與模型用量。沒有基線，就無法分辨某個 6GB 程序是正常負載，還是正在失控成長。
2，盤點尖峰疊加：把所有夜間任務依開始時間、模型、批次量與預估記憶體列出。不要只審查單一排程是否能成功，而要檢查它是否會撞上備份、索引、同步或另一個模型服務。
3，加入執行前熔斷：在載入模型前先讀取可回收記憶體與壓力等級；任一指標不足或讀取失敗，就記錄原因並跳過。對無人值守任務而言，「今晚沒有產出」通常比「半夜拖垮整台機器」更便宜。
4，設計品質閘門：小模型輸出必須先經過 Wiki 結構、必要欄位與繁體中文檢查，格式不合格就拒絕寫入。這能把效能降級與資料品質隔離，避免省下記憶體，卻把錯誤內容永久寫進知識資產。
5，保留復原與告警：清楚記錄哪個程序被停止、哪個模型被替換、何時可以重試，以及誰需要收到通知。告警必須包含時間、資源數字與停止原因，不能只丟出一句「任務失敗」。
每月一次的韌性演練
- 模擬可用記憶體低於門檻，確認排程真的跳過且不載入模型。
- 提供一份格式錯誤的測試輸出，確認知識庫拒絕寫入。
- 檢查長時間常駐程式的 footprint 是否持續成長，而非只看當下快照。
- 確認排程所用模型、批次量與文件說明一致，避免設定悄悄漂移。
- 比較小模型節省的資源，是否足以抵銷人工抽查與重跑成本。
一套值得信任的 AI 系統，不該把「成功完成任務」放在所有事情之前。更高的優先順序是保護資料、維持工作站可用、留下可查證紀錄，並在條件不安全時主動停止。
如果你的 Mac、工作站或企業 AI 排程經常在夜間變慢、記憶體暴增，或只能靠重新開機恢復，問題很可能已經超過單一工具設定。歡迎與蔡教練聊聊您的數位轉型需求，從資源基線、排程治理與品質閘門開始建立真正有韌性的 AI 工作系統。
