华为昇腾FlashComm:三招破解大模型推理通信瓶颈,性能提升高达80%

华为昇腾FlashComm三箭齐发,优化大模型推理通信,提速高达80%。包含AllReduce优化、以存换传和多流并行三项关键技术,助力MoE模型高效推理。

原文标题:帮大模型提速80%,华为拿出昇腾推理杀手锏FlashComm,三招搞定通算瓶颈

原文作者:机器之心

冷月清谈:

华为针对大模型推理过程中面临的通信瓶颈,推出了昇腾推理加速方案FlashComm,包含三项关键技术:FlashComm1通过优化AllReduce通信,将数据智能分拣并压缩,提升推理性能;FlashComm2通过重构计算流程、以存换传的方式,大幅降低通信量;FlashComm3通过多流并行技术,充分挖掘昇腾硬件能力,实现MoE模型的高效并行推理,显著提升模型吞吐。这些技术旨在解决MoE模型规模持续扩张带来的挑战,并为未来的超大规模专家并行提供更优的解决方案。

怜星夜思:

1、文章中提到的FlashComm技术主要针对MoE模型,那么对于非MoE的大模型,这些优化策略是否仍然有效?如果有效,效果如何?如果无效,原因是什么?
2、文章提到FlashComm通过昇腾硬件的多流引擎实现并行计算,那么在其他硬件平台(如GPU)上,是否也能实现类似的多流并行优化?如果可以,需要做哪些适配和调整?
3、文章中FlashComm的优化都提到了INT8量化技术,INT8量化虽然能减少计算量和通信量,但也会带来精度损失。那么,在实际应用中,如何权衡量化带来的性能提升和精度损失?有没有更好的量化策略选择?

原文内容

机器之心发布

机器之心编辑部


在今年 2 月的 DeepSeek 开源周中,大模型推理过程中并行策略和通信效率的深度优化成为重点之一。



近日,华为数学家出手,祭出 FlashComm,三箭齐发,解决大模型推理通算难题


  • FlashComm1: 大模型推理中的 AllReduce 通信优化技术。将 AllReduce 基于通信原理进行拆解,并结合后续计算模块进行协同优化,推理性能提升 26%。

  • FlashComm2:大模型推理中以存换传的通信优化技术。在保持计算语义等价的前提下,实现 ReduceScatter 和 MatMul 算子的计算流程重构,整体推理速度提升 33%。

  • FlashComm3: 大模型推理中的多流并行技术。充分挖掘昇腾硬件的多流并发能力,实现 MoE 模块的高效并行推理,大模型吞吐激增 30%。


随着大语言模型(Large Language Models, LLMs)规模的指数级扩张,其部署形态也随之变化,显卡配置朝着规模化、集约化演进。从神经网络时代的单卡部署,到稠密模型时代的多卡 / 单节点部署,再到以最近发布的 DeepSeek V3/R1 模型为代表的混合专家(Mixture of Experts, MoE)模型,大语言模型甚至会采用数百卡组成的集群和超节点来部署。


可以说,模型推理早已不是「单兵作战」,而是一场高协同的「群体作战」。而在这基于集群的大模型推理中,集合通信操作就像是一群工人协作盖房子时传递材料和信息的方式,能让多个计算节点高效配合完成任务


有一些常用集合通信操作,比如全量规约(AllReduce)可以想象成一群工人各自收集了不同区域的建筑材料数据,全量规约就是把所有工人手里的数据汇总到一个地方,进行求和、求平均值等计算。在大模型里,多个计算节点可能各自计算了一部分参数梯度,AllReduce 操作能把这些梯度汇总起来,计算出最终的梯度,用于更新模型参数。


再比如全量收集(All-Gather)则类似于所有工人把自己手头的材料清单共享给彼此,这样每个人都知道所有材料的情况。在大模型里,All-Gather 操作能让每个计算节点都获取到其他节点计算出的部分结果,将分散在各节点的数据聚合到所有节点。还有像规约散射(Reduce-Scatter)操作则相当于先把所有建筑材料按类别汇总,再重新分配给不同工人。在大模型中,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 操作在大模型端到端推理时延中占比较高;在多节点的部署场景中,跨节点的带宽限制进一步加剧了整网时延劣化。



针对上面三个难题,华为团队用数学补物理,给出了他们的系列性创新解法,把加速大模型推理提到了新的高度


