EVO-X2 (Ryzen AI Max+ 395 / gfx1151) で FLUX.2 dev を動かす — ROCm / TheRock / ComfyUI 検証記録

Last updated at 2026-03-30Posted at 2026-03-29

本記事の内容は 2026年3月末時点のものです。 カーネル、ROCm、ComfyUI のアップデートにより状況が変わる可能性があります。

EVO-X2でFLUX.2の画像生成に挑戦しました。ROCmまわりで苦労しました。

（とりあえずグラビア風アップしておけばクリック稼げるかな？って下心ｗ）

対象読者

GMKtec EVO-X2 や ASUS NUC など Strix Halo (Ryzen AI Max+ 395 / gfx1151) 搭載マシンを持っている
FLUX.2 dev をローカルで動かしたいが、ROCm の公式サポート外で情報が少なくて困っている
NVIDIA 環境向けのガイドが使えず、gfx1151 固有の問題に直面している

はじめに

GMKtec EVO-X2 は AMD Ryzen AI Max+ 395 (Strix Halo) を搭載したミニPC。統合GPU (gfx1151, RDNA 3.5) に VRAM 64GB（最大96GB）を割り当てられるため、FLUX.2 dev のような大規模な画像生成モデルもローカルで動かせる——理論上は。

実際にやってみると、以下の壁が立ちはだかる。

ROCm が gfx1151 を公式サポートしていない。 公式リリースには含まれず、TheRock nightly ビルドを使う必要がある
FP8 演算ができない。 FLUX.2 の標準的な FP8 safetensors モデルはロードした瞬間に Segfault
BF16 フル精度はメモリに載らない。 61GB のモデルファイルを 62GB の CPU RAM に mmap するのは現実的ではない
ネット上のガイドがほぼ MI300X か RDNA 3 前提。 gfx1151 固有の問題には触れていない

この記事では、試行錯誤の結果たどり着いた動作する構成と、やってはいけない構成を網羅的にまとめた。同じハードウェアで FLUX.2 を動かしたい人が、同じ轍を踏まずに済むことを目指している。

この記事の範囲: テキストから画像を生成する基本ワークフローまで。LoRA の適用など第2弾以降で扱う。

環境情報

ハードウェア

項目	スペック
マシン	GMKtec EVO-X2
CPU/GPU	AMD Ryzen AI Max+ 395 with Radeon 8060S
GPU アーキテクチャ	gfx1151 (RDNA 3.5)
搭載メモリ	128 GB（CPU と GPU で共有）
BIOS VGM 設定	64 GB

VGM（Video Graphics Memory）について。 筆者環境では 64GB が安定する唯一の設定だった。96GB にすると CPU RAM が約30GB に減り、テキストエンコーダのロードで OOM Kill が発生した。逆に小さくして GRUB の GTT パラメータで補おうとすると、モデルが低速メモリパスに配置されてハングした。2026年3月末時点では、64GB 以外の選択肢を見つけられていない。

ソフトウェア

項目	バージョン
OS	Ubuntu 25.10 (Questing Quokka) Server
カーネル	6.18.20-061820-generic（Mainline PPA）
Python	3.13.7
ROCm	7.13.0a（TheRock nightly, pip wheel）
PyTorch	2.10.0+rocm7.13.0a
Triton	3.6.0+rocm7.13.0a
ComfyUI	最新版 + ComfyUI-GGUF カスタムノード

なぜ Ubuntu 25.10 + kernel 6.18 なのか。 kernel 6.14（Ubuntu 24.04 OEM）では複数モデルを使うワークフローで SDMA/SVM 起因のクラッシュが発生していた。kernel 6.18 でこれが解消され、HSA_USE_SVM=0 の環境変数ハックも不要になった。基本的な単一モデル生成は 6.14 でも動くが、安定性を考えると 6.18 にしておくメリットは大きい。

なぜ TheRock nightly なのか。 gfx1151 は ROCm の公式リリースに含まれていない。AMD が開発中の TheRock ビルドシステムの nightly wheel には gfx1151 サポートが入っており、pip install だけで使える。システムレベルの ROCm インストールは不要。

TheRock nightly のインストール例

# Python 3.13 の venv を作成
python3.13 -m venv ~/rocm-therock-25
source ~/rocm-therock-25/bin/activate

# TheRock nightly wheel のインストール（gfx1151 対応）
# ※ URL は変更される可能性あり。最新は https://github.com/ROCm/TheRock を参照
pip install --pre torch torchvision torchaudio \
    --index-url https://download.pytorch.org/whl/nightly/rocm7.1

