# Qwen3.8 27B の量子化、Q4・Q2・Q1 で何が変わるか——Q3_K_XL は BF16 と同じ、同じ 2-bit でも 96% と 74%、Q1 は 53% > Kaitchup が 2026-09-01 に公開した Qwen3.8 27B の GGUF 15 本実測（950 プロンプト・150M トークン超）を、VRAM 別の決定表に組み直しました。UD-Q3_K_XL（12.80 GB）は BF16 の精度を 100.0% 回復、UD-Q2_K_XL は 96.0%、UD-IQ2_XXS は 74.3%、UD-IQ1_M は 53.4%。落とすほど同じ問題に多くのトークンを費やし、出力は最大 62% 増えます。量子化の段が変えるのは速さではなく仕様です。 - Published: 2026年9月3日 - Author: Linden Kern, Chief Scientist - Tags: models, local-llm, quantization - Canonical: https://pirouter.ai/ja/blog/qwen38-27b-quantization-q4-to-q1 --- 結論から。Kaitchup の Benjamin Marie 氏が 2026-09-01 に公開した [Qwen3.8 27B GGUF Benchmark: Q4 to Q1 Accuracy and Token Efficiency](https://kaitchup.substack.com/p/qwen38-27b-gguf-benchmark-q4-to-q1) では、**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 点の 値と方法論の記述だけです。 [前回](/ja/blog/gguf-filename-is-a-request)は GGUF のファイル名が謳う bpw と中身の差を書きました。 dense の 27B は、そこで「置換ゼロ、名前は正直」と確認できたモデルです。だから今回は名前と中身が一致 している前提で、**その中身が段ごとに何を返すか**を読みます。 ## まず 15 本の表——体積・回復率・出力トークン、95% の線 | 作り手 | ファイル | 体積 | 回復率 | 出力トークン | 対 BF16 | 95% 判定 | |---|---|---:|---:|---:|---:|---| | unsloth | UD-Q4_K_XL | 17.21 GB | 101.0% | 9.47M | −0.2% | ✓ | | huihui-ai | UD-Q4_K_XL（abliterated） | 17.03 GB | 98.8% | 9.93M | +4.6% | ✓ | | AtomicChat | AD-Q4_K_M | 16.84 GB | 99.9% | 9.99M | +5.3% | ✓ | | bartowski | IQ4_XS | 15.33 GB | 99.1% | 10.18M | +7.3% | ✓ | | AtomicChat | AD-IQ3_S | 13.60 GB | 101.1% | 10.48M | +10.4% | ✓ | | unsloth | UD-Q3_K_XL | 12.80 GB | 100.0% | 9.89M | +4.2% | ✓ | | bartowski | IQ3_XXS | 12.39 GB | 97.7% | 11.54M | +21.6% | ✓ | | empero-ai | Ridge 3.7 bpw | 12.26 GB | 97.4% | 10.29M | +8.4% | ✓ | | AtomicChat | AD-IQ2_S | 10.85 GB | 95.9% | 12.24M | +29.0% | ✓ | | unsloth | UD-IQ3_XXS | 10.58 GB | 95.5% | 12.27M | +29.3% | ✓ | | ISTA-DASLab | GSQ-RCO IQ3_XXS | 10.09 GB | 96.5% | 10.87M | +14.5% | ✓ | | unsloth | UD-Q2_K_XL | 9.48 GB | 96.0% | 11.89M | +25.3% | ✓ | | ISTA-DASLab | GSQ-RCO IQ2_S | 9.26 GB | 92.2% | 11.81M | +24.4% | ✗ | | unsloth | UD-IQ2_XXS | 7.27 GB | 74.3% | 11.96M | +26.0% | ✗ | | unsloth | UD-IQ1_M | 6.73 GB | 53.4% | 15.41M | +62.4% | ✗ | BF16 基準は平均正答率 85.63%、出力 9.49M トークン。「回復率」はこの正答率に対する比です。 表の読み方を四つ。 - 体積は Kaitchup の値で、MTP と vision を除いた本体です。Hugging Face の実ファイルは MTP を含む段で 0.35 GB ほど大きい（[unsloth/Qwen3.8-27B-GGUF](https://huggingface.co/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 ではない」と書いています。 ![Kaitchup の散布図：Qwen3.8-27B GGUF 15 本の体積と BF16 に対する精度回復率。金色の線が 95%、破線が BF16 基準](/blog/images/qwen38-27b-quantization-q4-to-q1-kaitchup-chart.png "15 本の体積（横軸、MTP・vision 除外）と回復率（縦軸）。金色の線が Kaitchup の閾値 95%、破線が BF16 基準。作図 Benjamin Marie。出典：[Qwen3.8 27B GGUF Benchmark: Q4 to Q1 Accuracy and Token Efficiency — The Kaitchup](https://kaitchup.substack.com/p/qwen38-27b-gguf-benchmark-q4-to-q1)") ## 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 の説明](https://unsloth.ai/docs/basics/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 の後の数字は段そのものではなく、レシピ名まで含めて 初めて仕様になります。 ![Unsloth UD 6 段の横棒グラフ：UD-Q4_K_XL 101.0%、UD-Q3_K_XL 100.0%、UD-IQ3_XXS 95.5%、UD-Q2_K_XL 96.0%、UD-IQ2_XXS 74.3%、UD-IQ1_M 53.4%。95% の線が金色](/blog/images/qwen38-27b-quantization-q4-to-q1-ud-ladder-ja.png "Unsloth UD 6 段の体積と BF16 に対する精度回復率。数字は Kaitchup の公開図（2026-09-01）から読み取った値。") ## 同じ体積で作り手が違うと——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 の[転載スレッド](https://www.reddit.com/r/LocalLLaMA/comments/1w4mevo/kaitchup_posted_qwen38_27b_benchmarks_for_quants/) で 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](https://www.reddit.com/r/LocalLLaMA/comments/1w4wjxd/everyone_is_ts_maxing_38_but_after_a_week_of_using_it_for_work_im_tempted_to_switch_back/) というスレッドがありました（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](https://www.reddit.com/r/LocalLLaMA/comments/1w4z94f/running_104gb_qwen38flashnext_on_48gb_mac_at_12_toks/) （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 比較の回](/ja/blog/glm-flash-vs-qwen-flash-next)）。 Qwen の[モデルカード](https://huggingface.co/Qwen/Qwen3.8-27B)自体が、思考量について同じ形の注意を 書いています。「マルチターンのエージェント作業では、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 量子化検証](https://quesma.com/blog/qwen-quantization-quality/)ですが、対象が 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 の回](/blog/quantization-is-a-product-spec)に書きました。今回の 95% の線は、そのタスクについて何も 言っていない、と読むのが正確です。 ## VRAM 別の決定表——12 GB・16 GB・24 GB で何を取るか Unsloth の[要件表](https://unsloth.ai/docs/models/qwen3.8)（RAM + VRAM の合計、またはユニファイドメモリ） では 3-bit が 12〜14 GB、4-bit が 16〜19 GB、MTP を使うなら +1〜2 GB。そこに Kaitchup の数字を重ねると、 こうなります。 | 手元のメモリ | 候補 | 回復率 | 代償と条件 | |---|---|---|---| | 24 GB VRAM / 32 GB ユニファイド | UD-Q4_K_XL（17.21 GB） | 101.0% | 出力トークンは BF16 と同量。KV の余地を優先するなら bartowski IQ4_XS（15.33 GB、99.1%、+7%） | | 16 GB | UD-Q3_K_XL（12.80 GB） | 100.0% | 出力トークン +4%。同帯の AD-IQ3_S（13.60 GB、101.1%）、bartowski IQ3_XXS（12.39 GB、97.7%）も線の上 | | 12 GB | GSQ-RCO IQ3_XXS（10.09 GB）または UD-Q2_K_XL（9.48 GB） | 96.5% / 96.0% | 出力トークン +15〜25%。短答式・要約向け。エージェント用途は Kaitchup の非対称読みで「避ける候補」 | | 8 GB | UD-IQ2_XXS（7.27 GB）/ UD-IQ1_M（6.73 GB） | 74.3% / 53.4% | Kaitchup：「95% 未満なら小さいモデルを健全な段で」。Unsloth：1-bit は短い事実質問向け、presence_penalty 1.5 以上 | 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 より下は用途を 短答式に限る。** [編成の回](/ja/blog/local-llm-ensembles)で書いた「どのモデルにどのタスクを」は、同じ モデルの中でも「どの段にどのタスクを」として続いています。 ここに書いた数字は全部 Kaitchup と Unsloth と Reddit のもので、当方の計測は一つも入っていません。自分の タスクで折れ目がどこにあるかは、自分の tool call で測るしかありません。 --- ## Sources ### kaitchup.substack.com - [Qwen3.8 27B GGUF Benchmark: Q4 to Q1 Accuracy and Token Efficiency](https://kaitchup.substack.com/p/qwen38-27b-gguf-benchmark-q4-to-q1) ### huggingface.co - [unsloth/Qwen3.8-27B-GGUF](https://huggingface.co/unsloth/Qwen3.8-27B-GGUF) - [モデルカード](https://huggingface.co/Qwen/Qwen3.8-27B) ### unsloth.ai - [Dynamic 3.0 GGUFs の説明](https://unsloth.ai/docs/basics/dynamic-3.0-ggufs) - [要件表](https://unsloth.ai/docs/models/qwen3.8) ### reddit.com - [転載スレッド](https://www.reddit.com/r/LocalLLaMA/comments/1w4mevo/kaitchup_posted_qwen38_27b_benchmarks_for_quants/) - [Everyone is t/s maxing.. 3.8.. but after a week of using it for work I'm…](https://www.reddit.com/r/LocalLLaMA/comments/1w4wjxd/everyone_is_ts_maxing_38_but_after_a_week_of_using_it_for_work_im_tempted_to_switch_back/) - [Running 104GB Qwen3.8-Flash-Next on 48GB Mac at ~12 tok/s](https://www.reddit.com/r/LocalLLaMA/comments/1w4z94f/running_104gb_qwen38flashnext_on_48gb_mac_at_12_toks/) ### quesma.com - [Quesma の Qwen3.6 27B 量子化検証](https://quesma.com/blog/qwen-quantization-quality/)