大型语言模型非常庞大。由于它们的体积大，我们需要大量GPU来运行它们。如果LLM推理能够“毫无羞耻地并行”，我们只需在不同的GPU上计算独立的内容，那就太好了。然而，很遗憾，在LLM推理中使用大量GPU，我们需要使这些GPU能够相互通信。让不同GPU协同工作的方式有很多：张量并行、流水线并行、上下文并行、专家并行等。每种方式都有其特定的应用场景。但对于MoE模型，在MoE层中，当你想要进行大规模服务时，“宽专家并行”（wideEP）是王道。请参见vLLM的原始DeepSeek大规模服务帖子，以展示在生产规模下的演示：DeepSeek在H200集群上每秒2.2k个token，使用宽EP和数据并行注意力。其他类型的并行性都需要GPU之间的通信，但它们的模式由架构决定：谁发送，谁接收，以及发送多少，在前向传播开始之前都是已知的，并且在每一步都是相同的。这些通信可以作为标准集合运行。专家并行是不同的。哪些token需要到达哪些GPU由路由器在运行时根据数据决定，在每个MoE层中都是最新的。并且token是有目的地到达的：我们假设DeepSeek使用的数据并行注意力安排，每个token仅存在于一个rank（rank是集群中的一个GPU）。专家分布在这些相同的rank上，因此token及其路由到的专家通常不会在同一个地方。以下是一个例子，显示8个GPU分布在2个节点上，每个GPU有两个专家，每个rank上有1个token，以及每个token的2个路由专家：悬停在rank芯片上查看token的往返时间，或悬停在专家上查看所有路由到它的内容。本次步骤中十六个专家中有四个根本没有接受到token：路由显得不均匀。在运行我们的MoE层时，token必须去与它们的专家见面，无论它们在网络结构中的哪个位置。EP通信内核的工作就是实现这一点。这些内核的现代形状由DeepSeek的DeepEP库设定。在这篇文章中，我们将构建一个DeepEP风格的分发与合并内核的解剖：首先是高吞吐量的形状，然后是低延迟的形状。我们需要做的工作 § 让设置更具体。我们有8个GPU，分布在2个节点上，通过RDMA连接，每个数据并行的rank拥有一个单独的GPU。注意力在每个GPU上运行一批BiB_i token，其中BiB_i可以在GPU之间变化。我们在专家并行中有E=16E=16个专家，每个GPU两个，其中K=2K=2个专家被路由给每个token。在每个rank rir_i上，在EP层的入口处，我们有一个形状为(Bi,H)(B_i, H)的张量，H是隐藏层大小。路由层将在本地运行，并为每个token提供专家分配。我们正在进行16个中的2个路由：对于每个token，路由器提供一个长度为16的logits集合（即形状为(Bi,16)(B_i, 16)的张量），我们将取前2的索引，以获得一个形状为(Bi,2)(B_i, 2)的张量。例如，如果token kk被路由到专家33和1313，那么第kk行将是[3,13][3, 13]。因此在EP层的入口时，每个rank持有两个信息：它产生的激活行，以及在本地路由过程后每行的前2个专家分配。激活(Bᵢ, H)router专家logits(Bᵢ, E=16)分配(Bᵢ, K=2)0123456789101112131415E:Wᵣ xH→Et0−1.20.3−0.42.10.1−0.80.5−0.20.9−0.60.2−1.00.41.7−0.30.6313t12.40.2−0.50.9−1.10.31.9−0.20.7−0.90.10.5−0.70.2−0.1−0.406t20.12.2−0.30.4−0.90.2−0.60.80.31.8−0.20.6−1.10.10.5−0.819t3−0.60.32.00.1−0.20.7−1.00.4−0.50.20.8−0.30.61.6−0.70.1213并非所有的专家都在本地。一些在邻近的NVLink对等体上，而一些则远在只能通过RDMA访问的节点上。专家并行性内核的目标是将激活输出到它们需要到达的地方，运行专家GEMM，然后再将它们带回家。我们在进行通信，而在通信中，专注于我们最关心的点是方便的：吞吐量或延迟。这个分割映射到推理的两个阶段：预填充带来了大量的计算密集型批量工作，能够隐藏住通信，而在解码时几乎没有其他工作，因此我们等待的就是传输本身。我们将从优化吞吐量的标准EP形状开始，然后讨论优化延迟的形状。高吞吐量：询问，然后发送 § 分发 § 分发的目的在于输送一个分组的GEMM。分组的GEMM是一次内核启动，在每个专家上运行单独的矩阵乘法，每个专家都是...