自分のノートPCで動くLLMはどれ？ RAM・VRAM・パラメータ数・量子化・GGUFの選び方

LM StudioやOllamaのモデル一覧には、7B、Q4_K_M、GGUF、128Kといった表記が並びます。数字が大きいほど高性能に見えますが、大きなモデルほど必要メモリ、応答時間、発熱も増えます。

モデル選びを決めるのは、次の5要素です。

PCのメモリ構成 × パラメータ数 × 量子化 × コンテキスト長 × 用途

結論から言えば、ローカルLLMは「読み込める最大モデル」ではなく、十分な速度・コンテキスト長・回答品質を維持できるモデルを選ぶべきです。

1. まずはPC側のRAM・VRAMを理解する

CPUとGPUの役割

CPUはOSやアプリケーションを含む汎用処理を担当します。GPUは同じ種類の計算を多数並列に実行することが得意で、LLMが行う大規模な行列演算と相性がよいプロセッサです。

LLMの推論では、モデルの重みをメモリから繰り返し読みながら計算します。そのため、計算性能だけでなく、単位時間にどれだけデータを運べるかを示すメモリ帯域も速度に影響します。同じメモリ容量でも、GPU、チップ世代、電力設定、推論ランタイムが違えば生成速度は変わります。

RAMとVRAMの違い

RAMはOS、ブラウザ、IDEなどが使うメインメモリです。ディスクリートGPUを搭載した一般的なPCでは、GPUが直接使うVRAMはRAMと物理的に分かれています。NVIDIAのCUDA Programming Guideも、CPUに接続されたホストメモリとGPUに接続されたデバイスメモリを区別しています。

モデルをVRAMに収められると高速になりやすい一方、収まらない層をRAMとCPUへオフロードできるか、その場合にどこまで遅くなるかはランタイムと接続帯域次第です。「ロードできた」だけではGPU上で快適に動いているとは限りません。

Apple Siliconのユニファイドメモリ

Apple Siliconでは、CPUとGPUが同じユニファイドメモリを共有します。AppleのMetalドキュメントでも、ユニファイドメモリをGPUがCPUとすべてのメモリを共有する構成として説明しています。

ただし、MacBookの24GBすべてをLLMへ割り当てられるわけではありません。macOS、ブラウザ、IDE、推論エンジンも同じ領域を使います。

flowchart LR
    accTitle: MacとWindowsのメモリ構成
    accDescr: Apple SiliconではCPU、GPU、OSがユニファイドメモリを共有する。ディスクリートNVIDIA GPU搭載PCではCPUとOSがRAMを使い、GPUは別のVRAMを使う。
    subgraph Mac[Apple Silicon]
        MC[CPU] --> UM[ユニファイドメモリ]
        MG[GPU] --> UM
        MO[OSとアプリ] --> UM
    end
    subgraph Win[NVIDIA GPU搭載PC]
        WC[CPU] --> RAM[RAM]
        WO[OSとアプリ] --> RAM
        WG[GPU] --> VRAM[VRAM]
        RAM <--> WG
    end

MacとWindowsのメモリ構成

したがって、Macの16GBユニファイドメモリと、WindowsのRAM 16GB＋VRAM 8GBは同じ構成ではありません。

2. モデルの「3B」「7B」は何を表すのか

Bはbillion、つまり10億を意味します。パラメータは、学習によって調整されたモデルの重みです。

• 3B：約30億パラメータ
• 7B：約70億パラメータ
• 14B：約140億パラメータ
• 30B：約300億パラメータ

一般には、パラメータが多いモデルほど複雑な指示や知識、推論を扱える可能性があります。その代わり、ファイルサイズ、必要メモリ、ロード時間、生成時の計算量、発熱、消費電力も増えます。

ただし、パラメータ数は品質ランキングではありません。新しい7Bモデルが古い14Bモデルより特定用途で優れることもあります。世代、学習データ、指示チューニング、対応言語、コンテキスト設計を合わせて確認してください。

MoE（Mixture of Experts）では、表記された総パラメータ数と、1トークンの処理で実際に使う有効パラメータ数が異なる場合があります。ただし、使わない重みも通常は保存・ロードする必要があるため、メモリを有効パラメータ数だけで見積もるのは危険です。

3. モデルサイズと必要メモリの関係

重みだけの理論値は、次の式で概算できます。

重みのサイズ ≒ パラメータ数 × 1パラメータ当たりのビット数 ÷ 8

7Bモデルを単純な4ビット表現にすると、70億 × 4 ÷ 8 = 約35億バイト、すなわち約3.5GBです。ただし、実際の量子化形式にはブロックごとのスケールなどが加わるため、GGUFファイルはこの単純計算より大きくなることがあります。たとえばllama.cppの資料では、ある8BモデルのQ4_K_Mは4ビットちょうどではなく、約4.89 bits/weightとされています。

