ローカルLLM 統合メモリ 構造を徹底解説|必要容量・量子化・KVキャッシュの関係

anatato.jp へ本日もお越しいただきありがとうございます。
耳で聞くだけで短時間に分かりやすく理解できる音声会話形式の動画はこちら
ローカルLLMを自分のパソコンで動かそうとすると、最初に迷いやすいのがメモリです。
「16GBで足りるのか」「統合メモリはGPUのVRAMと何が違うのか」「モデルファイルが保存できれば動くのか」といった疑問は、カタログの数字だけでは解決できません。
ローカルLLMの実用性は、モデルの重み、量子化方式、KVキャッシュ、コンテキスト長、メモリ帯域、推論ソフトの最適化によって変わります。
- ローカルLLMと統合メモリ構造の違い
- CPU用RAMとGPU用VRAMを分ける構成との比較
- 7B・14B・32B・70Bモデルの重み容量の計算方法
- KVキャッシュとコンテキスト長が必要容量を増やす理由
- 16GBから128GBまでの用途別の考え方
- 「動く」と「快適に使える」を分けて判断する方法
💡ローカルLLMと統合メモリ構造の基本
ローカルLLMは端末内で推論する言語モデル
ローカルLLMとは、学習済みの大規模言語モデルをクラウド事業者のサーバーではなく、手元のパソコンやワークステーションで実行する利用形態です。
モデルの重みを端末へ保存し、CPUやGPUを使って文章生成、要約、分類、コード補助、文書検索などを行います。
入力内容を外部APIへ送らずに処理でき、通信できない場所でも利用できる点がローカルLLMの大きな特徴です。
ただし、端末内で動かすことは、回答の正確性や情報セキュリティを自動的に保証しません。
- モデルや推論ソフトの入手元を確認する
- 端末のアクセス権と暗号化を管理する
- 生成内容を一次情報と照合する
- モデルのライセンス条件を確認する
統合メモリ構造はCPUとGPUが同じ領域を共有する
統合メモリ構造では、CPUとGPUが同じ物理メモリ領域を共有します。
Apple Silicon搭載Macでは、CPU、GPU、Neural Engineなどが1つのSoCに統合され、ユニファイドメモリへアクセスします。
CPU用RAMとGPU用VRAMを単純に合算する仕組みではなく、最初から共有メモリとして設計されている点が重要です。
Appleの機械学習フレームワークであるMLXでは、配列が共有メモリ上に置かれ、CPUまたはGPUで演算するときにデータを別領域へ転送せずに扱えます。
ディスクリートGPU構成とはメモリの置き場所が違う
| 比較項目 | 統合メモリ構造 | ディスクリートGPU構成 |
|---|---|---|
| メモリ | CPUとGPUが共有 | システムRAMとVRAMが分離 |
| データ転送 | 同じ領域を参照できる | RAMからVRAMへの転送が発生し得る |
| 大容量モデル | 共有容量の範囲で置きやすい | 主にVRAM容量に制約される |
| 増設 | Macでは購入後に増設できない | 構成によって交換・増設できる |
| 主要環境 | MLX、Metal、llama.cpp | CUDA、ROCm、llama.cppなど |
統合メモリは大容量モデルを扱いやすくしますが、どの処理でもディスクリートGPUより速いという意味ではありません。
✨ローカルLLMで統合メモリ構造が注目される理由
GPUが共有メモリ上のモデルを参照できる
LLMの推論では、学習済みパラメータを保存した重みをメモリへ読み込みます。
ディスクリートGPUでは、GPUで高速に計算するためにモデルの大部分をVRAMへ配置するのが一般的です。
VRAMに収まらない部分をシステムRAMへ逃がすCPUオフロードも可能ですが、データ移動が増えると生成速度が低下する場合があります。
大容量の統合メモリでは、GPUが同じ共有領域から重みを参照できるため、一般的な単体GPUのVRAMを超えるモデルも候補にできます。
CPUとGPUが同じ配列を扱えるため、統合メモリ構造ではデバイス間の不要なデータコピーも減らせます。
MLXでは、CPUまたはGPUで演算するときに配列全体を別のメモリ領域へ転送する必要がありません。
ただし、転送を省けても行列演算や重みの読み出しは必要です。
「読み込める」と「快適に生成できる」は別
メモリ容量が大きければ、大きなモデルを配置できます。
一方、1秒間に何トークン生成できるかは、メモリ帯域、GPU性能、モデル構造、量子化カーネル、冷却性能などにも左右されます。
容量はモデルを置ける上限を決め、帯域と演算性能は待ち時間や生成速度を左右します。
- 容量:モデル、KVキャッシュ、バッファを保持できるか
- 帯域:重みをどの速度で読み出せるか
- GPU性能:行列演算をどの速度で処理できるか
- ソフト最適化:チップの能力をどこまで引き出せるか
🧠ローカルLLMが統合メモリを使う内訳
最大の基本要素はモデルの重み
モデルの重み容量は、パラメータ数と1パラメータ当たりのビット数から概算できます。
例えば70億パラメータの7Bモデルを4ビットで表現すると、理論上は約35億バイトです。
この式で求められるのは重みだけの理論値であり、実行時の総メモリ使用量ではありません。
実際には量子化用のスケール情報、トークン処理、一時バッファなどが加わります。
KVキャッシュは会話や資料が長いほど増える
自己回帰型のLLMは、直前までの入力と生成結果を参照しながら次のトークンを予測します。
過去のAttention計算で得たKeyとValueを保存し、再計算を減らす仕組みがKVキャッシュです。
KVキャッシュは生成を効率化しますが、保持するトークン数が増えるほどメモリ使用量も増えます。
Hugging Faceの公式文書でも、長いコンテキストではKVキャッシュがメモリの大きな部分を占め、オフロードや量子化が速度とのトレードオフになると説明されています。
KVキャッシュ量はモデル構造でも変わる
KVキャッシュは、パラメータ数だけから正確には判断できません。
層数、KeyとValueのヘッド数、ヘッド次元、精度、バッチ数、コンテキスト長によって変わります。
Multi-Head Attentionに比べ、Grouped-Query AttentionやMulti-Query Attentionを採用するモデルは、KeyとValueのヘッドを共有してKVキャッシュを抑えられる場合があります。
同じ32Bモデルでも、Attention構造が違えば長文処理時の必要メモリは同じとは限りません。
📐ローカルLLMのモデル規模と必要容量を計算する
精度別に重みの理論容量を比較する
| モデル規模 | 16ビット | 8ビット | 4ビット |
|---|---|---|---|
| 7B | 約14GB | 約7GB | 約3.5GB |
| 14B | 約28GB | 約14GB | 約7GB |
| 32B | 約64GB | 約32GB | 約16GB |
| 70B | 約140GB | 約70GB | 約35GB |
表は10進法の概算です。
実際の配布ファイルは量子化形式やメタデータにより増減します。
32Bの4ビット重みが約16GBだからといって、16GB搭載機で実用的に動くわけではありません。
実行時には重み以外の領域が必要になる
- KVキャッシュ
- 入力・出力トークンの管理領域
- 演算用の一時バッファ
- 推論ランタイム
- OSと常駐アプリ
- 画像対応モデルの画像エンコーダー
- RAGで使う埋め込みモデルや検索インデックス
モデル選びでは配布ファイルの容量だけでなく、推論中のピークメモリを確認する必要があります。
物理メモリが不足すると、OSがSSDの一部を仮想メモリとして使う場合があります。
スワップによって起動できても生成速度が大きく低下することがあるため、メモリ圧迫、スワップ使用量、生成速度を同時に確認しましょう。
🔧量子化がローカルLLMの統合メモリ必要量を変える
4ビット・8ビット量子化で重みを小さくする
量子化は、重みなどを低いビット数で表現し、容量と計算負荷を抑える技術です。
16ビットから4ビットへ変換すれば、重みの理論容量は4分の1になります。
量子化は、大型モデルを一般的なパソコンで扱うための中心的な技術です。
ただし、スケール値などの補助情報が必要なため、実ファイルが単純に4分の1になるとは限りません。
同じ4ビットでも形式と品質は同じではない
GGUF、GPTQ、AWQ、MLX向け量子化など、推論環境ごとに複数の形式があります。
GGUFにもQ4_0やQ4_K_Mなどがあり、重みの扱い方、容量、速度、品質が異なります。
「4ビット」という表示だけで比較せず、具体的な量子化方式と推論ソフトへの対応を確認してください。
- 配布元と元モデルが明記されているか
- 量子化方式が説明されているか
- 使用するランタイムに対応しているか
- ライセンス条件を満たすか
低ビット化には品質と速度のトレードオフがある
低ビット化は容量を減らしますが、元の重みが持つ情報を簡略化します。
文章分類や定型要約では差が小さくても、複雑な推論、数値、コード、固有名詞では差が現れる場合があります。
また、量子化された値を使うための処理が必要なので、低ビットほど必ず高速になるわけではありません。
必要な品質を保てる範囲で軽い形式を選び、実際の用途に近い入力で比較することが大切です。
📝用途別に見るローカルLLMの統合メモリ容量
16GB・24GBは小型モデルと短めの文書向け
16GBでは1B~8B級の量子化モデルが中心です。
短い質問、文章分類、下書き、定型的な要約などから始める用途に向きます。
24GBでは14B級も候補になりますが、長いコンテキストや画像入力、複数アプリの併用で余裕が減ります。
16GBは入門には使えますが、大型モデルや長文RAGへ広げたい人には制約が早く現れます。
32GB・48GB・64GBは実用範囲を広げやすい
32GBでは14B級を扱いやすくなり、量子化方式と文脈長によって20B~32B級も候補になります。
48GBや64GBでは32B級の余裕が増え、70B級の軽量量子化も読み込める場合があります。
70B級では重みが入るだけでなく、KVキャッシュを含めた余白と実測生成速度の確認が欠かせません。
96GB・128GBは大型モデルや複数処理向け
96GB以上では、70B級モデル、複数モデル、画像対応モデル、大規模なRAGなどの選択肢が増えます。
AppleのM4 Maxは公式に最大128GBのユニファイドメモリと最大546GB/sのメモリ帯域幅へ対応します。
大容量はモデル選択の自由度を高めますが、価格に見合うかは実際の用途と利用頻度で判断すべきです。
| 統合メモリ | 主な候補 | 注意点 |
|---|---|---|
| 16GB | 1B~8B級、短文処理 | 長文・画像・併用アプリで余裕が少ない |
| 24GB | 7B~14B級、軽量RAG | 14B級は設定と文脈長を確認 |
| 32GB | 14B級、条件により32B級 | 32B級の長文では不足し得る |
| 48~64GB | 32B級、条件により70B級 | 70B級は速度とキャッシュを要確認 |
| 96~128GB | 70B級、大規模RAG、複数モデル | 費用対効果と帯域を確認 |
⚡ローカルLLMの速度を決めるメモリ帯域と処理段階
デコードでは重みの読み出し速度が効きやすい
LLMは回答を1トークンずつ生成し、そのたびに多くの層を通って次のトークンを計算します。
このデコード処理ではモデルの重みを繰り返し参照するため、メモリ帯域の影響が大きくなる場合があります。
同じ容量でも帯域が異なれば、大型モデルの1秒当たり生成トークン数に差が出る可能性があります。
入力処理と文章生成は別の速度で見る
長いプロンプトを最初に処理する段階はPrefill、回答を順番に生成する段階はDecodeと呼ばれます。
- Time to First Token:最初のトークンが出るまでの時間
- Prompt Processing:入力文を処理する速度
- Tokens per Second:回答を生成する速度
- Peak Memory:処理中の最大メモリ使用量
ベンチマークを比べるときは、モデル名、量子化方式、入力長、出力長が同じかを確認してください。
Neural EngineのTOPSだけでは速度を判断できない
Apple SiliconにはNeural Engineが搭載されていますが、すべてのローカルLLMがそこで実行されるわけではありません。
MLXやllama.cppではGPUを中心に使う構成も多く、対応している演算やランタイムによって利用されるハードウェアが変わります。
製品比較ではNeural EngineのTOPSだけでなく、GPU、帯域、推論ソフト、実測値を確認しましょう。
🔍ローカルLLM導入前に確認する手順
用途からモデルと統合メモリを逆算する
先に高価なパソコンを選び、購入後にモデルを探すと、容量不足や過剰投資が起こりやすくなります。
用途、モデル、量子化、文脈長の順に決め、最後に必要な統合メモリを算出するのが合理的です。
| 順番 | 確認内容 | 見るポイント |
|---|---|---|
| 1 | 用途 | 要約、コード、RAG、画像など |
| 2 | モデル | 規模、言語、得意分野 |
| 3 | 量子化 | 形式、品質、対応ランタイム |
| 4 | 文脈長 | 通常使うトークン数 |
| 5 | 実測 | ピークメモリと生成速度 |
| 6 | 余裕 | OS、ブラウザ、将来用途 |
ライセンスとファイルの配布元を確認する
モデルの重みを公開していても、商用利用、再配布、派生モデルの公開が無条件に許可されているとは限りません。
非公式なモデルファイルや実行ツールには、改変や悪意あるコードのリスクもあります。
公式リポジトリ、モデルカード、ライセンス、更新履歴を確認してから利用してください。
Macでは購入後に統合メモリを増設できない
Apple Silicon搭載Macの統合メモリは、一般的なデスクトップPCのDIMMのように購入後の増設ができません。
現在のモデルだけでなく、将来使う可能性が高い長文処理、画像入力、RAGの分まで検討する必要があります。
最大容量を無条件に選ぶのではなく、現在必要な量に現実的な余裕を足すのが費用対効果の高い選び方です。
✅ローカルLLMと統合メモリ構造の結論
容量・量子化・KVキャッシュ・帯域を一緒に見る
統合メモリ構造は、CPUとGPUが同じ物理メモリを共有し、不要なデータコピーを減らせる仕組みです。
大容量モデルを候補にしやすい一方、搭載容量をすべてモデルへ使えるわけではありません。
重みが収まるか、KVキャッシュを確保できるか、実用速度が出るかの3段階で判断しましょう。
自分の用途に合う最小モデルから試す
文章分類や短い要約に70B級が必要とは限りません。
小型モデルで目的を満たせれば、応答速度、消費電力、必要容量のすべてを抑えられます。
まず手元の端末で小型モデルを試し、不足しているのが品質、容量、速度のどれかを確認する方法が堅実です。
ローカルLLMはモデルと推論技術の変化が速く、小型モデルの性能向上や量子化技術の改善も続いています。
統合メモリは多いほど選択肢が増えますが、最適容量は使いたいモデルと待てる生成時間によって決まります。
- モデルの実ファイル容量を確認する
- 通常使用するコンテキスト長を決める
- KVキャッシュを含むピークメモリを確認する
- 同じ条件で生成速度を比較する
- OSと普段使うアプリの余裕を残す
ローカルLLM向けのパソコンは、「最大何GBか」ではなく、「自分の用途をどのモデルで、どの速度で処理したいか」から選びましょう。