DeepSeek又有新動作了。

不過，這次發布的，依然不是大家期待已久的DeepSeek-V4。

更重要的是，這套系統并非為常規對話而設計，它所瞄準的，是當下更復雜、也更火熱的智能體場景中的核心難題。

既然是三大頂尖機構聯手發布的技術成果，論文里自然少不了一堆專業術語，讀起來容易讓人頭大。

01

智能體推理：算力成了配角

你可能已經注意到，AI圈的風向變了——從“大模型”變成了“智能體”。

過去用大模型，交互很簡單：你輸入一段提示詞，模型思考幾輪，給你一個答案。

到了智能體時代，事情復雜了。交互的雙方，不再只是“人”和“機”，還有“機”和“機”。模型不僅要讀懂你的話，還要自己去調用瀏覽器、打開代碼解釋器、與外部環境打交道。交互次數也從幾次，飆升到幾十次、上百次。

在這個過程中，智能體每次調用工具所產生的輸入輸出其實很短，可能只需要幾百個token。但問題在于，隨著交互輪次增加，上下文會像滾雪球一樣越積越大，最終堆積成幾十萬token的龐然大物。

換句話說，智能體任務呈現出一種奇特的特征：多輪次、長上下文、短追加。

這種模式帶來的直接后果是——KV-Cache的命中率，常常高達95%以上。

什么是KV-Cache？用一個追劇的比喻就能明白：

假設大模型的推理過程，就像你在追一部連續劇，剛更新到第20集。

第20集的內容，是由前19集的劇情背景（也就是上下文），加上第20集的新劇情（新輸入）組成的。

如果沒有KV-Cache，就像你得了健忘癥，每次看新一集，都得把前面19集從頭到尾重看一遍，才能看懂第20集。

而有了KV-Cache，就好比你已經把前19集牢牢記在腦子里，只需要看新的那一集，就能無縫銜接，繼續追下去。

對于Transformer架構的模型來說，原理也是一樣的。

當智能體完成一次交互，準備處理下一個任務時，它所需要的絕大部分上下文，早在之前的交互中就已經計算過了。直接讀取緩存就好，只有極少量新內容需要重新計算。

所以，對計算機來說，KV-Cache的命中率當然是越高越好，因為命中就意味著“省事”。

但“省事”的背后，卻藏著一個新問題：

強大的GPU，算幾百個token的新一輪交互，可能還不到1毫秒。但在此之前，它需要先拿到那幾十萬token的“記憶”——也就是幾十GB的KV-Cache數據。

要想用KV-Cache“省事”，就得把這些數據，從硬盤或分布式存儲設備里，硬生生地搬運到GPU的顯存里。

這就像一個頂級大廚，炒一盤菜只需要1秒鐘，但他的助手買菜卻要花10秒鐘。

于是，智能體推理的最大瓶頸，已經不是算力，而是KV-Cache數據的輸入輸出速度。

02

現有架構：PD分離

為了提升推理性能，業內普遍采用的架構叫做“預填充-解碼分離”，簡稱PD分離。

簡單來說，在這種架構下，GPU集群被分成了兩個部門：

一個是預填充引擎，負責處理海量輸入文本，屬于計算密集型任務，擅長批量處理；

另一個是解碼引擎，負責一個字一個字地生成回答，對延遲極度敏感，但受限于內存。

在這樣的組織方式下，預填充引擎需要不斷從外部存儲里加載海量的KV-Cache數據，它的存儲網卡幾乎隨時處于過飽和狀態，堵得水泄不通。

與此同時，解碼引擎雖然也在正常運行，但它的存儲網卡大部分時間卻閑著沒事干。

一個倉庫里，進貨的大門被堵死，出貨的大門空空蕩蕩，整個物流線就這樣卡住了。

在算力成本高昂的今天，讓高性能芯片集群里的硬件資源閑置，簡直是極大的浪費。

最直觀的解決辦法，當然是把進貨的大門拓寬——給預填充引擎增加帶寬。但在實際操作中，這既不現實，成本也高得嚇人。

一個更聰明的辦法是：讓出貨的大門也來幫忙進貨——也就是讓閑置時的解碼引擎，分擔一部分“拉取數據”的任務。

03

來自DeepSeek、清華和北大的研究團隊在對現代AI數據中心的研究中得到了靈感。

類似英偉達的AI超級計算機DGX SuperPOD，其架構普遍具備一個重要的硬件特性：網絡隔離。

每個GPU一般配備兩套網卡：

一是計算網卡（Compute NIC）：專門用于GPU之間的跨節點卡間通信，通常配備多張總傳輸帶寬極大；

