Qwen Image 2.1は参照10枚でも崩れない──2511との多参照比較と、AMD機で標準ノードだけの約4倍速

画像編集モデルのQwen Image 2.1が出ました。ComfyUIを更新したら、標準のワークフロー（テンプレート）にQwen Image 2.1系が3つ並んでいて、モデルのダウンロードもすぐ終わりました。

私がいちばん気になっていたのは、参照画像をたくさん入れたときの安定性です。前の世代のQwen Image Edit（2511）では、参照画像を3枚以上入れると結果が安定しなかった記憶があります。もう1つは速さです。170万円の自宅AI環境のうち、EVO-X2はAMDのRadeonで、画像生成はRTX 5090よりだいぶ遅い。ComfyUIの標準ノード（Model Sparse AttentionやEasyCacheなど）の範囲で、どこまで速くできるのか。

そこで、Claude Codeに、この2つをEVO-X2のComfyUIで確かめてもらいました。比べる基準は、ComfyUIの標準テンプレート「Image Edit（Qwen Image 2.1）」と「Image Edit（Qwen 2511）Int8」です。

先に結論を書きます。

• 多参照の安定性は、Qwen Image 2.1の圧勝でした。 参照1〜10枚の24枚すべてが、作例としてそのまま使える出来でした。2511（Lightning 4ステップ）は参照4枚で3枚中1枚、5枚では0枚。40ステップ版も、参照5枚で二重露光のように崩れました
• ただし、2.1は参照1枚目に忠実すぎます。 種（シード）を変えても立ち姿がほとんど変わらず、参照5枚以上では合成写真っぽさが出ます
• 素の状態では、2511（Lightning）のほうが2〜3倍速い。 2.1は25ステップ、Lightningは4ステップだからで、1ステップにかかる時間は、2.1が2511の3分の1ほどです
• 標準ノードだけで、2.1は約4倍速くなりました。 comfy kitchen attentionとEasyCacheを重ねると、参照3枚で211秒→55秒、参照5枚で329秒→88秒。2511（Lightning）より速くなります。ただし、無地の背景に「色むら」が出ます
• Model Sparse Attentionは、2.1の画像編集では働きませんでした

まず、結果をどうぞ

課題は、参照1枚目の男性に、2枚目以降の要素を1つずつ足していくものです。ジャケットを着せ、カメラを首から下げ、柴犬を足元に座らせ、背景をアーケード商店街にし……と、参照10枚では9つの要素を1枚の絵にまとめてもらいます。2.1は、この10枚分をすべて入れても、1つも落としませんでした。

検証の条件

• 機材：EVO-X2（Ryzen AI Max+ 395、Radeon 8060S）、ComfyUI 0.37.4（ROCm 7.2.1）
• 配線：ComfyUIの標準テンプレートのまま（下の表）。Claude Codeがテンプレートの中身を読み、同じ配線をComfyUIのAPIから組み立てて回しました
• 2511の参照4・5枚：2511の標準ノードは参照3枚までなので、参照を5枚まで入れられるカスタムノードを使いました。Claude Codeが、処理の中身が標準ノードと同じ（入れ口を増やしただけ）ことを確かめています。ただし、2511は参照1〜3枚で学習されているので、4・5枚は学習の範囲の外です
• 参照画像：Claude CodeがFLUX.2 [dev]で作った10枚（下の図）。比べる2モデルのどちらとも系統の違うモデルで作ることで、どちらかに有利にならないようにしています
• 種：11・22・33の3つ
• 採点：Claude Codeのサブエージェント4体が、参照の枚数ごとに分担しました（同じ枚数の2.1と2511は、同じ採点役が見ています）。見るのは、人物が同じか、足した要素が参照どおりか、背景、破綻、そして「作例としてそのまま使えるか」です

呼び方	モデル	ステップ	cfg
Qwen Image 2.1	Qwen Image 2.1（int8版）	25	1
2511＋Lightning	Qwen Image Edit 2511（int8版）＋LightningのLoRA	4	1
2511（40ステップ）	Qwen Image Edit 2511（int8版）、テンプレートの既定	40	4

2511の40ステップは、1枚に最大59分かかるので、種1つだけです。

