跳到主要内容

Interconnect 资源域

通信延迟与拓扑作为 perf model 输入——各档精度下怎么消费、五种并行的通信特征、暴露通信如何涌现

核心要点:

  • 互联机制本身(拓扑 / 路由 / 集合通信 / 拥塞)已有完整调研在 docs/interconnect/,本篇不重复机制细节,只讲"作为 perf model 输入怎么用"
  • 通信在 perf model 里是占用链路资源的节点,时长来自 $\alpha + n/\beta$,但 $\alpha$、$\beta$ 是拓扑 + 路由 + 拥塞的函数,不是常数
  • 五种并行(TP / PP / DP / EP / SP-CP)的通信特征截然不同——TP 每层两次 AllReduce 落关键路径,EP 每个 MoE 层两次 All-to-All,PP 是 bubble 主导
  • 端到端只受暴露通信影响,藏进计算的部分对延迟贡献为零——决定哪些通信暴露的是事件驱动时序层,不是通信模型本身
  • 升档触发不是"想更准",而是问题需要 cycle-approx 才答得出:拥塞 / incast / 多流争用 → cycle-approx,否则 analytical 拓扑感知足够

名词定义​

名词定义
$\alpha$-$\beta$ 模型通信延迟 $\alpha + n/\beta$,机制详见 6.2 Alpha-Beta 模型
暴露通信通信时间超出可重叠计算的部分,计入端到端关键路径
Bubble流水线并行因 stage 依赖等待造成的资源空闲
Capacity factorMoE 专家容量与平均负载之比,影响 All-to-All 不均衡程度
拓扑感知 $\beta$按拓扑与集合通信算法折算的有效带宽,而非链路裸带宽

本篇范围与边界​

本篇是 perf model 视角层,讲互联机制怎么作为模型输入被各档精度消费。机制层的完整调研在 docs/interconnect/,本篇用链接引用,不重述:

机制层主题已有调研位置
$\alpha$-$\beta$ 模型与 $\alpha$ 物理分解6.2 Alpha-Beta 模型
LogP / LogGP 扩展模型6.3 扩展模型
集合通信延迟闭式6.4 集合通信算法延迟公式
多跳拓扑建模6.5 多跳拓扑建模
参数标定方法6.6 参数标定
通信模型精度验证6.7 精度验证
拥塞建模6.8 拥塞建模
网络拓扑(fat-tree / dragonfly / torus 等)2.1 总览
路由算法(DOR / ECMP / UGAL 等)3.1 总览
集合通信算法(Ring / Tree / NVLS / SHARP 等)4.1 总览
网络仿真器(ASTRA-sim / SimAI / ns-3 / SystemC)7.1 总览

@tbl-ipm-i-mechanism-refs 互联机制层调研索引

本篇独占的增量内容:

  • 五种并行(TP / PP / DP / EP / SP-CP)的通信特征作为 perf model 输入
  • 暴露通信(exposed comm)如何在 perf model 中涌现
  • 各档精度下通信节点怎么进时序
  • G5 / SystemC AT 在 interconnect 域的落点判据

通信在 perf model 里是什么​

核心抽象:通信节点 = 占用链路资源一段时间的节点,时长由 $\alpha + n/\beta$ 给出。它和计算节点的区别只在占用资源类型——计算占算力引擎,通信占链路(片内 NoC、片间 c2c、跨机网络)。

这个抽象让计算和通信在同一套事件驱动框架里统一处理(见 05-调度与时序协同):两类节点占用不同资源,所以能在时间轴上并发,重叠自然涌现。

关键认识:$\alpha$、$\beta$ 不是常数,是拓扑 + 路由 + 拥塞的函数。多机大规模推理,通信延迟绝对值几乎全由这一栈决定。机制详见 6.2 Alpha-Beta 模型 的 $\alpha$ 物理分解(7 个分量,从 $\alpha_{\text{sw}}$ 到 $\alpha_{\text{mem}}$,跨拓扑层级量级差异 10-100 倍)。

各档精度下的通信建模​

档通信节点形态$\alpha$、$\beta$ 来源适用问题
analytical一个标量时长datasheet 峰值 + 经验 $\eta$设计空间相对排序
trace-replay一个标量时长真机集合通信实测查表已上线硬件部署评估
event-driven占链路资源的事件拓扑感知 $\alpha$、$\beta$ + 集合通信闭式端到端时序、暴露通信
cycle-approxflit 流 + router 仲裁链路级精确建模拥塞、incast、多流争用

@tbl-ipm-i-tier 互联建模四档精度的通信节点形态

analytical 档:拓扑感知 $\alpha$、$\beta$​

最低精度档把通信折算成一个标量时长。关键不是用裸 $\alpha$、$\beta$,而是用拓扑感知后的有效值:

