CUDAコードをAMDへ移植したら、速度も同じになるのでしょうか？

予算内でメモリ容量の大きいRadeon構成を見つけたものの、使いたいローカル画像処理アプリの導入ガイドにはCUDAしか書かれていないとします。次に気になるのは「AMD向けにコードを移せば、速度も同じなのか」でしょう。ソースがHIP³形式になり、ログにGPU⁴名が表示されても、移植が完了したとは限りません。プログラムが起動すること、正しい結果を出すこと、長いセッションでも安定すること、CUDA構成と同程度の時間で終わることは別々に確認する必要があります。本記事では、そのRadeonを購入する前に公式の実行経路と実作業の比較を確認する順序を追います。

移植ツールを調べる前に、アプリが公式にサポートする実行経路を確認します。GPUを購入する前に、プロジェクトの導入ガイド、リリースファイル、issue、サポート一覧でROCm/HIPビルドの有無を探します。「CUDA対応」とだけ書かれていても、AMD対応を意味しません。HIPはCUDAに似たGPUプログラミングAPI⁵を提供し、HIPIFYはソース内の一部の呼び出しを対応するHIP形式に変換する手助けをします。アプリがROCm⁶向けのパッケージを配布しているのか、利用者がソースから移植する必要があるのかで、必要な作業と検証範囲は大きく異なります。購入者にとっては、公式バイナリや導入経路の有無を先に調べることが、リスクを減らす現実的な出発点です。

ローカル画像処理ツールがCUDAビルドしか配布しておらず、Radeonでも同じような構成を使いたいとします。リポジトリのソースにHIPIFYを実行しただけでは、完成したAMDアプリにはなりません。GPUの作業をどのように分割するか、入力や中間結果をどこに置くか、いつメモリをコピーまたは再利用するかはプロジェクトが決めています。cuBLASなどCUDAライブラリを呼び出す場合は、対応するライブラリと関数の動作も確認が必要です。自動変換ツールが関数名を書き換えても、性能に影響する作業単位の大きさ、データ配置、同期タイミング、ライブラリアルゴリズムまで自動最適化するわけではありません。コンパイル成功だけで速度まで保証されないのはそのためです。

まず正確さを別に確認します。同じ入力ファイルを両方で処理し、出力がアプリの許容範囲に収まるか見ます。浮動小数点演算は実行順序やカーネル実装によって、末尾の数桁に差が出ることがあります。ビット単位で同一の出力が必要か、指定した誤差範囲内ならよいかは、プログラムの目的に応じて決めます。画像生成では、同じseedと設定でもすべてのGPUでピクセルが完全に一致すると仮定せず、アプリが求める品質基準や失敗の種類を比べます。この段階で結果が正しくなければ、速度比較に意味はありません。

次に実行の安定性を確認します。小さな入力を1枚処理できても、長いセッションで問題がないとは限りません。代表画像を保存して同じファイルを繰り返し処理し、アプリを終了して再起動したあとも同じ流れを再現できるか試します。モデルや画像サイズを一度に大きくせず、普段使う解像度まで段階的に上げてください。メモリ使用量が増え続けないか、大きな入力だけでエラーが起きないか、終了後にリソースが解放されるかも見ます。モデルファイル、精度、画像解像度、同時に起動するアプリを実際の利用条件に固定すると、一度だけの成功と再現可能なセッションを区別しやすくなります。

その後で初めて性能を比べます。NVIDIA CUDAとAMD ROCmは、同じPyTorch⁷ API名や似たソースコードを使っていても、異なるランタイム⁸、ライブラリ、カーネル実装を介してGPUを実行します。コード行数が似ていることや変換が短時間で済むことは、実行時間が同じという根拠にはなりません。新しいハードウェアを買う前に比較条件を書き出します。同じ画像入力、出力解像度と処理ステップ、アプリのバージョン、品質基準をそろえてください。メモリ不足で片方だけCPU⁹オフロード¹⁰が必要なら、その設定も記録し、実際に使う構成を反映しているか判断します。

