第十五章：多节点大模型推理——并行部署、解码优化与 MoE 路由

录屏回看

本章概要

多节点大模型推理不是单一的并行或加速问题，而是在模型容量、请求负载、硬件拓扑和服务目标共同约束下进行的系统优化。本章依次讨论阶段资源组织、模型静态布局、MoE 运行时执行路径和投机解码，并以 SLO 约束下的 goodput 作为统一评价目标。

1. 问题定义、系统边界与决策框架

本节不展开具体优化机制，而是定义后续各节共同使用的问题边界、决策层次和评价口径。

1.1 统一优化问题：可部署、可达标与可扩展

多节点推理系统需要同时回答三个问题：

问题	核心约束	判定标准
可部署	权重、KV cache、激活值和运行时缓冲区能否容纳于目标集群	容量约束满足，并保留必要显存余量
可达标	排队、计算和通信能否满足服务等级目标（SLO）	TTFT、TPOT 及其达标率满足业务要求
可扩展	增加 GPU 或系统复杂度能否转化为有效服务能力	goodput、goodput/GPU 或达标请求成本持续改善

因此，本章研究的不是“某个算子怎样达到最高吞吐”，而是：在给定模型、负载、硬件、SLO 和质量约束时，如何选择阶段资源组织、模型布局、运行时路由和解码机制，使系统以可接受成本获得更高的 SLO 约束下的 goodput。该问题也可以从两个互补视角规划：在固定 GPU 预算下最大化 goodput，或在给定目标负载与 SLO 时最小化 GPU 数量和服务成本。单独增加 GPU 通常可以提高绝对吞吐，但不能据此证明方案更高效。

1.2 系统输入与请求生命周期

任何方案比较都必须固定或明确以下输入，否则实验结论不能直接横向比较：

输入类别	需要明确的内容	主要影响
模型	Dense/MoE、参数量、专家数与 Top-k、精度、上下文上限	权重容量、计算量和通信模式
负载	prompt/output 长度分布、到达率、突发性、并发度和采样设置	排队、batch 形态和 KV cache 压力
硬件	GPU 显存、计算与内存带宽、节点规模、节点内外互联	可用并行度和通信成本
服务合同	TTFT/TPOT 阈值、SLO attainment、质量要求和成本预算	优化目标与可接受的工程代价

一次在线请求依次经历排队与调度、Prefill、KV 状态交接或驻留，以及多轮 Decode：

Prefill 处理完整 prompt 并建立 KV cache，主要影响 TTFT；Decode 读取并扩展 KV cache，逐 token 生成结果，主要影响 TPOT。两个阶段共享模型状态，但负载形态和扩容依据不同，因此阶段资源组织是后续第一项架构决策。

1.3 决策层次及其依赖关系

多节点推理可以分为四个相互依赖的决策层次：

决策层次	回答的问题	典型方案	对应章节
阶段资源组织	Prefill 和 Decode 在哪里执行，资源共享还是隔离	共置、Chunked Prefill、PD 分离	第 2 节
静态模型布局	权重、专家、上下文和请求如何映射到 GPU	TP、SP、PP、EP、CP、DP	第 3 节
运行时执行路径	token 如何到达专家，通信与热点如何处理	Dispatch/Combine、负载均衡、专家副本	第 4 节
解码算法	如何减少 Target Model 的串行调用	Draft-and-Verify、EAGLE、Medusa	第 5 节

这些层次并不独立。PD 分离后，Prefill Pool 和 Decode Pool 可能需要不同的并行布局；EP 只定义专家的静态放置，不能替代运行时路由与负载均衡；投机验证形成类似短 Prefill 的批量计算，也会改变 Decode 阶段的 batch 和显存需求。因此，系统配置通常需要根据 profiling 结果迭代，而不是依次套用所有技术。

1.4 统一评价指标与比较口径

在线推理首先关注服务结果指标：

指标	全称	定义
TTFT	Time To First Token	从请求到达至首个 token 返回的延迟
TPOT	Time Per Output Token	首个 token 返回后，相邻输出 token 之间的时间间隔
goodput	Useful Throughput	在满足给定 SLO 达标率目标时，系统可持续承载的有效请求率

增大 batch size 可能提高 token 吞吐，也可能增加排队时间和单 token 延迟。如果大量请求违反 TTFT 或 TPOT SLO，吞吐增长并未转化为在线服务能力提升。在 DistServe 的实验口径中，goodput 表示：

TTFT 和 TPOT 的 SLO attainment 同时达到目标时，系统能够支持的最大请求到达率。

该定义是本章的主要评价口径，但完整评估还应覆盖以下层次：

指标层次	代表指标	用途
硬约束	模型与目标 KV cache 可部署、质量要求满足、预算不超限	排除不可行方案
服务结果	P50/P95/P99 TTFT、TPOT、端到端完成延迟、goodput	判断业务目标是否达成
成本效率	GPU 数量、goodput/GPU、GPU-hours、达标请求成本	判断扩展是否经济
诊断指标	队列、显存余量、collective 占比、链路利用率、专家尾延迟	定位瓶颈及解释结果

比较不同配置时，至少应固定模型版本与精度、prompt/output 长度分布、请求到达过程、采样参数、硬件拓扑、SLO 阈值和达标率目标。投机解码等可能影响输出分布的方案，还必须在同一质量约束下比较。

1.5 本章路线

后续内容按系统决策顺序展开：

第 2 节比较 Prefill/Decode 共置、Chunked Prefill 和分离部署；
第 3 节从容量约束出发，分析模型与状态的静态布局；
第 4 节在既定布局上分析 MoE 的运行时通信、负载均衡和专家副本；
第 5 节分析减少 Decode 串行调用的投机解码；
第 6 节给出复杂度预算、验证闭环与核心结论。

2. Prefill/Decode 资源组织

Prefill 与 Decode 共享模型状态，却具有不同的计算形态和延迟目标。本节先说明共置部署的阶段干扰，再比较 Chunked Prefill 与 PD 分离两类资源组织方式。数据参考 AI Infra Learning Docs — PD 分离与 DistServe。

2.1 阶段特征与共置干扰

维度	Prefill	Decode
主要任务	处理完整 prompt，建立 KV cache	读取并扩展 KV cache，逐 token 生成
计算形态	大规模、并行度较高的矩阵计算	多次小规模、存在串行依赖的迭代
典型瓶颈	更接近计算受限（compute-bound）	更接近内存带宽受限（memory-bound）
主要影响指标	TTFT	TPOT
调优重点	prompt 处理吞吐和首 token 延迟	显存带宽、KV cache 容量和稳定输出延迟

Compute-bound 与 memory-bound 是典型概括，并非所有模型和 batch 配置下的绝对结论，实际瓶颈仍需通过 profiling 确认。关键在于，两个阶段的最优批处理、并行配置和扩容依据并不相同。假设一批请求正在逐 token 输出，此时进入一个 32K token 的长文档请求：

调度选择	结果
优先执行长 Prefill	活跃 Decode 请求等待时间增加，TPOT 上升
优先执行 Decode	新请求的 Prefill 排队时间增加，TTFT 上升
在两者之间频繁切换	调度开销增加，批处理效率下降

这种结构性冲突称为 Prefill-Decode Interference。DistServe 在 13B 模型上向 Decode batch 插入一个 Prefill，得到以下结果：

prompt 长度	混合 batch 的 Decode 延迟 / 纯 Decode 延迟
128 token	约 1.8×
1024 token	约 12.6×

论文原图：左、右分别为插入长度 128 和 1024 的 Prefill Job 后，混合 batch 的执行时间。来源：DistServe，Figure 2。

实验观察： 在该实验中，prompt 从 128 增至 1024 token 后，混合 batch 的 Decode 延迟倍率由约 1.8× 增至 12.6×。该结果说明长 Prefill 会显著放大阶段干扰，但 12.6× 不是 PD 分离的通用加速比。

2.2 独立 Prefill Pool 与 Decode Pool

Prefill/Decode 分离部署（disaggregated prefill and decoding，以下简称 PD 分离）将请求拆成两个阶段执行：

Prefill Pool 处理完整 prompt 并建立 KV cache；
Decode Pool 接收中间状态并继续逐 token 生成；
Scheduler 选择两类 Worker，并协调阶段交接。

分离后的主要收益不是 FLOPs 下降，而是两个资源池可以独立排队、调优和扩容：

维度	Prefill Pool	Decode Pool
主要目标	降低 TTFT，提高 prompt 处理能力	降低并稳定 TPOT
资源配置侧重	为长 prompt 提供计算并行度；超长上下文需要分摊序列状态	扩展并发请求容量，同时保持单 token 延迟稳定
扩容依据	输入 token 到达率和 prompt 长度	活跃序列数和输出 token 速率

两个资源池可以根据各自的容量与延迟约束采用不同的 TP、PP、CP 或 DP 组合，具体定义和组合方式见第 3 节。

PD 分离不等于“Prefill 一定用大 batch，Decode 一定用小 batch”。 它提供的是独立寻找两个阶段计算饱和点和 SLO 边界的能力。

DistServe 报告，在其特定模型、请求分布、TTFT/TPOT SLO 和目标 SLO attainment 下，PD 分离支持的最大请求到达率最高提升 7.4×。这是该实验定义下的 goodput 提升，不是所有场景的裸吞吐都提高 7.4×。

2.3 KV cache Handoff 的新增成本

两个资源池通常各自承载模型权重或模型并行实例，因此分离还会增加权重驻留、实例预热和容量碎片。阶段边界不仅要交接 KV cache，还要传递当前生成位置、采样参数、停止条件和已生成 token ID 等请求元数据。Handoff 延迟可以粗略拆成固定开销与按数据量增长的传输开销：

T_{handoff}\approx T_{fixed}+\frac{S_{KV}}{B_{effective}}

其中，

T_{fixed}

是每次 Handoff 在批量数据传输前后的固定延迟，包括调度决策、控制元数据交换、源端与目标端同步、通信操作启动和首字节网络延迟；它不表示模型加载或 Worker 冷启动。

S_{KV}

是 KV cache 大小，

B_{effective}

是端到端有效带宽。若只比较请求关键路径上的延迟，PD 分离成立的必要条件可近似写为：

\Delta T_{interference} > T_{handoff}+\Delta T_{scheduling}+\Delta T_{queueing}

其中

\Delta T_{interference}

表示共置部署中被隔离掉的阶段干扰，后两项表示分离后新增的调度与排队时间。额外权重副本、容量碎片和运维复杂度不属于同一延迟量纲，应通过 goodput、GPU 数量或总体成本单独评估。 DistServe 对 OPT-175B 做过理想化估算：若每个 token 的 KV cache 约为 4.5 MB，2048 token 对应约 9.2 GB；若八条 64 GB/s 链路可被该传输并行且充分利用，理论传输时间约为 17.6 ms。

17.6 ms 不是一般部署的实测值。 它假设聚合带宽充分兑现、没有 Host 中转和链路争用。生产环境应测量 P95/P99 Handoff 延迟，并确认 GPUDirect RDMA 等直接路径真正生效。

进一步地，Mooncake 将 KV cache 视为可在 GPU VRAM、CPU DRAM 和 SSD 之间路由、复用和分层存储的集群资源，用于缓解跨池交接与缓存复用问题。该架构同时引入分层存储、传输调度和一致性管理，不等同于基础 PD 分离。

2.4 Chunked Prefill：保留共享资源池

