モデルの選定
ローカルLLMを動かす際の最初の難点は、どのモデルを使うかを選ぶところです。モデル自体の特徴で判断する前に、モデルのハードウェア的スペックも考える必要があります。
Hugging Faceで「物理スペック」を読み解く
まず知るべきことは、「そのモデルが、手元のPCの貴重なメモリをどれだけ消費するか」という物理的制約面です。
では、実際に世界中のオープンソースLLMが集まるプラットフォーム「Hugging Face」を覗いてみましょう。
いろいろな「モデル」があり、それらをどう見たらいいかわからないと思います。まず、その前に「モデル」を評価するための共通の3つの指標があります。
- ファイル名の中の「数字 + B」： パラメータ数（7B＝約70億個のパラメータ）
- ファイル名の中の「Q + 数字」： 量子化ビット数（Q4＝4ビット圧縮）
- Size（ファイル容量）： これが「最低限必要なVRAM（メモリ）容量」の目安になります。
「このモデルは賢いか」という性能評価（ベンチマーク）を見る前に、まずはこのファイルサイズを見てそのモデルの概要を判断をしましょう。
具体的なモデルファイルの見方
では、llama-32 （図1） を見てみます。
さまざまなモデルがありますが、ここを見ると先ほどの1Bや3B、11Bや90Bといった「B」情報がすぐにわかります。
では、続いてLlama-3.2-3B-Instruct を選択してみます。
しかし、先ほどのQとSizeについては全くわかりません。
なぜなら、これらの情報は、生データであってこれ自体は、自分でモデルファイルを作る人のためのデータだからです。
つまり、これらのデータを使って多くの方が、さまざまな最適化や自分のハードウェアに特化したファイルを作って公開するというようになっています。
今回は、そのモデルファイルを作ることはしないので、次回インストールするLM Studioの公式コミュニティが公開しているもの を見てみます。
公開しているモデルがあり、たくさんのモデルがあることがわかります。
ここで、先ほどののモデルである Llama-3.2-3B-Instruct の「Files and versions」（図2）を開いてみてください。
このようなファイルから、3BでQ4は約2Gで、3BでQ8は3.4G程度のメモリが必要とわかるわけです。
また、例えば、Googleが公開しているモデルのgemma-4では、以下のようなファイルがあります。
- gemma-4-12B-it-Q8_0.gguf （12.7 GB）
このようにBとQの値を見ながらどれを選ぶかを決めていきます。
パラメータ数と「メモリ消費」のシビアな関係
着目すべきパラメータ数（7B、13B、70Bなど）は、モデルの「知能のポテンシャル」であると同時に、「ロードするだけで消費するメモリ容量」そのものです。
ここで、Mac（Apple Silicon）の「統合メモリ（Unified Memory）」の特性も踏まえて考えて見ましょう。
モデルをロードした瞬間にメインメモリが固定され、OSや他のプロセスが使える領域が確実に減ります。一般的なデータのように「使われていない領域がキャッシュとして退避される」といった仕組みはないため、注意が必要です。
32GBメモリのMacで、28GBのモデルをギリギリロードできたとしましょう。「動いた！」と喜ぶのも束の間、いざ推論を開始して数文字出力した瞬間、システムは深刻なメモリ不足（スワップアウトの連鎖）に陥り、GUIの操作すら出来なくなってしまいます。
「動く」は「常用できる」と同義ではありません。インフラとして24時間安定稼働させるためには、「安全のためのマージン」も意識する必要があります。これは、実際にそのPCに搭載されているメモリ容量や、用途によっても変わります。まずは、検証にあたって以下のような目安としてこのような基準で見てみればよいと思います。
- モデルのファイルサイズ + OSなどのメモリ（約8GB）＜搭載メモリの70%〜80%程度
つまり、32GBメモリのMac Studioならば、8B～14Bクラスのモデルまでが検証できる現実的な実用ラインとなります。
もし、このメモリ量をすべて独立したグラフィックボード（VRAM）で確保しなければならないとしたら、WindowsやLinux PCだとどれほどの高スペックなマシンになってしまうか、想像がつくでしょう。
さらに、そのGPUを24時間365日動かす電気料金や、オフィスには置けないほどの排熱・騒音対策まで考えれば、多くの組織にとって自作PCによる実務運用は実用性が乏しくなります。
一見、検証機にMac Studioを導入するのは少々ハードルが高い（大げさだ）と思うかもしれませんが、ローカルLLMの世界に正しく足を踏み入れるには、Mac Studioレベルのスペックは決して過剰ではなく、むしろ、導入の入門機ということがわかると思います。
量子化とは
次に意識すべきは、モデルのデータ形式です。先ほど登場した「量子化（Quantization）」について解説します。
「量子化」とは、平たく言えば、モデルという「脳」の神経回路の「計算精度をあえて大雑把にして、ファイルサイズを劇的に圧縮する」技術です。
元のモデルは非常に高い精度（16ビット浮動小数点など）で演算を行いますが、その分莫大なメモリを必要とします。これを、人間が実用で困らない程度の粗さに「丸める」ことで、メモリ消費量を3分の1から4分の1に減らすのが量子化の正体です。ローカル環境でLLMを動かす場合、この「GGUF」というフォーマットに量子化されたモデルを使うのが現在の世界標準となっています。
「Q4_K_M」がおすすめ？
ここまで解説してきた「パラメータ数」と「量子化」は、ローカルLLMの性能とサイズを決める独立した2つの要因（掛け算）です。
- パラメータ数（7B／14B／32Bなど）： 脳細胞の「数」そのもの（知能の最大ポテンシャル）
- 量子化（Q4／Q8など）： 脳細胞が使う言葉の「繊細さ（データの解像度）」
もし、「迷ったらQ4_K_Mを選びましょう」などのような助言があったときにそれはどんな意味なのでしょうか。
それは「脳細胞の数をそこそこ大きく保ったまま、言葉の解像度を4ビット（元の1/4）まで間引いて、手元のPCに乗るサイズに圧縮したファイルを選びなさい」という意味になります。でも、同じようにサイズを縮小したいなら、パラメータ数を下げて、量子化レベルをあげるという選択もあるはずです。
このどちらを選ぶべきか迷った場合に、次のように考えれば1つの目安になるでしょう。
| 目的 | アプローチへの考え方 | 特徴 |
|---|---|---|
| 汎用的な知能、文脈への理解（要約・壁打ち利用など） | 大きなモデル + 高圧縮（Q4等） | 大きなモデルで「概念を捉える良さ」を活かして、ファイルサイズを小さくする |
| 厳密なルールや出力のブレを抑える（ログチェックやJSON構造化など） | 小さいモデル + 低圧縮（Q8） | 解像度を高くし、条件分岐などの正確さや出力のブレ、ハルシネーションを出来るだけ抑える |
つまり、「理解の広範囲さが重要ならばB（パラメータ）を大きく、出力の正確性が重要ならばQ（量子化）を大きく」と考えてバランスをとるようにします。多くの方が、ローカルLLMの検証の用途として、チャットや文章の要約などで使うと思います。そのため、「Q4_K_M」がおすすめと言われる理由もわかると思います。
もしあなたが、チャットで動かしてみて「これなら本当に実務で使えるじゃん！」と確認したいのであれば、Llama-3.2-3B-Instruct-Q4_K_M.gguf ではなく、gemma-4-12B-it-Q8_0.gguf くらいのモデル（120億パラメータ・8ビット高解像度）を選択しておけばよいとなります。
