Qwen-Image-2.1 GGUF：量子化ビルドが実際にあなたに課すコスト

の公式GGUFは存在しないQwen-Image-2.1。その名前を冠した.ggufファイルはすべて、事後に他の誰かが、ベンダーの7B拡散トランスフォーマーを手に取り、その重みをより低い精度で再エンコードして作り出したものだ。GGUFとは、ローカル推論スタックが読み込む単一ファイル形式の量子化チェックポイントのことである。この一文が、読者がまず抱く疑問に答えつつ、このページが解決するより難しい問いを立ち上げる——画像モデルの量子化が実際に圧縮しているのは何か、そのファイルがそのままでは何を欠いているのか、各レベルが時計（所要時間）だけでなく絵の上で何を犠牲にさせるのか、そして、重みに付随するライセンスの下でそれを再配布するには何が必要か、という問いである。

このページの日付を決めているのは、それが報じるニュースではなく、モデルそのものです。Qwen-Image-2.1 は2026年9月20日に Hugging Face と ModelScope で公開され、コミュニティによるその量子化版も同日に続きました。leejet、Abiray、RealRebelAI のリポジトリはすべて9月20日に作成され、unsloth のものは9月21日に作成されています。これはこのページが書かれた23日前です。その時系列についてここで繰り返し説明する必要はありません。読者が「qwen image 2.1 gguf」と入力して求めているのは操作マニュアルであり、これがまさにそれです。

このモデルのGGUFとは何か、そして何ではないか

最初に腹に落とすべきなのは、そのファイルが断片だということだ。Qwen-Image-2.1は単一のネットワークではない。拡散トランスフォーマーに、視覚言語テキストエンコーダー、さらにオートエンコーダーを組み合わせたものだ。その名前で出回っている量子化には、そのうち最初のものしか含まれておらず、リポジトリ自体がそう述べている。UnslothのQwen-Image-2.1 GGUF向けカードは、次の一行でそれを言い表している。「GGUFはデノイザーだけなので、VAEとQwen3-VLテキストエンコーダーを一緒に必要とする。」

では、GGUFのダウンロードとはトランスフォーマーのことだ——視覚生成コンポーネントにおける32のシングルストリームDiT層、7Bパラメータ——が、より低い数値精度で再表現されたものだ。テキストエンコーダーとVAEは元の形式のまま残るか、別々の人々によって、別々のリポジトリで個別に量子化される。これが、多くの読者が頭の中に思い描いているテキストモデルの状況との構造的な違いだ。チャットモデルのGGUFをダウンロードしたときは、そのモデルそのものをダウンロードしたことになる。ここでは、パイプラインの3分の1をダウンロードしたにすぎない。

これらはどれもベンダーのパッケージではありません。ベンダーのリポジトリ Qwen/Qwen-Image-2.1 は Diffusers レイアウトのリリースであり、model_index.json、transformer/、text_encoder/、vae/、scheduler/、processor/ を含み、2026年10月13日に確認したそのファイル一覧には、いかなる種類の .gguf ファイルも含まれていません。量子化はコミュニティの成果物であり、それぞれの作者の名の下に公開されたもので、ベンダーの承認ではなくベンダーのライセンスを継承します。

テキストモデルの量子化に関する知見は、なぜ移転しないのか

GGUFについての定説は言語モデルに由来しており、おおよそ次のようなものだ。Q8_0は実質的にロスレス、Q4_K_Mが最適点、Q3未満は妥協であり、品質はフル精度の参照に対するパープレキシティやKLダイバージェンスで測られる。しかしそのほとんどは画像モデルには当てはまらず、その理由については正確に述べておく価値がある。

拡散トランスフォーマーにはパープレキシティが存在しない。このモデルはスコアを計算できるトークン分布を出力するのではなく、VAEがピクセルにデコードする潜在表現を出力する。この側の世界に存在する指標——参照レンダリングに対するLPIPSやSSIM——は、比較の両側で同じシード、同じプロンプト、同じサンプラー設定を必要とし、それでもなお正確さではなく知覚的な距離を測っているにすぎない。つまり「Q4_K_Mはどれだけのコストを私に課すのか」という問いには、テキストモデルの場合のように公表された単一の数値は存在せず、それを引用している人は誰であれ、ある一つのシードにおける一つの測定値を引用しているだけなのだ。

