大模型推理，不再是“一根筋”

摘要：然而主流的MoE架构大模型，却苦于其结构上的“先天不足”：巨大的硬件成本与多重拖累效率的环节，使得中国企业在这场芯片堆砌与效率挖掘的苦径上难以提速。

没有人不在期待大模型能够成为下一个电动车，作为代表中国的新兴产业，在世界范围内掀起狂澜。

然而主流的MoE架构大模型，却苦于其结构上的“先天不足”：巨大的硬件成本与多重拖累效率的环节，使得中国企业在这场芯片堆砌与效率挖掘的苦径上难以提速。

作为智能基础设施提供商，华为在这场战役中另辟蹊径，利用其在数学算法和工程领域的深厚积累，为DeepSeek显著提升了效率及用户体验。

山就在那里，但中国企业找到了不一样的登顶之路。

近期，虎嗅将打造《华为技术披露集》系列内容，全面揭秘超大规模MoE模型推理部署技术，通过一连串的技术报告，首次全面披露技术细节。

希望本系列内容能为业界起到参考价值，也希望更多人能与华为一起，共同打造长期持续的开放协作生态环境，让昇腾生态在中国茁壮成长。

《华为技术披露集》系列

VOL.4 ：通信优化

大模型的推理，就只是算力吗？

大语言模型(Large Language Models， LLMs) 自从其问世以来，便迅速成为全球科技领域乃至整个社会的焦点。

根据Scaling law，大语言模型的能力与其参数量的对数正相关，因此大语言模型的参数规模也在指数级增长。

随之而来的，是大语言模型部署形态的变化。从神经网络时代的单卡部署，到稠密模型时代的多卡/单节点部署，再到以最近发布的DeepSeek V3/R1模型为代表的混合专家（Mixture of Experts， MoE）模型，它甚至会采用数百卡组成的集群和超节点来部署。

而在这基于集群的大模型推理中，集合通信操作就像是一群工人协作盖房子时传递材料和信息的方式，能让多个计算节点高效配合完成任务。

有一些常用集合通信操作，比如全量规约（AllReduce）可以想象成一群工人各自收集了不同区域的建筑材料数据，全量规约就是把所有工人手里的数据汇总到一个地方，进行求和、求平均值等计算。

在大模型里，多个计算节点可能各自计算了一部分参数梯度，AllReduce 操作能把这些梯度汇总起来，计算出最终的梯度，用于更新模型参数。再比如全量收集（All-Gather）则类似于所有工人把自己手头的材料清单共享给彼此，这样每个人都知道所有材料的情况。

在大模型里，All-Gather 操作能让每个计算节点都获取到其他节点计算出的部分结果，将分散在各节点的数据聚合到所有节点。

还有像规约散射（Reduce-Scatter）操作，先对数据进行规约计算，再将计算结果分散到各个节点，常用于在多个节点间分摊计算压力。相当于先把所有建筑材料按类别汇总，再重新分配给不同工人。

也还有像All-To-All这样允许所有节点之间相互交换数据，让每个节点都能获取到其他节点的相关数据的操作。

这些形形色色的集合通信操作，大多用来支持在集群上运行大模型推理时的并行策略，比如常见的张量并行（TP）是把一个大的张量（可以理解为模型的参数矩阵）拆分成多个部分，分配到不同的计算节点上计算。

在这个过程中，节点之间需要频繁交换数据，比如 All-to-All 操作就经常被用到，让各个节点能获取计算所需的张量片段，实现高效的并行计算。

再如数据并行（DP），其将输入数据分成多个批次，在不同节点上同时处理不同批次的数据。

各节点计算完各自批次数据对应的梯度后，需要用 AllReduce 操作把这些梯度汇总起来，计算出平均梯度，再将更新后的模型参数发送给所有节点，保证各节点使用相同的模型。

而被MoE带火的专家并行（EP）就像工厂的流水线，不同的计算节点负责模型不同专家的计算。在这个过程中，节点之间需要传递中间计算结果，类似广播操作会把上一层的输出传递给下一层的节点，确保专家正常激活运行。