時間に何を含めるかも分けて記録します。モデルファイルを読み込んで準備する時間と、準備後に画像を処理する時間は異なる場合があります。利用者が実際に待つのは実行ボタンを押してから出力ファイルを保存するまでかもしれません。準備、最初の画像、繰り返し処理、保存まで含む全体の完了時間を分けて記録します。同じ画像を複数回処理すると、キャッシュ済みセッションだけ速いのか、毎回モデルを準備する環境でも実用的なのかが分かります。購入後の使用感と数字を結びつけられるよう、どの条件を測ったのか明記してください。

公開ベンチマークで速い構成が示されていても、それだけで購入判断はできません。アプリのバージョン、GPUメモリの使い方、出力品質の基準が異なれば、その数値を自分の作業にそのまま当てはめられません。ドライバーやROCmのバージョンも結果に影響し、メモリ不足で停止するアプリもあれば、一部をCPUへ移すアプリもあります。購入判断に役立つ比較にするには、実際に使う予定の画像処理と同じ設定で確認してください。

何を試せばよいか分からない場合は、アプリの実行ログを手掛かりにします。ログにHIPランタイムやAMD GPUが表示されれば、どの経路で実行されたかを知る材料になります。ただし、デバイス検出やランタイム初期化が成功したことを示す場合があっても、アプリ全体が正常に動作しGPUを有効に使っている保証にはなりません。詳細ログでモデル初期化、メモリ確保、カーネル実行、結果保存まで完了したか確認します。公式ROCmビルドがないプログラムでは、コミュニティ変換版の更新や不具合対応の責任が異なる点も考慮してください。

比較メモにはGPUモデル、OSビルド、ドライバー・ROCmのバージョン、アプリのリリース、画像入力、出力解像度と処理ステップ、品質基準を記録し、設定ファイル、出力画像、ログを保存します。テスト中にアプリやモデルを更新した場合は、別の試行として区別してください。既存のCUDA PCとRadeon候補を交互に試す際は、同じファイルと設定を使い、新しいセッションからモデル初期化、初回処理、反復処理、結果保存の時間を分けます。初回ロードだけに差があるのか、繰り返し作業でも差が続くのかを判断できます。再現できるエラー情報と出力品質も残し、速度だけでなく安定性も並べて確認します。電力制限やバックグラウンド作業が異なる場合も記録し、条件が一致しているか振り返れるようにしてください。

時間を測る際は画面に最初の進捗表示が出るまでではなく、アプリの完了通知とファイル保存までを測定範囲として定めます。GPU処理を非同期キューに入れるアプリでは、ボタンを押した時刻と計算完了が異なることがあるため、完了ログや出力ファイルのタイムスタンプも確認します。両方のPCで同じ準備状態にし、反復値のばらつきも見てください。一度だけのキャッシュ効果やバックグラウンド処理が購入判断を左右する可能性を減らせます。

購入判断で重要なのは、ソースを変換できるかではなく、使いたいそのアプリに確認可能なAMD経路があるかです。公式ROCmビルドがある場合は、文書に記載されたGPU・OS・ドライバー・ROCm・フレームワークの構成を合わせ、代表的な画像処理を保存や再起動まで含めて繰り返します。ソースのみ公開されているなら、HIPIFYによる変更を確認し、正確さ・安定性・性能を検証し、今後誰がAMD環境を維持するのか決めます。移植版が一度起動したからといってCUDA版と同じ速度を期待することはできません。AMD公式経路がなく、移植と検証を自分で担う予定もないなら、このアプリのためにそのGPUを買う判断は保留するのが現実的です。

背景説明として、Unreal TechのCUDA動画を参照できます。実際のプロジェクトに移植手順やAPIの違いを適用する際は、動画とは別にAMDのHIP移植ガイドとHIPIFYドキュメントを確認してください。