Deepseek V4 速率限制：高流量生產環境最佳實踐

你好，我是 Dora。上週有件小事讓我卡住了。我正在將一個新工具接入筆記應用程式，卻在一批無害的提示詞請求中不斷看到 429 錯誤。不算嚴重，但足以打斷我的思路。這個小插曲讓我鑽進了一個熟悉的兔子洞：Deepseek V4 的速率限制會是什麼樣子，我又該如何構建系統，讓它無論如何都不受影響？

我不追逐閃亮的規格數字。我試著打造在規格變動時依然穩定的系統。所以這裡是我目前對 Deepseek V4 速率限制的思考方式，以及當上限模糊或變動時我所仰賴的模式。

預期速率限制

如果你來這裡是為了找一個神奇的確切數字，我沒有。截至我在 2026 年 1 月的測試，我還沒有看到 Deepseek V4 速率限制的明確公開數字。即使有，供應商也會根據帳戶等級、地區和濫用訊號調整限制。他們還會分開計算每分鐘請求數和每分鐘 token 數，有時還會限制並發流數量。

我改為觀察以下指標：

• 每分鐘請求數（RPM）：你可以發起多少次呼叫。
• 每分鐘 token 數（TPM）：更隱藏的瓶頸，尤其在長上下文情境下。
• 並發數：API 能容忍多少個進行中的請求。
• 重試語義：是否存在 Retry-After 或 X-RateLimit-* 等標頭，且是否可靠。

我把這些當作天氣來看待。值得查看，但不明智依賴它一直晴天。

基於當前 V3 限制

根據我在 2025 年底的筆記，v3 的行為與大多數現代 LLM API 相似：低流量時可預測，在邊界處敏感。我看到限制以 RPM 和 token 預算兩種形式表達。標頭的資訊足夠指導退避策略，而且長提示詞消耗配額的速度明顯比我預期的更快。

因此，如果 v4 沿襲 v3 的規律，以下是我的規劃：

• 數量級對等：我假設 v4 在發布時不會比 v3 寬鬆太多。新模型往往先收緊，再放寬。
• Token 優先思維：我更注重 TPM 而非 RPM。一個長請求可能相當於許多個小請求。
• 突發 vs. 持續負載：短暫的流量尖峰比穩定的細流更容易觸發 429。我在客戶端平滑突發流量。

實際上，這意味著我按 token 而非請求數量來設定佇列大小。如果用戶貼上一份 30 頁的文件，我預期接下來幾分鐘會很「昂貴」，即使這只是一個請求。我也接受限制可能因小時和 IP 而異的事實。這聽起來很明顯，但我仍然發現自己在一切順利時忘記這一點——直到它不再順利。

客戶端模式

如果你想快速重現這種設置——從第一次對話到可重複的 API 迴圈——可以查看我的 DeepSeek V4 快速入門指南。

這些是我在向支援人員申請提高配額之前就會採用的模式。它們很無聊，這正是重點。它們減少了心智負擔，讓限制感覺像是背景雜音。

指數退避

我的第一步使用帶有抖動的簡單退避策略。沒有什麼花哨的東西。

我觀察到的：

• 最初幾次執行感覺更慢。我幾乎要關掉它。後來我注意到，在流量尖峰期間我不再陷入重試風暴。
• 抖動很重要。沒有它，我的批次作業會「雷群效應」，所有請求同步重試。
• 在有 Retry-After 的情況下遵守它，比耍小聰明節省了更多時間。當伺服器告訴我何時再試時，我照做。

我的日常調整方式：

• 從小開始：基礎延遲 250–500 毫秒。
• 指數：每次重試加倍，直到合理上限（8–16 秒）。如果兩次達到上限，我將其記錄到帶有上下文的日誌中。
• 優雅放棄：嘗試 4–6 次，然後拋出帶有提示的型別化錯誤（建議縮小批次或稍後重試）。

一個幫助了我的小細節：我將 429 的重試與 5xx 的重試分開處理。它們代表不同的問題。429 表示「你在超限推進」；5xx 表示「服務不穩定」。我對 5xx 退避更長時間。

請求佇列

我不讓 UI 或定時任務無限制地發送呼叫，因為「只是文字而已」。這是我讓速率限制變得刻骨銘心的方式。

比我預期更有效的做法：

• Token 加權佇列。我不是限制同時 N 個請求，而是在填滿 token 預算之前接受請求，然後讓佇列喘息。
• 小批次視窗。我將請求分組到短視窗中（例如 200–500 毫秒），以平滑微突發，同時不讓應用程式感覺遲鈍。
• 優先級通道。用戶觸發的操作優先；後台同步等待。僅此一項就消除了最嚴重的流量尖峰。

