Qwen-Image-2.1をVRAM 16GBで動かす｜30GiBのbf16も動く、量子化版はPyTorch cu130なら速い実測

公式の案内は「consumer cards」までしか書いていない

Qwen-Image-2.1 は Alibaba の Qwen チームが公開した画像生成・編集モデルで、ComfyUI は2026年9月20日にネイティブ対応を告知し、その対応を含むバージョン0.37.0が9月21日にリリースされた。ComfyUI 側の告知は「7B」というパラメータ数と、「推論は速く、重みは consumer cards に快適に収まる」という表現を置いている。ただし Qwen 公式はこの7Bを画像生成コンポーネントのパラメータ数と明記しており、テキストエンコーダはこれに含まれない別ファイルである。いずれにせよ、どの組み合わせなら16GBのカードに収まるのか、収まったとして何秒かかるのかは書かれていない。

配布側が用意しているファイルは1種類ではない。拡散モデルに bf16 と量子化版、テキストエンコーダに3通りがあり、組み合わせによってダウンロード量は13.27GiBから30.21GiBまで幅がある。16GBのカードで使う側から見ると、まず、どの組み合わせを選ぶか判断する必要がある。

そこで、配布されている組み合わせのうち合計が最小・テンプレート既定・最大になる3通りを選び、RTX 5080 16GB と RTX 5060 Ti 16GB で実際に動かして、所要時間とVRAMのピークを測った。

配布されているファイルと、その合計サイズ

ComfyUI 向けの重みは Comfy-Org のリポジトリに置かれている。ファイルサイズはリポジトリが返す実バイト数で、2026年9月22日時点では次のとおり。

役割	ファイル	実サイズ
拡散モデル	qwen_image_2.1_bf16	14,230,280,616バイト (13.25GiB)
拡散モデル	qwen_image_2.1_int8_convrot	7,256,783,064バイト (6.76GiB)
テキストエンコーダ	qwen3vl_8b_bf16	17,534,334,616バイト (16.33GiB)
テキストエンコーダ	qwen3vl_8b_int8_convrot	9,350,798,360バイト (8.71GiB)
テキストエンコーダ	qwen3vl_8b_w4a8	6,312,105,364バイト (5.88GiB)
VAE	qwen_image_2.1_vae_bf16	675,509,688バイト (0.63GiB)

同じフォルダにはプロンプト強化用のファイルも別に置かれているが、この記事では扱わない。

テンプレートに添えられた案内で挙げられているのは、拡散モデルの bf16 と int8_convrot、テキストエンコーダの bf16 と int8_convrot、そしてVAEである。テンプレートを開いたときに最初から選択されている組み合わせは int8_convrot 同士で、合計は16.10GiBになる。

ここで気になるのが容量の関係だ。16GBと呼ばれるカードで nvidia-smi が報告する total は、RTX 5080 で16,303MiB、RTX 5060 Ti で16,311MiB、つまり15.92GiB前後しかない (これは物理搭載量そのものではなく、ドライバの予約などにより公称容量とは差が出る場合がある)。テンプレートの既定の組み合わせは、ファイル合計だけを見るとカードの容量をすでに超えている。

さらに、案内には載っていないが同じリポジトリには w4a8 というテキストエンコーダも置かれている。これを選ぶと合計は13.27GiBまで下がる。逆に bf16 同士を選ぶと30.21GiBで、カード容量のほぼ倍になる。拡散モデル2種とテキストエンコーダ3種で6通りの組み合わせができるが、測ったのはこのうち最小・既定・最大の3通りである。ローカルで動かすモデルがディスクをどれだけ使うかは別記事にまとめてある。

検証環境と測り方

測定は ComfyUI 0.37.0 を既存のインストールとは別のディレクトリに展開し、依存ライブラリもそちらに分離した状態で行った。モデルの置き場だけを共有し、出力先・設定・データベースは測定用に分けている。測定に使ったPCの構成は検証環境のページにまとめてある。

項目	内容
GPU	RTX 5080 16GB (16,303MiB)・マザーボードの PCIe 5.0 x16 / RTX 5060 Ti 16GB (16,311MiB)・OCuLink (MINISFORUM DEG1) の PCIe 4.0 x4 で外付け
ComfyUI	0.37.0
PyTorch	2.9.1+cu128 (「PyTorch を cu130 にすると量子化版のほうが速い」の節の追試だけ 2.9.1+cu130)
サンプラー	euler・simple・cfg 1.0・25ステップ (いずれも公式テンプレートの既定値)
ノード	UNETLoader / CLIPLoader (type=qwen_image) / TextEncodeQwenImage21 / KSampler / VAEDecode / SaveImage
解像度の決め方	TextEncodeQwenImage21 の resolution に 1024 または 2048 を入れ、同ノードの LATENT 出力を KSampler へ渡す
起動オプション	演算精度やVRAMの扱いを変えるものは指定していない (ポートと出力先の指定のみ)。全条件で同一
測定日	2026年9月22日 (cu130 版の追試は2026年9月24〜25日)

