DeepSeek V4 情境快取：重複提示節省高達 90% 費用

嗨，我是 Dora。上週有件小事讓我卡住了：我把同一個提示詞跑了三次，因為我不記得把最新草稿放在哪裡。輸出幾乎沒有變化，但我的速率限制卻變了。這件事讓我開始思考建立一個 DeepSeek v4 快取。我並不期待奇蹟。我只是想減少不必要的呼叫、讓延遲更穩定，並在速率限制下多一點喘息空間。由於 v4 的文件尚不完整，我從研究 v3 和類似 API 的實際情況開始，再整理出幾個我能接受的客戶端模式。一旦 DeepSeek 正式推出 v4 的快取功能，我希望能直接接入，而不必重做整個工作流程。

以下是我處理 deepseek v4 快取問題的方式：假設有限制、快取可重複的部分、沉著地重試，並觀察正確的指標。

預期速率限制

我目前還沒找到 v4 的公開完整說明，所以我把它當成趕機場轉機一樣對待：假設時間很緊，並為延誤做好準備。

我從使用 DeepSeek v3（以及類似服務商）的經驗中了解到幾件事：

日常使用中通常有兩個關鍵上限：每分鐘請求數（RPM）和每分鐘 token 數（TPM）。在批次處理或執行背景工作時，429 錯誤很快就會出現。
突發流量有時能通過，直到某個時間點就不行了。尖峰負載可能在某一分鐘正常運作，下一分鐘就被鎖住。
限制可能因金鑰、帳號層級，有時甚至因 IP 而異。這使得本地測試感覺寬鬆，而正式環境則更嚴苛。

因此，當我考慮 deepseek v4 快取時，我會將它與保守的速率處理策略搭配使用。目標不是把每一個請求都硬塞進去，而是平滑曲線，讓自己不用花整個下午追著 429 跑。

基於當前 V3 限制

2026 年 1 月，我在 v3 端點上針對生成和重新排序呼叫進行了一些輕量測試。沒有什麼嚴謹的實驗，只是足以感受到邊界在哪裡。以下是我記下的幾點：

Token 密集的提示詞（長上下文窗口）在 RPM 之前就會先觸及 TPM 上限。這意味著即使輸出會改變，快取重量級的部分仍然值得。
短暫且重複的提示詞（健康檢查、模板運行）則先觸及 RPM。這些是設置短 TTL 回應快取的理想候選。
退避（backoff）有效，但單靠指數退避並不是完整的策略。它需要一個佇列，這樣在「禮貌等待」時才不會讓並發數爆炸。

總而言之：如果 v4 沿用 v3 的分層設計，我預期大型上下文的 TPM 會很緊，互動式使用的 RPM 還算合理，而尖峰負載則會很快受到懲罰。我的設置假設在繁忙時段會遇到 429 和 5xx 錯誤高峰，並將其視為正常情況，而非例外。

客戶端模式

我不打算等待官方的 deepseek v4 快取功能才來整理自己這一端。這些是我在 API 前面加入的模式，這樣之後即使接入服務商快取，也不需要改變我的使用習慣。

指數退避

我的第一版使用了普通的指數退避（200ms、400ms、800ms，最大約 5–8 秒）。雖然有效，但在負載下感覺不穩定。以下調整有所幫助：

加入抖動（jitter）。我對每次延遲加入一點隨機性（例如 20–30% 的變異量）。這能分散重試請求，避免大量呼叫同時失敗時產生同步風暴。
限制重試次數。冪等讀取或快取提示詞最多重試三次。對於明顯面向用戶的互動，最多一次，除非 UI 預期會有載入動畫。如果超過約 10 秒還無法完成，我寧願優雅失敗，也不要讓人乾等。
區分 429 和 5xx。429 表示我應該放慢整個佇列。5xx 表示短暫的故障：我會重試幾次，然後開啟斷路器（詳見下文）。

一個小觀察：退避一開始並沒有為我節省時間。它真正帶來的，是在幾次運行後減少了心理負擔。我不再需要緊盯著終端，而在我的世界裡，這和速度本身一樣珍貴。

請求佇列

並發是我通常最容易出問題的地方。我加入了一個簡單的客戶端佇列，規則如下：

固定並發數（背景工作從 2–4 個 worker 開始，UI 觸發的動作從 1–2 個開始）。只有在靜止期之後才會提高。
感知 token 的排程。如果能估算 token 數，我會在平靜時段優先排程重量級提示詞，再填入輕量呼叫。這能讓 TPM 更平穩。
優先通道。用戶操作可以搶占批次工作。如果有人在等待，系統會讓路。

