DeepSeek API 遷移指南：切換至 V4.1 Flash

如果你的程式還在傳送 deepseek-v4-flash，請求成功已不代表它仍使用最初的 V4 Flash。當前官方文件說明，這個相容名稱會路由至 V4.1 Flash。新接入應明確使用 deepseek-flash。

本文按 2026 年 9 月 23 日的官方資料更新遷移路徑，面向維護指令碼、後端服務或 Agent 接入的開發者。網頁版聊天記錄遷移是另一件事：複製歷史對話，不會改變程式中使用的 API 模型和引數。

先弄清每個模型名現在指向哪裡

設定中的名稱	當前官方說明	建議動作
`deepseek-flash`	V4.1 Flash	新專案採用此名稱
`deepseek-v4-flash`	相容路由至 V4.1 Flash	更新維護中的設定與示例
`deepseek-v4-flash-vision-exp`	相容路由至 V4.1 Flash	圖片請求遷往 `deepseek-flash`
`deepseek-v4-pro`	V4 Pro 繼續提供服務	先評估現有任務，再決定是否切換
`deepseek-chat`、`deepseek-reasoner`	官方曾公告於 2026 年 7 月 24 日停止提供這兩個名稱	不依賴可能殘留的相容行為，遷移到當前模型與引數

舊的 chat、reasoner 名稱不應繼續承擔“切換思考模式”的設定職責。新程式碼應分別宣告模型與思考設定。檢查範圍也要包含定時任務和後臺佇列：互動頁面改了模型，不代表另一個服務裡複製的舊設定已經同步。

模型名之外，還要核對服務商和請求格式

先記下 base URL、模型名、協議，以及程式實際讀取的響應欄位。第三方閘道器可能有自己的模型別名、價格和限制；上表描述的是 DeepSeek 官方服務。

例如，環境變數裡寫著 MODEL=deepseek-v4-flash，還不足以判斷請求最終發到了哪裡。需要繼續看地址，以及把業務訊息轉換成 API 請求的適配程式碼。有些介面卡會丟掉欄位，或設定比模型上限更小的輸出預算。

第一次遷移檢查先保留原來的提供商和提示詞，只調整需要核對的模型及引數。把提供商、協議、模型和提示詞同時換掉，一旦結果變差，就很難定位原因。

Start using deepseek-v4

先發一個答案明確的小請求

下面的 Python 示例使用相容客戶端訪問官方 Chat Completions 介面。測試環境需要安裝 openai 包，並透過平時使用的金鑰管理方式提供 DEEPSEEK_API_KEY，不要把真實金鑰寫進程式碼、瀏覽器端或請求日誌。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-flash",
    messages=[{
        "role": "user",
        "content": "Extract the order ID from: Order A-104 is ready. Return only the ID.",
    }],
    max_tokens=128,
    extra_body={"thinking": {"type": "disabled"}},
)

print(response.choices[0].message.content)
print(response.usage)

預期內容是 A-104。這個任務用於檢查認證、路由、響應解析和用量記錄，不需要複雜上下文。示例依據文件編寫，本文沒有把它描述為已經進行過真實 API 呼叫的測試記錄。

128 token 適用於這裡非常短的非思考任務，不是推理和 Agent 工作的通用預算。恢復業務輸入時，要為實際輸出留足空間，並檢查結束原因，避免把截斷結果當作完整答案。

引數被接受，不代表引數生效

思考模式文件說明，當前預設開啟思考，預設強度為 high。透過上述 Python 客戶端呼叫 Chat Completions 時，thinking 應放入 extra_body；強度可用 low、high 或 max。

需要測試思考模式時，可把相應引數改為：

reasoning_effort="high",
extra_body={"thinking": {"type": "enabled"}},

不要把 HTTP 成功響應當作所有采樣設定生效的證據。官方說明，在思考模式下，temperature 可以因相容需要被接受，但不會生效。如果舊測試依賴溫度控制輸出變化，比較前應先記錄這一差別。

工具呼叫還有一處容易漏掉的細節：對攜帶 tools 的 Chat Completions 請求，文件要求後續請求回傳歷史 reasoning_content，包括沒有執行工具呼叫的輪次。如果介面卡只儲存助手的最終文字，第一輪可能正常，後面的工具會話卻可能失敗。因此至少要檢查一段“請求—工具結果—繼續回答”的完整歷史，而不只是單輪請求。

迴歸樣例應包含容易失敗的輸入

從已有答案的任務開始：一個缺欄位的提取任務、一個必須符合 Schema 的輸出、一段答案位於末尾的長輸入，以及一次接收工具結果後的續聊。業務使用圖片時，再加入圖片樣例。

先看輸出是否能使用，再測速度。看起來像 JSON，仍要經過解析和結構校驗；程式碼修改仍要跑對應測試；引用的數字仍要能在原文中找到。把錯誤分成格式不符、事實錯誤、工具歷史錯誤和服務錯誤，之後才容易確定修復方向。

用量應按完成整個任務計算，包含重試。分別記錄輸入、輸出和快取用量。單價下降不保證任務總價一定下降，因為新行為可能生成更長的答案，或觸發更多重試。第一輪比較固定提示詞與顯式引數，提示詞最佳化可以留到下一輪。

Pro 的繼續服務與 Flash 的回退，是兩件事

9 月 10 日的發布稿曾計劃將 Pro 請求路由至 Flash；當前日誌則明確說明，9 月 14 日後 Pro 繼續服務，計費方式不變。因此，不必僅因為讀到舊的停服計劃，就立即遷移一個執行正常的 Pro 應用。

Flash 的回退方案更需要寫清楚：把設定改回 deepseek-v4-flash，不能恢復已經退役的舊模型，因為這個名字現在指向新模型。回退目標必須是實際仍可用的服務，而且能力適合當前任務。Pro 當前官方 API 不支援視覺，所以不能直接承擔圖片請求的備用路由。

先讓少量流量走新設定，並設定明確的停止條件。透過業務檢查後，再同步內部示例與維護文件，避免下一次接入又複製回舊模型名。遷移記錄應儲存提供商、日期、引數和驗收結果，而不只是寫一句“介面已通”。