2026 年 2 月中，OpenAI 依照 model release notes 的時程，把 GPT-4o 與其他舊模型送進退役名單。對 ChatGPT 的一般使用者來說，這多半是一次無感的背景更新；但對把 model ID 寫死在程式碼、eval 流程與成本假設裡的 API 開發者來說，這是每次都必須認真以待的工程事件。
真正值得注意的不是哪一個模型退場，而是頻率。攤開兩家主要供應商的 release notes，近期的迭代節奏一目了然：
- OpenAI：GPT-5.2 base（2025 年 12 月 11 日）→ GPT-5.2-Codex（2026 年 1 月 14 日）→ GPT-5.3-Codex（2026 年 2 月 5 日）
- Anthropic：Claude Opus 4.6（2 月 5 日）→ Claude Sonnet 4.6（2 月 17 日），發布即成為免費與 Pro 用戶的預設 model
生命週期比專案時程還短
把上面的日期連起來看：OpenAI 在不到兩個月內推出三個 GPT-5 系列版本，Anthropic 光是二月就上了兩個主力新型號。多數產品團隊的開發週期是一季，這意味著專案啟動時選定的模型，很可能在功能上線之前，就已進入退役觀察名單。
模型退役不像伺服器汰換那樣「先變慢、再停機」。它是一個明確的截止日：release notes 公告之後，寫死的 model ID 總有一天直接失效，而且失效的是整個 API 呼叫，不是某個功能。
真正會壞掉的三個地方
工程上，模型汰換的風險通常集中在三處：
- 寫死的 model ID：退役當天開始收到錯誤，而不是效能漸進退化那種可以觀察的警訊
- 針對舊型號調校的 prompt：新型號行為不同，輸出品質會悄悄漂移，問題往往在用戶抱怨之後才被發現
- eval 與成本模型：token 用量與計價結構隨型號改變，原本算好的單位成本會失準
三道務實防線
面對只會更快、不會更慢的迭代節奏，與其預測哪個模型撐得久，不如把生命週期管理做進架構：
- pin 明確版本：在設定與程式碼中固定完整型號名稱，別讓 alias 替你決定升級時程
- 抽象 model routing：把供應商與型號選擇收斂到一層可設定的 routing，讓換模型是改組態，不是改 code
- 例行遷移：訂閱 release notes、先在 staging 驗證新模型、分階段切流量，把升級變成每季的例行工作，而不是生產事故後的搶救
模型汰換加快不是供應商惡意，而是這個產業目前的競爭方式。差別在於：把生命週期管理當成一等工程問題的團隊，會讓退役日變成行事曆上的一個格子；沒有處理的團隊，則會在某個二月的中旬收到生產環境的錯誤通知。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。