DeepSeek的含金量還在上升。

就在最近，Hugging Face聯創、首席科學家Thomas Wolf表示——

DeepSeek的出現，是開源AI領域的ChatGPT時刻！

用他的話說，「正如ChatGPT讓全世界認識到AI的存在，DeepSeek則讓全世界意識到，原來還有著這樣一個充滿活力的開源社區。」

DeepSeek-R1的性能已經媲美甚至超越美國最頂尖的閉源AI模型，對于全球AI圈來說，這件事的意義都極其深遠。

與此同時，來自SGLang、英偉達等機構的數十人聯合團隊，也在DeepSeek上整了個大活。

在短短4個月內，他們利用最新的SGLang推理優化，直接讓DeepSeek-R1在H100上的性能提升了26倍！

這是怎么做到的？

團隊發布了長篇博文，詳細展示了這一過程。

文章地址：https://lmsys.org/blog/2025-05-05-large-scale-ep/

在96塊H100 GPU上優化部署DeepSeek

要知道，DeepSeek模型因為龐大的參數，以及多頭潛注意力（MLA）和專家混合機制（MoE）等獨特架構，如果想要大規模部署，就必須使用更先進的系統。

為此，團隊先是對SGLang進行了全面升級，完整支持了PD分離、大規模EP、DeepEP、DeepGEMM及EPLB等功能。

然后憑借這些新特性，成功地在12個節點共96塊GPU的集群上，復現了DeepSeek的推理系統。

最終，在處理2000個token的輸入序列時，實現了每個節點每秒52.3k輸入token和22.3k輸出token的吞吐量。

方案運行在Atlas Cloud的12個節點上，每個節點均配備8塊H100 GPU

團隊表示，這應該是首個吞吐量接近DeepSeek官方數據的開源實現。

在本地環境下部署此方案，成本可降至0.20美元/1M輸出token，約為DeepSeek Chat API官方定價的五分之一。

相較于使用相同資源的原始張量并行策略，此優化方案可將輸出吞吐量提升高達5倍。

接下來，團隊深入探討了他們的并行設計、優化方法以及最終成果。

并行設計

高效的并行化設計，對于控制DeepSeek架構的計算復雜度和內存需求至關重要。

針對以下關鍵組件，團隊都給出了優化方案：注意力層、稠密前饋網絡（FFN)、稀疏FFN以及語言模型（LM）的頭部。

每個組件都采用了專門設計的并行化策略，以提升可擴展性、內存效率和整體性能。

注意力層

DeepSeek采用了多頭潛注意力機制（MLA)，從而能夠有效地對輸入序列中的復雜依賴關系進行建模。

為了優化這一機制，團隊實現了DP attention，這是一種數據并行策略，目的是消除跨設備的KV緩存冗余，從而顯著降低內存開銷。

在SGLang v0.4版本中引入的該方法，現已擴展至支持混合數據并行和張量并行，為高效處理小批量數據提供了更大的靈活性。

稠密FFN

即便DeepSeek-V3僅使用了三個稠密FFN層，其計算過程仍然可能顯著增加峰值內存占用，若不加以謹慎管理，極易導致系統崩潰。

為了解決這個問題，團隊選擇采用數據并行（DP）策略，而非張量并行（TP)，主要是考慮到DP的以下優勢。

· 更強的可擴展性

當中間層維度為18,432時，較高的TP度（例如TP32）會導致數據被低效地分割成小單元片段（例如576個單元），而這些單元無法被128整除。

128，就是現代GPU（如H100）常見的對齊邊界。

這種未對齊的情況，會嚴重阻礙計算效率和內存利用率。

相比之下，DP能夠避免數據碎片化，從而提供更具可擴展性的解決方案，確保跨設備的工作負載均衡分配。

· 優化的內存效率

傳統觀念認為，TP可以隨著worker size的增加而降低內存使用量，但這種優勢在DP attention的應用場景下會逐漸減弱。

在純TP設置中，單層Transformer模型的內存需求與DP size的關系如下：

其中，是每個設備（DP rank）上隱藏狀態的大小，是模型參數的數量，k是一個系數，表示來自CUDA Graph復制的額外內存開銷。