PD 分离不是唯一方案。SARATHI 将长 prompt 划分为受每轮 token 预算限制的分块（chunk），每轮先安排延迟敏感的 Decode token，再用剩余预算执行 Prefill：

每轮 token budget = Decode token + Prefill chunk token

这样可以将少量 Decode token 与 Prefill 分块组成混合 batch，既限制单轮 Prefill 的阻塞时间，也摊薄权重读取成本。chunk 越小，阻塞时间越短，但矩阵效率和历史 KV 读取成本可能变差，因此需要通过 profiling 选择 chunk size。

	Chunked Prefill	PD 分离
资源组织	P/D 共享 GPU	P/D 使用独立资源池
优势	资源共享充分，无跨池 KV Handoff	干扰隔离彻底，可独立调优与扩容
代价	仍有资源竞争，chunk 参数敏感	网络、调度和容量规划更复杂
更适合	集群较小、SLO 可折中	TTFT/TPOT 都严格、负载差异大、网络条件好

二者也可以组合：Prefill Pool 内部对超长 prompt 分块，再将 KV cache 流水传给 Decode Pool。最终选择取决于 在哪个层级共享资源、在哪个层级隔离干扰。

2.5 方案选择与采用条件

PD 分离更适合以下场景：

共置部署已经出现明显的 Prefill/Decode 干扰；
TTFT 与 TPOT 都有严格 SLO；
集群足够大，可以独立调节两个资源池；
KV cache 能通过高带宽路径传输，且隔离收益大于 Handoff 成本。

容量规划还要考虑反压：Prefill Pool 不足会让 TTFT 队列增长；Decode Pool 不足会让已完成 Prefill 的请求携带 KV cache 等待，甚至反过来占用 Prefill 侧资源。某一侧持续饱和时，另一侧即使有空闲 GPU，也不能自动转化为有效吞吐。评估时应同时比较 goodput、P99 TTFT、P99 TPOT、KV Handoff 延迟、两侧队列长度和 GPU 利用率。PD 分离通过隔离两个目标不同的负载改善资源竞争，但不减少单次前向计算量。

3. 超大 MoE 模型的静态布局与混合并行

阶段资源组织确定请求在哪里执行；本节进一步确定模型权重、专家、上下文和请求如何映射到 GPU。配置需要同时满足容量、单请求延迟、服务吞吐和互联拓扑约束。

3.1 容量可行性与切分维度

并行配置首先必须通过容量可行性检查。Kimi K3 的公开参数可以量化超大 MoE 的部署压力：

指标	Kimi K3	对静态布局的影响
总参数量	2.8T（2.8 万亿）	全部专家权重需要分布到加速器集群
每 token 激活参数量	104B（1040 亿）	稀疏激活仍对应较大的单 token 计算规模
专家配置	896 个专家，每次激活 16 个	需要 EP 分布专家，并为运行时路由建立物理映射
上下文窗口	100 万 token	长 prompt 会放大 Prefill、KV cache 和 CP 需求

稀疏激活只减少单个 token 实际执行的专家子集，并不减少模型总权重的部署需求。只计算纯权重，并按十进制 GB/TB 和 NVIDIA 公布的单卡显存容量估算，理论最少 GPU 数量如下：

权重格式	理论权重容量	A100 80GB	H200 141GB	B200 180GB
BF16 / FP16（2 Bytes）	约 5.6 TB	70 张	40 张	32 张
FP8（1 Byte）	约 2.8 TB	35 张	20 张	16 张
4-bit（0.5 Byte）	约 1.4 TB	18 张	10 张	8 张

以 BF16 权重为例，按常见的 8-GPU 节点向上取整，纯权重理论下限分别对应 9 个 A100 节点、5 个 H200 节点和 4 个 B200 节点。实际部署还需为量化 scale、KV cache、激活值、通信缓冲区、CUDA 上下文和显存碎片预留空间，并满足专家与并行组的整除约束，因此实际 GPU 数量通常更高。

案例边界： 以上卡数只用于说明容量下限，不代表 Kimi K3 的实际部署配置。数据来源：Kimi K3 官方技术博客与 Kimi K3 技术报告。GPU 显存规格来自 NVIDIA 官方页面：A100 80GB、H200 141GB 和 DGX B200；B200 单卡 180GB 由 DGX B200 的 8 GPU、总计 1,440GB HBM3e 计算得到。

容量下限只回答“至少需要多少设备”，不能决定采用哪种并行方式。不同策略对应不同的超限维度，初始选择可依据以下映射：

单层权重或计算超过设备能力   → 层内切分：TP
TP 组内训练激活重复存储      → 序列激活切分：SP
模型深度导致整体容量不足     → 层间切分：PP
MoE 专家总状态超过设备容量   → 专家切分：EP
单实例请求吞吐不足           → 实例复制：DP
单请求上下文超过设备能力     → Attention 上下文切分：CP

六种策略的切分对象、通信模式与主要代价如下。SP 通常复用 TP group，是 TP 的激活内存优化，而不是独立扩大的并行维度：

策略	切分对象	主要解决的问题	关键通信	主要代价
Tensor Parallelism（TP）	一层内部的权重矩阵和计算	单层太宽；希望降低单实例计算延迟	每层或子层执行 All-Reduce	通信频繁，依赖高速互联
Sequence Parallelism（SP）	TP 组内非 TP 区域的 sequence activation	LayerNorm、Dropout 等训练激活重复存储	All-Gather / Reduce-Scatter	collective 次数增加；通常需与 TP 配合
Pipeline Parallelism（PP）	Transformer 层	模型太深，单个设备或 TP 组容纳不下	stage 之间传递激活值	pipeline bubble，单请求路径变长
Expert Parallelism（EP）	MoE 专家	专家总参数量太大	MoE 层前后执行 All-to-All	通信密集，容易出现专家负载不均
Data Parallelism（DP）	请求；模型实例整体复制	单实例吞吐不足	推理副本通常独立工作	每个副本都要占用权重和缓存空间
Context Parallelism（CP）	Attention 的上下文位置	上下文太长，单卡 KV cache 或 Attention 压力过大	交换 K/V Block 或 Attention 中间结果	Attention 实现复杂，短序列收益有限

切分维度： TP 切层内权重与计算，SP 切 TP 组内非 TP 区域的训练激活，PP 切层间，EP 切专家，DP 切请求，CP 切 Attention 上下文。

四种集合通信的语义与典型用途如下：

通信操作	直观含义	常见用途
All-Reduce	每张卡先计算局部结果，再求和并让所有卡拿到合并结果	TP 合并局部计算
All-Gather	每张卡持有一部分数据，交换后让参与者获得完整数据	SP 从 sequence shard 恢复完整激活
Reduce-Scatter	先对各卡数据求和，再让每张卡保留结果的一部分	SP 将 TP 输出规约并切回 sequence shard
All-to-All	每张卡都向其他卡发送不同的数据	EP 将 token 分发给专家并收回结果

这些策略可以组合，但并非所有并行度都构成相互独立的乘积。例如，SP 复用 TP group，而 EP 在不同框架中也可能与 TP 或 DP 维度重组。各策略的组合方式将在 3.7 节统一讨论。

3.2 Tensor Parallelism（TP）：层内并行与集合通信约束

结论： TP 让多张 GPU 同时计算同一层，从而分摊权重并缩短计算时间；代价是几乎每层都要同步，因此只能在高速互联域内有效扩展。

TP 将同一层中的权重矩阵按行或按列切分。每张 GPU 只保存并计算其中一部分，随后通过集合通信合并局部结果。TP 的特点是 计算和通信都发生在每一层内部。所有参与设备必须保持接近同步：其中一张 GPU 或一条链路变慢，整组设备都会等待。因此，TP 的性能上限很大程度上由互联带宽和集合通信延迟决定。

经典案例：Megatron-LM 的 Attention 与 MLP 张量并行

经典 Megatron-LM 将 Transformer 中成对出现的线性层组织为“列并行输入投影 + 行并行输出投影”。设 TP group 包含

p

个 rank，输入 hidden state

X

在各 rank 上保持一致。

Megatron-LM Figure 3：MLP 与 Self-Attention 的列并行、行并行和 f/g 通信算子 — Megatron-LM 在 MLP 与 Self-Attention 中的张量并行

论文原图：上半部分为 MLP，第一个 GEMM 按列切分、第二个 GEMM 按行切分；下半部分为按 attention head 切分的 Self-Attention。 $f$ 在前向为 identity、反向执行 All-Reduce； $g$ 在前向执行 All-Reduce、反向为 identity。来源：Megatron-LM，Figure 3。推理只执行前向传播，因此每个 Transformer layer 的主要 TP 通信是 Attention 和 MLP 输出端各一次 All-Reduce。下面同时给出训练反向传播与 SP 的通信量，作为理解 Megatron 并行实现和显存权衡的补充。

TP 与 SP 的前向、反向通信量

Attention 前向传播：

将 $W_Q$ 、 $W_K$ 和 $W_V$ 按输出维度切分，每个 rank 计算一组完整 attention head 的 $Q_i$ 、 $K_i$ 和 $V_i$ ；
每个 rank 在本地完成 $Q_iK_i^T$ 、softmax 和与 $V_i$ 的乘法，head 内计算不需要跨 rank 通信；
将输出投影 $W_O$ 按输入维度切分，每个 rank 得到部分结果 $O_i$ ；
对部分结果执行 All-Reduce：

O=\sum_{i=1}^{p}O_i

MLP 前向传播：设两层 MLP 为

Y=\operatorname{GeLU}(XW_1)W_2

。

W_1

按输出维度切分，每个 rank 独立计算

Z_i=\operatorname{GeLU}(XW_{1,i})

；逐元素 GeLU 不需要通信。

W_2

按输入维度切分，各 rank 计算部分输出

Y_i=Z_iW_{2,i}

，随后执行

Y=\sum_iY_i

的 All-Reduce。为同时比较通信次数与数据量，设 Transformer 边界激活包含

s\times b\times h

个元素，每个元素占

\beta

字节，并记完整激活大小为：

S=sbh\beta

以下采用 Ring Collective 的带宽模型，统计每个 rank 为完成一次 collective 需要传输的数据量；不统计链路级聚合流量。对于

p

个 rank：

V_{AR}=2\frac{p-1}{p}S,\qquad V_{AG}=V_{RS}=\frac{p-1}{p}S

其中

AR

、

AG

和

RS

分别表示 All-Reduce、All-Gather 和 Reduce-Scatter。经典 TP 在 Attention 和 MLP 中各有两个通信边界：输入端的

f

与输出端的

g

。

模块与通信位置	前向操作	前向通信量 / rank	反向操作	反向通信量 / rank
Attention 输入端 $f$ ，进入 $W_Q,W_K,W_V$ 前	Identity	$0$	All-Reduce 输入梯度	$2\frac{p-1}{p}S$
Attention 输出端 $g$ ，完成 $W_O$ 后	All-Reduce 部分输出	$2\frac{p-1}{p}S$	Identity	$0$
MLP 输入端 $f$ ，进入 $W_1$ 前	Identity	$0$	All-Reduce 输入梯度	$2\frac{p-1}{p}S$
MLP 输出端 $g$ ，完成 $W_2$ 后	All-Reduce 部分输出	$2\frac{p-1}{p}S$	Identity	$0$

