以下の内容はhttps://nowokay.hatenablog.com/entry/2026/01/04/170108より取得しました。


画像や動画の生成モデルは量子化の影響を受けやすくVRAMはみ出ていいのでなるべく大きいサイズを選ぶ

Qwen-Image-Editを使ってたら、どうにもうまく画像編集してくれないなと思っていたのだけど、Q4_K_SをQ4_K_Mにしたら断然思い通りに生成してくれるようになりました。
ほとんど違いがないのにこれだけ挙動が変わるのかとビックリしたので、この量子化の違いはなんぞやということも含めてまとめてみました。
画像や動画の生成モデルは量子化の影響が出やすく、そしてVRAMを大幅にはみ出るサイズでも生成時間に影響がないので、メインメモリの許す大きいサイズを選ぶのがいいようです。

2枚入力時のプロンプト追従

Qwen-Image-Edit-2511で「pict1の男性をpict2の女性に入れ替える。」とやってみます。メガネをかけることがあったのでネガティブ側に「メガネ」をいれています。

まずQ8_0。たまに失敗はあるけど、だいたいうまくやってくれます。

生成時間は52秒

ところがQ4_K_S。一部に5ビットを使う4ビット量子化です。
同じプロンプトだと、絶対に人がふたり出てきます。背景も変わってます。だいたいリア充バージョンが出てくるのだけど、世界が平和なほうを載せておきます。

生成時間は49秒

そしてQ4_K_M。一部6ビットも使う量子化です。
帽子をかぶったけど、だいたいあってる。

もう一度やるとちゃんと出ました。

どっちかというと、成功が多いです。Q4_K_Sが一度も成功しなかったのに、ちょっとの違いで全然違います。

生成時間は53秒。

Q4_K_Sで試してて、Qwen-Image-Editうまくいかんなぁと思ってたけど、ほとんど差のないQ4_K_Mにするだけで解決してびっくりでした。

画像一枚での画質

画像一枚の場合はQ4_K_Sでもだいたいうまくやってくれるので、ここでは画質を見てみます。
ツインテールに。後ろの堤防には「GGUF」という落書き」というプロンプト。

Q4_K_SとQ4_K_Mは明らかにディティールが違いますね。

Q4_K_MとQ8_0はほとんど同じだけど、なんとなくQ8_0がよさげ。

Qwen-Image-Layered

Qwen-Image-LayeredではQ4_K_Mが使い物にならず、Q8_0にしましょう、というくらい違います。
画像は、昨日のブログのときの画像に「アニメ調」のような指定をつけたものです。
Qwen-Image-2512をGGUFで動かしてそこらへんにいそうな人を生成する - きしだのHatena

ちなみにワークフローはこのケモ耳娘をドラッグドロップして出てくるものを使ってます。
https://github.com/comfyanonymous/ComfyUI/issues/11427#issuecomment-3676770732

Q8_0。背景と箒とメイドさんをきれいに分離して、背景も違和感なく埋めてくれています。

ところがQ4_K_M。背景のメイドさんがいたところに謎の影。メイドさんのまわりにもなにかあります。

いつもの女性の場合もQ4_K_Mでは堤防がぼやけてる。

Q8_0だと堤防がそれなりに補完されてます。

Qwen-Image-LayeredではQ8_0以上が必須ですね。

画像や動画の生成モデルはVRAMからはみでてもいい

ところでQwen Imageは20Bです。20BのモデルをQ8_0で動かすと単純に20GB必要ですね。そんなモデルをVRAM 16GBのGPUで動かして遅くならないの?という疑問があります。

言語モデルの感覚だと、VRAMからはみ出てメインメモリを使うとかなり遅くなりますね。 でも、画像生成は実際に見ても生成スピードは変わってません。

これは画像動画モデルと言語モデルの生成スタイルの違いによるものです。

言語モデルの場合、1回の生成で出てくるのは1トークンです。これを何回も繰り返してトークンをたくさん生成して文章ができあがるわけです。このとき15tok/secはチャットだと我慢できるけどエージェントだと我慢できないくらいのスピードです。20tok/secは最低でも欲しい。
つまり、言語モデルでは、1回の生成は0.05秒で終わって欲しいわけですね。

