摘要： OpenAI 在 2026 年 2 月中依既有時程讓 GPT-4o 等舊模型除役，對 API 開發者而言這是會影響呼叫、評測與成本假設的工程事件。文章建議明確 pin 版本、把 model routing 收斂到可設定層，並用 staging 驗證與分批切換讓遷移例行化。
OpenAI 在 2026 年 2 月中，照著 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 在 2 月 5 日推出 Claude Opus 4.6，2 月 17 日再上 Claude Sonnet 4.6，新模型一登場就是免費與 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 驗證新模型、流量分批切換，讓升級成為每季照表操課的固定事項，而非生產事故後的緊急搶修
汰換加速不代表供應商存心刁難，它就是這個產業眼下的競爭樣貌。真正的分野在流程：把生命週期管理視為頭等工程議題的團隊，退役日只是行事曆裡尋常的一格待辦；沒有安排的團隊，則會挑在某年二月中旬，從生產環境的錯誤通知得知這件事。
資料來源
在 X 上查看原貼文