第二に、そしてより重要な点として、画像モデルでは平均ビット幅よりも、どのテンソルがビットを失ったかのほうが重要だ。画像構造を担うアテンション射影とMLP経路は、丸められると目に見えて劣化する一方、小さな正規化テンソルや変調テンソルはほとんど何でも許容する。したがって、すべてのテンソルに均一な目標を適用する変換は、同じ名目上のラベルを持ちながら敏感な層を保護する変換よりも見劣りして見えることがある——これはまさに、この作業に携わっている人々が発見したことだ。私たちが見つけられた中で最も明示的な量子化の注記を公開しているRealRebelAIは、「標準的な汎用Q4_K_M変換は、参照INT8モデルと比較して微細構造と解剖学的構造に目に見える品質劣化を示した」と述べており、同社自身のビルドではそれを回復するためにQ4_K_Mファイル内でアテンションのQ/K/V/OutをQ8_0に保っている。ファイル名のラベルは基本量子化であって、ポリシーではない。

第三に、失敗の仕方は種類が異なる。テキスト量子化は主に流暢さとして劣化し、しかも穏やかに劣化する——少し劣った文でも、依然として文ではある。低い段階での画像量子化は、明らかで、時には使い物にならない形で失敗する。手や人体構造、細かいテクスチャ、小さな文字、そして——ピクセルのアーティファクトですらないため見落としやすいもの——プロンプトへの追従性である。もしビルドが長い指示の半分に従わなくなったら、それは量子化のコストであり、二つの良好なレンダリングを並べた比較には現れない。

はしご——形容詞ではなくファイルで

ファイルサイズは、この中で判断ではなく厳然たる事実と言える唯一の部分だ。なぜなら、どのリポジトリもそれぞれ独自の一覧を公開しているからである。2026年10月13日時点で見ると、最もダウンロードされているコミュニティ量子化の2つは互いにわずかに食い違っており、それ自体が示唆に富んでいる。

• Unsloth Dynamic 2.0（12ファイル）：F16 14.23 GB、Q8_0 7.64 GB、Q6_K_XL 6.72 GB、Q6_K 6.27 GB、Q5_K_M 5.39 GB、Q5_K_S 4.50 GB、Q4_K_M 4.20 GB、Q4_K_S 3.91 GB、Q3_K_XL 3.61 GB、Q3_K_M 3.17 GB、Q3_K_S 2.72 GB、Q2_K 2.47 GB。

• leejet / stable-diffusion.cpp（7ファイル）: Q8_0 7.69 GB、Q6_K 6.00 GB、Q5_0 5.07 GB、Q4_K 4.20 GB、Q4_0 4.20 GB、Q3_K 3.27 GB、Q2_K 2.56 GB。

• Abiray（6ファイル）：Q8_0 7.59 GB、Q6_K 5.88 GB、Q5_K_M 5.01 GB、Q4_K_M 4.19 GB、Q4_K_S 4.06 GB、Q3_K_M 3.19 GB。

• RealRebelAIは、単純なレベルではなく-HQv3というサフィックスを付けた混合精度のラダーを公開しており、モジュールごとの精度を表で文書化している。基本の量子化はQ2_KからQ8_0まで及ぶ。

ばらつきは現実だ。Q8_0 は3つの配布元で7.59～7.69 GBにまたがり、Q6_K は5.88～6.27 GBにまたがる — 同じ公称レベルで0.4 GBの差があり、これは混合精度ポリシーがバイト数として現れているものだ。ファイル名だけで2つのビルドを比較している人は、成果物ではなくラベルを比較している。

反対側の規模感としては、参照用のF16トランスフォーマーは14.23 GBで、Comfy-Orgの再パックに含まれるベンダー自身のbfloat16拡散コンポーネントも14.23 GBです。したがって、Q4クラスのGGUFはトランスフォーマーではおよそ3.4倍の削減となりますが、テキストエンコーダーでは別途量子化しない限りまったく削減されません。

各段の費用はいくらか、情報源がそう述べている場合

このモデルについて、レベルごとの測定された品質コストを公表している人はほとんどいない。そして誠実な対応は、出回っている3種類の主張を区別することだ。

• メモリの目安、コミュニティ報告。 Abirayのリポジトリでは、各ファイルに推奨VRAMプロファイルを対応付けている。Q8_0 7.59 GBは「12 GB+（ほぼロスレスな忠実度）」、Q6_K 5.88 GBは10～12 GB、Q5_K_M 5.01 GBは8～10 GB、Q4_K_M 4.19 GBとQ4_K_S 4.06 GBは6～8 GB、Q3_K_M 3.19 GBは4～6 GBで「極端な低予算／最小VRAM」。これらは公開者自身の経験則であり、ベンダーの仕様でも、当方が再現できたベンチマークでもない。また、トランスフォーマーファイル単体について述べたものなので、テキストエンコーダーに必要な余裕はその上にさらに乗る。

