Windows上のAMD向けCUDA

AMD GPU向けWindows用CUDA互換スタック

［画像: Windows］ ［画像: AMD Radeon］ ［画像: verify］ ［画像: License: MIT］

ZLUDA + AMD ROCm/HIP を中心とした、AMD GPU向けの再現可能なWindows用CUDA互換スタック。

AMDハードウェア上でCUDAターゲットのWindowsアプリケーションを実行し、作業が実際にGPUに到達していることを検証し、クラッシュ、タイムアウト、CPUフォールバック、またはサイレントに間違ったテンソルから正しい結果を区別します。

重要

このプロジェクトは完全なCUDA実装ではありません。サポートは機能とワークロード固有です。現在検証済みのリファレンスGPUはRadeon RX 9060 XT (gfx1200) です。

クイックスタート

1. AMDの前提条件をインストール

最新のAMD GPUドライバーとHIPライブラリ付きAMD HIP SDK for Windowsをインストールします。

必要なHIPバージョンはGPUアーキテクチャによって異なります。プロジェクトはmanifests/windows-gpu-profiles.jsonに記録されているアーキテクチャ固有の最小バージョンをチェックします。

2. クローンしてインストール

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環境を検証し、ピン留めされたアセットをダウンロードし、ランタイムをステージングし、ランタイムの簡単なテストを実行し、互換性のあるPython/PyTorch環境が利用可能な場合は数値チェックを実行します。

3. CUDAターゲットアプリケーションを実行

.\scripts\run-zluda.ps1 -Program C:\path\to\app.exe

4. ランタイムを検証

.\scripts\doctor.ps1
.\scripts\test-runtime.ps1
.\scripts\test-functional.ps1 -PythonExe C:\path\to\venv\Scripts\python.exe

元の低レベルセットアップパスは、既存のユーザーや古い投稿との互換性を保つために意図的に維持されています。

.\scripts\setup.ps1 -DownloadZluda -DownloadLibTorch

安定したユーザー向けコマンドとメンテナーツールについては、scripts/README.mdを参照してください。

PyTorchアテンションの安全性（安定版と最新版）

scripts/run-zluda.ps1 を介してCUDA対応PyTorchを起動します。ZLUDA v6安定版とv7最新版の両方で、デフォルトでmath-only SDPA（flash=False、mem_efficient=False、math=True）が有効になります。これにより、gfx1100/gfx1150で報告された有限だが間違った結果を返す融合アテンション出力が回避されます。これは安全な回避策であり、融合カーネルが機能することの証明ではありません。 -AllowUnsafeFusedSDPA は、分離された診断にのみ使用してください。

test-functional.ps1 は、生のカーネルを個別に意図的にプローブし、依然として incorrect と報告する可能性があります。zluda.exe を直接実行すると、Pythonの安全フックがバイパスされます。

現在のプリビルド zluda.exe は、スペースを含むプログラム引数も分割します。v7ソースパッチ候補がこれのために含まれています（#6）。これはgfx1200でビルドおよびテストされました。アップストリームのプリビルドランチャーは、修正が有効になる前にパッチを適用して再ビルドする必要があります。

ランチャーのargvパッチは、Radeon 890M / gfx1150でも独立して再ビルドおよびチェックされました（引数のラウンドトリップと複数単語のllama.cppプロンプトで3回のパス）。パッチはまだ分散バイナリに適用される必要があります。個別の zluda-launcher-candidate-build ワークフローは、候補のみのビルドを作成し、安定版/最新版の自動置換ではありません。

保守的なllama.cppの簡単なテストでは、デフォルトのコンテキストが、潜在的に巨大なモデルの最大値を継承するのではなく、-c を介して4096トークンに制限されます。意図的な大規模テストでオーバーライドするには -ContextSize を渡してください。その他の安全フラグは変更されていません。

リリース品質とリグレッション保護

ビルドがグリーンであることは、ハードウェアの正確性の証明ではありません。ZLUDAドライバー候補を一般使用に検討する前に、メンテナーは候補DLLのSHA-256を検証し、ソート、累積和、行列乗算、およびmath-only SDPAのCPU対GPU数値テストを実行する必要があります。フェイルクローズ、読み取り専用のプロモーションゲート（各プローブプロセスによって実際にロードされたDLLのSHA-256を含む）は、欠落、古い、または不一致のテストエビデンスを拒否します。コンパイルのみの成果物は実験的なままであり、既知の良好なランタイムは自動的に置き換えられません。

現在の互換性

