Interleaved交错流水线并行

可视化演示

动态演示Interleaved交叉流的核心机制，通过全局/局部/动态/静态四种模式展示关键概念与交互流程。

一、流水线瓶颈：气泡从哪来

蛋糕塔工厂里，一单 8 层塔由 4 位师傅接力：张师傅做 1-2 层，李师傅做 3-4 层，王师傅做 5-6 层，赵师傅做 7-8 层。订单一份接一份送来，但工位只有一条流水线——赵师傅做完第 2 单的 7-8 层后，想直接做第 3 单，却发现王师傅还没把第 3 单的 5-6 层送上来。整条线环环相扣，任何一环卡住，后面的人全得干等。这些大家集体“等米下锅”的时间段，在分布式训练里有个形象的叫法——气泡（bubble）。

在大模型训练里，“蛋糕层”就是 transformer 层，师傅就是 GPU 设备，订单就是微型批次（microbatch，一种把大训练批次拆小后逐个送入流水线的数据切片）。把模型按层切成几段，每台设备负责连续一段，数据按顺序流过所有设备——这就是最基本的流水线并行。气泡的本质是：一个批次进入和排出流水线时，前后设备无法同时开工，存在“启动慢、排空慢”的阶段。

设设备数为 P，微型批次数为 M，传统流水线（如 GPipe、1F1B，其中 1F1B 是一种让前向和反向交错执行的经典调度方式）的气泡占比近似为：

通俗理解：M 越大、订单排得越满，气泡占比越低；P 越大、流水线越长，气泡占比越高。想喂饱一条长流水线，必须准备足够多的订单（微型批次）。

张师傅们不是不勤快，而是流水线的结构决定了他们必然要等。要减少气泡，要么多接订单（增大 M），要么……换一种排班方式，比如把每层的活拆细，交错着干。

二、虚拟阶段划分：把蛋糕切得更碎

店长想了个新主意：既然大家干等是因为“活儿太大块”，那就把活儿拆小。张师傅负责的 1-2 层拆成“1 层”和“2 层”两个小包，李师傅的 3-4 层拆成“3 层”和“4 层”……整个蛋糕塔从 4 大包变成 8 小包。每小包就是一个“虚拟阶段”——它还是一段真实的楼层，只是变细了。

这就是 Interleaved 的第一个核心动作：虚拟阶段划分。假设原来把模型切成 P 段（对应 P 台设备），现在再把每一段切成 k 小段（chunk，即“大块里的子块”），于是总共有 k×P 个虚拟阶段，每台设备将负责 k 个虚拟阶段。

例如 4 台设备、每段切 2 小段：虚拟阶段总数 = 8。关键点：切碎后，设备的“工作包”不再是一整段连续层，而是多个分散的小段——这就为后面“交错分配”创造了条件。

把大包拆成小包还只是第一步。真正神奇的是下一步——怎么把 8 个小包分给 4 位师傅，才能让他们都忙起来？答案是：不再按楼层顺序分，而是交错着分。

三、交叉调度：像发牌一样交错分配

店长把 8 个小包排成一列，不按“一二三四”顺序发，而是像打扑克牌一样交叉着发：张师傅领第 1 小包和第 8 小包，李师傅领第 2 小包和第 7 小包，王师傅领第 3 小包和第 6 小包，赵师傅领第 4 小包和第 5 小包。每位师傅都既有“开场活”，又有“收尾活”。订单流动时，谁都不会干坐着。

这就是 Interleaved 的命名由来——interleave，交叉交错。设备 i 认领的虚拟阶段按头尾配对：第 i 个和第 kP−1−i 个，再下一轮是第 i+P 个和第 kP−1−i−P 个……这种对称交错让每个设备的工作负载在时间轴上呈互补分布，谁都不再是“只等开场”或“只等收尾”的可怜人。

交错调度使设备之间的依赖更均匀地铺开，直接反映在气泡公式上：

对比传统公式 (P−1)/(M+P−1)，分母多出 (k−1)P 项，气泡比例显著下降。当 k 越大，分母越大，气泡越趋近于零——但永远不会是零。

发牌式排班让每个人都“心中有数，手头有活”。但天底下没有免费的午餐：包拆小了，送包的小工（通信模块）就得跑更多趟。下一节说说这个代价。

四、通信开销权衡：省了时间费了带宽