我遇到的阻力：

• 估算 token 並不完美。我在客戶端保留一個廉價的估算器，並在響應返回時用實際用量修正。夠用就好，勝過精確。
• 取消請求。如果用戶導航離開，我取消佇列中的呼叫，為螢幕上的內容釋放預算。聽起來很基本，但確實節省了真實的資源。

我遵循的簡單規則：如果佇列超過閾值（基於時間，而非長度），我顯示一個安靜的提示。沒有誇張。只是一行字說「正在穩定處理」。用戶感受語氣與速度同樣重要。

熔斷器

當限制收緊或錯誤堆積時，我不想讓成千上萬的重試假裝有用。熔斷器讓系統有權休息。

我的使用方式：

• 在持續失敗率上觸發：例如，如果滾動一分鐘內 25–30% 的呼叫是 429/5xx。
• 半開狀態：暫停後，我讓幾個金絲雀請求通過。如果成功，熔斷器關閉。
• UI 行為：顯示溫和的橫幅，如「API 正在限流：我們很快恢復」。我避免在沒有進展時使用暗示進度的轉圈動畫。

一個意外的驚喜：當我坦白承認限制時，用戶反應更友善。熔斷器沒有讓應用程式感覺脆弱，反而讓它感覺誠實。

監控與警示

我以前把速率限制當作邊緣案例，所以日誌記錄得很少。那是個錯誤。隨著 v4 即將到來，我先建立護欄，讓限制自行發展。

我現在捕捉的資訊：

• 狀態碼和原因。429 按端點和呼叫方（用戶 vs. 任務）分類。5xx 單獨追蹤。
• 有效 token 成本。每個請求的提示詞 + 完成 token 數。這比單純的 RPM 更能解釋行為。
• 延遲百分位數。每條路由的 P50、P95、P99。尖峰通常在限流之前出現。
• 重試元資料。嘗試次數、總退避時間、是否遵守了 Retry-After。
• 客戶端並發數。429 發生時進行中的呼叫數量。

我也保留一個小型每日匯總：「請求數、token 數、錯誤率、平均增加的退避時間」。這足以看出趨勢，而不需要建立一個本身需要儀表板的儀表板。

不讓我煩惱的警示：

• 429 率超過基準線，而非尖峰。我關心的是 429 是否在 10 分鐘內超過 2–3%。一次閃現不會通知我。
• 退避時間預算。如果用戶平均每個工作階段等待超過 X 秒的退避時間，我想知道。
• Token 異常。如果提示詞中位大小增加了 3 倍，說明有人發布了更改或用戶行為改變了。

在人的層面，我把限制當作產品限制，而不僅僅是後端限制。如果我在為大量上下文上傳製作介面，我會顯示提示：

• 「大型文件可能在後台處理。完成時會通知您。」
• 「先簡短摘要，再深入分析。」

這不只是禮貌。它將使用模式塑造成速率限制能容忍的形狀。

關於文件的一點補充：在可能的情況下，我會對照官方文件或標頭來確認行為。如果 v4 發布時帶有清晰的速率標頭（Retry-After、X-RateLimit-Remaining 或 token 計數器），我會逐字記錄。如果它們缺失或模糊，我回退到觀察到的上限，並保留充裕的安全餘量。

為什麼這很重要

• 對於建構者：你可以在沒有確切數字的情況下自信地發布。為可變性設計，讓重試保持安靜。
• 對於規模化團隊：在你證明客戶端尊重當前限制之後，再申請更高的配額。大多數供應商在看到合理的退避和乾淨的日誌時反應更好。
• 對於個人開發者：保持簡單。一個小佇列、帶抖動的基本退避，以及一兩個警示就能走很遠。

可能不喜歡這些方法的人

• 如果你今天需要在固定延遲下保證吞吐量，模型 API 總體上可能會讓你沮喪。專用推理端點或快取管道可能更適合你。

會喜歡的人

• 如果你想要一個能吸收尖峰、讓你專注於工作而非管線的穩定工具，這些模式會有所幫助。它們故意設計得枯燥乏味。

關於 Deepseek V4 速率限制的最後一點說明：一旦我讓真實流量跑過它一週，我會更新我的假設。目前，v3 時代的習慣依然適用——預算 token、平滑突發，並在系統疲憊時讓它喘息。

這週讓我印象深刻的小觀察：當我停止把限制當作障礙，開始把它當作天氣看待的那一刻，我構建出了更平靜的軟體。說實話，我的早晨也變得更安靜了。