780MでQwen-Image-2512を動かす、そして実在しなかった「Qwen-Image-2.0」

780mcomfyuiimage-generation

ComfyUI-TheRock経由でLTX VideoやMiniMax Music3をすでに動かしている、同じ780Mで最新のオープンウェイト画像モデルを試したくなった。Krea 2が候補として真っ先に浮かんだ。6月にオープンウェイトが公開され、FP8量子化ならこの780Mの32GB共有メモリにも収まるサイズだった。決める前に、他に比較する価値があるものがないか確認した。

ダウンロードできないモデル

比較の過程で出てきたのがQwen-Image-2.0で、2月に発表された数字は良く見えた。70億パラメータ、Apache-2.0、ネイティブ2K出力。複数の記事がこれをオープンウェイトだと書いていたが、そのどれもが間違っていた。ComfyUI本体のリポジトリに立っていたこのモデルの対応要望issueに、メンテナーから一行だけ返信がついていた。OSSモデルではない、と。

Alibabaの実際のオープンリリースは別の命名規則を使っていて、セマンティックバージョン番号ではなく年月で日付管理されている。実際にダウンロードできて、Alibaba自身のブラインド評価で現時点最強のオープンソースモデルとされているのは、2025年8月の元となる20BモデルへのアップデートであるQwen-Image-2512だ。「2.0」を扱った記事の内容自体は、発表について正確だった。それはAlibaba自身のAPIの向こう側にしか存在しない製品についての話だった。

セットアップ

ComfyUI-TheRockにはQwen-Imageのアーキテクチャがすでに組み込まれていて、収まるサイズまで量子化するのに必要なComfyUI-GGUFノードもあった。ファイル3つ、合計約22.87GB。Q4_K_M量子化の拡散モデル(13.24GB)、fp8のQwen2.5-VL-7Bテキストエンコーダー(9.38GB)、VAE(0.25GB)。Q4_K_Mなら32GBの共有プールに約9GBの余裕が残る。単体GPUがない場合、これは重要な数字になる。予算を超えたときに逃げ込める別のVRAMがなく、PC上の他の全てが必要としているのと同じメモリを使うことになるからだ。

最初の生成

1024x1024、20ステップの画像生成に19分41秒かかった。起動ログがその大半を説明していた。モデルの6022MBがGPUに載り、6716MBがシステムメモリに置かれて必要に応じて入れ替わる。重みの約半分が毎ステップ行き来する計算だ。各ステップは安定して57秒で着地した。2ステップ目は1ステップ目とほぼ同じ時間で、一回きりのウォームアップという説明を除外できた。GPUメモリとシステムメモリ間の絶え間ない入れ替えが、ここでのペースを決めている。

これを同じチップの同じ1024x1024で測ったSDXLの約4.1秒/ステップと並べると、1ステップあたり約14倍遅い計算になる。量子化前のパラメータ数で言えば約8倍のモデルだ。SDXLはVRAMにまるごと収まるが、Qwen-Image-2512はQ4_K_Mにしても収まらない。この差がギャップの大半を占めている。

VAEデコードは問題なく終わった。これをわざわざ書くのは、同じチップでのZLUDA構成がまさにこのステップで実際にcuDNNクラッシュを起こしていたからで、あの記事で最後まで閉じられなかった2つの未解決issueのうちの1つだった。

実際のスプライトでテスト

次のテストでは実際のゲームアセットを使った。Craymel Ballのキャラクター、P1とP2の2体で、スプライトシートは以前の作業からすでにディスクに残っていた。1回目はテキストの説明だけから生成した。2回目は実際のスプライトフレームに対してimg2imgを実行した。1つのきれいなポーズに切り出して、元々120pxしかない高さから拡大したものだ。

img2imgの方が速く終わった。理由を確認するのに少し時間がかかった。このComfyUIのビルドでは、denoiseを1.0未満にしてもステップ数は減らない。プログレスバーは設定に関わらず20ステップのままだ。本当の違いは解像度だった。スプライトフレームは512x768と432x768で、最初のテストの1024x1024よりずっと小さい。ピクセル数が少ない分、1ステップあたりの時間が57秒から33秒程度まで下がった。img2imgの出力は、実際の衣装の色とシルエットを保っていて、説明だけから作ったテキスト版では再現できなかった部分だった。

アートプランからの一場面

最後の生成は、もっとテストらしくない題材を狙った。個人的に進めている世界観構築プロジェクトのアートディレクション資料をもとにした、写実的な夕暮れの街並みだ。その資料は狙っているルックをかなり具体的に指定していた。橙から紺へのグラデーション、逆光のシルエット、電柱間に張られた電線、光源代わりの自動販売機、赤いポスト、おでん屋台、銭湯の入口。これは手描き風のトゥーン調のゲーム内表現を狙って書かれたものだ。それでも色と構図の指示はそのままテキストプロンプトに変換できた。1280x768、20ステップで約17分。アスペクト比は違うが、ピクセル数が近い範囲に収まったため、最初のテストとほぼ同じ時間になった。

結果

4回の生成から、確かな数字が1つ得られた。専用のVRAMを持たない内蔵GPUでも20B級のモデルは動き、解像度に応じて1枚あたり15〜20分かかる。ボトルネックは約6GBの読み込み済みの重みと、システムメモリに残る残りの部分との間の絶え間ない入れ替えだ。もっと小さい量子化ならこのギャップの一部を縮められるだろう。長辺768px未満まで解像度を落とせば、ディテールを犠牲にする代わりにもっと縮められるはずだ。

これより前の30分の調査は、ダウンロードできないモデルを指し示していた。GitHub issueについた2行のコメントの方が、その発表を扱った複数の記事より頼りになった。