Qwen3.8 27B の量子化、Q4・Q2・Q1 で何が変わるか——Q3_K_XL は BF16 と同じ、同じ 2-bit でも 96% と 74%、Q1 は 53%

結論から。Kaitchup の Benjamin Marie 氏が 2026-09-01 に公開した Qwen3.8 27B GGUF Benchmark: Q4 to Q1 Accuracy and Token Efficiency では、UD-Q3_K_XL（12.80 GB）が BF16 の精度を 100.0% 回復し、UD-Q2_K_XL（9.48 GB）で 96.0%、 UD-IQ2_XXS（7.27 GB）で 74.3%、UD-IQ1_M（6.73 GB）で 53.4% です。 同じ 950 問を解くのに生成する トークンは、BF16 の 9.49M から IQ1_M の 15.41M へ 62% 増えます（当方換算）。段を落とすと 1 トークンは 軽くなりますが、同じ問題に多くのトークンを費やすようになる。量子化の段が決めるのは「速い・遅い」では なく、どの段でどの種類のタスクに別の答えを返し始めるか——それは速度ではなく仕様です。

評価の条件を先に書きます。950 プロンプト（MMLU-Pro・LiveCodeBench・GPQA Diamond からの抽出）、Qwen 推奨のサンプリング設定で 3 回走らせて平均、llama.cpp server、最大出力 128K トークン、思考は low、 RTX Pro 6000 で約 8 日・150M トークン超。シングルターン・非エージェントのタスクだけです。 記事本体は有料で、タスク別の内訳はそこにあります。本稿が使うのは無料部分の公開図から読み取った 15 点の 値と方法論の記述だけです。

前回は GGUF のファイル名が謳う bpw と中身の差を書きました。 dense の 27B は、そこで「置換ゼロ、名前は正直」と確認できたモデルです。だから今回は名前と中身が一致 している前提で、その中身が段ごとに何を返すかを読みます。

まず 15 本の表——体積・回復率・出力トークン、95% の線

BF16 基準は平均正答率 85.63%、出力 9.49M トークン。「回復率」はこの正答率に対する比です。

表の読み方を四つ。

• 体積は Kaitchup の値で、MTP と vision を除いた本体です。Hugging Face の実ファイルは MTP を含む段で 0.35 GB ほど大きい（unsloth/Qwen3.8-27B-GGUF の UD-Q3_K_XL は 13.15 GB——当方が 2026-09-03 に API で確認）。UD-IQ2_XXS 以下は MTP が外され一致します。
• 「対 BF16」列は当方の換算（出力トークン ÷ 9.49M − 1）で、Kaitchup の図にはない列です。
• 判定列は Kaitchup 自身の閾値、「95% を超えれば good enough」。✓ が 12 本、✗ が 3 本。
• 100% を超える 3 本は BF16 より良いのではなく、サンプリングとベンチマークの分散です（氏の注記）。 1〜2 ポイントの差も 3 回平均のノイズの中で、氏自身「definitive ranking ではない」と書いています。

Unsloth の 6 段で折れ目を見る——Q3_K_XL まで平ら、Q2_K_XL で 4 ポイント、その下の 2.2 GB で 22 ポイント

作り手を一つに固定すると、段の効き方が見えます。Unsloth の 6 段を体積順に並べると、17.21 GB → 12.80 GB で 回復率は 101.0 → 100.0、4.4 GB 減って 1 ポイントでノイズの中。12.80 → 9.48 GB で 100.0 → 96.0。ここまでは 8 GB 弱を削って 4〜5 ポイントとの引き換えで、線の上に残ります。

次の一段が違います。9.48 GB → 7.27 GB、削れるのは 2.2 GB で、回復率は 96.0 → 74.3。21.7 ポイント。 さらに 0.5 GB 削って IQ1_M にすると 53.4、もう 20.9 ポイント。上の 8 GB で失った量の 4 倍以上を、 下の 2.7 GB で失う形です。

順序の逆転も一つ。UD-IQ3_XXS（10.58 GB、95.5%）は UD-Q2_K_XL（9.48 GB、96.0%）より 1.1 GB 大きくて 0.5 ポイント低い。差はノイズの中ですが、「体積が大きいほど良い」が同じ作り手の隣同士でも崩れる例です。 名前の数字（3 と 2）ではなく、レシピが決めています。

