AMDミニPCでローカルAI画像生成:ComfyUI + Z-Image Turbo

うちのミニPCは、テキストのプロンプトを約27秒で完成品の1024×1024画像にします。クラウドのアカウントなし、1枚ごとの課金なし、他人のプロンプト千件の後ろに並ぶ待ち行列もなし。しかもそれをやっているのは、「こういうのは無理」と思われがちなAMDのチップです。

できあがったもの

セットアップの話の前に、日常の使い勝手から。ブラウザのタブを開くか、ターミナルから叩くか。どちらでも:

項目	値
解像度	1024×1024
ステップ数 / CFG	8ステップ、CFG 1.0
温まった状態の生成時間	約27秒(実測レンジ:26.5〜30.4秒)
コールドスタート(起動後の1枚目)	約43.5秒。約20GBの重みの読み込み込み
1枚あたりのコスト	$0
必要なアカウント	なし
Wi-Fiを切っても動くか	はい

この箱での本当の用途は「芸術のための芸術」ではありません。チャットボットプロジェクト用のアバターのバリエーションを一括生成するスクリプトです。出力フォルダのPNGは222枚、今も増加中。退屈で確実なインフラ——遊びで作ったものに依存し始めたとき、いちばん欲しい性質です。

ハードウェア

128GBユニファイドメモリの箱です。AMD Ryzen AI Max+ 395(通称「Strix Halo」)、CPUと同じパッケージにRadeon 8060SのiGPU。ディスクリートGPUはどこにもありません。

肝心なのはここ。ファームウェアが128GBのうち64GiBを切り出して、iGPU専用の「VRAM」として渡します。ComfyUI自身の起動ログにもTotal VRAM 65536 MB, total RAM 63920 MBと出ます。コンシューマ向けNVIDIAカードのどれよりも多いVRAMですが、それはグラボに半田付けされた高価なGDDRではないから。ファームウェアがGPUに割り当てた、ただのシステムメモリです。しかも必要ならその後ろに、GPUから見える約31GBのGTTが控えています。

部品	スペック
CPU	AMD Ryzen AI Max+ 395、16コア/32スレッド
iGPU	Radeon 8060S、ROCmアーキテクチャはgfx1151
メモリ	128GBユニファイドLPDDR5X——64GiBをVRAMに切り出し、Linux側は約62GiB
OS	Bazzite(イミュータブル、Fedora Silverblueベース)
ディスクリートGPU	なし

このセットアップ全体のモデル重みは合計で約20.7GB。64GBの中なら余裕ですが、よくある8〜16GBのコンシューマカードでは、レイヤーをシステムRAMに退避して速度の代償を払わない限り絶望的です。

ソフトウェアスタック

これを動かしているバージョン一覧、現時点のインストールそのまま:

コンポーネント	バージョン
ComfyUI	v0.27.0(gitチェックアウト)
Python	3.12.13、uvで作ったvenv内
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は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はROCmに「このGPUはgfx1151だ」と教えます。ROCm 7.2では冗長(ログにすでに「native」と出る)ですが、お守りとして残しています。古いROCmビルドでは、この手のiGPUを動かすのにまさにこのオーバーライドが必須だったからです。
• PYTORCH_HIP_ALLOC_CONF=expandable_segments:Trueは、ユニファイドメモリ上でアロケータがVRAMを断片化させるのを止めます。これがないと、メモリは理屈の上ではたっぷり空いているのにout-of-memoryエラー、という目に遭えます。
• HIP_VISIBLE_DEVICES=0は唯一のGPUに固定するだけ。面白みはありませんが、いつかハードウェアを増やす日のために。

もうひとつ。サーバーの待ち受けアドレスは、起動スクリプト内で127.0.0.1にハードコードされています。設定のトグルではなく、直書きの値です。そこのコメントいわく「これがセキュリティモデルの全部」。実際その通りです。別の端末から使いたい?それは自分でリバースプロキシかVPNを立てる話であって、切り替えられるフラグにはわざとしてありません。

プロンプトが絵になるまで

ここが神秘的な工程だと思われがちですが、違います。ComfyUIが公式テンプレートから組み上げる、短くて固定のパイプラインです:

