ローカルLLMを動かすとき、どこまで圧縮しても実用に耐えるのかは切実な問題です。GPUメモリは限られていますし、モデルを小さくしたい気持ちは強い一方で、精度が落ちすぎれば意味がありません。QuesmaのPiotr Migdał氏は、Qwen3.8 27Bの複数のquantizationを実測し、その境界線をベンチマークで確かめました。結果はかなりはっきりしていて、4bitは驚くほど健闘し、1bitは一気に崩れます。
元記事で扱っているのは、Qwen3.8 27BのGGUF量子化版です。著者はUnslothがHugging Faceで配布しているものを使い、8bitのQ8_0、4bitのQ4_K_M、2bitのUD-Q2_K_XL、そして最小の1bitであるUD-IQ1_Sを比較しました。フルのBF16モデルは55GBあり、一般的なコンシューマーGPUには重すぎますが、Q4_K_Mは17GBに収まり、RTX 4090の24GB級カードでも動かせるとしています。
検証にはllama.cppを使い、GPQA Diamond、IFBench、Terminal-Bench 2.1の3つを回しました。GPQA Diamondは大学院レベルの知識問題、IFBenchは指示追従、Terminal-Bench 2.1はエージェント的なコーディング能力を見るベンチマークです。著者はBF16の公式結果を再現するところから始め、量子化によってどこから結果が崩れるかを見ています。テストはかなり高くつき、ModalのGPU代だけで約3,000ドルかかったと書いています。なお、KV-cacheはモデルの量子化にかかわらずF16で、32k tokensあたり約2.3GBを使います。
GPQA Diamondでは、著者がまず公式値を再現できたことに安心したと述べています。hidden settingsや前提の違いで結果が大きく変わるからです。そのうえで見ると、BF16から4bitのQ4_K_Mまでの差はほとんどなく、2bitのUD-Q2_K_XLだけ少し下がりました。しかも reasoning effort の設定が効き、low・medium・xhigh のどれを選ぶかでスコアがかなり変わります。xhighはデフォルト設定ですが、最良の結果には約8k reasoning tokensが必要でした。
IFBenchでも傾向は似ています。ここではBF16、Q8_0、Q4_K_M、UD-Q2_K_XLの間でほぼ差が出ず、2bitでも十分実用に見える結果でした。contextは約4k tokensで、GPQAよりも短めです。さらにTerminal-Bench 2.1では、BF16の公式結果を再現しただけでなく、Q4_K_Mもほぼ同じ水準に達しました。著者はQ8_0を回し忘れたものの、4bitとBF16の間に大きな差がないため、そこは補間しても問題ないだろうとしています。2bitになるとさすがに落ちますが、それでも完全に使い物にならないというほどではなく、Opus 4.7やGemini 3.1 Proに近いレベルだと述べています。
一方で、1bitは様相がまったく違います。GPQA Diamondではスコアがほぼランダム当てに近づき、最小のUD-IQ1_Sはそれを下回る結果でした。しかもxhighにすると、むしろ低い effort より悪化します。理由は、考え続けた末にtoken budgetを使い切って空の答えを返すことが増えるからです。著者はUnslothが「top-1 accuracyの72%を保ちつつ89%小型化」とうたっている点にも触れていますが、ここでは残りの28%が致命的だと切っています。量子化は直線的に悪化するのではなく、しばらく平気で、あるところで急に崩れる。この記事はその境目が4bitと1bitの間にあることを示しています。
まず目を引くのは、4bitの強さです。一般に量子化は「小さくなる代わりに少し頭が悪くなる」ものとして語られがちですが、この記事の結果を見ると、少なくともQwen3.8 27Bではその感覚がかなり雑だと分かります。GPQA Diamond、IFBench、Terminal-Bench 2.1のどれでも、Q4_K_MはBF16とほぼ同等でした。これは単に「圧縮してもまあまあ」ではなく、かなり積極的にローカル運用へ背中を押す結果です。24GB級のGPUで27Bを回し、しかもコンテキストをある程度確保できるなら、個人環境や小規模チームの選択肢は一気に広がります。
ここで面白いのは、性能の落ち方ではなく、落ち方が見えないこと自体です。ベンチマークの多くは、微妙な差を拾おうとするとノイズに埋もれます。著者はそこを承知で、答えのトークン分布の差ではなく、最終的なタスク成績を見ています。その結果、4bitで差がほぼ出ないなら、実務ではなおさら気にしなくていい場面が多いはずです。LLMをローカルで動かす人の多くは、理論上のわずかな精度差より、動くか、待たされないか、メモリに収まるかを気にしています。そういう意味で、Q4_K_Mはかなり強い実用解だと思います。
2bitのUD-Q2_K_XLは、4bitと比べると少し怪しくなります。それでも著者の測定では、GPQA Diamondでやや下がる程度、IFBenchではかなり健闘し、Terminal-Bench 2.1でも「壊れた」と言うほどではありません。ここが厄介で、2bitは失敗ではないのです。むしろ「用途を選べば十分ありえる」位置にいます。小さなGPUしかない、あるいはより多くのcontextを積みたい、複数ストリームを並べたいといった事情があるなら、2bitは候補に残るでしょう。
ただし、著者がわざわざ「best model that fits in your GPU memory together with the required context」を勧めているのは、この層で設計判断が分かれるからだと思います。2bitは単純に軽いだけではなく、出力トークン数が少し増えたり、余計に考え込んだりもしています。つまり、同じ「動く」でも体験は少し違う。安定した推論を求めるなら4bit、メモリ優先なら2bit、という線引きが見えてきます。ここで重要なのは、2bitを万能視しないことです。ベンチマークでは許容できても、長い対話や微妙な指示追従では別の癖が出るかもしれません。著者自身もKV-cacheの量子化が別の論点になりそうだと書いており、まだ見えていない部分があるのだと思います。
1bitの結果は、単に点数が落ちるという話ではありません。著者の描写では、モデルが考え続けた末に答えを返せず、空振りすることが増えます。ここが本質的で、1bitでは推論能力が少し鈍るのではなく、タスク遂行の流れそのものが壊れています。GPQA Diamondでランダム当て水準に落ちるだけならまだしも、xhighを選ぶほど悪化するというのは、圧縮がモデルの内部挙動まで変えてしまっている証拠です。
この結果は、極端な圧縮を「とにかく軽いから便利」と見なす見方に釘を刺します。モデルサイズが半分になる、4分の1になる、という数字だけを見ると得した気になりやすいですが、実際には残る性能の使い道が重要です。質問に答えない、途中で空出力になる、長考ほど失敗する、となれば、たとえメモリに収まっても用途はかなり限られます。著者が「quantization should be embraced, rather than feared」と書きつつ、1bitは例外的にダメだと切っているのも納得です。圧縮は万能ではないし、限界を見誤るとローカルLLMの印象そのものを悪くします。小さくすることと、仕事をこなせることは別物です。
著者はこの検証に相当なお金を使っています。ModalのGPU代だけでGPQAとIFBenchが663ドル、Terminal-Bench 2.1が2,308ドル。しかも、実行環境にはL40S、H100、H200を使っています。ここまでして得られた結論は、実はかなり地味です。4bitは十分、2bitは用途次第、1bitは危険。派手な発見ではありません。けれど、LLMの圧縮を巡る議論では、この「地味な線引き」こそが一番役に立つのだと思います。
なぜなら、ローカル運用の失敗はたいてい、モデル選びが間違っていたというより、期待値の置き方が雑だったことから起きるからです。ベンチマークで十分だった4bitを、感覚で「もっと削れるはず」と追い込み、結局使えなくする。逆に、2bitでもいける場面に必要以上の大きなモデルを載せて、速度やコストを無駄にする。この記事は、その両方に対する実務的な答えを出しています。私は、これは量子化の議論を少し大人にする記事だと思います。夢物語ではなく、どの圧縮率ならどの仕事を任せられるかを、ベンチマークと費用の両面から示しているからです。
参考: Benchmarking Qwen3.8 27B quantizations: 4-bit holds up, 1-bit collapses - Quesma Blog
