GitHub Repo
PyTorch 社群回報資料載入效能回歸，背景執行緒可能拖慢 CUDA 訓練
10 月 24 日的 PyTorch 社群回報指出，同一程序內的背景執行緒接收大型 DataLoader 批次時，特定 CUDA 訓練測試會明顯變慢。回報附有跨版本測量與重現程式，但根因、影響範圍及修復版本仍待確認。
PyTorch 使用者於 10 月 24 日提交效能問題，指出從 2.10.0 起，同一程序內若有背景執行緒持續接收 DataLoader 的大型批次，CUDA 訓練迴圈可能受到明顯干擾。這是一項附有重現程式的社群回報；截至查核時，議題仍開啟，尚無維護者確認根因或提供正式修復。問題回報
重現程式讓主執行緒訓練小型卷積網路，背景執行緒則接收八個載入工作程序送出的影像批次，每批約 79 MB，收到後直接丟棄。在回報者的 RTX PRO 6000 Blackwell 上，2.9.1 每步約 8.83 毫秒，2.10.0 約 428 毫秒；關閉背景載入後，兩版都約 8.4 毫秒。這個對照顯示，問題值得從資料載入與運算同時執行的路徑調查，但尚不足以判定底層原因。測試程式與數據
極端測試的倍率也不能直接套用到實際訓練。回報中的 YOLO 工作負載，每步時間由約 73 至 75 毫秒增至 80 至 85 毫秒，差距較小。回報者並聲明，詳細報告由 Claude Code 根據其機器上的測量撰寫，因此這些數字仍需其他環境獨立重現。測量說明
官方文件說明，num_workers 控制資料載入的子程序數量；設為零時，資料會在主程序載入。pin_memory=True 則將張量放入鎖頁記憶體，以加速傳往 CUDA GPU。兩者控制不同環節，工程團隊排查時應分別測量工作程序數、批次大小與記憶體固定設定，避免僅憑 GPU 利用率判斷瓶頸。DataLoader 文件
對近期升級後吞吐量下降的團隊，這份回報提供了可比較的測試入口。建議固定模型、驅動與資料條件，比較純運算和完整輸入管線的每步延遲；後續應觀察維護者能否定位引入變更，以及修補是否同時改善微型測試與真實訓練。