この表は、4、5、8、16ビットをそのまま掛けた重みだけの理論値です。GBとGiBの違いや量子化方式のオーバーヘッドも省略しています。

実行時には、さらに次の領域が必要です。

• KVキャッシュ
• 推論エンジンの作業領域
• モデルのメタデータとトークナイザー
• GPUへ配置するバッファ
• OSと他のアプリケーション

ファイルサイズが8GBでも、空きメモリ8GBで安定して動くとは限りません。購入やダウンロード前には、常に余裕を残してください。

4. 量子化とは何か

量子化は、重みをより低い精度で表現し、ファイルサイズと必要メモリを減らす技術です。llama.cppの量子化ツールは、F32やBF16などの高精度GGUFを低ビット形式へ変換できます。サイズ縮小や高速化を期待できる一方、情報を丸めるため品質低下の可能性があります。

Q4_0、Q4_K_S、Q4_K_Mは同じものではありません。名称は、ビット数だけでなく、ブロック方式やテンソルごとの精度配分を表します。K_Mのような混合方式では、すべての重みが一律4ビットになるわけでもありません。

初心者の出発点はQ4系です。メモリに余裕があればQ5を比較し、品質差が用途上重要で、速度と容量を許容できるならQ8を試します。極端に量子化した大型モデルと、高精度な小型モデルのどちらが優れるかは一律に決まりません。同じ評価プロンプトで実測する必要があります。

5. GGUFとは何か

次の3つを分けて考えましょう。

• モデル：学習済みのLLMそのもの
• 量子化：重みの表現精度を下げる処理
• GGUF：重み、テンソル情報、メタデータなどを格納するファイル形式

Hugging FaceのGGUF解説によれば、GGUFはモデルを素早く読み書きするためのバイナリ形式で、テンソルに加えて標準化されたメタデータも保持します。つまり、GGUFはモデル名でも量子化方式でもありません。1つのモデルがQ4、Q5、Q8など複数のGGUFファイルで配布されることがあります。

実行ルートは目的に応じて選べます。

• 幅広いCPU・GPUでGGUFを扱う：llama.cpp系
• Apple Silicon向けのモデルを使う：MLX-LM
• GUIで検索・実行する：LM Studioなど
• CLIやローカルAPIとして使う：Ollamaなど

MLX-LMは、Apple Silicon上でLLMの生成、量子化、追加学習を行うPythonパッケージです。GGUFとは異なる配布・実行ルートなので、ダウンロード前にランタイムが対象形式とモデル構造へ対応しているか確認してください。

6. コンテキスト長とKVキャッシュ

コンテキスト長は、モデルが一度に参照できるトークン数です。システムプロンプト、会話履歴、貼り付けた文書やコード、生成中の回答が同じ予算を消費します。

自己回帰型LLMは1トークンずつ生成します。過去のAttention計算を毎回やり直さないようにKeyとValueを保存する領域がKVキャッシュです。Hugging Face Transformersの資料でも、KVキャッシュは過去の計算結果を再利用して生成を高速化する仕組みと説明されています。

モデルの重みはロード後ほぼ固定ですが、一般的な動的KVキャッシュはトークンが増えるにつれて成長します。必要量はレイヤー数、KV head数、データ型、バッチ数、ランタイム、Sliding Window Attentionなどの構造によって変わるため、パラメータ数だけでは計算できません。

モデルカードに「128K対応」とあっても、最初から128Kを割り当てる必要はありません。通常のチャットは4K〜8Kから始め、長いコードや文書が必要なときだけ16K以上へ増やします。メモリ不足なら、モデルサイズだけでなくコンテキスト設定も下げてください。

7. MacBookとWindowsノートPCでは選び方が違う

Apple Silicon搭載MacBook

CPUとGPUがユニファイドメモリを共有するため、専用VRAM容量に分断されずモデルを配置できます。Metal対応のllama.cpp系やMLX-LMが候補です。一方、購入後にメモリを増設できず、OSやIDEも同じ容量を使います。容量だけでなく、チップ世代とメモリ帯域も生成速度に影響します。

NVIDIA GPU搭載Windows PC

CUDA対応ランタイムを利用しやすく、モデルとKVキャッシュをVRAMへ収められれば高速になりやすい構成です。RAMとVRAMは別々に確認してください。VRAMを超える部分をRAMへオフロードできても、PCIe経由の転送やCPU処理によって生成速度が大きく落ちる場合があります。

同じGPU名のノートPCでも、消費電力上限、冷却、メモリ構成が異なります。製品名だけで速度を断定できません。

NVIDIA GPUなしのWindows PC

CPU推論、対応する内蔵GPU、またはVulkanなどを利用します。まず小型のGGUFから試すのが安全です。大型モデルがRAMへロードできても、対話用途では待ち時間が長すぎる可能性があります。

最終的な性能は、メモリ容量＋メモリ帯域＋GPUの種類＋ランタイム＋量子化＋コンテキスト長の組み合わせで決まります。