⚠️ 上記の URL は 2026年3月末時点のもの。TheRock は nightly のため、URL やバージョン体系が変わることがある。公式リポジトリで最新の手順を確認してほしい。

ComfyUI + ComfyUI-GGUF の導入

# ComfyUI 本体
git clone https://github.com/comfyanonymous/ComfyUI.git ~/ComfyUI
cd ~/ComfyUI
pip install -r requirements.txt

# ComfyUI-GGUF カスタムノード（GGUF モデル読み込みに必須）
cd ~/ComfyUI/custom_nodes
git clone https://github.com/city96/ComfyUI-GGUF.git
cd ComfyUI-GGUF
pip install -r requirements.txt

gfx1151 の既知の制約（2026年3月末時点）

ソフトウェアでは回避できないハードウェア／ドライバレベルの制約：

FP8 演算不可 — PyTorch の torch._scaled_mm は CDNA3（MI300 以降）専用。gfx1151 では対応していない
64GB 超の mmap が不安定 — ROCm のバグで、大きなファイルの mmap がハングまたは極端に遅くなる
Flash Attention が効かない — AOTriton の experimental フラグを有効にしても、少なくとも筆者環境では FLUX.2 推論の速度改善はゼロだった。むしろ MEMORY_APERTURE_VIOLATION でクラッシュするリスクがある
Q5_K GGUF がクラッシュする — Q5_K の dequantization で使われるビットシフト演算が gfx1151 で不安定。Q8_0 なら安定

動作する構成

使用するモデルファイル

役割	ファイル名	サイズ	配置先
拡散モデル	`flux2-dev-Q8_0.gguf`	35 GB	`models/diffusion_models/`
テキストエンコーダ	`mistral_3_small_flux2_fp8.safetensors`	17 GB	`models/text_encoders/`
VAE	`flux2-vae.safetensors`	321 MB	`models/vae/`

配置先は ~/ComfyUI/ からの相対パス。

ℹ️ FLUX.2 dev のテキストエンコーダは Mistral ベース（17GB）。FLUX.1 で使われていた T5XXL + CLIP_L の構成とは異なる。CLIPLoader ノードのタイプは flux2 を選択すること。

⚠️ VAE は flux2-vae.safetensors（FLUX.2 用）を使うこと。FLUX.1 用の ae.safetensors を使うと 16ch/128ch のチャンネル不一致エラーになる。

起動スクリプト（コピペ可）

#!/bin/bash
# FLUX.2 dev on EVO-X2 (gfx1151) — 2026-03-29 検証済み安定構成

source ~/rocm-therock-25/bin/activate

export HIP_VISIBLE_DEVICES=0
export TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL=1

cd ~/ComfyUI
python main.py \
    --listen 0.0.0.0 \
    --port 8190 \
    --disable-mmap \
    --bf16-vae \
    --cache-none

各オプションの意味

オプション	役割	外すとどうなるか
`--disable-mmap`	Strix Halo では必須。 ROCm の mmap バグを回避	モデルロードがハングまたは極端に遅くなる
`--bf16-vae`	VAE を BF16 精度で実行	—
`--cache-none`	VRAM 上のモデルキャッシュを無効化	複数モデルワークフローで VRAM 不足クラッシュ
`HIP_VISIBLE_DEVICES=0`	GPU デバイス指定	—
`TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL=1`	AOTriton 有効化（experimental）	FLUX.2 への速度効果は確認できなかったが、他のワークロードで効く可能性あり

ComfyUI ワークフローの組み方

起動スクリプトで ComfyUI を起動したら、ブラウザで http://<EVO-X2のIP>:8190 にアクセスする。以下の手順でワークフローを組む。

ノードの配置

ワークスペース上でダブルクリック（またはノード検索）して、以下の 8つのノード を配置する。

Unet Loader (GGUF) — ダブルクリックで「gguf」と検索すると出てくる
CLIPを読み込む（CLIPLoader）
CLIPテキストエンコード × 2個（ポジティブ用とネガティブ用）
空の潜在画像（EmptyLatentImage）
Kサンプラー（KSampler）
VAEを読み込む（VAELoader）
VAEデコード（VAEDecode）
画像を保存（SaveImage）

各ノードの設定

ノード	パラメータ	値
Unet Loader (GGUF)	unet_name	`flux2-dev-Q8_0.gguf`
CLIPを読み込む	clip_name	`mistral_3_small_flux2_fp8.safetensors`
	タイプ	`flux2`
	デバイス	`default`