项目链接:https://gitcode.com/ascend-tribe/ascend-inference-cluster/tree/main/FlashComm


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


    FlashComm1 通算重组:给通信装上「智能压缩器」


    传统 AllReduce 的笨重通信方式如同用集装箱运输散装货物,华为团队则通过数学手段,基于昇腾硬件特点,将其拆解重构:先将数据智能分拣(ReduceScatter),再对精简后的核心信息进行广播(AllGather)。在这两个阶段之间,创新性插入数据投影降维和 INT8 动态量化技术,使后续通信量直降 35%,关键计算量锐减至 1/8。


    这种「先浓缩再传递」的智慧,让 DeepSeek 模型 Prefill 推理性能提升 22 ∼ 26%,Llama3.1-70B 模型的 Decode 阶段性能提升 14%,如同为数据洪流建造了分级疏导系统。



    技术博客:https://gitcode.com/ascend-tribe/ascend-inference-cluster/blob/main/FlashComm/ascend-inference-cluster-flashcomm.md


    FlashComm2 以存换传:重新定义计算与通信的平衡


    面对 TP+AllReduce 架构的通信瓶颈,团队发现了一个精妙的数学等价关系:通过调整矩阵乘法的并行维度,在保持计算结果精确性的前提下,将原本需要传输的三维张量「压扁」成二维矩阵。这种维度魔法配合 INT8 量化技术,使得 DeepSeek 模型在注意力机制转换阶段的通信量骤降 86%,整体推理速度提升 33%。


    这就像在保证货物完整性的前提下,把运输集装箱体积压缩了五分之四,让数据传输真正实现「轻装上阵」。



    技术博客:https://gitcode.com/ascend-tribe/ascend-inference-cluster/blob/main/FlashComm/ascend-inference-cluster-flashcomm2.md


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


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


    在 MoE 模型的推理过程中,华为团队如同拆解精密钟表般对 DeepSeek V3/R1 的计算流程展开深度剖析。通过数学重构将原本环环相扣的激活通信、门控决策等五大模块拆解重组,借助昇腾硬件的多流引擎实现三股计算流的精准并行:当一组数据正在进行专家计算时,另一组数据已开启门控决策,而第三组数据已在传输途中 —— 这种「计算不停歇」的流水线设计,使关键路径耗时大幅缩短。


    更巧妙的是,通过 TP8 分片与流水线技术的交织运用,在多卡并行时仍为系统腾出 2GB 内存空间,如同在高速运转的引擎内部完成精密的空间重组。实际部署中,DeepSeek 模型的 Prefill 阶段提速超 10%,Decode 吞吐激增 25%-30%。



    技术博客:https://gitcode.com/ascend-tribe/ascend-inference-cluster/blob/main/FlashComm/ascend-inference-cluster-flashcomm3.md


    总结与展望


    针对 DeepSeek 这类超大规模 MoE 模型的多机多卡推理场景中的通信挑战,华为团队提出了三项关键技术,其中 FlashComm 技术基于相同的集合通信逻辑替大模型推理中的 AllReduce 通信算子,在不改变网络并行方式的前提下,充分利用网络中低维度数据或低比特数据特性进行通信算子位置的编排,实现通信数据量的降低和通信时延的优化,同时消除了计算流程中的冗余计算,进一步提升了网络端到端推理性;FlashComm2 技术充分考虑网络并行过程中数据特征的维度变化,基于相同的集合通信逻辑将张量并行中的原有通信算子进行替换,并对新的通信算子在网络中的位置进行编排;FlashComm3 技术通过对 MoE 架构的细致理解,通过计算流程的等价变换,尽可能提升模型计算的并行度,并借助昇腾硬件提供的多流能力实现并行,进而大幅提升大模型的推理吞吐。


    未来,围绕着超大规模 EP 下的多流并行、权重自动预取、模型自动多流并行等方向,华为团队将进行更多的创新,进一步提升大模型推理的系统性能。


    同时,随着大语言模型特别是 MoE 架构的进一步扩展,其参数规模、专家数量与并发推理需求将持续增长,对通信、调度和资源协同会提出更高的要求。在这一趋势下,华为昇腾不仅仅是硬件算力的提供者,更要构建一个面向大模型推理的全栈生态体系。


    © THE END 

    转载请联系本公众号获得授权

    投稿或寻求报道:liyazhou@jiqizhixin.com

    其实我觉得吧,多流并行这玩意,说白了就是尽可能让CPU和GPU都别闲着。在GPU上搞多流,感觉跟CPU上搞多线程有点像,都是尽量把资源用满。问题是,资源用满了,活儿能不能也干完,那就不好说了。万一stream之间抢资源,或者同步开销太大,反而会更慢。所以,移植FlashComm的多流并行技术到GPU上,我觉得最大的挑战不是技术,而是找到一个合适的平衡点。

    个人观点,量化策略的选择要结合具体的应用场景。对于一些对精度要求不高的场景,例如图像分类,可以采用INT8量化,甚至更低的精度。但对于一些对精度要求较高的场景,例如目标检测,可能需要采用混合精度量化,或者采用一些更高级的量化方法。此外,还可以考虑一些其他的优化方法,例如知识蒸馏,可以将一个高精度的模型蒸馏到一个低精度的模型中,从而在保证精度的前提下,提高推理速度。总的来说,量化是一个复杂的优化过程,需要综合考虑各种因素,选择最合适的策略。

    多流并行这种思路,本质上就是把多个计算任务尽可能并行执行,从而提高硬件利用率。在GPU上,虽然没有像昇腾那样的“多流引擎”的说法,但可以通过CUDA stream来实现类似的效果。CUDA stream允许将多个kernel launch到不同的stream中,从而实现kernel的并发执行。要将FlashComm的多流并行技术移植到GPU上,需要将原来的计算流程拆解成多个kernel,然后将这些kernel分配到不同的CUDA stream中执行。同时,还需要考虑kernel之间的依赖关系,以及数据在不同stream之间的同步问题。这需要深入理解CUDA编程模型,以及目标GPU的硬件架构。

    谢邀,人在实验室,刚跑完实验。简单说两句,FlashComm在非MoE模型上的效果取决于模型的并行方式和通信模式。如果模型采用了张量并行或者数据并行,且通信量较大,那么FlashComm1和FlashComm2的优化可能会带来一定的性能提升。但是,如果模型本身计算密集,通信较少,或者已经采用了其他通信优化方法,那么FlashComm的效果可能不明显。另外,FlashComm3是针对MoE模型的专家并行设计的,其多流并行的策略在非MoE模型上难以直接应用。

    楼上说的有道理,FlashComm针对AllReduce的优化,像是一种通用的“榨干带宽”的思路,类似于给zip文件再次压缩,应该任何模型都有收益,只不过收益大小可能不同,具体还是要看模型本身的通信密集程度。而以存换传,本质上是在算力一定的情况下用空间换时间,我觉得只要模型足够大,这个策略都有用武之地。至于多流并行,明显是针对MoE这种“一部分积极分子干活,剩下摸鱼”的特性,我感觉很难套用到所有模型上。

    我觉得量化这东西,有点像压缩照片。压缩狠了,照片是小了,但是细节也没了。在AI里,细节就是精度。所以,量化的时候,得悠着点。除了文章里说的INT8,还可以试试INT4,甚至二值化。不过,量化等级越低,对硬件的要求也越高。很多硬件对低精度计算的支持并不好。另外,还可以考虑一些更高级的量化方法,比如smoothQuant,可以减少量化带来的精度损失。总之,量化是一门玄学,需要不断尝试和调整。

    个人觉得,在GPU上实现类似的多流并行优化是可行的,但挑战也不小。首先,GPU的编程模型与昇腾有所不同,需要对CUDA或OpenCL等GPU编程接口有深入的了解。其次,GPU的硬件架构也与昇腾存在差异,需要针对GPU的特点进行优化。例如,GPU的shared memory容量有限,需要在kernel设计时充分考虑shared memory的使用,避免出现bank conflict等问题。此外,还需要关注kernel launch的开销,以及不同stream之间的同步开销,避免过度并行导致性能下降。总的来说,移植FlashComm的多流并行技术到GPU上需要进行大量的实验和调优。

    我认为FlashComm的部分优化策略,例如AllReduce的优化和以存换传的思路,在一定程度上也可以应用于非MoE的稠密模型。AllReduce优化降低了通信开销,这对于任何需要多卡协同的大模型都有帮助。以存换传的思路,核心在于寻找计算上的等价变换来减少通信量,这种思路也有可能在稠密模型中找到应用场景。但MoE模型由于其稀疏激活的特性,通信模式与稠密模型有很大不同,因此针对MoE模型设计的FlashComm3多流并行技术,可能不太适合直接应用于稠密模型。具体效果需要实际测试和调整,不能一概而论。

    这是一个trade-off问题,需要在性能和精度之间找到平衡。一般来说,可以通过以下几种方式来权衡:1. 离线量化评估:在实际部署前,先用少部分数据对量化后的模型进行精度评估,如果精度损失在可接受范围内,就可以采用量化后的模型。2. 动态量化:根据输入数据的不同,动态调整量化参数,从而尽可能减少精度损失。3. 混合精度量化:对不同的层或不同的参数采用不同的量化策略,例如,对一些对精度要求较高的层,可以采用FP16或FP32,而对其他层则采用INT8。更好的量化策略选择包括:Post-Training Quantization (PTQ), Quantization-Aware Training (QAT)等。QAT通常能获得更高的精度,但需要重新训练模型。