完整程式碼可在 GitHub 專案中找到：Finetune-30-days-demo / day-15

在 Day 14，我們談到測試與錯誤處理，確保系統能在錯誤時正確回報。
但光能「報錯」還不夠，如果系統長期跑下去，還會遇到另一個常見的隱憂：Checkpoint 爆炸。

每次訓練，我們都會保存模型中間狀態（checkpoint），這對於後續分析或中斷恢復非常重要。問題在於：如果不加管理，幾十次實驗後，硬碟會被這些檔案塞滿，導致整個平台無法再跑新的任務。

因此，Day 15 的重點就是建立 Checkpoint 管理機制，讓實驗能長時間穩定運作。

一、為什麼要管理 Checkpoint

1. 硬碟空間有限

   • 每個 checkpoint 動輒數百 MB 到數 GB。
   • 幾十次實驗下來，TB 級別的硬碟也撐不住。

2. 研究習慣

   • 大部分實驗其實只需要「最佳模型」與「最後一個 checkpoint」。
   • 其餘中間檔案幾乎不會再被用到。

3. 平台穩定性

   • 沒有清理策略時，worker 可能因為寫檔失敗直接 crash。
   • 對團隊協作來說，更容易造成資源爭奪與混亂。

二、Checkpoint 保留策略

我為系統設計了一個簡單卻有效的規則：

• 保留最近的 3 個 checkpoint：確保能回溯或恢復。
• 保留最佳準確率的 checkpoint：確保不會錯過實驗最好的成果。
• 保留最後一個 checkpoint：用來恢復中斷的實驗。

清理時機則設計在 每次保存新 checkpoint 後自動觸發，由系統分析 trainer_state.json 或對應的 metrics，選出該留的檔案，刪掉其餘的。

三、實際效果

在測試時，我跑了一個共產生 20 個 checkpoint 的實驗：

• 清理前：占用 12 GB
• 清理後：只保留 4 個檔案，占用降到 2.3 GB
• 節省空間比例：超過 80%

更重要的是，對實驗流程沒有影響：我仍然可以快速拿到最佳模型、恢復最後一次進度，或追蹤最近的結果。

Day 15 的核心價值不在於複雜的演算法，而是讓系統具備 長期穩定運行的基礎。
如果說 Day 14 的測試與錯誤處理是保障「不會被錯誤擊垮」，那麼 Day 15 的 Checkpoint 管理則是避免「自己把自己撐爆」。

有了這套清理規則，平台不會因為幾十次實驗就硬碟滿載，而是能持續支撐更多任務。接下來，我們就能把重心放在 版本管理（Day 16），讓模型的演進過程被更好地追蹤與治理。

📎 AI 協作記錄：今日開發指令

請幫我實作以下功能：

1. **Celery 錯誤回復**：
   - 修改 `train_model` 任務
   - 使用 `autoretry_for` + `retry_backoff`
   - 捕捉 OOMError 與 SoftTimeLimitExceeded
   - 最多重試 3 次

2. **FastAPI 全域錯誤處理**：
   - 新增 middleware
   - 捕捉 OOMError 與 Exception
   - 統一回傳 JSON 格式：
     { "error": "ErrorType", "message": "錯誤訊息" }

3. **Checkpoint 管理**：
   - 新增 script `cleanup_checkpoints.py`
   - 設定最多保留 3 個 checkpoint
   - 自動刪除舊的 checkpoint
   - 排序方式：依照檔案建立時間

請確保程式碼結構清晰，支援未來擴展（例如不同錯誤類型或不同清理策略）。