完全な詳細、バージョンフロア、エビデンスレベル、既知の制限、およびCUDA DLL → AMDバックエンドマップについては、docs/COMPATIBILITY.mdを参照してください。

何が検証されたか？

安定した公開リファレンスパス

公開リファレンスパスは、ピン留めされたアップストリームコンポーネントを使用し、以下でテストされています。

• ZLUDA v6-preview.69
• AMD HIP SDK 6.4
• LibTorch 2.3.0 + cu118
• Radeon RX 9060 XT / gfx1200
• CUDA対応ドライバーローディング、cuBLAS、cuBLASLt、cuSPARSE、cuFFTの簡単なカバレッジ
• 数値的なCPU対GPUの正確性プローブ
• 実際の2,216,347パラメータPPOワークロード
• 65,536タイムステップのクリーンな検証イテレーション

docs/VALIDATION.mdを参照してください。

実験的なv7パス

リポジトリは、新しいCUDA対応動作のために、ソースベースのZLUDA v7-preview.10 パッチシリーズも維持しています。

リファレンスマシンでの検証作業には、以下のような領域が含まれます。

• CUDA Graph互換性
• ドライバーメタデータと起動プローブ
• cuFFTおよびcuSPARSEパス
• NVML互換性
• 実験的なcuSOLVER → hipSOLVERブリッジ
• リファレンスgfx1200システムでの実験的なcuDNN v8 → MIOpenブリッジ（順方向/逆方向畳み込み）
• 安全でない融合SDPAフォールバックのフェイルクローズ処理
• 最新のllama.cpp登録とGPU実行

パッチセットは安定版インストーラーとは別にされているため、実験的な作業が安定版パスをサイレントに再定義することはありません。

patches/zluda-v7-preview10/README.mdを参照してください。

実アプリケーションのチェック

このプロジェクトは、意図的に小さなAPI呼び出し以上のものをテストします。

PyTorch / LibTorch / PPO

リファレンスワークロードは、CUDA対応デバイスを通じてロールアウト、順方向、逆方向、PPO学習、およびオプティマイザの処理を実行します。

docs/VALIDATION.mdおよびdocs/BENCHMARKS.mdを参照してください。

llama.cpp

最近のllama.cpp b10978 ビルドが、RX 9060 XT実験的v7パスでエンドツーエンドのGPU簡単なテストを完了しました。

• AMD GPUがZLUDA経由でCUDA0として公開
• 6/6モデルレイヤーがオフロード
• KVキャッシュがGPU上
• コンピュートバッファがGPU上
• CUDA Graphウォームアップに到達
• プロンプト処理と生成が完了
• クリーンなプロセス終了、複数回再現

これはテストされたパスのエビデンスであり、すべてのllama.cppカーネルまたはモデルがサポートされているという主張ではありません。

docs/LLAMA_CPP.mdを参照してください。

実験的なcuDNNフェーズ1、gfx1200ハードウェア結果

狭いソースビルドのcuDNN v8 → MIOpenブリッジ（60のエクスポートオーバーライド）が、16/16の実際のRX 9060 XTダイレクトHIP FP32/FP16数値チェックを完了しました。これには、アクティベーション、正確なチャネルソフトマックス、制限付き最大プーリング、およびストライド付きテンソル操作が含まれます。FP16ホストスカラーABIは、実際のハードウェアでサイレントに間違った出力ケースが検出された後に修正されました。これは完全なcuDNN、cuDNN v9、またはPyTorch CUDAアプリケーションのサポートではありません。フェーズ1チェックリストを参照してください（phase 1 checklist）。

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

パフォーマンスの主張は、可能な限り同じGPUで再現可能に保たれています。これはAMD対NVIDIAのベンチマークではありません。

実験的なv7/TheRockパスでは、クリーンな4ペアFP32 SGEMM検証により、ダイレクトHIP/rocBLASに対するペアの中央値オーバーヘッドが1024²で+1.79%、2048²で+0.45%、4096²で+2.20%と測定されました。対応するスループット比は98.2%、99.6%、97.8%でした。

実際のVelocityRL 512 agents × rollout 16 の簡単なテストでは、初回コンパイルと定常状態が分離されました。ウォームアップ後の更新は、72,306 SPSおよび70,333 SPSに達し、71,319.5 SPSの中央値定常状態となりました。

方法論と生の結果については、docs/BENCHMARKS.mdおよびbenchmarks/を参照してください。

正確性第一

CUDA APIが成功を返しただけでは、サポートされているとは言えません。

