自分のパソコンで30BのLLMを動かしたいとするね。グラフィックカードがそこそこ上位のRTX5080なら、VRAMは16GBでわりと余裕がある。でも30Bのモデルファイルだけで20GBを超えていて、VRAMをオーバーしてしまう。
こんなときはどうすればいいのかな。
もっと高いグラフィックカードを買う方法もあるけど、モデルをもっと小さな数字で保存する方法もあるよ。それが量子化だよ。モデルが覚えた膨大な数字を、より少ないビットで表して、ファイルサイズとメモリ使用量を減らすんだ。
昔は量子化の技術が普及していなくて、VRAMを大きく超えるサイズのモデルは、動かしてみること自体が難しかった。でも量子化のおかげで、この問題を乗り越えられるようになったんだ。
10月16日に公開されたOllama v0.40.6も、これに関係するアップデートだったよ。新しく対応した形式はQ2_0。モデルの重みをとても小さな単位に圧縮するGGUF形式の一つだね。
✦ Ollama v0.40.6のアップデート内容
2026年10月16日公開
もちろん、llama.cppではすでにQ2_0のGGUFを実行できた。でもOllamaのファイル読み取り部分が、その形式をうまく読めなかったんだよね。今回のアップデートで、Ollamaでもその形式のモデルをきれいに読み込んで実行できるようになったんだ。
量子化は、モデルをどうやって小さくするのかな
言語モデルは、数十億個の重みでできているんだ。重みは、モデルが文章を理解して、次の単語を選ぶときに使う数字だと思えばいいよ。
「たくさんの単語の中から、どの単語を選ぶのが確率的によりよいかを探すための、参考用の数字」と言えば、少し分かりやすいかな。もともとこの数字を32ビット浮動小数点、つまりFP32で保存していたなら、数字一つに4バイト必要になるよ。
数字一つは小さく見えても、数十億個が集まると、ファイル一つが数十GBに膨らんでしまう。
量子化は、こうした数字の量を、理屈に合った方法で減らしていくことなんだ。細かい目盛りが刻まれた定規で図面を描いていたのに、目盛りの粗い定規に替えるようなものだと思えば分かりやすいかな。
目盛りが粗くなるほど作業はやりやすくなるけど、とても精密な図面を完璧に描くのは難しくなる。きっと少しだけ隙間ができるはずだよ。
✦ 量子化のトレードオフ
得られるものと、手放すもの
だから量子化には、いつもトレードオフがある。ファイルとメモリを減らす代わりに、元のモデルの回答品質を少しあきらめるんだ。その代わり、メモリから読むデータが減るから、推論は速くなるはずだよ。ただ、必ず速くなるわけじゃない。
実行する装置（たいていはグラフィックカード）がその形式を効率よく処理できないと、圧縮された数字を計算用に戻すのに時間がかかって、速度の利点が小さくなることがあるんだ。
戦争のとき、暗号解読者が味方にいれば、暗号で素早くメッセージをやり取りして戦況を有利にできる。でも暗号解読者がいないのに暗号でやり取りすると、解読しているうちに夜が明けてしまうよ。
こういうときは、むしろ平文でメッセージを送ったほうが効率的かもしれない、ということだね。そこが、エヌビディアのRTXグラフィックカードが多くの人に愛されている理由でもあるんだ。こうした形式をいちばんうまくサポートしてくれるからね。
FP32からBF16、FP16まで：数字を保存する基本の形式
まずFP32は、高精度の基準点だと思えばいいよ。数字一つに32ビット、つまり4バイトを使って、細かく表すんだ。モデルの重みがFP32なら、サイズが大きい代わりに、量子化で生じる損失がほとんどない基準モデルとして使いやすいね。
✦ 数字の形式を系列で分けると
名前が似ていても、系列が違う
FP16とBF16は、どちらも16ビットだから、数字一つに2バイト入る。でも中身の配分が違うんだ。FP16は小数部分をより細かく表せる代わりに、表せる数字の範囲が相対的に狭い。
BF16はFP32に近い広い範囲を保つ代わりに、小数の細かさを削ったんだ。だから、どちらも16ビットでも同じ形式じゃなくて、どんな作業をするかによって選び方が変わる。それでモデルごとに、両方試してみるのがいいよ。
どちらが望む結果に近い値をくれるか、テストしてみるんだよ。どちらが優位とはっきり言うのは難しいんだよね。
INT8とFP8は8ビット、つまりだいたい1バイト級だよ。INT8は、整数の段階いくつかとスケール値を組み合わせて、元の重みを近似する方式。FP8は、とても小さな浮動小数点の数字体系を使う。
FP8には、小数の表現をもう少し細かくするE4M3や、もっと広い値の範囲を扱うE5M2のような形式がある。名前にどちらも「8」が入っていても、INT8とFP8は数字の入れ方からして違うんだ。
ここにMXFP8もある。これはFP8の数字だけを使うんじゃなくて、連続する32個の値ごとに別のスケールを付ける、ブロック単位の方式だよ。ひとかたまり全体に一つの目盛りを無理に合わせるより、小さな区間ごとに合った目盛りを使うわけだね。
数字一つあたり8ビットだけで終わる単純なFP8と違って、スケールの情報も必要になる。その代わり、値の範囲が区間ごとに変わるデータを、より合った形で表せるんだ。
NVFP4は、名前のとおり4ビット浮動小数点の形式だよ。16個の値ごとにブロックスケールを付けて、全体のスケールも一緒に使うことで、値そのものは小さく保存しながら、表せる範囲を調整するんだ。
NVIDIAの低精度演算の技術で扱われる形式だけど、OllamaもApple Silicon向けのMLXエンジンで、NVFP4モデルの実行に対応すると発表した。
ただ、こうしたFP系の形式は、モデルファイルと実行エンジン、ハードウェアが対応しているかを一緒に見る必要がある。名前だけ見て、どのOllama環境でもそのまま使えると思うのは困るよ。
✦ グラフィックカードで変わる事情
エヌビディアかどうかで、気にする点が違う
ここまでに挙げた量子化の方式は、エヌビディアのグラフィックカードを使っていないと、使いにくいことが多い。だからAMDやインテルのグラフィックカードを使う人や、Macを使う人は、名前に「Q」が付いたGGUFの量子化方式を探すことになる。
でも、GGUFの量子化方式は、基本的に速度が少し遅い。もちろん、エヌビディアのグラフィックカードを使う人でも、VRAMが小さすぎる場合は、小さなVRAMでもよく動くGGUFを使うことがある。ただ、速度で損をするのは仕方ないよ。
FP16やBF16のような方式が、Windowsで実行ファイルをそのまま実行する感じなら、GGUFは、圧縮ファイルの中に入っている実行ファイルを実行する感じかな。実際に動かして比べてみると、まさにそんな感じがするよ。
Macを使う人は、Macに最適化されたMLXの量子化方式を探すこともあるけど、どうしても一般的な方式じゃないから、使いたいモデルにMLX方式がないことがかなり多い。これが、エヌビディアがAI市場で強い地位を持っている理由だね。
エヌビディアのグラフィックカードを使う人は、どんな量子化方式でも対応しているだろうと思って、とりあえず実行する。でもAMD、インテル、Macを使う人は、「この量子化方式は自分のグラフィックカードで対応してるのかな」から考えなきゃいけない面倒があるんだ。
Q8_0、Q4_K_M、Q2_0：Ollamaでよく見る名前
ここからは、Ollamaでモデルを探すときによく見かけるQ8_0、Q4_K_M、Q2_0を見てみよう。ここでのQは、GGUFで使う特定の量子化方式の系列を指しているよ。先に説明したINT8やFP8と、数字だけ比べて同じ種類だと思ってはいけない。
✦ GGUFのQ系、3つの特徴
Q8_0、Q4_K_M、Q2_0
Q8_0は、8ビットの値にブロックごとのスケールを付けるGGUFの量子化方式だよ。32個の重みを34バイトに収めるから、スケールまで含めると平均で約8.5ビット入ることになる。
ファイルはかなり大きいほうだけど、低ビットの量子化より元のモデルの性能をうまく保とうとする選択肢なんだ。
Q4_K_Mは、ローカルの言語モデルでよく使われる折衷案だよ。K系のブロック量子化をベースにしながら、一部の重みにはより高い精度を割り当てる混合構成になっている。
だから名前はQ4でも、実際の平均はモデルや実装によって、おおよそ4.8〜4.9ビット/重みくらいなんだ。Q4という名前は、すべての重みがぴったり4ビットで保存されるという意味じゃない。
ファイルサイズと回答品質のバランスを取りたい人が、Q4_K_Mをよく選ぶ理由だよ。
今回Ollamaが対応したQ2_0は、もっと大胆だよ。64個の重みを18バイトのブロックに保存するから、スケールまで合わせた平均は2.25ビット/重みになる。
同じ数の重みをQ4_K_Mよりずっと小さく入れられるけど、元の数字を表せる段階も大きく減る。長い推論やコーディングで答えが乱れたり、モデルならではの能力がより多く傷ついたりする可能性も高くなるよ。
Q2_0とQ2_K、IQ2は、名前が似ていても、それぞれ別の量子化方式なんだ。よく分からなければ、まずQ8_0、Q4_K_M、Q2_0の方式から試してみよう。
数字で見ると、違いがよく分かるよ
重みが10億個だと仮定すると、FP32は重みのデータだけで約4GB、FP16とBF16は約2GB、INT8とFP8はおよそ1GBが必要になるよ。
✦ 重み10億個のおおよその容量
メタデータ・重み以外のテンソルを除く、重みデータ基準
GGUFのQ8_0は、スケールのオーバーヘッドがあるから約1.06GB、Q4_K_Mは平均ビット数を基準にすると約0.61GB、Q2_0は約0.28GBくらいと計算できる。
実際のモデルファイルには、メタデータや別の形式で保存された一部のテンソルも入っているから、最終的なファイルがこの数字とぴったり同じにはならないよ。
この数字だけ見ると、Q2_0が無条件でいちばんよく見えるかもしれない。でもサイズを4分の1に減らしたからといって、知能をそのまま保ったままタダで手に入れた結果じゃない。
量子化はモデルのサイズを減らす技術であって、モデルの能力を同じ水準に保ったまま、あらゆるコストをなくす魔法じゃないんだよ。
グラフィックカードがエヌビディアじゃないなら…どの形式を選べばいいのかな
一般的なローカル推論なら、まずQ4_K_Mから試してみるのがいい出発点だよ。メモリ使用量を抑えながら、使える品質を期待できるからね。
✦ 形式選びの目安
一般的なローカル推論の場合
メモリに余裕があって回答品質のほうが大事なら、Q5_K_MやQ6_K、もっと大きなファイルを我慢できるならQ8_0も候補になる。
逆に、モデルがメモリに入らなくて、そもそも実行すらできないなら、Q2_0のようにもっと強い量子化を試してみるといいよ。そのときは、サイズが減った分、品質も一緒に比べてみないとね。
今回のOllamaのアップデートの意味も、そこにあるんだ。実は、Q2_0は誰もが最初に選ぶ基本値じゃない。大きなモデルをなんとかローカルで動かしたいときに取り出す、小さなリュックみたいな選択肢だね。
普段はQ4_K_Mか、それより上の形式で品質とサイズを合わせて、本当にメモリが足りないときにQ2_0を試すのが賢いやり方だよ。
今回はここまでにするよ。また会おう。
関連記事
- ComfyUIに新モデル！MOSS-Imageは何が特別？（商用利用OK）
- FLUX 3 Image Klein vs Qwen Image 2.1：守る？なじませる？
- Nano Banana 2.1、4K画像が1枚約150ウォン。使えるのかな？
🌐 韓国語版: 10월 16일, Ollama의 Q2 양자화 형식 지원 시작! 양자화가 뭔지 쉽게 알아보자
🌐 英語版: Ollama's New Q2 Quantization Support: Quantization Explained
💬 コメント
まだコメントがないよ。最初のコメントを書いてみてね。
コメントを投稿