p2p overlap with dw and recompute - #79681
Conversation
risemeup1111
left a comment
risemeup1111
left a comment
There was a problem hiding this comment.
| 序号 | 位置 | 优先级 | 规则来源 | 状态 |
|---|---|---|---|---|
| 1 | 重计算接入 |  |
默认规则：优先级 仓库规则：功能与兼容性 |
🚧 |
| 2 | 异步 P2P 回归测试 | |
默认规则：优先级 仓库规则：分布式与测试 |
🚧 |
| 3 | 评估后计数复位 |  |
默认规则：优先级 仓库规则：生命周期与边界 |
🚧 |
验证范围：已完成目标 head 的完整 diff、历史、线程与检查核对，且 py_compile、git diff --check 通过；当前环境不具备可执行 Paddle/CUDA 多卡运行时，因此未运行 GPU/VPP 用例。
| have_dw = not WeightGradStore.funcs_queue.empty() | ||
|
|
||
| rc_key = None | ||
| if RecomputeStore.enabled and micro_step + 1 < num_steps: |
There was a problem hiding this comment.
RecomputeStore.enabled = False 的默认值，没有生产代码启用它或调用 put/drop；run() 还要求 span 提供当前代码树中不存在的 run_recompute_now()。因此 PR 所述 recompute 不会进入 P2P window。请同步接入实际 selective-recompute span 的启用、注册、移除和提前执行协议，并用可执行用例证明 rc_key 能命中。
| if not RecomputeStore.pending(rc_key): | ||
| rc_key = None | ||
|
|
||
| if have_dw or rc_key is not None: |
There was a problem hiding this comment.
test_zero_bubble_utils.py 只在单进程中测试队列；这里却会按各 rank 的 have_dw/rc_key 在同步与异步 P2P 间切换，并重排 best-unbalanced 最后一级收到的梯度目标。至少需要在 pp_degree > 2、vpp > 1 下覆盖 dW/recompute 开关及含 EmptyLayer 的不对称 pending 场景，并与不开优化时的 loss/梯度对齐，否则无法捕获通信挂起或梯度进入错误 virtual chunk。
| RecomputeStore.begin_chunk( | ||
| (virtual_pp_rank, self._rc_forward_count[virtual_pp_rank]) | ||
| ) | ||
| self._rc_forward_count[virtual_pp_rank] += 1 |
There was a problem hiding this comment.
eval_batch() 的 forward_only=True 路径也会递增，但 _rc_forward_count/_rc_backward_count 只在下方训练分支清零。一次 eval 后，下一训练批的 forward group 会从非零 micro id 开始，而 backward 计数仍从 0 开始，cooldown 因此无法命中任何 rc_key，该批 recompute overlap 会静默失效。请在每个 batch 边界（包括 forward-only）统一重置 Store 和两个计数，并覆盖 eval→train 顺序。
2 participants
PR Category
Performance Optimization
PR Types
New features
Description
p2p overlap： weight grad and recompute
是否引起精度变化
否