GitHub Repo
PyTorch 開發版回報 CUDA Graph 複製缺陷，延遲複製張量可能在重播時讀取舊資料
10 月 7 日的 PyTorch 與 TorchTitan 回報指出，copy-on-write 張量在 CUDA Graph 擷取期間實體化，可能漏記複製操作，導致重播產生錯誤結果。案例附有最小重現與 MoE 推論對照，但正式版本影響範圍及上游修補仍待確認。
PyTorch 儲存庫於 10 月 7 日新增正確性回報：以 torch._lazy_clone() 建立的 copy-on-write 張量，若在 CUDA Graph 擷取期間觸發實際複製，重播可能持續讀取擷取當下的舊資料，且擷取過程沒有報錯。回報環境為 PyTorch 2.16.0a0 開發版、CUDA 13.0 與 GB300，並指出 torch.compile(mode="reduce-overhead") 也能重現。PyTorch 回報
最小案例先以 NaN 初始化輸入，再於擷取區域建立延遲複製張量，呼叫 data_ptr() 觸發實體化。即使每次重播前已填入新隨機值，輸出仍含 NaN。回報分析將原因指向配置器使用未指定串流的同步 cudaMemcpy：複製只在擷取時執行一次，沒有成為圖中的節點。重現與原因分析
這與 CUDA Graph 的資料更新機制直接相關。官方文件說明，重播會沿用相同記憶體位址，使用者須在重播前更新輸入緩衝區；其效能收益主要來自省去 CPU 端的核心派送開銷。若中間複製未納入圖，更新原始輸入也無法刷新後續核心讀取的副本。CUDA Graph 官方文件
相關 TorchTitan 案例在 Qwen3.5-35B-A3B 的張量平行 MoE 推論遇到此問題：分片流程產生延遲複製張量，Dist-MoE 再透過原始指標交給 Triton 或 CuTe 核心。回報者也提供 H100 單 GPU 測試，顯示非預設串流可能在資料產生前先完成複製；改用一般 clone() 的對照則得到正確結果。TorchTitan 案例
工程上的下一步，是針對延遲複製、原始指標與串流交界建立正確性對照，並追蹤複製操作能否依目前串流排序及安全擷取。截至查核時，兩則 issue 仍開啟，頁面未連結修補 PR；現有證據集中於開發版，不能推定所有穩定版或所有 vLLM 部署都受影響。一般複製的暫時繞法也尚無完整效能成本量測。TorchTitan 回報與建議