• 量子化ツールの提供元が報告した、単一シードによる測定比較。Unslothは、パイプラインのエンコーダ側について1組の数値を公開している。同社のDynamic 2.0 4ビットテキストエンコーダと、均一なQ4_K_Mエンコーダとの比較で、どちらも同一のシードを使い、デノイザーとVAEを固定した条件において、LPIPS 0.029およびSSIM 0.959、5.15 GB対5.03 GB、36.5秒対39.0秒というものだ。これはファイルを販売している当事者による、単一シードでの1回の測定であり、このモデルについて2つの量子化ポリシーを比較した、我々が特定できた唯一の公開定量的比較である。

• 定性的な失敗リスト、コミュニティによる報告。 RealRebelAIは、低ビット量子化が依然として影響しうるもの——「細部、手や解剖、タイポグラフィ、プロンプトへの追従性、編集の忠実度、テクスチャの一貫性」——を挙げ、劣化が見られる場合は一段階上げるよう勧めている。Q3_K_MとQ2_Kはメモリに制約のあるシステム向けであり、「保護された高精度レイヤーにもかかわらず、品質低下が進み続ける可能性がある」と明言している。

何が公表されていないかは、何が公表されているかと同じくらい重要です。Qwen-Image-2.1 の量子化品質についてのベンダー側の記述は一切なく、いかなる GGUF ビルドに関する独立したベンチマークも存在せず、また、われわれが探し得た限りでは、具体的なコンシューマー向けハードウェア上でのスループット表も誰も公表していません。メモリのトレードオフの向きは確実であり、速度のトレードオフの向きも概ね確実ですが、忠実度のコストの大きさは公には確立されておらず、このページがそれをあなたに代わって推定することはありません。

実際に動かしているのは何なのか

これほど新しいフォーマットにしては、ランタイム周りの状況は異例なほど落ち着いており、これは通常のGGUFの状況と比べて実に大きな利点だ。

• stable-diffusion.cpp — 画像モデル向けGGUFのリファレンス実装です。プロジェクトのニュース一覧には、2026年9月20日にQwen-Image-2.1へのDay-0サポートを記録しており、同モデル専用のページも公開されています。コマンドラインでは量子化された拡散モデルを直接指定します：--diffusion-model qwen-image-2.1-Q4_K_M.gguf --vae qwen_image_2.1_vae_bf16.safetensors --llm Qwen3-VL-8B-Instruct-UD-Q4_K_XL.gguf、さらに--steps 20 --cfg-scale 6.0 --sampling-method eulerを公開元自身のサンプルに沿って指定します。

• カスタムノード経由のComfyUI。 これがほとんどの読者が取るルートであり、何かをインストールする前に知っておく価値のある厄介な点が一つあります。多くの量子化モデル作者が指し示すリポジトリはcity96/ComfyUI-GGUFです。stable-diffusion.cppの作者は自身のフォークであるleejet/ComfyUI-GGUFを公開しており、そのREADMEには、こちらを優先するよう明示する指示が、「city96リポジトリはもはや活発にメンテナンスされていないようだ」という明記された理由とともに載っています。これは一方の当事者が他方について述べた主張であり、しかも古いものです。city96/ComfyUI-GGUFのコミット履歴は、直近の活動が2026年1月であることを確かに示しています。ComfyUI自身のQwen-Image-2.1に関する公式ドキュメントページには.safetensorsの重みしか記載されておらず、GGUFには一切言及されていません。そのため、カスタムノードは任意ではなく、ベンダー公認でもありません。どちらのローダーもファイルをComfyUI/models/diffusion_models/に配置し、GGUF拡散モデルローダーを通じて公開します。

• llama.cpp / ggml — このモデル用のサンプラーではありませんが、このフォーマットの起源であり、これらのファイルを生成するツールチェーンです。leejet と Abiray の両リポジトリが明示的にクレジットしています。誰も公開していないレベルが欲しいなら、これで変換するのです。

• Unsloth Desktop — stable-diffusion.cpp と並ぶサポート対象のフロントエンドとして、unsloth リポジトリで名前が挙げられています。

ひとつのランタイムが際立ってそれを読み込みません：Diffusers。ベンダー自身のクイックスタートはQwenImage21Pipelineを bfloat16 safetensors リポジトリ上で動かすものであり、そのパイプラインに GGUF の経路はありません。Diffusers を使いたいのなら、あなたは量子化ファイルの対象者ではありません。量子化ファイルを使いたいのなら、行き着く先は stable-diffusion.cpp か ComfyUI のグラフです。

