如果你在程式碼裡還寫著 deepseek-chat 或 deepseek-reasoner，日曆上只剩 5 天——DeepSeek 官方文件寫得很硬：兩個舊模型 ID 將在 2026 年 7 月 24 日 15:59 UTC 之後「fully retired and inaccessible」，不是警告標頭、不是自動轉址，而是直接報錯。對照 Gemini 3.5 Pro 一再跳票 這種「可能永遠不來」的不確定性，DeepSeek 給的是極少數「日期寫死」的基礎設施事件：過了時間點，生產環境就斷。
好消息是遷移本身常被形容為「一行改 model 字串」；壞消息是有兩個坑，足以讓以為自己已遷移的團隊在 7 月 24 日深夜才發現帳單或能力不對。
官方映射：同一個 Flash，兩種模式
自 2026 年 4 月 24 日 V4 Preview 起，舊名稱其實已是別名——多數請求早已在 V4-Flash 上跑，只是 ID 還叫舊名。7 月 24 日後別名消失：
| 舊名稱（7/24 後失效） | 新名稱 | 模式 |
|---|---|---|
deepseek-chat | deepseek-v4-flash | thinking 關閉 |
deepseek-reasoner | deepseek-v4-flash | thinking 開啟 |
| （新選項） | deepseek-v4-pro | 旗艦雙模式 |
不變的：base_url 仍為 https://api.deepseek.com、API 金鑰、OpenAI ChatCompletions 相容格式（亦支援 Anthropic Messages 介面）。
V4-Flash 規格（官方）：約 284B 總參數、13B 活躍、1M 上下文。V4-Pro：1.6T 總參數、49B 活躍——若你過去用 deepseek-reasoner 做重型推理，只把字串改成 v4-flash 不等於能力對位 Pro。
陷阱一：thinking 從「模型名」變成「請求參數」
這是遷移裡最容易漏的一項。deepseek-reasoner 時代，選模型名就開啟推理；現在要在 body 裡顯式設定。
非思考（原 chat 流量）示例：
client.chat.completions.create(
model='deepseek-v4-flash',
messages=[{'role': 'user', 'content': '...'}],
extra_body={'thinking': {'type': 'disabled'}},
)
思考（原 reasoner 流量）示例：
client.chat.completions.create(
model='deepseek-v4-flash',
messages=[{'role': 'user', 'content': '...'}],
extra_body={'thinking': {'type': 'enabled'}},
)
若原 deepseek-chat 流量沒關 thinking，可能每請求多付推理 Token——四月以來輸出飄移、帳單變貴，有時就是路由已在 Flash 但模式未鎖定。
陷阱二：reasoner 用戶的「隱性降級」
官方映射表寫得很清楚：deepseek-reasoner → v4-flash + thinking，不是 v4-pro。重度數學、長鏈代理或複雜程式任務，應在遷移時顯式評估是否改呼叫 deepseek-v4-pro，並重跑 eval——別在 7 月 24 日後才從錯誤率發現能力缺口。
定價：遷移後通常更便宜
V4 定價（官方定價頁，以站為準）讓遷移有經濟誘因：
| 模型 | 輸入／百萬 Token | 輸出／百萬 Token |
|---|---|---|
| deepseek-v4-flash | 約 $0.14 起（依快取） | 低於西方旗艦一個數量級 |
| deepseek-v4-pro | 高於 Flash | 仍遠低於 GPT-5.6 Sol／Fable 5 |
對比 Kimi K3 的 3/15 美元 或 GPT-5.6 Sol 的 5/30，DeepSeek 仍占「高量 推理 最便宜 API」生態位——但前提是模型字串與 thinking 參數都改對。
實務遷移清單（7 月 19 日版）
- 全庫 grep：
deepseek-chat、deepseek-reasoner（含設定檔、K8s ConfigMap、CI 環境變數）。 - 分流量標記：chat 路徑加
thinking: disabled；reasoner 路徑加enabled或升級 Pro。 - 並行 shadow：對關鍵路徑用 v4-flash／v4-pro 跑一週回歸，比對延遲、JSON 模式、工具呼叫。
- 記時區：15:59 UTC 約為北京 23:59、台北同；若需工作日發布，實際截止日是 7 月 23 日下班前。
- 監控：7 月 24 日後對舊 ID 設 alert，捕捉漏網之魚。
為什麼這件事比新模型發布更「安靜」
它不會上頭條，但會在排程任務、客服 bot、內部 RAG 管線裡同時爆紅燈——這類變更屬於「日曆炸彈」，與 法國監管 AI 代理集中度 或 WAICA 學術會 的敘事戰不同，卻直接決定多少產品在 7 月 25 日還能不能說話。
與七月其他「硬日期」對照
同一個七月，開發者同時面對多個不可延期的節點：
| 事件 | 日期 | 性質 |
|---|---|---|
| Gemini 3.5 Pro 傳聞 GA | 已過 7/17，仍未 GA | 不確定、可無限滑 |
| Kimi K3 權重釋出 | 7/27 | 承諾發布，可驗證 |
| DeepSeek 舊 ID 下線 | 7/24 15:59 UTC | 硬截止、無 fallback |
這張表說明：當旗艦閉源模型還在重建預訓練時，基礎設施級 API 變更反而最不容忽視——因為它不等你準備好。
Anthropic 相容介面與 JSON 模式
官方文件指 V4 同時支援 OpenAI ChatCompletions 與 Anthropic Messages API；若你的管線用後者，遷移時除 model 字串外，還要確認 thinking／reasoning_effort 在該 SDK 的映射。JSON mode、function calling、streaming 在 V4 上大多延續 V3 行為，但仍建議對結構化輸出路徑做回歸——四月以來「感覺變聰明／變囉嗦」的團隊，有時只是 thinking 預設不同。
自架與合規團隊
V4 權重在 MIT 等開放條款下提供（以官方 repo 為準），與本次 API 別名下線是兩條線：託管 API 用戶只關心 model 字串；自架用戶要同步追蹤 checkpoint 版本與量化格式（如 NVFP4）。若合規要求資料不出境，7 月 24 日前就應完成從舊別名到明確 v4-flash／v4-pro 的配置審計，避免維運腳本在截止後批次失敗。
常見故障模式（截止日前預演）
維運社群整理的「7 月 24 日後第一週」高頻錯誤，多半不是 API 掛了，而是配置沒改乾淨：
| 症狀 | 可能原因 | 處理 |
|---|---|---|
| HTTP 4xx，model not found | 環境變數仍指向舊 ID | grep 全 repo + CI secret |
| 帳單突然翻倍 | chat 流量未 thinking: disabled | 鎖定非推理路徑參數 |
| 推理品質斷崖 | reasoner 只換名未升級 Pro | 評估 deepseek-v4-pro |
| 夜間批次全失敗 | cron 用舊 Docker 映像 | 重建映像並打 tag |
建議在 staging 故意保留一條舊 ID 請求做「負向測試」，確認監控會在 7 月 25 日抓到——比生產爆雷便宜得多。
DeepSeek 四月就給了三個月窗口；若你讀到這裡還沒 grep，現在就做——5 天後沒有 grace period。