ノード構成は公式テンプレートと同じではない。テンプレートは ResolutionSelector と EmptyLatentImage を持ち、KSampler へ渡す latent はそちらから来る。この測定では ResolutionSelector を使わず、TextEncodeQwenImage21 が出す LATENT を直接つないでいる。サンプラー・スケジューラ・cfg・ステップ数はテンプレートの既定値をそのまま使った。読者がテンプレートから解像度を変える場合の操作は別で、後の節に書いてある。

条件を変えるたびに ComfyUI のプロセスを起動し直している。同じプロセスのままテキストエンコーダだけを差し替えると、前の条件の重みが載ったままの状態がピークに混ざるためである。実際、最初の測定ではこれを踏んでしまい、その組み合わせが実際に何MiBを必要とするのか分からなくなった。

VRAMは nvidia-smi の値を走行中に0.5秒間隔でサンプリングし、走行ごとの最大値を記録している。拾えるのはこの間隔に引っかかった最大値で、これより短いスパイクは取りこぼす。デスクトップ表示に使われている分も含む絶対値で、新規プロセスでの走行開始時点は RTX 5080 が849〜1,921MiB、RTX 5060 Ti が114MiBだった。以下の表に載せる「VRAMピーク」は各条件の2回目以降の中央値で、モデル読み込みを含む初回は cu128 版の10条件中8条件でこれより高かった。例外は2条件で、RTX 5060 Ti の int8_convrot + w4a8 が初回13,456MiBと2回目以降の14,064MiBより608MiB低く、透過を指示した条件が初回15,271MiBと2MiB低い。秒数は小数第1位まで丸めて載せているが、倍率と1ステップあたりの増分は丸める前の値から計算しているので、表示された秒数で割り直すと末尾が一致しないことがある。cu128 版の全走行で最も高かったのは bf16 同士・1024×1024の初回で15,431MiB、16,303MiBのカードに対して872MiBの余裕だった。

合計16.10GiBの既定構成は16GBに載るか

テンプレート既定の int8_convrot 同士は、RTX 5080 16GB で生成まで通った。1024×1024・25ステップを回したところ、2回目以降の所要は27.8秒 (27.6〜28.0秒、n=2)、VRAMピークは15,201MiB。モデル読み込みを含む初回は41.1秒で、そのときのピークは15,346MiBだった。

合計16.10GiBのファイルが15.92GiBのカードで動いている。ファイルサイズの合計は、そのままVRAMの占有量にならない。この条件の走行後の常駐は13,226〜13,354MiB (約12.9〜13.0GiB) で、3ファイルの合計16.10GiBより小さい。少なくとも全部が同時に載ってはいない。

案内に載っていない w4a8 を使った13.27GiBの組み合わせも同じ条件で通り、所要は27.8秒 (27.7〜27.8秒、n=2)、ピークは15,136MiB。軽い側を選んでも所要時間は変わらなかった (PyTorch cu128 版。cu130 版では RTX 5080 で w4a8 のほうが0.6秒短い7.5秒対8.1秒、RTX 5060 Ti は16.8秒対16.7秒でほぼ同じ)。cu128 版で差が出たのはモデル読み込みを含む初回で、41.1秒に対して33.4秒と7.7秒短い。テキストエンコーダのファイルサイズは2.83GiB違い、短くなったのはファイルが小さい側である。ただし初回はそれぞれ1本ずつで、読み出しの速度も初期化にかかる分も測っていないため、この要因が差の原因だとまでは言えない。

合計30.21GiBのbf16構成はどうなるか

bf16 同士の構成も、RTX 5080 16GB で生成まで通った。PyTorch が cu128 版のこの測定では、量子化版を使った2通りより短い時間で終わっている。ただし cu130 版では順位が入れ替わる (後述)。

組み合わせ	ファイル合計	所要 (2回目以降の中央値)	VRAMピーク (同・中央値)
bf16 + bf16	30.21GiB	19.8秒 (n=6)	15,181MiB
int8_convrot + int8_convrot	16.10GiB	27.8秒 (n=2)	15,201MiB
int8_convrot + w4a8	13.27GiB	27.8秒 (n=2)	15,136MiB

RTX 5080・1024×1024・25ステップ・PyTorch cu128 版。この環境ではファイルが最も大きい組み合わせが最も速く、量子化版を使った2通りに対して所要時間が約29%短い。速度換算で1.40倍にあたる。cu130 版では順位が入れ替わる (後述)。