反向传播中的通信位置与前向互补。行并行输出端的上游梯度可以直接分发给各 rank，各 rank 本地计算本分片的激活梯度和权重梯度；继续反传至列并行输入端时，每个 rank 只得到对复制输入

X

的一部分梯度，必须执行 All-Reduce：

\frac{\partial L}{\partial X} = \sum_{i=1}^{p} \left(\frac{\partial L}{\partial X}\right)_i

因此，经典 TP 每个 Transformer layer 合计产生 前向 2 次 All-Reduce、反向 2 次 All-Reduce。对应的每 rank 通信量为：

范围	前向通信量 / rank	反向通信量 / rank	前向 + 反向
Attention	$2\frac{p-1}{p}S$	$2\frac{p-1}{p}S$	$4\frac{p-1}{p}S$
MLP	$2\frac{p-1}{p}S$	$2\frac{p-1}{p}S$	$4\frac{p-1}{p}S$
每个 Transformer layer	$4\frac{p-1}{p}S$	$4\frac{p-1}{p}S$	$8\frac{p-1}{p}S$

推理只执行前向，因此主要承担两次输出端 All-Reduce；训练还要承担两次输入梯度 All-Reduce。TP 分片内的权重梯度在本 rank 计算，若同时使用 DP，跨副本的梯度同步属于 DP 通信，不应计入这里的 TP 通信。

Sequence Parallelism：切分非 TP 区域的激活

经典 TP 切分 Attention 和 MLP 的大矩阵乘，但 LayerNorm、Dropout 和残差连接仍在各 TP rank 上保存完整的

s\times b\times h

激活。Megatron-LM 的 Sequence Parallelism（SP）沿 sequence 维度切分这些非 TP 区域，使每个 rank 只保存约

S/p

的边界激活；进入 TP 区域时恢复完整 sequence，离开 TP 区域时再切回 sequence shard。

Megatron-LM Figure 5：Attention 与 MLP 两侧通过 All-Gather 和 Reduce-Scatter 在 TP 与 SP 区域之间转换 — Megatron-LM 中 Tensor Parallelism 与 Sequence Parallelism 的组合

论文原图：Attention 与 MLP 是 Tensor Parallel 区域，LayerNorm、Dropout 和残差连接是 Sequence Parallel 区域。 $g$ 在前向执行 All-Gather、反向执行 Reduce-Scatter； $\bar g$ 在前向执行 Reduce-Scatter、反向执行 All-Gather。来源：Reducing Activation Recomputation in Large Transformer Models，Figure 5。SP 将经典 TP 边界上的一次 All-Reduce 拆为一次 Reduce-Scatter 和一次 All-Gather。只计算这些边界 collective 时，Attention 与 MLP 两侧的前向、反向通信量如下：

模块与通信位置	前向操作	前向通信量 / rank	反向操作	反向通信量 / rank
Attention 输入端 $g$ ，SP → TP	All-Gather sequence shard	$\frac{p-1}{p}S$	Reduce-Scatter 输入梯度	$\frac{p-1}{p}S$
Attention 输出端 $\bar g$ ，TP → SP	Reduce-Scatter 部分输出	$\frac{p-1}{p}S$	All-Gather 输出梯度	$\frac{p-1}{p}S$
MLP 输入端 $g$ ，SP → TP	All-Gather sequence shard	$\frac{p-1}{p}S$	Reduce-Scatter 输入梯度	$\frac{p-1}{p}S$
MLP 输出端 $\bar g$ ，TP → SP	Reduce-Scatter 部分输出	$\frac{p-1}{p}S$	All-Gather 输出梯度	$\frac{p-1}{p}S$

但这还不是保留完整 SP 显存收益时的全部反向通信。列并行层的权重梯度需要完整序列输入：

\nabla W_i=X^T\nabla Y_i

如果前向只保存 sequence shard

X_i

，而不保留 All-Gather 后的完整

X

，反向计算权重梯度前必须再次 All-Gather 输入激活。这在每个 Transformer layer 中通常发生两次：Attention 的 QKV 列并行投影一次，MLP 的

W_1

列并行投影一次。

反向额外通信位置	用途	通信量 / rank
Attention QKV 权重梯度计算前	All-Gather 保存的输入 shard，重建完整 $X$	$\frac{p-1}{p}S$
MLP $W_1$ 权重梯度计算前	All-Gather 保存的输入 shard，重建完整 $X$	$\frac{p-1}{p}S$

因此需要区分两种统计口径：

范围	前向通信量 / rank	反向通信量 / rank	前向 + 反向
经典 TP	$4\frac{p-1}{p}S$	$4\frac{p-1}{p}S$	$8\frac{p-1}{p}S$
TP+SP，仅统计替代 All-Reduce 的边界 collective	$4\frac{p-1}{p}S$	$4\frac{p-1}{p}S$	$8\frac{p-1}{p}S$
TP+SP，只保存 sequence shard 并在反向重建输入	$4\frac{p-1}{p}S$	$6\frac{p-1}{p}S$	$10\frac{p-1}{p}S$

论文所说“TP 与 TP+SP 通信带宽相同”，对应第二行：4 次 All-Reduce 等价于 4 次 All-Gather 加 4 次 Reduce-Scatter。实际 Megatron Core 为保留激活显存收益，只保存前向输入 shard，并在反向为权重梯度额外执行 2 次 activation All-Gather；在上述等尺寸近似下，总通信量比经典 TP 高约 25%。实现会将 activation All-Gather 与输入梯度 GEMM 重叠，并将输入梯度 Reduce-Scatter 与权重梯度 GEMM 重叠，因此网络字节数增加不等于关键路径时间按相同比例增加。如果保留前向 All-Gather 后的完整输入，反向可以避免这两次额外通信，但会失去相应的激活显存节省；冻结权重或仅执行推理时不计算权重梯度，也不需要这两次反向 activation All-Gather。

实现边界： 这里的 SP 是 Megatron-LM 中与 TP 配合使用、以降低训练激活显存为目标的 Sequence Parallelism，不等同于为超长上下文切分 Attention 计算的 Context Parallelism。通信量采用等尺寸边界张量与理想 Ring Collective 模型；QKV/门控投影融合、重计算、梯度累积、collective 算法和框架融合方式均可能改变实际通信字节数与关键路径。来源：原始 SP 论文与 Megatron Core Tensor Parallel API。

TP 同时解决容量和延迟问题

TP 有两个常见动机：

容量需求：单层权重或单个 MoE 专家无法放入一张 GPU；
延迟需求：希望多张 GPU 并行完成同一层计算，缩短单个模型实例的前向时间。

在 Transformer 中，TP 主要用于 Attention 投影和 FFN/MLP 的大矩阵乘。它不需要修改或近似模型权重，因此不会像量化那样直接引入数值精度变化。 TP 是否能降低延迟，取决于一个简单关系：

T_{TP} \approx T_{compute}/N + T_{collective}

其中

N

是 TP 规模。随着

N

增大，单卡计算量下降，但集合通信不会同比消失。当

T_{collective}

接近甚至超过节省的计算时间后，继续扩大 TP 只会增加同步成本。

TP 的有效范围由互联拓扑决定

硬件范围	互联条件	对 TP 的含义
单机多卡	NVLink / NVSwitch	通常是最适合建立 TP 组的范围
NVL72 机架	72 GPU NVLink 域，约 130 TB/s 聚合带宽	可以建立更大的 TP 组，但仍会出现收益递减
普通跨节点集群	InfiniBand / RoCE / Ethernet	延迟更高，应谨慎扩大 TP 组
跨机架 NVLink Switch System	最多可形成 576 GPU 的全连接域	说明技术可达规模，不等于 576-way TP 是生产最优配置

Blackwell 第五代 NVLink 的聚合双向 GPU-to-GPU 带宽最高可达 1.8 TB/s；NVL72 将高速互联域扩展到 72 张 GPU。即便硬件允许更大规模 TP，生产配置仍应优先考虑 收益递减点，而不是追求理论上最大的并行度。 TP 的实用原则是：

把高频集合通信限制在最快的互联域内，并在节省的计算时间无法覆盖新增通信时间之前停止扩大 TP。

因此，常见部署将 TP group 限制在单个 8-GPU 节点或一个 NVSwitch 域内，再使用 PP、EP 或 DP 实现跨节点扩展。

3.3 Pipeline Parallelism（PP）：模型容量与流水线延迟

结论： PP 让不同设备保存不同层，主要解决整个模型放不下的问题；单个 token 仍要依次经过全部 stage，因此它通常不用于降低 Decode 延迟。

PP 将连续的 Transformer 层分配给不同 GPU 或 GPU 组。例如，一个 60 层模型可以被拆成三个 stage：

PP 的主要价值是 分摊模型状态。只要 stage 间的激活值能够传输，模型就可以跨越多个节点，因此 PP 对互联带宽的要求通常低于每层都要同步的 TP。

Prefill 与 Decode 中的 PP 差异

阶段	PP 的表现	原因
Prefill	在长序列或多 microbatch 下可以获得较好吞吐	多个 microbatch 能同时占据不同 stage，流水线容易被填满
Decode	单请求延迟通常不会改善，甚至可能增加	每个新 token 都必须依次通过全部 stage，存在填充、排空和等待

对单个 Decode 序列，token

t+1

必须等待 token

t

走完整条流水线。为了减少 stage 空闲，系统通常把不同请求组成 microbatch，让它们交错进入各个 stage。但这只能提高整体吞吐，无法消除单个 token 穿过全部 stage 的串行路径。因此，PP 主要用于满足模型容量约束，其代价是增加流水线延迟；该策略通常不用于降低单请求延迟。这也解释了 TP 与 PP 的分工：TP 处理“层太宽”，PP 处理“模型太深”。常见组合是先在节点内用 TP 拆分层内计算，再用较小的 PP 规模跨节点分摊层数。

3.4 Expert Parallelism（EP）：专家布局与激活通信

结论： EP 将不同专家分布在不同 GPU 上，以满足 MoE 专家权重的容量约束；每个 MoE 层因此需要执行 token activation 的分发与结果回收。

EP 是 MoE 特有的并行方式。假设一个 MoE 层有 16 个专家，分布在 4 张 GPU 上，每张 GPU 保存 4 个专家。gating network 为每个 token 选择 top-k 专家后，系统需要完成两次数据重排：

Dispatch：把 token 的激活向量发送到目标专家所在的 GPU；
Combine：专家计算完成后，把结果送回原来的 token 顺序并合并。

EP 允许专家总数随 GPU 数量扩展，而单个 token 仍只执行 Top-k 专家。例如，100 个等规模专家分布在 100 张 GPU 上、每个 token 选择 2 个专家时，专家计算量由这 2 个专家决定，而不是由全部 100 个专家决定。代价是每个 MoE 层都需要执行通信密集的 All-to-All。随着 EP group 扩大，通信拓扑、消息粒度和专家负载偏斜会逐渐成为关键瓶颈。

All-to-All 通信量模型与数值例子

设一个 EP group 包含

P

个 rank，一个 MoE 层在整个 EP group 内处理

T

个 token，每个 token 选择

k

个专家，hidden size 为

H

，每个激活元素占

b

字节。忽略路由元数据、对齐和压缩时，Dispatch 的逻辑数据量为：

S_{dispatch}^{logical}\approx T k H b

Combine 将专家输出送回 token 的来源 rank。若专家输入与输出 hidden size 相同，两轮逻辑数据总量为：

S_{dispatch+combine}^{logical}\approx 2T k H b

