AMD用CUDA for Windows – ZLUDAとROCm/HIPを介してAMD GPU上でCUDA Windowsアプリを実行する方法

TL;DR

AMD用CUDA for Windowsは、ZLUDAとROCm/HIPスタックを介してCUDA呼び出しを翻訳することで、CUDA対応WindowsアプリをAMD GPU上で実行可能にする。参照実装はRadeon RX 9060 XT（gfx1200）で検証済みであり、cuBLAS、cuBLASLt、cuSPARSE、cuFFTなどの主要ライブラリをサポートしている。

プロジェクトが提供する機能

CUDAドライバおよびライブラリ呼び出しを満たすために ZLUDA → ROCm/HIP を連鎖する再現可能なWindows環境。
AMD GPUを検出、ドライバ/HIP SDKバージョンを検証し、公式ZLUDA Windowsビルドを取得し、オプションでLibTorch 2.3.0+cu118をダウンロードする自動インストーラ（install.ps1）。
ライブラリカバレッジを確認しGPU詳細を報告するランタイムチェックスクリプト（cuda_check.exe、doctor.ps1、gpu‑scan.ps1）。
AMD GPU上で2,216,347パラメータのネットワークを用いた完全なPPOトレーニング実行（65,536ステップ）を示すドキュメント化された検証ワークフロー。

検証済みのハードウェアおよびソフトウェアスタック

コンポーネント	バージョン / 詳細
AMD GPU	Radeon RX 9060 XT（`gfx1200`、RDNA4） – 公式に検証済みの唯一のモデル
AMD HIP SDK	6.4（Windows）
ZLUDA	v6‑preview.69（公式リリース）
LibTorch	2.3.0 + cu118（約2.66 GB）
CUDAライブラリ	`nvcuda`、cuBLAS、cuBLASLt、cuSPARSE、cuFFT – すべて`cuda_check`を通過
cuDNN	ステーブルWindows HIP SDKでは利用不可

このリポジトリは他のAMD GPUを検証未確認候補として明示的にマークしており、成功・失敗を問わずGPU互換性に関する問題を報告することをユーザーに推奨している。

翻訳レイヤーの動作原理

CUDA対応Windowsアプリ
        │
      ZLUDA（PTX/JIT → HIP）
        │
  cuBLAS / cuSPARSE / cuFFT
        │
  rocBLAS / hipBLASLt / rocSPARSE
        │
      AMD GPU

ZLUDAはCUDAドライバ呼び出しを傍受し、PTXをJITコンパイルしてHIPに変換し、対応するROCmライブラリに処理を転送する。

インストール手順（Windows）

AMDの前提条件をインストール – 最新のAMD GPUドライバとWindows用AMD HIP SDK（HIPライブラリを含む）。参照環境ではHIP SDK 6.4を使用。最新リリースは動作する可能性があるが、検証済みではない。
リポジトリをクローンしてインストーラを実行：
```
git clone https://github.com/Speedstu/CUDA-for-AMD-Windows.git
cd CUDA-for-AMD-Windows
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1
```
インストーラはGPUを検出、ドライバ/HIPバージョンを検証し、ZLUDAとLibTorchをダウンロード、SHA‑256ハッシュをチェック、ランタイム設定ファイルを生成し、cuda_check.exeを実行する。
オプション – LibTorchのダウンロードを-SkipLibTorchでスキップ可能。翻訳レイヤーのみが必要な場合に有効。

CUDA対応プログラムの実行

# 必要なDLLを自動的にステージングして起動
.
scripts\run-zluda.ps1 -Program C:\path\to\app.exe

# 起動せずにランタイムをステージングする場合
.
scripts\stage-runtime.ps1 -TargetDir C:\path\to\your-app

スクリプトは実行ファイルの隣にZLUDA互換DLLを配置し、そのセッション内でのみHIP/ROCmランタイムパスを設定する。

環境の診断

.
scripts\doctor.ps1
.
scripts\gpu-scan.ps1
.
scripts\test-runtime.ps1

gpu-scan.ps1はGPUモデル、gfxアーキテクチャ、ドライババージョン、HIP SDK詳細を含むJSONレポートを出力する。例：

AMD Radeon RX 9060 XT -> gfx1200 -> RDNA4 -> validated-reference

