Qwen-Image 2.1を、RTX 5070 Ti 16GB＋Windows 11＋ComfyUI環境で実際に動かしてみました。
今回確認したのは単純なText to Imageだけではありません。線画着色、別画像からの配色参照、局所編集、INT8とBF16の比較、キャラクターのポーズ変更、複数人物を1枚の新しいシーンへ統合するところまで試しています。
結論を先に言うと、Qwen-Image 2.1は「元画像を厳密に固定したまま何でも変更するモデル」というより、元画像や複数の参照画像を理解し、それらの特徴を保ちながら新しい画像へ再構成する使い方が面白いモデルだと感じました。特に線画着色と複数参照はかなり印象的でした。
今回の要点： 線画着色と複数参照は特に良好。大きなポーズ変更はimage_1の保持が強く、ControlNetのような厳密なポーズ拘束とは挙動が異なりました。RTX 5070 Ti 16GBではINT8版を実用的な速度で試せています。
Qwen-Image 2.1とは
Qwen-Image 2.1はQwenチームが2026年9月20日に公開したオープンウェイトの画像モデルです。画像生成部分は7Bパラメータで、Text to ImageとImage Editを1つのモデルで扱えます。
公式には、最大10枚の参照画像、人物や商品の特徴保持、局所編集、透明画像の生成・編集などが主な特徴として紹介されています。
なお、Qwen-Image 2.1はQwen Research Licenseで公開されています。 商用利用などを考えている場合は、利用前に必ず最新のライセンス原文を確認してください。
公式発表：Qwen-Image-2.1: Compact, Efficient, and Unified Image Creation
今回の検証環境
| 項目 | 環境 |
|---|---|
| OS | Windows 11 |
| GPU | NVIDIA GeForce RTX 5070 Ti |
| VRAM | 16GB |
| UI | ComfyUI Portable |
| Diffusion Model | qwen_image_2.1_int8_convrot.safetensors |
| Text Encoder | qwen3vl_8b_int8_convrot.safetensors |
| VAE | qwen_image_2.1_vae_bf16.safetensors |
| CFG | 1.0 |
| Steps | 25 |
| Sampler | Euler |
| Scheduler | simple |
| 主な解像度 | 1024×1024 / 1024×1536 / 1536×1024 |
Comfy-OrgではQwen-Image 2.1用のComfyUI向けモデルファイルと、Text to Image / Image Editの公式ワークフローが公開されています。
必要なモデル容量とVRAMの目安
今回ダウンロードした3ファイルをPowerShellで確認すると、容量は次の通りでした。ここではWindows上で1GiB=1024³バイトとして計算した実測値を掲載しています。
| コンポーネント | 実測容量 |
|---|---|
| Diffusion Model INT8 | 約6.76GiB |
| Text Encoder INT8 | 約8.71GiB |
| VAE BF16 | 約0.63GiB |
| 合計 | 約16.10GiB |
Hugging Face上では十進表記のため、それぞれ約7.26GB、9.35GB、0.68GBと表示されます。数字が少し違って見えるのはGBとGiBの換算差です。
モデル合計が約16GBでも、16GB VRAM必須ではない
3ファイルすべてを常時VRAMへ同時に載せるわけではありません。今回のログでは、Text Encoder、Diffusion Model、VAEがそれぞれDynamic VRAM loadingの対象として準備され、必要に応じてGPUとCPU側を使い分けていました。
Model QwenImage21TEModel_ prepared for dynamic VRAM loading. 8916MB Staged.
Model QwenImage21 prepared for dynamic VRAM loading. 6920MB Staged.
Model WanVAE prepared for dynamic VRAM loading. 644MB Staged.したがって「モデルファイルの合計が約16GBだから、VRAMも最低16GB必要」という単純な関係ではありません。
12GBでも動作例はある
コミュニティにはRTX 4070 12GBで、今回と同じINT8 ConvRotのDiffusion Model、INT8 Text Encoder、BF16 VAEを使ってQwen-Image 2.1を実行した検証例があります。
ただしこれは公式の最低要件ではなく、ワークフロー、解像度、参照画像数、システムRAMなどで条件は変わります。今回の実機検証を踏まえると、目安としては次のように考えるのが分かりやすそうです。
| VRAM | 目安 |
|---|---|
| 24GB以上 | BF16や高解像度、複数参照まで余裕を取りやすい |
| 16GB | 今回のINT8構成ではかなり扱いやすい |
| 12GB | INT8構成の動作実例あり。ただし今回と同じ速度・余裕を保証するものではない |
| 8GB | GGUF、CPU Text Encoder、Tiled VAEなど低VRAM向けの別構成を検討 |
| 6GB以下 | 実験的。強いオフロードや解像度低下が前提になりやすい |
今回と同程度のImage Editや複数参照を積極的に試すなら、16GBは扱いやすい容量だと感じました。12GBでもINT8構成の動作実例はありますが、オフロード量や処理時間は環境によって変わるため、「12GBなら必ず同じように動く」という意味ではありません。
低VRAM構成ではGPUから追い出したモデルやText EncoderをシステムRAM側で扱うため、メインメモリも重要です。低VRAM向けコミュニティ検証では、32GB RAMを計画上の目安、64GBをより余裕のある構成として案内しています。
重要：公式Image Editテンプレートの仕様
検証後に公式テンプレートを改めて確認したところ、結果を読むうえで重要な仕様が2つありました。
- image_1が編集対象で、image_2～image_10は追加の参照画像
- CFG=1ではnegative_promptは使用されない
公式テンプレートでは「output follows image_1」と説明されているため、image_1の構図やポーズが強く残りやすかった今回の結果は、この仕様とも整合します。
また今回のテストでは公式テンプレートに合わせてCFG=1を維持していました。そのため、途中でnegative promptを書き換えたテストについては、negative promptそのものが結果を変えたとは評価できません。変化は主にpositive prompt、参照画像、画像の役割分担によるものとして見るべきです。
これは実際に試してから気付いた点で、ポーズ変更の結果を理解するうえでもかなり重要でした。
ControlNetなしで線画を着色してみる
今回一番驚いたのが線画着色です。1024×1536の線画をImage Editへ入力し、キャラクターデザイン、ポーズ、顔、衣装、線をできるだけ維持しながらアニメ調で着色させました。
顔や髪だけでなく、フリル、スカートの輪郭、花模様、リボン、靴、長い髪の流れまでかなり元線画に近い状態を維持しました。
完全にピクセル単位で同じではありませんが、目視では「元絵へそのまま色を乗せた」ように感じる部分もあります。Stable Diffusion系で線画保持にControlNet Lineartなどを使っていた用途の一部を、Image Editだけで簡略化できる可能性を感じました。
別画像の配色を参照して着色
次は複数画像参照を利用し、元線画とは別のカラー画像から配色を持ってこられるか試しました。下のカラー画像を色見本として参照させています。
ピンクの髪、青い瞳、青系のリボン、白を基調とした衣装など、参考画像の色構成がかなり明確に反映されました。
「1枚目の形を使い、2枚目から色やデザインのヒントをもらう」といった使い方はQwen-Image 2.1の複数参照と相性がよさそうです。
腰のリボンだけ赤くする局所編集
完成したキャラクター画像から、腰の大きな青いリボンだけを赤く変更するテストも行いました。
色変更自体は成功しました。しかし画像全体を見ると、背景、肌、白い衣装部分などに細かな粒状感が目立ちます。
INT8量子化が原因なのか？ BF16と比較
粒状感がINT8量子化によるものか確認するため、Diffusion ModelだけをBF16版へ変更しました。
使用したBF16モデルはqwen_image_2.1_bf16.safetensorsです。Text EncoderはINT8、VAEはBF16のままなので、「すべてBF16」にした比較ではありません。
今回のログでは、BF16 Diffusion Modelは約13.6GBがStagedされ、RTX 5070 Ti 16GBでもDynamic VRAMで動作しました。
ただし処理時間はINT8より明確に長くなりました。条件によって差はありますが、今回の局所編集ではINT8が20～40秒台、BF16は約65秒かかるケースがありました。
そして画質を見ると、BF16へ変更しても粒状感は大きく改善しませんでした。少なくとも今回の症状については、INT8量子化だけが原因とは考えにくい結果です。
参照画像のVAE latent結合経路を外すとどうなるか
次に、今回使用したImage Editワークフローで、参照画像由来のVAE latentを編集処理へ結合する経路を外して比較しました。ここでは便宜上「VAE spliceなし」と呼びます。
ノイズは目立ちにくくなりましたが、顔、髪、衣装、ポーズなどは元画像から大きく変化しました。
今回のワークフローでは、元画像への高い追従性と再生成の自由度にトレードオフがあるように見えます。ただし内部原因をこのテストだけで断定することはできません。
同じキャラクターを別ポーズにできるか
次は、ピンク髪のキャラクターを「同じキャラクターのまま椅子へ座らせる」テストです。
最初は椅子を追加しただけに近い結果
顔、髪、衣装はかなり維持されましたが、ポーズ変更は弱く、元画像の全身構造が強く残りました。
Positive Promptを強化
座面へ腰を置く、膝を曲げる、立ちポーズを維持しない、といったpositive promptを強くしても変化量は限定的でした。
なお前述の通りCFG=1ではnegative promptは使われないため、このテストで結果へ影響したのはpositive prompt側です。
ポーズ参照画像を追加
そこで、image_1に元キャラクター、image_2にシンプルな座りポーズ画像を入れ、役割を明確にしました。
完全に参照画像と同じポーズではありませんが、腰が座面へ移動し、膝が曲がり、衣装も座り姿勢向けに再構成されました。
ここで公式テンプレートの仕様が重要になります。Qwen-Image 2.1のComfyUI公式Image Editでは、image_1が編集対象で、追加画像はreferenceです。さらに「output follows image_1」とされています。
つまりimage_2のポーズをControlNetのように厳密拘束する設計ではなく、image_1を基本に編集しながら参考情報として使う、と考えた方が今回の挙動を理解しやすいです。
複雑な衣装も影響している可能性
今回のピンク髪キャラクターは、長い髪、多数のリボン、多層フリル、大きなスカート、花飾り、脚の装飾など、全身シルエットに非常に多くの特徴があります。
そのためポーズ変更時に、「キャラクターを維持する」ことと「全身構造を大幅に変更する」ことが競合している可能性があります。ただし今回の検証だけでは、衣装の複雑さとimage_1を強く保持するワークフロー仕様を切り分けられません。ここは仮説として扱います。
複数キャラクターを1枚にまとめる
Qwen-Image 2.1公式では、複数人物の個別画像を参照して新しい集合写真を作る例が紹介されています。
そこで、ピンク髪のキャラクターと、白シャツ＋青スカートの黒髪キャラクターを同時に入力しました。
まずは2人を白背景へ並べる
結果は非常に素直で、2人を白背景へ横に並べた画像になりました。
ここで注目したいのは、髪型や衣装が混ざらず、それぞれが別人物としてかなり明確に維持されたことです。
2人を新しい花園シーンへ統合
次は単なる横並びではなく、「2人が同じ花園で一緒に記念写真を撮っている」という新しいシーンを指定しました。
これは今回かなり良い結果になりました。
新しい花園の背景、共通した光源、同じカメラ視点、2人を近づけた構図まで生成され、「2枚を横に置いたコラージュ」ではなく、1枚のイラストとして成立しています。
また黒髪キャラクターは元画像と比べて、立ち位置や腕・上半身の配置が新しいシーンに合わせて変化しています。一方、複雑な衣装を持つピンク髪キャラクターは元ポーズを比較的強く残しました。
この差から衣装の複雑さがポーズ変更へ影響している可能性も感じましたが、image_1が編集対象として強く残る公式ワークフローの仕様もあるため、原因を衣装だけに絞ることはできません。
RTX 5070 Ti 16GBでの生成速度
最後の1536×1024、2人＋花園の生成ではログ上、サンプリングが約22秒、Prompt executedが35.41秒でした。
100%|████████████████████████████| 25/25 [00:22<00:00, 1.10it/s]
Prompt executed in 35.41 seconds1024×1536のImage Editでも、モデルがロード済みの状態では20～40秒台で終わるケースが多くありました。
一方、BF16 Diffusion Model、モデルの再ロード、大きな元画像をそのまま扱う場合などは1分以上かかるケースもあります。
今回使ったRTX 5070 Ti 16GB＋INT8構成は、結果を見ながら何度も条件を変えるImage Edit用途でも、十分実用的な速度だと感じました。
実際に試して分かった得意・不得意
| 用途 | 今回の評価 | 結果 |
|---|---|---|
| Text to Image | ◎ | INT8でも十分高品質 |
| 線画着色 | ◎ | ControlNetなしでも元線画への追従性が高かった |
| 配色参照 | ◎ | 別画像の色を自然に取り込めた |
| 小規模な色変更 | ○ | 色変更自体は成功 |
| 局所編集 | △～○ | 今回の条件では粒状感が目立つケースあり |
| INT8 | ◎ | 16GB環境では速度と品質のバランスが良好 |
| Diffusion BF16 | ○ | 16GBでも動作したがINT8よりかなり遅かった |
| キャラクター特徴保持 | ○～◎ | 顔・髪・衣装をかなり維持 |
| 大きなポーズ変更 | △ | image_1の構造保持が強い |
| ポーズ画像参照 | ○ | 2枚構成へ絞ると明確に改善した |
| 複数人物の保持 | ◎ | 2人を別人物としてきれいに維持 |
| 複数人物＋新規シーン | ◎ | 今回特に良好だった |
まとめ：Qwen-Image 2.1は「複数の画像を理解して再構成する」のが面白い
Qwen-Image 2.1を実際に試して、特に印象に残ったのはImage Editと複数画像参照でした。
線画着色では専用ControlNetを追加していないにもかかわらず、元の線をかなり残しながら自然に着色できました。別画像の配色を使うこともでき、複数人物を新しい花園へ統合するテストでは、それぞれの特徴を維持しながら1枚の新しいイラストへまとめられました。
一方、「元キャラクターの見た目を完全に維持したまま大きくポーズだけ変更する」用途は簡単ではありません。
ただしこれは単純にポーズ能力が低いというより、公式ComfyUIワークフローがimage_1を編集対象として強く扱い、追加画像をreferenceとして利用する設計であることも大きそうです。シンプルなポーズ参照画像を2枚目へ入れ、役割を明示すると結果は明確に改善しました。
また今回の局所編集では粒状感が出るケースがありました。Diffusion ModelをINT8からBF16へ変えても大きく改善しなかったため、量子化だけの問題とは判断できませんでした。
今回の検証から感じたQwen-Image 2.1の強みは、「元画像を完全固定した画像編集ソフト」ではなく、元画像や複数参照の内容を理解し、特徴を保ちながら新しい画像へ組み直す能力です。
RTX 5070 Ti 16GBでは、INT8版なら1024×1536のImage Editや1536×1024の複数参照まで十分現実的な速度で使えました。12GBでもINT8構成の動作例はあり、8～12GB向けにはGGUF＋CPU Encoderなどの低VRAM構成も存在します。
ローカル画像生成を「テキストから1枚作る」だけでなく、既存素材を編集・合成して新しい画像を作る方向へ広げたい場合、Qwen-Image 2.1はかなり面白い選択肢だと思います。
コメント