通過假設DP=TP，當時，此內存的使用函數達到最小值。

DeepSeek-V3使用18,432的中間大小。在prefill階段，CUDA Graph通常被禁用，因此k=0。

但是，每個設備的token大小很容易超過2,048，導致最佳TP大小為3或更小。

在解碼階段，一個實際的配置可能使用每個設備128個token，并設置k=3。在這種情況下，內存最佳的TP大小為6。

在這兩個階段，較低的TP度可以最大限度地減少每個設備的內存使用量。

因此，與僅依賴TP相比，DP可以提供更節省內存的擴展方法。

· 最小化的通信開銷

在純TP模式下，每個FFN層都需要執行兩次all-reduce操作，從而導致巨大的通信開銷。

通過采用DP策略，團隊將該過程優化為：在先前的attention層之后執行一次reduce-scatter操作，并在下一個attention層之前執行一次all-gather操作，從而將通信成本降低50%。

更進一步，如果attention計算也采用純DP模式，那么設備間的通信將被完全消除，進而顯著提升整體效率。

DP稠密FFN與DP attention的集成方案如下圖左側所示。用戶可以通過設置--moe-dense-tp-size=1來啟用。

稀疏FFN

在DeepSeek-V3的MoE架構中，稀疏FFN需要處理大量的專家權重，進而造成顯著的內存瓶頸。

為了緩解這一問題，團隊采用了專家并行（EP）策略，將專家權重分散到多個設備上。

這種方法能夠有效地擴展內存容量，不過，它在維持高性能的同時，也帶來了一些新的挑戰，比如不規則的全互聯通信以及工作負載不均衡等。

團隊利用DeepEP框架實現的EP方案

LM頭

LM頭（LM Head）負責計算大型詞匯表上的輸出概率，這是一項資源稠密型的操作，傳統方案是采用詞匯表并行技術，從TP組中聚合token logits。

為了進一步提升可擴展性和效率，團隊采用了數據并行（DP）策略，與處理稠密FFN的方法保持一致。

這種做法不僅可以降低內存開銷，還能簡化跨設備的通信過程，從而提供了更加精簡的解決方案。

預填充和解碼分離

LLM的推理過程主要包含兩個不同的階段：預填充（prefill）和解碼（decode)。

預填充階段屬于計算密集型，需要處理完整的輸入序列；而解碼階段則屬于內存密集型，主要負責管理用于生成token的KV緩存。

傳統方案通常在一個統一的引擎中處理這兩個階段，然而，這種預填充和解碼batch的混合調度方式會引入效率問題。

為了解決這些挑戰，團隊在SGLang中引入了預填充和解碼（PD）分離技術。

如下圖所示，SGLang會通過預填充服務器和解碼服務器的協同工作，實現兩個階段的交錯執行。

接收到輸入請求后，系統的工作流程如下：

1. 預填充服務器和解碼服務器通過握手配對，各自作為本地發送者和接收者。
2. 解碼服務器預先分配KV緩存，并通知預填充服務器啟動模型前向傳遞，計算KV緩存。
3. 完成計算后，數據將被傳輸至解碼服務器，由該服務器負責進行迭代式的token生成。

這種分離機制確保了每個階段都能在最佳狀態下運行，從而最大限度地利用GPU資源。

并且，為了進一步提升性能，團隊的實現方案還包含以下特性。

• 非阻塞傳輸：數據發送和接收操作在后臺線程中執行，從而保證調度器的事件循環不會被中斷。
• 基于RDMA的傳輸：遠程直接內存訪問（RDMA）技術利用隊列對（Queue Pairs）進行連接管理，并利用分散-聚集元素（Scatter-Gather Elements, SGE）實現非連續內存塊的高效傳輸。
• 靈活的API集成：SGLang提供了高度可定制的API，能夠與Mooncake和NIXL等高性能RDMA庫無縫集成，從而簡化了數據傳輸流程。

大規模專家并行性

基于DeepEP的專家并行

由DeepSeek團隊開發的DeepEP提供了一系列優化過的通信內核，可以有效降低延遲并提升吞吐量，高效地將token路由到多個GPU上。