8. 16GB・24GB・32GB以上の選択目安

次の表は保証値ではありません。OSの使用量、モデル構造、量子化方式、コンテキスト長、ランタイム、チップ性能によって結果は変わります。最初に検証する候補として使ってください。

ディスクリートNVIDIA GPUでは、まずVRAM側を確認します。

flowchart TD
    accTitle: ノートPC向けローカルLLMの選択フロー
    accDescr: Apple Siliconではユニファイドメモリ容量から候補を選ぶ。それ以外ではNVIDIA GPUの有無を確認し、ある場合はVRAM、ない場合は小型GGUFのCPU推論から試す。
    A[PCを確認] --> B{Apple Siliconか}
    B -->|はい| C{ユニファイドメモリ}
    C -->|16GB| D[3B〜8B Q4から試す]
    C -->|24GB| E[7B〜14B Q4から試す]
    C -->|32GB以上| F[14B以上を実測する]
    B -->|いいえ| G{NVIDIA GPUがあるか}
    G -->|はい| H[VRAMを基準に候補を選ぶ]
    G -->|いいえ| I[小型GGUFをCPUで試す]
    D --> J[速度・メモリ・品質を測る]
    E --> J
    F --> J
    H --> J
    I --> J

モデル選択フロー

合否は「何Bまで起動したか」ではなく、次の条件で決めます。

• 最初の回答が返るまで待てるか
• 生成速度がチャットやコーディングに十分か
• ブラウザやIDEと同時に使えるか
• 長文入力や連続利用でも落ちないか
• 発熱、ファン音、バッテリー消費を許容できるか

9. コーディング・日本語・要約で選ぶ

コーディング

コード向けの学習や追加学習、対象言語、長いコードへの対応を確認します。エージェントから使うなら、Tool Calling、構造化出力、差分生成、Fill-in-the-Middle、利用するクライアントと互換性のあるローカルAPIも重要です。

固定課題として「この関数のバグを説明し、最小差分を出力する」「JSON Schemaに厳密に従う」などを試します。Claude CodeやCodexなどのクライアントに接続できても、そのモデルがツール呼び出しを安定して生成できるとは限りません。

日本語

対応言語の記載だけでなく、日本語の指示理解、敬語、固有名詞、自然さを実際に確認します。トークナイザーによっては日本語が英語より多くのトークンへ分割され、同じ文字数でもコンテキストと入力処理時間を多く消費します。

要約

長文を収められることに加え、固有名詞と数字を保持するか、入力にない内容を足さないか、指定した長さと形式を守るかを評価します。実際に扱う文書と同程度の長さでテストしてください。

モデル名のランキングはすぐ古くなりますが、固定した用途別プロンプトは次の世代にも使えます。

10. 「ダウンロードできる」と「実用速度で動く」は違う

モデルを選ぶ前にモデルカードを読みます。Hugging FaceのModel Cardsガイドでは、用途、制約、学習情報、データセット、評価結果などを記載する文書としてモデルカードを位置づけています。

最低限、次を確認してください。

• パラメータ数とDense／MoEの別
• Base、Instruct、Codeなどの種類
• 対応言語と想定用途
• コンテキスト長と推奨チャットテンプレート
• ライセンスと商用利用条件
• 既知の制約と評価結果
• 必要な推論ライブラリとバージョン
• GGUF、MLXなどの配布形式
• 量子化ファイルの作成者と変換元

成功状態は3段階あります。

1. ダウンロードできる
2. メモリへロードできる
3. 必要な速度と品質で継続利用できる

必要なのは3段階目です。モデルを起動したら、短い挨拶だけで判断せず、実際のコード、文書、会話履歴を与えて数分間使ってください。

11. モデルを実測するときに記録するもの

条件をそろえるため、同じプロンプト、コンテキスト長、最大生成トークン数、温度、ランタイム設定で比較します。llama.cppには推論性能を測るllama-benchも用意されています。

Prompt tokens/secは入力を読み込む速度、Generation tokens/secは回答を出す速度です。両者を混ぜずに記録します。さらにCPU・GPU使用率、発熱、ファン音、初回トークンまでの時間も残すと、ボトルネックを判断しやすくなります。

品質は、コーディング、日本語、要約の固定プロンプトセットで評価します。速度が速くても指示を守れないモデルや、品質が高くても一文ごとに長く待つモデルは、毎日の道具として最適とは限りません。

まとめ：最初は小さめのQ4から試す

判断手順はシンプルです。

1. RAM、VRAM、ユニファイドメモリを確認する
2. OS、IDE、ブラウザ用の余裕を残す
3. まず3B〜8BのQ4を試す
4. 実際の用途で速度、メモリ、品質を測る
5. 余裕があれば14B以上やQ5へ上げる
6. 厳しければモデルかコンテキスト長を下げる

「自分のPCで動く最大モデル」ではなく、毎日使える速度と品質を備えたモデルが、あなたのPCにとって最適なローカルLLMです。