Radeon 780MのComfyUIをZLUDAからTheRockへ移行する

shino

780mcomfyuiimage-generation

青緑色に光る画面の横に並ぶ基板とケーブル

以前書いたZLUDAでの構成は動いていましたが、そこまでたどり着くのに8つの個別対応が要りました。ロケールの問題から、ZLUDAが差し込んだDLLを止めるセキュリティ層、HIP SDKのバージョンを変える羽目になったrocBLASのカーネルのバグまで、いろいろありました。AMD自身のツール側もようやく追いついてきています。TheRockはAMD自身が作り直しているROCmのビルド・リリースパイプラインで、まだプレビュー段階ですが、gfx1103を正式なビルド対象にしたナイトリー版のPyTorchホイールを配布するようになりました。

TheRockを入れる

Windows向けのネイティブインストーラーはまだありませんが、pipのインデックスがそのまま使えます。

pip install --index-url https://rocm.nightlies.amd.com/whl-multi-arch/ \
    "torch[device-gfx1103]" "torchvision[device-gfx1103]" torchaudio

インストール直後から、torchは正しいデバイスを認識しています。

torch version: 2.12.0+rocm7.15.0a20260728
hip available: True
device name: AMD Radeon 780M Graphics

4096×4096のfp16行列積を20回まわして1.3秒でした。ZLUDAでは「unable to find an engine to execute this computation」でクラッシュしていたConv2d演算も、いまは警告(MIOpen: CK grouped conv library not found for device gfx1103)を出すだけで先に進みます。どちらもComfyUIが本番で使うコードパスをそのまま通したチェックです。

TheRockでは要らなくなったもの

  1. **DLLの差し込みが要らない。**ZLUDAはWindows Defenderの除外設定と、元に戻すのにWindowsの再インストールが要る片道切符のSmart App Controlのオフ化が必要でした。TheRockはただのPyTorchホイールなので、どちらの問題も出てきません。

  2. **CLIPがGPUで動く。**ZLUDAの構成では、アクセス違反クラッシュを避けるためにCLIPのテキストエンコーダーを常にCPUに固定するパッチが必要でした。起動ログを見るとその違いがはっきり出ています。

    ZLUDA:   CLIP/text encoder model load device: cpu
TheRock: CLIP/text encoder model load device: cuda:0

  3. **cuDNNの手動パッチが要らない。**ZLUDAの構成ではzluda.pyを直接書き換えてtorch.backends.cudnn.enabled = Falseをグローバルに設定する必要がありました。このComfyUIはAMDのGPUを検知すると自動で同じことをします。起動ログにそのまま出ています。

    Set: torch.backends.cudnn.enabled = False for better AMD performance

チューニング: アテンションアルゴリズムの選択

デフォルトのままだと、TheRockのアテンションアルゴリズム(サブクアドラティック)はSD1.5でZLUDAに勝ち、SDXLでは負けました。--use-pytorch-cross-attentionを足すとその結果が逆転し、両方のモデルサイズでおおよそ倍近い速度になりました。

テストZLUDATheRock(デフォルト)TheRock(cross-attention)
SD 1.5、512×512、20ステップ1.11-1.22 it/s(26.6-27.3秒)1.25 it/s(24.1秒)2.44 it/s(12.6秒)
SDXL、1024×1024、20ステップ4.63 s/it(110.3-112.2秒)5.16 s/it(135.5秒)2.86 s/it(77.9秒)

チェックポイントがすでにメモリに載っているウォーム状態だと、さらに安定します。SDXLは繰り返し実行しても2.82-2.95 s/itのあたりに収まりました。--use-split-cross-attentionも試しましたが、デフォルトとの差は誤差の範囲でした。

逆効果だったこと

ZLUDAのチューニングからそのまま持ち込んだ--disable-async-offloadと--disable-pinned-memoryは、同じように効くだろうと思っていましたが、SDXLが77.9秒から98.25秒に伸びました。ZLUDAの変換層は非同期オフロードとピン留めメモリの扱いに難があり、そこを切るのは意味のある対処でした。TheRockのネイティブなHIPドライバはどちらもデフォルトで正しく処理するので、ここで切るとただ有効な最適化を捨てるだけです。元に戻しました。

結果

ZLUDAは引退させました。いまはTheRockがポート8188のデフォルトです。コアの外で保守されているカスタムノード、ComfyUI-Managerは手作業で移行しました。ZLUDA専用だったcuDNN回避のカスタムノードも、もう要らないので削除しました。

同じパソコン上でOllamaとGPUを共有するテストもしました。合計14.8GBのVRAMプールを両方で分け合う形です。ComfyUI側に--reserve-vram 6を設定した状態で、SDXLの生成とOllamaのチャットリクエストを同時に走らせても、クラッシュせずに終わりました。SDXL側の速度もほとんど落ちず、2.87-2.97 s/itと単独実行時と同じ範囲でした。

(追記: この同じOllama環境は、のちにローカルのコード生成ループを動かし、さらにその後本格的なコーディングエージェントのハーネスも動かすことになりました。この同じComfyUI-TheRock環境は、のちにGGUF量子化で20B級の画像モデルも動かすことになりました。)

残っている課題

TheRockのgfx1103対応は、AMDが公式に動作確認済みとしているチップの一覧にはまだ入っていません。ナイトリービルドなので、不安定さはその前提の一部です。

知っておく価値のある穴が2つあります。ComfyUIのVAE decodeがgfx1103でcuDNN絡みでクラッシュする件は既知のissueで、開いたままです。ここでは再現しませんでした。ComfyUIが自動でcuDNNを無効化する処理が、この問題を避けているのだと思います。根本的な穴自体は残っています。MIOpenにはgfx1103向けのComposable Kernelベースの畳み込みカーネルがまだありません。sage-attentionやflash-attentionのビルドがこのチップでまだ使えないのも、どちらもCKに依存しているのが理由です。

ZLUDAの記事のときと同じ注意点です。この構成全体がナイトリーで、非公式に近いものです。個人のパソコンで使う分には問題ありません。何か大事なものの近くでは動かしたくありません。