DeepSeek 為什麼把緩存漲了 11 倍？長上下文需求暴漲，得交點「存儲稅」了

緩存漲價背後，是大模型的存儲與數據搬運困境。作者丨高允毅 編輯丨岑 峰 一直以來，DeepSeek都是白菜價的代名詞，這次它開始漲價了，而且還按時間段收錢。8 月 17 日，DeepSeek V4 Pro API 的輸入和輸出價格漲幅如下圖。其中，最便宜的緩存命中價格在空閒時斷直接漲了5倍，在高峰時期，它竟然漲了11倍，從0.025 元 / 百萬Token 漲至 0.3 元/ 百萬 Token。很多人或許並不瞭解“緩存命中”是什麼。簡單理解，它就像大模型的“草稿紙”，AI 每次回答問題時，不必每次都去重新翻閱所有信息。

只要它之前計算過一次，這段長文本就會以“KV單元”的形式沉澱在存儲集群裡，後續調用直接提取即可。一直以來，極高的緩存命中率是DeepSeeek最出圈的“性價比殺器”，它依靠極致的KV壓縮技術和冷熱記憶分層搬運架構，直接省掉了這部分海量的重複計算，把長文本的調用門檻控制到可以忽略不計。正因如此，無數市面上的代碼助手、知識庫 Agent、長文檔分析這樣有著超長上下文的產品，通過薅DeepSeek的羊毛撐起了自己的盈利模型。而過大的需求量也直接把低廉的緩存命中變成了廠商不堪重負的剛性開銷。

大模型的成本結構，正在發生歷史性的變化：“算力（FLOPs）”正變得日益廉價，而“狀態”的保存、帶寬和數據搬運，正在成為AGI時代最昂貴的成本。01緩存命中到底幫 GPU 省掉了什麼？在沒有緩存命中之前，很多人是用不起長上下文大模型的。我們可以算筆賬，假設你要用DeepSeek V4 Pro搭建一個代碼庫智能 Agent，核心代碼有 50 萬 Token，開發者一天問 50 輪。在沒有緩存的情況下，每一輪對話 AI 都要把這 50 萬 Token 從頭到尾完整計算一遍，50 輪下來累計輸入就是 2500 萬 Token，僅輸入成本就超過 75 元。

長此以往，光是調用模型就能吃掉產品的大部分利潤。但有了 90% 的緩存命中率，只有第一輪需要全額支付預計算成本，後續 49 輪裡 90% 的上下文可以直接複用已計算好的狀態，輸入成本直降 90% 以上，幾乎可以忽略不計。這種誇張的省錢效率，背後靠的是 DeepSeek的KV壓縮技術先把長上下文壓縮，再靠冷熱記憶分層搬運架構把存儲成本打下來。具體而言，大模型每讀一個字都會產生龐大的記憶矩陣（KV Cache）。上下文越長，記憶矩陣佔用的內存也更多，也會更貴。DeepSeek V4用了兩種注意力架構交錯配置，一個是壓縮稀疏注意力技術（CSA），另一個是 重度壓縮注意力技術（HCA）。

能把相鄰的 4 個甚至 128 個Token合成一個記憶塊，直接把長文本的記憶體積直接縮小 95% 以上。這樣超長的上下文變成了輕薄的壓縮包。由於壓縮包足夠小，服務器內部可以輕鬆搬動。DeepSeek又按照訪問頻率，把這些壓縮後的記憶做了冷熱分層存放。頻繁被調用的 “熱記憶” 留在昂貴但響應極快的 GPU 顯存裡，長期無人訪問的 “冷記憶” 則被放到便宜、容量近乎無限的企業級 NVMe 固態硬盤中。這進一步節省了開支。不過，緩存命中雖然省錢，不代表它免費。它幫 GPU省掉的是重複計算的算力的錢，但這又會在存儲、搬運、調度三個環節中產生新的開銷。

存儲成本指的是海量 KV 狀態要分層存儲在 GPU 顯存、CPU 內存和 NVMe 磁盤中；調度成本指的是每次請求要快速定位到對應緩存塊、調度資源；IO 搬運成本指的是找到緩存後要從磁盤搬到內存、再加載到顯存中。這些成本之所以長期被開發者忽略，是因為它們一直很低廉。DeepSeek V4 的 CSA+HCA 混合壓縮技術，能把 100 萬 Token 的 KV 記憶狀態壓縮到約 10GB 。在一塊常用的均價為 6000 元的15.36TB 企業級 NVMe 硬盤計算，單份百萬 Token 緩存的硬件分攤成本僅幾分錢。而單次磁盤到顯存的搬運成本，算完電費與損耗，大約在幾分錢量級。