逻辑数据量包含本地 assignment。设需要跨 rank 传输的 assignment 比例为

r_{remote}

，则实际进入网络的数据量近似为：

S_{network}\approx 2T k H b\,r_{remote}

在专家均匀放置、路由目的地近似均匀且没有专家副本时，本地命中概率约为

1/P

，因此：

r_{remote}\approx\frac{P-1}{P}

此时每个 rank 在 Dispatch 与 Combine 两轮中平均发送的数据量约为：

S_{rank}\approx\frac{2T k H b}{P}\frac{P-1}{P}

每个源 rank 的数据还会分散到多个目的 rank。均匀情况下，单个 source-destination pair 的平均 Dispatch 消息大小约为：

M_{peer}\approx\frac{T k H b}{P^2}

该公式说明，扩大 EP group 虽然降低了每个 rank 保存的专家数量，但会把相同数据拆成更多小消息；All-to-All 可能由消息启动延迟而非总带宽主导。数值例子： 假设一个 MoE 层在 8-rank EP group 中处理 4096 个 token，采用 Top-2 路由，

H=8192

，激活为 BF16（

b=2

Bytes）。

指标	估算结果
Dispatch 逻辑数据量 $TkHb$	128 MiB
远端 Dispatch 数据量， $r_{remote}=7/8$	112 MiB
Dispatch + Combine 远端数据量	224 MiB / MoE layer
每 rank 两轮平均发送量	28 MiB
每个 source-destination pair 的平均 Dispatch 消息	约 2 MiB

如果其他条件不变，只把 Top-2 改为 Top-16，逻辑与远端通信量都会增加 8 倍：Dispatch + Combine 的远端数据量约为 1.75 GiB / MoE layer。这只是容量估算，不代表延迟也严格增加 8 倍，因为 kernel 效率、通信计算重叠和链路饱和程度也会变化。平均通信量不足以决定 All-to-All 延迟。令

n_{i\rightarrow j}

表示从 rank

i

发往 rank

j

的 assignment 数，则：

S_{i\rightarrow j}=n_{i\rightarrow j}Hb

Dispatch 的关键路径更接近最繁忙 rank 或链路，而不是全组平均值：

T_{dispatch}\gtrsim T_{fixed}+ \max_i\left( \frac{S_i^{send}}{B_i^{send}}, \frac{S_i^{recv}}{B_i^{recv}} \right)

其中

T_{fixed}

包括 collective 调度、同步和小消息启动延迟。因此，相同的

TkHb

可能产生完全不同的延迟：均匀路由主要受带宽和消息粒度影响，热点专家则会使少数目的 rank 的接收流量和专家队列同时增长。路由元数据、capacity padding、通信对齐、节点内本地复制以及跨节点比例还会进一步改变实测字节数。

论文原图：52B、128 专家的 MoE 模型在 8–64 张 GPU 上的延迟和单 GPU 吞吐；DeepSpeed-MoE 的优化路径与 PyTorch 基线对比。来源：DeepSpeed-MoE，Figure 10。该图验证的是特定系统实现，不代表所有 MoE 都能获得相同扩展曲线。

实验观察： 增加 GPU 只有在专家并行通信和 kernel 实现同步优化时才能转化为有效扩展；GPU 数量本身不保证延迟下降或单卡吞吐稳定。

单 token 稀疏性与集群级设备利用率

从单个 token 看，它只访问少数专家，计算确实是稀疏的；从高并发服务的聚合视角看，不同 token 会选择不同专家，一批请求很可能让大多数甚至全部专家同时工作。这两个结论并不矛盾：

算法视角：每个 token 的计算量是稀疏的；
系统视角：在常规低延迟部署中，专家权重仍需在设备侧可用；高并发下，多数 GPU 可能同时活跃并持续参与 All-to-All。

因此，MoE 的主要收益是用较低的单 token 计算量换取更大的模型容量，而不是让生产集群中的大部分 GPU 长期闲置。MoE 推理的工程难点也由此集中在 通信效率和专家负载均衡 上。

EP 与动态路由的职责边界

Gating 结果通常不会完全均匀。如果某些专家收到的 token 明显更多，它们会成为热点；而一个 MoE 层必须等待相关专家完成后才能继续，因此最慢专家会决定整层延迟，这就是 straggler effect。这里需要区分两个层次：

EP 是静态放置问题：哪些专家保存在哪些 GPU 上；
动态路由是运行时调度问题：当前 token 如何到达专家，热点如何限流、复制或迁移。

因此，EP 只回答了“专家放在哪里”，并没有自动解决 All-to-All 效率和负载均衡。完成单实例的其余切分与混合并行配置后，第 4 节将继续分析 Capacity Factor、热点专家复制和专家重放置等运行时机制。

3.5 Context Parallelism（CP）：序列切分与跨设备通信

结论： CP 将一个请求的序列位置分到多张 GPU，分摊超长上下文的计算和状态；但全局 Attention 仍需跨卡交换信息。

超长上下文会同时带来两类压力：

Prefill 的 Attention 计算量和延迟快速增长；
KV cache 随序列长度增长，可能超过单卡容量。

CP 将一个请求的序列位置分布到多张 GPU，使每张 GPU 只保存和处理其中一部分上下文。

经典 CP 方法与实现流程

自回归 Transformer 中，每个 Query 需要访问此前所有相关 Key/Value。CP 方法都沿 sequence 维度分摊输入，但必须通过通信恢复全局 Attention 依赖。常见实现包括全量收集、环形分块、sequence—head 维转置和二维混合；Striped Attention 则针对因果 Ring 的负载不均改进数据布局。

术语说明： DeepSpeed-Ulysses、Ring Attention 和 USP 的论文通常使用 Sequence Parallelism 描述长序列 Attention 切分；本章按 Megatron 的术语将它们归入 CP，因为它们切分 Attention 上下文。这里的 SP 专指 3.2 节中复用 TP group、切分非 TP 区域训练 activation 的 Megatron Sequence Parallelism。

经典 CP 方法的执行流程

1. All-Gather KV：实现最直接的基线每个 rank 保留本地 Query，并收集所有 rank 的 K/V：

本地 Q_i, K_i, V_i
        │
        │ All-Gather K/V
        ▼
本地 Q_i + 全局 K/V
        │
        ▼
计算本地 Query 对全局上下文的 Attention

前向完成后，每个 rank 只输出本地 Query 对应的结果；反向需要将不同 rank 产生的 K/V 梯度归并到 K/V 所属 rank，语义上对应 Reduce-Scatter。该方法通信轮次少、实现简单，但 Attention 期间每个 rank 都临时持有完整 K/V，峰值显存随全局序列长度增长，因此只适合 CP degree 较小或上下文尚未达到极端规模的场景。2. Ring Attention：固定 Query，循环 K/V BlockRing Attention 将序列切成

C

个连续块。rank

i

的 Query block

Q_i

始终留在本地，K/V block 沿 CP ring 循环：

初始化：Q_i 固定，当前持有 K_i/V_i

每一轮：
用 Q_i 与当前 K/V Block 计算局部 Attention；
异步把当前 K/V 发送给下一个 rank；
从上一个 rank 接收下一块 K/V；
使用在线 Softmax 统计量合并局部结果；
重复 C 轮，直到处理全部 K/V Block。

论文原图：每个 rank 固定本地 Query，并在计算当前 Attention Block 的同时发送、接收下一块 K/V。来源：Ring Attention with Blockwise Transformers for Near-Infinite Context，Figure 2。不同 K/V Block 的 Softmax 不能独立计算后直接相加。每个 Query 行需要维护历史最大值、归一化分母和 Value 累加量，通过在线 log-sum-exp 合并各块结果。因此 Ring Attention 保持精确全注意力，不是稀疏或近似 Attention。Ring 在计算期间只需保存当前 K/V Block；采用双缓冲时通常同时保留当前块和下一块，而不必物化完整全局 K/V。该方法需要约

C

轮点对点通信。采用双缓冲时，当前 Block 的 Attention 计算可以与下一块 K/V 的传输重叠；如果网络传输慢于 Block 计算，设备仍会等待通信。反向传播沿对应的环形路径交换 K/V 及其梯度，并把不同 Query Block 对同一 K/V Block 的梯度归并回所属 rank。3. Striped Attention：为因果 Attention 均衡 Ring 计算量连续分块的 Ring Attention 在因果场景中存在负载不均：靠前的 Query Block 只能访问少量历史 K/V，靠后的 Query Block 需要处理更多有效 Block。Striped Attention 不按连续区间分配 token，而是按位置交错分配：

\operatorname{rank}(i)=i\bmod C

例如 3 个 rank 处理 12 个位置时，各 rank 分别保存

\{0,3,6,9\}

、

\{1,4,7,10\}

和

\{2,5,8,11\}

。每个 rank 的 token 分布覆盖整条序列，使因果三角形的有效计算更均匀地分散到各轮。它仍使用 Ring 的 K/V P2P 通信并保持精确 Attention，代价是位置布局更不连续，数据准备、位置编码和 kernel 实现更复杂。来源：Striped Attention。4. DeepSpeed-Ulysses：在 sequence 与 attention head 之间执行 All-to-All 转置Ulysses 在 Attention 外保持 sequence-sharded 布局。设 CP degree 为

C

，注意力头数为

A

：

初始布局：每个 rank 持有 [s/C, A]，即部分序列、全部 heads
       │
       │ QKV 投影后执行 All-to-All
       ▼
Attention 布局：每个 rank 持有 [s, A/C]，即完整序列、部分 heads
       │
       │ 本地计算所负责 heads 的完整序列 Attention
       ▼
逆 All-to-All
       │
       ▼
恢复 [s/C, A] 的 sequence-sharded 布局

第一次 All-to-All 同时收集序列分片并切分 attention heads，第二次 All-to-All 收集不同 heads 的输出并重新切回 sequence shard。该方法没有 Ring 的多轮流水，但依赖高效 All-to-All，并通常要求 attention head 数能被 Ulysses degree 整除。GQA/MQA 的 KV head 或 query group 数较少时，可用的 All-to-All degree 可能受到更严格限制。来源：DeepSpeed-Ulysses。5. USP 与 Hierarchical CP：组合 Ulysses 和 RingUSP 将总 CP group 组织为二维网格：

C=U\times R

其中

U

为 Ulysses degree，

R

为 Ring degree。初始每个 rank 保存约

s/(UR)

个 token；先在 Ulysses group 内执行 All-to-All，得到

s/R

长度、部分 heads 的布局，再在 Ring group 内循环 K/V Block，最后执行逆 All-to-All 恢复原始 sequence shard。

[s/(U·R), 全部 heads]
        │ Ulysses All-to-All
        ▼
[s/R, 1/U heads]
        │ Ring 维度循环 K/V
        ▼
[s/R, 1/U heads] 的 Attention 输出
        │ 逆 All-to-All
        ▼
[s/(U·R), 全部 heads]

这种二维方法可以把 Ulysses All-to-All 放在 NVLink/NVSwitch 域内，把 Ring P2P 放在跨节点链路上；同时用较小的

U

满足 GQA/MQA 的 head 整除约束，再通过

R

扩大总 CP degree。代价是进程网格、拓扑映射和通信计算重叠更复杂。来源：USP。Megatron Core 中的 a2a+p2p 和 Hierarchical CP 采用相近的工程分层思想。

方法差异与选型

