Pipeline Parallel 推理
推理流水线并行把模型层分布到多个 stage，降低单卡权重占用。与训练流水线不同，推理没有反向传播，但逐 token 生成时 stage 间的串行依赖会引入额外延迟。
推理流水线并行源自训练的 layer 切分思想，但在推理引擎（如 vLLM）中服务于「模型单卡放不下」的场景：把层分布到多卡，让请求依次经过各 stage。与训练的区别在于，训练流水线的气泡主要来自「前向完成后才能反向」的启动与收尾，推理没有反向，因此不存在这一部分气泡；推理的瓶颈转为「逐 token 生成时请求必须串行跨越所有 stage」带来的固定延迟，以及不同请求在各 stage 间调度不均造成的空闲。
快速开始¶
均衡 stage，测量跨 stage 延迟和并发下的气泡。建议步骤：
- 按计算量把层均衡分到各 stage，避免某 stage 成为瓶颈。
- 测量单个请求跨越所有 stage 的端到端延迟，以及 stage 间传输激活的耗时。
- 在不同并发下压测，观察各 stage 的利用率与空闲气泡。
- 记录首 token 时延 (Time To First Token, TTFT) 和逐 token 时延 (Time Per Output Token, TPOT) 两个指标，分别评估输入处理和生成速度。
验证成功：模型能跨设备加载，各 stage 负载均衡，目标并发下延迟满足要求。
案例¶
一个长模型单卡放不下，分为两个 stage 后可以加载，但低并发下端到端延迟增加：单个请求必须串行经过两个 stage，且 stage 间有通信和调度开销。此时可通过请求批处理改善利用率，即多个请求同时进入流水线，让各 stage 同时处理不同请求，摊薄固定开销。
但批处理会增大 batch，可能抬高单个请求的 TPOT；应在吞吐和延迟之间按服务目标取舍。若某 stage 始终是瓶颈，应重新均衡层分配，而不是一味加大 batch。