3通りのピークは中央値で15,136・15,181・15,201MiBに並ぶ。ただしこれは絶対値で、デスクトップ表示に使われている分を含む。3構成はそれぞれ別の起動で測っており、走行開始時点は bf16 同士が1,027〜1,304MiB、量子化の2通りが1,856MiBと1,921MiBで、最大894MiB違う。量子化2通りのピーク差65MiBは、走行開始時点の差65MiB (1,921と1,856) とちょうど同じで、各条件の開始時点を引くとどちらも13,280MiBになり、差が残らない。

2回目以降の各走行の直前に残っていた常駐量を引いた増分で見ても、bf16 同士が1,911〜2,194MiB、int8_convrot 同士が1,850〜1,972MiB、w4a8 が1,716〜1,972MiBで重なっている。ファイル合計が2.3倍開いても、ピークからもこの増分からも構成間の差は取り出せなかった。ピークの絶対値はどれも約14.8GiB (15,136〜15,201MiB) で、16,303MiBのカードに対して1,100MiB前後の余裕を残す位置に揃っている。

bf16 の2回目以降6本のうち1本だけ28.09秒で、残る5本は19.38・19.43・19.84・19.84・19.92秒に収まっている。読み込みを含む初回はこの6本とは別に2本あり、26.52秒と24.98秒だった。

量子化側が遅かった理由の有力な候補が、公開後の追試で見つかった。この測定に使った PyTorch は 2.9.1+cu128 で、ComfyUI は PyTorch の CUDA 版が13未満だと、量子化形式向けに用意された最適化済みの CUDA 処理 (comfy-kitchen の cuda バックエンド) を無効にする。起動ログにはそのことを示す警告が出ていた (cu130 版の起動ログでは警告が出ず、この処理は有効になっていた)。PyTorch を cu130 版に替えると量子化版の所要は3分の1以下になり、bf16 同士の短縮は1割ほどにとどまった。版を替えると PyTorch と CUDA のライブラリも同時に変わるので、この処理だけを入れ替えて比べたわけではない。結果はこの処理の有無と整合するが、逆転への寄与の大きさまでは切り分けていない。1.40倍の差は、量子化形式向けの最適化処理が無効になった環境での値である。順位が入れ替わった追試の結果は次の節にまとめた。なお拡散モデルのファイルは6.76GiBと13.25GiBで倍近く違うが、CPUとGPUの間の転送量や回数は測っていないため、重みの退避や転送が速度にどう効いたかは切り分けていない。

出力の品質は測っていない。同じシードで生成した画像を並べて比較する、あるいは数値指標で評価するといった作業はしておらず、bf16 と量子化版で生成される画像がどう変わるかについては何も言えない。

使えるVRAMの量そのものを変えて所要時間がどう動くかを測った結果は、別記事にある。

PyTorch を cu130 にすると量子化版のほうが速い

ここまでの秒数は、PyTorch 2.9.1+cu128 の環境で測ったものである。ComfyUI は PyTorch の CUDA 版が13未満だと、量子化形式向けの最適化された CUDA 処理を無効にし、起動時に「You need pytorch with cu130 or higher to use optimized CUDA operations」という警告を出す。ComfyUI の README も、NVIDIA の20シリーズ以降では cu130 以上の PyTorch を必須としている。

そこで ComfyUI 0.37.0・配線・サンプラー設定はそのままに、PyTorch だけを 2.9.1+cu130 に替えて RTX 5080 と RTX 5060 Ti で測り直した (2026年9月24〜25日)。まず RTX 5080 の結果である。

組み合わせ	1024×1024	2048×2048
bf16 + bf16	17.6秒 (n=3)	86.2秒 (n=2)
int8_convrot + int8_convrot	8.1秒 (n=3)	51.8秒 (n=2)
int8_convrot + w4a8	7.5秒 (n=3)	測っていない

RTX 5080・25ステップ・PyTorch cu130 版・2回目以降の中央値。1024×1024では量子化版を使った2通りが bf16 同士より約2.2〜2.3倍速く、2048×2048でも int8_convrot 同士が約1.7倍速い。cu128 版で測った前の節の値と比べると、量子化版は27.8秒から8.1秒 (int8_convrot 同士) へ縮んだのに対し、bf16 同士は19.8秒から17.6秒への短縮にとどまる。測定日が違うため、この短縮幅は目安である。

RTX 5060 Ti でも1024×1024では、量子化版を使った2通りが bf16 同士より速かった。

組み合わせ	cu130 版	cu128 版 (「2枚のカードで所要はどれだけ違うか」の節の値)
bf16 + bf16	38.1秒	測っていない
int8_convrot + int8_convrot	16.7秒	63.3秒
int8_convrot + w4a8	16.8秒	63.6秒

RTX 5060 Ti・1024×1024・25ステップ・2回目以降の中央値 (cu130 版は各n=3、cu128 版は各n=2)。cu130 版では量子化版を使った2通りが bf16 同士より約2.3倍速く、cu128 版の63秒台からは所要が約74%短くなった (速度換算で約3.8倍)。測定日が違うため、この短縮幅は目安である。