GenZ / Calculon / LLM-Viewer 均在此档,把"一次 AllReduce 多久"作为给定标量输入。它们的局限是忽略拥塞——这在单作业独占网络时尚可,多机大规模有共享时系统性低估通信。

trace-replay 档:真机查表​

实测代表性集合通信(AllReduce / All-to-All 在不同 N、不同 message size 上),建查表。Vidur / vTrain 用此法,详见 02-计算建模 中两工具的描述——同一套 trace 工程同时覆盖 compute 与 comm。

局限:必须能跑到目标硬件,且 NCCL 类库的实测在孤立 profiling 下平均低估约 30%(vTrain 论文 verbatim,适用于通信侧),原因是真实多算子环境下的争用未被捕获。

event-driven 档:通信作为事件​

ASTRA-sim 2.0 的网络后端可在 analytical / Garnet(flit 级 cycle-approx)/ ns-3(packet 级)之间切换,见 7.2 ASTRA-sim。事件驱动核心负责:

  • 通信节点按数据依赖挂到计算 DAG
  • 同资源串行 / 不同资源并发
  • 暴露通信按依赖与资源占用涌现

这一档相对 analytical 的增量价值不在单次通信时长精度(仍由底层 $\alpha$、$\beta$ 给),而在算子间通信能否藏进计算这件事 analytical 无法表达。

cycle-approx 档:flit / router / 拥塞​

flit 级 NoC + c2c + router 仲裁 + 拥塞流控的完整微架构。代表工具:Garnet 3.0(gem5)、SST、ns-3 + RDMA 扩展。详见 7.4 NS-3、7.5 SystemC / TLM。

该档能 capture 前三档 capture 不到的:bank conflict(NoC 内 buffer 争用)、virtual channel 死锁避免、PFC 反压链、incast 多 sender → 单 receiver 拥堵——这些都是拥塞建模的物理来源(详见 6.8 拥塞建模)。

五种并行的通信特征(本篇独占)​

这是 perf model 视角下的核心增量——把 LLM 并行策略翻译成"通信节点何时触发、传什么、占多久"。各并行的算法细节在 interconnect/05-LLM并行通信/,本表是 perf model 输入清单:

并行通信操作何时发生通信量perf model 关键点
TP(张量并行)AllReduce每层 forward 两次(self-attention 输出、FFN 第二 GEMM 后)$b\cdot s\cdot h$落每层关键路径,高频,decode 算子小 $\alpha$ 占比高
PP(流水线并行)P2Pstage 边界stage 间激活通信量小,真开销是 bubble(GPipe / 1F1B 公式见下)
DP(数据并行)AllReduce推理几乎无—推理 forward 无通信,训练才有梯度 AllReduce
EP(专家并行)All-to-All每个 MoE 层两次(分发 / 收集)$b\cdot s\cdot h\cdot \text{cap-factor}$decode 每步触发,capacity factor 不均衡放大消息
SP / CP(序列 / 上下文并行)AllGather / 集合通信attention 沿序列维KV 或 Q 分片与 attention 计算可流水重叠(Ring Attention)

@tbl-ipm-i-parallel-comm 五种并行的通信特征 perf model 输入清单

各并行的详细算法、通信调用模式、变体见对应已有文档:

TP 的关键路径性质​

TP 每层 AllReduce 直接落关键路径,且无法跨层提前——这是 TP 扩展性受片内带宽约束的根因。decode 阶段算子小,AllReduce 的 $\alpha$(启动延迟)占总时长比 prefill 高得多。perf model 必须按 prefill / decode 分别评估 TP 通信开销,用同一 $\eta$ 会偏。

PP 的 bubble 公式​

通信本身量小,真正开销是 stage 间等待的 bubble。GPipe 的 bubble 比例:

$$\begin{equation} \text{bubble}_{\text{GPipe}} = \frac{N - 1}{N + M - 1} \label{eq:ipm-i-gpipe-bubble} \end{equation}$$

其中 $N$ 是 stage 数,$M$ 是 micro-batch 数。1F1B / interleaved 调度能压低 bubble。推理 decode 的 micro-batch 数少,bubble 占比可能比训练严重,这是 PP 在推理少用的原因之一。详细调度变体见 5 流水并行 (PP)。

EP 的 decode 触发性​

EP 的 All-to-All 在 decode 每步都发生——每生成一个 token 都要走 expert 分发 + 收集两次。容量因子(capacity factor)不均衡时,某些设备消息更大,perf model 必须 capture 这种不均(详见 10 MoE 篇待写)。

CP 的可重叠性​

Ring Attention 把 KV 分块在设备间环形传递,通信与分块 attention 计算流水重叠——这类通信暴露程度低,前提是计算足够长能掩盖传输。这是 perf model 中"通信可隐藏"最干净的例子,但 decode 计算太短时仍会暴露。