一方で、画像生成の場合、1枚に1分でも許せます。15秒ならとても速い。実際には荒い画像を生成して再投入して、というのを何ステップか行います。30秒だとして、4ステップだと1ステップ7秒ですね。画像動画生成は1回の生成に7秒かかっていい。 そうすると、半分のブロックの処理が終わったら残りの半分をメインメモリからVRAMに読み込むということを0.2秒くらいかけてやっても許されます。ということで、画像動画モデルの場合は、途中でモデル読み込みができるのでVRAMからはみ出すモデルでも使えるわけです。
言語モデルで0.1秒かけてモデルの残りの部分を読み込んでたら、それだけで10tok/secになってしまいます。処理自体に0.05秒かかるのだと、6tok/secになります。それであれば、CPUで処理をしたほうがいいということになるわけですね。

ただしメインメモリは必要。

ただ、1回の生成に時間がかかるので、画像モデルでは量子化の誤差が積み重なりやすいのだと思います。そのため、生成結果に目に見える違いが出てくるわけです。
言語モデルの場合、1回の生成で出てくるのはトークンの複数候補とそれぞれのもっともらしさです。少々誤差があっても、第一候補は変わりにくく尤もらしさが多少ズレるだけ。ということで、言語モデルでは量子化の誤差が最終結果に表れにくいのだと思います。

Q4_K_MとQ4_K_Sの違い

ところでこのQ4_K_MとかQ4_K_Sってなんやってなりますね。
最初のQ4は4ビット量子化を表します。ここはわかりやすい。
次のKはK-Quantという量子化手法を表します。 そのあとのSとかMは、SmallやMediumの略です。なので他にLもありますね。ちょっとずつサイズが違う。

どう違うかは、ログにヒントがあります。量子化ごとの層の数が表示されてます。

まとめるとQwen-Image-Editではこんな感じで量子化が使われてます。
Q4_K_SやQ4_K_Mは一部に5ビット量子化が使われていて、Q4_K_Mの場合は6ビット量子化も使われている、ということです。

F32 BF16 Q8_0 Q6_K Q5_K Q4_K
Q4_K_S 1087 6 168 672
Q4_K_M 1088 6 232 48 560
Q8_0 1088 6 840

こちらはQwen-Image-Layeredのほう。BF16が多い。

F32 BF16 Q8_0 Q6_K Q5_K Q4_K
Q4_K_M 1087 7 232 28 580
Q8_0 1087 7 840

LayeredではQ5_Kの数がEditより少ないな、ってなりますが、実はこれEditはUnsloth版で、LayeredはQuantStack版だからです。あとで見るように、Unsloth版のLayeredのQ4_K_Mでは20層分Q5_Kが多いのです。

レイヤーの構造は、HuggingFaceのサイトで見れます。
https://huggingface.co/QuantStack/Qwen-Image-Layered-GGUF/blob/main/Qwen_Image_Layered-Q4_K_S.gguf
https://huggingface.co/QuantStack/Qwen-Image-Layered-GGUF/blob/main/Qwen_Image_Layered-Q4_K_M.gguf

QuantStackのQwen-Image-LayeredのGGUFを見てみます。
まずTransformerブロックを閉じた状態。Transformerの前後はBF16です。ここに7層見えますね。あと、biasは全部F32です。

ちなみにこれがQwen-Image-Editのレイヤーのembedding部分です。↑にあるaddition_t_embeddingがLayeredで追加された層ってことになりますね。

で、Transformerの1ブロック目。ここはQ5_K主体で、Q4_K_MもQ4_K_Sも変わりません。

Q4_K_SのTransformer2ブロック目。Q4_K主体になってます。そして、add_v_projのところだけQ5_Kになってますね。ここに出てないけどto_vの層もQ5_Kになってます。つまりvalue関連だけ量子化が大きい

そしてこれが、Q4_K_Mだと、add_v_projがQ6_Kになってます。基本的にはこの違い。

で、気が付いたのだけど、unslothさんのところのQ4_K_Mは2ブロック目もQ5_K主体になっていて、Q4_Kになるのは3ブロック目からでした。

なので微妙にファイルサイズも違います。下がunsloth版。

GGUF、どこのものでも同じってわけではないことを改めて認識。




以上の内容はhttps://nowokay.hatenablog.com/entry/2026/01/04/170108より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14