崖の位置については、測り方も測る人も違う第二の数字があります。Unsloth 自身の Dynamic 3.0 GGUFs の説明（作り手の自己申告）は、 300 例（Terminal-Bench 2.1・DeepSWE などから抽出）で BF16 と各量子化を 32 トークン greedy で走らせた 一致率「Divergence-300 @32」を出しています。そこに「UD-Q2_K_XL から UD-IQ2_S へ、約 25% から 8〜10% 未満へ 急落する。tool calling と non-thinking モードが壊れる」とあります。UD-Q2_K_XL 未満では looping が多く presence_penalty を 1.5 以上に、とも。Kaitchup の正答率と Unsloth の 32 トークン一致率は、指標も測定者も 別なのに、折れ目を同じ場所——UD-Q2_K_XL のすぐ下——に置いています。

だから「同じ 2-bit でも 96% と 74%」です。UD-Q2_K_XL も UD-IQ2_XXS も名前は 2 で始まりますが、片方は 95% の線の上、片方は 20 ポイント下。ファイル名の Q の後の数字は段そのものではなく、レシピ名まで含めて 初めて仕様になります。

同じ体積で作り手が違うと——9〜11 GB は全員が線の上下、12〜14 GB は全員 97% 超

作り手を跨いで、体積帯で読み直します。

12〜14 GB 帯：bartowski IQ3_XXS 97.7%、Ridge 3.7 bpw 97.4%、UD-Q3_K_XL 100.0%、AD-IQ3_S 101.1%。 四本とも 97% 超で幅は 3.7 ポイント。誰のものを取っても線の上です。

9〜11 GB 帯：GSQ-RCO IQ2_S 92.2%、UD-Q2_K_XL 96.0%、GSQ-RCO IQ3_XXS 96.5%、UD-IQ3_XXS 95.5%、 AD-IQ2_S 95.9%。五本が 95% の線をまたいで散り、ISTA の IQ2_S と Unsloth の Q2_K_XL は体積差 0.22 GB で 3.8 ポイント違います。

15〜17 GB 帯：bartowski IQ4_XS 99.1%、AD-Q4_K_M 99.9%、huihui-ai の abliterated 版 UD-Q4_K_XL 98.8%。 最後の一本は元の UD-Q4_K_XL より 2.2 ポイント低く、Kaitchup は理由を書いていないので本稿も書きません。

Reddit の転載スレッド で u/Bubbly_Orange_3502 氏が書いた一文がそのまま当てはまります。「作り手を跨ぐと量子化ラベルはほとんど 何も拘束しない。UD と ISTA は imatrix のキャリブレーションデータが違い、高ビットで残すテンソルも違うので、 一方の Q3 が他方の Q4 の上に来ることがある」。ラベルより体積帯で読むほうが外れが少ない（帯の中の 1〜2 ポイントは順位づけできません）。

速い GGUF と使える GGUF は別物——落とすほど同じ問題に多くのトークンを費やす

Kaitchup の無料部分にある一文、「トークン効率は精度劣化と強く相関する」。表の「対 BF16」列がその実物です。 UD-Q4_K_XL は BF16 と同じ量を生成し（−0.2%）、Q3_K_XL で +4%、Q2_K_XL で +25%、IQ1_M で +62%。他の作り手も 同じ向きで、bartowski IQ4_XS +7%、ISTA IQ2_S +24%。精度が落ちる段では、答えに至るまでの思考が長くなります。

ここに「速さ」の計算を当てます。以下は当方の試算で、Kaitchup は tok/s を測っていません。decode がメモリ 帯域で律速される環境なら、1 トークンの速さはおおむね体積に比例します。UD-Q3_K_XL → UD-Q2_K_XL は体積 −26%。仮にそのぶん速くなっても、同じ 950 問に生成するトークンは 9.89M → 11.89M で +20%。実時間の利得は ほとんど残らず、正答率は 4 ポイント下がります。「軽くしたのに終わるのが速くならない」の中身はこれです。

同じ日の r/LocalLLaMA には、題名がそのまま Everyone is t/s maxing.. 3.8.. but after a week of using it for work I’m tempted to switch back to 3.6 というスレッドがありました（u/Chuyito 氏、2026-09-02、採集時 top/day 掲載）。氏の訴えは「Qwen 3.8 is a damn good coder, but a terrible collaborator」——2 行で済む修正を 100 行に書き換える、と。設定は氏自身が 別コメントに貼っています。UD-Q4_K_XL、コンテキスト 120k、DFlash2 の draft モデル、reasoning-budget 1000。

読み応えがあったのは返信のほうです。u/1beb 氏は「3.8… what? Dense? Flash? What quant? What kv? What thinking setting? Context?」と返し、u/MycologistNo5577 氏は「“3.8” could mean like five different models at this point」。「3.8 がダメで戻ると言う人は大抵 Q2 に Q4 の KV cache」という声も。モデル名だけの報告は モデルを特定していない——量子化の段が仕様の一部なら、そうなるのが当然です。

