viable/strict/1790023830: Reuse workers in process-group hook tests (#197686)
PyTorch 合并 PR #197686，修改 process-group hook 测试：不再为每个测试方法新建一对 Gloo rank，而是在 hook 测试间复用同一对 rank，并在下一个测试前注销 replay hook，同时保留 collective、hook-correlation 与 captured-graph 断言。测试计划覆盖 CPU 构建与 lint，两个测试在正常与逆序下运行，隐藏 GPU 及构建后运行。运行时间从 4.96s 降至 2.49s。
Development
- First Reportviable/strict/1790023830: Reuse workers in process-group hook tests (#197686)PyTorch Core
- Current Assessment该改动本身不改变 PyTorch 对外能力或商业格局，但反映大型开源项目持续压缩 CI 时间的工程取向。对依赖 PyTorch 的团队而言，测试稳定性与反馈速度是间接收益。可验证的下一信号是 PyTorch CI 整体时长或 flaky 率是否出现可观测变化。Agent Pulse · analysis
PyTorch 核心仓库的 viable/strict/1790023830 发布条目记录了 PR #197686：在 process-group hook 测试中复用 worker。改动让两个 Gloo rank 在 hook 测试间保持存活，而不是为每个方法重新拉起一对进程；同时在下一个测试前注销 replay hook，并保留 collective、hook-correlation 和 captured-graph 断言。测试计划包括 CPU 构建与 lint，两个测试在正常与逆序下运行，隐藏 GPU 以及构建后运行。运行时间由 4.96s 降到 2.49s。
这是测试基础设施层面的进程复用优化，而非分布式训练语义变化。复用 Gloo rank 能减少进程启动与销毁开销，但前提是 hook 状态被正确清理，因此注销 replay hook 是保证测试隔离的关键步骤。可验证的下一信号是：后续 PR 是否把同样的复用模式推广到其他 process-group 测试，以及是否出现因状态残留导致的 flaky 测试报告。
该改动本身不改变 PyTorch 对外能力或商业格局，但反映大型开源项目持续压缩 CI 时间的工程取向。对依赖 PyTorch 的团队而言，测试稳定性与反馈速度是间接收益。可验证的下一信号是 PyTorch CI 整体时长或 flaky 率是否出现可观测变化。
对使用 PyTorch 的团队，更快的 CI 意味着更短的合并等待与更低的开发摩擦，但该收益是间接且局部的。若团队自建分布式测试，可参考其复用 rank 加显式注销 hook 的做法来降低测试成本。
若复用模式被更广泛采用，PyTorch 的分布式测试套件可能进一步缩短反馈周期。需要观察后续是否出现 hook 状态泄漏相关的回归，以及维护者是否将其写入测试编写规范。