GitHub Repo
PyTorch 社群回報 CUDA 批次 SVD 效能落差，矩陣跨過 32 維可能轉為逐筆執行
10 月 10 日的 PyTorch 社群回報指出，CUDA 批次 SVD 在矩陣尺寸從 32 增至 33 時，可能因執行路徑切換而大幅變慢。案例附有跨環境量測與修補提案，但替代驅動的精度取捨及正式修補狀態仍須確認。
PyTorch 社群於 10 月 10 日提交 CUDA 線性代數效能回報：同樣一次處理 50 個矩陣，torch.linalg.svd 的預設路徑在尺寸由 32×32 增至 33×33 時，耗時可能突然跳升，svdvals 與 pinv 也呈現類似現象。這次新增的是附有重現程式的問題追蹤，尚非正式版本修正。原始回報
回報者在 Tesla T4、PyTorch 開發版上，以 CUDA Event 計時並取七次執行中位數；float32 SVD 從約 1.10 毫秒增至 104.8 毫秒。相同 33×33 輸入改用 driver="gesvda" 約需 3.80 毫秒。回報也列出穩定版與 RTX 3050 的類似結果，但這些數字仍屬提交者量測，不能直接推算其他 GPU 或整體訓練流程的加速幅度。量測與環境
回報將原因指向後端分支：兩個矩陣維度都不超過 32 時，使用 gesvdjBatched；超過門檻後，改為逐矩陣呼叫 gesvdj，批次因而失去原有執行優勢。討論中已有貢獻者提出讓預設選擇考慮批次與尺寸的修補方向，但查核時議題仍開啟，未能確認正式發布版本。技術討論
替代演算法也有代價。官方文件將 gesvda 定義為近似方法，並提醒驅動選擇需權衡速度與精度；病態矩陣或精度要求較高的情境，建議考慮 QR 方法 gesvd。文件也指出，使用奇異向量計算梯度時，重複或相近的奇異值可能造成數值不穩定，因此單看前向耗時不足以決定替換策略。SVD 文件
對在低秩分析或研究流程中頻繁執行小矩陣分解的團隊，這份回報提供了具體排查線索：應在實際資料上比較門檻兩側的延遲、重建誤差與梯度表現，再評估顯式指定驅動。後續值得追蹤的是預設策略是否合併、涵蓋哪些資料型別，以及新策略在病態矩陣上的驗證結果。