「速さ」のもう一つの追い方も同じ日に並んでいました。 Running 104GB Qwen3.8-Flash-Next on 48GB Mac at ~12 tok/s （u/yogthos 氏、2026-09-02）。27B ではなく MoE の Flash-Next で、12 tok/s は題名の自己申告です。u/tarruda 氏 は llama.cpp の -lm none -lzm on でも同じことができるが、プロンプト処理が約 450 から約 300 tok/s に落ちる （自己申告）と。量子化を落とさない代わりにプロンプト処理を失う——「動く」と「使える」が分かれる別の形です （Flash 比較の回）。

Qwen のモデルカード自体が、思考量について同じ形の注意を 書いています。「マルチターンのエージェント作業では、reasoning effort を下げても全体の完了時間が短くなるとは 限らない。ターンごとの応答は速くなっても、分析不足・失敗・再試行が増えて総トークンが増えることがある」。 量子化でも思考量でも、ターン単位の速さとタスク全体の速さは符号が逆になりえます。

この評価が教えてくれないこと

Kaitchup 氏自身が先に書いています。シングルターン・非エージェントのタスクだけ。温度 0 ではなく推奨設定 でのサンプリング、3 回平均。95% の閾値は氏の慣行で業界の基準ではなく、エージェント用途では非対称に読め、 とも。「95% 付近か下は避ける有力候補、明確に上でも『たぶん十分』にとどめる」——1% の差が多段の tool call で複利になるからです。UD-Q2_K_XL と UD-Q4_K_XL の追試を進めていて 1 週間以上かかる、と注記があります。

転載スレッドの反証も、それぞれ別の場所を指します。

u/crusaderky 氏（本人の測定、自己申告）：「KLD・perplexity・同一サンプル token のデータでは、UD-Q2_K_XL は 崖のはるか下。UD-IQ4_XS は問題なし、UD-IQ3_S はまだ使えるかもしれない」。氏いわく、KLD を対数軸で描くと 崖が見えなくなり、温度 1 で BF16 と同じトークンを引く確率——同一サンプル token——が最も厳しく崖を映す。 この指標の出所は Quesma の Qwen3.6 27B 量子化検証ですが、対象が Qwen3.6 で世代が違うため、数字は持ち込みません。

u/Repinsky 氏：「100% は数個のサブセットの平均で、Q3_K_XL の 100% は Q4 のノイズの中にある。自分の環境では UD-Q3_K_XL と Q4_K_M の差は long-context と tool-call の書式にだけ出る。短い MMLU 型の回答は量子化に最も 耐性がある測定対象だ」。

u/Fancy-Snow7 氏：「自作の難しい needle-in-haystack では q3 が落ちて q4 は 100%」。u/BalorNG 氏：「Q3 は 定期的に thinking loop に入る、Q4 は入らない」。u/ea_man 氏：「130k のセッションで細部を失わないかは 測っていない」。

これらは Kaitchup と矛盾していません。測っているものが違います。分布（KLD・同一サンプル token）は Q2 で 大きくずれる。短答式の正答率は Q2_K_XL まで保つ。二つが出会う場所が long-context と tool-call で、 そこはどちらの表にもありません。 同じ重みの FP8 が長いコンテキストの tool call で壊れる話は en の回に書きました。今回の 95% の線は、そのタスクについて何も 言っていない、と読むのが正確です。

VRAM 別の決定表——12 GB・16 GB・24 GB で何を取るか

Unsloth の要件表（RAM + VRAM の合計、またはユニファイドメモリ） では 3-bit が 12〜14 GB、4-bit が 16〜19 GB、MTP を使うなら +1〜2 GB。そこに Kaitchup の数字を重ねると、 こうなります。

16 GB の行には u/Repinsky 氏の一言を足しておきます。「12.8 GB なら KV cache を載せる余地が残る。offload の ほうが、量子化が精度に払うコストよりずっと多くの tok/s を失う」。勝ち筋は 100% だけではなく、残りの 3 GB です。

一行にすると、16 GB なら UD-Q3_K_XL、迷ったらラベルではなく体積帯で読み、UD-Q2_K_XL より下は用途を 短答式に限る。 編成の回で書いた「どのモデルにどのタスクを」は、同じ モデルの中でも「どの段にどのタスクを」として続いています。

ここに書いた数字は全部 Kaitchup と Unsloth と Reddit のもので、当方の計測は一つも入っていません。自分の タスクで折れ目がどこにあるかは、自分の tool call で測るしかありません。