cu128 版で見えた「ファイルが最も大きい組み合わせが最も速い」は、量子化形式向けの最適化処理が無効になった環境での結果だったことになる。手元の ComfyUI がどの版の PyTorch で動いているかは、起動ログに出る pytorch version の行と、上の警告の有無で確かめられる。

この追試でも出力の品質は比較していない。2048×2048は RTX 5080 だけ、透過・40ステップの条件 (もともと RTX 5080 でだけ測ったもの) は cu130 版で測り直していないので、それらの秒数は cu128 版での値のまま載せている。

なぜファイル合計で判断できないのか

bf16 同士の構成が手がかりになる。この構成のテキストエンコーダは単体で16.33GiBあり、カード容量の15.92GiBを超えている。それでも生成は通り、観測したピークも15,431MiBまでしか上がっていない。「テキストエンコーダと拡散モデルを片方ずつ載せる」という説明では、この事実を説明できない。少なくとも、ファイル全体がそのままVRAMへ同時に常駐しているわけではなく、実行中に何らかの退避が働いていることになる。

常駐量の動き方も同じ方向を指す。1024×1024では走行後の常駐が両GPUで観測した範囲で12,092〜13,434MiB (RTX 5080 だけなら12,963〜13,434MiB) で安定していたが、同じ RTX 5080 で2048×2048を回した直後は7,210〜7,698MiB (約7.0〜7.5GiB) まで下がっていた。同じモデルを使っているのに、解像度を上げたほうが常駐が減る。

ComfyUI には、VRAMの空きに応じて重みの置き場を調整する仕組み (dynamic VRAM) がある。2026年3月の配布元のブログでは NVIDIA のハードウェア・Windows と Linux 向けとされ、AMD等への対応は今後の予定として挙げられていた。2026年9月22日時点の配布元ドキュメントでは --enable-dynamic-vram の既定値が「auto on Nvidia, ROCm 7.14+」と記載されており、対応はROCm 7.14以降にも広がっている。すべての環境で自動的に有効になるわけではなく、有効にならない環境で有効化する --enable-dynamic-vram と、無効化する --disable-dynamic-vram が用意されている。この測定は NVIDIA のカードを Windows で使い、どちらのフラグも付けていないので、同ドキュメントの記載では自動的に有効になる条件にあたる。ただし ComfyUI はこの仕組みが入る前からVRAMが足りない場合に重みを退避する経路を持っており、今回観測した退避がどちらによるものかは、無効化して走らせる対照を取っていないため切り分けていない。起動オプション全般はComfyUIの起動オプション実測ガイドにまとめてある。より大きな作業領域を必要とする条件では、その分だけ重みを退避させていると読める。16GBに収まるかどうかは、ファイル合計だけでは判断できず、実行時の重みの退避や作業領域の確保に左右される。

どの重みをどの単位でどこへ退避させているかは測っていない。確認したのは常駐量とピークの推移までである。モデル一式がカードに収まらない状態を動画生成で測った記事は別にある。

ネイティブ2Kは RTX 5080 16GB で回るか

2048×2048も、試した3通りとも RTX 5080 16GB で生成まで通った。所要は次のとおり。

組み合わせ	1024×1024	2048×2048	倍率
bf16 + bf16	19.8秒	92.7秒	4.67倍
int8_convrot + int8_convrot	27.8秒	130.1秒	4.68倍
int8_convrot + w4a8	27.8秒	130.2秒	4.69倍

RTX 5080・25ステップ・PyTorch cu128 版。2048×2048はいずれも2回目以降が各条件1本ずつなので、ばらつきは評価できない。面積は4倍になるが所要は4.67〜4.69倍で、面積比をやや上回る。3通りとも近い倍率で伸びており (cu130 版では bf16 同士が約4.9倍、int8_convrot 同士が約6.4倍で、倍率は揃わない)、1024で見えた1.40倍差は2048でもそのまま残った (92.7秒対130.1秒、PyTorch cu128 版)。cu130 版では2048でも量子化版のほうが速い (前の節)。

VRAMピークは2回目以降の値で14,832〜15,017MiB。初回は15,361〜15,402MiBで、1024の初回 (15,230〜15,431MiB) と同じ水準。2回目以降は1024より300MiBほど低い側に出ている。

公式テンプレートから解像度を変える場合は、ResolutionSelector ノードのアスペクト比を1:1、メガピクセルを4に設定する (既定の1メガピクセルが1024×1024にあたる)。案内は32の倍数を使うよう勧めている。この測定は前述のとおり ResolutionSelector を使わない配線で行っており、テンプレート側の操作としてはこちらが該当する。