暴露通信:perf model 关心的不是绝对时长​

一次通信发生了,只有没被计算掩盖的部分计入端到端:

$$\begin{equation} T_{\text{exposed}} = \max(0,\; T_{\text{comm}} - T_{\text{overlap-compute}}) \label{eq:ipm-i-exposed-comm} \end{equation}$$

这是把通信接入 perf model 的核心价值——通信对端到端的影响不是它的绝对时长,而是暴露时长。一个通信量很大的算子,只要能藏进计算,就不构成瓶颈。

prefill 与 decode 的暴露差异:prefill 算子大(GEMM),有充足计算可掩盖通信,TP 的 AllReduce 常能部分重叠;decode 算子小(GEMV),可重叠的计算少,同样的 AllReduce 在 decode 里更容易暴露。这解释了为什么 decode 阶段对通信延迟(尤其 $\alpha$)比 prefill 敏感得多。

判断暴露多少要靠事件驱动时序层(见 05-调度与时序协同)按依赖与资源排时间轴,不能在通信模型里单独算。analytical 档常用全局 overlap 系数近似,会丢失局部效应——比如负载均衡消除的等待气泡,只有事件驱动模型才看得见。

网络仿真器在 perf model 链路中的定位​

把仿真器按精度档对位,详细的工具介绍在 interconnect/07-仿真工具/:

仿真器档与 compute 域协同
ASTRA-sim 2.0event-driven(可降到 cycle-approx Garnet)compute backend 可换 roofline / trace,统一事件循环
SimAI(阿里)event-driven,面向 LLM 训练集成自己的 compute model
Garnet 3.0(gem5)cycle-approx flit 级经 gem5 集成 GPU/CPU compute
SSTcycle-approx 多节点模块化 backend
ns-3 + RDMApacket 级通常 standalone,trace 喂上层
SystemC TLM ATcycle-approx与 compute / memory 同一框架(见 09 G5 落地)

@tbl-ipm-i-simulators 主流网络仿真器在 perf model 链路中的位置

具体能力对比见各篇:7.2 ASTRA-sim、7.3 SimAI、7.4 NS-3、7.5 SystemC / TLM。

升降档判据(interconnect 域)​

  • 单作业独占网络的相对排序:analytical 拓扑感知 $\alpha$、$\beta$ 够用,升档无价值——拥塞不存在,精细建模只增加不确定性
  • 多作业共享 / 大规模拓扑:必须升 event-driven 至少,因为争用产生的有效 $\beta$ 折扣不能用全局 $\eta$ 表达
  • 拥塞 / incast / PFC 反压链:必须 cycle-approx(Garnet / SST / SystemC AT),拥塞控制反馈环路解析不出来
  • 暴露通信精确预测:event-driven 足够,不必升 cycle-approx——暴露程度由依赖与资源决定,与 flit 级细节无关

G5 落地视角(interconnect 域)​

SystemC AT 在 interconnect 域的实际定位与 compute 域不同——它的杀手级用例就在这里(见 02 Compute 篇的 SystemC AT 在 compute 域的盲区讨论)。理由:

  • 通信涉及多个 unit 异步交互(NIC、router、链路、buffer),AT 的 nb_transport_fw / bw 四相握手正好适配
  • 拥塞 / 流控是反馈环路,需要 cycle-approx 才能正确建模
  • 多时钟域(片内 / 片间 / 跨机)在 SystemC 里用独立 sc_clock + sc_event 表达自然

具体实现细节(模块结构、信号、握手时序)放 09 G5 落地示例篇。本篇只点出"interconnect 是 SystemC AT 在 G5 建模里最重要的应用域"。

Takeaway​

知识点核心结论
本篇定位perf model 视角层,机制详见 docs/interconnect/
通信节点抽象占链路资源一段时间,与计算节点统一处理
五种并行通信TP 每层两次 AllReduce、PP 是 bubble、EP decode 每步 A2A、SP/CP 可与计算重叠
暴露通信端到端只受暴露时长影响,涌现自事件驱动时序层
升降档判据单作业 → analytical 够;争用 / 暴露分析 → event-driven;拥塞 → cycle-approx
G5 落点SystemC AT 在 interconnect 域的杀手级用例,优于 compute 域

开放问题​

  • 多目标 perf model(同时优化延迟与吞吐)下,通信对两个目标的权重不同,如何在同一通信模型里表达——见 07 多目标与异构篇待写
  • 异构 die / chiplet 互联的 perf model 标定:die-to-die 链路与传统 c2c 的差异在 SystemC AT 怎么建,公开资料稀少

参考资料​

本篇主要内容来自 docs/interconnect/ 章节的已有调研,具体引用请见对应链接的"参考资料"段。本篇独占增量来自:

延伸阅读​