DeepSeek API 無法使用？修正驗證、計費與速率限制錯誤
作者：Nicho
當 DeepSeek API 請求失敗時，請先從收到請求的服務著手。官方 DeepSeek Key、閘道 Key 和程式訂閱彼此不能互換。相同的 HTTP 狀態在不同服務上也可能代表不同意思。
最快且有用的診斷會結合四項事實：目的地主機名稱、模型識別碼、HTTP 狀態，以及回應的錯誤訊息。請先記錄這些資訊，再變更設定。本指南涵蓋設定與請求失敗，使用 2026 年 10 月 26 日查核過的文件。這不是即時中斷報告，也不是聲稱某個特定服務目前無法使用。
如果問題是 402 錯誤或儲值失敗，請參閱 DeepSeek API 付款，了解儲值、退款與餘額如何運作。
1. 確認你呼叫的是哪個 API
請將供應商、Key 簽發者、端點格式和模型 ID 視為同一組設定。混用不同範例的部分內容，會產生看起來像模型問題的失敗。
| 路由 | OpenAI 格式 Base URL | Flash 模型識別碼 |
|---|---|---|
| DeepSeek 直連 | https://api.deepseek.com | deepseek-flash |
| cheapaimodel | https://api.cheapaimodel.ai/v1 | deepseek-v4-1-flash |
這些識別碼來自 DeepSeek 快速開始以及 cheapaimodel 上的 DeepSeek V4.1 Flash 模型頁面。它們描述的是不同的存取路由，並不代表後端行為完全相同。DeepSeek 也記錄了 Anthropic 格式的端點；請勿將該位址貼到預期使用 OpenAI 請求格式的用戶端。
請檢查你的應用程式實際使用的設定，而不只是你編輯過的檔案。部署環境變數、另一個專案設定檔，或較舊的處理程序，都可能覆寫預期的值。請僅依應用程式的需求重新啟動或重新部署，然後檢查其生效的供應商與模型設定，且不要印出密鑰。
2. 一起解讀狀態與訊息
對於 DeepSeek 直連 API，官方錯誤參考記錄了以下類別：
| 狀態 | 直連 API 意義 | 先檢查 |
|---|---|---|
| 400 | 請求格式錯誤 | 主體結構與 JSON 格式 |
| 401 | 驗證失敗 | Key 與目的地 |
| 402 | 餘額不足 | 直連帳號餘額 |
| 422 | 參數無效 | 名稱、型別與支援的值 |
| 429 | 速率或並行限制 | 請求節奏與進行中的工作 |
| 500 | 伺服器錯誤 | 有界重試，接著調查是否持續發生 |
| 503 | 伺服器過載 | 等待後再進行有界重試 |
這張表不是通用的閘道錯誤字典。例如，cheapaimodel 的計費常見問題指出，預付餘額用完時會回傳 403。請閱讀該閘道的回應，而不是把每個 403 都解讀成密碼錯誤，或把每個餘額問題都當成 DeepSeek 的 402。
3. 將驗證與帳號存取分開
若發生驗證失敗，請檢查該 Key 是否由端點的供應商簽發，且仍在使用中。留意前後是否意外多了空格、缺少環境變數，或變數名稱在本機與部署環境之間有所不同。
請勿在螢幕截圖或日誌中揭露 Key 來證明它存在。請改為記錄非機密的 Key 標籤或設定變數的名稱。如果憑證已外洩，請先依照供應商的撤銷與更換流程處理，再繼續操作。
若遇到餘額或存取錯誤，請開啟被呼叫路由所屬的帳號。儲值一個供應商並不會為另一個供應商提供資金。請檢查任何適用的 Key 層級限制，以及帳號餘額。cheapaimodel 提供各 Key 的預算、到期、模型允許清單與 IP 允許清單等文件；限制本身值得單獨調查，而不是自動儲值。
當回應指出 Key 無效、請求參數有誤或目的地錯誤時，請避免把購買更多額度當成第一個除錯動作。
4. 將請求縮減為最小案例
如果驗證成功但請求遭到拒絕，請暫時移除應用程式的複雜度。從所選供應商目前文件中的範例開始，使用簡短、非機密的文字提示與支援的模型。在基本路徑可用之前，先略過工具、圖片、自訂回應格式、選用的推理設定與冗長的對話歷史。
接著一次加入一項功能。如果單純的請求成功，而啟用工具的請求失敗，兩者的差異比反覆重新傳送完整的正式環境承載內容更有參考價值。
請檢查以下常見的不相符來源：
- 模型值是行銷顯示名稱，而非 API 識別碼。
- SDK 附加了已包含在你設定 URL 中的路徑。
- 複製的參數屬於另一個供應商或端點格式。
- 欄位型別錯誤，例如應為數字或物件卻使用字串。
- 請求的上下文或輸出超過適用的模型或路由限制。
請利用錯誤回應與目前的供應商文件，判斷適用哪一種情況。永久移除所有選項，並不能取代理解哪一項必要功能不相容。
5. 在加入重試之前先診斷 429 錯誤
DeepSeek 的速率限制文件將並行定義在帳號層級。請求會持續作用，直到其回應完成，而在同一帳號中使用另一個 Key 並不會產生獨立的額度。
這表示當請求耗時變長時，工作負載可能受到限制，即使每秒開始的請求數並未改變。請檢查作用中的請求、佇列大小、完成時間，以及是否有數個應用程式工作程序共用同一個帳號。
請減少平行工作、套用有上限且帶有抖動的延遲，並在服務提供重試延遲時遵守該延遲。同時限制嘗試次數與總等待時間。確保只有一層負責重試：SDK 重試迴圈乘以應用程式重試迴圈，可能使超載更加嚴重。
請勿反覆重試無效的憑證或格式錯誤的請求。那些需要的是設定變更，而不是更多流量。
6. 將逾時視為不確定的結果
用戶端逾時並不代表伺服器從未處理該請求。在重複執行昂貴的工作之前，請先檢查任何可用的請求紀錄或用量日誌。回應可能是在你的用戶端停止等待之後才產生的。
串流失敗也需要類似的謹慎處理。記錄連線是否開啟、是否有任何事件送達，以及你的用戶端是否看到預期的完成訊號。部分顯示的答案並不自動等於成功且完整的回應。
如果模型會驅動外部動作，請將這些動作與重試生成分開處理。應用程式不應只因為遺失了最終回應，就重複執行付款、通知或其他副作用。
7. 以安全的重現方式向上呈報
如果問題持續存在，請為供應商準備一份簡潔的報告：UTC 時間戳記、端點主機名稱、model ID、狀態、經過清理的錯誤訊息、請求識別碼（若有）、SDK 版本，以及不含私人資料的最小可重現 payload。
說明它是持續失敗、只在並行時失敗，還是只在某項功能上失敗。包含失敗之前所做的變更。切勿只為了讓報告更完整就附上原始授權標頭或客戶提示。
一旦請求可以正常運作，請逐步回到你實際的工作負載，並檢查其計費用量。我們的 DeepSeek 定價指南 說明了各項費用類別；開發人員文件 則是閘道特定設定的起點。在決定是否需要改用其他模型或供應商之前，先修正已診斷出的原因。