MoE 推理的核心优势是“稀疏计算”：每个令牌只被路由到少数专家，而不是让全部参数参与计算。但专家通常分布在不同 GPU 上，路由结果又取决于每个令牌的输入内容。当目标专家不在当前设备时，令牌及其中间状态就必须跨卡传输。于是，模型节省下来的矩阵计算，可能被通信延迟和数据搬运抵消。
通信为何会成为瓶颈
MoE 推理通常包含三个环节：路由器决定令牌交给哪些专家；令牌被发送到对应 GPU；专家完成计算后，再把结果汇总回原设备。只要专家跨卡部署，第二和第三个环节就会形成频繁的集体通信。通信量不仅取决于令牌数量，也取决于专家分布、路由是否均衡以及不同设备之间的互联能力。
这与普通密集模型存在明显差异。密集模型的每个设备通常执行相对固定的计算，通信模式更容易预测；MoE 则会根据请求内容动态改变令牌去向。长上下文、图像输入和多轮工具调用会增加输入规模，使一次推理需要处理更多令牌，也会放大跨卡交换的压力。
输出阶段的问题更突出。Decode 通常按令牌逐步生成，单轮可并行处理的令牌较少，通信延迟难以被大批量计算隐藏。即使专家本身只需少量计算，频繁的跨卡往返仍可能直接拉高首令牌延迟或降低生成速度。若部分专家被集中调用，还会出现热点：某些 GPU 过载，其他 GPU 却未被充分利用。
不能只看显卡算力
MoE 部署评估至少要同时观察专家并行方式、专家是否跨卡、路由均衡性、GPU 互联带宽和推理框架的原生支持能力。单卡峰值算力高，并不代表端到端推理更快；如果通信链路无法承受动态路由，理论上的稀疏计算收益就难以兑现。
工程上，专家布局应尽量减少高频路由的跨卡距离，并通过批处理和合理的并行策略提高通信与计算的重叠程度。同时要监测专家负载、跨卡通信占比、首令牌延迟和不同并发下的生成速度。最终应以目标硬件和真实请求集实测，而不能用激活参数数量直接推导服务性能。