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推理的一个显著特点。{"layout": {"title": "推理显存占用:密集模型与MoE模型", "xaxis": {"title": "模型架构"}, "yaxis": {"title": "bfloat16精度下所需显存 (GB)"}, "barmode": "group", "font": {"family": "Arial", "size": 12, "color": "#495057"}, "plot_bgcolor": "#f8f9fa", "paper_bgcolor": "#ffffff"}, "data": [{"type": "bar", "name": "活跃参数占用", "x": ["密集130亿参数模型", "MoE 8x7B模型 (总计470亿参数)"], "y": [26, 26], "marker": {"color": "#74c0fc"}}, {"type": "bar", "name": "总参数占用", "x": ["密集130亿参数模型", "MoE 8x7B模型 (总计470亿参数)"], "y": [26, 87.5], "marker": {"color": "#fa5252"}}]}此图比较了运行密集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数量增加时。digraph G { rankdir=TB; splines=true; node [shape=box, style="filled,rounded", fontname="Arial", fillcolor="#e9ecef"]; edge [fontname="Arial", fontsize=10]; subgraph cluster_0 { label="GPU 0"; style=filled; color="#dee2e6"; T0 [label="Token批次", fillcolor="#a5d8ff"]; E0 [label="专家 0", fillcolor="#b2f2bb"]; E1 [label="专家 1", fillcolor="#b2f2bb"]; } subgraph cluster_1 { label="GPU 1"; style=filled; color="#dee2e6"; E2 [label="专家 2", fillcolor="#c0eb75"]; E3 [label="专家 3", fillcolor="#c0eb75"]; } subgraph cluster_2 { label="GPU 2"; style=filled; color="#dee2e6"; E4 [label="专家 4", fillcolor="#d8f5a2"]; E5 [label="专家 5", fillcolor="#d8f5a2"]; } subgraph cluster_3 { label="GPU 3"; style=filled; color="#dee2e6"; E6 [label="专家 6", fillcolor="#ffec99"]; E7 [label="专家 7", fillcolor="#ffec99"]; } T0 -> E1 [label="发往专家1的Token", color="#4263eb"]; T0 -> E2 [label="发往专家2的Token", color="#82c91e", style=dashed]; T0 -> E7 [label="发往专家7的Token", color="#f59f00", style=dashed]; }All-to-All通信模式的示意图。源自GPU 0的token批次被分割,token隐藏状态被分派到不同GPU上为其分配的专家。虚线表示设备间的网络流量,这是延迟的一个主要来源。低效的内存访问即使在单个设备上,稀疏激活也比密集计算效率低。在密集前馈网络中,大型权重矩阵只需从显存加载一次,然后通过高度优化的矩阵乘法核用于整个token批次。这使得内存访问成本可以分摊到大量的计算中。在MoE层中,特定专家的权重被加载,只为路由到它的一小部分token进行处理。这导致算术强度较低(计算操作与内存操作之比)。推理过程可能变为内存带宽受限,这意味着GPU等待数据从显存到达的时间多于执行计算的时间。这个问题由于路由的不可预测性而加剧;如果一个批次将其90%的token发送给一个专家,1%发送给另一个,硬件利用率将非常不均衡,导致计算单元空闲并增加整体延迟。这些内存容量和延迟的基本困难影响着任何实用MoE推理方案的设计。后续章节将介绍旨在直接解决这些问题的技术,从卸载专家权重以管理内存,到实施专门的批处理和解码策略以减轻延迟。