昇腾杀手锏FlashComm，让模型推理单车道变多车道

正文

请到「今天看啥」查看全文

自从其问世以来，便迅速成为全球科技领域乃至整个社会的焦点。根据 Scaling law ，大语言模型的能力与其参数量的对数正相关，因此大语言模型的参数规模也在指数级增长。随之而来的，是大语言模型部署形态的变化，从神经网络时代的单卡部署，到稠密模型时代的多卡 / 单节点部署，再到以最近发布的 DeepSeek V3/R1 模型为代表的混合专家（ Mixture of Experts, MoE ）模型，它甚至会采用数百卡组成的集群和超节点来部署。

而在这基于集群的大模型推理中，集合通信操作就像是一群工人协作盖房子时传递材料和信息的方式，能让多个计算节点高效配合完成任务。有一些常用集合通信操作，比如全量规约（A ll Reduce）可以想象成一群工人各自收集了不同区域的建筑材料数据，全量规约就是把所有工人手里的数据汇总到一个地方，进行求和、求平均值等计算。

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

在大模型里，All-Gather 操作能让每个计算节点都获取到其他节点计算出的部分结果，将分散在各节点的数据聚合到所有节点。还有像规约散射（Reduce-Scatter）操作则相当于先把所有建筑材料按类别汇总，再重新分配给不同工人。

在大模型中，Reduce-Scatter 先对数据进行规约计算，再将计算结果分散到各个节点，常用于在多个节点间分摊计算压力。也还有像A ll-To-All 这样允许所有节点之间相互交换数据，让每个节点都能获取到其他节点的相关数据的操作。

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

在这个过程中，节点之间需要频繁交换数据，比如 All-to-All 操作就经常被用到，让各个节点能获取计算所需的张量片段，实现高效的并行计算。再如数据并行（DP），其将输入数据分成多个批次，在不同节点上同时处理不同批次的数据。各节点计算完各自批次数据对应的梯度后，需要用 AllReduce 操作把这些梯度汇总起来，计算出平均梯度，再将更新后的模型参数发送给所有节点，保证各节点使用相同的模型。

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

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

通信-Scalinglaw头顶的乌云

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

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

请到「今天看啥」查看全文