実際に人々を妨げている部分

このフォーマットに関するあらゆる失敗報告は、同じ一点に行き着く。GGUF がトランスフォーマーなので、パイプラインの残りは、正しいフォーマットで、正しいリポジトリから、手作業で組み立てなければならない。対象範囲には3つのコンポーネントがあり、そのうちの1つには罠が仕込まれている。

• テキストエンコーダー。 Qwen-Image-2.1 は Qwen3-VL 8B を条件付けに使用しており、そのエンコーダーはフル精度では Transformer よりも大きく、Comfy-Org のリパックでは bfloat16 で 17.53 GB であるのに対し、拡散モデルは 14.23 GB です。同じリパックには量子化された代替版が 9.35 GB（int8）と 6.31 GB（w4a8）で存在し、さらに独立した GGUF としても存在します。ベンダーはファーストパーティの Qwen/Qwen3-VL-8B-Instruct-GGUF を公開しており、F16 は 16.39 GB、Q8_0 は 8.71 GB、Q4_K_M は 5.03 GB です。このエンコーダー GGUF は、隣り合っている Transformer GGUF とは異なりベンダーの成果物であることに注意してください — パイプラインの両半分は、出自が異なる別々の公開元から提供されています。

• VAE です。単一のファイル、qwen_image_2.1_vae_bf16.safetensorsで、Comfy-Org の再パッケージ版では 0.68 GB です。小さいながら、最もよく互換性があると决めてかから此時れるコンポーネントであり、実際には互換性がありません。stable-diffusion.cpp のドキュメントには、以前の Qwen Image および Wan 2.2 の VAE 重みは、Qwen Image 2.1 の VAE 重みとは互換性がないと記載されています。間違った方を組み合わせると、グラフは読み込まれても誤った画像が生成されます。

• 編集したいなら、ビジョンプロジェクターも必要です。 テキストから画像の生成はまだ簡単な半分にすぎません。画像編集には、エンコーダー用に別途マルチモーダルプロジェクターが必要です。stable-diffusion.cpp のドキュメントでは、エンコーダーのリポジトリから mmproj-Qwen3VL-8B-Instruct-F16.gguf（1.16 GB）もダウンロードし、--llm_vision で指定するよう読者に指示しています。また、参照画像1枚ごとに -r を繰り返す必要があります。トランスフォーマーのみの GGUF とテキストエンコーダーの組み合わせは、テキストから画像を生成するパイプラインにすぎず、それ以上のものではありません。

さらに知っておく価値のあるアップロードが2つあります。このリリースには、プロンプトを書き換えるエンコーダーも2つ同梱されています — Qwen-Image-2.1-PE-T2IとQwen-Image-2.1-PE-I2Iで、どちらも9Bモデルをファインチューニングしたもので、ベンダーは画像モデルの前段で実行することを推奨しています。そしてこれらも量子化が進められています。LightX2VプロジェクトによるT2IリライターのGGUFビルドが2026年10月12日にHugging Faceに登場し、複数のコミュニティビルドも並んでいます。また、このモデルのより際立った特徴の一つであるアルファチャンネルは、量子化を経ても維持されますが、すべてのコンテナで保持されるわけではありません。拡散モデルはスイッチではなくプロンプトから透過を判断し、アルファが保持されるのは.pngおよび.webp出力のみです。

GGUF自体の周辺におけるメモリ計画は、ランタイムのドキュメントが本当に具体的に記述している数少ない領域である。stable-diffusion.cppは、ステップに依存しないテキストと参照画像のキーおよび値（バリュー）をプレフィックスキャッシュとして再利用し、32層モデル・4096トークンのプレフィックスにおける条件あたりのコストを公表している。FP32で4 GiB、FP16で2 GiB、q8_0で1.0625 GiB、q4_0で0.5625 GiBである。キャッシュの量子化は、重みの量子化とは別個の第二のトレードオフであり、デフォルトでは無効になっている。また、量子化されたキャッシュストレージは、ドキュメントが隠すのではなく明示している追加の丸め誤差を導入する。

量子化が継承するライセンス

これは多くのGGUFページが省略しているセクションであり、このモデルにおいては、あなたにできることを変える部分です。

