推理面临的困难：内存与延迟

MoE模型在训练时将参数量与计算成本分离，然而，这种优点却给实际推理带来了明显障碍。其主要难点并非源于计算量（$FLOPs$），而是内存容量以及稀疏数据访问模式导致的延迟。了解这两个问题是为稀疏模型构建高效服务体系的第一步。

内存瓶颈：总参数量与活跃参数量

部署大型MoE模型最直接的难点是其庞大的内存需求。尽管单个token的前向计算仅激活模型总参数的一小部分（通常是两个专家），但整个专家组都必须加载到高速内存（GPU显存）中，并准备好供门控网络选择。这种“全有或全无”的要求造成了明显的内存瓶颈。

以Mixtral 8x7B模型为例。尽管其名称表明其专家总计560亿参数，但其总参数量（包括共享的自注意力模块）大约为470亿。在推理时，每个token仅由八个专家中的两个处理，这使得其计算量相当于一个小得多的130亿参数密集模型。然而，要部署此模型，您必须将全部470亿参数驻留在显存中。

在半精度（如bfloat16，每个参数占用2字节）下，内存占用量可以这样计算：

$$\text{内存 (GB)} = \frac{47 \times 10^9 \text{ 参数} \times 2 \text{ 字节/参数}}{1024^3 \text{ 字节/GB}} \approx 87.5 \text{ GB}$$

这甚至超过了单个80GB NVIDIA A100或H100 GPU等高端加速卡的容量。因此，模型必须在多个GPU上分片，增加了系统复杂性和成本。所需内存与实际计算量之间的这种差异是MoE推理的一个显著特点。

此图比较了运行密集130亿参数模型与计算成本相似的MoE模型所需的显存。尽管两种模型都有相似的活跃参数占用，但MoE模型的总内存需求明显大得多，因为所有专家都必须驻留在内存中。

延迟瓶颈：稀疏访问与通信

除了静态内存占用，稀疏路由的动态特性引入了明显的延迟。与计算可预测、数据移动有规律的密集模型不同，MoE推理性能通常受限于内存带宽和网络通信，而不仅仅是原始计算能力。

All-to-All通信开销

由于大型MoE模型使用专家并行在多个GPU上分布式部署，路由一批token通常需要设备间通信。当在GPU 0上处理的token需要路由到驻留在GPU 1上的专家时，其隐藏状态必须通过网络发送（例如NVLink或InfiniBand）。专家计算完成后，结果必须回传。

对于一批token，这个过程变成一个复杂的All-to-All通信模式，其中每个GPU将其部分token发送给其他每个GPU，并接收返回的token。这种集体通信操作是分布式计算中众所周知的瓶颈，并且可能在一个生成步骤中占据主导地位，影响端到端延迟，特别是在组中GPU数量增加时。

All-to-All通信模式的示意图。源自GPU 0的token批次被分割，token隐藏状态被分派到不同GPU上为其分配的专家。虚线表示设备间的网络流量，这是延迟的一个主要来源。

低效的内存访问

即使在单个设备上，稀疏激活也比密集计算效率低。在密集前馈网络中，大型权重矩阵只需从显存加载一次，然后通过高度优化的矩阵乘法核用于整个token批次。这使得内存访问成本可以分摊到大量的计算中。

在MoE层中，特定专家的权重被加载，只为路由到它的一小部分token进行处理。这导致算术强度较低（计算操作与内存操作之比）。推理过程可能变为内存带宽受限，这意味着GPU等待数据从显存到达的时间多于执行计算的时间。这个问题由于路由的不可预测性而加剧；如果一个批次将其90%的token发送给一个专家，1%发送给另一个，硬件利用率将非常不均衡，导致计算单元空闲并增加整体延迟。

这些内存容量和延迟的基本困难影响着任何实用MoE推理方案的设计。后续章节将介绍旨在直接解决这些问题的技术，从卸载专家权重以管理内存，到实施专门的批处理和解码策略以减轻延迟。