- A+
虎嗅注：
“大模型江湖，落地为王。”这句话的含金量还在提升。随着DeepSeek V3/R1在春节期间一夜爆火，基于超大规模MoE（Mixture of Experts）架构的大模型正在从训练开发转向推理应用的落地。
对于MoE推理部署来说，效率一直是一个痛点。谁能将部署计算效率提升至最高，才能真正获得大模型商业成功。但受限于庞大的模型容量与计算需求，传统部署方案通常依赖于多张数据中心级GPU（如H20）。您我都知道，英伟达不仅贵，而且不断受到地缘政治摩擦的影响，不断降低自己的性能来满足监管需求。
而在最近，华为全面揭秘超大规模MoE模型推理部署技术，不仅实现了国产的进一步突破，更全面超越了基于英伟达Hopper架构的推理部署性能。
他们是怎么做到的？
数学补物理，极致提升计算效率
“数学补物理”，这种通过数学理论、软件、算法和建模等路径，来弥补硬件和工艺的局限性，实现最大化发挥芯片和系统能力效果。华为轮值董事长孟晚舟曾在2025年新年致辞中提到：
“华为十多个实验室与伙伴们的工程师组成“大杂烩”团队，面对天成AI集群系统和单芯片性能的严峻工程挑战，他们创造性应用数学补物理、非摩尔补摩尔、系统补单点等思想，在散热、供电、高速、高密及大芯片在板可靠性等工程领域突破极限。”
“华为十多个实验室与伙伴们的工程师组成“大杂烩”团队，面对天成AI集群系统和单芯片性能的严峻工程挑战，他们创造性应用数学补物理、非摩尔补摩尔、系统补单点等思想，在散热、供电、高速、高密及大芯片在板可靠性等工程领域突破极限。”
华为技术团队面向超大规模MoE模型的推理技术优化也是围绕着数学补物理这一思路，充分发挥等价数学变换，也就是在保持数学对象本质属性不变的前提下，通过数学变形、逻辑转换或结构重构等路径提升计算效率的方法，极致的提升了硬件集群的算力利用率，包括从点到面的推理框架侧优化技术，把数学最优实现变为物理最优的FlashComm通算优化技术，把串行计算变成四流并发的通算极致掩盖技术，以加法代乘法昇腾MLA最优实现，硬件感知亲和的大量创新算子等一系列核心技术孕育而生，并将通过一连串的技术报告首次全面披露这些宝贵的技术细节。
这次昇腾超大规模MoE模型推理部署技术的揭秘，除了通过技术报告分享昇腾在超大规模MoE模型的推理部署技术之外，在近一个月的时间内，这些核心技术的相关代码也都会陆续开源出来。在与业界分享技术思路的同时，也通过开源的路径共同打造长期持续的开放协作生态环境，让昇腾亲和的技术能力通过这些开源项目真正的活跃起来，这体现出华为坚定建设开放生态的决心，让所有愿意尝试采取昇腾能力的专家有信心长期投入，也让所有积极参与贡献的开发者有信心持续耕耘，一起努力让昇腾生态在中国茁壮成长。
超大MoE大模型推理的挑战
拥有6710亿参数，采用混合专家架构，在各种榜单表现出色的DeepSeek V3某种程度上代表了大模型发展的一个新趋势，即基于软硬件协同优化的模型架构，能够最大性能的发挥硬件平台的能力，在多种任务中表现出色，包括自然语言理解、代码生成和数学推理。小编暂且把DeepSeek V3为代表的大模型统称为超大MoE类模型。
尽管在性能上表现出色，并且有着大量开源的模型权重以及很多的包括DeepEP等在内的软件类项目，但对于想采取这类大模型的企业来说，能够高效部署完整版本的超大MoE类模型目前依旧面临多重挑战：
首先，硬件部署规模要求更高。现在小编在和大模型进行交互聊天的时候，无时无刻不在采取大模型的推理。而由于其自身的尺寸规模，这不再是此前小尺寸模型在单机多卡甚至单机单卡就允许运行能够相比的。硬件集群逐渐成为“满血版”超大MoE类模型的标配。
其次，模型规模庞大对推理效率提出了高要求。庞大的专家数量给硬件内存采取效率提出了很大挑战，每个专家权重约44MB，而共有58个MoE层14906个专家的超大MoE类模型，对于一般的AI硬件来说，需要合理的分布式并行和通信策略设计，才能将如此大量的专家有效的跑在硬件集群上。
再次，超大MoE类模型的诸多架构创新，也带来了很多实际部署上的困难。比如其多头隐式注意力机制(MLA - Multi Head Latent Attention)，虽然允许通过将原有的注意力机制的键值对通过一个投影矩阵压缩到一个较小的隐式向量空间中，但这种创新也为算子优化带来了新的挑战，比如其带来了中间变量膨胀且向量计算占比显著增加，这样给硬件对计算的加速提出了新的要求
华为的解法
为了排除如上提到的实际部署中遇到的难点，从模型和算子两个方面入手，基于昇腾硬件和组网路径，团队提出了多个亲和的优化策略，开发出了一整套面向集群的大规模专家并行的排除方案。
昇腾服务器有多种配置和型号，团队针对：
• CloudMatrix 384 超节点
• Atlas 800I A2 推理服务器
• CloudMatrix 384 超节点
• Atlas 800I A2 推理服务器
两种典型机型进行部署。为了解耦prefill 阶段的首token 时延约束和decode 阶段的解码时延约束，采用了PD 分离部署的路径。在框架侧，团队基于vLLM 框架，为了适配昇腾服务器，针对DP和EP 并行策略做了相应适配，在调度和KV 传输方面分别采用了Prefill调度分桶和灵衢互联与分层传输的技术来降低调度开销，在请求下发、调度策略、系统建链和框架前后处理方面做了性能优化，以实现整个系统的最优性能。模型方面，采用了A8W8C16 的量化策略，其中A8W8 采用INT8 的数据类型，C16 采用BF16 的数据类型进行量化。在具体部署方面，由于两种机型的定位和配置（尤其是网络配置）存在较大差异，从而具体部署方案也不尽相同。
针对 CloudMatrix 384 超节点，其特殊的组网路径使其具有很高的通信带宽。按照 DeepSeek的论文所述，Decode 部分是严重的通信瓶颈，在 Micro-batch 技术的加持下，几乎允许做到通信掩盖其他所有计算类处理。而 CloudMatrix 384 的独特组网使得通信耗时大幅降低，允许有效释放昇腾芯片的算力。因此，针对超节点小编采用大规模 EP 并行的路径来部署：Prefill 采取 16 卡，Decode 采取 144 卡。其中 Decode 部分采取 128 卡通过大规模 EP 的路径部署路由专家，16 卡通过 DP 的路径部署共享专家，MLA 部分采取 DP 的路径进行部署。按照理论分析，超节点允许获得非常高的理论吞吐。实际场景下，由于各种因素的影响，包括 Decode 时延的约束使得各部分耗时未能达到理想的线性度，带宽抢占带来一部分性能劣化，框架的耗时和调度开销带来了额外的时延增加，MLA 部分的序列负载均衡和 MoE 部分的专家负载均衡带来进一步的性能恶化；最后多种因素综合在一起，华为团队实现在保证 50ms 时延下单卡 Decode 吞吐达到 1920 Tokens/s。
针对 Atlas 800I A2 服务器，由于每个节点包含 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。
推理框架侧优化技术
1. API Server 扩展技术
团队提出了API Server 扩展技术，通过兼容API Server 水平扩容策略，允许有效提升框架请求处理能力，降低访客请求延迟，提高系统吞吐量（QPS）。结合包括组网方案优化和全并行、全异步前后处理，可进一步实现最佳TTFT，提升推理服务的可用性与处理效率
2. MoE模型负载均衡
团队提出了一种高效的负载均衡策略，通过动态负载均衡，热专家冗余部署，实时调度和动态监控等核心技术，显著提升MoE模型推理性能。
FusionSpec推理投机加速技术
在实际应用中，投机推理技术更多聚焦于小批量（batch）低时延场景，如何将其高效应用于高吞吐量场景并实现性能收益最大化，成为当前亟待攻克的技术难题。
投机推理在模型解码阶段的高计算密度，天然匹配昇腾高计算带宽比的特点。为了能够充分发挥昇腾算力大的优势，在低时延大并发场景下实现高吞吐，团队提出了投机推理引擎FusionSpec 深度优化MTP 在昇腾上的推理性能：
● 流程拼接：在推理流程上，将投机模型置于主体模型之后，直接采取主体模型的输出，并复用主体的控制参数，大幅减少了框架耗时，适配PD 分离的部署场景。
● 轻量步间准备：在投机场景中针对框架与算子优化，实现了轻量步间准备，适配多核并行全异步框架，降低端到端时延。
● 流程拼接：在推理流程上，将投机模型置于主体模型之后，直接采取主体模型的输出，并复用主体的控制参数，大幅减少了框架耗时，适配PD 分离的部署场景。
● 轻量步间准备：在投机场景中针对框架与算子优化，实现了轻量步间准备，适配多核并行全异步框架，降低端到端时延。
模型侧性能优化技术
1. 模型侧通信优化
● FlashComm ：主流张量并行（TP） 中采取AllReduce 进行通信的方案存在通信次数多，通信数据量大等难点，且AllReduce 之后的残差连接和归一化计算存在计算冗余，没有充分利用多卡并行能力。为此团队提出了FlashComm 网络通信方案：在 Prefill 阶段针对DeepSeek V3 网络 MLA 层前后的 AllReduce 通信，基于相同的集合通信逻辑将张量并行中的AllReduce 通信算子进行替换，并对通信算子在网络中位置进行编排，实现了低比特和低维度数据通信，从而有效降低了通信数据量和通信时延，并消除了网& TMGM外汇代理 #8203;络中存在的冗余计算。FlashComm 技术应用于 DeepSeek V3 模型 Prefill 阶段，降低 25% 的通信量，提升 10%的推理性能。
● 层内并行转换技术：在FlashComm 的基础上，为进一步优化通信算子的时延，团队提出层内并行转换的优化方案：针对Prefill 阶段网络MLA 层的节点内通信重新设计了单层内采取的并行策略，灵活做到张量并行（TP）与数据并行（DP）的转化，消除节点内卡间求和的需求，且充分利用网络中低数据维度和量化特性实现节点间通信量的大幅降低，从而显著优化了通信时延。这一技术术应用于 DeepSeek V3/R1 模型 Prefill 阶段，降低 71%的节点内通信量，提升 10% 以上的推理性能。
● FlashComm ：主流张量并行（TP） 中采取AllReduce 进行通信的方案存在通信次数多，通信数据量大等难点，且AllReduce 之后的残差连接和归一化计算存在计算冗余，没有充分利用多卡并行能力。为此团队提出了FlashComm 网络通信方案：在 Prefill 阶段针对DeepSeek V3 网络 MLA 层前后的 AllReduce 通信，基于相同的集合通信逻辑将张量并行中的AllReduce 通信算子进行替换，并对通信算子在网络中位置进行编排，实现了低比特和低维度数据通信，从而有效降低了通信数据量和通信时延，并消除了网络中存在的冗余计算。FlashComm 技术应用于 DeepSeek V3 模型 Prefill 阶段，降低 25% 的通信量，提升 10%的推理性能。
● 层内并行转换技术：在FlashComm 的基础上，为进一步优化通信算子的时延，团队提出层内并行转换的优化方案：针对Prefill 阶段网络MLA 层的节点内通信重新设计了单层内采取的并行策略，灵活做到张量并行（TP）与数据并行（DP）的转化，消除节点内卡间求和的需求，且充分利用网络中低数据维度和量化特性实现节点间通信量的大幅降低，从而显著优化了通信时延。这一技术术应用于 DeepSeek V3/R1 模型 Prefill 阶段，降低 71%的节点内通信量，提升 10% 以上的推理性能。
2. 模型侧并发优化
● 计算通信并发：昇腾芯片呈现了计算和通信的并发机制。MoE 层的计算过程中需要采取AllGather 汇聚各张卡上的Token 的特征进行激活专家的筛选和计算。方案中，对于Gating函数采取先计算后通信的方法，对共享专家采取DP部署，从而保证了Gate 函数的计算和通信、共享专家的计算，以及特征汇聚的AllGather 函数之间没有依赖关系。团队利用昇腾的多流机制，将这三部分进行并发处理，从而最大化推理模型的性能。此技术在 DeepSeek V3模型的大并发场景下允许实现 Decode 性能提升 15%。
● 通信通信并发：昇腾芯片也呈现了通信和通信并发的机制。当通信带宽利用率比较低的时候，允许把两个通信算子并发起来以掩盖通信算子的启动开销，同时提高通信带宽的利用率。DeepSeek V3模型在进行AllGather 等通信时，允许将Norm 算子和量化算子移到AllGather 通信的前面，从而降低通信的数据量，进而提高通信的效率。但是由于量化算子的前移，需分别通信量化后的激活值和scale，进而增大了通信算子启动开销。由于量化scale 的数据量较小，对带宽的占用较低，因此团队采用通信通信并发的机制，将通信激活值和通信量化scale 并发起来，在不增加激活值通信开销的前提下，掩盖掉量化scale 的通信代价。
● 通信和权重预取的并发：昇腾芯片呈现了缓存机制，算子在进行计算时，会优先从缓存中寻找数据，如果命中，则直接从缓存中读取数据，否则从HBM 中读取数据，而缓存的带宽是HBM 带宽的数倍。由于通信算子进行过程中HBM 带宽占用率较低，在通信算子进行过程中允许将后续算子需要的权重提前预取到缓存中，从而降低后续算子计算过程中的权重搬运开销。同时昇腾芯片兼容灵活限定预取带宽，因此在通信过程中预取对通信性能影响很小。对于DeepSeek 模型，在MoE 模块末尾的ReduceScatter 预取MLA 中权重矩阵和KV cache，允许提升MLA 部分约10%计算性能。
● 计算通信并发：昇腾芯片呈现了计算和通信的并发机制。MoE 层的计算过程中需要采取AllGather 汇聚各张卡上的Token 的特征进行激活专家的筛选和计算。方案中，对于Gating函数采取先计算后通信的方法，对共享专家采取DP部署，从而保证了Gate 函数的计算和通信、共享专家的计算，以及特征汇聚的AllGather 函数之间没有依赖关系。团队利用昇腾的多流机制，将这三部分进行并发处理，从而最大化推理模型的性能。此技术在 DeepSeek V3模型的大并发场景下允许实现 Decode 性能提升 15%。
● 通信通信并发：昇腾芯片也呈现了通信和通信并发的机制。当通信带宽利用率比较低的时候，允许把两个通信算子并发起来以掩盖通信算子的启动开销，同时提高通信带宽的利用率。DeepSeek V3模型在进行AllGather 等通信时，允许将Norm 算子和量化算子移到AllGather 通信的前面，从而降低通信的数据量，进而提高通信的效率。但是由于量化算子的前移，需分别通信量化后的激活值和scale，进而增大了通信算子启动开销。由于量化scale 的数据量较小，对带宽的占用较低，因此团队采用通信通信并发的机制，将通信激活值和通信量化scale 并发起来，在不增加激活值通信开销的前提下，掩盖掉量化scale 的通信代价。
● 通信和权重预取的并发：昇腾芯片呈现了缓存机制，算子在进行计算时，会优先从缓存中寻找数据，如果命中，则直接从缓存中读取数据，否则从HBM 中读取数据，而缓存的带宽是HBM 带宽的数倍。由于通信算子进行过程中HBM 带宽占用率较低，在通信算子进行过程中允许将后续算子需要的权重提前预取到缓存中，从而降低后续算子计算过程中的权重搬运开销。同时昇腾芯片兼容灵活限定预取带宽，因此在通信过程中预取对通信性能影响很小。对于DeepSeek 模型，在MoE 模块末尾的ReduceScatter 预取MLA 中权重矩阵和KV cache，允许提升MLA 部分约10%计算性能。
昇腾亲和的创新算子
1. MLA 算子优化
Attention 算子：MLA 相较于传统的Attention 算子（如MHA, GQA 类显著带宽瓶颈的算子），由于其中间变量膨胀且计算量显著增加，为算子优化带来了新的挑战。针对昇腾处理器的架构特性，团队对MLA 场景的FA 算子进行了算法重构以及硬件亲和的性能优化。
• 提出AMLA（Ascend MLA）算法，通过二进制编码解析及存内计算，实现乘性计算的加性等价转换，从而实现直接在Global Memory 上更新O 的操作路径，无须进入Vector core，大幅降低中间变量的重复搬运。
• 对L1 缓存进行了细致规划，尽可能地减少数据重复搬入搬出的过程。
• 在工程实现方面，通过优化计算流程提高L2 cache 命中率，并且利用K-buffer 流水排布等策略，实现Cube 计算和Vector 计算互相掩盖，提高了算子整体性能。
• 提出AMLA（Ascend MLA）算法，通过二进制编码解析及存内计算，实现乘性计算的加性等价转换，从而实现直接在Global Memory 上更新O 的操作路径，无须进入Vector core，大幅降低中间变量的重复搬运。
• 对L1 缓存进行了细致规划，尽可能地减少数据重复搬入搬出的过程。
• 在工程实现方面，通过优化计算流程提高L2 cache 命中率，并且利用K-buffer 流水排布等策略，实现Cube 计算和Vector 计算互相掩盖，提高了算子整体性能。
上述优化方案提升 Attention 算子性能接近 1 倍，非 MTP 场景算力利用率达到 55%，采取一个 MTP 模块场景算力利用率达到 60%。
MLA 前序算子：针对繁琐的MLA 前序算子，分别在Prefill 阶段和Decode 阶段采取了不同的优化策略：
• 在Prefill 阶段，通过双流并发等技术实现了流水掩盖，同时增加了FA 算子对多种输入输出模式的兼容以消除纯访存类冗余算子。
• 在Decode 阶段，团队采用权重吸收，同时将前序算子深度融合为MLAProlog 算子，并且针对昇腾硬件架构进行了全方位的深度优化。
• 在Prefill 阶段，通过双流并发等技术实现了流水掩盖，同时增加了FA 算子对多种输入输出模式的兼容以消除纯访存类冗余算子。
• 在Decode 阶段，团队采用权重吸收，同时将前序算子深度融合为MLAProlog 算子，并且针对昇腾硬件架构进行了全方位的深度优化。
具体优化措施包括：采用权重预取减少流水线空泡；基于最小化搬运以及最大化带宽的tiling 策略；通过计算解耦降低指令依赖与等待；利用局部计算融合消除全核同步开销；运用昇腾定制指令集实现ICache 压缩，规避issue queue 阻塞风险等。
通过上述优化方案，MLAProlog 算子性能提升 30%以上。
2. MOE 算子优化
Dispatch/Combine 通算融合算子：在EP 部署模式中，MoE 中的专家分布在较大的通信域的各个卡上，每个Token 需要分发到对应的卡上进行计算，原始的实现路径采取InitialRouting 根据专家排序对所有Token 进行重排，再用AllToAll 以及AllToAllv通信算子进行交换token。该实现路径在通信域比较大的场景下，存在通信次数多、卡间同步开销严重等难点，阻碍了整网端到端时延的提升。因此团队提出MoeDistributeDispatch 和MoeDistributeCombine 两个通算融合算子技术：将计算和传输拆解为Token 粒度的计算单位，通过流水排布实现通信和计算的并行执行；同时利用内存语义的通信技术直接向不同卡上的共享内存传输数据，从而减少了本地拷贝和等待数据的开销；团队还通过本地内存筛选和拷贝的机制，减少了数据传输次数和卡间同步开销。
SMTurbo-CPP 算子：针对MOE 层大通信域场景下，小数据量传输效率低的难点，团队提出SMTurbo-Concurrent Push and Pull （SMTurbo-CPP）技术：在内存语义级别对通信算子AllToAll(v) 进行优化，充分利用硬件并发能力，采取读写混合、聚合流水、批量检测等技术，提升了线程的访存效率与吞吐，显著降低Dispatch 和Combine 场景通信算子的时延。
细粒度分级流水算法：基于Atlas A2 系列产品，HCCL 兼容细粒度的分级流水算法，可大幅提升集群中Allgather、ReduceScatter、AlltoAll 等集合通信算子的执行效率。该算法利用A2 组网的特性，实现了节点内/节点间的并发执行，以提高带宽利用率。
在2025 年4 月，硅基流动联合华为云基于CloudMatrix 384 超节点昇腾云服务和高性能推理框架SiliconLLM，用大规模专家并行最佳实践正式上线DeepSeek-R1。该服务在保证单访客20 TPS 水平前提下，单卡Decode 吞吐突破1920 Tokens/s，可比肩H100 部署性能。同时，经过主流测试集验证及大规模线上盲测，在昇腾算力部署DeepSeek-R1 的模型精度与DeepSeek 官方保持一致。返回搜狐，查看更多