ベースとなる重みは寛容なライセンスの下では配布されていません。Qwen/Qwen-Image-2.1リポジトリにはlicense: otherが記載されており、license_name: qwen-researchが添えられています。また、LICENSEファイルはQwen Research License Agreementであり、リリース日は2026年9月20日です。2026年10月13日に全文を読んだところ、その運用上の許諾は、「Materials を非商業的目的のみのために使用、複製、配布、コピー、派生著作物の作成、および改変すること」に対する、非独占的、世界的、譲渡不可、ロイヤルティ不要のライセンスであり、「Non-Commercial」は本契約内で「研究または評価目的のみ」と定義されており、商業利用は、本契約が指定するアドレスへの電子メールによる申請で得られる別個のライセンスに振り分けられています。

量子化されたチェックポイントはそれらの素材の二次的著作物であり、つまりGGUFの再配布は同契約に基づく再配布であって、それに付随するあらゆる条件を引き継ぐ。そのうち3つは具体的である：

• あなたはこの契約を引き継がなければなりません。 第3条(a)は、本素材または派生物を受け取るすべての人に、ライセンスの写しを提供することを義務付けています。ライセンスタグがあるだけで契約文書が含まれていないGGUFリポジトリは、ダウンロード数がいくつであっても準拠していません。

• 変更した箇所を明示しなければなりません。 第3条(b)は、変更されたファイルに、変更が加えられた旨を明示する目立つ表示を付すことを求めています。再エンコードされた重みファイルは、変更されたファイルに該当します。

• 帰属表示の通知を逐語的に記載しなければなりません。 第3条(c)は、通知テキスト — 「Qwen is licensed under the Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. All Rights Reserved.」 — を、複製物とともに配布される「Notice」テキストファイル内に保持することを求めています。

量子化を行う者およびその結果を基に構築する者には、さらに2つのルールが適用されます。素材またはその出力を用いてAIモデルを訓練、微調整、改良し、その後それを配布する場合、製品ドキュメントに「Built with Qwen」または「Improved using Qwen」を目立つように表示する必要があります。また、「Qwen」を派生作品の主要な名称または識別子として使用することはできませんが、「fine-tuned from Qwen Image」のような説明的な使用は許可されています。準拠法は中国法であり、杭州市の人民法院が専属管轄権を有します。

実用的な結論は一行に尽きる。そして、形式がそれを隠しているので、はっきり述べておく価値がある。重みを量子化してもライセンスは変わらない。このページのために調査したあらゆるリポジトリは以下を記載している：license_name: qwen-research そして、ベンダーの LICENSE ファイルにリンクしている。また、GGUF ファイルのダウンロード数は商用権の付与ではない。対照的に、以前の Qwen 画像シリーズは寛容だった——モデルカード（Qwen-Image、Qwen-Image-Edit、Qwen-Image-Edit-2511 および Qwen-Image-2512）はすべて apache-2.0 と記されていた（2026年10月13日時点）——そして Qwen-Image-2.1 はそのパターンの破れである。商用パイプラインが目的なら、ライセンスは最初に読むべきものであり、最後に読むものではない。

これがあなたをどういう立場に置くのか

要約ではなく判断として述べるなら、あなたのカードが14.23 GBのtransformerと17.53 GBのencoder、さらにVAEを保持できない場合、GGUFビルド以外にQwen-Image-2.1を動かす方法はそもそも存在しない。そして正直な見込みとしては、中程度の量子化は実行を可能にする代わりに、細部、手、小さな文字、指示追従性において何かを犠牲にする——それがどれほどのものかを教えてくれる公表された測定値はない。カードがそれを保持できるなら、safetensorsの経路こそがベンダーが文書化しているものであり、定義されたリファレンスを持つものである。

このプロパティの別の場所では、2人の読者それぞれに1文が必要です。もしあなたが本当に求めているのが、形式についての議論ではなく、安全フィルタリングを取り除いたコミュニティビルドなら、それは別のページであり、検閲なしのビルドはそこで扱われています。そして、あなたの本当の目的地が、手作業で組み立てなければならないファイルではなく、動作するノードグラフなら、ComfyUI のページがパイプライン全体をローダーごとに順を追って説明します。

未解決のままなのは、エコシステムが公表していないこと、つまり固定シード上で、同じプロンプトと同じサンプラーを使い、誰かが具体的に名前を挙げるハードウェアで、これらのレベルを対照比較した結果だ。RealRebelAIが、汎用のQ4_K_MはINT8参照に対して目に見えて劣化した一方、同じラベルの混合精度ビルドはそうならなかったと記しているのは、公開されている中でその答えに最も近いものだが、それはある発信者自身のA/Bテストにすぎない。誰かがその比較を公表するまでは、選ぶべきレベルは自分のメモリが許す最も高いものであり、ファイル名のラベルは、その背後にあるテンソルポリシーよりも弱い保証でしかない。