DeepEP有兩種專門設計的調度模式，以滿足不同的工作負載需求。

• 標準調度模式（Normal Dispatch）：主要針對處理較長的輸入序列進行優化，例如預填充階段，其首要目標是最大化計算吞吐量。 但會生成與CUDA Graph不兼容的符號形狀，從而降低其在解碼階段的效率，因為在解碼階段，內核啟動開銷會成為一個顯著的瓶頸。
• 低延遲調度模式（Low-Latency Dispatch）：專門為解碼階段生成輸出token而設計，其核心目標是最小化延遲，從而確保實時性能。盡管它支持CUDA Graph，但需要預先分配固定大小的內存。如果實際內存需求超過了預分配的容量，則會觸發運行時錯誤。

在SGLang中，DeepEP的集成提供了一種自動模式，能夠根據當前的工作負載，動態地在上述兩種調度模式之間進行選擇。

與此同時，通過利用PD分離技術，使得在DP attention機制下，預填充階段能夠采用標準調度模式（Normal Dispatch)，而解碼階段則能夠采用低延遲調度模式（Low-Latency Dispatch)。

這種集成方式能夠根據每個階段的具體需求來調整調度模式，從而優化資源利用率，并提升整體性能。

DeepGEMM集成

由DeepSeek團隊開發的DeepGEMM，則被用于優化MoE模型中的計算過程。

DeepGEMM提供了兩個經過專門設計的函數，用于處理與MoE相關的矩陣乘法運算（分組GEMM），每個函數都針對推理過程的不同階段進行了定制。

• 分組GEMM（連續布局）： 這種內核專門為動態輸入形狀而設計，使其成為MoE推理預填充階段的理想選擇。 它可以處理來自不同專家的輸入數據，這些數據以連續的方式連接在一起，從而靈活地處理各種輸入尺寸的變化。
• 分組GEMM（掩碼布局）： 這種內核假定輸入形狀是固定的，并使用掩碼張量來僅計算輸入的有效部分。 由于它與CUDA Graph兼容（可優化內核啟動過程），因此特別適合于需要顯著降低開銷的解碼階段。

DeepGEMM與DeepEP的調度模式可以實現無縫集成：

• 對于與預填充階段的標準調度模式配合使用的連續布局內核，需要執行一個額外的步驟。團隊參考了LightLLM項目，并實現了一個自定義的Triton內核來實現高效的置換。確保了從標準調度模式輸出的數據能夠被正確地重新排列，從而實現與連續GEMM內核的平滑集成。
• 掩碼布局內核與DeepEP的低延遲調度模式能夠實現無縫對接，因為兩者都針對解碼階段進行了專門優化，并且都支持CUDA Graph。

SGLang集成了DeepGEMM，用于在張量并行模式下進行MoE計算。通過在SGLang中設置環境變量SGL_ENABLE_JIT_DEEPGEMM為1，即可激活該內核，從而為非MoE操作提供更高的計算效率。

雙batch重疊

在多節點環境下，有限的通信帶寬可能會顯著增加整體延遲。

為了應對這一挑戰，團隊遵循DeepSeek的系統設計理念，實現了雙batch重疊（TBO）技術。

TBO將單個batch拆分為兩個micro-batch，從而允許計算和通信過程相互重疊，同時，通過將有效batch大小減半，也降低了峰值內存的使用量。

為了創建更易于維護和重用的代碼庫，團隊采用了一個由操作和yield點構成的抽象層。

這種方法可以讓用戶像處理單個micro-batch一樣編寫代碼，同時通過策略性地插入yield點來暫停執行，從而允許其他micro-batch繼續進行。

如此一來，不僅消除了代碼重復，減少了對變量后綴的需求，并且還能有效地管理某些執行在層末尾完成而其他執行尚未完成的情況。

此外，抽象層還能輕松地適應不同的重疊區域選擇，或者未來的增強功能，例如三batch重疊，而只需要進行極少的代碼修改。