二是存儲網卡（Storage NIC）：用于讀寫硬盤或分布式存儲上的數據，通常只配備1張，總帶寬相對較小。

先前的架構采用的路徑是：讓預填充引擎直接通過自己的存儲網卡，從硬盤或分布式存儲中拉取KV-Cache數據。

如此一來，進貨的大門被堵住時，如果暫時沒有出貨，出貨的大門也開始進貨，所有引擎的存儲網卡帶寬都得到了有效利用，不對稱帶寬飽和問題得以解決。

04

流量調度與優先級博弈

雖然數據的流向多繞了一大圈，實際推理效率卻能大幅提升，想法看起來很美好。

但想要在以微秒級別運行的系統中落地，還有相當重量級的挑戰擺在眼前：

一是大量數據引入帶來的混亂：

讓解碼引擎幫著一起拉取歷史記憶數據（KV-Cache）確實是個好主意，但也會帶來巨大的風險。

GPU在推理過程中，需要頻繁地與集群中的其他GPU進行“集體通信”，完成數據的同步和結果的交換，這種通信對延遲極其敏感，慢一點都不行。

如果解碼引擎開始下載幾個GB的KV-Cache數據，火山噴發一般的數據流就可能擠占網絡帶寬，如果GPU之間的集體通信不幸被阻塞了，推理過程還是會卡住。

為了解決這種混亂的情況，研究團隊在網卡層面上設置了一個高速上的“交警”：

GPU之間的通信必須具有最高的優先級，它有走VIP通道的權力，無論如何都要保證正常運行、不許堵車；

拉取KV-Cache數據的任務則只有普通優先級，VIP通道沒車的時候它才能上路，只要GPU通信任務出現，它就得立刻避讓。

這位由計算網卡（CNIC）扮演的“交警”必須徹底隔絕兩種數據流量，確保解碼引擎拉取數據絕對不能影響GPU之間的集體通信。

二是如何動態分配任務：

人們的各種需求意味著智能體的推理任務總是動態變化的，有時請求多，有時請求少，有的請求長，有的請求短。

如果這位“交警”指揮不當，那就必然會幫倒忙。例如，預填充引擎的帶寬明明沒有飽和，卻非要繞遠路讓解碼引擎去拉取數據。

如何實時通過負載均衡（Load Balance）來動態分配任務，是這位“交警”必須面對的數學難題。

為此，研究團隊設計了自適應請求調度器，讓系統在運行時根據存儲網卡的隊列長度、GPU計算負載以及請求特征，動態選擇最優的數據加載路徑。

在引擎間，它不僅會監控每個GPU當下的計算負載，也就是待處理的token數量；還會同時監控底層分布式存儲在每個節點上的磁盤讀取隊列長度。

這樣，新的請求總會被智能分配到讀取隊列最短、GPU最閑的那個引擎進行加載。

在引擎內，由于多張GPU被綁定在一起干活，所有的GPU必須同時干完手上的活才能進入下一個環節，這就是注意力機制的同步。

為了防止拿到短任務的GPU“干等著”拿到長任務的GPU，它需要使用基于計算配額的批處理選擇算法，把長任務分割為短任務，這樣多張GPU計算注意力機制的時間就能基本對齊，盡快進入到下一個環節。

05

實測：吞吐量翻倍！

現在到了檢驗技術成果的時候。

研究團隊在基于InfiniBand高速互聯的英偉達Hopper GPU集群上，使用了DeepSeek-V3.2的660B參數版本、27B參數簡化版本和Qwen2.5-32B三種模型進行測試，并根據真實的智能體強化學習訓練軌跡進行評估。

在在線服務推理任務中，模擬的真實用戶會不斷涌入，系統需要在保證輸出第一個字符的延遲不超過4秒的情況下盡可能處理更多請求。

回顧從“大模型”到“智能體”的發展歷史，我們可以看到一條清晰的路徑：

最早期的挑戰是算力，如何更快計算神經網絡矩陣是頭號問題；

隨后內存登場，模型權重和KV-Cache占據了網絡傳輸帶寬；

現在智能體爆發，上下文成倍增長，挑戰又來到了輸入輸出和網絡層面。

毫不夸張地說，又是一次軟硬件協同設計的教科書級別示范。

大模型作為智能體的底層基礎設施，其內在計算邏輯正在悄無聲息地發生巨變。

不必因新產品遲遲未能發布而遺憾，因為技術已成為最牢固的基石，而日思夜想的DeepSeek-V4，已經指日可待。