Z-Image Turboの設定

Z-Image Turboは、AlibabaのZ-Imageモデルの蒸留・高速版です(私の理解では同社のTongyi Lab発、約60億パラメータ、Apache-2.0)。ここでの「蒸留」には具体的な意味があります。古いモデルが欲しがる20〜30ステップ以上の代わりに、8ステップ・CFG 1.0で完成画像が出る、ということです。以下は私の保存済みワークフローの設定で、中身はただの公式テンプレートのデフォルト。探し当てるべき魔法の組み合わせはありません。

設定	値
ステップ数	8
CFG	1.0
サンプラー	res_multistep
スケジューラ	simple
ModelSamplingAuraFlowのshift	3
解像度	1024×1024
CLIPLoaderのtype	lumina2
ネガティブプロンプト	ゼロ化(ConditioningZeroOut)

最後の行は説明の価値があります。CFG 1.0では、ネガティブプロンプトには押し返す相手がいません。だからこのワークフローは、何もしないテキストをエンコードする代わりにConditioningZeroOutノードでゼロ化しています。気が済むならネガティブプロンプトを打っても構いません。画像は1ピクセルも変わりませんが。

実際に働いているファイルは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秒という計算になります。

サービスのコールドスタート後、最初の1枚は43.54秒かかりました。約20GBの重みをディスクから読むのがその回だからです。以降はずっと温まった状態。その日の1枚目がもっさりしていたら、理由はこれです。故障のサインではありません。

サービスとして動かす

画像が欲しくなるたびにターミナルでPythonプロセスの子守りはしたくないので、これはsystemdのユーザーユニットとして、ログインセッションと一緒に起動します:

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

envファイルには、ポートと追加の起動引数を編集しやすい1か所にまとめてあります。その上に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

comfyctl startが実際にやること:

プロセスが死ねばRestart=on-failureが5秒後に立て直します。毎分5回までで、そこを超えるとsystemdが匙を投げるので、本物のクラッシュループが永遠に空回りすることはありません。週次タイマーがgit pull --ff-onlyで更新を取り込み、サービスを再起動して、/system_statsを確認してから成功を名乗ります。このツールのデスクトップアイコンはモデル自身に生成させました。必要以上に気に入っています。

ヘッドレスでやる

Web UIは単発には十分ですが、ここでの日常はスクリプトです。標準ライブラリだけのPythonスクリプトがグラフをJSONで組み、POSTして、結果をポーリングし、完成したPNGのパスを出力します:

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

APIキーなし、レート制限なし、月末の請求なし。プロジェクト全体を「やってよかった」にしたのはこの部分です。箱の上の何からでも呼べる素のスクリプト——たとえば、新しいアバターが欲しいけれど、いちいち人間にお伺いを立てたくないチャットボットからでも。

ハマりどころ

• ログの「cuda:0」は正常です。ROCm版PyTorchはAMDのGPUをCUDAデバイスとして報告します。設定ミスではないし、こっそりNVIDIAカードを使っているわけでもありません。
• 再起動後の1枚目は遅い。重みの読み込みで約43秒、その後は約27秒に落ち着きます。セッションの途中で再起動して「壊れた!」と慌てないように。
• ここではネガティブプロンプトは無意味。CFG 1.0では設計上ゼロ化されます。変な画像のデバッグ中なら、ネガティブプロンプトは犯人ではありません。
• 「スマホからも見えるように」は簡単には開けません。待ち受けアドレスは意図的に127.0.0.1へハードコードされています。リモートアクセスは自前のリバースプロキシかVPNの話で、設定ファイルの編集では済みません。
• 毎週勝手に自分を更新します。便利です——便利じゃない週が来るまでは。fast-forward限定のpullで暗黙のマージは防げますが、上流の破壊的変更は、見ていない間にも着地しえます。
• 64GBは「たっぷり」に聞こえますが、積めば消えます。このワークフローの重みは約20.7GB。大きいモデルを何個も同時にロードしたり、横でGPU食いの何かを走らせたりすれば、余裕はあっという間になくなります。