GitHub Repo
PyTorch 社群回報 BF16 Dropout 隨機序列重疊，連續呼叫可能產生相關遮罩
10 月 28 日的 PyTorch 社群回報指出，特定 CUDA BF16 輸入在連續執行 Dropout 時，部分遮罩會完全重合。回報附有兩個版本的重現結果與核心程式分析，但截至查核時尚無維護者確認或正式修補。
PyTorch 於 10 月 28 日收到一份涉及訓練隨機性的錯誤回報：在 NVIDIA L40 上，以立即執行模式連續呼叫 aten::native_dropout，特定 BF16 張量產生的兩份遮罩出現規律重疊。回報者在 2.7.0+cu126 與 2.14.1+cu126 均觀察到相同現象；這是兩個版本的實測結果，尚不能據此認定中間所有版本皆受影響。問題回報
重現條件包括形狀為 (4096, 128)、連續排列且記憶體位址對齊 16 位元組的 BF16 輸入，以及 0.5 的丟棄機率。將遮罩每八個元素分組後，第一次呼叫的後四個元素，與第二次呼叫的前四個元素完全一致；獨立伯努利遮罩的預期吻合比例則約為一半。測試只在兩次呼叫前設定一次種子。改用 FP32，或將 BF16 起始位址偏移八個位元組，這項特定重疊便消失。重現與對照
回報者懷疑，向量化核心消耗的亂數量與 Philox 計數器預留量不一致。公開的 2.14.1 原始碼顯示，亂數產生次數隨向量寬度調整，計數器位移則使用 UNROLL 計算；當每次處理八個元素，若只預留四個亂數的位置，下一次呼叫便可能重用前一次的序列。這個解釋符合回報結果，但仍屬待確認的根因分析。CUDA 核心原始碼
技術上的關鍵是遮罩的獨立性。官方文件說明，Dropout 在訓練時以伯努利分布選擇歸零元素，每次前向呼叫獨立抽樣，用於抑制神經元共同適應。因此，跨呼叫的固定相關性可能改變正則化行為；目前沒有完整模型的收斂或準確率數據，無法量化訓練影響。Dropout 文件
截至查核時，議題仍開放，只有自動分類標籤，未見維護者確認或關聯修補。工程團隊可依最小重現檢查自身硬體、張量形狀與實際執行路徑；後續應追蹤跨 GPU 驗證、亂數位移修正及穩定分支回補，也不能直接把結果推及編譯模式或其他融合核心。處理狀態