方法	Attention 内的数据布局	主要通信	峰值 K/V 显存	主要优势	主要限制
All-Gather KV	本地 Query + 完整 K/V	All-Gather / Reduce-Scatter	高，临时保存完整 K/V	实现简单，通信轮次少	超长序列下峰值显存高
Ring Attention	本地 Query + 流动 K/V Block	多轮 P2P Send/Recv	低，约 1–2 个本地 K/V Block	易扩展到较大 CP degree，可流水重叠	Ring 轮数和启动延迟随 degree 增长
Striped Attention	交错 Query 位置 + 流动 K/V 条带	多轮 P2P Send/Recv	低	改善 causal Ring 的计算负载不均	非连续位置布局增加实现复杂度
Ulysses	完整 sequence + 部分 attention heads	两次 All-to-All 布局转换	中等，不复制全部 heads	通信阶段少，适合高速全互联	受 Q/KV head 数和整除性限制
USP / `a2a+p2p`	Ulysses head shard + Ring sequence shard	组内 All-to-All + 组间 P2P	低	匹配分层网络，突破纯 Ulysses degree 限制	配置和调优最复杂

Megatron Core 将这些路径统一为不同 cp_comm_type：all_gather 对应全量 K/V 收集，p2p 对应 Ring 路径，a2a 对应 Ulysses 式 sequence/head 转置，a2a+p2p 对应分层混合。选择时应同时考虑上下文长度、CP degree、Q/KV head 数、节点内外网络差异以及计算能否覆盖通信。

CP 的能力边界： 上述方法都分摊了每设备的 Attention 状态与计算，但没有改变精确全注意力 $O(s^2)$ 的全系统总计算复杂度。它们主要改变的是每卡显存、计算分配和通信方式。对短 prompt 或逐 token Decode，Query 计算量较小，通信更难被隐藏，CP 不一定带来延迟收益。NVIDIA 工程实现参考：Megatron Core Context Parallelism。

CP 与 SP 的职责边界及组合

CP 和 SP 都沿 sequence 维度切分数据，但目标和执行阶段不同：

维度	Sequence Parallelism（SP）	Context Parallelism（CP）
主要目标	降低训练时非 TP 区域的 activation 显存	分摊超长上下文的 Attention 计算和 KV 状态
切分范围	LayerNorm、Dropout、Residual 等非 TP 区域	Attention 的全局上下文位置
进入 Attention 后	在 TP group 内 All-Gather，恢复当前 CP 分片的完整输入	Ring 类方法保持上下文分片并交换 K/V；Ulysses 类方法恢复完整 sequence，但只保留部分 heads
主要通信	TP group 内的 All-Gather / Reduce-Scatter	P2P K/V 交换、All-Gather 或 sequence—head All-to-All
主要使用阶段	训练	训练和推理
与 TP 的关系	通常复用 TP group，不增加独立 rank 维度	构成独立的 CP rank 维度，可与 TP 组合

因此，SP 的 sequence 切分主要是一种 activation 存储布局：进入 TP 计算区域时会临时恢复当前 CP 分片的完整输入。CP 则改变 Attention 的执行布局：Ring 类方法始终保留上下文分片并交换 K/V Block；Ulysses 类方法会为部分 attention heads 临时恢复完整 sequence，但不会在单个 rank 上同时复制全部 sequence 和全部 heads。二者可以同时使用。以下以保持上下文分片的 Ring 类 CP 为例。设全局序列长度为

s

，TP/SP 大小为

p

，CP 大小为

c

。在 LayerNorm 等 SP 区域，每个 rank 保存：

\left[\frac{s}{cp},b,h\right]

进入 Attention 前，SP 在 TP group 内执行 All-Gather，只恢复当前 CP rank 负责的上下文分片：

\left[\frac{s}{cp},b,h\right] \xrightarrow{\text{TP-group All-Gather}} \left[\frac{s}{c},b,h\right]

QKV 列并行后，每个 TP rank 计算当前 CP 分片上的部分 attention head：

\left[\frac{s}{c},b,\frac{h}{p}\right]

随后 CP group 交换远端 K/V，使本地 Query 能够关注全局上下文。Attention 输出完成 TP 行并行投影后，再通过 Reduce-Scatter 切回

[s/(cp),b,h]

的 SP 布局。 SP 复用 TP group，因此不应作为 world size 的独立乘数。忽略 EP 等框架相关维度时，组合关系通常写为：

\text{World Size}=TP\times CP\times PP\times DP,\qquad \text{SP Size}=\text{TP Size}

组合边界： SP 主要减少训练 activation 的长期存储，CP 主要分摊 Attention 上下文。二者组合后，SP 的 All-Gather 只恢复 CP-local sequence，而不是全局 sequence；全局依赖仍由 CP 通信完成。

3.6 Data Parallelism（DP）：实例复制与请求吞吐扩展

结论： DP 不再切分单个请求，而是复制完整模型实例，让不同副本并行处理不同请求。它提高整体吞吐，但不会缩短某个请求的模型路径。

推理中的 DP 与训练中的 DP 目标不同：

训练 DP 复制模型，并通过梯度同步保持副本一致；
推理 DP 让不同副本独立处理不同请求，副本之间通常不需要同步前向结果。

这里的“副本”不一定只占一张 GPU。一个副本本身可以由 TP、PP、EP 和 CP 组成。例如，一个模型实例需要 8 张 GPU 才能运行，那么两个 DP 副本一共需要 16 张 GPU。

DP 对请求吞吐与单请求延迟的影响

如果一个副本可以处理 10 req/s，8 个相互独立的副本在理想情况下可以接近 80 req/s。但某个请求仍然只由其中一个副本处理，因此其模型前向路径没有变短。

优势	代价
扩展方式直观，吞吐可随副本数接近线性增长	每个副本都需要一份完整的模型状态和 KV cache 空间
不同副本之间通常没有推理通信	GPU 数量和硬件成本随副本数增长
便于故障隔离和水平扩缩容	需要负载均衡，并考虑 Prefix/KV cache 的局部性

DP 最适合用在 单个模型实例已经调优完成，但业务并发继续增长 的阶段。它通常是扩展吞吐的最后一层，而不是解决单实例容量问题的第一步。

3.7 Hybrid Parallelism：配置顺序、拓扑映射与验证

结论： 高频、细粒度通信应留在最快的互联域；跨节点尽量使用频率更低、消息更大的通信。混合并行是在容量、延迟、吞吐和物理拓扑之间寻找可行解。

生产环境中的超大 MoE 通常组合多种并行方式：TP、PP、EP 和 CP 共同满足单实例的容量与延迟约束；训练时可在 TP group 内叠加 SP 以分摊激活；单实例配置稳定后，再通过 DP 扩展请求吞吐。

Megatron-LM 中 Tensor Parallelism 与 Pipeline Parallelism 的组合

论文原图：Megatron-LM 在每个 Transformer layer 内使用 TP，再沿模型深度使用 PP。图来自训练论文，但“高频层内通信限制在小组内、较粗粒度激活跨 stage 传递”的组织方式同样适用于理解推理。来源：Megatron-LM，Figure 2。

实验观察： TP 与 PP 并非二选一：TP 在层内形成高频通信组，PP 沿模型深度传递激活，两类通信应映射到不同层级的物理互联。

64-GPU Rank Mesh 示例

为了让维度关系可计算，假设某个推理框架将 PP、TP 与 EP 组织为相互正交的 rank mesh，并使用 64 张 GPU 运行一个模型实例：

\text{World Size}=PP\times TP\times EP=4\times2\times8=64

维度	配置示例	解决的问题
PP = 4	模型层拆成 4 个 stage	分摊模型深度和权重容量
TP = 2	每个 stage 内建立 2-GPU TP group	分摊层内权重与计算
SP = 2	训练时复用同一个 2-GPU TP group	分摊非 TP 区域的 activation；不增加 world size
EP = 8	每个 MoE 层的专家在 8 个 EP rank 间分布	分摊专家参数并限定 All-to-All 范围
DP = 1	64 张 GPU 共同组成一个实例	暂不复制模型

如果每个 MoE 层有 64 个专家，在没有额外副本时，每个 EP rank 保存 8 个专家。再部署 2 个 DP 副本，需要两套 64-GPU 实例，共 128 张 GPU。不同框架对 EP、TP 与 DP 的 rank group 组织并不完全相同，EP 有时会占用或重组 DP 维度。SP 通常使用 TP group 的相同 rank，只改变 activation 布局，因此不出现在

PP\times TP\times EP

的 world-size 乘积中。上例只用于展示一个维度明确、乘积闭合的 mesh，实际配置必须以目标框架的并行语义为准。

混合并行的配置顺序

并行策略不存在脱离硬件和负载的固定最优值，但可以按以下顺序缩小搜索空间：

先满足容量约束：确定权重和最大 KV cache 是否能放入目标设备；
让 TP 停留在高速互联域内：扩大到继续增加 GPU 不再降低端到端延迟为止；
训练 activation 成为瓶颈时叠加 SP：复用 TP group 分摊非 TP 区域的激活，并验证更多 collective 的延迟；
PP 保持最小：只在 TP/EP 后模型仍放不下时增加 stage；
MoE 尽量用 EP 分布专家：同时控制 All-to-All 范围和每个专家的 token 数；
仅为超长上下文增加 CP：用实测判断通信成本是否值得；
最后通过 DP 扩吞吐：复制已经调优好的模型实例。

这不是严格的执行顺序，而是一条经验性原则：高频、细粒度的通信留在最快的互联域；跨节点通信尽量选择频率更低、消息更大的形式。

硬件拓扑会改变最优组合

集群拓扑	更合理的选择
单个 NVL72 域	TP、SP 和 EP 可以在高速互联域内组织；TP 仍需寻找收益递减点，CP 仅在长上下文确有需求时加入
两台 8-GPU 节点，节点间 InfiniBand	TP/SP 通常限制在节点内；跨节点可使用 PP、EP、DP，长上下文 CP 宜采用拓扑感知的 Ring 或分层方案
普通 Ethernet 集群	应进一步减少高频跨节点 collective，优先使用较小 TP 和更粗粒度的切分

这体现了软硬件协同设计的基本原则：并行策略不是抽象的数学分解，而是通信频率、消息大小和物理链路共同决定的系统配置。

配置验证指标

改变并行配置后，至少需要同时观察：

端到端 TTFT、TPOT 和 goodput；
Tensor Core 利用率和 kernel 执行时间；
NVLink/NIC 吞吐与集合通信占比；
pipeline bubble 和 GPU 空闲区间；
不同专家收到的 token 数及最长尾部延迟；
单卡显存余量和 KV cache 可用容量。

Nsight Systems 适合检查端到端时间线和通信/计算重叠，Nsight Compute 适合分析具体 kernel。并行度增加后，如果计算时间下降但通信、空闲或尾延迟上升，端到端性能仍可能变差。混合并行是在容量、延迟、吞吐和通信之间进行约束优化。配置应从容量约束出发，限制高频通信的物理范围，再通过 profiling 确定端到端性能的收益递减点。需要特别注意：SP 不减少理论通信字节数，也不能替代 CP；DP 扩展整体吞吐，但不缩短单请求路径；EP 解决专家布局，却不自动保证均匀负载。对于 MoE，静态布局确定后仍需处理 All-to-All 和专家负载不均，第 4 节将分析相应的运行时机制。

4. MoE 执行路径：路由、通信与负载均衡

