樊玉偉，鄭靈超，李勇鋒，區(qū)曉峰，李君，KenZhang，韓偉，李億杜霄鵬，王鵬程，劉杰，董谷音，梁泓，柳伊揚，廖崎臣，高雪健王鵬宇，趙毅，王翔，林棟，練韻文，林清揚，陳衎，龐西豹呂俊龍，蘭龍文，張維熹，丁益斌，高宇，陶壯，張弓，謝冬輝范港華，范峻逸，胡琤球，李寶，鄭樂文，陳付愷，申智好，金穎華為技術有限公司摘要本報告旨在探討華為昇騰服務器上部署DeepSeekV3/R1推理的最佳實踐。為滿足不同推理場景的需求，本文提供兩種不同的部署形態(tài)。第一種是基于華為CloudMatrix384超節(jié)點的大規(guī)模EP部署策略：為充分發(fā)揮CloudMatrix384的獨特組網(wǎng)優(yōu)勢，使用其中的144張卡作為一個Decode實例，以實現(xiàn)較低時延下的高并發(fā)，當前已達到了50ms時延約束下每卡輸出1920Tokens/s。第二種是基于Atlas800IA2服務器的小規(guī)模EP部署策略：使用4節(jié)點A2服務器作為一個Decode實例，以實現(xiàn)較優(yōu)吞吐下的靈活部署，當前達到了100ms時延約束下每卡輸出723~808Tokens/s。我們采用基于vLLM的部署框架，并面向昇騰服務器進行修改以適配EP/DP/TP混合并行策略，同時滿足靈活調度和極致性能的需求。模型層面，采用A8W8(INT8)的動態(tài)量化方式，并使用Multi-TokenPrediction技術進行加速。針對昇騰芯片和昇騰服務器組網(wǎng)特征，從數(shù)學上重新審視模型的推理過程，選用了合適的并行方式和計算邏輯，同時還充分利用了昇騰硬件支持多種多流并發(fā)的能力以最大化實現(xiàn)通信/計算/數(shù)據(jù)搬運的相互掩蓋，實現(xiàn)模型層面的性能極致。算子層面，提出了多種結合數(shù)學等價變換、融合算子、緩存復用和流水掩蓋等技術的計算和通信算子的優(yōu)化方案，使MLA、MoE和通信算子達到預期的算力利用率、訪存帶寬和通信帶寬。本報告將詳細介紹上述兩套部署方案，并列出關鍵的特性和優(yōu)化技術，更詳細的技術細節(jié)之后會陸續(xù)公開。11引言32昇騰服務器和組網(wǎng)52.1昇騰芯片 52.2Atlas800IA2服務器 52.3CloudMatrix384超節(jié)點 63DeepSeekV3/R1模型部署方案63.1模型與框架配置 63.2Atlas800IA2部署方案 83.3CloudMatrix384超節(jié)點部署方案 4框架側性能優(yōu)化144.1APIServer擴展技術 4.2MoE模型負載均衡 5模型側性能優(yōu)化155.1模型側通信優(yōu)化 5.2模型側并發(fā)方案 5.3推理投機框架FusionSpec 6昇騰算子性能優(yōu)化196.1MLA算子優(yōu)化 6.2MoE通信算子優(yōu)化 7性能分析217.1Altas800IA2性能分析 7.2CloudMatrix384超節(jié)點性能分析 8下一步工作252DeepSeekV3/R1作為業(yè)界領先的開源大語言模型，已在自然語言處理、代碼生成、知識推理等多個領域展現(xiàn)出卓越的應用價值。DeepSeek團隊于3月份推出了迭代版本DeepSeekDeepSeek-Prover-V2-671B[11]。這兩款新的模型與原始DeepSeekV3架構完全兼容，僅需進行參數(shù)差異化配置的權重調整，便可實現(xiàn)既有模型部署方案的無縫遷移。這一設計不僅降低了技術迭代的邊際成本，更有效擴大了DeepSeekV3系列模型的使用范圍。本報告分享當前在昇騰服務器上高性能DeepSeekV3/R1部署方案的最佳實踐，包括具體的部署方案和關鍵優(yōu)化特性的簡單介紹。關鍵優(yōu)化特性的詳細報告將于近期陸續(xù)發(fā)布。昇騰服務器有多種配置和型號，我們針對近期發(fā)布的CloudMatrix384超節(jié)點和Atlas800IA2推理服務器兩種典型機型進行部署。為了解耦Prefill階段的首token時延約束和Decode階段的解碼時延約束，同時希望針對不同場景選擇最優(yōu)的部署策略和計算流程，我們采用PD分離部署的方式。在框架側，以vLLM為基礎，針對DP、EP和TP并行策略做了相應適配，在KVCache傳輸方面采用了靈衢直聯(lián)的技術來降低開銷，在請求下發(fā)、調度策略和框架前后處理等方面做了性能優(yōu)化，以實現(xiàn)整個系統(tǒng)的最優(yōu)性能。模型方面，采用A8W8(INT8)的動態(tài)量化策略。針對昇騰芯片和昇騰服務器組網(wǎng)特征，從數(shù)學上重新審視模型的推理過程，并綜合考慮了數(shù)據(jù)搬運量、數(shù)據(jù)通信量、計算量和內存占用量，選用了合適的并行方式和計算邏輯，有效降低了模型推理過程中的通信和計算耗時；我們還充分利用了昇騰硬件的多流并發(fā)能力，實現(xiàn)通信-計算并發(fā)、通信-通信并發(fā)和通信-權重預取并發(fā)等多種加速技術，從而做到通信/計算/數(shù)據(jù)搬運的相互掩蓋，實現(xiàn)模型層面的極致性能。算子方面，我們針對DeepSeek模型的特點，提出了多種結合數(shù)學等價變換、融合算子、緩存復用、流水掩蓋等技術的極致優(yōu)化的計算算子和通信算子，特別是在MLA、MLA前序計算、Dispatch/Combine通算融合算子和指令級底層通信調度方面做了深入的優(yōu)化，以最大化利用昇騰的算力、訪存帶寬和通信帶寬。詳細的部署方面，由于兩種機型定位和配置不同，所以具體部署方案也不盡相同。3針對CloudMatrix384超節(jié)點，其特殊的組網(wǎng)方式使其具有很高的通信帶寬。按照DeepSeek的論文[16]所述，Decode部分是嚴重的通信瓶頸，在Micro-batch技術的加持下，幾乎可以做到通信掩蓋其他所有計算類操作。而CloudMatrix384的獨特組網(wǎng)使得通信耗時大幅降低，可以有效釋放昇騰芯片的算力，具體見第7.2節(jié)。因此，針對超節(jié)點我們采用大規(guī)模EP并行的方式來部署：Prefill使用16卡，Decode使用144卡。其中Decode部分使用128卡通過大規(guī)模EP的方式部署路由專家，16卡通過DP的方式部署共享專家，MLA部分使用DP的方式進行部署。按照類似于[16]的分析，超節(jié)點可以獲得非常高的理論吞吐。實際場景下，由于各種因素的影響，包括Decode時延的約束使得各部分耗時未能達到理想的線性度，帶寬搶占帶來一部分性能劣化，框架的耗時和調度開銷帶來了額外的時延增加，MLA部分的序列負載均衡和MoE部分的專家負載均衡帶來進一步的性能惡化；最后多種因素綜合在一起，使得當前吞吐如[19]所述，實現(xiàn)在保證50ms時延下單卡Decode吞吐達到1920Tokens/s。針對Atlas800IA2服務器，由于每個節(jié)點包含8張昇騰芯片，我們需要采用多節(jié)點互聯(lián)的方式來進行部署。綜合考慮模型吞吐和部署靈活性，我們選定使用2節(jié)點16卡作為一個Prefill實例，4節(jié)點32卡作為一個Decode實例。為了部署時盡可能的靈活，這里選用的卡數(shù)較少，這使得整個系統(tǒng)采用較小規(guī)模的EP并行策略：每張卡上部署8(Decode)/16(Prefill)個路由專家和1個共享專家。在Decode階段，MLA部分采用DP并行策略，通信方式采用AllGather/ReduceScatter方案。這種部署方式可以在卡數(shù)較少情況下依然達到相當可觀的吞吐。值得一提的是，真實負載下AllGather/ReduceScatter比Dispatch/Combine的通信方案具有更好的性能表現(xiàn)。綜合上述優(yōu)化方案，我們實現(xiàn)了在100ms時延下單卡吞吐達到723~808Tokens/s。本文結構安排如下：在第2節(jié)簡單介紹昇騰服務器相關的硬件信息，在第3節(jié)詳細介紹兩種不同機型下的部署方案，在第4,5,6節(jié)分別介紹框架層、模型層和算子層的優(yōu)化技術，在第7節(jié)給出兩種部署下的性能分析結果，最后列舉一些當前部署方案后續(xù)要增加的特性和優(yōu)化方案。42昇騰服務器和組網(wǎng)2.1昇騰芯片昇騰NPU芯片是華為推出的一系列高性能AI處理器，專為大規(guī)模AI訓練、高性能AI推理等任務設計。該系列芯片采用達芬奇架構[18]，具備強大的計算能力和高效的能效表現(xiàn)，能夠滿足深度學習模型訓練與推理、自然語言處理等多種應用場景的需求。該系列芯片分為多種型號，不同型號的性能不同，不同服務器會根據(jù)定位選用不同型號的芯片。2.2Atlas800IA2服務器昇騰Atlas800IA2推理服務器（下文簡稱為A2服務器或A2）一個節(jié)點包含8張NPU芯片，形成多機組網(wǎng)架構(圖1)，具有以下特點：?節(jié)點內拓撲：A2單節(jié)點內8卡NPU通過Fullmesh形成全互聯(lián)結構，通信總帶寬392GB/s。?節(jié)點間拓撲：A2節(jié)點間通過網(wǎng)絡交換機進行互聯(lián)，形成Stars結構，通信總帶寬50GB/s。圖1:Atlas800IA2服務器節(jié)點內和節(jié)點間組網(wǎng)。左圖：A2節(jié)點內全互聯(lián)；右圖：多節(jié)點間通過交換機實現(xiàn)互聯(lián)。節(jié)點間通信時，由于不同卡上的數(shù)據(jù)匯聚到同一個網(wǎng)絡通信接口上，共享總帶寬。所以如果模型需要部署在多個節(jié)點上時，需關注節(jié)點間通信量和通信次數(shù)，減少節(jié)點間帶寬對性能帶來52.3CloudMatrix384超節(jié)點CloudMatrix384超節(jié)點（下文簡稱為CM384）是基于靈衢高速互聯(lián)總線，滿足AI時代海量算力需求的大規(guī)模超節(jié)點集群(圖2)。CM384通過多卡緊耦合互聯(lián)，統(tǒng)一內存編址，統(tǒng)一標識，統(tǒng)一通信等技術，實現(xiàn)算力、互聯(lián)帶寬、內存帶寬的全面領先。因此，在CM384上進行網(wǎng)絡部署時，子節(jié)點間帶寬不再成為通信瓶頸，可考慮利用全部AI處理器的算力分布式部署，如全域的專家并行，以充分利用超節(jié)點高算力高帶寬的特性。圖2:CloudMatrix384超節(jié)點內卡間和多子節(jié)點間高速互聯(lián)。3DeepSeekV3/R1模型部署方案本節(jié)重點介紹DeepSeekV3/R1在昇騰服務器上的具體部署方案和調度策略?？紤]到Atlas800IA2和CloudMatrix384超節(jié)點的部署方案比較相似，我們將在第3.2節(jié)中詳細介紹Atlas800IA2上的部署方案，在第3.3節(jié)中介紹CloudMatrix384超節(jié)點上的部署方案相比Atlas800IA2的差異。3.1模型與框架配置3.1.1模型量化策略為適配昇騰芯片保證推理性能，這里采用SmoothQuant技術[15]對模型進行A8W8動態(tài)量化(權重激活均采用INT8量化數(shù)據(jù)類型)，計算過程的中間變量采用BF16。當前KVCache采用了BF16的數(shù)據(jù)類型進行存儲和計算，后續(xù)該量化策略會記為A8W8C16，即激活INT8、權重INT8和KVCacheBF16。63.1.2Prefill和Decode分離部署大模型推理過程主要分Prefill和Decode兩個階段。Prefill階段通常是計算瓶頸，而Decode階段通常是帶寬瓶頸和通信瓶頸，這導致兩者的最佳部署策略往往不同。此外，由于權重吸收的技術，MLA模塊在Prefill和Decode階段的計算邏輯是不同的，部署在同一實例上會導致額外的權重占用。另一方面，由于實際服務時對首Token時延(TTFT)和Decode時延(TPOT)的要求，如果在同一套硬件上部署Prefill和Decode，導致該系統(tǒng)要同時滿足TTFT和TPOT兩個指標，這會導致整體吞吐難以達到最優(yōu)。綜合上述原因，如果采用Prefill和Decode分離部署的方式，可以更好的獲得兩階段的極致性能，并更好的滿足實際需求。所以本報告中我們總是基于Prefill和Decode分離的方式進3.1.3服務框架配置vLLM[8]是當前較為流行的開源大模型推理框架，我們以此為基礎來對大模型進行部署。為適配PD分離，并獲得極致的性能，我們在框架側做了相應的適配：圖3:基于PD分離部署的vLLM框架調度示意圖。7?Prefill調度分桶：基于vLLM框架，結合請求長度與KV親和性調度策略，根據(jù)任務特性動態(tài)優(yōu)化資源分配，顯著提升了在高并發(fā)場景下的推理性能；?靈衢互聯(lián)與分層傳輸：在KVCache傳輸上，我們采用了靈衢互聯(lián)與分層傳輸?shù)男问剑瑏斫档蚄VCache傳輸時延。為了支撐大規(guī)模EP、小規(guī)模EP、DP和TP等并行策略，我們對框架做了相應的修改和適配。同時為了支持超高并發(fā)（10K以上需要較為極致的性能優(yōu)化，這部分在第4節(jié)框架優(yōu)化部分會詳細介紹。3.2Atlas800IA2部署方案在Atlas800IA2的部署上，綜合考慮模型吞吐和部署靈活性，我們在Decode階段僅使用32卡進行部署，Prefill階段僅使用16卡部署。如果Decode要達到高吞吐，或Prefill要支持長序列，則意味著高內存占用，這導致內存可能會成為關鍵瓶頸，所以具體的部署策略上要特別注圖4:圖4:DeepSeekV3/R1主體網(wǎng)絡架構。PrefillDecodeMLATP16DP32DenseFFNDP16DP4+TP8路由專家EP16EP32共享專家DP16DP4+TP8EmbeddingTP16DP4+TP8LMHeadTP16DP4+TP8表1:Altas800IA2的PD分離部署。DeepSeekV3/R1模型共有61層（圖4）和額外的一層MTP層，每層包括MLA模塊和DenseFFN/MoE模塊。整體部署策略如表1所示。總體來說，MoE部分均采用EP部署策略，其中共享專家部分采用DP4+TP8并行，MLA部分在Prefill和Decode部分因其核心邏輯的差異導致采用不同的部署策略。此外，稠密層FFN、Embeding和LMHead部分均為了節(jié)省內存采用DP4+TP8的部署策略。下面詳細介紹各模塊的部署方案。83.2.1多頭潛在注意力（MLA）DeepSeekV3/R1使用了獨特的MLA進行KVCache壓縮。不同于傳統(tǒng)的MHA[14]，MLA的多個頭共用壓縮后的KVCache。在Decode階段，對MLA用TP無法節(jié)省內存,反而會導致KVCache的大量重復搬運；而在Prefill階段，矩陣乘計算取代數(shù)據(jù)搬運成為主要性能瓶頸，DP與TP的計算量相同，但TP可以獲得一定的內存收益。內存分析單張卡上MLA部分的內存占用可以描述為：Memory=++Memory激活,其中W是模型MLA部分的權重大小。在Decode階段,KVCache會占據(jù)大量內存(卡均72并發(fā)，序列長度為4K時，KVCache內存占用接近20GB)。由于MLA的多頭共享KVCache機制，傳統(tǒng)的TP（head軸切分）部署并不能降低單卡KVCache占用，因此全DP部署是最節(jié)省內存的并行部署方式。而在Prefill階段，并發(fā)數(shù)較小，序列長度較大，權重（約11.6GB)和激活內存（總token數(shù)為16384場景下，約1GB）占據(jù)了大部分內存，更適合采用TP的方式進行部署。因此，我們對Prefill和Decode采取不同的部署策略。Prefill我們采用Attention前序計算DP16，AttentionTP16,Attention后序計算DP8+TP2的混合部署策略，流程圖示見圖5b。具體而言：?在Q、K、V降維階段采用DP16部署，這部分模型權重數(shù)量較少，使用DP不會占用過多內存，且降維后的Q、K、V可以最大程度降低切換到TP所引入的通信開銷;?在Q、K、V升維以及Attention計算階段采用TP16部署，顯著降低算子激活內存;?Output投影矩陣采用DP8+TP2,能顯著降低TP轉換為DP的通信量,具體技術見Decode此時MLA的性能瓶頸主要在權重和KVCache搬運，其中KVCache搬運為主要耗時。因此，我們采用業(yè)界主流的DP32與權重吸收[5]的部署方式，避免KVCache重復搬運，降低Attention算子的耗時。9(a)Prefill稠密層(b)PrefillMLA圖5:左：Prefill稠密層使用DPDenseFFN提升Prefill性能，避免引入額外通信。右：Prefill的MLA部分使用DP-TP16-TP2的方式部署。其中，我們選擇在Q、K、V降維之后進行DP-TP轉換，最大程度降低通信量。Attention采用TP16，最后對Output投影矩陣計算(圖中的OProj)使用DP8+TP2。注：簡潔起見，圖中忽略了RoPE和RMSNorm部分的計算。3.2.2DenseFFNPrefill此時性能瓶頸是矩陣乘的計算量。注意到無論使用DP或者TP，計算量都保持不變,但是使用TP會引入額外的通信，且全TP在長序列場景下的矩陣乘法的維度對計算硬件不親和，影響矩陣乘計算性能。因此，我們對DenseFFN采用全DP的部署方式。Prefill階段稠密層的計算流程見圖5a。Decode此時性能瓶頸是權重搬運。綜合考慮FFN性能和通信耗時，以及權重所需內存（總共約1.1GB)，我們采取DP4+TP8的部署策略。Decode階段稠密層的計算流程見圖6。3.2.3混合專家（MoE）路由專家DeepSeekV3/R1龐大的專家數(shù)量對內存提出了巨大挑戰(zhàn)。每個專家在總共58層共占權重約2.5GB，而每張Atlas800IA2昇騰卡的內存大小是64GB。因此，我們在Prefill和Decode階段都采用了業(yè)界主流的EP并行部署策略，即將256個路由專家平均地部署到所有昇騰卡上。對于Prefill節(jié)點而言，每張卡上需要部署16個路由專家；Decode節(jié)點上每張卡部圖6:Decode階段稠密層采取DP32MLA+節(jié)點內TP8DenseFFN的部署方式。MLA使用DP32可以避免KVCache的重復搬運，且有效降低了單卡的內存壓力。DenseFFN采用了節(jié)點內TP8，避免過高的通信代價，同時能夠部分降低單卡載入的權重（約1GB）。注：簡潔起見，圖中已忽略各處的RMSNorm計算。署8個路由專家。這種部署方式很大程度上減輕了單卡的內存壓力和計算量，但同時也引入了別的挑戰(zhàn)如MoE前后的通信開銷（見第5.2節(jié)）和專家負載不均衡（見第4.2節(jié)）。共享專家通常場景下，我們選擇對共享專家應用全DP的并行策略。在長序列的場景下，內存成為提升吞吐的瓶頸之一，我們可以選擇對共享專家應用節(jié)點內TP8的并行策略，這能節(jié)省約2.1GB內存。兩種場景下，共享專家的計算都與路由專家的通信操作并發(fā)掩蓋?？傮w流程Decode節(jié)點MoE層的具體計算流程請見圖7。由于Prefill的流程與Decode高度相似（共享專家部署略有不同），這里不另展示Prefill的流程圖。3.2.4Embedding和LMHeadDeepSeekV3/R1模型一開始的Embedding和模型最后的LanguageModel(LM)Head都涉及對一個巨大的形狀為(129280,7168)的BF16數(shù)據(jù)格式的字典映射/矩陣乘，權重大小均為1.7GB，共約3.5GB。在Prefill節(jié)點上，我們采取TP16的部署方式；而在Decode節(jié)點上，我們采取類似DenseFFN的DP4+TP8的部署方式。這部分減少內存占用約3GB，但需要引入額外的節(jié)點內通信操作。圖7:Decode節(jié)點稀疏層的計算流程。MLA部分和稠密層一樣采取DP32的方式，降低KVCache搬運量。MoE部分使用EP32的部署策略。首先對MLA的輸出使用AllGather通信，所有路由專家計算完畢后，使用ReduceScatter分發(fā)結果給下一3.3CloudMatrix384超節(jié)點部署方案本節(jié)介紹我們在CM384上設計的部署策略。PrefillCM384在Prefill階段的部署方案與Atlas800IA2基本相同，主要差異是，在CM384上MoE模塊的通信方式為All2All。CM384的子節(jié)點間通過交換設備形成無收斂高速互聯(lián)（第2.3節(jié)因此在CM384上采用All2All方案，比AllGather+ReduceScatter的方案（圖6）性能更優(yōu)。Decode由于DeepSeekV3/R1模型的路由專家數(shù)量多，在Decode階段，MoE模塊的主要性能瓶頸為權重搬運。EP的規(guī)模越大，意味著每個子節(jié)點需要搬運的專家權重越少，但代價是通信時延的增加。在CM384上，子節(jié)點間的互聯(lián)帶寬相比Atlas800IA2大大提高，這使得大規(guī)模的EP部署成為可能。在Decode階段，我們用18個CM384子節(jié)點（共144卡）進行部署。具體部署方案與Atlas800IA2的對比如下：1.MLA模塊的部署方案與Atlas800IA2基本相同，采用DP。但在Output投影矩陣部分，CM384Decode稠密層子節(jié)點1~18NPU1&2NPU3&4NPU5&6NPU7&8DPMLADPMLADPMLADPMLADPMLADPMLADPMLADPMLAAllGatherAllGatherAllGatherAllGatherAllGatherAllGatherAllGatherTP2DenseFFNTP2TP2DenseFFNTP2DenseFFNTP2DenseFFNReduceScatterReduceScatterReduceScatterReduceScatterReduceScatterReduceScatterReduceScatter圖8:CM384Decode階段稠密層部署方式為全DPMLA和TP2DenseFFN。在CM384Decode子節(jié)點上，稠密層的MLA整體上采取全DP的部署方式，最后的Output投影矩陣采用TP2（圖中的O-proj）。不同于Atlas800IA2上的TP8，基于CM384的組網(wǎng)特點（第2.3節(jié)我們在FFN層采取了TP2的部署方式。CM384Decode稀疏層子節(jié)點2子節(jié)點3子節(jié)點子節(jié)點2子節(jié)點3子節(jié)點18…………………DispatchAll2All路由專家路由專家路由專家共享專家路由專家路由專家路由專家共享專家共享專家共享專家共享專家…………CombineAll2All圖9:CM384Decode階段稀疏層部署方式為DPMLA和EP144MoE。在CM384Decode子節(jié)點上，稀疏層的MLA整體上采取DP的部署方式，最后的Output投影矩陣采用TP2（圖中的O-proj）。MoE采取EP144的部署方式，共享專家也被當做路由專家處理[6]。在18個CM384子節(jié)點中，2個子節(jié)點以DP的方式部署共享專家；其余16個子節(jié)點用于部署路由專家，每張卡部署兩個專家。由于通信性能更高，CM384采用了TP2。2.Atlas800IA2上節(jié)點內是Fullmesh組網(wǎng)，TP2/TP4無法充分利用帶寬，但CM384上子節(jié)點內是通過交換設備互聯(lián)，不存在這一問題。因此，不同于Atlas800IA2的TP8，CM384上稠密層FFN的并行策略采取TP2（見圖8）。3.與Prefill相同，CM384上MoE模塊采用了All2All的通信方式（見圖9并且將共享專家看做一個必選的路由專家[6]，部署到單獨的NPU上。由于每個Token會選擇8個路由專家和1個共享專家，因此單獨部署時，共享專家的數(shù)量應為路由專家的8分之1。在18個CM384子節(jié)點的144張NPU中，128張用于部署路由專家，其余16張卡用于4.對于Embedding模塊，由于CM384上采用了EP144，內存壓力小，沒有使用TP；而在LMHead部分，由于TP切分可以減小每張卡上的權重搬運，帶來性能收益，我們最終采用了TP8。4框架側性能優(yōu)化為了實現(xiàn)DeepSeekV3/R1的高吞吐，需要框架支持10K甚至更高的并發(fā)度。為此我們需要對框架進行增強，通過性能優(yōu)化和多Server并發(fā)等來降低框架側耗時。我們在vLLM的以下關鍵環(huán)節(jié)進行了深度優(yōu)化：1.請求下發(fā)：支持下發(fā)水平擴展，結合負載均衡機制，降低轉發(fā)時延。2.調度策略：采用請求長度感知與KVCache親和等高級調度策略，實現(xiàn)負載均衡與資源高3.系統(tǒng)建鏈：簡化系統(tǒng)通訊鏈路，在保證穩(wěn)定性的前提下去除所有非必要鏈路。4.前后處理：多核全并行、全異步的高效前后處理，降低NPU閑置率，確保推理結果快速返回，降低端到端延遲。4.1APIServer擴展技術當前單節(jié)點APIServer部署存在故障風險。在昇騰服務器高性能架構下，高并發(fā)請求易使單點APIServer成為性能瓶頸，導致響應延遲增加，NPU算力資源浪費。因此我們做了如下優(yōu)化：?APIServer水平擴容策略：通過GlobalProxy組件插件化實現(xiàn)KVCache親和、負載均衡及序列長度調度優(yōu)化，提升請求處理能力和系統(tǒng)吞吐量（QPS降低用戶請求延遲。?組網(wǎng)方案優(yōu)化：從APIServer與DP全連接簡化為1:1組網(wǎng)，減少通訊開銷，增強系統(tǒng)魯棒性。整體方案顯著提升TTFT提高推理服務可用性與效率，充分發(fā)揮昇騰算力，為高并發(fā)場景下的大模型推理服務提供可靠支持。?全并行、全異步前后處理，并結合Multi-Step技術進一步降低Decode前后處理耗時；Prefill部分支持動態(tài)進程前后處理降低TTFT。4.2MoE模型負載均衡針對混合專家（MoE）模型推理中的“冷熱專家”問題，我們提出高效負載均衡策略，解決負載不均、推理延遲高及吞吐量低等痛點。通過專家重排、分層冗余部署和近實時調度，顯著提升推理性能，具體包括：?動態(tài)負載均衡：基于激活數(shù)據(jù)與計算均衡，動態(tài)調整專家部署，縮小通信域，優(yōu)化后結果靜態(tài)負載均衡的收斂性與負載均勻性。?熱專家冗余部署：為高頻專家分配冗余實例，結合實時資源預測，降低通訊開銷，從而提?實時調度：動態(tài)調整專家分配，實現(xiàn)快速收斂、適應輸入變化的同時，保持低延遲。?動態(tài)監(jiān)控：獨立流監(jiān)控激活數(shù)據(jù)，不干擾推理，確保高魯棒性。5模型側性能優(yōu)化5.1模型側通信優(yōu)化大模型多卡部署時，卡間并行方式包括數(shù)據(jù)并行（DP）、張量并行（TP）、專家并行（EP）等。不同的卡間并行方式對多卡間通信方式和通信算子有著不同的需求，從而影響模型部署時的通MoE層整體通信策略針對Altas800IA2的組網(wǎng)架構，我們采用AllGather和ReduceScatter來進行MoE層前后的數(shù)據(jù)通信，而非經(jīng)典的EP部署下的All2All。這是因為節(jié)點間通信帶寬相較節(jié)點內的較低。當單卡的并發(fā)數(shù)為BS時，若采用AllGather通信，單卡需要進行節(jié)點間通信的數(shù)據(jù)量為BS×3×hidden__size。作為對比，若采用All2All方案，單卡平均需要進行節(jié)點間通信的數(shù)據(jù)量為BS×6×hidden__size。同時All2All方案的通信數(shù)據(jù)量會受到專家負載不均的影響，不如AllGather/ReduceScatter方案穩(wěn)定。結合細粒度分級流水算法(第6.2節(jié))，AllGather/ReduceScatter方案可以做到節(jié)點間通信耗時幾乎被節(jié)點內通信耗時掩蓋。另一方面，采用AllGather的分發(fā)模式，AllGather通信可以和Gating函數(shù)的計算解耦，實現(xiàn)計算通信并發(fā)，詳見第5.2節(jié)。綜上所述，在Altas800IA2的32卡部署方案中，我們采用了AllGather/ReduceScatter來進行MoE層前后的數(shù)據(jù)通信。FlashComm主流張量并行（TP）[12]中使用AllReduce進行通信的方案存在通信次數(shù)多、通信數(shù)據(jù)量大等問題，且AllReduce之后的殘差連接和歸一化計算存在計算冗余，沒有充分利用多卡并行能力。為此，我們提出FlashComm網(wǎng)絡通信方案：在Prefill階段針對DeepSeekV3/R1網(wǎng)絡MLA層前后的AllReduce通信，基于相同的集合通信邏輯將張量并行中的AllReduce通信算子進行替換，并對通信算子在網(wǎng)絡中的位置進行編排，實現(xiàn)了低比特和低維度數(shù)據(jù)通信，從而有效降低了通信數(shù)據(jù)量和通信時延，并消除了網(wǎng)絡中存在的冗余計算。FlashComm技術應用于DeepSeekV3/R1模型Prefill階段，降低25%的通信量，提升10%的推理性能。層內并行轉換技術在FlashComm的基礎上，為進一步優(yōu)化通信算子的時延，我們提出層內并行轉換的優(yōu)化技術：針對Prefill階段網(wǎng)絡MLA層的節(jié)點內通信，我們重新設計了MLA層內的多卡并行策略，實現(xiàn)張量并行（TP）與數(shù)據(jù)并行（DP）[9]的靈活轉換，消除了節(jié)點內卡間求和的需求，且充分利用網(wǎng)絡中低維度數(shù)據(jù)和量化特性實現(xiàn)節(jié)點內通信量的大幅降低，從而顯著優(yōu)化了通信時延。層內并行轉換技術應用于DeepSeekV3/R1模型Prefill階段，降低71%的節(jié)點內通信量，提升10%以上的推理性能。5.2模型側并發(fā)方案昇騰芯片支持多種計算資源如張量計算單元、向量計算單元，以及通信資源的并發(fā)使用，這為盡可能發(fā)揮昇騰硬件的算力和帶寬提供了支持。我們針對DeepSeekV3/R1模型的架構進行了細致的流水編排，從而盡可能利用硬件資源，實現(xiàn)極致的性能。具體來講，包含如下幾項技術：通信通信并發(fā)昇騰芯片提供了通信和通信并發(fā)的機制。當通信帶寬利用率比較低的時候，可以把兩個通信算子并發(fā)起來以掩蓋通信算子的啟動開銷，同時提高通信帶寬的利用率。在DeepSeekV3/R1模型中，我們將Norm算子和量化算子移到AllGather通信前，從而降低通信的數(shù)據(jù)量，進而提高通信的效率。由于量化算子的前移，需分別通信量化后的激活值和量化Scale，進而增大了通信算子啟動開銷。由于量化Scale的數(shù)據(jù)量較小，對帶寬的占用較低，因此我們采用通信通信并發(fā)的機制，將通信激活值和通信量化Scale并發(fā)起來，在不增加激活值通信開銷的前提下，掩蓋掉量化Scale的通信開銷。計算通信并發(fā)昇騰芯片也提供了計算和通信的并發(fā)機制。MoE層的計算過程需要使用AllGather匯聚各張卡上token的特征，以進行激活專家的篩選和計算。但Gating函數(shù)無須依賴AllGather匯聚的結果。因此，對Gating函數(shù)使用先計算后通信的方法，對共享專家使用DP部署，從而保證Gating函數(shù)的計算和通信、共享專家的計算，以及特征匯聚的AllGather通信之間解耦。我們利用昇騰的多流機制，將這三部分進行并發(fā)處理，從而最大化推理模型的性能。結合通信通信并發(fā)技術可以實現(xiàn)極致的流水編排（參見圖10）。此技術在DeepSeekV3/R1模型在大并發(fā)下可以實現(xiàn)Decode性能提升15%。通信和權重預取的并發(fā)昇騰芯片提供了緩存機制，算子在進行計算時，會優(yōu)先從緩存中尋找數(shù)據(jù)，如果命中，則直接從緩存中讀取數(shù)據(jù)，否則從HBM中讀取數(shù)據(jù)，而緩存的帶寬是HBM帶寬的數(shù)倍。由于通信算子進行過程中HBM帶寬占用率較低，我們在通信算子的進行過程中可以將后續(xù)算子需要的權重提前預取到緩存中，從而降低后續(xù)算子計算過程中的權重搬運開銷。同時昇騰芯片支持限定預取帶寬，因此在通信過程中預取對通信性能影響很小。對于DeepSeekV3/R1模型，我們在MoE模塊末尾的ReduceScatter預取下一層MLA模塊中的權重和KVCache，提升了MLA約10%的性能。圖10:DecodeMoE層計算通信并發(fā)和通信通信并發(fā)。利用昇騰多流機制，使能Gating函數(shù)計算和通信，激活值的AllGather通信，共享專家計算進行通信計算并發(fā)。量化后激活值和Scale的通信，路由專家門控系數(shù)和Index的通信進行通信和通信并發(fā)5.3推理投機框架FusionSpec在大模型推理優(yōu)化領域，投機推理是一種極具潛力的技術路徑：其通過引入輕量模型或外部知識數(shù)據(jù)，為大模型生成推理草稿，從而在解碼階段一次推理多個token，提升了計算密度。以DeepSeekV3/R1模型[6]為例，其創(chuàng)新性地引入MTP（Multi-TokenPrediction）投機層，實現(xiàn)了投機推理技術的落地。投機推理在模型解碼階段的高計算密度天然匹配昇騰高算力帶寬比的特點。為了充分發(fā)揮這一優(yōu)勢，在低時延大并發(fā)場景下實現(xiàn)高吞吐，我們提出了投機推理框架FusionSpec，包括投機流程及投機算子性能的優(yōu)化技術，持續(xù)提升MTP在昇騰上的推理性能，使得MTP部分框?流程拼接：在推理流程上，將投機模型置于主體模型之后，直接使用主體模型的輸出，并復用主體模型的控制參數(shù)，大幅減少了框架耗時，適配PD分離的部署場景。?輕量步間準備：在投機場景中針對框架與算子優(yōu)化，實現(xiàn)了輕量步間準備，適配多核并行全異步框架，降低端到端時延。6昇騰算子性能優(yōu)化6.1MLA算子優(yōu)化Attention算子MLA相較于傳統(tǒng)的Attention（如MHA,GQA類在Decode階段顯著帶寬瓶頸的算子由于其中間變量膨脹且計算量顯著增加，為算子優(yōu)化帶來了新的挑戰(zhàn)。針對昇騰處理器的架構特性，我們借鑒了Flash-Attention的思想[2,3]，對MLA場景的Attention算子[5,6]進行了計算過程的優(yōu)化，以及硬件親和的性能優(yōu)化。主要包括以下幾點：?提出AMLA（AscendMLA）算法，通過浮點二進制編碼解析及存內計算能力實現(xiàn)乘性計算的加性等價轉換，從而實現(xiàn)直接在內存上更新輸出矩陣O的步驟，無須進入向量計算單元，大幅降低中間變量的重復搬運。?根據(jù)[2,3]的思想，對L1緩存進行了細致規(guī)劃，盡可能地減少數(shù)據(jù)重復搬入搬出的過程。?在工程實現(xiàn)方面，通過優(yōu)化計算流程提高L2緩存命中率及數(shù)據(jù)復用率，并且利用K-buffer流水排布等策略，實現(xiàn)張量計算和向量計算互相掩蓋；使能昇騰硬件親和的數(shù)據(jù)排布，提高了算子整體性能。上述優(yōu)化方案提升Attention算子性能接近1倍，非MTP場景算力利用率達到55%，使用一個MTP模塊場景算力利用率達到60%。MLA前序算子針對復雜的MLA前序算子，我們分別在Prefill階段和Decode階段采取了?在Prefill階段，我們通過雙流并發(fā)等技術實現(xiàn)了流水掩蓋，同時增加了Attention算子對多種輸入輸出模式的支持以消除純訪存類冗余算子。?在Decode階段，我們采用權重吸收，同時將前序算子深度融合為MLAProlog算子，并且針對昇騰硬件架構進行了全方位的深度優(yōu)化。具體優(yōu)化措施包括：采用權重預取減少流水線空泡；基于最小化搬運以及最大化帶寬的Tiling策略；通過計算解耦減少依賴；利用局部計算融合消除全核同步開銷等。基于上述優(yōu)化方案，MLAProlog算子性能提升30%6.2MoE通信算子優(yōu)化Dispatch/Combine通算融合算子在EP部署模式中，MoE中的專家分布在通信域的各個卡上，每個token需要分發(fā)到對應的卡上進行計算。原始的方案使用InitialRouting根據(jù)專家排序對所有token進行重排，再利用兩次通信算子（All2All以及All2Allv）完成token分發(fā)。該方案在通信域比較大的場景下，存在通信次數(shù)多，卡間同步開銷大等問題，導致端到端時延增加。針對此問題，我們提出MoEDistributeDispatch和MoEDistributeCombine兩個通算融合算子：將計算和通信拆解為token粒度，通過流水排布實現(xiàn)兩者的并行執(zhí)行；利用內存語義的通信技術直接向不同卡上的內存?zhèn)鬏敂?shù)據(jù)，從而減少了本地拷貝和等待數(shù)據(jù)的開銷；通過本地內存篩選和拷貝的機制，減少了數(shù)據(jù)傳輸次數(shù)和卡間同步開銷。SMTurbo-CPP針對MoE層大通信域場景下，小數(shù)據(jù)量傳輸效率低的問題，我們提出SMTurbo-ConcurrentPushandPull（SMTurbo-CPP）技術：在內存語義級別對通信算子All2All(v)進行優(yōu)化，充分利用硬件并發(fā)能力，使用讀寫混合、聚合流水、批量檢測等技術，提升了線程的訪存效率與吞吐，顯著降低Dispatch和Combine場景通信算子的時延。實測可降低Dispatch/Combine算子8%-20%的推理時延。細粒度分級流水算法Atlas800IA2服務器通信協(xié)議支持細粒度的分級流水算法，可大幅提升AllGather、ReduceScatter、All2All等集合通信算子的執(zhí)行效率[17]。該算法利用A2組網(wǎng)的特性，實現(xiàn)了節(jié)點內/節(jié)點間通信的并發(fā)執(zhí)行以提高帶寬利用率。采用細粒度分級流水算法后的AllGather和ReduceScatter,在4節(jié)點時，可以達到節(jié)點間通信耗時被節(jié)點內通信耗時幾乎完全掩蓋。在Decode4節(jié)點部署/Prefill2節(jié)點部署場景中，其性能相較All2Allv具有更大優(yōu)圖11:細粒度分級流水算法[17]，每次Server間傳輸過來的數(shù)據(jù)，在下一個步驟將此數(shù)據(jù)用于Server內傳輸，同時獲得下一份Server間的數(shù)據(jù)，以此類推。7性能分析7.1Altas800IA2性能分析7.1.1Decode性能A2Decode的測試方式為：?序列長度為2K輸入+2K輸出/1K輸入+2K輸出。?在使能MTP進行推理加速的情況下，由于不同測試數(shù)據(jù)集和業(yè)務場景的MTP接受率不同，性能測試結果會有比較大的偏差。因此在計算時延和吞吐的時候默認按照70%接受?TPOT（Decode平均每token時延）不超過100ms。對于序列長度是2K輸入+2K輸出的情形，每卡平均并發(fā)數(shù)為72，此時端到端耗時為99.6ms，卡均吞吐為723Tokens/s。具體數(shù)據(jù)詳見表2。圖12中詳細拆解了每個模塊的耗時，可以看出：?由于MLA的Attention算子，尤其在使能MTP時，計算密度遠高于GQA和MHA，與MQA相當，此時MLA的計算不再是完全帶寬瓶頸。我們通過第6.1節(jié)中的優(yōu)化方案，當前的算子實現(xiàn)可以達到55%的算力利用率。輸入長度輸出長度單卡并發(fā)數(shù)不同接受率吞吐(Tokens/s)70%80%90%2K2K7237658081K2K784830876表2:Altas800IA2的Decode性能：在不同MTP接受率和不同序列下的單卡吞吐。圖12:Atlas800IA2的Decode在序列長度2K+2K，卡均72并發(fā)的各模塊耗時拆解。?卡均72并發(fā)，且使用一個MTP模塊時，MoE中的全連接層中，每個專家激活的token數(shù)是72×2×8×32/256=144，對于昇騰硬件而言，這還是一個相對帶寬瓶頸的場景，算力利用率不高。未來使用更大規(guī)模的EP部署方案，可以進一步提高單卡并發(fā)數(shù)，提高MoE模塊的算力利用率。?由于采用了AllGather和ReduceScatter來作為通信方式，而非All2All方案，所以通信數(shù)據(jù)量不隨著真實的專家負載變化，負載不均僅通過MoE路由專家計算不均來影響性能，對整體性能的影響相對較小。?根據(jù)DeepSeek披露的數(shù)據(jù)[16]，MTP接受率可達80%~90%。如果按照90%的MTP接受率來估算，2K輸入+2K輸出的Decode單卡吞吐可達808Tokens/s。7.1.2Prefill性能A2Prefill的測試方式為：單batch輸入序列長度為2K/1K，通過拼batch的方式拼成一共16K序列。對于序列長度是2K，共8batch拼成一共16K序列的場景，端到端耗時為631ms，卡均吞吐為1622Tokens/s。具體的數(shù)據(jù)見表3，具體的拆解數(shù)據(jù)見圖13。分析如下：輸入長度總并發(fā)數(shù)單卡吞吐2K81K表3:Altas800IA2的Prefill性能。圖13:序列長度8×2K,Prefill階段各組件的耗時占比。?Prefill階段除了MoE層前后的AllGather和ReduceScatter之外，由于我們MLA部分采用了TP16的部署策略，所以這里也存在AllGather和ReduceScatter通信過程。?由于在Output投影矩陣部分采用了第5.1節(jié)中提到的層內并行轉換技術，我們在Prefill階段也存在All2All通信過程。?雖然采用了AllGather和ReduceScatter通信方式，在負載不均時MoE部分的通信數(shù)據(jù)量是不受MoE負載不均影響的。不過負載不均會導致不同卡的MoE部分計算時間不同，不同卡間等待的過程在當前的統(tǒng)計方式里會表現(xiàn)在通信的耗時上。?當前為了部署的靈活性，同時考慮到實際場景Prefill難以拼到足夠的并發(fā)數(shù)，我們采用了16卡部署，MLA選擇TP16，所有卡的序列長度之和為16K的一種方案。如果采用DPMLA的部署方式，則可以減少MLA前后的通信，同時如果采用更大的并發(fā)數(shù)，可以進一步提高MoE部分的算力利用率。同時根據(jù)[13]，大并發(fā)的Prefill階段采用Micro-batch(Two-batchOverlap)技術可以得到相當大的吞吐收益，甚至可以完全掩蓋通信。據(jù)此計算，Altas800IA2在Prefill階段可達到卡均3095Tokens/s的吞吐。7.2CloudMatrix384超節(jié)點性能分析DeepSeek團隊基于H800的算力、帶寬和網(wǎng)絡互聯(lián)帶寬，給出了DeepSeekV3/R1模型的理論分析[16]。由于H800高單卡算力帶寬，而低網(wǎng)絡帶寬的特性，作者使用Micro-batch技術，提出利用Dispatch/Combine掩蓋其余所有計算的方案，并給出了理論的耗時估計。昇騰CloudMatrix384超節(jié)點由于其獨特的網(wǎng)絡互聯(lián)使得其通信方面具有顯著優(yōu)勢，這使得在CM384上我們不再是通信瓶頸?；诖?，可以設計不同的Micro-batch掩蓋策略：使用MLA中Attention計算掩蓋其他部分，包括其他計算部分。根據(jù)當前MLA的實現(xiàn)（當前MTP的MLA算子接近60%的算力利用率并考慮到使用MLA計算掩蓋其余部分會帶來35%左右的性能劣化，以3K序列長度為例，估算單層MTP的MLA的耗時大約為這里BS表示單卡的并發(fā)數(shù)，從而按照70%的MTP接受率來算的話，整個網(wǎng)絡的耗時接近如果不限制Decode時延，理論吞吐可以達到在實際部署的時候，由于多種因素的影響，實際可達吞吐會大幅打折。一個關鍵原因是Decode時延的約束限制了實際使用的并發(fā)數(shù)，使得各部分耗時未能達到理想的線性度，導致可達吞吐的大幅下降。另一方面，帶寬搶占帶來的惡化不可忽略，實際上上述評估中需要使用MLA來掩蓋MoE等其他計算部分，這里會發(fā)生嚴重的HBM帶寬搶占導致整體帶寬利用率下降?？蚍值男蛄胸撦d均衡和MoE部分的專家負載會分別使得MLA和MoE部分耗時增加，導致進一步的性能惡化。這些因素結合在一起，使得當前吞吐明顯低于理論值。2025年4月，硅基流動聯(lián)合華為云基于CloudMatrix384超節(jié)點昇騰云服務，采用與本報告完全相同的大規(guī)模專家并行方案正式上線DeepSeek-R1。該服務在保證單用戶20TPS（等效50ms時延約束）水平前提下，單卡Decode吞吐突破1920Tokens/s。[19]圖14:2025年4月，硅基流動聯(lián)合華為云基于CloudMatrix384超節(jié)點上線DeepSeek-R1，單卡Decode吞吐突破1920Tokens/s.8下一步工作當前已經(jīng)完成了在昇騰服務器上部署DeepSeek-V3/R1模型的方案，后續(xù)還有一些工作需要完善，以進一步提升性能和支撐更多場景：?低時延場景的極致優(yōu)化：本報告中的部署方案主要瞄準高吞吐場景，暫未針對低時延場景進行極致優(yōu)化。基于當前的部署方案，CloudMatrix384超節(jié)點在卡均8并發(fā)下時延為15ms，Atlas800IA2服務器上的方案在卡均4并發(fā)下時延為30ms。實際上當前的整體部署方案、算子優(yōu)化和模型并行優(yōu)化策略均未針對低時延下做優(yōu)化，也并未使能多層MTP，還有很大的優(yōu)化空間。?Micro-batch優(yōu)化方案：在DeepSeek公布的DeepEP方案[1,13]中，提出通過將數(shù)據(jù)拆分為兩個Micro-batch的思路，實現(xiàn)了通信和計算的相互掩蓋。該技術可以預見地會有較大的性能收益，尤其在高并發(fā)的Decode和Prefill場景。當前在CloudMatrix384超節(jié)點的部署上已經(jīng)采用了該技術，但在Altas800IA2上還未有效使用。接下來我們會基于Altas800IA2進行適配以及更極致地優(yōu)化。?低比特量化方案：當前模型采用的是A8W8C16的量化模式。對于MLA而言，其計算密度遠大于經(jīng)典的GQA方案，所以傳統(tǒng)的KVCache量化[7,10]只能保證較大的內存收益，能帶來的性能收益有限。因此我們也在探索一些將Q/K/V全部量化的計算方案，如果可以給出滿足精度要求的量化方案，會給Attention計算帶來可觀的加速效果。另外，針對低時延場景，Decode部分是強訪存帶寬瓶頸，如果對MoE部分使用A8W4或A4W4的量化方案，可有效降低訪存帶寬需求量，從而大幅提升性能。因此我們需要探索針對MoE部分INT4的量化技術。?MLA層算子量化支持：在長序列下KVCache量化可以大幅減少推理過程中的內存占用，我們將同步進行Attention及MLAProlog算子針對僅KVCache的INT8量化和Q/K/V全INT8量化場景的適配，通過深度的算子重構與極致流水優(yōu)化保證性能。?Altas800IA2的更大EP部署方案：對于Altas800IA2，當前采用的是32卡的部署策略，每張卡的路由專家個數(shù)是8個，這帶來了不小的FFN層的開銷。單卡72并發(fā)，使用一個MTP模塊時，MoE的每個專家激活token個數(shù)是144個。而對于昇騰硬件來言，其算力帶寬比較高，因此行數(shù)為144的GEMM還不足以實現(xiàn)較高的算力利用率。我們可以進一步地采用更大EP的部署策略，例如64卡或128卡部署?？梢灶A見更大EP的部署方案可以進一步地提高MoE部分的算力利用率，提高單卡吞吐。?序列負載均衡優(yōu)化方案：實際部署的Decode階段，每個請求由于其輸入序列長度不同和Decode開始時間不同，使得整個實例中不同請求的序列長度相差很大，進而導致不同卡上MLA耗時相差很大，這時MLA階段會出現(xiàn)嚴重序列負載不均的問題。針對該問題，可以按照不同的請求的處理時間對請求序列進行處理優(yōu)先級劃分，從而減少整體的等待時間。具體來說，可以通過某種簡單的預測手段快速預測請求輸出長度。在獲得輸出長度之后結合輸入長度來做卡間負載均衡調度，最小化不同卡間的序列負載不均。References[2]TriDao.FlashAttention-2:Fasterattentionwithbetterparallelismandworkpartitioning.InternationalConferenceonLearningRepresentations,2024.[3]TriDao,DanFu,StefanoErmon,AtriRudra,andChristopherRé.FlashAttention:Fastandmemory-e?icientexactattentionwithIO-awareness.Advancesinneuralinformationprocessingsystems,35:16344–16359,2022.[5]DeepSeek-AI,AixinLiu,BeiFeng,andBinWangetal.DeepSeek-V2:Astrong,econom-ical,ande?icientmixture-of-expertslanguagemodel,2024.URL/[6]DeepSeek-AI,AixinLiu,BeiFeng,andBingXueetal.DeepSeek-V3technicalreport,[7]ColemanHooperandetal.Kim.KVQuant:Towards10MillionContextLengthLLMInferencewithKVCacheQuantization.InA.Globerson,L.Mackey,D.Belgrave,A.Fan,U.Paquet,J.Tomczak,andC.Zhang,editors,AdvancesinNeuralInformationProcessingSystems,volume37,pages1270–1303.CurranAssociates,Inc.,2024.[8]WoosukKwon,ZhuohanLi,SiyuanZhuang,YingSheng,LianminZheng,CodyHaoYu,JosephE.Gonzalez,HaoZhang,andIonStoica.E?icientMemoryManagementforLargeLanguageModelServingwithPagedAttention.InProceedingsoftheACMSIGOPS29thSymposiumonOperatingSystemsPrinciples,2023.[9]ShenLi,YanliZhao,RohanVarma,OmkarSalpekar,PieterNoordhuis,TengLi,AdamPaszke,JeffSmith,BrianVaughan,Pr