我也在上游快取昂貴的部分：

提示詞骨架（prompt scaffold）。如果系統提示和工具鮮少改變，我對它們進行雜湊，並以雜湊值作為快取鍵。如果 v4 推出伺服器端上下文快取，我會傳入這個鍵；目前它只是我自己的標籤。
檢索到的上下文。我根據內容指紋快取 RAG 片段。如果來源沒有改變，我會重用相同的上下文區塊，而不是每次都重新抓取和重新嵌入。

這並不華麗，但在一週內將我的背景工作 429 錯誤減少了約 70%。不是更快，只是更穩定。

斷路器

我沒想到自己會需要這個。後來有一個下午，服務開始拋出 5xx 錯誤長達幾分鐘，而我的重試邏輯愉快地放大了這個問題。斷路器解決了這個問題。

我的規則很簡單：

如果錯誤率超過閾值（例如，在 60–90 秒窗口內超過 30% 的呼叫失敗），或者如果延遲在連續兩個窗口內超過 P95，則開啟斷路器。
斷路器開啟時，短路呼叫並進行降級處理：如果有快取回應則提供快取，降低功能（縮小上下文、簡化提示詞），或顯示一則安靜的訊息說明暫停原因。
退避一段時間後進入半開狀態。讓少量請求通過並觀察指標。如果指標穩定，則關閉斷路器。

讓我出乎意料的是，UI 感覺平靜了多少。清楚地顯示「我們暫停一分鐘」遠比無止盡旋轉的載入圈要好得多。

監控與警報

我不喜歡在黑暗中救火。對於像 deepseek v4 快取這樣的設置，有用的訊號是細小且枯燥的。

我觀察的指標：

快取命中率。按類型區分：提示詞骨架、檢索到的上下文，以及完整回應重用。如果完整回應命中率在某個工作流程中超過約 25%，我會再次檢查 TTL——我可能過度快取，遺漏了新鮮的上下文。
實際 TPM/RPM。不只是服務商的數字，而是經過佇列處理後實際通過的量。如果在輸入增長的同時實際 RPM 保持平穩，表示佇列正在發揮作用。
重試分佈。有多少呼叫在第一次就成功，相比於第二/第三次。如果趨勢向後偏移，表示某處正在積累壓力。
延遲分段。P50 告訴我順暢路徑的狀況；P95 告訴我用戶在糟糕的一天會感受到什麼。我對 P95 設置警報。
錯誤分類。429 vs 5xx vs 超時。每種情況對應不同的解決方式。

不會過度警報的警報規則：

P95 延遲在 5 分鐘內上升 2 倍。僅在持續發生時通知我。
10 分鐘內 429 錯誤率超過 5%。自動將並發數降低一步並延長佇列等待時間；讓我知道發生了什麼。
斷路器開啟超過 3 分鐘。這是真正的事故。我會查看服務商狀態，並決定是否切換地區或暫停批次工作。關於官方文件的一點說明：當 v4 文件上線時，我會尋找任何關於伺服器端上下文快取、快取鍵或重用 token 的內容。一些服務商會公開一個 cache_id，可以附加到共享的預填充片段（想像一下：長系統提示詞）。如果 DeepSeek 做了類似的事情，我會將我的客戶端鍵與他們的格式對齊，並遵守他們發布的任何 TTL 或失效規則。在那之前，我把我的快取視為輔助性的：命中時有幫助，未命中時也無害。

適合這個設置的使用者：

擁有可重複提示詞和緩慢變化上下文的人（文件、幫助中心、知識庫）。快取在這裡最能發揮作用。
在夜間批次處理工作的團隊。佇列和斷路器能減少意外。
任何厭倦了不穩定性的人。它不會更快，但會更平靜。

可能不需要這個設置的使用者：

高度動態、用戶特定的對話，新鮮度比重用更重要。快取骨架可以，但不要快取完整回應。
流量極低的專案。如果你一天只發幾個請求，這些額外負擔不值得。

如果你想深入了解機制，我建議從服務商關於速率限制的文件，以及任何關於上下文快取或重用的說明開始。當 DeepSeek 發布 v4 的具體細節時，我會更新我的設置以符合要求，並直接連結文件。目前，這套系統運作良好：更少的無謂呼叫、更清晰的背壓，以及一個知道何時暫停的 UI。我在螢幕旁邊貼了一張小紙條：「別跟佇列作對。」這不是什麼深刻的哲理，但在繁忙的日子裡，這句話足以讓我不去追著最後一個請求擠過快要關閉的窗口。