由上可以看出，集合通信操作是大模型推理中多个计算节点协作的 “桥梁”，不同的并行策略（TP、DP、EP）通过这些操作实现高效的数据交互和计算，从而加速大模型的推理过程。

通信-Scaling law头顶的乌云

随着集群规模和推理并发数的飞速增长，在大语言模型的推理中，通信面临的压力也在不断变大，在推动应用通算融合技术上还有一些问题需要解决：

1. 随着MoE模型规模的持续扩张，专家数量与参数总量呈指数级增长，单个模型参数突破千亿级别已成常态。尽管MoE通过稀疏激活机制仅调用部分专家，但海量参数的存储与调度仍对硬件构成严峻挑战。MoE模型的稀疏计算特性虽能提升推理效率，却引入了更复杂的流程与通信瓶颈。专家路由、数据分发与结果聚合等环节紧密耦合，通信带宽需求随专家数量呈平方级增长，极易引发网络拥塞；而流程各阶段的强依赖性使得计算与通信难以重叠，硬件资源长期处于“饥饿”状态。如何实现通信与计算的深度协同成为关键难题

2. 传统的通信方案中小并发推理场景下常用的通信策略——AllReduce，存在着一些缺陷：

· AllReduce 在通信原理上，等价于ReduceScatter 和AllGather 的组合。直接使用AllReduce 算子，在通信次数上较少，适用于小并发场景。但在大并发场景下，AllReduce算子对比拆分的ReduceScatter 和AllGather，收益并不明显。

· Transformer 结构中AllReduce 算子之后，往往会有一些其他计算操作，如RMSNorm、以及MLA 中的降维计算等。这些计算过程会在不同卡上执行相同的计算操作，在小并发场景下可能耗时不高，但在大并发场景下，会带来不小的代价。

3. 当前主流的并行方案是张量并行(TP)在应用AllReduce时也面临一些问题。TP方案通过卡间均匀切分权重的方式，虽然能够有效降低每张卡上加载的模型权重大小，但卡间求和的AllReduce操作在大模型端到端推理时延中占比较高；在多节点的部署场景中，跨节点的带宽限制进一步加剧了整网时延劣化。

FlashComm：别让通信扼住算力的咽喉

针对上面三个难题，华为团队给出了他们的创新解法。

多流并行：打破计算链条的串行桎梏

针对上文提到的第一个问题，华为团队提出了昇腾亲和的大模型推理多流并行技术。

在MoE模型的推理过程中，华为团队如同拆解精密钟表般对DeepSeek V3/R1的计算流程展开深度剖析。

通过数学重构将原本环环相扣的激活通信、门控决策等五大模块拆解重组，借助昇腾硬件的多流引擎实现三股计算流的精准并行：当一组数据正在进行专家计算时，另一组数据已开启门控决策，而第三组数据已在传输途中——这种"计算不停歇"的流水线设计，使关键路径耗时大幅缩短。更巧妙的是，通过TP8分片与流水线技术的交织运用，在多卡并行时仍为系统腾出2GB内存空间，如同在高速运转的引擎内部完成精密的空间重组。实际部署中，DeepSeek模型的Prefill阶段提速超10%，Decode吞吐激增25%-30%。

AllReduce革新：给通信装上“智能压缩器”

传统AllReduce的笨重通信方式如同用集装箱运输散装货物，华为团队则通过数学手段将其拆解重构：先将数据智能分拣（ReduceScatter），再对精简后的核心信息进行广播（AllGather）。

在这两个阶段之间，创新性插入数据投影降维和INT8动态量化技术，使后续通信量直降35%，关键计算量锐减至1/8。这种"先浓缩再传递"的智慧，让DeepSeek 模型 Prefill 推理性能提升 22 ∼ 26%，Llama3.1-70B模型的Decode阶段性能提升14%，如同为数据洪流建造了分级疏导系统。