GitHub Repo
PyTorch 社群提出 NCCL2 記憶體池修補，後續配置可能錯失對稱通訊核心
10 月 13 日的 PyTorch 回報指出，NCCL2 後端可能漏登記對稱記憶體池新增的區段，讓集合通訊退回 ring 核心。修補提案附有雙 GB200 測試與核心路徑對照，但尚未合併，也未提供端到端效能數據。
PyTorch 於 10 月 13 日收到一項分散式通訊回歸回報：使用 NCCL2 後端時，先登記空的對稱記憶體池、再從池中配置張量，可能無法啟用預期的對稱通訊路徑。回報環境為兩張 GB200、CUDA 13.0 與 NCCL 2.30.7，涵蓋開發版及 nightly；作者將問題連結至 2.15 的預設後端切換，但正式版本影響仍須確認。問題回報
缺口在於區段的登記生命週期。register_mem_pool(pool, symm=True) 只替呼叫當下已有的區段建立對稱視窗；之後新增的區段僅做一般登記，未保留對稱屬性。回報中的 profiler 顯示，AllReduce 因而使用 ring 核心；設定 zero-CTA 的 AllGather 也未走 Copy Engine。重現與分析
這會影響工程師對通訊與計算重疊的判斷。NVIDIA 文件說明，對稱視窗要求各 rank 使用相同的緩衝區位移，也是 zero-CTA 最佳化的必要條件；符合硬體、驅動與集合運算限制時，Copy Engine 可執行通訊而不占用 CTA。據此推論，漏登記可能使原本規劃的資源分配失效，但目前不能換算成固定的訓練速度損失。NCCL 技術文件
修補提案改為保存每個池的 symm 旗標，在配置新區段時補做視窗登記。作者提供的局部驗證顯示，新增的四個核心選擇測試通過；停用修補後，NCCL2 測試失敗而舊後端仍通過。審查也要求對稱登記失敗時直接報錯，避免默默降級。不過，視窗登記是集合操作，各 rank 仍須以相同順序配置區段。修補與測試
截至查核，提案仍開放，尚不能視為已發布修正。使用對稱記憶體池的團隊可先比對登記前後配置的核心路徑，再於測試環境評估回報列出的舊後端暫避方式。後續應追蹤合併與版本收錄，以及真實工作負載的延遲、頻寬和重疊效果；目前證據支持通訊路徑回歸，未顯示張量計算結果錯誤。提案狀態