検証済み設定でのランタイムカバレッジ

CUDA対応コンポーネント	状態
CUDAドライバ（`nvcuda`）	✅
cuBLAS	✅（rocBLAS経由）
cuBLASLt	✅（hipBLASLt経由）
cuSPARSE	✅（rocSPARSE経由）
cuFFT	✅
cuDNN	⚠️ 利用不可（ステーブルHIP SDKにMIOpenが欠如）

cuDNNが利用できないため、畳み込みを多く含むワークロードは、より新しい/ナイトリーHIPスタックまたはカスタムオーバーレイを必要とする可能性がある。

パフォーマンスのスナップショット

参照PPOワークロード上で制御されたA/Bベンチマーク（2026‑09‑13）の測定結果：

中央値全体のステップ/秒（SPS）：上流ZLUDAパスで13,278 vs. 歴史的カスタムオーバーレイで12,876。
相対的な遅延：カスタムオーバーレイは約3 %遅く、上流パスがデフォルト推奨。

過去の最適化済み実行（異なるトレーニング設定）では70k–109k SPSを報告しており、docs/BENCHMARKS.mdにドキュメント化されている。

オプションの歴史的カスタムオーバーレイ

このリポジトリには歴史的なカスタムcuBLAS/cuBLASLt/HIPオーバーレイが含まれているが、検証済みパスには不要。回復されたDLLハッシュはmanifests/recovered-artifacts.sha256に保存されている。オーバーレイは参考用に提供されているのみ。上流ZLUDAビルドはPPOベンチマークでこれを上回る性能を発揮している。

互換性またはバグの報告

診断スクリプト（gpu‑scan.ps1、test-runtime.ps1）を実行する。
提供されたテンプレートを使用してGPU互換性レポートのIssueを開き、JSON出力とエラーログを添付する。

プロジェクトメンテナは、成功・失敗を問わず報告を歓迎しており、互換性マトリクスの拡張を促進している。

リポジトリ構成（概要）

scripts/          # インストール、診断、ステージング、ランチャ
manifests/        # ピン止めバージョン、ハッシュ、GPUメタデータ
docs/             # 検証、ベンチマーク、トラブルシューティング
examples/         # 参照統合スニペット
.runtime/         # 生成された依存関係とレポート（git無視）
local-artifacts/  # アーカイブファイル（git無視）

注意すべき制限事項

GPUサポート：RX 9060 XT（gfx1200）のみが公式に検証済み。
CUDA完全性：ZLUDAは完全なCUDA APIを実装していない。サポートされていない機能にはCDNA固有の拡張、NCCL、TensorRT、多数のカスタムPTX命令が含まれる。
Windows ROCmエコシステム：ステーブルWindows HIP SDKにはAIスタック全体（例：MIOpen/cuDNN）が欠如しており、畳み込みを多く含むモデルの制限がある。
互換性価値：ZLUDA_CC=8.6はAMD GPUアーキテクチャではなく、CUDA互換性ターゲットを反映している。

ライセンス

プロジェクトのスクリプトおよびドキュメントはMITライセンス。ZLUDA、AMD ROCm/HIP、NVIDIA CUDAコンポーネント、PyTorch/LibTorchはそれぞれ上流ライセンスを保持。詳細はTHIRD_PARTY_NOTICES.mdを参照。

コミュニティの反応（Hacker Newsのハイライト）

オープンスタンダードの提唱：一部のコメントでは、このような取り組みがLLM推論における閉鎖的NVIDIAスタックの支配を背景に、HIP、SYCL、OpenCLなどのオープンAPIの必要性を強調している。
ハードウェア範囲に関する質問：ユーザーはこのセットアップが他のGPU（例：Radeon 7900 XT）やAI以外のワークロード（例：MATLAB）でも動作するかを尋ねている。
戦略的インパクト：一部のコメントでは、CUDAからHIPへの翻訳が容易になると、CUDAの独占的優位性が失われ、中間表現に過ぎなくなる可能性を示唆している。
実用的な注意点：他のコメントではcuDNNの欠如と、現在の上流リリースと比較して古いWindows ROCmバージョン（7.1/7.2）に依存している点を指摘している。

これらの議論は、ベンダー間互換性への関心と、現在の制限に対する現実的な期待を浮き彫りにしている。