ロンドンのSpectral Computeが、NVIDIAのCUDAソースをAMD GPU向けに直接コンパイルするツールチェーン「SCALE」を開発している。同社の最新測定では、AMD Instinct MI300X上でHIP版を平均6.19倍上回った。だが、この数字はAMD GPUがNVIDIA GPUをその倍率で上回ったという意味ではない。同じAMD製GPUへ、CUDAソースをSCALEで通すか、AMDの移植経路を使うか。その差を測った結果である。
SCALEの狙いはCUDAを捨てることではなく、CUDAとNVIDIA製GPUの結び付きをコンパイラの下で解くことにある。実現すれば、長年蓄積したCUDAコードを一本に保ち、調達できるGPUへ再コンパイルできる。ただし、CUDAの強さは言語仕様より広い。ランタイムと数値計算ライブラリの上にフレームワークが積み重なり、NVIDIA固有の低水準コードも入り込むため、コンパイラが動いた時点で移植が終わるわけではない。
6.19倍は何を比べた数字か
Spectral Computeが2026年5月に公開した測定は、科学技術計算向けのRodiniaベンチマークをAMD Instinct MI300Xで実行したものだ。比較相手はROCm 7.2.0上のHIPで、14ワークロードのうち10本でSCALEが速かった。平均高速化率は6.19倍、最大は33.8倍に達したという。
測定手順も公開されている。各ベンチマークを計150回、独立した5ラウンドに分けて走らせ、初期化とウォームアップの後に計時した。ファイル入出力やホスト側のメモリ確保など、CPUだけで処理する時間は除外している。代表値には中央値ではなく、記録した最小実行時間を採った。
ここには二つの留意点がある。まず、33.8倍という最大値が平均を押し上げるため、6.19倍を典型的なアプリケーションの改善率とはみなせない。4本ではHIPを上回っていない。さらに、結果は開発元による自社測定であり、第三者が同じ条件で再現したデータは確認できない。最小値はコンパイラが到達できる定常実行の下限を見るには向くが、実運用で効く中央値やばらつきは示さない。
対照として、NVIDIA B300上でCUDA 13のnvccと比べた測定では、SCALEは最大9%高速だった一方、平均性能は0.98倍だった。SCALEの価値を「常に速いコンパイラ」と捉えると見誤る。現時点でAMD向けに大きな差が出ていることは分かるが、公開結果だけでは個別の高速化要因まで切り分けられない。
翻訳ではなく、CUDAからネイティブ命令へ
AMDが提供するHIPIFYは、CUDAソースをHIP C++へ移行するツールである。API名や言語構造を変換し、その後はROCmのコンパイラとライブラリでビルドする。大規模なコードでは、自動変換後の修正に加え、CUDA版とHIP版の違いを追い続ける作業が生じる。
SCALEは別の経路を取る。ビルドシステムからはNVIDIAのnvccに見える互換フロントエンドを置き、nvccが受理するCUDA方言を解析する。AMD向けではLLVMのAMDGPUバックエンドを使ってネイティブ命令を生成し、独自に再実装したCUDA Runtime、Driver、Math APIへ接続する。cuBLASなどCUDA-X系のAPIは、対応するROCmライブラリをラッパー越しに呼ぶ。NVIDIA向けではコンパイラだけを置き換え、実行時ライブラリはNVIDIA製を使う。
この設計なら、既存のビルド設定を大きく変えずにターゲットGPUを切り替えられる。だが「ドロップイン」という言葉は、あらゆるCUDAプログラムが無修正で動く保証ではない。SCALE自身も未実装APIを一覧化し、開発途上だと明記している。互換性は宣伝文句ではなく、アプリケーションごとにコンパイル、数値一致、性能を検証して初めて確定する。
AMD固有命令をCUDAコードから引き出す
Spectral Computeは、SCALEが性能を伸ばす仕組みの一例として、AMD固有ハードウェアを狙ったコンパイラ最適化を挙げている。ただし、同社はRodinia全体の速度差を最適化ごとに分解しておらず、平均6.19倍のうちDPPがどこまで寄与したかは分からない。具体例は、GPU内のスレッド間で値を交換する「shuffle」の処理だ。一般的なLLVMのAMD向け経路は、幅広い並べ替えに対応できるds_bpermuteを使う。柔軟だが、共有メモリ系の経路を通るためコストがかかる。
AMD GPUには、特定パターンのデータ交換をレジスタ内で処理するData-Parallel Primitives（DPP）がある。SCALEはCUDAのshuffleやreductionの形を認識し、条件が合えばDPPへ落とす。交換と加算を一つの命令へ融合できる場合もあり、汎用経路より少ない命令で済む。CUDAで書かれた抽象的な処理から、NVIDIAには存在しないAMD側の機能を引き出すわけだ。
これは移植ツールと最適化コンパイラの違いをよく表す。ソースの表記をCUDAからHIPへ変えるだけでは、ターゲット固有命令の選択まで自動的に最良になるとは限らない。SCALEはCUDAを共通の入力言語として残し、その下でGPUごとに別の最適化を行う。CPUで同じC++をIntel系やArmへコンパイルする発想を、GPUへ持ち込んだ設計である。
ただし、ハードウェア差はコンパイラだけでは消せない。NVIDIAのwarpは通常32スレッドだが、AMDには64スレッドのwavefrontを使う製品がある。CUDAコードやインラインPTXが32ビットのlane maskを前提にしていれば、SCALEは警告を出せても、意図まで自動で直せない場合がある。「同じソースを受理すること」と「同じ並列実行の意味を保つこと」は別の課題だ。
CUDA互換の本丸はライブラリにある
CUDAアプリケーションは、コンパイラとランタイムだけで完結しない。AIならcuDNNやcuBLASLt、科学技術計算ならcuSOLVERなど、用途別ライブラリの上にフレームワークが積み重なる。SCALEがAMD上でこれらを動かすには、CUDA APIの振る舞いを再現しながら、ROCm側のライブラリへ正しく対応付ける必要がある。
公開されているSCALE 1.7.1の検証表は、到達点と残る距離を同時に示す。Rodinia、llama.cpp、FFmpegなどは複数のAMD／NVIDIAターゲットで検証に成功している。これに対しPyTorch、vLLM、cuMLなどは掲載されたターゲットで検証失敗となっている。公式サイトが案内するPyTorch対応も、希望者向けのプレリリースだ。AI基盤を丸ごと置き換えられる一般提供版とはまだ言えない。
検証表で失敗が多いことは、設計が成立しない証拠ではない。公開リポジトリには、対応前のプロジェクトも早期に追加されるためだ。互換性は一つの可否で決まらない。カーネルがコンパイルできても、必要なCUDA-X APIが欠ければアプリケーションは動かない。動いても数値精度や性能が変われば、本番投入前の再検証が要る。
価格より先に、検証コストを見る
SCALEは研究、教育、非営利目的では無償だが、公開ライセンスは商用利用を認めていない。営利事業で使う場合は有償契約が必要で、価格は公開されていない。したがって企業は、GPUの時間単価に加えて導入コストを比べることになる。ライセンス料と移植を避けられる工数を見積もり、再検証に必要な期間や複数ベンダーを選べる調達上の価値も合わせて判断する必要がある。
HPCwireによると、Spectral Computeは2018年の創業から長くコンパイラを開発し、2025年に600万ドルを調達した。取材時点で従業員は約30人である。巨大なCUDAエコシステムの互換実装を担うには小さな組織だが、裏返せば、CUDAへの依存を解く難しさがシリコン設計よりソフトウェアの地道な実装にあることを物語る。
SCALEがCUDAの囲い込みを崩せるかは、最大33.8倍という数字より、実アプリケーションを何本、無修正かつ再現可能な性能で通せるかにかかっている。判断材料になるのは、PyTorch正式版の提供、公開検証表での成功範囲、第三者によるRodinia再測定である。この三つが揃えば、CUDAコードを保ったままAMDも検討できる有力な選択肢になり始める。