operations = [    self._forward_attn,    YieldOperation(),  # Pause execution for other micro-batches    self._forward_dispatch,    self._forward_mlp,    YieldOperation(),  # Another pause point    self._forward_combine,]# Process a single micro-batch without duplicating codedef _forward_attn(self, state):    state.hidden_states = self.self_attn(state.hidden_states, ...)
operations = [
    self._forward_attn,
    YieldOperation(),  
# Pause execution for other micro-batches
    self._forward_dispatch,
    self._forward_mlp,
    YieldOperation(),  
# Another pause point
    self._forward_combine,
]
# Process a single micro-batch without duplicating code
def _forward_attn(self, state):
    state.hidden_states = self.self_attn(state.hidden_states, ...)

團隊優化了預填充階段的啟動順序，以避免通過DeepEP中的調度操作阻塞CPU，即使用的是其異步模式。

具體來說：

• 在GPU從其他rank接收到元數據，從而能夠正確分配大小合適的張量之前，調度操作會阻塞CPU。
• 不正確的實施方式會導致在此期間計算流處于空閑狀態，因為沒有計算任務被提交給GPU。

為了實現優化，團隊優先將計算任務提交給GPU，然后再啟動可能導致CPU阻塞的通信操作。這樣可以確保GPU在通信期間保持活躍狀態。

如下圖所示，通過采用正確的啟動順序，TBO可以避免由CPU阻塞操作引起的性能瓶頸。

專家并行負載均衡器

為了解決由專家并行（EP）引起的各個GPU工作負載分布不均勻的問題，DeepSeek開發了專家并行負載均衡器（Expert Parallelism Load Balancer, EPLB)。

EPLB以專家分布的統計信息作為輸入，計算出專家的最佳排列方式，從而最大限度地減少不平衡現象。

用戶可以分配冗余專家（例如，增加32個專家），這些冗余專家與原有的256個專家組合在一起，形成一個包含288個專家的資源池。

借助這個資源池，EPLB能夠策略性地放置或復制專家——例如，多次復制最常用的專家，或者將使用頻率適中的專家與在單個GPU上很少使用的專家組合在一起。

除了平衡工作負載之外，EPLB還在并行設計方面提供了更大的靈活性。如果使用最初的256個專家，并行規模只能被限制為2的冪次方。而EPLB通過使用288個專家，能夠實現更多樣化的配置，例如將并行規模設置為12或72。

在下圖中，團隊展示了系統規模和EPLB算法對不平衡問題的影響。

他們將GPU的平衡度，定義為GPU中MoE層的平均計算時間與最大計算時間之比，并使用GPU處理的token數量來估計其計算時間。

從圖中可以看出，當系統隨著節點數量的增加而擴展時，GPU的利用率會降低，而啟用EPLB則可以顯著提高了GPU的利用率。

EPLB在實際服務中的應用

為了使EPLB能夠有效發揮作用，輸入數據的分布必須與實際服務的工作負載高度吻合。通過以下兩種策略，可以增強這種吻合度：

• 增加batch大小：更大的batch可以減少專家使用過程中的隨機波動，從而提高負載均衡的效果。這一目標可以通過擴展集群規模或者采用多token預測（MTP）等技術來實現。
• 定期進行重新平衡：定期更新專家的排列方式可以利用時間局部性原理，但這需要高效地重新加載專家模型。因此，需要盡可能降低專家模型重新加載操作的成本。

即使采用了EPLB，一定程度的不平衡現象仍然難以避免，未來仍需進一步優化。

重新平衡的具體實施方案

SGLang通過三個階段的重新平衡操作，來確保既高效又不會造成中斷，進而在權重更新期間維持系統的性能。

1. 系統加載階段：可以選擇從磁盤預加載權重數據到主內存中，以加快重新平衡的速度；也可以選擇將權重數據保存在磁盤上，并使用內存映射（memory mapping, mmap）技術，從而減少內存的占用量。
2. 重新平衡準備階段：所需的權重數據會在后臺異步傳輸到設備內存中，利用空閑的DMA硬件引擎，從而避免中斷正在進行的GPU操作。
3. 重新平衡執行階段：通過設備到設備的數據復制來更新權重數據。還可以通過物理內存重綁定等技術來進一步優化這一步驟。

