AMD（ROCm）上でのローカルAI画像生成：ComfyUI＋Z-Image Turbo

更新情報：2026年9月16日。現在は自分のPC上でこのComfyUIのセットアップを動かしていません。普段の画像生成は遠隔にあるGPUマシンを利用して行っています。ただし、ご自身のAMDマシン上で同様の設定を試したい場合でも、以下の手順は変更されておらず問題なく使えます。

私のAMDマシンでは、テキストプロンプトから1024×1024サイズの画像が約27秒で生成されます。クラウドアカウントも不要で、画像1枚ごとに料金がかかることもなく、他のユーザーのリクエストが多数並ぶような待機列も存在しません。しかもこれは、多くの人が「到底無理だ」と思っているAMDチップなのです。

最終的に得られるもの

設定に関する説明は後回しにしても構いません。普段はブラウザのタブを開くか、端末からコマンドを実行します。どちらの方法でも以下のような結果が得られます：

項目	値
解像度	1024×1024
ステップ数／CFG	8ステップ、CFG 1.0
ウォームアップ時の生成時間	約27秒（測定範囲：26.5～30.4秒）
コールドスタート時（起動後最初の画像生成）	約43.5秒。この間に約20GB分の重みデータが読み込まれます

このマシンでの実際の用途は、単なるアート制作ではありません。実際には自己ホスト型チャットアプリ用に、アバターのバリエーションを一括生成するスクリプトとして利用しています。現在までに出力フォルダ内には222個のPNG画像が生成されており、その数は増え続けています。つまり、単なる遊びで作ったものですが、今では頼りにしている堅実で信頼性の高いインフラというわけです。

ハードウェアについて

これは128GBのユニファイドメモリを備えたマシンです。AMD Ryzen AI Max+ 395（「Strix Halo」）というCPUであり、そのパッケージ内にはRadeon 8060SというiGPUも搭載されています。これは私が以前ホームラボ記事で紹介したASUS ROG Flow Z13なのですが、電源トラブルにより使用不能になってしまいました。ディスクリートGPUは一切搭載されていません。

ここが重要な点です。ファームウェアによって128GBのうち64 GiBが切り出され、iGPU用の「VRAM」として割り当てられます。ComfyUIの起動ログにはTotal VRAM 65536 MB, total RAM 63920 MBと記録されています。これは市販されているどのNVIDIA製グラフィックカードよりも多くのVRAM量です。なぜなら、これは高価なGDDRメモリが搭載されたグラフィックカードではなく、単にファームウェアによってGPU用に割り当てられたシステムメモリだからです。さらに必要であれば、約31GBのGTT領域もGPUから利用可能となります。

コンポーネント	仕様
CPU	AMD Ryzen AI Max+ 395、16コア／32スレッド
iGPU	Radeon 8060S、ROCmアーキテクチャ gfx1151
メモリ	128GBのユニファイド LPDDR5X — 64GiBがVRAMとして割り当てられ、残り約62GiBがLinux用に使用可能
OS	Bazzite（不変型で、Fedora SilverblueをベースとしたOS）
ディスクリートGPU	なし

この構成全体で使用されるモデルの重みデータの合計量は約20.7GBです。64GBものVRAMがあれば問題なく処理可能ですが、一般的な8～16GB程度の消費者向けグラフィックカードでは到底無理で、やむを得ずレイヤーをシステムRAMにオフロードする必要があり、その場合は処理速度が大幅に低下してしまいます。

ソフトウェアスタック

現在インストールされている、この環境を動作させるためのバージョンは以下の通りです：

コンポーネント	バージョン
ComfyUI	v0.27.0（gitチェックアウト版）
Python	3.12.13。uvを用いて作成された仮想環境内にインストール済み
PyTorch	2.12.1+rocm7.2
torchvision	0.27.1+rocm7.2
torchaudio	2.11.0+rocm7.2
pytorch-triton-rocm	3.5.1
ROCm	7.2。gfx1151をネイティブにサポート

面白い点として、ROCm用にビルドされたPyTorchはNVIDIAのCUDAであるかのように振る舞います。起動ログには実際に「Device: cuda:0 AMD Radeon 8060S : native」と記載されています。NVIDIA向けに書かれたPythonコードも、まるでNVIDIAカードと通信しているかのようにそのまま実行されるのです。またComfyUIもこのハードウェア上では自動的にcuDNNを無効化し、通常のPyTorchアテンション処理に切り替えます（xformersやflash-attnは使用されません）。それでも問題なく動作します。

