并行策略塑造通信关键路径

并行策略首先改变数据的归属，然后改变通信发生的时刻。TP 把一层内部的计算和张量切开，PP 把模型分成有先后依赖的阶段，DP 复制完整执行链并同步对应参数的梯度，EP 则让 token 按路由寻找专家。Fabric 设计必须同时看到通信对象、参与者和依赖位置，才能判断带宽与时延分别会在哪一步限制训练或推理。S044 pp. 12–15, 35–37

将一轮训练展开为有坐标的数据流#

以本文构造的 128 xPU 作业为例：每台服务器八颗 xPU 构成 TP=8，一条模型流水线有 PP=4 个阶段，四条同构流水线形成 DP=4，合计 $8\times4\times4=128$ 颗 xPU。每个副本拥有四个阶段，阶段内八颗卡持有该阶段参数的不同分片。输入数据先分给四个副本，再切为 micro-batch 沿阶段推进。这个例子对应 AFPM 所描述的 TP group、PP stage、pipeline replica、DP group 层级。S044 pp. 35–37

一个 micro-batch 到达第一阶段时，八颗卡需要通过 collective 组合层内的部分输入、结果或梯度；阶段完成后，输出 activation 通过点对点链路送到下一阶段。第二阶段处理当前 micro-batch 时，第一阶段可以开始下一份。反向传播沿相反方向传递与输入 activation 对应的梯度，阶段内部继续执行必要的 TP collective。每个操作都对应明确的生产者和消费者，链路等待会沿依赖传播。S044 pp. 35–36

梯度同步按“相同参数分片”建立 DP 通信组。在这个例子里，四个副本中第一阶段、第三个 TP rank 持有相同的参数片，它们应互相归约；其他阶段和 rank 有各自的对应组。因此，同一个 DP 作业包含多组同时活动的通信。将这些组映射到相同 rail、不同 leaf 或跨 OPG 的位置，决定共享 spine 承担多少流量。OPG 的逐 NIC 映射由此与并行坐标发生直接联系。S044 p. 37 S048 pp. 30–35

TP 的代价沿层数反复累积#

TP 将权重矩阵和中间 activation 分给多卡，每卡完成部分计算后，需要通过 All-Reduce、All-Gather 或 Reduce-Scatter 等操作形成后续层可用的结果。它的主要约束来自层内依赖：一次通信尚未完成，消费这些结果的操作就要等待；模型跨很多层执行时，这种开销重复出现。因此，AFPM 将 TP 放在高带宽、低时延的 scale-up 域，并强调通信算法、kernel 融合和启动开销同样影响关键路径。S044 pp. 13–15, 43–44

可以用一个简化模型分辨优化方向。对 $p$ 个 rank、每个 rank 大小为 $S$ 字节的梯度或结果缓冲，采用 ring All-Reduce，忽略重叠和协议细节时，单 rank 时间近似为：

这里 $\alpha$ 表示每轮通信的有效启动和时延开销，$B$ 是可达到的单向有效带宽。此式为本文的通信量重建：reduce-scatter 和 all-gather 各经过 $p-1$ 轮，每轮处理约 $S/p$ 字节。小张量受第一项影响更明显，大张量更多暴露第二项；将 TP 跨到较慢网络会同时改变二者。实际 collective 可能采用树形或分层算法，因此规划要用相应 trace 校准这个估计。S044 pp. 36, 43–44, 53–54

这也解释了相同端口速率下仍可能出现很大性能差异。GPU 到 NIC 的 PCIe 路径、内存注册、主机中断亲和、NIC 固件和集合通信库都会改变有效带宽与启动成本。训练 RA 把 fabric QoS 与 host/NIC tuning 并列，要求用具体工作负载观察吞吐和尾时延，再调整参数。S048 pp. 30, 45–46

PP 同时受阶段边界和最慢阶段限制#

PP 的通信发生在 micro-batch 跨阶段时，前向发送 activation，反向发送对应梯度。增加 micro-batch 可以让多个阶段并发工作，但启动和排空仍会产生 pipeline bubble；某一阶段计算或通信更慢，又会限制整条流水线的推进速度。系统需要同时平衡各阶段的计算量、显存占用和边界张量，模型层数相近的切法未必具有相近的执行时间。S044 pp. 12–13, 35–36

作为本文的理想化算例，假设四阶段等时、只观察一次前向流水、每个 micro-batch 耗时相同，处理 $m$ 份微批共需 $m+3$ 个阶段时隙，设备平均利用率为 $m/(m+3)$。$m=4$ 时约57%，$m=16$ 时约84%。该算例揭示填充摊销的方向；完整训练的前反向调度、activation 保留与重计算会带来额外约束，应该在运行时 trace 中保留。S044 pp. 13, 35–37, 53

PP 阶段跨服务器时，要追踪边界数据经过的真实路径。若两个节点的全部后端 NIC 同归一个 leaf，阶段间通信可留在首跳域；rail 布线则需要看发送与接收 rank 的 rail 归属，跨 rail 可能经过 spine。通信方式、rank 编号和接线策略共同决定局部性，详细比较见拓扑放置与性能建模。S048 pp. 22–25, 35

DP 与 EP 对共享层提出不同要求#