CLIPテキストエンコード（ポジティブ）	text	プロンプトを入力
CLIPテキストエンコード（ネガティブ）	text	空のまま
空の潜在画像	幅	`1024`
	高さ	`1024`
	バッチサイズ	`1`
Kサンプラー	シード	任意（`randomize` で毎回変更）
	ステップ	`28`
	cfg	`4.0`
	サンプラー名	`euler`
	スケジューラ	`simple`
	ノイズ除去	`1.00`
VAEを読み込む	vae_name	`flux2-vae.safetensors`
画像を保存	ファイル名プレフィックス	`ComfyUI`（任意）

ノード間の接続

以下の 9本の線 を繋ぐ。ComfyUI では出力ポート（右側の丸）から入力ポート（左側の丸）へドラッグする。

Unet Loader (GGUF) の モデル → Kサンプラー の モデル
CLIPを読み込む の CLIP → CLIPテキストエンコード（ポジティブ） の クリップ
CLIPを読み込む の CLIP → CLIPテキストエンコード（ネガティブ） の クリップ（同じ CLIP 出力から2本分岐）
CLIPテキストエンコード（ポジティブ） の 条件付け → Kサンプラー の ポジティブ
CLIPテキストエンコード（ネガティブ） の 条件付け → Kサンプラー の ネガティブ
空の潜在画像 の 潜在 → Kサンプラー の 潜在画像
Kサンプラー の 潜在 → VAEデコード の サンプル
VAEを読み込む の VAE → VAEデコード の vae
VAEデコード の 画像 → 画像を保存 の 画像

接続が正しければ、線の色で役割が区分される: モデル（紫）、CLIP/条件付け（黄〜オレンジ）、潜在画像（ピンク）、VAE（赤）、画像（青）。

実行

右上の「▷ 実行する」をクリック。初回はモデルのロード（テキストエンコーダ 17GB + 拡散モデル 35GB）に数分かかる。2回目以降はサンプリング（28ステップ × 約27秒 ≒ 約13分）のみ。

ターミナルに step 1/28, step 2/28... とプログレスが表示されれば正常動作。

生成性能

指標	値
ステップ速度	27.16 s/step
合計時間（1024×1024, 28 ステップ）	約12分40秒
連続生成安定性	6枚以上連続、クラッシュゼロ

1枚あたり約13分。お茶を入れに行って戻ってくるとちょうどできている、くらいの感覚。

測定条件

項目	値
解像度	1024×1024
ステップ数	28
サンプラー	euler
スケジューラ	simple
CFG	1.0（FLUX.2 dev 推奨値）
seed	固定（再現性確認のため）
ワークフロー	ComfyUI txt2img（Unet Loader GGUF → CLIPLoader type:flux2 → KSampler → VAE Decode）
測定方法	ComfyUI のコンソール出力から step 時間を取得、28 ステップの平均

動作しない構成 ― 失敗の全記録

ここが一番大事かもしれない。以下の構成は筆者環境ですべて検証済みで、いずれも 2026年3月末時点では実用にならなかった。

モデル	サイズ	VGM	オプション	結果	原因
FP8 safetensors (dtype=fp8)	34 GB	96 GB	—	Segfault	`_scaled_mm` が MI300+ 専用
FP8 safetensors (dtype=default)	34 GB	96 GB	—	Segfault	MixedPrecisionOps 内部で FP8 演算
BF16 safetensors	61 GB	96 GB	`--disable-smart-memory`	OOM Kill	全モデル同時保持で 96GB 超
BF16 safetensors	61 GB	96 GB	smart memory	Segfault	FP8 メタデータ問題
BF16 safetensors	61 GB	96 GB	—	mmap 失敗	32GB の CPU RAM に 61GB を mmap 不可
BF16 safetensors	61 GB	64 GB	`--disable-mmap`	Kill	RAM 62GB に OS + 61GB は収まらない
Q5_K_M GGUF	24 GB	96 GB	—	step 9 でクラッシュ	Q5_K dequant のビットシフトバグ
Q8_0 GGUF	35 GB	96 GB	—	step 3–5 でクラッシュ	VGM=96GB だと RAM=30GB でメモリ逼迫
AOTriton Flash Attention	Q8_0	64 GB	`AOTRITON_EXPERIMENTAL=1`	クラッシュ	`MEMORY_APERTURE_VIOLATION`
GTT カーネルパラメータ	Q8_0	64 GB	`amdgpu.gttsize=126976`	ハング	モデルが GTT（低速パス）に配置