EP 定义逻辑专家到物理 rank 的静态布局，模型 Gating 为 token 选择逻辑专家，Runtime Router 再将 token-to-expert assignment 映射到具体 rank 或等价副本。对于包含远端 assignment 的 MoE 层，系统还需在 EP group 内完成 Dispatch 和 Combine；因此，关键路径同时受专家放置、通信拓扑和负载分布影响。本节依次分析执行路径、通信优化、负载均衡和运行时反馈控制。

4.1 模型 Gating 与 Runtime Routing

MoE 系统中经常把两件不同的事都称为路由：

层次	决定什么	是否属于模型语义
模型路由（Gating）	根据 token 的 hidden state 选择 Top-k 逻辑专家	是；改选不同专家可能改变输出
系统路由（Runtime Routing）	把 token 送到专家所在 GPU，或在同一专家的多个副本中选一个	选择等价副本或通信路径时通常不改变语义

结论： Gating 决定“应该调用哪个专家”，Runtime Router 决定“怎样到达这个专家”。性能优化首先应在不改变逻辑专家选择的范围内进行。

在每个 MoE 层中，完整路径是：

这条路径同时面对两类瓶颈：

瓶颈	表现	后果
通信开销	跨 GPU 交换大量、小粒度且目的地不规则的激活	NIC/NVLink 等待时间超过专家计算时间
负载不均	少数专家收到大量 token，其他专家工作量较少	最慢专家形成 straggler，整层等待

两者不能分开看。即使网络足够快，热点专家仍会拖慢整个 batch；即使 token 分配很均匀，不合理的专家放置也可能让大量流量穿越慢速跨节点链路。因此，MoE 运行时优化有两个目标：

减少跨慢速链路的数据量，并通过分块流水使通信与专家计算重叠，尽可能将通信时间移出关键路径；
让各专家的完成时间尽量接近，而不只是让 token 数在统计上平均。

第二点尤其重要：两个专家收到相同数量的 token，不代表耗时一定相同。不同 GPU 状态、kernel 效率、网络拥塞和专家实现都可能造成服务时间差异。

Kimi K3：在 896 个专家中动态选择 16 个

根据前述 Kimi K3 公开配置，若每个相关 MoE 层对每个 token 选择 16 个路由专家，且不计共享专家或其他固定分支，则包含

T

个 token 的一次层执行会产生：

N_{assignment}=16T

个 token-to-expert 分配。即使完全均衡，每个专家平均也只能收到：

\frac{16T}{896}=\frac{T}{56}

个 token。batch 较小时，单个专家收到的 token 较少，通信与 kernel 启动成本难以摊薄；batch 增大后，专家 GEMM 和消息粒度通常更有利，但总通信量、显存占用和热点专家的绝对排队长度也随之上升。因此，最优 batch 取决于固定开销的摊销收益能否覆盖带宽、容量和尾延迟成本。 Kimi K3 使用 Quantile Balancing 改善训练期专家分配，但训练阶段的均衡机制不能证明线上推理同样均衡。真实业务中的主题、请求长度和并发不断变化，仍需通过专家级 token 数、队列时间与 All-to-All 耗时验证运行时负载。

4.2 通信优化：拓扑感知与通信计算重叠

结论： All-to-All 优化不是单纯追求更高峰值带宽，而是同时减少跨慢链路流量、增大消息粒度，并让传输与专家计算重叠。

1. 让路由和专家放置感知拓扑 节点内 NVLink/NVSwitch 的带宽和延迟通常明显优于跨节点 InfiniBand 或 RoCE。路由系统可以先在本地高速互联域内完成交换，只有目标专家不在本地时才产生跨节点流量。这种层级化通信需要同时设计：

哪些逻辑专家及其副本放在同一 GPU、节点或机架；
Runtime Router 是否优先选择本地可用的等价副本；
All-to-All 是一次全局执行，还是拆分为节点内重排和节点间交换。

论文原图：DeepSpeed-MoE 将全局 All-to-All 拆成节点内交换、数据布局转换和并发的节点间交换，以减少通信跳数并利用不同层级链路。来源：DeepSpeed-MoE，Figure 8。

实验观察： 分层 All-to-All 不改变逻辑 assignment；其主要作用是利用节点内快链路完成局部重排，并聚合跨节点消息，减少慢链路上的小消息和中间转发。只有结合专家副本或放置优化时，跨节点 assignment 的比例才可能进一步下降。

“优先本地”不能覆盖模型的路由分数。如果为了减少通信而把 token 送到不同权重的低分专家，模型输出可能发生变化。只有路由到 同一专家的等价副本 时，局部性优化才不会改变模型语义。 2. 将通信分块并与计算重叠 将 Dispatch 拆成多个 chunk 后，专家可以在首批输入到达时启动计算，并与后续 chunk 的传输形成流水：

时间片 1：传输 Chunk A
时间片 2：计算 Chunk A，同时传输 Chunk B
时间片 3：计算 Chunk B，同时传输 Chunk C

Double Buffer 为正在计算和正在传输的数据分别准备缓冲区，使专家计算与下一批激活交换并行推进。该优化要求专家 kernel 能在部分输入到达后增量执行，且 chunk 足够大以摊薄通信和 kernel 启动开销；如果通信与计算争用同一内存带宽，或被同一个 CUDA stream 串行化，异步 API 也不会产生实际重叠。 3. 避免单一全局 Barrier 朴素实现可能让所有 GPU 在全局 All-to-All 前后同步，任何慢链路或热点 GPU 都会让整组设备等待。部分系统使用分阶段交换或 grouped send/receive，避免所有 rank 在单一全局屏障前后同时等待。这类方法可能改善链路并发度，但也会增加阶段数、转发和同步开销；是否有效取决于消息大小、GPU 与节点数量、rail 配置、专家分布，以及通信库和推理框架版本。 4. 将高相关专家放在一起 如果流量分析发现某些专家经常被同一个 token 同时选择，可以将它们放在同一节点。若通信实现支持“跨节点聚合一次、节点内再分发”，这种 Expert Collocation 能减少慢链路上的重复消息和启动开销；若每个 assignment 仍独立跨节点发送，单纯共置专家并不会自动减少网络字节数。专家共置还可能让某个节点承载更多热门专家，因此放置策略必须同时优化通信局部性和负载均衡。 5. 压缩传输数据 在 All-to-All 前把激活转换为 FP8 或 NVFP4，可以减少网络流量；接收端再恢复为后续计算所需格式。只有当节省的传输时间大于量化、打包、解包和反量化成本时，这种方法才有收益。与模型权重量化一样，通信压缩也需要验证数值误差。不能因为压缩发生在网络路径上，就默认它对模型质量没有影响。 通信侧检查清单：

TP/EP 通信组是否与 NVLink、NIC 和 NUMA 拓扑一致；
跨节点路径是否真正启用了 GPUDirect RDMA；
多端口 InfiniBand/RoCE 是否正确使用多 Rail 或 Bonding；
All-to-All 是否被单个全局 Barrier 串行化；
通信与专家计算是否在时间线上真实重叠；
是否存在少数链路长期拥塞，而其他链路空闲；
压缩带来的网络收益是否覆盖转换开销和精度损失。

4.3 负载均衡：基于完成时间的优化目标

结论： MoE 层的延迟由最慢专家决定。均衡 token 数只是手段，真正要均衡的是包含排队、通信和计算在内的完成时间。

训练均衡与线上负载的差异

训练阶段可以加入 Load-Balancing Loss 和 Gating Noise，鼓励模型更均匀地使用专家。但线上流量并不服从训练数据的稳定分布：某一时段的请求可能集中在代码、数学或某个垂直领域，使相关专家持续过热。例如，假设热点专家所在 GPU 的利用率达到 99%，而其他 GPU 平均仅为 60%。即使集群平均利用率不高，MoE 层仍需等待热点专家完成，其他设备的空闲也无法自动转化为更高吞吐。设专家

e

收到的 assignment 数为

n_e

，一个直观的负载偏斜指标是：

R_{imbalance}=\frac{\max_e n_e}{\operatorname{mean}_e n_e}

R_{imbalance}=1

表示按 assignment 数完全均衡，数值越大说明热点越严重。但 assignment 数相同也不保证完成时间相同，因为不同 rank 的排队、链路和 kernel 效率可能不同。在忽略通信与专家计算重叠时，MoE 层关键路径可以粗略表示为：

T_{MoE}\approx T_{dispatch}+\max_e\left(T_{queue,e}+T_{compute,e}\right)+T_{combine}

最慢专家的排队与计算时间位于关键路径上。因此，运行时应同时观察 assignment 数、队列时间和专家服务时间，而不是只看平均 GPU 利用率。

Capacity Factor

Capacity Factor 为每个专家设置一个 batch 内的容量上限。设：

batch 中有 $T$ 个 token；
每个 token 选择 $k$ 个专家；
总共有 $E$ 个专家；
Capacity Factor 为 $c$ 。

每个专家的容量可以近似写为：

C \approx \left\lceil c \cdot \frac{T \times k}{E} \right\rceil

Switch Transformer 中 Capacity Factor 1.0 与 1.5 的路由差异

论文原图：Capacity Factor 决定每个专家可处理的 token 容量。1.0 时不均匀路由更容易产生溢出；1.5 增加缓冲容量，但也增加空槽、计算和通信成本。来源：Switch Transformers，Figure 3。该图来自训练语境，用于说明 Capacity 的定义与权衡，不直接等价于线上推理结果。

实验观察： Capacity Factor 提供的是热点缓冲空间，而不是负载均衡能力。增大容量可以减少溢出；在固定容量和 padding 型实现中，它也会增加空槽、通信与计算浪费，而 dropless 或变长 grouped GEMM 实现的代价结构可能不同。

例如，一个 batch 有

T=5600

个 token，Kimi K3 每个 token 选择

k=16

个专家，总专家数

E=896

。完全均衡时，每个专家平均收到 100 个 token-to-expert assignment；若

c=1.2

，容量上限约为 120。 Capacity Factor 不是“负载均衡算法”，而是给热点设置缓冲边界。上限过紧会频繁溢出并可能影响模型语义；上限过松又无法有效抑制 straggler。

专家容量溢出的处理方式

超过容量的 token 仍然必须选择处理方式：

处理方式	性能影响	质量影响
转给次高分专家	避免热点继续排队	使用不同专家，可能改变输出
延后到第二轮处理	保留原专家选择	增加延迟，破坏流水线
丢弃或使用残差路径	延迟最低	可能造成更明显的质量损失
转给同权重专家副本	分摊负载	理论上不改变专家计算，但增加显存成本

4.4 Expert Replication：热点分流与语义一致性

结论： 复制同一个逻辑专家的权重，并在等价副本之间选择负载较低者，可以用额外显存换取热点容量，而不必改选其他专家。

如果某些专家在较长时间内持续过热，可以把同一组权重复制到其他 GPU，并让路由系统在多个等价副本之间分流。这种方法有三个特点：

针对性强：只复制热点专家，不必复制整个模型；
语义相对稳定：多个副本权重完全相同时，选择哪个副本不改变专家函数；
消耗额外显存：副本越多，可用于其他专家和 KV cache 的空间越少。

专家副本通常由推理引擎管理，模型的 gating network 仍然选择逻辑专家，系统层再把逻辑专家映射到某个物理副本。这样比直接把副本当作不同专家索引更容易保持模型语义。副本管理还需处理：