DP 在有效 batch 完成后同步梯度，通信频率通常低于逐层 TP，数据量却可能很大。梯度累积及后台重叠可以推迟或隐藏一部分传输，参数更新仍依赖相应归约完成。AFPM 的流量分类把 DP 与高吞吐流放在一起；工程上应同时记录其可重叠窗口和最终同步点，才能估算暴露出来的等待。S044 pp. 37, 43–44

EP 将专家分布到不同设备，router 为每个 token 选择目的专家，通信矩阵随输入而变化。规划时除总字节数外，还要观察专家热度、目的地集中度和返回路径。若专家分布跨多个 rail leaf，同一个 token 分发阶段可能把大量流量推到 spine；同 rail 梯度同步形成的局部性收益，仍需要与专家路由的跨 rail 需求一起计算。这个推论把 AFPM 的输入相关通信与训练 RA 的 rail-domain 选择连接起来。S044 p. 14 S048 pp. 24–25, 36–37

混合并行因此需要多个指标：TP 观察层内暴露时延，PP 观察阶段平衡和边界传输，DP 观察同步尾部及可重叠比例，EP 观察动态通信矩阵与负载偏斜。网络验收可以据此构造对应的 NCCL/RCCL 类负载，并对齐域内与跨域放置后的 spine 利用率、p95/p99 和作业完成时间。训练 RA 将这些放置前后对照纳入验证计划，具体测量目标由部署者确定。S048 pp. 52–55

让rank坐标贯穿接线、调度和测量#

前述128卡算例可以将每个进程记作三元坐标 $(d,p,t)$：$d$标识四个数据副本，$p$标识四个流水阶段，$t$标识八个张量分片。固定$d,p$得到一个八卡TP组；固定$d,t$沿$p$形成相邻阶段的数据路径；固定$p,t$跨$d$建立四成员DP归约组。坐标对应的是参数和执行归属，能够直接转换为应当观测的通信伙伴集合。S044 pp. 35–37

在八GPU机箱和GPU/NIC一一亲和的本文放置示例中，每个TP组占一台服务器，十六台服务器承接全部作业。若将相同$t$映射到相同NIC索引，跨副本的对应分片归约便具有同rail结构；PP阶段之间的activation传递还需根据张量分布确定发送rank和接收rank。改变rank映射时，流量进入的NIC和leaf也可能变化，因而应把逻辑rank、GPU槽位、NIC槽位和交换端口一起留在运行记录中。S048 pp. 30–34

通信量估计还应保留张量布局。一次边界activation大小取决于微批token数、hidden维度、精度及是否按TP切分，发送完整张量与各rank发送自己的分片具有不同通信伙伴。AFPM要求workload trace记录张量大小、collective类型和依赖，正是为了让这些变化能够进入模型。将每个阶段粗略记成相同字节量，会漏掉边界布局转换、聚合和重复传输。S044 pp. 36, 53–54

可以按同一坐标建立测量对照：先测固定$(d,p)$的TP组，再测相邻$p$的边界通信，最后测固定$(p,t)$跨$d$的归约。三组测试使用与真实作业一致的张量大小、并发和NIC绑定，再观察完整step中哪些通信被计算覆盖。这样，单独通信测试、网络计数器和训练trace能相互解释，而作业变慢也能追到某个并行维度。S048 pp. 46, 52–55 S044 pp. 53–55

故障后的重映射也需要更新这些关系。减少某台服务器后，剩余显存是否容纳原分片、TP组是否被迫跨机箱、PP阶段是否失衡，都会改变恢复后的通信模式。AFPM提出故障隔离、拓扑调整后重新加载checkpoint并优化计算通信；实际恢复计划应将新的rank坐标与硬件映射作为一个版本保存，再用同样方法建立退化运行基线。S044 pp. 43, 55

在性能模型中，参数量、activation量和优化器状态也应分别保留。参数分片决定每个rank拥有的持久模型部分，activation随micro-batch流动，优化器状态进入训练checkpoint；三者使用同一批显存和I/O资源，却对应不同的交换与恢复时刻。先按对象建立字节账，再按依赖把它们放到迭代时间轴上，能够看清提高并行度究竟减少了单卡占用，还是增加了无法覆盖的通信。S044 pp. 35–44

推理把状态迁移加入并行坐标#

推理同样可能采用 TP、PP 和 EP，但请求批处理和 KV 生命周期又加入了新的依赖。Prefill 计算输入各层的 K/V，decode 每次生成一个 token 并消费既有 KV。两阶段分置到不同资源池后，需要把对应状态传到 decode 位置；共享 KV 或跨主机流水线，也会让单台服务器之外的网络进入请求关键路径。S045 pp. 8–13 S047 pp. 21, 40–41

一个模型即使能装入单台服务器，运行形态仍可能需要 Distributed Inference：prefill 远置、共享状态或跨节点批处理都会产生跨 host 依赖。反过来，单服务器执行且关键状态本地的服务，可以采用省去后端的 Minimal Inference。选择前先明确一次请求经过哪些计算池、何时搬 KV、恢复时从哪里取状态，再决定需要哪种网络配置。S047 pp. 21–24, 40–41

从训练的四维并行到推理的阶段与状态放置，规划对象始终是有依赖的数据流。将计算、内存访问和 collective 表成 DAG，再映射到带宽、时延和容量已知的硬件图，能够把“增加多少卡”的讨论推进到“哪条路径缩短了完成时间”。对应的结构见系统架构的三层闭合，状态容量与迁移见存储层级与数据服务。S044 pp. 52–55