ROCmを正常に動作させる方法

設定上の問題は、起動スクリプト内にあるいくつかの環境変数に起因します：

HSA_OVERRIDE_GFX_VERSION=11.5.1
PYTORCH_HIP_ALLOC_CONF=expandable_segments:True
HIP_VISIBLE_DEVICES=0

• HSA_OVERRIDE_GFX_VERSION は、GPUがgfx1151であることをROCmに伝えます。ROCm 7.2では実際には不要です（ログにも「ネイティブ」と記載されています）が、念のため設定しておきます。というのも、古いバージョンのROCmでは、このようなiGPUが正常に動作するためにはこのオーバーライドが必須だったからです。
• PYTORCH_HIP_ALLOC_CONF=expandable_segments:True は、ユニファイドメモリ上でVRAMが断片化するのを防ぎます。これを設定しないと、実際には十分なメモリが空いているにもかかわらずメモリ不足エラーが発生することがあります。
• HIP_VISIBLE_DEVICES=0 は、使用するGPUを1つに固定します。特別な機能ではありませんが、将来的にハードウェアを追加する際に役立ちます。

もう一つ重要な点として、サーバーのリスンアドレスは起動スクリプト内で 127.0.0.1 に固定されています。これは設定オプションではなく、ハードコーディングされた値です。そこにあるコメントでは「セキュリティモデル全体」と記述されており、まさにその通りです。他のデバイスからアクセス可能にしたい場合は、ご自身でリバースプロキシやVPNを用意する必要があります。つまり、簡単に切り替えられるフラグなどは用意されていないのです。

プロンプトが画像になるまでの流れ

この工程は神秘的に思われがちですが、実際はそうではありません。ComfyUIでは、公式テンプレートをもとにして、短く固定された処理パイプラインが構成されています。

Z-Image Turboの設定について

Z-Image Turboは、アリババ社が開発したZ-Imageモデルの高速版です（私の理解ではTongyi Labから公開されており、パラメータ数は約60億で、ライセンスはApache-2.0です）。「高速版」というのは具体的にはこういうことです：ステップ数が8回、CFG値が1.0であれば画像が完成します。これに対し、従来のモデルでは20～30回以上のステップが必要でした。以下に記載するのは私が保存しておいたワークフローの設定内容であり、公式のデフォルト設定そのものです。特別な組み合わせを探す必要はありません。

設定項目	値
ステップ数	8
CFG	1.0
サンプラー	res_multistep
スケジューラー	simple
ModelSamplingAuraFlow shift	3
解像度	1024×1024
CLIPLoaderの種類	lumina2
ネガティブプロンプト	ゼロ化済み（ConditioningZeroOut）

最後の項目について説明します：CFG値が1.0の場合、ネガティブプロンプトが作用する対象が存在しないため、実際には何もしないテキストをエンコードする代わりにConditioningZeroOutノードを用いてネガティブプロンプトをゼロ化しています。安心感を得たい場合はネガティブプロンプトを入力しても構いませんが、画像には何の影響もありません。

実際に処理を行っているのは以下の3つのファイルです：

ファイル名	サイズ	役割
z_image_turbo_bf16.safetensors	12.3GB	拡散型トランスフォーマーモデル（bf16形式）
qwen_3_4b.safetensors	8.0GB	テキストエンコーダー
ae.safetensors	0.34GB	VAE

測定されたパフォーマンス

これらはリリース告知ブログに記載されている数値ではなく、このマシン上で記録された実際のデータです。20回連続してプロンプトを送信した際の実行時間は26.62秒から30.41秒の範囲であり、「約27秒」というのは単調で再現性のある平均値に過ぎます。最良のケースだけを選び出した数値ではありません。テキストのエンコードやVAEデコードの処理も含めると、1サンプリングステップあたりおよそ2.5秒から3秒程度になる計算です。