蛋糕小包是拆细了，但问题来了：原来张师傅把 1-2 层一起端给李师傅，一趟完事；现在得把“1 层”和“2 层”分两趟端。传菜的小工（通信）来回跑的次数明显变多。小工腿跑断了，师傅倒是没干等。

通信开销的变化是 Interleaved 最核心的权衡。每完成一个虚拟阶段，就需要把结果（激活值或梯度）传给下一个虚拟阶段所在的设备。虚拟阶段总数从 P 变成 kP，机器间的通信边界从 P−1 变成 kP−1，通信总次数从 M(P−1) 变为 M(kP−1)。

每次通信的数据量不变，但趟数约为原来的 k 倍。幸运的是，通信可以异步进行（与计算重叠），只要带宽够用，增加的部分就可以被隐藏起来。这也是 Interleaved 在 InfiniBand 等高速网络上效果更好的原因。

所以 Interleaved 不是“无脑更优”，而是“用师傅的忙碌换小工的奔波”。带宽像高速公路，路宽便宜，多跑几趟不心疼；路窄收费高，就得盘算值不值。

五、实现复杂度：排班表更难写了

店长的排班表从一页纸变成了一本册子。原来每位师傅“永远只干固定的活”，现在张师傅时而做 1 层、时而做 8 层，还得记住第 5 单送到哪一步了。稍不留神，蛋糕就送错了柜子。老板还得多雇一个“调度员”，专门盯着进度。

工程实现上，Interleaved 的复杂度来自三方面：一是调度器要为每个设备维护多个虚拟阶段的执行顺序（前向和反向交错），二是每个虚拟阶段都要保留独立的中间状态，显存管理更精细，三是负载均衡更难——如果拆得不均匀，某些虚拟阶段比其他重，气泡又会悄悄回来。

常见的实现框架如 DeepSpeed 的 Interleaved Schedule、PipeDream 的变体（如 V-Shaped schedule）都内置了这类调度逻辑。但引入它们意味着要处理更复杂的流水线冲刷（pipeline flush，即训练结束时把流水线内残留的批次全部处理完的过程）、梯度累积顺序和通信流控制，调试成本显著高于传统 1F1B。对于训练框架开发者和参与并行策略调优的人来说，这部分是重点考量的“隐性成本”。

排班表复杂，不等于不该用。只要收益大于麻烦，店长就愿意花精力升级。关键是要算清楚账——这正是最后一节的主题。

六、选型实践建议：什么时候用 Interleaved

店长终于学会了算账：如果订单足够多（M 大）、传菜通道足够宽（带宽足）、客户还要求极致效率（性能敏感），那这套复杂排班法非常划算；如果店里只有两三个订单、传菜通道还是条窄胡同，那就老老实实按顺序接单。

工程选型时，Interleaved 的收益不是固定的，而是随条件变化。最直接的评估是看气泡节省比例：

它告诉我们：M 越大，节省越有限（因为传统方案本来气泡就少）；k 越大，节省越多（但通信成本也越高）。要找到甜点位，通常需要用小规模实验扫描 k 的取值。

一句话总结：订单多、路宽、追求极致，就上 Interleaved；否则传统流水线的简单可靠也是一种智慧。学会了算这笔账，你就能像那位店长一样，让每一位师傅都物尽其用。

AI 应用场景

Python 演示

def bubble_ratio(M, P, k=1):    """Return bubble ratio (0~1). k=1 means traditional pipeline."""    return (P - 1) / (M + k * P - 1)  def main():    M = 32     # number of microbatches    P = 4      # number of pipeline devices    print("M =", M, " P =", P)    print("k(chunks)  bubble_ratio  saved_vs_trad")    base = None    for k in (1, 2, 4, 8):        ratio = bubble_ratio(M, P, k)        if base is None:            base = ratio        saved = (1 - ratio / base) * 100        print("%6d      %8.2f%%       %6.2f%%" % (k, ratio * 100, saved))  if __name__ == "__main__":    main()

1. def bubble_ratio(M, P, k=1):定义气泡比例函数，k=1 时自动退化为传统流水线。
2. return (P - 1) / (M + k * P - 1)核心公式，分子始终是 P−1，分母随 k 增大而变大。
3. base = None先记录传统方案（k=1）的气泡值作为基准。
4. saved = (1 - ratio / base) * 100计算相对传统方案节省的气泡比例。
5. if __name__ == "__main__":可执行入口，让脚本既能被导入也能直接运行。

常见误区

面试题