ROCmメンテナー、PyTorchパッケージの不整合は緩和されたと確認　安定版チャネルの文書にはalpha版が残存

ROCm TheRockのメンテナーであるScottToddは10月16日、PyTorchのリリース工程に関する問題をクローズし、現時点で修正または緩和済みだと述べた。同時に、リリースの各段階でチェックを追加できる余地があることも認めた。今回の更新で確認されたのは、先行する修正の対応状況だ。関連する変更は10月上旬にnightlyへ取り込まれており、これをもって既存の安定版パッケージがすべて再リリースされたと推定することはできない。問題の記録

問題は、パッケージのバージョンとインストーラーの選択ルールが相互に作用したことで発生した。最初の報告によると、ROCm 10.1.0の安定版インデックスに、a0マーカーが付いたtorchvision 0.29が含まれていた。バージョンを指定しない通常のインストールではtorch 2.14とtorchvision 0.28が取得され、ComfyUIなどのアプリケーションの実行時に、torchvision::nmsオペレーターが存在しないというエラーが発生する可能性があった。パッケージのダウンロードに成功しても、含まれるネイティブ拡張同士の互換性が保証されるわけではない。再現記録

修正は2段階で行われた。まず、torchvision wheelの依存関係メタデータで、ビルド時に使用したtorchのバージョンを指定し、リゾルバーが互換性のないパッケージを自由に組み合わせないようにした。次に、PyTorchの正式リリースブランチからビルドする際、パッケージの公開バージョンからa0サフィックスを取り除いた。前者はバイナリの組み合わせを制約し、後者は正式ブランチの成果物がプレリリース版として扱われる問題に対処する。バージョン紐付けの修正、バージョン番号の修正

ただし、確認時点でAMD公式インストールページのROCm 10.1.0向けコマンドの一部には、torchvision==0.29.0a0+rocm10.1.0が明示的に指定されていた。バージョンを厳密に指定したインストールと、バージョン制約を設けないインストールでは、異なる解決結果になる可能性がある。そのため、文書の例、インデックスの内容、ビルド工程をそれぞれ確認する必要がある。AMDインストール文書

AMD GPUの推論環境を保守するエンジニアリングチームにとって、この事例はパッケージの依存関係宣言がデプロイの再現性に与える影響を浮き彫りにした。上記の障害の仕組みを踏まえると、環境の検証時にはインデックスと完全なバージョン情報を記録し、アプリケーションが依存するビジョンオペレーターを実際に読み込んで確認する必要がある。今後は、安定版インデックスと文書が同期されるか、またリリース工程でバージョンを固定しないインストール経路を自動テストできるかが注目点となる。現時点で公開されている証拠は、主にメンテナーが提示したインストール出力に限られる。