なお、Qwen Image 2.1は、これまでのQwen Imageシリーズ（Apache 2.0）と違い、研究・評価の目的に限るライセンス（Qwen Research License）になりました。性能の比較・評価は、この目的の範囲です。生成した画像はライセンスの対象（Materials）に含まれない、というのが開発元の説明です。この記事の画像も、評価のために生成したものです。

多参照の安定性：2.1は10枚まで崩れない

	参照1枚	2枚	3枚	4枚	5枚	8枚	10枚
Qwen Image 2.1	3/3	3/3	3/3	3/3	3/3	3/3	3/3
2511＋Lightning	3/3	2/3	2/3	1/3	0/3	—	—
2511（40ステップ）	1/1	—	0/1	—	0/1	—	—

（作例としてそのまま使える枚数。2511は参照5枚まで）

2.1は、参照10枚でも9つの要素がすべて出ました。 自転車の折りたたみのヒンジや茶色のサドル、コーヒーを右手に持つところまで、参照どおりです。参照どうしの特徴が混ざることも、1回もありませんでした。

2511（Lightning）は、崩れる順番がはっきりしていました。

1. 参照2〜3枚から、全身の指示を外して腿から上に寄りがちになる（6枚中4枚）
2. 参照4枚で、白いTシャツが紺のニットやシャツとネクタイに替わり、カメラを首から下げずに手で構えたりする。顔も丸く、彩度が強くなる
3. 参照5枚で、3枚とも胸から上のアップになり、柴犬は抱きかかえられ、背景はアーケードではなく昼の街路になる

ジャケットと柴犬は、最後まで残りました。40ステップ版は、参照3枚でカメラが小さな銀色の塊になり、参照5枚では人物が半透明の二重露光のようになりました。頼んでいない帽子や鞄まで出てきます。私の「3枚以上で不安定」という記憶は、正しかったようです。

一方で、2.1にも弱点があります。 参照1枚目に忠実すぎて、種を変えても立ち姿と構図がほとんど変わりません。参照5枚以上では、参照のアーケードの写真の上に人物と犬を置いたような仕上がりになり、足元の影が薄く、照明も背景と合っていません。2511のほうが「絵として」は自由に動くので、構図の幅がほしいときは、2511にも出番がありそうです。

参照画像の出どころで、結果は変わるか

参照画像を2.1自身で作れば、2.1に有利になるのでは、という心配もありました。そこでClaude Codeは、参照1〜3枚目を2.1で作ったものに替えて、同じ種でも回しています。

• 2.1：どちらの参照でも、結果は変わりませんでした
• 2511（Lightning）：顔と要素の忠実さは変わりませんでした。ただ、FLUX.2の参照ではコントラストと彩度が強く出て、2.1の参照のほうが自然な質感でした

2.1が有利になるどころか、2511のほうが2.1の参照と相性が良かった、という結果です。本番をFLUX.2の参照にしたのは、2511に少し厳しい条件だったのかもしれません。

速さ：1ステップは2.1のほうが軽い

素の状態（標準テンプレートのまま）の、1枚あたりの時間です。種だけを替えて2枚目以降を作るときの時間で、1枚目は、これに文字と参照画像の読み込み（符号化）の時間が加わります。

参照	Qwen Image 2.1（25ステップ）	2511＋Lightning（4ステップ）	2511（40ステップ、符号化込み）
1枚	88秒	33秒	664秒
3枚	211秒	92秒	1,838秒
5枚	352秒	177秒	3,542秒
10枚	852秒	—	—

2511（Lightning）のほうが2〜3倍速いのですが、これは4ステップで済むからです。1ステップあたりに直すと、参照3枚で2.1は8.5秒、2511は23秒。1ステップにかかる時間は、2.1が2511の3分の1ほどです。

理由は、標準テンプレートに入っている「Qwen Image 2.1 Cache」ノードです。2.1は、参照画像の分の計算を最初に1回だけして取っておき、各ステップで使い回します。このキャッシュを切ると、1ステップは18.7秒になり、2511とほぼ同じになりました（参照5枚では、2.1が14秒、キャッシュを切ると39秒、2511が44秒）。参照が多いほど、このキャッシュが効きます。

逆に、2.1は1枚目の符号化が重く、参照1枚で68秒、参照10枚では692秒（11分半）が上乗せされます。2.1は参照画像を約1024四方のまま文字エンコーダ（Qwen3-VL 8B）に読ませるためで、2511は384四方相当に縮めてから読ませています。種だけを替えて何枚も作るなら、符号化は1回で済みます。