なお ComfyUI 側には2026年9月21日起票の未解決の報告があり、Qwen-Image-2.1 のサンプリングの shift が解像度によらず0.69で固定されていて、モデル側が2048で想定する値 (約1.31) と離れる、とされている。この記事が測ったのは所要時間とVRAMだけで、出力の品質は比較していない。2Kの品質を評価する場合は、この報告の状況を確認する必要がある。

2枚のカードで所要はどれだけ違うか

GPU	組み合わせ	所要 (2回目以降の中央値)	VRAMピーク (同・中央値)
RTX 5080 16GB	int8_convrot + int8_convrot	27.8秒	15,201MiB
RTX 5080 16GB	int8_convrot + w4a8	27.8秒	15,136MiB
RTX 5060 Ti 16GB	int8_convrot + int8_convrot	63.3秒	14,782MiB
RTX 5060 Ti 16GB	int8_convrot + w4a8	63.6秒	14,064MiB

1024×1024・25ステップ、各n=2、PyTorch cu128 版 (cu130 版での値は「PyTorch を cu130 にすると量子化版のほうが速い」の節)。RTX 5060 Ti は RTX 5080 の2.28〜2.29倍の時間がかかる。5080では65MiB (走行開始時点の差と同じ幅) しか違わなかった2構成が、走行開始時点が共通の5060 Ti では718MiB開いている。ピークがファイル合計の順に並ばないのは、5080で測った条件の話になる。cu128 版では、どちらのカードでもテキストエンコーダを軽くして所要が短くなることはなく、5080で27.8秒対27.8秒、5060 Ti で63.3秒対63.6秒だった。

この2枚は接続も違う。RTX 5080 はマザーボードの PCIe 5.0 x16 に挿さっており、RTX 5060 Ti は OCuLink (MINISFORUM DEG1) 経由の PCIe 4.0 x4 で外付けにしている。規格上の片方向帯域は約63GB/sと約7.9GB/sで、8倍ほど開く。この比較はGPUそのものに加えて接続条件も違うため、2.28〜2.29倍という差をGPUの性能差だけに帰属させることはできない。PCIe接続がどの程度効いているかは切り分けていない。

VRAMピークの絶対値は5060 Ti のほうが低い。ただしこの値にはデスクトップ表示に使われている分が含まれている。新規プロセスでの走行開始時点は5060 Ti が114MiB、5080 が1,856〜1,921MiBで、1.7GiB以上の差がある。ピークの差はそれより小さく、int8_convrot 同士で419MiB、w4a8 で1,072MiBだった。

各条件の走行開始時点を引くと、int8_convrot 同士は5060 Ti が14,668MiB・5080 が13,280MiB、w4a8 は5060 Ti が13,950MiB・5080 が13,280MiB (5080は2構成とも同じ値になる)。どちらの組み合わせでも、走行開始時点の占有量を差し引いたピーク時の差分は5060 Ti のほうが大きい。これは生成中だけに増えた分ではなく、前の走行から載ったままの重みと今回の作業領域を合わせた量で、載っている重みの量を直接測ったものではない。前の節に書いた「空きに応じて置き場を調整する」という読み方と矛盾はしない、というところまでになる。走行後の常駐 (これも絶対値) は、同じ2構成で見ると5060 Ti が12,092〜12,892MiB、5080が13,164〜13,420MiB。ここでも、走行開始時点の1.7GiB以上の差より小さい範囲に収まっている。

2枚挿した環境でどちらのカードに実行させるかの指定はComfyUIで使うGPUを指定するに、同じ2枚で動画生成を測った結果はMiniMax H3 のVRAM 16GB実測にまとめてある。

透明な背景は本当に出るか

背景が透明なPNGは出力できた。ただし透過を指示した条件だけである。

テンプレートに添えられた案内は、透過画像を作る場合にプロンプトを次の形で包むよう指定している。「This is an RGBA format image with transparency.」で始め、対象を書き、「The image has an alpha channel and a transparent background.」で閉じる形である。

生成する対象を同じにし、組み合わせも揃えたうえで (RTX 5080・int8_convrot 同士・1024×1024・25ステップ)、この指示を付けた場合と付けない場合の出力を比べた。PNGのアルファチャンネルを画素単位で数えた結果は次のとおり。

条件	アルファ値の範囲	完全不透明の画素	完全透明の画素	中間の値の画素	四隅のアルファ値
指示なし (n=1)	253〜255	95.7%	0.0%	4.3%	4か所とも255
指示あり (n=2)	0〜255	27.2〜41.3%	18.3〜24.3%	40.4〜48.4%	4か所とも0

指示を付けなかった1本では、完全透明の画素が0.0%で背景が抜けていない。ただし測ったのは指示なし1本・指示あり2本で、「指示しなければ透過しない」がモデルの仕様なのかまでは確かめていない。配布元の案内は透過画像にこのプロンプト形式を使うよう示しているが、使わなかった場合にどうなるかは書いていない。この条件で言えるのは、透過の指示を入れた側にだけ明確な透明画素が出たという事実までである。

