GitHub Repo
PyTorch 社群回報 Inductor 損失函數檢查缺陷，標籤尺寸不符仍可能回傳數值
10 月 8 日的 PyTorch 開發版重現指出，Inductor 編譯的 nll_loss 可能接受空間尺寸錯誤的標籤，直接算出損失值。相同輸入在 eager 與 aot_eager 會拋出例外，但正式版本影響範圍與修補仍待確認。
PyTorch 社群於 10 月 8 日提交一個涉及訓練正確性的最小重現：torch.nn.functional.nll_loss 收到空間尺寸不符的標籤時，一般 eager 執行與 torch.compile(backend="aot_eager") 都會拒絕輸入；改用 Inductor 後，卻回傳損失張量。回報環境為 2.15.0a0+git1a080e5 開發版，目前議題仍開啟，頁面未列出修補 PR。社群回報
案例將輸入設為 (2, 3, 2, 2)，代表兩筆樣本、三個類別與二乘二的空間維度；標籤卻是 (2, 2, 1)。官方文件規定，多維負對數似然損失的標籤形狀應對應輸入移除類別軸後的各維度，因此此處應為 (2, 2, 2)。文件也要求輸入為對數機率、標籤值落在有效類別範圍內。API 文件
值得注意的是，重現使用隨機數作為輸入，重點在於錯誤形狀是否遭拒絕，而非驗證某個損失數值的合理性。aot_eager 同樣會追蹤並執行計算圖，卻仍保留例外；回報者據此將問題指向 Inductor 的降階或分解路徑。這是有對照支持的定位線索，尚不能視為維護者已確認的根因。重現與後端對照
對工程團隊而言，這類差異可能讓資料前處理的尺寸錯誤更晚才被發現。例如像素分類流程若產生錯誤寬度的標籤，只檢查損失是否為有限數值，便可能漏掉輸入契約遭破壞的情況。這是依案例推導的風險，原回報沒有展示完整訓練、梯度結果或模型品質下降。
採用編譯訓練的團隊可在資料進入損失函數前核對形狀，並把刻意製造的錯誤標籤納入 eager 與編譯後端的對照測試。接下來應觀察上游是否確認受影響版本、補回尺寸檢查，以及加入例外行為的回歸測試；現有證據不足以推論所有正式版本或正常形狀輸入都受影響。