最近，DeepSeek工程師在GitHub上高亮了來自騰訊的程式碼貢獻，並用“huge speedup”介紹了這次效能提升。
什麼樣的最佳化技術讓頂尖AI團隊如此興奮？
簡單來說，是騰訊多年來調教資料中心和GPU通訊沉澱下來的TRMT技術，幫助DeepSeek開源的網路通訊神器DeepEP效能再上一個臺階。
這項合作的起點要追溯到今年2月——DeepSeek開源了包括DeepEP在內的五大程式碼庫，揭秘了他們如何用1/5硬體資源實現傳統萬卡叢集效能的核心技術。
其中，DeepEP作為突破NCCL效能瓶頸的通訊框架，透過300%的通訊效率提升，成功讓眾多MoE架構的大模型擺脫了對英偉達NCCL的依賴。
但這項技術存在“富貴病”：在成本較高的InfiniBand（IB）專用網路中如魚得水，卻難以適配更普適的RoCE網路環境。就像超級跑車只能在專業賽道馳騁，開上普通公路就效能縮水，這讓大多數使用普通網路的企業機構面對DeepEP往往看得著、用不上。
DeepEP的Github主頁上，也出現了關於RoCE網路環境中效能表現不佳的討論，相關問題一直沒有找到理想的解法。
但騰訊在RoCE網路領域可是老司機，多年來在資料中心沉澱了豐富的經驗，在DeepEP開源後立即展開驗證，迅速鎖定兩個關鍵突破點：
-
車道利用率低下：RoCE網絡卡普遍採用雙埠架構，但既有系統無法智慧分配流量，常出現單車道擁堵、雙車道閒置的窘境，就像快遞公司面對雙向八車道卻只使用一側車道。
-
CPU控制瓶頸：雖然DeepEP透過RDMA技術實現了GPU直連通訊，但在控制面交互層面仍依賴CPU中轉，存在時延和能耗最佳化空間。
於是，騰訊基於TRMT技術體系開始對DeepEP進行三個方面的最佳化👇
//雙車道充分用起來：拓撲感知的多QP建鏈
本質上是利用動態分配演算法來最大化雙埠網絡卡的頻寬利用率。
在 AI 模型啟動時，多個 GPU 之間會建立通訊組。每個 GPU 組內，GPU 之間都要建立通訊連結，並且每個 GPU 對需要建立多組 QP（佇列對）。
這種架構涉及革新類似於智慧交通管理系統：當2048輛特種車輛（GPU資料包）需要在城市路網（RoCE網路）中高效通行時，控制系統為每類物資運輸開闢專屬路線（QP繫結埠）。
透過動態分配起始匝道口（UDP源埠），確保雙車道物理通道（網絡卡埠）的車流均衡，從根本上避免了多車隊匯入同條車道引發的堵塞，讓雙埠網絡卡頻寬利用率達到理論峰值。
//進一步繞過CPU：基於 IBGDA 的多 Channel 負載均衡資料傳輸
RDMA直連GPU進行資料互動就像港口運貨，貨物到港後不用停下來卸貨裝車，可以直接運到市區。
但在“控制面”場景還是無法讓GPU繞過CPU的控制。“控制面”類似港口處理哪個批次的貨物到港、貨物是什麼、運貨的車牌號是多少等等，這種“控制面”場景的資訊還是需要CPU來處理。
騰訊基於IBGDA（InfiniBand GPU Direct Accelerator）技術，讓控制面場景的CPU也繞過了，控制時延降低至硬體極限。
(看這清爽的右圖，就知道IBGDR這種讓控制面繞過CPU的方法提升了多少效率)
同時，騰訊還讓每個 GPU 都能同時用多個“通道”來發送資料，而且這些通道會自動分配資料，不會讓某個通道太忙而其他通道閒著。
//排好隊不出錯：原子化信令協同
在GPU直接通訊時還存在一個關鍵難題：當A GPU直接把資料寫入B GPU記憶體時（類似隔空投送），B GPU並不知道資料何時到達。如果多個數據傳輸任務同時進行，可能會發“先發的包後到”的混亂情況。
鵝廠工程師提出了一種叫做“QP內時序鎖”機制，類似一種智慧快遞簽收機制：每次傳輸資料時，透過網絡卡硬體自動生成數字指紋（類似快遞單號加密），收件方必須按正確順序“簽收”。
現在，就算同時處理1000多個數據傳輸任務，系統也能自動理順先後順序。
這三板斧下來，DeepEP不僅在RoCE網路上實現效能翻倍，當DeepSeek將這套方案反哺到IB網路時，原本已經很優秀的通訊效率竟然又提升了30%。
目前，這些技術成果都已經全面開源至DeepEP社群，並深度應用於騰訊混元大模型等專案的訓練推理。在星脈網路與H20伺服器構建的高效能環境中，這套方案同樣展現出卓越的通用性。
最後，感謝DeepSeek工程師以及我的同事們，對GPU通訊瓶頸難題的探索。
還有，感謝開源。
—END—