今回の検証範囲では、Q8_0 GGUF + VGM=64GB 以外に安定動作する組み合わせを見つけられなかった。FP8 は演算ユニットが対応していないし、BF16 はメモリが足りないし、Q5_K はデコードが不安定。消去法で Q8_0 一択、というのが 2026年3月末時点の結論。

ROCm やカーネルのアップデートで BF16 mmap 問題や Q5_K の安定性が改善される可能性はある。状況が変わったらコメントで教えていただけるとありがたいです。

性能の現実

DGX Spark との参考比較

参考として、NVIDIA DGX Spark（GB10 Blackwell）との比較を載せておく。ただし DGX Spark は FP8/BF16 safetensors、EVO-X2 は Q8_0 GGUF で、量子化方式が異なるため厳密な同条件比較ではない。 実用上「それぞれの環境で最速の構成を使ったらどうなるか」という参考値として見てほしい。

	DGX Spark (FP8)	DGX Spark (BF16)	EVO-X2 (Q8_0 GGUF)
ステップ速度	5.39 s/step	8.34 s/step	27.16 s/step
合計時間 (1024×1024, 28step)	153秒	434秒	762秒
速度比	1.0×	0.65×	0.20×

EVO-X2 は DGX Spark FP8 比で約5倍遅い。DGX Spark は定価約60万円、EVO-X2 は約30万円（128GB 構成）。画像生成の速度だけで言えば DGX Spark のコストパフォーマンスが高いが、EVO-X2 は汎用デスクトップとしても使えるので、用途次第。

なぜこれが上限に近いのか

gfx1151 (RDNA 3.5) の BF16 実効性能は約 46 TFLOPS（The Register のベンチマーク）
DGX Spark (Blackwell GB10) は 120–125 TFLOPS で、約2.5倍の差がある
2026年3月末時点では、27 s/step が Q8_0 GGUF + math attention としてほぼ上限と考えている

試したチューニングと効果

効果あり

設定	効果
Ubuntu 25.10 + kernel 6.18.20	複数モデルワークフローのクラッシュ完全解消（`HSA_USE_SVM=0` 不要に）
ROCm 7.13 TheRock nightly (cp313)	7.12 と同等性能、Python 3.13 対応
`--cache-none`	複数モデルワークフローでの VRAM 不足回避に必須

効果なし（少なくとも筆者環境では速度変化ゼロ）

設定	結果
ROCm 7.12 → 7.13 アップグレード	速度変化なし
`TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL=1`	速度変化なし
`--use-pytorch-cross-attention`	速度変化なし
`ROCBLAS_USE_HIPBLASLT=1`	速度変化なし
`MIOPEN_FIND_MODE=FAST`	速度変化なし

悪化

設定	結果
GRUB: `amdgpu.gttsize=126976 ttm.pages_limit=32505856`	モデルが GTT（低速メモリ）に配置されハング。削除済み
VGM=96GB (BIOS)	RAM が約30GB に減り OOM Kill。64GB に戻した
Flash Attention (AOTriton)	`MEMORY_APERTURE_VIOLATION` でクラッシュ
`--cache-none` を外す	複数モデルワークフローで VRAM 不足クラッシュ

「効果なし」の項目が多いのが 2026年3月末時点の gfx1151 の現状。ROCm のチューニングノブの多くは CDNA 系（MI300X 等）向けに設計されており、RDNA 3.5 では空振りするものが多い。

まとめ ― 推奨構成（2026年3月末時点）

BIOS で VGM=64GB に設定
Ubuntu 25.10 + kernel 6.18 以降をインストール
Python 3.13 の venv を作り、TheRock nightly の ROCm pip wheel をインストール（gfx1151 対応）
ComfyUI + ComfyUI-GGUF カスタムノードをインストール
モデルファイルを配置: flux2-dev-Q8_0.gguf, mistral_3_small_flux2_fp8.safetensors, flux2-vae.safetensors
--disable-mmap --bf16-vae --cache-none で起動

期待できる性能: 1024×1024 / 28ステップで約12分40秒（27 s/step）。 高速とは言えないが、ローカルで 64GB VRAM を活かした FLUX.2 生成が安定して動く構成。

次回: 第2弾 — LoRA 適用編

DGX Spark (CUDA) で学習した FLUX.2 LoRA を EVO-X2 (ROCm) で適用する方法、性能への影響、ワークフロー設定を扱う予定。

検証環境: GMKtec EVO-X2, Ryzen AI Max+ 395, Ubuntu 25.10, kernel 6.18.20, ROCm 7.13 TheRock nightly, 2026-03-29

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up