標準ノードで高速化：約4倍まで

Claude Codeが、2.1にComfyUIの標準ノードを足して測りました。どれも、テンプレートのモデルの後ろにノードを1つ挟むだけです。

設定	参照3枚	参照5枚	既定との似かた（SSIM）	見た目
既定の設定	211秒	329秒	—	—
comfy kitchen attention	121秒（1.7倍）	168秒（2.0倍）	0.998／0.892	ほぼ同じ
EasyCache	91秒（2.3倍）	155秒（2.1倍）	0.986／0.950	無地の背景にむら
LazyCache	81秒（2.6倍）	160秒（2.1倍）	0.959／0.841	顔の肌がつるっとする
kitchen＋EasyCache	55秒（3.9倍）	88秒（3.8倍）	0.986／0.873	顔はほぼ同じ、背景にむら
Model Sparse Attention	221秒	340秒	1.000／1.000	働かない（同じ絵）

（種44。SSIMは同じ種の既定の設定の画像との似かたで、1なら完全に同じ絵）

• comfy kitchen attention（ModelAttentionBackendノード）：注意の計算を、INT8に量子化して計算する方式に切り替えます。NVIDIAとAMDのGPUで使え、画質の違いは目で見て分かりません。参照5枚でSSIMが0.892と下がったのは、犬の姿勢などが少しずれたためで、質が落ちたわけではありません
• EasyCache・LazyCache：途中のステップの計算を省き、前のステップの結果を使い回します。25ステップのうち14〜16回を省いていました（ComfyUIのログより）
• Model Sparse Attention（BlockSparseAttentionノード）：注意の計算を、関係の強いブロックに絞って速くするノードです。列が長いほど効く、大きな画像や動画向けの仕組みで、既定では、画像のトークンが12,288個（2048×1536ほど）以上のときにだけ働くので、1024四方（4,096個）では何もしません。下限を0にしても働きませんでした。2.1は参照画像の分をキャッシュしているので、画像のトークンが「文字＋参照＋画像」の長い列を参照する形になります。このノードはそれを相互注意（cross-attention）と見なし、元の計算のまま通します（ComfyUIのログで確認）

同じ設定を同じ種でもう一度回すと、画素まで同じ絵が出ました。設定ごとの違いは、たまたまではなく設定そのものの違いです。

顔を拡大すると、違いが出たのはLazyCacheでした。肌がなめらかになって、しわが減ります。人物の作例には向かなそうです。kitchen＋EasyCacheの顔は、既定の設定とほとんど見分けがつきません。

無地の背景の「色むら」を確かめる

EasyCacheを使った画像は、顔や服は既定の設定とほぼ同じでした。ただ、無地の背景に、うっすらとしたむらが出ます。ここは、少していねいに見ておきます。

なぜ色むらを見るのか

• 無地の背景は、作例でいちばんよく使い、いちばんむらが目立つ場所です。 人物の宣材写真、商品写真、切り抜いて合成する素材。どれも無地の背景が基本です
• 画像全体の数字では、ほとんど差が出ません。 EasyCacheの画像も、SSIMは0.986と「ほぼ同じ」です。むらは、明るさの差が1階調にも満たない、ゆるやかな揺らぎだからです
• 後から手を加えると、隠れていたむらが浮き出ます。 明るさやコントラストを上げる、色を補正する、といった仕上げの作業をすると、見えなかった揺らぎが強調されるからです。そのまま使うなら気にならなくても、素材として加工するなら効いてきます
• 省いた計算の影響は、背景に先に出ました。 EasyCacheとLazyCacheは、ステップの半分以上を省いています。今回の画像では、その影響が顔や服より先に、平らな背景に現れました

そのままでは、人の目にはほとんど分からない

上段は、参照3枚の画像から、人物の左側の無地の背景を切り抜いたものです（287×532画素）。5枚を並べても、違いはほとんど分かりません。

そこで下段では、Claude Codeに画像処理でむらをわざと目立たせてもらいました。

1. 照明による、なだらかな明るさの傾きを取り除く（半径の大きいぼかしを引く）
2. 画素ごとの細かい粒をならす（半径の小さいぼかしをかける）
3. 残った明るさと色の揺らぎを10倍に拡大する

