分布式推理的并行策略：张量、流水线与专家并行

什么时候单卡真的不够了

推理部署扩容的动机通常是三条，对应三种不同的「不够」。一是权重放不下：参数量上去了，单卡显存装不下整个模型。二是 KV Cache 放不下：推理时要为每个请求缓存注意力机制所需的键值对（KV Cache），长上下文、高并发之下这部分显存增长极快——模型装得下，上下文却装不下。三是吞吐不够：单卡能跑，但请求排队太长，需要多卡分摊。三条痛点对应不同的并行策略，方向扩错了就是白花钱。

张量并行：把一层切开算

张量并行（TP，Tensor Parallelism）把单个层内部的权重矩阵切开，多张卡各持有矩阵的一块，各自算一部分中间结果，再通信拼出完整结果。典型切法是把注意力与多层感知机的矩阵按行或按列分到各卡，一层之内要做一到两次 all-reduce（把各卡的部分结果求和后再同步给所有卡）。

因为每个推理步骤内部都有通信，TP 的性能几乎完全取决于卡间互联带宽。这也是它通常局限在单机内的原因：单机内的 NVLink 级高带宽互联撑得住每步通信，跨机器的网络则会把每一步都拖慢。TP 主要解决「权重放不下」这条痛点。顺带一提，TP 度数还受注意力头数约束——矩阵要切得均匀，头数不够时切分方案就得重新设计。

流水线并行：把层与层接力

流水线并行（PP，Pipeline Parallelism）按模型纵深切：前几层放一张卡、中间几层放一张、后面几层再放一张，数据像流水线一样接力。卡与卡之间只在交界处传一次激活值，通信量小得多，对网络不敏感，因此适合跨机器部署。

代价是流水线气泡：任一时刻只有持有「当前阶段」的卡在满负荷，其余在等待。实际系统会把一个批次切成多个微批（micro-batch）在流水线里错峰流动，让多数卡尽量有事做，但气泡只能压小、无法消除。另一个显性收益是显存：每张卡只持有自己那一段层的权重，占用随切分段数下降，这也是它撑得起超大模型的原因之一。PP 与 TP 组合是超大模型的常见形态：机内 TP 吃互联红利，机间 PP 躲开网络瓶颈。

专家并行：MoE 的专属切法

专家并行（EP，Expert Parallelism）服务于 MoE（Mixture of Experts，混合专家）架构——这类模型的每一层里有多个「专家」子网络，每个 token 只被路由到其中一两个专家处理。EP 把不同专家放到不同卡上：token 算完公共部分后，按路由结果「寻址」到专家所在的卡继续计算，卡间传输的是 token 本身而非权重。

EP 的收益是专家总容量可以远超单卡显存；代价是路由带来的通信模式不规则，负载均衡（各卡分到的 token 数要尽量均匀）成了新的工程问题。

序列维度的切法

如果上下文长到连 KV Cache 都要切，还有序列并行/上下文并行一路：把超长序列切成若干段，分到多卡分别计算注意力，卡间交换必要的边界信息。直觉上可以这么理解：注意力的本意是让每个位置「看」全序列，序列切开后，这个「看」就得靠卡与卡之间的配合来完成。它解决「上下文放不下」这条痛点，与前述并行策略正交、可以叠加使用。

选型直觉

工程现实：先测量，再扩容

并行度不是免费午餐：卡越多，运维越复杂——拓扑要规划，故障域变大，扩缩容与升级都更麻烦。实际收益取决于两个物理量：显存带宽决定单卡算力能不能喂饱，互联质量决定通信开销吃掉多少收益。动手扩容之前，先用压测弄清楚瓶颈到底在算力、显存还是通信——很多「加卡不提速」的案例，瓶颈根本不在并行度上。

小结

分布式的本质，是把「模型太大」翻译成「通信问题」：TP 用高频通信换层内拆分，PP 用流水线气泡换低频跨机，EP 用路由换专家容量，序列并行换上下文长度。每条策略对应一条明确的痛点，选型的第一步不是看别人用什么，而是确认自己的瓶颈属于哪一条。