所有副本从同一 Checkpoint 加载并保持权重一致；
路由表更新不能让在途请求丢失目标；
新副本需要加载、注册内存和预热，无法瞬间生效；
释放副本前要确认没有尚未完成的 token。

因此，Expert Replication 更适合应对持续性热点，而不是每个 batch 都变化的短时波动。

4.5 Adaptive Routing：运行时反馈控制

结论： 观测专家队列、完成时间和链路拥塞，再选择物理副本、通信路径或较慢时间尺度的专家放置；但不能把系统负载直接凌驾于模型 Gating 之上。

传统 Gating 根据 token 的模型分数选择逻辑专家。Adaptive Routing 在保持这一语义边界的前提下，还会考虑专家队列、处理时间、GPU 利用率和通信拥塞。

通常不改变模型语义的调整：

在 同一专家的等价副本 之间选择负载较低者；
改变通信路径或 All-to-All 调度顺序；
调整专家物理放置，但保持权重和逻辑映射不变。

可能影响模型质量的调整：

因主专家繁忙而改选不同权重的次优专家；
动态修改 gating score 或 Top-k；
跳过某些专家计算；
因容量不足丢弃 token 的专家分支。

系统层路由优化不能只追求负载均衡；还必须标记可能改变模型输出的动作，并为其建立独立的质量回归测试。 监控指标： 仅看 GPU 利用率不足以定位专家热点。更有价值的指标包括：

指标	能发现的问题
每个专家收到的 token 数	Gating 分布是否偏斜
每个专家的队列长度和服务时间	是否存在实际 straggler
Dispatch/Combine 字节数与耗时	All-to-All 是否成为主瓶颈
各 GPU 的 kernel 时间线	计算不均还是通信等待
NVLink/NIC 每链路利用率	是否存在拓扑热点
溢出、改路由和副本命中次数	动态策略是否过于频繁

Nsight Systems 可以观察不同 GPU 的 All-to-All 和专家计算时间线；Prometheus/Grafana 更适合持续收集专家级指标和建立告警。所有动态放置、路由偏置和副本变更都应记录日志，以便关联性能变化与模型质量变化。自适应路由会引入额外的观测、决策和配置管理成本。控制回路过快会追逐短时噪声，过慢又无法及时处理热点。

自适应路由的控制时间尺度

时间尺度	适合的动作
每个 token / batch	在等价副本之间选路、执行 capacity 检查
秒到分钟	调整路由权重、batch 策略或流量分配
分钟到小时	创建热点专家副本、迁移专家、调整物理放置
离线	根据长期 gating 统计重新规划专家布局或训练均衡策略

吞吐能否随 GPU 数接近线性增长，取决于 All-to-All、负载均衡和模型计算是否同时扩展。只增加专家和 GPU，而不解决网络与 straggler，通常不会得到线性收益。

4.6 MoE 运行时优化汇总

问题	主要手段	核心权衡
All-to-All 过慢	拓扑感知、分层交换、分块流水、通信压缩	实现复杂度、缓冲区和精度
专家负载不均	Capacity Factor、训练期均衡损失	延迟与模型质量
持续热点	Expert Replication	额外显存与副本管理
动态流量变化	Adaptive Routing + Telemetry	控制开销、稳定性与语义一致性

MoE 运行时优化的目标不是让每个专家收到完全相同数量的 token，而是在保持模型语义边界的前提下，缩短并稳定每个 MoE 层的完成时间。只有通信局部性、专家负载和运行时控制同时有效，EP 带来的容量扩展才能转化为服务吞吐。

5. Speculative Decoding：候选生成与批量验证

自回归解码要求当前位置的输出作为下一位置的输入，因而 Target Model 调用位于串行关键路径。投机解码使用低成本方法生成多个候选，再由 Target Model 批量验证，以减少串行调用次数。

结论： 投机解码的收益取决于候选生成成本、平均接受长度与批量验证效率。本节算法与案例参考 AI Infra Learning Docs — Speculative Decoding。

5.1 Draft-and-Verify

标准 Decode 生成 100 个 token，通常需要约 100 次模型前向。投机解码将部分高成本 Target Model 调用转换为以下流程：

Draft Model 顺序提出 $k$ 个候选；
Target Model 将候选视为一段短 Prefill，一次计算所有候选位置及其后一个位置；
从前向后接受连续候选；若某个候选被拒绝，则在该位置生成修正 token 并结束本轮；
若 $k$ 个候选全部通过，则再从 Target 的下一个位置采样一个 bonus token，使本轮最多推进 $k+1$ 个 token。

Draft 阶段仍具有自回归依赖，因为后一个候选依赖前一个候选；Target Model 接收完整候选序列后可以并行验证多个位置。实际收益取决于候选生成成本以及候选分布与 Target Model 分布的一致程度。

5.2 接受率与平均推进长度

为建立简化分析模型，假设系统仅在前序候选全部通过时检查下一个候选，且每个被检查候选均以相同条件概率

\alpha

被接受。即使首个候选被拒绝，本轮也会生成一个修正 token；若

k

个候选全部通过，则额外生成一个 bonus token。因此平均推进长度近似为：

E[L]=1+\alpha+\alpha^2+\cdots+\alpha^k =\frac{1-\alpha^{k+1}}{1-\alpha}

当

k=5

时：

条件接受率 $\alpha$	平均推进长度 $E[L]$
0.5	约 1.97 token
0.8	约 3.69 token
0.9	约 4.69 token

如果第 2 个候选被拒绝，第 3 个候选即使碰巧合理也不能保留，因为它依赖的上文已经改变。

论文原图：Draft 长度增大时，Target 调用减少，但接受率下降、Draft 成本上升，最终收益会饱和。来源：Accelerating Large Language Model Decoding with Speculative sampling，Figure 1。

实验观察： 更长的 draft 同时增加潜在推进长度和失败浪费；最优 $k$ 由任务可预测性与 Draft/Verify 成本共同决定。

平均推进 3.69 个 token 不等于 3.69× 加速。 还要扣除 Draft、验证、采样和调度成本。

5.3 Target 分布的保持

标准投机采样不是简单比较 Top-1。设 Draft 对候选

\tilde{x}_i

给出的概率为

q(\tilde{x}_i)

，Target 给出的概率为

p(\tilde{x}_i)

，接受概率为：

a_i=\min\left(1,\frac{p(\tilde{x}_i)}{q(\tilde{x}_i)}\right)

Target 概率不低于 Draft 时直接接受；Draft 过度偏爱某个候选时，只按

p/q

的比例接受。候选被拒绝后，算法还需要从尚未被 Draft 覆盖的概率质量中采样修正 token。

候选拒绝后的修正分布与数值例子

拒绝后不能重新从完整 Target 分布采样，否则会重复计算接受阶段已经分配的概率质量。修正分布为：

p'(x)= \frac{\max\left(p(x)-q(x),0\right)} {\sum_y\max\left(p(y)-q(y),0\right)}

token	Draft $q(x)$	Target $p(x)$	接受环节已有质量	仍需补足
A	0.6	0.3	0.3	0
B	0.3	0.4	0.3	0.1
C	0.1	0.3	0.1	0.2

拒绝后只应在 B、C 的剩余质量中采样，归一化后分别为

1/3

和

2/3

。接受判断与修正分布共同恢复 Target 分布。

“质量无损”指标准算法理论上保持 Target Model 的输出分布。 近似接受、跳层、低精度或随机数处理差异仍可能改变结果。

5.4 候选来源与接受语义

候选生成方式与接受规则是两个需要分别分析但并非任意组合的维度：前者决定候选成本和命中率，后者决定最终输出是否严格保持 Target Model 分布。严格的接受—拒绝校正要求能够获得或构造与候选机制相匹配的 proposal 分布；只输出候选集合而没有可用概率的机制，通常需要专门校正或采用近似接受。双模型、Prompt Lookup、Self-Speculative、EAGLE 和 Medusa 的主要差异在候选来源：

方法	候选来源	核心特点
双模型投机解码	独立小模型	通用，但增加模型、显存和调度成本
Prompt Lookup	上下文中的 n-gram	成本低，依赖文本复用
Self-Speculative	Target 的跳层或轻量路径	不需要第二套完整模型
EAGLE	预测 Target 未来 hidden state	复用 Embedding 与 LM Head
Medusa	多个未来位置预测头	Draft 阶段并行生成候选树

具备兼容 proposal 分布的候选机制可以使用严格的接受—拒绝校正；其他实现通常采用专门设计或近似接受规则，后者可能改变原始采样分布。EAGLE 与 Medusa 的主要差异在候选预测对象，其分布保证仍取决于具体接受算法。

5.5 EAGLE：预测未来 hidden state

EAGLE-1 将 Target Model 的 LM Head 输入 hidden state 作为 feature：

EAGLE 使用当前 hidden state

f_t

与已经选中的下一 token Embedding

e_{t+1}

，预测未来状态

\hat f_{t+1}

，再复用 Target 的 LM Head 得到候选：

(f_t,e_{t+1}) \longrightarrow \hat f_{t+1} \longrightarrow \operatorname{LM\ Head}(\hat f_{t+1}) \longrightarrow \hat x_{t+2}

shifted token 用于消除由采样结果引起的分支歧义。例如，状态

f_I

后可能采样出 always 或 am。仅以

f_I

为输入时，下一状态的目标分布包含多条分支；加入实际采样 token 的 embedding 后，预测条件被限定到对应分支：

(f_I, Embedding(always)) → 预测 f_always
(f_I, Embedding(am))     → 预测 f_am

论文原图：Vicuna-7B、MT-Bench、temperature=0 条件下，直接预测 token、feature 和 feature+shifted-token 的对比。来源：EAGLE，Figure 4。

实验观察： 在该实验配置下，单独预测 feature 的结果优于直接预测 token；加入 shifted token 后，预测输入包含实际采样分支信息，准确率和端到端加速比进一步提高。

实验中，加速比从 token 预测的约 1.5×，提高到 feature 的约 1.9×，加入 shifted token 后约为 2.8×。这些是特定实验结果，不是固定加速承诺。

5.6 Medusa：多头预测与候选树

Medusa 从同一个 hidden state 并行预测多个未来位置：

输出模块	预测目标
原始 LM Head	$x_{t+1}$
Medusa Head 1	$x_{t+2}$
Medusa Head 2	$x_{t+3}$

Head 1 对

x_{t+2}

的预测不以最终采样的

x_{t+1}

为条件，因此单一路径的预测误差会累积。补充资料引用的一组统计显示，

x_{t+2}

的 Top-1 准确率约为 60%，Top-5 候选覆盖率超过 80%。该结果支持保留多个高概率候选并构建 Candidate Tree，但不能直接推导线上接受率。

Top-5 覆盖率不是线上接受率，也不是 Medusa 的核心理论。 Medusa 的完整方法是 Multiple Decoding Heads、Candidate Tree 与 Tree Attention；Tree Attention 让共享前缀的多条路径在一次 Target 前向中完成验证。

Medusa 的 Typical Acceptance 会接受 Target 认为“足够典型”的候选，但不再严格保持原始采样分布，需要单独评估生成质量。

5.7 适用条件与选型指标

