华为昇腾服务器DeepSeek V3R1推理部署最佳实践

樊玉伟，郑灵超，李勇锋，区晓峰，李君，KenZhang，韩伟，李亿杜霄鹏，王鹏程，刘杰，董谷音，梁泓，柳伊扬，廖崎臣，高雪健王鹏宇，赵毅，王翔，林栋，练韵文，林清扬，陈衎，庞西豹吕俊龙，兰龙文，张维熹，丁益斌，高宇，陶壮，张弓，谢冬辉范港华，范峻逸，胡琤球，李宝，郑乐文，陈付恺，申智好，金颖华为技术有限公司摘要本报告旨在探讨华为昇腾服务器上部署DeepSeekV3/R1推理的最佳实践。为满足不同推理场景的需求，本文提供两种不同的部署形态。第一种是基于华为CloudMatrix384超节点的大规模EP部署策略：为充分发挥CloudMatrix384的独特组网优势，使用其中的144张卡作为一个Decode实例，以实现较低时延下的高并发，当前已达到了50ms时延约束下每卡输出1920Tokens/s。第二种是基于Atlas800IA2服务器的小规模EP部署策略：使用4节点A2服务器作为一个Decode实例，以实现较优吞吐下的灵活部署，当前达到了100ms时延约束下每卡输出723~808Tokens/s。我们采用基于vLLM的部署框架，并面向昇腾服务器进行修改以适配EP/DP/TP混合并行策略，同时满足灵活调度和极致性能的需求。模型层面，采用A8W8(INT8)的动态量化方式，并使用Multi-TokenPrediction技术进行加速。针对昇腾芯片和昇腾服务器组网特征，从数学上重新审视模型的推理过程，选用了合适的并行方式和计算逻辑，同时还充分利用了昇腾硬件支持多种多流并发的能力以最大化实现通信/计算/数据搬运的相互掩盖，实现模型层面的性能极致。算子层面，提出了多种结合数学等价变换、融合算子、缓存复用和流水掩盖等技术的计算和通信算子的优化方案，使MLA、MoE和通信算子达到预期的算力利用率、访存带宽和通信带宽。本报告将详细介绍上述两套部署方案，并列出关键的特性和优化技术，更详细的技术细节之后会陆续公开。11引言32昇腾服务器和组网52.1昇腾芯片 52.2Atlas800IA2服务器 52.3CloudMatrix384超节点 63DeepSeekV3/R1模型部署方案63.1模型与框架配置 63.2Atlas800IA2部署方案 83.3CloudMatrix384超节点部署方案 4框架侧性能优化144.1APIServer扩展技术 4.2MoE模型负载均衡 5模型侧性能优化155.1模型侧通信优化 5.2模型侧并发方案 5.3推理投机框架FusionSpec 6昇腾算子性能优化196.1MLA算子优化 6.2MoE通信算子优化 7性能分析217.1Altas800IA2性能分析 7.2CloudMatrix384超节点性能分析 8下一步工作252DeepSeekV3/R1作为业界领先的开源大语言模型，已在自然语言处理、代码生成、知识推理等多个领域展现出卓越的应用价值。DeepSeek团队于3月份推出了迭代版本DeepSeekDeepSeek-Prover-V2-671B[11]。这两款新的模型与原始DeepSeekV3架构完全兼容，仅需进行参数差异化配置的权重调整，便可实现既有模型部署方案的无缝迁移。这一设计不仅降低了技术迭代的边际成本，更有效扩大了DeepSeekV3系列模型的使用范围。本报告分享当前在昇腾服务器上高性能DeepSeekV3/R1部署方案的最佳实践，包括具体的部署方案和关键优化特性的简单介绍。关键优化特性的详细报告将于近期陆续发布。昇腾服务器有多种配置和型号，我们针对近期发布的CloudMatrix384超节点和Atlas800IA2推理服务器两种典型机型进行部署。为了解耦Prefill阶段的首token时延约束和Decode阶段的解码时延约束，同时希望针对不同场景选择最优的部署策略和计算流程，我们采用PD分离部署的方式。在框架侧，以vLLM为基础，针对DP、EP和TP并行策略做了相应适配，在KVCache传输方面采用了灵衢直联的技术来降低开销，在请求下发、调度策略和框架前后处理等方面做了性能优化，以实现整个系统的最优性能。模型方面，采用A8W8(INT8)的动态量化策略。针对昇腾芯片和昇腾服务器组网特征，从数学上重新审视模型的推理过程，并综合考虑了数据搬运量、数据通信量、计算量和内存占用量，选用了合适的并行方式和计算逻辑，有效降低了模型推理过程中的通信和计算耗时；我们还充分利用了昇腾硬件的多流并发能力，实现通信-计算并发、通信-通信并发和通信-权重预取并发等多种加速技术，从而做到通信/计算/数据搬运的相互掩盖，实现模型层面的极致性能。算子方面，我们针对DeepSeek模型的特点，提出了多种结合数学等价变换、融合算子、缓存复用、流水掩盖等技术的极致优化的计算算子和通信算子，特别是在MLA、MLA前序计算、Dispatch/Combine通算融合算子和指令级底层通信调度方面做了深入的优化，以最大化利用昇腾的算力、访存带宽和通信带宽。详细的部署方面，由于两种机型定位和配置不同，所以具体部署方案也不尽相同。3针对CloudMatrix384超节点，其特殊的组网方式使其具有很高的通信带宽。按照DeepSeek的论文[16]所述，Decode部分是严重的通信瓶颈，在Micro-batch技术的加持下，几乎可以做到通信掩盖其他所有计算类操作。而CloudMatrix384的独特组网使得通信耗时大幅降低，可以有效释放昇腾芯片的算力，具体见第7.2节。因此，针对超节点我们采用大规模EP并行的方式来部署：Prefill使用16卡，Decode使用144卡。其中Decode部分使用128卡通过大规模EP的方式部署路由专家，16卡通过DP的方式部署共享专家，MLA部分使用DP的方式进行部署。按照类似于[16]的分析，超节点可以获得非常高的理论吞吐。实际场景下，由于各种因素的影响，包括Decode时延的约束使得各部分耗时未能达到理想的线性度，带宽抢占带来一部分性能劣化，框架的耗时和调度开销带来了额外的时延增加，MLA部分的序列负载均衡和MoE部分的专家负载均衡带来进一步的性能恶化；最后多种因素综合在一起，使得当前吞吐如[19]所述，实现在保证50ms时延下单卡Decode吞吐达到1920Tokens/s。针对Atlas800IA2服务器，由于每个节点包含8张昇腾芯片，我们需要采用多节点互联的方式来进行部署。综合考虑模型吞吐和部署灵活性，我们选定使用2节点16卡作为一个Prefill实例，4节点32卡作为一个Decode实例。为了部署时尽可能的灵活，这里选用的卡数较少，这使得整个系统采用较小规模的EP并行策略：每张卡上部署8(Decode)/16(Prefill)个路由专家和1个共享专家。在Decode阶段，MLA部分采用DP并行策略，通信方式采用AllGather/ReduceScatter方案。这种部署方式可以在卡数较少情况下依然达到相当可观的吞吐。值得一提的是，真实负载下AllGather/ReduceScatter比Dispatch/Combine的通信方案具有更好的性能表现。综合上述优化方案，我们实现了在100ms时延下单卡吞吐达到723~808Tokens/s。本文结构安排如下：在第2节简单介绍昇腾服务器相关的硬件信息，在第3节详细介绍两种不同机型下的部署方案，在第4,5,6节分别介绍框架层、模型层和算子层的优化技术，在第7节给出两种部署下的性能分析结果，最后列举一些当前部署方案后续要增加的特性和优化方案。42昇腾服务器和组网2.1昇腾芯片昇腾NPU芯片是华为推出的一系列高性能AI处理器，专为大规模AI训练、高性能AI推理等任务设计。该系列芯片采用达芬奇架构[18]，具备强大的计算能力和高效的能效表现，能够满足深度学习模型训练与推理、自然语言处理等多种应用场景的需求。该系列芯片分为多种型号，不同型号的性能不同，不同服务器会根据定位选用不同型号的芯片。2.2Atlas800IA2服务器昇腾Atlas800IA2推理服务器（下文简称为A2服务器或A2）一个节点包含8张NPU芯片，形成多机组网架构(图1)，具有以下特点：•节点内拓扑：A2单节点内8卡NPU通过Fullmesh形成全互联结构，通信总带宽392GB/s。•节点间拓扑：A2节点间通过网络交换机进行互联，形成Stars结构，通信总带宽50GB/s。图1:Atlas800IA2服务器节点内和节点间组网。左图：A2节点内全互联；右图：多节点间通过交换机实现互联。节点间通信时，由于不同卡上的数据汇聚到同一个网络通信接口上，共享总带宽。所以如果模型需要部署在多个节点上时，需关注节点间通信量和通信次数，减少节点间带宽对性能带来52.3CloudMatrix384超节点CloudMatrix384超节点（下文简称为CM384）是基于灵衢高速互联总线，满足AI时代海量算力需求的大规模超节点集群(图2)。CM384通过多卡紧耦合互联，统一内存编址，统一标识，统一通信等技术，实现算力、互联带宽、内存带宽的全面领先。因此，在CM384上进行网络部署时，子节点间带宽不再成为通信瓶颈，可考虑利用全部AI处理器的算力分布式部署，如全域的专家并行，以充分利用超节点高算力高带宽的特性。图2:CloudMatrix384超节点内卡间和多子节点间高速互联。3DeepSeekV3/R1模型部署方案本节重点介绍DeepSeekV3/R1在昇腾服务器上的具体部署方案和调度策略。考虑到Atlas800IA2和CloudMatrix384超节点的部署方案比较相似，我们将在第3.2节中详细介绍Atlas800IA2上的部署方案，在第3.3节中介绍CloudMatrix384超节点上的部署方案相比Atlas800IA2的差异。3.1模型与框架配置3.1.1模型量化策略为适配昇腾芯片保证推理性能，这里采用SmoothQuant技术[15]对模型进行A8W8动态量化(权重激活均采用INT8量化数据类型)，计算过程的中间变量采用BF16。当前KVCache采用了BF16的数据类型进行存储和计算，后续该量化策略会记为A8W8C16，即激活INT8、权重INT8和KVCacheBF16。63.1.2Prefill和Decode分离部署大模型推理过程主要分Prefill和Decode两个阶段。Prefill阶段通常是计算瓶颈，而Decode阶段通常是带宽瓶颈和通信瓶颈，这导致两者的最佳部署策略往往不同。此外，由于权重吸收的技术，MLA模块在Prefill和Decode阶段的计算逻辑是不同的，部署在同一实例上会导致额外的权重占用。另一方面，由于实际服务时对首Token时延(TTFT)和Decode时延(TPOT)的要求，如果在同一套硬件上部署Prefill和Decode，导致该系统要同时满足TTFT和TPOT两个指标，这会导致整体吞吐难以达到最优。综合上述原因，如果采用Prefill和Decode分离部署的方式，可以更好的获得两阶段的极致性能，并更好的满足实际需求。所以本报告中我们总是基于Prefill和Decode分离的方式进3.1.3服务框架配置vLLM[8]是当前较为流行的开源大模型推理框架，我们以此为基础来对大模型进行部署。为适配PD分离，并获得极致的性能，我们在框架侧做了相应的适配：图3:基于PD分离部署的vLLM框架调度示意图。7•Prefill调度分桶：基于vLLM框架，结合请求长度与KV亲和性调度策略，根据任务特性动态优化资源分配，显著提升了在高并发场景下的推理性能；•灵衢互联与分层传输：在KVCache传输上，我们采用了灵衢互联与分层传输的形式，来降低KVCache传输时延。为了支撑大规模EP、小规模EP、DP和TP等并行策略，我们对框架做了相应的修改和适配。同时为了支持超高并发（10K以上需要较为极致的性能优化，这部分在第4节框架优化部分会详细介绍。3.2Atlas800IA2部署方案在Atlas800IA2的部署上，综合考虑模型吞吐和部署灵活性，我们在Decode阶段仅使用32卡进行部署，Prefill阶段仅使用16卡部署。如果Decode要达到高吞吐，或Prefill要支持长序列，则意味着高内存占用，这导致内存可能会成为关键瓶颈，所以具体的部署策略上要特别注图4:图4:DeepSeekV3/R1主体网络架构。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部分均为了节省内存采用DP4+TP8的部署策略。下面详细介绍各模块的部署方案。83.2.1多头潜在注意力（MLA）DeepSeekV3/R1使用了独特的MLA进行KVCache压缩。不同于传统的MHA[14]，MLA的多个头共用压缩后的KVCache。在Decode阶段，对MLA用TP无法节省内存,反而会导致KVCache的大量重复搬运；而在Prefill阶段，矩阵乘计算取代数据搬运成为主要性能瓶颈，DP与TP的计算量相同，但TP可以获得一定的内存收益。内存分析单张卡上MLA部分的内存占用可以描述为：Memory=++Memory激活,其中W是模型MLA部分的权重大小。在Decode阶段,KVCache会占据大量内存(卡均72并发，序列长度为4K时，KVCache内存占用接近20GB)。由于MLA的多头共享KVCache机制，传统的TP（head轴切分）部署并不能降低单卡KVCache占用，因此全DP部署是最节省内存的并行部署方式。而在Prefill阶段，并发数较小，序列长度较大，权重（约11.6GB)和激活内存（总token数为16384场景下，约1GB）占据了大部分内存，更适合采用TP的方式进行部署。因此，我们对Prefill和Decode采取不同的部署策略。Prefill我们采用Attention前序计算DP16，AttentionTP16,Attention后序计算DP8+TP2的混合部署策略，流程图示见图5b。具体而言：•在Q、K、V降维阶段采用DP16部署，这部分模型权重数量较少，使用DP不会占用过多内存，且降维后的Q、K、V可以最大程度降低切换到TP所引入的通信开销;•在Q、K、V升维以及Attention计算阶段采用TP16部署，显著降低算子激活内存;•Output投影矩阵采用DP8+TP2,能显著降低TP转换为DP的通信量,具体技术见Decode此时MLA的性能瓶颈主要在权重和KVCache搬运，其中KVCache搬运为主要耗时。因此，我们采用业界主流的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庞大的专家数量对内存提出了巨大挑战。每个专家在总共58层共占权重约2.5GB，而每张Atlas800IA2昇腾卡的内存大小是64GB。因此，我们在Prefill和Decode阶段都采用了业界主流的EP并行部署策略，即将256个路由专家平均地部署到所有昇腾卡上。对于Prefill节点而言，每张卡上需要部署16个路由专家；Decode节点上每张卡部图6:Decode阶段稠密层采取DP32MLA+节点内TP8DenseFFN的部署方式。MLA使用DP32可以避免KVCache的重复搬运，且有效降低了单卡的内存压力。DenseFFN采用了节点内TP8，避免过高的通信代价，同时能够部分降低单卡载入的权重（约1GB）。注：简洁起见，图中已忽略各处的RMSNorm计算。署8个路由专家。这种部署方式很大程度上减轻了单卡的内存压力和计算量，但同时也引入了别的挑战如MoE前后的通信开销（见第5.2节）和专家负载不均衡（见第4.2节）。共享专家通常场景下，我们选择对共享专家应用全DP的并行策略。在长序列的场景下，内存成为提升吞吐的瓶颈之一，我们可以选择对共享专家应用节点内TP8的并行策略，这能节省约2.1GB内存。两种场景下，共享专家的计算都与路由专家的通信操作并发掩盖。总体流程Decode节点MoE层的具体计算流程请见图7。由于Prefill的流程与Decode高度相似（共享专家部署略有不同），这里不另展示Prefill的流程图。3.2.4Embedding和LMHeadDeepSeekV3/R1模型一开始的Embedding和模型最后的LanguageModel(LM)Head都涉及对一个巨大的形状为(129280,7168)的BF16数据格式的字典映射/矩阵乘，权重大小均为1.7GB，共约3.5GB。在Prefill节点上，我们采取TP16的部署方式；而在Decode节点上，我们采取类似DenseFFN的DP4+TP8的部署方式。这部分减少内存占用约3GB，但需要引入额外的节点内通信操作。图7:Decode节点稀疏层的计算流程。MLA部分和稠密层一样采取DP32的方式，降低KVCache搬运量。MoE部分使用EP32的部署策略。首先对MLA的输出使用AllGather通信，所有路由专家计算完毕后，使用ReduceScatter分发结果给下一3.3CloudMatrix384超节点部署方案本节介绍我们在CM384上设计的部署策略。PrefillCM384在Prefill阶段的部署方案与Atlas800IA2基本相同，主要差异是，在CM384上MoE模块的通信方式为All2All。CM384的子节点间通过交换设备形成无收敛高速互联（第2.3节因此在CM384上采用All2All方案，比AllGather+ReduceScatter的方案（图6）性能更优。Decode由于DeepSeekV3/R1模型的路由专家数量多，在Decode阶段，MoE模块的主要性能瓶颈为权重搬运。EP的规模越大，意味着每个子节点需要搬运的专家权重越少，但代价是通信时延的增加。在CM384上，子节点间的互联带宽相比Atlas800IA2大大提高，这使得大规模的EP部署成为可能。在Decode阶段，我们用18个CM384子节点（共144卡）进行部署。具体部署方案与Atlas800IA2的对比如下：1.MLA模块的部署方案与Atlas800IA2基本相同，采用DP。但在Output投影矩阵部分，CM384Decode稠密层子节点1~18NPU1&2NPU3&4NPU5&6NPU7&8DPMLADPMLADPMLADPMLADPMLADPMLADPMLADPMLAAllGatherAllGatherAllGatherAllGatherAllGatherAllGatherAllGatherTP2DenseFFNTP2TP2DenseFFNTP2DenseFFNTP2DenseFFNReduceScatterReduceScatterReduceScatterReduceScatterReduceScatterReduceScatterReduceScatter图8:CM384Decode阶段稠密层部署方式为全DPMLA和TP2DenseFFN。在CM384Decode子节点上，稠密层的MLA整体上采取全DP的部署方式，最后的Output投影矩阵采用TP2（图中的O-proj）。不同于Atlas800IA2上的TP8，基于CM384的组网特点（第2.3节我们在FFN层采取了TP2的部署方式。CM384Decode稀疏层子节点2子节点3子节点子节点2子节点3子节点18…………………DispatchAll2All路由专家路由专家路由专家共享专家路由专家路由专家路由专家共享专家共享专家共享专家共享专家…………CombineAll2All图9:CM384Decode阶段稀疏层部署方式为DPMLA和EP144MoE。在CM384Decode子节点上，稀疏层的MLA整体上采取DP的部署方式，最后的Output投影矩阵采用TP2（图中的O-proj）。MoE采取EP144的部署方式，共享专家也被当做路由专家处理[6]。在18个CM384子节点中，2个子节点以DP的方式部署共享专家；其余16个子节点用于部署路由专家，每张卡部署两个专家。由于通信性能更高，CM384采用了TP2。2.Atlas800IA2上节点内是Fullmesh组网，TP2/TP4无法充分利用带宽，但CM384上子节点内是通过交换设备互联，不存在这一问题。因此，不同于Atlas800IA2的TP8，CM384上稠密层FFN的并行策略采取TP2（见图8）。3.与Prefill相同，CM384上MoE模块采用了All2All的通信方式（见图9并且将共享专家看做一个必选的路由专家[6]，部署到单独的NPU上。由于每个Token会选择8个路由专家和1个共享专家，因此单独部署时，共享专家的数量应为路由专家的8分之1。在18个CM384子节点的144张NPU中，128张用于部署路由专家，其余16张卡用于4.对于Embedding模块，由于CM384上采用了EP144，内存压力小，没有使用TP；而在LMHead部分，由于TP切分可以减小每张卡上的权重搬运，带来性能收益，我们最终采用了TP8。4框架侧性能优化为了实现DeepSeekV3/R1的高吞吐，需要框架支持10K甚至更高的并发度。为此我们需要对框架进行增强，通过性能优化和多Server并发等来降低框架侧耗时。我们在vLLM的以下关键环节进行了深度优化：1.请求下发：支持下发水平扩展，结合负载均衡机制，降低转发时延。2.调度策略：采用请求长度感知与KVCache亲和等高级调度策略，实现负载均衡与资源高3.系统建链：简化系统通讯链路，在保证稳定性的前提下去除所有非必要链路。4.前后处理：多核全并行、全异步的高效前后处理，降低NPU闲置率，确保推理结果快速返回，降低端到端延迟。4.1APIServer扩展技术当前单节点APIServer部署存在故障风险。在昇腾服务器高性能架构下，高并发请求易使单点APIServer成为性能瓶颈，导致响应延迟增加，NPU算力资源浪费。因此我们做了如下优化：•APIServer水平扩容策略：通过GlobalProxy组件插件化实现KVCache亲和、负载均衡及序列长度调度优化，提升请求处理能力和系统吞吐量（QPS降低用户请求延迟。•组网方案优化：从APIServer与DP全连接简化为1:1组网，减少通讯开销，增强系统鲁棒性。整体方案显著提升TTFT提高推理服务可用性与效率，充分发挥昇腾算力，为高并发场景下的大模型推理服务提供可靠支持。•全并行、全异步前后处理，并结合Multi-Step技术进一步降低Decode前后处理耗时；Prefill部分支持动态进程前后处理降低TTFT。4.2MoE模型负载均衡针对混合专家（MoE）模型推理中的“冷热专家”问题，我们提出高效负载均衡策略，解决负载不均、推理延迟高及吞吐量低等痛点。通过专家重排、分层冗余部署和近实时调度，显著提升推理性能，具体包括：•动态负载均衡：基于激活数据与计算均衡，动态调整专家部署，缩小通信域，优化后结果静态负载均衡的收敛性与负载均匀性。•热专家冗余部署：为高频专家分配冗余实例，结合实时资源预测，降低通讯开销，从而提•实时调度：动态调整专家分配，实现快速收敛、适应输入变化的同时，保持低延迟。•动态监控：独立流监控激活数据，不干扰推理，确保高鲁棒性。5模型侧性能优化5.1模型侧通信优化大模型多卡部署时，卡间并行方式包括数据并行（DP）、张量并行（TP）、专家并行（EP）等。不同的卡间并行方式对多卡间通信方式和通信算子有着不同的需求，从而影响模型部署时的通MoE层整体通信策略针对Altas800IA2的组网架构，我们采用AllGather和ReduceScatter来进行MoE层前后的数据通信，而非经典的EP部署下的All2All。这是因为节点间通信带宽相较节点内的较低。当单卡的并发数为BS时，若采用AllGather通信，单卡需要进行节点间通信的数据量为BS×3×hidden__size。作为对比，若采用All2All方案，单卡平均需要进行节点间通信的数据量为BS×6×hidden__size。同时All2All方案的通信数据量会受到专家负载不均的影响，不如AllGather/ReduceScatter方案稳定。结合细粒度分级流水算法(第6.2节)，AllGather/ReduceScatter方案可以做到节点间通信耗时几乎被节点内通信耗时掩盖。另一方面，采用AllGather的分发模式，AllGather通信可以和Gating函数的计算解耦，实现计算通信并发，详见第5.2节。综上所述，在Altas800IA2的32卡部署方案中，我们采用了AllGather/ReduceScatter来进行MoE层前后的数据通信。FlashComm主流张量并行（TP）[12]中使用AllReduce进行通信的方案存在通信次数多、通信数据量大等问题，且AllReduce之后的残差连接和归一化计算存在计算冗余，没有充分利用多卡并行能力。为此，我们提出FlashComm网络通信方案：在Prefill阶段针对DeepSeekV3/R1网络MLA层前后的AllReduce通信，基于相同的集合通信逻辑将张量并行中的AllReduce通信算子进行替换，并对通信算子在网络中的位置进行编排，实现了低比特和低维度数据通信，从而有效降低了通信数据量和通信时延，并消除了网络中存在的冗余计算。FlashComm技术应用于DeepSeekV3/R1模型Prefill阶段，降低25%的通信量，提升10%的推理性能。层内并行转换技术在FlashComm的基础上，为进一步优化通信算子的时延，我们提出层内并行转换的优化技术：针对Prefill阶段网络MLA层的节点内通信，我们重新设计了MLA层内的多卡并行策略，实现张量并行（TP）与数据并行（DP）[9]的灵活转换，消除了节点内卡间求和的需求，且充分利用网络中低维度数据和量化特性实现节点内通信量的大幅降低，从而显著优化了通信时延。层内并行转换技术应用于DeepSeekV3/R1模型Prefill阶段，降低71%的节点内通信量，提升10%以上的推理性能。5.2模型侧并发方案昇腾芯片支持多种计算资源如张量计算单元、向量计算单元，以及通信资源的并发使用，这为尽可能发挥昇腾硬件的算力和带宽提供了支持。我们针对DeepSeekV3/R1模型的架构进行了细致的流水编排，从而尽可能利用硬件资源，实现极致的性能。具体来讲，包含如下几项技术：通信通信并发昇腾芯片提供了通信和通信并发的机制。当通信带宽利用率比较低的时候，可以把两个通信算子并发起来以掩盖通信算子的启动开销，同时提高通信带宽的利用率。在DeepSeekV3/R1模型中，我们将Norm算子和量化算子移到AllGather通信前，从而降低通信的数据量，进而提高通信的效率。由于量化算子的前移，需分别通信量化后的激活值和量化Scale，进而增大了通信算子启动开销。由于量化Scale的数据量较小，对带宽的占用较低，因此我们采用通信通信并发的机制，将通信激活值和通信量化Scale并发起来，在不增加激活值通信开销的前提下，掩盖掉量化Scale的通信开销。计算通信并发昇腾芯片也提供了计算和通信的并发机制。MoE层的计算过程需要使用AllGather汇聚各张卡上token的特征，以进行激活专家的筛选和计算。但Gating函数无须依赖AllGather汇聚的结果。因此，对Gating函数使用先计算后通信的方法，对共享专家使用DP部署，从而保证Gating函数的计算和通信、共享专家的计算，以及特征汇聚的AllGather通信之间解耦。我们利用昇腾的多流机制，将这三部分进行并发处理，从而最大化推理模型的性能。结合通信通信并发技术可以实现极致的流水编排（参见图10）。此技术在DeepSeekV3/R1模型在大并发下可以实现Decode性能提升15%。通信和权重预取的并发昇腾芯片提供了缓存机制，算子在进行计算时，会优先从缓存中寻找数据，如果命中，则直接从缓存中读取数据，否则从HBM中读取数据，而缓存的带宽是HBM带宽的数倍。由于通信算子进行过程中HBM带宽占用率较低，我们在通信算子的进行过程中可以将后续算子需要的权重提前预取到缓存中，从而降低后续算子计算过程中的权重搬运开销。同时昇腾芯片支持限定预取带宽，因此在通信过程中预取对通信性能影响很小。对于DeepSeekV3/R1模型，我们在MoE模块末尾的ReduceScatter预取下一层MLA模块中的权重和KVCache，提升了MLA约10%的性能。图10:DecodeMoE层计算通信并发和通信通信并发。利用昇腾多流机制，使能Gating函数计算和通信，激活值的AllGather通信，共享专家计算进行通信计算并发。量化后激活值和Scale的通信，路由专家门控系数和Index的通信进行通信和通信并发5.3推理投机框架FusionSpec在大模型推理优化领域，投机推理是一种极具潜力的技术路径：其通过引入轻量模型或外部知识数据，为大模型生成推理草稿，从而在解码阶段一次推理多个token，提升了计算密度。以DeepSeekV3/R1模型[6]为例，其创新性地引入MTP（Multi-TokenPrediction）投机层，实现了投机推理技术的落地。投机推理在模型解码阶段的高计算密度天然匹配昇腾高算力带宽比的特点。为了充分发挥这一优势，在低时延大并发场景下实现高吞吐，我们提出了投机推理框架FusionSpec，包括投机流程及投机算子性能的优化技术，持续提升MTP在昇腾上的推理性能，使得MTP部分框•流程拼接：在推理流程上，将投机模型置于主体模型之后，直接使用主体模型的输出，并复用主体模型的控制参数，大幅减少了框架耗时，适配PD分离的部署场景。•轻量步间准备：在投机场景中针对框架与算子优化，实现了轻量步间准备，适配多核并行全异步框架，降低端到端时延。6昇腾算子性能优化6.1MLA算子优化Attention算子MLA相较于传统的Attention（如MHA,GQA类在Decode阶段显著带宽瓶颈的算子由于其中间变量膨胀且计算量显著增加，为算子优化带来了新的挑战。针对昇腾处理器的架构特性，我们借鉴了Flash-Attention的思想[2,3]，对MLA场景的Attention算子[5,6]进行了计算过程的优化，以及硬件亲和的性能优化。主要包括以下几点：•提出AMLA（AscendMLA）算法，通过浮点二进制编码解析及存内计算能力实现乘性计算的加性等价转换，从而实现直接在内存上更新输出矩阵O的步骤，无须进入向量计算单元，大幅降低中间变量的重复搬运。•根据[2,3]的思想，对L1缓存进行了细致规划，尽可能地减少数据重复搬入搬出的过程。•在工程实现方面，通过优化计算流程提高L2缓存命中率及数据复用率，并且利用K-buffer流水排布等策略，实现张量计算和向量计算互相掩盖；使能昇腾硬件亲和的数据排布，提高了算子整体性能。上述优化方案提升Attention算子性能接近1倍，非MTP场景算力利用率达到55%，使用一个MTP模块场景算力利用率达到60%。MLA前序算子针对复杂的MLA前序算子，我们分别在Prefill阶段和Decode阶段采取了•在Prefill阶段，我们通过双流并发等技术实现了流水掩盖，同时增加了Attention算子对多种输入输出模式的支持以消除纯访存类冗余算子。•在Decode阶段，我们采用权重吸收，同时将前序算子深度融合为MLAProlog算子，并且针对昇腾硬件架构进行了全方位的深度优化。具体优化措施包括：采用权重预取减少流水线空泡；基于最小化搬运以及最大化带宽的Tiling策略；通过计算解耦减少依赖；利用局部计算融合消除全核同步开销等。基于上述优化方案，MLAProlog算子性能提升30%6.2MoE通信算子优化Dispatch/Combine通算融合算子在EP部署模式中，MoE中的专家分布在通信域的各个卡上，每个token需要分发到对应的卡上进行计算。原始的方案使用InitialRouting根据专家排序对所有token进行重排，再利用两次通信算子（All2All以及All2Allv）完成token分发。该方案在通信域比较大的场景下，存在通信次数多，卡间同步开销大等问题，导致端到端时延增加。针对此问题，我们提出MoEDistributeDispatch和MoEDistributeCombine两个通算融合算子：将计算和通信拆解为token粒度，通过流水排布实现两者的并行执行；利用内存语义的通信技术直接向不同卡上的内存传输数据，从而减少了本地拷贝和等待数据的开销；通过本地内存筛选和拷贝的机制，减少了数据传输次数和卡间同步开销。SMTurbo-CPP针对MoE层大通信域场景下，小数据量传输效率低的问题，我们提出SMTurbo-ConcurrentPushandPull（SMTurbo-CPP）技术：在内存语义级别对通信算子All2All(v)进行优化，充分利用硬件并发能力，使用读写混合、聚合流水、批量检测等技术，提升了线程的访存效率与吞吐，显著降低Dispatch和Combine场景通信算子的时延。实测可降低Dispatch/Combine算子8%-20%的推理时延。细粒度分级流水算法Atlas800IA2服务器通信协议支持细粒度的分级流水算法，可大幅提升AllGather、ReduceScatter、All2All等集合通信算子的执行效率[17]。该算法利用A2组网的特性，实现了节点内/节点间通信的并发执行以提高带宽利用率。采用细粒度分级流水算法后的AllGather和ReduceScatter,在4节点时，可以达到节点间通信耗时被节点内通信耗时几乎完全掩盖。在Decode4节点部署/Prefill2节点部署场景中，其性能相较All2Allv具有更大优图11:细粒度分级流水算法[17]，每次Server间传输过来的数据，在下一个步骤将此数据用于Server内传输，同时获得下一份Server间的数据，以此类推。7性能分析7.1Altas800IA2性能分析7.1.1Decode性能A2Decode的测试方式为：•序列长度为2K输入+2K输出/1K输入+2K输出。•在使能MTP进行推理加速的情况下，由于不同测试数据集和业务场景的MTP接受率不同，性能测试结果会有比较大的偏差。因此在计算时延和吞吐的时候默认按照70%接受•TPOT（Decode平均每token时延）不超过100ms。对于序列长度是2K输入+2K输出的情形，每卡平均并发数为72，此时端到端耗时为99.6ms，卡均吞吐为723Tokens/s。具体数据详见表2。图12中详细拆解了每个模块的耗时，可以看出：•由于MLA的Attention算子，尤其在使能MTP时，计算密度远高于GQA和MHA，与MQA相当，此时MLA的计算不再是完全带宽瓶颈。我们通过第6.1节中的优化方案，当前的算子实现可以达到55%的算力利用率。输入长度输出长度单卡并发数不同接受率吞吐(Tokens/s)70%80%90%2K2K7237658081K2K784830876表2:Altas800IA2的Decode性能：在不同MTP接受率和不同序列下的单卡吞吐。图12:Atlas800IA2的Decode在序列长度2K+2K，卡均72并发的各模块耗时拆解。•卡均72并发，且使用一个MTP模块时，MoE中的全连接层中，每个专家激活的token数是72×2×8×32/256=144，对于昇腾硬件而言，这还是一个相对带宽瓶颈的场景，算力利用率不高。未来使用更大规模的EP部署方案，可以进一步提高单卡并发数，提高MoE模块的算力利用率。•由于采用了AllGather和ReduceScatter来作为通信方式，而非All2All方案，所以通信数据量不随着真实的专家负载变化，负载不均仅通过MoE路由专家计算不均来影响性能，对整体性能的影响相对较小。•根据DeepSeek披露的数据[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。具体的数据见表3，具体的拆解数据见图13。分析如下：输入长度总并发数单卡吞吐2K81K表3:Altas800IA2的Prefill性能。图13:序列长度8×2K,Prefill阶段各组件的耗时占比。•Prefill阶段除了MoE层前后的AllGather和ReduceScatter之外，由于我们MLA部分采用了TP16的部署策略，所以这里也存在AllGather和ReduceScatter通信过程。•由于在Output投影矩阵部分采用了第5.1节中提到的层内并行转换技术，我们在Prefill阶段也存在All2All通信过程。•虽然采用了AllGather和ReduceScatter通信方式，在负载不均时MoE部分的通信数据量是不受MoE负载不均影响的。不过负载不均会导致不同卡的MoE部分计算时间不同，不同卡间等待的过程在当前的统计方式里会表现在通信的耗时上。•当前为了部署的灵活性，同时考虑到实际场景Prefill难以拼到足够的并发数，我们采用了16卡部署，MLA选择TP16，所有卡的序列长度之和为16K的一种方案。如果采用DPMLA的部署方式，则可以减少MLA前后的通信，同时如果采用更大的并发数，可以进一步提高MoE部分的算力利用率。同时根据[13]，大并发的Prefill阶段采用Micro-batch(Two-batchOverlap)技术可以得到相当大的吞吐收益，甚至可以完全掩盖通信。据此计算，Altas800IA2在Prefill阶段可达到卡均3095Tokens/s的吞吐。7.2CloudMatrix384超节点性能分析DeepSeek团队基于H800的算力、带宽和网络互联带宽，给出了DeepSeekV3/R1模型的理论分析[16]。由于H800高单卡算力带宽，而低网络带宽的特性，作者使用Micro-batch技术，提出利用Dispatch/Combine掩盖其余所有计算的方案，并给出了理论的耗时估计。昇腾CloudMatrix384超节点由于其独特的网络互联使得其通信方面具有显著优势，这使得在CM384上我们不再是通信瓶颈。基于此，可以设计不同的Micro-batch掩盖策略：使用MLA中Attention计算掩盖其他部分，包括其他计算部分。根据当前MLA的实现（当前MTP的MLA算子接近60%的算力利用率并考虑到使用MLA计算掩盖其余部分会带来35%左右的性能劣化，以3K序列长度为例，估算单层MTP的MLA的耗时大约为这里BS表示单卡的并发数，从而按照70%的MTP接受率来算的话，整个网络的耗时接近如果不限制Decode时延，理论吞吐可以达到在实际部署的时候，由于多种因素的影响，实际可达吞吐会大幅打折。一个关键原因是Decode时延的约束限制了实际使用的并发数，使得各部分耗时未能达到理想的线性度，导致可达吞吐的大幅下降。另一方面，带宽抢占带来的恶化不可忽略，实际上上述评估中需要使用MLA来掩盖MoE等其他计算部分，这里会发生严重的HBM带宽抢占导致整体带宽利用率下降。框分的序列负载均衡和MoE部分的专家负载会分别使得MLA和MoE部分耗时增加，导致进一步的性能恶化。这些因素结合在一起，使得当前吞吐明显低于理论值。2025年4月，硅基流动联合华为云基于CloudMatrix384超节点昇腾云服务，采用与本报告完全相同的大规模专家并行方案正式上线DeepSeek-R1。该服务在保证单用户20TPS（等效50ms时延约束）水平前提下，单卡Decode吞吐突破1920Tokens/s。[19]图14:2025年4月，硅基流动联合华为云基于CloudMatrix384超节点上线DeepSeek-R1，单卡Decode吞吐突破1920Tokens/s.8下一步工作当前已经完成了在昇腾服务器上部署DeepSeek-V3/R1模型的方案，后续还有一些工作需要完善，以进一步提升性能和支撑更多场景：•低时延场景的极致优化：本报告中的部署方案主要瞄准高吞吐场景，暂未针对低时延场景进行极致优化。基于当前的部署方案，CloudMatrix384超节点在卡均8并发下时延为15ms，Atlas800IA2服务器上的方案在卡均4并发下时延为30ms。实际上当前的整体部署方案、算子优化和模型并行优化策略均未针对低时延下做优化，也并未使能多层MTP，还有很大的优化空间。•Micro-batch优化方案：在DeepSeek公布的DeepEP方案[1,13]中，提出通过将数据拆分为两个Micro-batch的思路，实现了通信和计算的相互掩盖。该技术可以预见地会有较大的性能收益，尤其在高并发的Decode和Prefill场景。当前在CloudMatrix384超节点的部署上已经采用了该技术，但在Altas800IA2上还未有效使用。接下来我们会基于Altas800IA2进行适配以及更极致地优化。•低比特量化方案：当前模型采用的是A8W8C16的量化模式。对于MLA而言，其计算密度远大于经典的GQA方案，所以传统的KVCache量化[7,10]只能保证较大的内存收益，能带来的性能收益有限。因此我们也在探索一些将Q/K/V全部量化的计算方案，如果可以给出满足精度要求的量化方案，会给Attention计算带来可观的加速效果。另外，针对低时延场景，Decode部分是强访存带宽瓶颈，如果对MoE部分使用A8W4或A4W4的量化方案，可有效降低访存带宽需求量，从而大幅提升性能。因此我们需要探索针对MoE部分INT4的量化技术。•MLA层算子量化支持：在长序列下KVCache量化可以大幅减少推理过程中的内存占用，我们将同步进行Attention及MLAProlog算子针对仅KVCache的INT8量化和Q/K/V全INT8量化场景的适配，通过深度的算子重构与极致流水优化保证性能。•Altas800IA2的更大EP部署方案：对于Altas800IA2，当前采用的是32卡的部署策略，每张卡的路由专家个数是8个，这带来了不小的FFN层的开销。单卡72并发，使用一个MTP模块时，MoE的每个专家激活token个数是144个。而对于昇腾硬件来言，其算力带宽比较高，因此行数为144的GEMM还不足以实现较高的算力利用率。我们可以进一步地采用更大EP的部署策略，例如64卡或128卡部署。可以预见更大EP的部署方案可以进一步地提高MoE部分的算力利用率，提高单卡吞吐。•序列负载均衡优化方案：实际部署的Decode阶段，每个请求由于其输入序列长度不同和Decode开始时间不同，使得整个实例中不同请求的序列长度相差很大，进而导致不同卡上MLA耗时相差很大，这时MLA阶段会出现严重序列负载不均的问题。针对该问题，可以按照不同的请求的处理时间对请求序列进行处理优先级划分，从而减少整体的等待时间。具体来说，可以通过某种简单的预测手段快速预测请求输出长度。在获得输出长度之后结合输入长度来做卡间负载均衡调度，最小化不同卡间的序列负载不均。References[2]TriDao.FlashAttention-2:Fasterattentionwithbetterparallelismandworkpartitioning.InternationalConferenceonLearningRepresentations,2024.[3]TriDao,DanFu,StefanoErmon,AtriRudra,andChristopherRé.FlashAttention:Fastandmemory-efficientexactattentionwithIO-awareness.Advancesinneuralinformationprocessingsystems,35:16344–16359,2022.[5]DeepSeek-AI,AixinLiu,BeiFeng,andBinWangetal.DeepSeek-V2:Astrong,econom-ical,andefficientmixture-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.EfficientMemoryManagementforLargeLanguageModelServingwithPagedAttention.InProceedingsoftheACMSIGOPS29thSymposiumonOperatingSystemsPrinciples,2023.[9]ShenLi,YanliZhao,RohanVarma,OmkarSalpekar,PieterNoordhuis,TengLi,AdamPaszke,JeffSmith,BrianVaughan,Pr