【朗報】AIモデルは「3分の1」に潰しても賢さが落ちない！容量7割削減で効く“崖”の正体が判明
「16ビットを4ビットに圧縮するんだから、サイズは4分の1になるはず。でも実際に測ると3分の1にしかならない。しかも圧縮しても賢さはほとんど落ちないのに、あと少し削った途端に急に壊れる」。これは、ローカル環境でAIを動かす人なら一度は悩む「量子化」の不思議だ。モデルをダウンロードしようとすると、同じ名前のファイルが「Q4_K_M」「Q8_0」といった記号付きで10個くらい並ぶ。あの意味深な記号の正体と、性能が急落する「崖」の正体を、実測の数字だけで解き明かす。
1/4ではなく1/3 「大事な部分は高精度のまま」
まず、実際にどれくらい小さくなるのか。例として「Qwen3.8-27B」というモデル（アリババが開発したAIで、270億個の数字＝重みで構成される）を見てみる。手を加えていない状態のファイルサイズは実に53.81GB。これをQ4_K_Mに落とすと17.77GBになる。16ビットから4ビットへなら理論上は4分の1のはずだが、実測は約3分の1。なぜか。
理由は「全部の数字を4ビットにするわけではない」からだ。言葉を数字に変える表など、重要な部分は高い精度のまま置いておく。つまり「1つ1つは荒くするが、どれくらい荒いかをちゃんと記録している」という工夫の上に、この技術は成り立っている。だから理屈の4分の1にはならず、実測で3分の1になるのだ。
賢さは本当に落ちないのか 2026年1月の論文が示す結果
疑い深い読者のために、最新の測定データを確認しよう。2026年1月11日付で公開された論文（Uygar Kurt著「Which Quantization Should I Use?」）は、Llama-3.1-8B-Instructを使って量子化前後の賢さを測っている。※1機種での結果なので全てに当てはまるとは限らないが、形は見える。
算数の正答率は、手を加えていない状態が77.63点。Q4_K_Mに潰すと77.41点。なんと0.22点しか下がらない。容量は3分の1になっているのに、実質的な性能低下は誤差の範囲なのだ。常識テストも72.51→72.35とほぼ無傷。指示に従うテストに至っては78.93→79.06と「上がって」見えるが、これも誤差の範囲。結論としては、1点や2点の上下は気にせず、桁で見るのがコツ。10点動いたら本物の変化だ。
なぜ壊れないのか 「体重計」と「倍率・下駄」の妙
じゃあ、なぜここまで削っても賢さが残るのか。鍵を握るのは「重み」の性質だ。モデルの中の270億個の重みは、どの神経の繋がりをどれくらい重く見るかの数字で、それぞれの重みはそこまで正確である必要はない。例えるなら体重計で、体重を測るとき小数点以下を何桁まで知りたいか。0.1kgで十分で、0.001kgまで出ても意味がない。モデルの重みも同じで、細かすぎる桁は仕事をしていない。その「要らない桁」を捨てているから、賢さが保たれるのだ。
問題は、4ビットでは16段階しか表現できないこと。16段階は少なすぎる。そこで、近い数字同士をまとめて「その範囲内で16段階に割る」という工夫が入る。体重計なら、測る相手が50kgから58kgの人だけならその8kgを16個に割れば、1メモリは0.5kgになり急に実用的になる。
そして「どこからどこまでをまとめたか」の記録が、倍率（1メモリが何kgか）と下駄（どこから始まるか）という形で別途保存される。この記録があるおかげで、元へほぼ戻せる。この倍率と下駄を「どれくらいの単位で持つか」が品質を左右する。k-quantsという手法では、重みを256個ずつの大きな塊に分け、その中を32個ずつの小さな塊に分割。小さい塊ごとに倍率と下駄を持ち、さらにその倍率自体もまとめて荒く記録することで、記録による容量増加を抑えている。だからQ4系は重み1個あたり実質4.5ビット。この0.5ビット分の「記録」が、賢さを保つカギなのだ。
問題は「崖」 容量7割削減から先に何が待つのか
ここからが本題だ。あの論文は「容量をどれだけ削ったか」も記録しており、Q4_K_Mの削減率は69.41%（約7割）。それで算数は0.2点しか落ちなかった。では、もう一段下のQ3_K_M（3ビット）はどうか。削減率は75.03%で、算数は73.16点。7割を超えても、まだ我慢できる範囲だ。
しかし、その先が危ない。同じ3ビットでもっと攻めた設定のQ3_K_S（削減率77.23%）になると、算数はなんと68.31点へ急落。元の77.63から実に9.32点の大幅低下だ。「はっきりバカになった」と感じるレベルで、算数だけでなく指示に従うテスト（78.93→73.89）や知識テスト（63.5→59.31）も一斉に落ちる。容量はほとんど変わっていないのに、崖から一気に転げ落ちるのである。
この「崖」の正体について、動画ではこう説明されている。ファイルを限界まで小さくしようとすると、倍率と下駄の「記録」まで削らざるを得なくなる。記録を荒くするか、まとめる単位を大きくするか。そうなると16段階を広い範囲に引き延ばすことになり、急に精度が崩れる。つまり「数字を荒くした」のではなく「荒さを記録する余白まで削った」ことが崖の原因というわけだ（論文は境目を示すだけで、原因までは書いていない、との但し書きつき）。
16GBのグラボなら何を選ぶべきか
では、一番多い「VRAM 16GB」のグラボではどれを選べばいいのか。ひとくちに全部使えるわけではなく、画面表示や会話の記憶置き場も同じメモリを使うため、実質は15GBほどしか使えない。Qwen3.8-27BならQ4_K_M（16.55GB）は入らず、Q4_K_S（15.57GB）も無理。IQ4_XS（14.5GB）なら入るが残り0.5GBではほぼ話せない。Q3_K_M（13.6GB）で残り1.4GBなら話せるが、それは「崖の一歩手前」に踏み込むことになる。
そこで提案されているのが「発想の転換」だ。大きいモデルを無理に押し込むのではなく、もっと小さいモデルを良い量子化（Q5系）で動かす方が安全だという考え方。3ビットで9点落ちるのは実測で確認済みなので、崖に足をかける代わりに一回り小さい相手を選ぶ。なお、この選択を自分で確かめる手順も用意されている。同じモデルの量子化違いを2つダウンロードして並べ、同じ難しい質問をするだけだ（Ollamaならタグを変えるだけで指定可能、LM Studioなら一覧から選ぶ）。雑談では差が出にくいので、算数や手順が絡む込み入った問題で試すのがコツ。また、同じQ4_K_Mでも配布元によってファイルサイズが違う（ggml-org版18.97GB／bartowski版17.77GB）ため、残り容量ギリギリで戦うなら事前のサイズ確認も忘れずに。
量子化とMoEの違いも整理しておく
混同されがちなのが「MoE」だ。量子化は「数字そのものを荒くする」（ファイル全体が小さくなる）技術で、MoEは「使う場所を絞る」（専門家ごとに分けて、質問に応じた一部だけを動かす）技術。MoEは速さは上がるがメモリは全員分必要で、ファイルサイズは減らない。両方いっぺんに使えるため「モデルを量子化したMoE」も存在するが、MoEは専門家を選ぶ計算にも荒くした数字を使うため「量子化に弱い」という主張もあり、これは決着していない議論だ。
ネットの反応
わかりやすい。コピーして保存した
面倒だからBF16でいいやってなってるんだが
7割削って無傷で、あとちょっとで9点落ちるってのがリアルすぎて怖い
Q3_K_Sの「崖」の話、まさに体験したわ。なんで急に壊れるんだろうと思ってた
16GBグラボでQ3なんて使ってた自分、実は崖の縁で暮らしてたんだな
倍率と下駄の0.5ビットが効いてるっていう説明、すごく腑に落ちた
同じQ4_K_Mでも配布元で1GBも違うのは知らなかった。注意しよう
AIの所感
「圧縮しても賢さはほぼ落ちない」という話は、直感に反するだけに本当に面白い。本質は、モデルが持つ膨大な「冗長性」にある。270億個の重みのうち、多くの数字は1桁目や2桁目が大雑把でよかった。それを効率的に捨てることで、人間の知能とほぼ同等の出力を維持したまま、サイズだけを3分の1にする。まるで「本質を見抜く力」のような技術だ。
一方で、「崖」の存在は重要な警告でもある。どこからか性能が急に壊れる、その境目は使うモデルや用途によって変わる。性能評価を「桁で見る」という指摘は、AIに限らずあらゆる技術の見極めに通じる。ローカルAIの世界は、理論と実測のズレが誤解を生みやすい分野だけに、こうした実測ベースの検証は貴重だ。小さなモデルを安全な量子化で動かす、という実践的なアドバイスも、多くのユーザーの救いになるだろう。