這正是DeepSeek的緩存命中敢定價這麼低的原因。02高峰期太堵，得交“存儲稅”DeepSeek開始漲價，就是因為之前定價太便宜，太多開發者沒有了成本顧慮，把整個代碼庫，Agent 多輪反思日誌、全量行業文檔…… 一股腦全往上下文裡塞，這直接導致 DeepSeek 的後端服務器在高峰期陷入了嚴重的“緩存顛簸”。當高峰期，海量百萬 Token 級的請求同時湧進來，GPU 顯存（HBM）會在極短時間內被佔滿。為了給新請求騰地方，調度系統只能把長時間沒人訪問的緩存塊，從顯存裡 “踢” 出去，轉存到速度更慢但容量更大的 NVMe 磁盤上。

長上下文的緩存本身體積就不小，一次 “騰挪” 就要搬運上百兆甚至上 GB 的數據；而高峰期新請求源源不斷，這種驅逐和加載的操作頻率會指數級上漲。vLLM 社區在適配 V4 的壓測裡，就記錄過一個很典型的現象，在極端併發下，兩個長上下文請求前後腳進來，就像早高峰湧入地鐵的乘客，為了搶佔一個臨時的滑動窗口，會互相把對方原本佔據了座位的公共前綴緩存擠出顯存。用戶隔一分鐘發第二條消息，本該複用的緩存早就被踢去了磁盤，直接觸發緩存失效，只能從頭重新計算。

當數據在顯存和磁盤之間頻繁搬運，緩存不僅沒起到加速省錢的作用，反而消耗了巨量的 IO 資源和調度算力，昂貴的GPU集群從計算推理的”腦力勞動者“變成了搬運數據的“體力勞動者”，算力在I/O堵塞中空轉，嚴重的時候甚至會讓整個集群的有效處理能力直接崩盤。DeepSeek漲的價格就是這個“存儲稅”。或許會有人問，DeepSeek 不是已經在壓縮上做到行業極致了嗎，整套混合架構下來，1M Token 上下文的 KV 緩存體積相比 DeepSeek-V3 直接砍掉了 90%，和傳統的 GQA架構相比只剩約 2%。

但問題是，被壓縮的空間再小，也擋不住長上下文需求的指數級爆發，GPU 芯片總數、HBM 容量、總線帶寬，都是有物理上限的。當存儲、IO、調度這三類成本，大到一定程度的時候，DeepSeek必須漲價。同樣的難題，OpenAI 和 Anthropic 也躲不開。為此，Anthropic用顯式緩存斷點機制，讓開發者手動標記緩存位置，同時，首次寫入緩存收取 1.25 倍或 2 倍的溢價，用高昂的首次寫入成本，倒逼開發者自覺去優化架構，只緩存高頻複用的前綴，減小後端的緩存壓力。

而OpenAI賺得多，它的基礎輸入價格遠高於 DeepSeek，可以配置更充裕的 HBM 顯存加大緩存空間，以此降低後端的緩存壓力。只有DeepSeek因為真便宜，不得不漲價了。03開發者要省錢，得提高緩存命中率有不少人看到DeepSeek漲價，可能會心裡犯嘀咕，但DeepSeek即便漲價，依然是全球性價比最高的選擇之一，成本只有Claude幾分之一，甚至更低。而且輕易換廠商並不划算。大多數公司已在 DeepSeek 的 KV Cache 層形成了穩定且高命中的緩存池，一旦切換到別家，成本代價也不低。

與其折騰換廠商，不如先吃透 DeepSeek 的緩存規則，把命中率拉到極致，把漲價多出來的成本再省回去。DeepSeek 緩存的核心邏輯很簡單，要前綴完全匹配，如果差一個字符都觸發不了命中。很多開發者平時不注意細節，很容易踩坑，平白讓幾十萬 Token 的緩存直接作廢。比如把當前時間、用戶 ID、隨機參數放在 Prompt 最開頭，第一個字符變動，後面幾十萬 Token 的緩存直接全部作廢。或者在前端組件拼接時多了一個空格，換行符格式變了，在系統的字節匹配眼裡，這就是完全不同的文本，緩存直接失效。

還有很多 Agent 框架會把工具返回的結果插到上下文中間，這一插就打斷了後面所有歷史內容的緩存邊界，前面攢的長前綴緩存直接報廢。其實，DeepSeek的這波漲價，也在倒逼前端開發者的角色發生根本轉變。以前開發者調用大模型 API 很省心，寫好 Prompt 發請求就行，後端顯存怎麼分配、緩存怎麼調度都不用操心。但現在推理系統的底層，本質上已經變成了一個巨大的分佈式存儲系統，開發者必須要學會當 “數據管理員”。哪些是全公司共用的核心熱數據，要寫在 Prompt 最前面，保證穩定命中；哪些是低頻的冷數據，可以按需再加；緩存的生命週期怎麼管理，才能避免高峰期被系統輕易 “踢” 出顯存。

我們已經步入大模型精耕細作的時代，緩存命中就是其中一道重要的分水嶺。上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。