条件によらず共通する点がもう1つある。どちらの条件でもPNG自体はRGBA形式で保存されている。ファイルの形式を見ただけでは透過できているか判断できず、アルファ値の分布まで見ないと区別がつかない。

指示を付けた側は四隅がすべてアルファ値0で、完全透明の画素が2割前後ある。一方で中間の値を持つ画素が4割を超えており、輪郭の内側にも半透明の領域が広がっている。実際に合成した際にどう見えるかは評価していない。

透過の指示を入れても所要時間とVRAMは変わらなかった (2回目以降1本で27.7秒、ピーク15,273MiB。指示なしの27.8秒・15,201MiBと同じ範囲)。

ステップ数を案内どおり40にすると

テンプレートの既定は25ステップだが、案内には「公式のパイプラインは euler でおよそ40〜50を使う」という記述がある。RTX 5080 で int8_convrot 同士・1024×1024の40ステップを測ると、2回目以降の所要は53.8秒 (53.3〜54.3秒、n=4)、ピークは15,207MiBだった。

ステップ数が所要にどう効くかを見るなら2回目以降の値で比べることになり、27.8秒対53.8秒の1.94倍になる。

比べ方	25ステップ	40ステップ	倍率
2回目以降の値で比べる	27.8秒	53.8秒	1.94倍
読み込みを含む初回の値で比べる	41.1秒 (1本)	50.0秒 (初回2本の中央値。倍率は丸め前の値から算出)	1.22倍

初回の値で比べたときに1.22倍と小さく出た理由は、この測定では切り分けられていない。両方に共通して乗るモデル読み込みの時間が比を1へ寄せた、と読みたくなる。だが40ステップ条件では初回のほうが2回目以降より速いという逆転が起きている。モデル読み込みの時間が単純に上乗せされたという説明だけでは、この逆転までは説明できない。繰り返し生成する状態でのステップの効き方を見るなら、2回目以降の値で比べた1.94倍を取る。ステップ比の1.6倍 (40÷25) を上回っており、1ステップあたりの増分は2回目以降で約1.73秒、初回の値で比べると約0.60秒と、常駐の状態によって変わる。

40ステップ条件では、初回の2本 (49.7秒・50.4秒) が、2回目以降の4本 (53.3〜54.3秒) のいずれよりも短い。2回の独立した起動で、いずれも同じ結果になっている。25ステップでは初回が41.1秒、2回目以降が27.8秒で、初回のほうが長い。

常駐が13,213〜13,434MiB残った状態から作業領域を確保する場合と、何も載っていない状態から確保する場合とで、退避のしかたが違う可能性はある。ただし常駐の状態は25ステップでも同じで、そちらでは逆転していない。常駐の有無だけでは、逆転が40ステップにだけ出る理由は説明できない。内部で何が起きているかは確認しておらず、原因は切り分けられていない。

ライセンスは研究・評価に限られる

モデルのリポジトリに置かれているライセンスは Qwen RESEARCH LICENSE AGREEMENT で、許諾されている利用は非商業目的に限ると明記されている。同ライセンスは非商業目的を「研究または評価の目的のみ」と定義しており、商用で使う場合は別途の許諾が必要になる。

モデルやその派生物を再配布・提供する場合は、ライセンス本文の同梱、変更したファイルへの変更点の明示、所定の帰属表示の保持が条件として挙げられている (派生物を作ること自体は、非商業目的の範囲で許諾されている)。「Built with Qwen」「Improved using Qwen」の表示が必要なのは、これとは別の場合である。このモデルまたはその出力を使ってAIモデルを作成・学習・微調整・改善し、そのモデルを配布・公開するときの条件で、再配布や派生物のすべてに適用されるわけではない。あわせて、派生物や製品の主たる名称として Qwen を使うことは認められていない (「fine-tuned from Qwen Image」のような説明としての言及は認められている)。

生成物の権利帰属や、一般的な再利用の条件を直接定める条項は、ライセンス本文に見当たらなかった。出力そのものへの言及自体はあり、AIモデルへの利用時の表示義務、出力が権利を侵害するとして配布元を提訴した場合にライセンスが終了する条項、保証の否認と責任の制限に現れる。ただし許諾自体がモデルの使用を非商業目的に限っているため、条項が無いことが商用利用の許可にはならない。モデルの重みなどの配布物 (ライセンスでいう Materials) を商用目的で使うには、別途の商用ライセンスを取得する必要がある。判断に迷う場合は配布元に確認する必要がある。

目的別に、どの構成を選ぶか

ここまでの結果を、用途別に整理する。いずれも前節のライセンスの範囲内、つまり研究・評価の目的での利用が前提になる。商用の制作に使う場合は別途の許諾が必要になる。