サービスを再起動した直後に生成された最初の画像には43.54秒かかりました。これは約20GB分の重みデータがディスクから読み込まれる処理を行ったためです。それ以降の画像生成はすべて「ウォーム状態」となります。もし一日の最初に生成した画像が遅く感じられたとしても、それは何か問題があるというサインではなく、このためなのです。

サービスとして実行する方法

画像が必要なたびに端末でPythonプロセスを手動で起動したくないため、このプログラムはsystemdのユーザーユニットとして動作し、ログインセッションと同時に開始されるようにしています。

ExecStart=%h/comfy/start-comfyui.sh
WorkingDirectory=%h/comfy/ComfyUI
EnvironmentFile=-%h/comfy/comfy.env
Restart=on-failure
RestartSec=5
TimeoutStartSec=120

環境設定ファイルにはポート番号や追加の起動引数が記載されており、一箇所で簡単に編集できます。さらに、comfyctlという小さなラッパープログラムも用意されているため、日常的な利用方法は以下の通りです。

comfyctl start      # starts the service, waits for it to answer, opens the workflow
comfyctl status     # server health + unit state + newest output file
comfyctl generate "a foggy harbor at dawn, cinematic"
comfyctl stop
comfyctl logs

万が一プロセスが停止してしまっても、Restart=on-failureの設定により5秒後に自動的に再起動されます。1分間に最大5回まで再起動が試みられ、それでもダメな場合はsystemdが処理を打ち切ります（そうすることで、本当にクラッシュし続ける事態を防げます）。また、毎週定時にgit pull --ff-onlyを実行して更新情報を取得し、サービスを再起動した上で/system_statsの内容も確認してから正常終了とみなします。このアプリケーション用のデスクトップアイコンはモデル自体が生成したものですが、個人的には思った以上に気に入っています。

ヘッドレスモードでの利用方法

ウェブUIは一度きりの利用には問題ありませんが、日常的に使う場合はスクリプトを使用します。標準ライブラリのみを使ったPythonスクリプトがグラフをJSON形式で作成し、それを送信した後、処理結果を確認して完成したPNGファイルのパスを出力します。

python3 ~/comfy/comfy-generate.py "a foggy harbor at dawn, cinematic" \
  --steps 8 --width 1024 --height 1024 --out ~/Pictures/harbor.png

HTTP APIや制御用スクリプト、さらに他のデバイスからの安全なリモートアクセスについては、別途詳しく解説しています：ヘッドレスComfyUI：サービスとして実行し、どこからでも利用する方法。

注意点

• ログに「cuda:0」と出ても問題ありません。 ROCm版のPyTorchでは、AMD製GPUがCUDAデバイスとして認識されます。これは設定ミスではなく、NVIDIA製カードが使われているわけでもありません。
• 再起動後の最初の画像生成処理は遅いです。 重みデータの読み込み中は約43秒かかりますが、その後は約27秒程度に落ち着きます。セッション中に再起動して「何かおかしい」と慌てないでください。
• ここではネガティブプロンプトは効果がありません。 CFG値が1.0の場合、仕様上ネガティブプロンプトは無効化されます。生成結果が悪い場合でも、問題の原因はネガティブプロンプトにはありません。
• スマートフォンから直接アクセスすることはできません。 リスニング用アドレスは意図的に127.0.0.1に固定されています。外部からのアクセスを許可するには、自分でリバースプロキシやVPNを設定する必要があり、設定ファイルを編集するだけでは不十分です。
• 毎週自動的に更新されます。 便利な仕組みですが、その更新が行われない週もあり得ます。強制的に最新版へ更新する処理により不意なマージは防がれますが、見ていない間に互換性を損なうような変更が上流から反映される可能性も残ります。
• 64GBといっても、たくさんのモデルを読み込むとすぐに足りなくなります。 このワークフローでは約20.7GB分の重みデータが使用されます。複数の大型モデルを同時に読み込んだり、他のGPU負荷の高い処理を並行して実行したりすると、余裕容量はあっという間になくなってしまいます。

関連記事：ヘッドレス版ComfyUI：サービスとして実行し、どこからでも利用する方法 · ASUS ROG Flow Z13：持ち運び可能なホームラボとして使ったものの、結局はそうならなかった · DisPatch：ローカルで動作するAIエージェント用の自己ホスト型チャットアプリ · StudioForge：LM Studioに代わるGPU専用LLMサーバー