方案	更适合的条件	主要代价或限制
双模型 Draft	已有与 Target 分布接近的小模型	额外权重、显存与跨模型调度
Prompt Lookup	prompt 中存在大量可复用片段	对开放式生成收益有限
Self-Speculative	希望复用 Target 且可接受近似计算路径	跳层策略与质量验证复杂
EAGLE	可训练 feature-level Draft，并希望复用 LM Head	需要额外训练和 feature 预测模块
Medusa	可修改 Target 并训练多个预测头	候选树、Tree Attention 与接受规则增加实现复杂度

投机解码通常更适合 Target Model 较大、输出较长、batch 较小或中等且任务可预测性较高的场景。选型时应同时测量平均推进长度、Draft 与 Verify 耗时、端到端延迟、吞吐、显存占用和输出质量；候选数量本身不能直接推导加速比。

6. 实施闭环与核心结论

前述技术分别作用于资源组织、模型布局、运行时路径和解码算法。生产部署不应一次性叠加全部机制，而应围绕当前关键瓶颈选择最小改动，并验证收益是否覆盖新增复杂度。

6.1 复杂度预算

优化	直接收益	新增复杂度
PD 分离	隔离阶段干扰，独立优化 TTFT 与 TPOT	KV Handoff、跨池调度、两侧容量平衡
混合并行	满足容量约束并匹配硬件拓扑	多组通信域、拓扑映射和调试难度
MoE 运行时优化	缩短 All-to-All 与专家尾部延迟	专家级监控、控制回路、副本管理与质量验证
投机解码	减少 Target Model 的串行调用	Draft Model/Head、接受逻辑和额外显存

复杂度本身不是拒绝优化的理由，但每一项机制都应有明确的收益假设、观测指标和回退路径。若收益只能在局部 kernel 指标中体现，而 goodput、成本或质量没有改善，则该优化不构成有效的系统升级。

6.2 验证闭环

建议按以下流程实施优化：

固定比较合同：明确模型与精度、负载分布、硬件拓扑、SLO 阈值、达标率和质量要求；
定位关键路径：使用端到端 tracing 与 profiling 区分排队、计算、通信、KV cache 和专家热点；
选择最小改动：只引入直接缓解当前瓶颈的机制，避免同时改变多个变量；
联合测量结果：同时观察 goodput、P95/P99 延迟、GPU 数量、显存、网络、成本和输出质量；
验证稳定性：覆盖不同 prompt/output 长度、并发、突发流量和故障场景；
保留回退路径：当收益不能稳定覆盖复杂度时，能够恢复上一版配置。

本章的核心结论是：多节点推理性能取决于计算、通信、缓存和调度在同一服务目标下的协同，而不是任一设备或算子的峰值性能。模型布局决定数据必须在哪里计算，运行时机制决定数据如何到达计算位置，解码算法决定串行关键路径需要执行多少次；三者最终都应回到 SLO 约束下的 goodput 和成本效率。

常见技术问题

以下问题集中说明正文中最容易混淆的概念、适用条件和指标边界。

MoE 每个 token 只激活少数专家，为什么部署时仍需要大量 GPU 和显存？

MoE 的稀疏性作用于单 token 的计算路径，而不是模型总权重。每个 token 只执行 Top-k 专家，但全部专家权重仍需分布在集群中；在常规低延迟部署中，这些权重通常需要在设备侧保持可用。高并发下，不同 token 会选择不同专家，多数 GPU 也可能同时活跃。因此，MoE 降低的是单 token 计算量相对于总参数量的增长速度，并不会把超大模型转化为小模型部署。参见容量可行性与切分维度。

Expert Parallelism、模型 Gating 和 Runtime Router 分别负责什么，哪些调整可能改变模型输出？

EP 定义逻辑专家到物理 rank 的静态布局；模型 Gating 根据 hidden state 选择逻辑专家；Runtime Router 再把 token-to-expert assignment 映射到专家所在 rank 或同一专家的等价副本。在等价副本之间选路、调整通信路径或移动同权重专家通常不改变模型语义；改选不同权重的专家、修改 Top-k、跳过专家或丢弃分支则可能改变输出，必须单独进行质量验证。参见EP 的职责边界。

TP 和 PP 都能降低单卡权重占用，为什么 TP 通常限制在高速互联域，而 PP 更适合跨节点？

TP 切分同一层的矩阵计算，Attention 和 MLP 几乎每层都需要集合通信，因此对带宽和同步延迟高度敏感。PP 沿模型深度切分层，只在 stage 边界传递激活，通信频率更低、消息通常更粗粒度，更容易映射到跨节点链路。TP 还可能降低单层计算延迟；PP 主要解决模型整体容量，通常不会缩短单请求 Decode 路径。参见并行策略。

Megatron Sequence Parallelism 为什么能节省显存，但实际训练通信量可能高于经典 TP？

SP 复用 TP group，把 LayerNorm、Dropout 和残差等非 TP 区域的 activation 沿 sequence 维切分，使每个 rank 长期保存约

1/p

的激活。进入 TP 区域时需要 All-Gather，离开时通过 Reduce-Scatter 切回分片。为保留完整显存收益，反向计算列并行权重梯度前还需重新 All-Gather 输入 activation；因此实际网络字节数可能高于只统计边界 collective 的理论值。实现通常将这些通信与梯度 GEMM 重叠，所以通信量增加不等于关键路径按相同比例变长。参见并行策略。

SP 和 CP 都沿 sequence 维切分数据，核心区别是什么，能否在同一个模型实例中同时启用？

SP 主要改变训练 activation 的存储布局：进入 TP 计算区域时会临时恢复当前 CP 分片的完整输入。CP 改变 Attention 的执行布局：Ring 类方法保持上下文分片并交换 K/V，Ulysses 类方法则恢复完整 sequence、同时只保留部分 attention heads。两者可以同时启用；SP 通常复用 TP group，不增加独立 world-size 维度，而 CP 构成独立的 rank 维度。组合后，SP 的 All-Gather 只恢复 CP-local sequence，全局 Attention 依赖仍由 CP 通信完成。参见并行策略。

什么时候应采用 Prefill/Decode 分离，什么时候保留共享资源池并使用 Chunked Prefill？

当共置部署已出现明显阶段干扰、TTFT 与 TPOT 都有严格 SLO、集群规模足以独立调节两个资源池，且 KV cache 能通过高带宽路径传输时，PD 分离更有价值。它提供更彻底的隔离，但会增加 KV Handoff、权重副本、双池容量平衡和调度复杂度。集群较小、负载较低或网络条件不足时，Chunked Prefill 可以在共享资源池内限制长 Prefill 的阻塞，并保持更高的资源复用率。最终应比较 goodput、尾延迟、Handoff 延迟和两侧队列，而不是只比较 tokens/s。参见PD 分离。

投机解码所说的“质量无损”具体保证什么，哪些实现不在这个保证范围内？

标准投机采样通过接受概率和拒绝后的修正分布，在理论上保持 Target Model 的输出分布；它并不要求 Draft Model 的每个候选都正确。“质量无损”不自动覆盖 Typical Acceptance、近似接受、跳层 Self-Speculative、低精度误差或不同的随机数处理。候选机制还必须提供或构造与校正算法兼容的 proposal 分布，否则需要专门校正或单独评估质量。参见Target 分布的保持。

EAGLE 与 Medusa 都用于投机解码，它们预测的对象、候选结构和训练要求有什么不同？

EAGLE 预测 Target Model 未来的 LM Head 输入 hidden state，再复用 Target 的 LM Head 生成 token 候选；shifted token 用于标识采样后实际进入的分支。Medusa 则在同一个 hidden state 上增加多个预测头，直接预测不同未来位置的 token，并通过 Candidate Tree 与 Tree Attention 批量验证多条路径。EAGLE 需要训练 feature-level Draft 模块，Medusa 需要修改并训练多个预测头；两者的分布保证仍取决于具体接受算法。参见 EAGLE 与 Medusa。

Medusa 的 Top-5 覆盖率超过 80% 是否意味着线上接受率超过 80%，或一定能获得固定加速比？

不能。Top-5 覆盖率是离线候选集合是否包含目标 token 的统计指标，不等同于候选沿同一路径连续通过的线上接受率。端到端加速还取决于候选树大小、Target 验证成本、平均连续接受长度、batch、显存和调度开销。该指标只说明保留多个候选有助于构建 Candidate Tree，不能直接推导线上加速比。参见 Medusa。

Capacity Factor 是否越大越安全，它与真正的专家负载均衡有什么区别？

Capacity Factor 为每个专家设置 batch 内的容量边界。增大取值可以减少溢出，但在固定容量、padding 型实现中会增加空槽、通信和计算浪费；减小取值则更容易触发改路由、延后或丢弃。dropless 或变长 grouped GEMM 的代价结构可能不同。Capacity Factor 只能提供热点缓冲空间，不能消除 Gating 偏斜、网络拥塞或专家服务时间差异，因此不构成完整的负载均衡算法。参见 Capacity Factor。

​录屏回看

​本章概要

​1. 问题定义、系统边界与决策框架

​1.1 统一优化问题：可部署、可达标与可扩展

​1.2 系统输入与请求生命周期

​1.3 决策层次及其依赖关系

​1.4 统一评价指标与比较口径

​1.5 本章路线

​2. Prefill/Decode 资源组织

​2.1 阶段特征与共置干扰

​2.2 独立 Prefill Pool 与 Decode Pool

​2.3 KV cache Handoff 的新增成本

​2.4 Chunked Prefill：保留共享资源池

​2.5 方案选择与采用条件

​3. 超大 MoE 模型的静态布局与混合并行

​3.1 容量可行性与切分维度

​3.2 Tensor Parallelism（TP）：层内并行与集合通信约束

​经典案例：Megatron-LM 的 Attention 与 MLP 张量并行

​Sequence Parallelism：切分非 TP 区域的激活

​TP 同时解决容量和延迟问题

​TP 的有效范围由互联拓扑决定

​3.3 Pipeline Parallelism（PP）：模型容量与流水线延迟

​Prefill 与 Decode 中的 PP 差异

​3.4 Expert Parallelism（EP）：专家布局与激活通信

​单 token 稀疏性与集群级设备利用率

​EP 与动态路由的职责边界

​3.5 Context Parallelism（CP）：序列切分与跨设备通信

​经典 CP 方法与实现流程

​方法差异与选型

​CP 与 SP 的职责边界及组合

​3.6 Data Parallelism（DP）：实例复制与请求吞吐扩展

​DP 对请求吞吐与单请求延迟的影响

​3.7 Hybrid Parallelism：配置顺序、拓扑映射与验证

​混合并行的配置顺序

​硬件拓扑会改变最优组合

​配置验证指标

​4. MoE 执行路径：路由、通信与负载均衡

​4.1 模型 Gating 与 Runtime Routing

​Kimi K3：在 896 个专家中动态选择 16 个

​4.2 通信优化：拓扑感知与通信计算重叠

​4.3 负载均衡：基于完成时间的优化目标

​训练均衡与线上负载的差异

​Capacity Factor

​4.4 Expert Replication：热点分流与语义一致性

​4.5 Adaptive Routing：运行时反馈控制

​4.6 MoE 运行时优化汇总

​5. Speculative Decoding：候选生成与批量验证

​5.1 Draft-and-Verify

​5.2 接受率与平均推进长度

​5.3 Target 分布的保持

​5.4 候选来源与接受语义

​5.5 EAGLE：预测未来 hidden state

​5.6 Medusa：多头预测与候选树

​5.7 适用条件与选型指标

​6. 实施闭环与核心结论

​6.1 复杂度预算

​6.2 验证闭环

​常见技术问题