テストスイートは以下を区別します。

PASS · UNSUPPORTED · INCORRECT · TIMEOUT · ERROR · プロセス失敗

プロジェクトはフェイルクローズルールに従っています。明示的な未サポートの結果は、もっともらしく見えるが不正確なテンソルよりも優れています。

このポリシーにより、明確に失敗するのではなく、数値的に間違った出力を返す可能性のある融合SDPAフォールバックパスが既に検出されています。

エビデンスモデルと貢献ルールについては、CONTRIBUTING.mdを参照してください。

プロジェクトマップ

生成されたランタイムファイルは .runtime/ 以下に保持され、Gitからは無視されます。

ドキュメント

リポジトリ内を検索する代わりに、docs/README.mdから始めてください。

• 互換性とサポートレベル
• 検証方法論とエビデンス
• アーキテクチャ
• ベンチマーク
• llama.cpp検証
• RX 9070 XT外部検証
• トラブルシューティング
• 実験的なv7パッチセット
• 実験的なcuSOLVERプロキシ
• 実験的なcuDNN v8 → MIOpen畳み込みブリッジ

歴史的再構築資料は引き続き保存されていますが、推奨パスの一部ではなくなりました。

バグを見つけたか、他のGPUをテストしましたか？

成功したレポートと失敗したレポートの両方が役立ちます。

.\scripts\gpu-scan.ps1 -OutputPath .\gpu-report.json
.\scripts\test-runtime.ps1
.\scripts\test-functional.ps1 -PythonExe C:\path\to\venv\Scripts\python.exe

その後、GPU互換性レポートを開いてください。

GPUモデル、gfxXXXXターゲット、ドライバー、HIPバージョン、ZLUDAチャンネル/ビルド、正確なワークロード、およびAMD/ZLUDAデバイスがCPUにフォールバックせずに実際に作業を実行した証拠を含めてください。

既知の制限事項

• ZLUDAはCUDAエコシステム全体を実装しているわけではありません。
• cuda_check またはデバイス検出を渡すだけでは、数値的な正確性は確立されません。
• Windowsは、完全なROCmエコシステムの一部のみを公開します。
• 検証済みの安定したWindows HIPパスは、完全なcuDNN/MIOpen相当のスタックを提供しません。個別の実験的なv7ブリッジは、gfx1200で狭いcuDNN v8 2D順方向+逆方向データ+逆方向フィルタサブセットを検証します。ドキュメント/CUDNN_BRIDGE.mdを参照してください。
• NCCL、TensorRT、未サポートのPTX動作、カスタムCUDA拡張機能、およびアーキテクチャ固有のカーネルは失敗する可能性があります。
• 融合Flash/メモリ効率の良いSDPAパスはNVIDIA cubinに依存する可能性があり、安全でないフォールバックは正しいと見なされるのではなく、未サポートとして扱われます。
• ZLUDA_CC=8.6は、ネイティブAMD GPUアーキテクチャではなく、CUDA対応の互換性値です。

詳細については、docs/COMPATIBILITY.mdを参照してください。

ディープラーニング互換性の作業進行中：フェーズ1リリースと正確性チェックリスト。

貢献

プロジェクトはエビデンス駆動型です。新しい互換性の主張には、焦点を絞った再現器、該当する場合は数値検証、正確なバージョン/ハッシュ、および可能な場合は実際のワークロードを含める必要があります。

サポート主張を変更したり、実験的なパッチをプロモートしたりする前に、CONTRIBUTING.mdをお読みください。

ライセンス

プロジェクト所有のスクリプトとドキュメントはMITライセンスです。

ZLUDA、AMD ROCm/HIP、NVIDIA CUDAコンポーネント、PyTorch/LibTorch、およびその他のサードパーティプロジェクトは、独自のライセンスを保持します。THIRD_PARTY_NOTICES.mdを参照してください。llama.cpp / gfx1150 issue #6: 新しいピン留めされた安全ビルド候補は、既存のMMVF/cuBLASフォールバックを通じて、欠落しているF32 mul_mat_f スペシャライゼーションを回避します。これは ZLUDA_CC=8.6 および F16/BF16 MMF は変更しません。Radeon 890Mのコミュニティテスターは、以前失敗した6つのモデルすべてで3/3回の実行を確認しました。ネイティブ回答の比較は4Bモデルでのみチェックされました。F32 MMF候補を参照してください（F32 MMF candidate）。これは、推測的なtop-kまたはNemotronコピーの誤りを解決するものではありません。