評估

為了突出使用的先進優化技術帶來的吞吐量提升，團隊使用DeepSeek-V3模型，在一個包含12個節點的集群上，對 SGLang 的不同配置進行了端到端性能評估。

他們比較了以下四種不同的配置：

• SGLang（采用TP16x6）
• SGLang（采用PD分離）
• SGLang（采用PD分離和模擬MTP）
• DeepSeek的結果

為了適應不同的工作負載需求，團隊分別獨立地評估了預填充階段和解碼階段的性能。

評估結果總結如下：

· 預填充階段：在4個節點的配置下，對于prompt長度分別為1K、2K和4K的情況，系統所實現的單節點吞吐量分別為每秒57,674、54,543和50,302個token。

如下圖所示，與TP16基線相比，這種配置實現了高達3.3倍的性能提升。

在假設工作負載完全平衡的前提下，此系統的吞吐量與DeepSeek官方數據之間的差距在5.6%以內。

· 解碼階段：在9個節點的配置下進行評估，對于2K的輸入，系統實現的單節點吞吐量為22,282個token/秒，這意味著與TP16基線相比，性能提升了5.2倍。

在模擬MTP條件下，對于4K的輸入，系統仍然能夠保持每節點17,373個token/秒的高吞吐量，僅比DeepSeek官方性能分析數據低6.6%。

接著，團隊將SGLang的性能與DeepSeek的推理系統進行對比，力求使實驗設置盡可能貼近DeepSeek的生產環境。

對于預填充階段，團隊測試了一個場景，在該場景中，每個設備處理16,384個token，輸入長度為4,096。

考慮到DeepSeek的專家分布存在不確定性，他們評估了兩種情況：一種是采用默認的專家分布，另一種是模擬理想狀態下的EPLB，并將后者的結果作為性能上限。

評估結果如下所示：

DeepSeek的性能分析數據顯示，其所報告的吞吐量大約是其生產環境的兩倍。

在默認的專家不平衡情況下，SGLang的性能比DeepSeek的性能分析數據慢20%；而在模擬的理想EPLB情況下，這個差距縮小到了6%。

對于解碼階段，結果如下所示：

在使用DeepSeek一半數量的節點的情況下，搭載模擬MTP的SGLang僅比DeepSeek的性能分析數據略慢。

在更高的batch大小設置下（256個序列，2,000個輸入長度），SGLang實現了每節點每秒22,282個token的處理速度，充分展現了其強大的可擴展性。

下圖詳細分析了預填充階段各個內核的執行時間。

如下圖所示，SGLang的解碼內核分析結果與DeepSeek的結果非常接近：

可以看出，SGLang的解碼性能在很大程度上與DeepSeek的性能相一致。

因此，下一步的工作重點，就是預填充階段的優化了。

局限性與未來工作

總的來說，項目在吞吐量上有著顯著的提升，但仍然存在一些局限性以及需要增強的領域：

• 延遲優化：目前因為專注于提升吞吐量，導致首token時間（TTFT）達到2-5秒，token間延遲（ITL）大約100毫秒。之后還需要進一步優化，來滿足實時使用場景的需求。
• 序列長度約束：由于使用了96個GPU，因此序列長度被限制在較短的范圍內。 擴展GPU資源將支持更長的序列，這對于特定應用至關重要。
• 多token預測（MTP）集成：SGLang支持MTP，但缺乏與DP注意力的完全集成，降低了混合并行配置的效率。
• 專家并行負載均衡（EPLB）分布：本次實驗使用了專家并行負載均衡器（EPLB）的同分布數據，這可能無法反映真實場景中的數據變動。之后還需要研究出現分布偏移時的性能表現。
• 靈活的張量并行（TP）規模：對于DeepSeek-V3而言，稠密FFN的內存最優TP規模較小，但大于1。目前SGLang僅支持純TP或DP，導致內存利用率不高。之后還需要支持更靈活的TP選項。
• Blackwell支持：目前的實現僅支持NVIDIA Hopper架構。團隊正在努力將兼容性擴展到下一代Blackwell架構。