S17：双进程 CPU/Gloo 与 Collective 观察
Collective 是一组 rank 必须以兼容顺序共同参与的数据交换操作；两进程 CPU/Gloo 能观察其同步与故障语义，但不代表 GPU 集群性能。
内容类型：预习教材（不代表已完成）
日期：2026-12-09
阶段：P2 · AI Systems Engineering 90
总路线：Day 107 / 360
周次 / 节奏：W3 · 周三引导练习
状态：教材已备；学习未完成
主题：process group、rank、world size、collective
一句话定义
Collective 是一组 rank 必须以兼容顺序共同参与的数据交换操作；两进程 CPU/Gloo 能观察其同步与故障语义，但不代表 GPU 集群性能。
学习目标
- 能解释 rank、world size、process group 和 rendezvous 的基本关系。
- 能追踪一次 all-reduce 前后每个 rank 的张量值。
- 能观察 collective 顺序不一致或 rank 缺席为何会等待/失败。
- 能清楚标注本地 CPU 演示与 NCCL、多机训练的差异。
核心知识
每个分布式进程拥有 rank，参与同一个 process group，world size 是组内成员数。初始化需要 rendezvous 信息，让进程就地址、端口和成员达成会合。Collective 的关键不只是 API：所有 rank 必须参与相匹配的操作，张量 shape/dtype 也要兼容。
All-reduce 对每个 rank 输入做归约，再把结果发送给所有 rank。例如 rank0 输入 1、rank1 输入 2，SUM 后两边都得到 3。Broadcast 由一个 source rank 向其他成员复制；all-gather 让每个成员得到各 rank 分片；reduce-scatter 先聚合再分片。同步点可能显式或隐式，快 rank 会等待慢 rank。
Gloo 支持 CPU 上的教学演示，便于不依赖 CUDA/NCCL 理解语义。它不能用来预测 GPU kernel、NVLink/InfiniBand、NCCL 拓扑或大规模吞吐。若当前 Python/PyTorch 环境不适合双进程，本日可以跟踪纸面模拟，不需要安装或修复大型环境。
机制与推导
以数据并行梯度平均为例，rank r 计算本地梯度 g_r：
[ \bar g=\frac{1}{P}\sum_{r=0}^{P-1}g_r ]
可用 all-reduce SUM 后除以 P。若某 rank 使用不同 batch size，简单平均 rank 梯度不一定等于按样本平均，需按样本数加权。若 rank0 先 all-reduce 而 rank1 先 broadcast，两边操作序列不匹配，可能 hang；这说明分布式控制流也必须一致。
故障会传播：一个 rank 崩溃，其他 rank 的 collective 无法永久自行完成。Timeout 能终止等待，却不自动恢复 optimizer 与数据位置；恢复依赖 checkpoint 和作业编排。
最小练习或观察步骤
- 先画 rank0/rank1，写出初始化、local compute、all-reduce、继续训练的顺序。
- 若 PyTorch 环境已可用，使用官方最小 Gloo 示例运行两个本地进程；否则手工模拟数值。
- 为两个 rank 赋不同标量，记录 collective 前后；不预设输出，按实际结果填写。
- 只在安全临时副本中尝试一次顺序不一致或 rank 延迟，设置合理 timeout，避免长时间挂起。
- 写出 CPU/Gloo 演示能证明与不能证明的各三点。
常见误区与边界
- 以为 rank 是设备编号；进程、设备和 rank 映射需显式定义。
- 两进程都返回就声称具备容错；正常同步不等于故障恢复。
- 不设 timeout 测试错误序列，造成进程长期等待。
- 用 CPU/Gloo 延迟推测 GPU/NCCL 生产性能。
- 本地环境不满足时强行安装；纸面 collective 模拟同样是正式学习方式。
系统场景连接
训练作业中的“一个 worker 慢导致全部慢”来自同步 collective 与 barrier-like 行为。平台监控需同时看各 rank step time、通信等待和数据加载，不能只看平均 GPU 利用率。Checkpoint 还要与所有 rank 的一致 step 对齐，才能在故障后恢复相同训练状态。
自检问题
- Process group 初始化解决什么问题？
- All-reduce SUM 与梯度平均差哪一步？
- Collective 调用顺序不一致为什么可能 hang？
- CPU/Gloo 演示不能支持哪些性能结论？
专业课程对齐
- 阅读 PyTorch Distributed 官方文档 的 initialization、rank/world size 和 collective API，重点跟踪每个 rank 的输入输出。
- 阅读 CMU Deep Learning Systems 的 distributed execution 内容，把计算图中的梯度同步映射为 collective。
- 阅读 MIT 6.5840 中容错与一致性课程框架，思考成员失败为什么会让同步操作无法仅靠 timeout 自动恢复。
深入学习提示
先手算两个标量，再运行任何代码。代码层重点观察进程是谁启动、group 在哪里初始化、每个 rank 是否执行相同控制流、资源怎样清理。若实验失败，记录失败阶段和错误即可，不把修环境变成主任务。最后用“数值语义、同步语义、故障语义、性能边界”四栏总结。
学后填写区
- 采用运行还是纸面模拟：
- 每个 rank 的输入与输出：
- 观察到的同步/错误事实：
- 演示不能证明的事项：
- 下一次最想确认的 collective：