06. Communication Profiling and Overlap | 通信剖析与重叠

学习问题

通信总时长不等于真正拖慢关键路径的通信时间。Profiling 要把 collective 放回计算时间线，区分已被计算覆盖的部分和暴露在 step 或请求关键路径上的部分，再决定减少 payload、降低频率还是调整调度。

从通信总时长到暴露通信时间

量	回答的问题	常见来源
collective	采用什么协同语义	All-Reduce、Gather、Scatter、All-to-All、P2P
payload	每次交换多少字节	梯度 bucket、activation、KV、token dispatch
frequency	一个 step / 请求触发多少次	bucket 数、层数、micro-batch、路由轮次
overlap	有多少通信与有效计算并行	stream、bucket ready time、双缓冲与调度

一次 collective 的时间可以先用启动延迟与载荷传输近似： $T_{c o m m} \approx α + β \cdot b y t e s$ 。多次调用还要乘以频率，但这些时间不能直接全部加到 step time 上。真正影响端到端时间的是未被独立计算覆盖的区间。

令 step_time_ms 为最慢 rank 的完整步骤时间，comm_total_ms 为通信 Kernel 区间之和，exposed_comm_ms 为落在关键路径且没有被有效计算覆盖的通信区间，则暴露通信比例为：

comm_exposed_ratio = \frac{exposed_comm_ms}{step_time_ms}

字段	计算或读取方式	能回答的问题	不能替代的证据
`median_max_rank_ms`	每次运行先取 max-rank，再跨重复取中位数	同步步骤的典型关键路径	P95 长尾与单 rank 原始值
`p95_max_rank_ms`	对重复运行的 max-rank 时间取 P95	抖动和尾部退化	平均有效带宽
`comm_total_ms`	合并同一 rank 上 NCCL 区间的总持续时间	通信工作总量	暴露在关键路径上的时间
`exposed_comm_ms`	从 Trace 依赖和时间区间计算未覆盖部分	通信实际延长了多少步骤时间	合成 serial/overlap 微基准的节省量
`comm_exposed_ratio`	`exposed_comm_ms / step_time_ms`	是否应优先优化通信关键路径	跨拓扑扩展效率

先在 trace 中确定依赖关系，再比较 max-rank 时间。简单相加所有 NCCL kernel 会重复计算已经与计算重叠的部分，也无法解释某个热点 rank 为什么拖慢全局同步。

Trace 现象	可能原因	下一步验证
大量短 collective	bucket 太碎、启动成本占主导	合并 bucket，比较调用次数与总时间
单次长 collective	payload 大或链路带宽不足	payload sweep、拓扑与有效带宽
通信与计算串行	依赖过紧、stream 或调度未重叠	检查 ready time、stream 和执行顺序
rank 间时间差异大	workload、路由或 stage 不均	对比 per-rank load 与 max-rank time
总通信高但 step 未变慢	大部分通信已被覆盖	记录 exposed communication 而非仅总时长