やりたいこと	選ぶ構成	この記事で測った根拠
待ち時間を短くして枚数を試す	PyTorch を cu130 版にしたうえで int8_convrot + w4a8 (13.27GiB) か int8_convrot + int8_convrot (16.10GiB)	cu130 版の追試で7.5秒と8.1秒。bf16 同士の17.6秒より約2.2〜2.3倍速い
ディスクの使用量を抑える	int8_convrot + w4a8 (13.27GiB)	bf16 同士より約56%小さい容量。cu130 版では速さでも bf16 同士を上回る (7.5秒対17.6秒)。cu128 版では27.8秒で、bf16 同士の1.40倍かかった
テンプレートの設定のまま動かす	int8_convrot + int8_convrot (16.10GiB)	cu130 版で8.1秒、cu128 版で27.8秒。cu128 版では w4a8 に替えても2回目以降は変わらなかった。ディスクは2.83GiB差。cu128 版の初回は41.1秒対33.4秒だが、どちらも1本ずつで原因は切り分けていない
2048×2048で出力する	3通りとも通る (cu128 版。cu130 版は int8_convrot 同士と bf16 同士で確認)	RTX 5080 でいずれも生成できた。cu128 版では所要が1024×1024の4.67〜4.69倍 (bf16 同士で92.7秒)。cu130 版では bf16 同士86.2秒、int8_convrot 同士51.8秒
背景が透明なPNGを作る	int8_convrot + int8_convrot で確認	プロンプトを案内の形にした条件で、四隅まで抜けた出力が得られた。所要とVRAMは指示なしと同じ範囲 (cu128 版)。他の2通りでは試していない
案内どおり40ステップで回す	int8_convrot + int8_convrot で確認	cu128 版で53.8秒。25ステップの1.94倍で、VRAMピークは15,207MiBで25ステップと同じ範囲。他の2通りと RTX 5060 Ti、cu130 版では試していない

特記のない秒数とVRAMは、RTX 5080・1024×1024・25ステップ・2回目以降の中央値で、PyTorch の版は各欄に記した。この表は速度とディスク使用量だけで選んだ場合の整理で、出力の品質は測っていない。生成される画像の差が選択を変える可能性は残っている。

用途そのものについては、テキストからの生成のほかに、参照画像を渡した編集にもモデルが対応している (Qwen 公式の仕様で最大10枚。ComfyUI のノードが出す入力スロットは image_1〜image_16 で、数が一致しない)。ただしこの記事で測ったのはテキストから生成する経路だけで、編集の所要時間もVRAMも測っていない。

この記事が測っていないこと

• RTX 5060 Ti での2048×2048。5060 Ti で回したのは1024×1024・25ステップだけで (bf16 同士は cu130 版の追試だけ)、透過と40ステップも RTX 5080 でしか測っていない。
• cu130 版での透過・40ステップ。PyTorch cu130 版で測ったのは RTX 5080 の1024×1024 (3通り)・2048×2048 (2通り) と RTX 5060 Ti の1024×1024 (3通り。bf16 同士はこのとき初めて測った) だけで、それ以外の秒数と、この記事のVRAMの値はすべて cu128 版での値のまま。cu130 版でピークが変わるかは比べていない。
• 他のカード。測ったのは RTX 50 シリーズの16GB 2枚のみ。同じ16GBでも RTX 5080 と RTX 5060 Ti で所要が cu128 版で2.28〜2.29倍、cu130 版で約2.1〜2.2倍開いたが、この2枚は接続も PCIe 5.0 x16 と PCIe 4.0 x4 で違うため、差の内訳は切り分けていない。順位の入れ替わりを cu128 版と cu130 版の両方で確かめたのは RTX 5080 だけで (RTX 5060 Ti は cu128 版の bf16 同士を測っていない)、ほかのカードでは確かめていない。構成が変われば、容量が同じでもこの記事の秒数はそのまま当てはまらない。12GBや24GBの容量帯も測っていない。
• サンプラーとcfgを変えた場合。euler・simple・cfg 1.0 に固定しており、他の設定でも同じ差が出るかは測っていない。
• 長時間の連続生成。各条件の走行は最大8本で、数十本を連続で回したときの挙動は見ていない。

まとめ

試した3通りの組み合わせは、RTX 5080 16GB で1024×1024と2048×2048のいずれも生成できた (2048×2048は cu128 版で3通り、cu130 版では int8_convrot 同士と bf16 同士で確認)。ファイル合計が30.21GiBになる bf16 同士も含めてである。RTX 5060 Ti 16GB で測ったのは1024×1024だけで、量子化版を使う2通りは cu128 版と cu130 版の両方、bf16 同士は cu130 版の追試で、いずれも生成まで通っている。