5枚とも、まったく同じ処理です。図の「むら」の数字は、強調する前の揺らぎの大きさ（256階調での二乗平均の平方根）です。

• 既定の設定とkitchen：むら0.48で同じ。強調しても、うっすらとした濃淡が見える程度です
• EasyCacheとkitchen＋EasyCache：むら0.93〜0.94と、約2倍。赤・緑・紫の色のしみが、画面全体に浮き出ます。kitchenを重ねても変わらないので、むらはEasyCacheから来ています
• LazyCache：むら0.33と、逆に小さい。ただし、なめらかすぎて、強調すると等高線のような縞（バンディング）が出ました。画像は明るさを256段階でしか持てないので、揺らぎがなさすぎると、段の境目が縞になって見えます。強いトーン補正をかけると、これも表に出てきます

使い分けるなら

同じ種なら、kitchen＋EasyCacheでも構図は既定の設定とほぼ同じです。なので、下見と本番で設定を分けられます。

• 下見（種や言い回しを探す）：kitchen＋EasyCache。参照3枚なら1枚55秒で、4倍の枚数を試せます
• 本番：気に入った種を、kitchenだけで描き直す。約2倍速く、画質は既定の設定とほぼ同じです
• LazyCache：人物の作例には使わない

人間がやったこと、Claude Codeに任せたこと

人間（私）	Claude Code
検証の発案（多参照の安定性と、標準ノードでの高速化）、比べる基準にする標準テンプレートの指定	ライセンスの整理、テンプレートの配線の読み取りと、APIでの組み立て
2511をLightningと40ステップの両方で回す判断、参照の枚数（1〜5枚、2.1は8・10枚も）	参照画像の設計と生成（FLUX.2を本番、2.1製を出どころの確認用に）、5枚用のカスタムノードが標準ノードと同じ処理かの確認
モデルのダウンロード、ComfyUIの再起動	比較用の67回の生成の無人実行、時間の集計、SSIMの計算、Sparse Attentionが働かない理由の特定
記事にする判断と軸の選択（多参照＋高速化）、色むらを強調して見せる案	採点（参照の枚数ごとにサブエージェント4体）、色むらの強調処理、REPORT、この記事の下書きと図
この記事のレビュー

正直、気になっていること

• 1つの条件につき3枚です（2511の40ステップは1枚）。崩れる順番などは、傾向として読んでください
• 採点はClaude Codeのサブエージェントによるもので、私は1枚ずつの採点はしていません。 採点役どうしで基準が揺れた所もあります。2.1の合成写真っぽさは、参照5枚の採点役は「軽い破綻」としましたが、参照8・10枚の採点役は減点しませんでした
• 課題は「人物に物を足していく」1種類だけです。 人物2人の合成や、画風の転写などは試していません
• 2511の参照4・5枚は、学習の範囲の外です。 2511にとっては無理をさせた条件で、2511の設計どおりの使い方は参照3枚までです
• 速さは、種1つで測った数字です。 既定の設定の参照3枚でも、同じ条件で193〜230秒のばらつきがありました
• ほかの機材では、倍率が変わるかもしれません。 comfy kitchen attentionの効きは、GPUによって違うはずです。測ったのはEVO-X2（Radeon 8060S）だけです

まとめ

• Qwen Image 2.1は、参照10枚でも9つの要素を1つも落とさず、24枚すべて作例として使える出来。2511は参照4枚から崩れ始め、5枚で使える出来は0枚だった
• 2.1の弱点は、参照1枚目に忠実すぎること。構図がほとんど動かず、参照が多いと合成写真っぽくなる
• 素の状態では2511（Lightning）が2〜3倍速い。ただし1ステップにかかる時間は、参照をキャッシュする2.1が2511の3分の1ほど
• 標準ノードだけで、2.1は約4倍速くなる。comfy kitchen attentionは約2倍で画質はほぼそのまま、EasyCacheを重ねると約4倍で、2511（Lightning）より速い
• EasyCacheは無地の背景に色むら、LazyCacheは肌のつるつると縞。むらは人の目では分かりにくいので、加工する素材なら強調して確かめておく
• Model Sparse Attentionは、2.1の画像編集では働かない

多参照で崩れないモデルが、AMD機でも1枚1分を切る。EVO-X2の画像生成にも、出番が回ってきそうです。

五十路の朝食は、Uberで朝マックでした（イミフ