PyTorchコミュニティがCUDAバッチSVDの性能差を報告、行列が32次元を超えると逐次実行に切り替わる可能性

PyTorchコミュニティは10月10日、CUDA線形代数の性能に関する報告を提出した。同じく50個の行列を一度に処理する場合、torch.linalg.svdのデフォルト経路では、サイズが32×32から33×33に増えると処理時間が急増することがある。svdvalsとpinvでも同様の現象が見られる。今回追加されたのは再現コードを含む課題報告であり、正式リリースでの修正ではない。元の報告

報告者はTesla T4上のPyTorch開発版でCUDA Eventを使って計測し、7回の実行の中央値を採用した。float32のSVDは約1.10ミリ秒から104.8ミリ秒に増加した。同じ33×33の入力をdriver="gesvda"で処理した場合は約3.80ミリ秒だった。報告には安定版とRTX 3050での類似した結果も記載されているが、これらは投稿者による計測値であり、ほかのGPUや学習処理全体で得られる高速化の度合いを直接推定することはできない。計測と環境

報告では、原因としてバックエンドの分岐が挙げられている。2つの行列次元がいずれも32以下の場合はgesvdjBatchedが使われ、閾値を超えると行列ごとにgesvdjを呼び出す方式に切り替わるため、バッチ処理の利点が失われる。議論では、バッチサイズと行列サイズを考慮してデフォルトの選択を行う修正案が貢献者からすでに提案されている。ただし、確認時点では課題は未解決で、正式リリースへの反映は確認できていない。技術的な議論

代替アルゴリズムにはトレードオフもある。公式ドキュメントではgesvdaを近似手法と定義し、ドライバーの選択では速度と精度のバランスを考慮するよう説明している。悪条件行列や高い精度が求められる場面では、QR法のgesvdを検討することが推奨されている。また、特異ベクトルを使って勾配を計算する場合、重複または近接した特異値によって数値的不安定性が生じることがある。そのため、順伝播の処理時間だけで置き換え方針を決めるのは不十分だ。SVDドキュメント

低ランク解析や研究ワークフローで小さな行列の分解を頻繁に行うチームにとって、この報告は具体的な調査の手がかりとなる。実データを使って閾値の前後でレイテンシ、再構成誤差、勾配の挙動を比較したうえで、ドライバーを明示的に指定するか評価するとよい。今後は、デフォルトの選択方針が取り込まれるか、どのデータ型が対象になるか、また新しい方針が悪条件行列で検証されるかに注目したい。