RTX 5080 の1024×1024では、VRAMピークの絶対値はファイル合計の大小に対応しなかった。cu128 版で測った10条件を通して見ると、条件ごとの代表値 (2回目以降の中央値) では14,064〜15,273MiB、個別の走行で見ても14,064〜15,313MiB、読み込みを含む初回まで入れて最大15,431MiBに収まった。合計が2.3倍違っても、ピークからも走行中の増分からも構成間の差は取り出せなかった。ただしRTX 5060 Ti では同じ2構成が14,782MiB対14,064MiBで718MiB開いており、対応しないと言えるのは5080で測った範囲に限られる。bf16 のテキストエンコーダは単体でカード容量を超えているのに通っており、ファイル全体がそのまま同時に常駐しているわけではない。

所要時間の順位は PyTorch の版で入れ替わった。ComfyUI が必須としている cu130 版では、RTX 5080 の1024×1024・25ステップで量子化版を使った2通りが7.5秒と8.1秒、bf16 同士が17.6秒で、量子化版のほうが約2.2〜2.3倍速い。2048×2048でも int8_convrot 同士が51.8秒、bf16 同士が86.2秒だった。最初に測った cu128 版では量子化版が27.8秒、bf16 同士が19.8秒と逆の順位だったが、これは量子化形式向けの最適化処理が無効になった環境での値である。cu128 版の測定では、テキストエンコーダを軽い側に替えても2回目以降の所要時間は変わらず、モデル読み込みを含む初回だけ7.7秒の差が出た。

透過については、RTX 5080・int8_convrot 同士の1条件で指示なし1本と指示あり2本を比べた範囲で、指示を入れた場合にのみ明確な透明画素が出た。PNGがRGBA形式で保存されること自体は指示の有無に関係なく起きるため、形式だけを見て判断すると取り違える。

よくある質問

ダウンロードは全部必要か

使う組み合わせの分だけでよい。テンプレートの既定で動かすなら拡散モデルの int8_convrot、テキストエンコーダの int8_convrot、VAEの3ファイルで合計16.10GiB。速度を重視する場合も、PyTorch が cu130 版なら量子化版のほうが速かった (RTX 5080 の1024×1024・25ステップで量子化版7.5〜8.1秒、bf16 同士17.6秒)。

16GB未満のカードでも動くか

測っていない。この記事の測定は16GBの2枚で、それ未満のカードでどうなるかは分からない。PyTorch cu128 版の測定では、ピークが個別の走行で14,064〜15,313MiB (初回を含めると最大15,431MiB) に収まっていたことから、VRAMがそれより少ない場合は退避の量が増えると考えられるが、実際に動くかどうかは、測定しないと分からない。

量子化版を選ぶ意味はあるか

ある。PyTorch が cu130 版なら、RTX 5080 の1024×1024・25ステップで量子化版を使った2通りが7.5秒と8.1秒、bf16 同士が17.6秒で、速度でも量子化版が上回った。ディスク使用量も13.27GiBと30.21GiBで2.3倍違う。ただし PyTorch が cu128 版の環境では最適化された処理が無効になり、この記事の測定では量子化版のほうが遅かった (27.8秒対19.8秒)。品質の差は測っていない。RTX 5060 Ti でも cu130 版では量子化版のほうが速かった (1024×1024で16.7秒対38.1秒)。

ネイティブ2Kはどう指定するか

公式テンプレートでは ResolutionSelector ノードのアスペクト比を1:1、メガピクセルを4にする (既定の1メガピクセルが1024×1024)。案内は32の倍数を使うよう勧めている。所要は RTX 5080 で測った範囲で、PyTorch cu128 版では1024×1024の4.67〜4.69倍 (各組み合わせ2回目以降1本ずつ)、cu130 版では bf16 同士が約4.9倍、int8_convrot 同士が約6.4倍だった (2回目以降2本ずつ。測定は ResolutionSelector を使わず、TextEncodeQwenImage21 の LATENT を直接つないだ配線で行っている)。

透過画像がうまく抜けない場合は

プロンプトが案内の形になっているかを確認する。「This is an RGBA format image with transparency.」で始め、「The image has an alpha channel and a transparent background.」で閉じる形が指定されている。保存形式はPNGを使う。

参考資料

• Qwen-Image-2.1 in ComfyUI: Open-Weight Image Generation and Editing, Now with Transparency — ComfyUI Blog
• Qwen-Image-2.1 ComfyUI チュートリアル — ComfyUI Docs
• Comfy-Org/Qwen-Image-2.1 — Hugging Face
• Qwen/Qwen-Image-2.1 — Hugging Face (ライセンス本文を含む)
• ComfyUI v0.37.0 — GitHub Releases
• Dynamic VRAM in ComfyUI — ComfyUI Blog
• Qwen-Image 2.1 の既定サンプリングが解像度によらず mu=0.69 固定という報告 — GitHub issue #16447
• Startup Flags — ComfyUI Docs (dynamic VRAM の有効・無効の指定)