ローカルLLM用のGPU選びは、使いたいモデルの規模、用途、手元のPC環境の3つを照合するところから始まります！
GPUは必須とは限らず、CPUとメインメモリ（システムRAM）だけでも動く場合があります。
GPUを使う主な理由は、計算を速くして待ち時間を減らすことです。
短い要約や対話なら小さいモデルから試せますが、長い文書では作業メモリが増えやすく、許容できる待ち時間によっても必要な性能が変わります。
必要メモリ試算ツール
パラメータ数・量子化・VRAMなどから、必要メモリの目安と専用VRAMに収まりそうかを判定するツールを作ってみました。
判定は次の3段階です。
- GPUに収まる目安: 必要量が専用VRAMの容量（の9割）に収まる
- 一部をメインメモリへ回す目安: 専用VRAM（の9割）とメインメモリ（の6割）の合計に収まる。部分オフロードなら載る可能性がありますが、全層をGPUに載せるより遅くなりえます
- この条件では厳しい目安: それを超える場合
9割・6割は仮の値です（詳しくは末尾の「試算ツールの前提と更新方針」）。
統合メモリ（Apple Silicon）では判定せず、必要量と容量を並べて表示します。
たとえばVRAM 12GB・メインメモリ32GBで8B・Q4_K_Mを試すなら、まず「（KVキャッシュを除く）」の結果を見て、詳細設定で層数などを足すとコンテキスト分が加わります。
VRAM・RAM・モデルファイルサイズを分けて考える
「ファイルサイズが15GBなら、16GBのメモリで動くはず」と考えたくなりますよね。
でも、そう単純ではないんです。
専用VRAMとメインメモリ（統合メモリを含む）
独立したGPUを搭載したPCには、GPUカード上の専用VRAMと、マザーボード上のメインメモリ（システムRAM）があります。
タスクマネージャーの「共有GPUメモリ」は、GPUが必要に応じて使うシステムメモリの一部で、VRAMではありません。
速いのはモデルを専用VRAMに置く方法です。
足りなくても、一部をVRAMに、残りをメインメモリに割り当てる部分オフロードに対応した処理系（llama.cppなど）があります。
ただ、メインメモリに頼る割合が増えると、速度や起動の可否は環境や設定に大きく左右されます。
Apple SiliconのMacは、CPUとGPUが同じメモリを共有する統合メモリなので、専用VRAMと同列には比べられません。
OSや他のアプリも使うため、全量をLLMに割り当てられるわけでもありません。
ファイルサイズ・量子化と実行時メモリ
実行時には重みに加えて、入力や対話の計算状態を保持する作業領域も必要です。
その一つが、計算済みのKeyとValueを再利用するためのKVキャッシュです。
コンテキスト長を長くするほどメモリ消費は増える傾向ですが、増え方はモデルの構造、アテンションの保持方式、ツールの実装で異なります。
モデルを圧縮して軽量化する量子化も広く使われています。
メモリを抑えられる一方、圧縮の度合いによっては出力品質に影響する場合があります。
「ファイルサイズが収まるか」だけで判断せず、コンテキスト長や実行時の設定も含めて検討しましょう。
ただし「4bit量子化」でも、1パラメータあたりのデータ量がちょうど4ビットになるわけではありません。
llama.cppの量子化ツールの説明には、Llama 3.1 8Bでのbits/weight（1重みあたりの平均ビット数。以下、実効ビット数）として、Q4_K_Mが4.8944、IQ4_XSが4.4597、Q8_0が8.5008と示されています。
次の表は、AIがLM StudioのローカルAPIから取得した、表示パラメータ「27B」・量子化4ビットの2モデルです。
| モデル（識別名） | 量子化 | 実ファイル | 名目4bitの計算 | 実効ビット数の計算 |
|---|---|---|---|---|
| unsloth/qwen3.8-27b | IQ4_XS | 約15.18 GB | 13.5 GB | 約15.05 GB |
| qwen/qwen3.8-27b | Q4_K_M | 約17.74 GB | 13.5 GB | 約16.52 GB |
名目どおり「27B × 4 ÷ 8」で計算した13.5 GBは、どちらの実ファイルとも開きがあります。
実効ビット数で計算すると、IQ4_XSは実ファイルとの差が約1%、Q4_K_Mは実ファイルより約7%小さくなりました。
表示パラメータ数の丸めも一因かもしれませんが、原因は特定できていません。
試算ツールが実効ビット数を使うのは、このためなんです。
手元PCのスペックを確認する判断表
| 順 | 確認項目 | 内容 | 確認場所 |
|---|---|---|---|
| 1 | OS・実行環境 | 命令セット（AVX2等）、OSバージョン | システム情報 |
| 2 | メモリ量 | メインメモリと専用VRAM（Macはシステムメモリ） | タスクマネージャー、アクティビティモニタ |
| 3 | モデル規模と量子化 | パラメータ数、量子化形式（4/8ビットなど）、ファイルサイズ | ダウンロード画面 |
| 4 | コンテキスト長 | トークン数の上限（4,096、32,768など） | ロード設定 |
| 5 | オフロード | 全層をGPUか、CPU・メインメモリへ分散か | オフロード比率 |
LM Studioの動作要件は、Windows（x64）がAVX2対応CPU必須、メモリ16GB以上・専用VRAM 4GB以上推奨、macOSがApple SiliconとmacOS 14以降、メモリ16GB以上推奨です（8GBは小さめのモデルと控えめなコンテキスト長が条件）。
推奨値はアプリ自体の目安で、中規模以上のモデルの使用量や速度までは保証しません。
自分のVRAM容量を確認する
Windowsでは、タスクマネージャーで「パフォーマンス」を開いてGPUを選ぶと、「専用GPUメモリ」と「共有GPUメモリ」が表示されます。
独立GPU（グラフィックボード）なら、試算ツールに入れるのは専用GPUメモリの容量（最大値）です。
GPUが複数あるときは、使う独立GPUを選んでください。
Macでは、アクティビティモニタの「メモリ」タブ下部にある「物理メモリ」（搭載RAM容量）を、統合メモリの欄に入れます。
LM Studioの見積もりを2条件で確認した例
LM StudioのCLIの --estimate-only は、モデルをロードせずに推定値だけを出力します。
2026年10月5日、AI（Codex）がWindows上のLM Studio（アプリ 0.4.23.0、CLI commit 07b7252）を使い、ローカルAPI上で「unsloth/qwen3.8-27b」（表示パラメータ約270億、IQ4_XS、表示ファイルサイズ約15.18 GB）と識別されるモデルの見積もりを確認しました。
モデルの出自・真正性・品質は未検証で、推薦の意図もありません。
GPUオフロードは全層を割り当てる max、コンテキスト長は「4,096」と「32,768」の2条件です。
# 条件1: コンテキスト長 4,096
$ lms load unsloth/qwen3.8-27b --estimate-only --context-length 4096 --gpu max
Estimated GPU Memory: 14.14 GiB
Estimated Total Memory: 14.14 GiB
Confidence: LOW
# 条件2: コンテキスト長 32,768
$ lms load unsloth/qwen3.8-27b --estimate-only --context-length 32768 --gpu max
Estimated GPU Memory: 14.14 GiB
Estimated Total Memory: 14.14 GiB
Confidence: LOW
推定メモリ値は、どちらの条件でも「14.14 GiB」（信頼度表示: LOW）でした。
ドキュメントではコンテキスト長も推定に反映されるとされていますが、今回は変わりませんでした。
見積もりが同値でも、実際の推論時にメモリ使用量が変わらないとは判断できません。
この値は、表示ファイルサイズ15,180,457,232 bytesのGiB換算（約14.14 GiB）と一致しましたが、理由やLM Studio内部の計算方法は分かっていません。
「GiB」は1,024の3乗バイト、SI接頭辞の「GB」は1,000の3乗バイトですが、メモリやVRAMの容量表記では1,024の3乗バイトを「GB」と書く慣習もあります。
一方、試算ツールに同じファイルサイズを入れると、KVキャッシュなしで約16.2 GB（重み15.18 GB＋余白1.0 GB）です。
層数などの3つも入れればKVキャッシュが加わり、4,096と32,768で値が変わります。
この検証は推定値の表示のみで、ロード・推論や、実際の使用量・速度の測定はしておらず、どの数値も起動や速度を担保しません。
推定だけで決められないときの選択肢
買い替える前に、試せる見直しもあります！
まずは、量子化形式やファイル容量の異なる候補で、用途に足りる出力精度が得られるか試す方法です。
小さなモデルなら、VRAMが限られていてもロードしやすくなります（試算ツールの「量子化」「パラメータ数」の欄）。
コンテキスト長を必要最小限にすれば、メモリ確保量を抑えられる可能性があります（同「コンテキスト長」の欄）。
ただし入力を分割して減らしても、確保済みのキャッシュ領域が自動で解放されるとは限らず、実際の使用量は環境ごとに確認が必要です。
入力の整理にはこちらも参考になります。
LM Studioなどでは、モデルの一部だけをGPUに、残りをCPUとメインメモリで処理させるオフロード設定も可能です。
対応する実行系と十分なシステムメモリがあれば、判定が「一部をメインメモリへ回す目安」のときの回避策になり得ます。
起動や速度は手元で確認してください。
個人情報や機密データを扱うなら、入力のルールも先に決めておきましょう（考え方はこちら）。
試算ツールの前提と更新方針
必要量は「重み＋KVキャッシュ＋余白」の合計です。
重みは「パラメータ数 × 実効ビット数 ÷ 8」で推定し、ファイルサイズを入れればその値を優先します。
実効ビット数は、llama.cppの説明にあるLlama 3.1 8Bでのbits/weightです（確認日 2026-10-16）。
27Bの例のように、別のモデルでは実ファイルとずれることがあります。
KVキャッシュは「2 × 層数 × KVヘッド数 × ヘッド次元 × コンテキスト長 × 要素バイト数」で計算します。
この式は、同時に処理する系列（リクエスト）を1つとし、すべての層がコンテキスト全体のKVを保持する標準的な構造を前提にしています。
一部の層だけが長い範囲を参照する構造では、実際より大きく出ることがあります。
層数・KVヘッド数・ヘッド次元（config.jsonなどの値）がそろったときだけ加算します。
未入力なら「（KVキャッシュを除く）」の値になり、コンテキスト長を変えても必要量は変わりません。
パラメータ数・ファイルサイズ・VRAMなどが0以下、構造値が1以上の整数でない、余白が負の値といった入力ではエラーになり、判定しません。
ファイルサイズ入力時は、「GPUに収まるパラメータ数の目安」は表示しません。
実効ビット数は量子化表、KVキャッシュの式はNVIDIAの解説、動作要件はLM Studioのページで確認できます。
判定の境界（専用VRAMの90%、専用VRAMの90%＋メインメモリの60%）と、ツールやドライバ分の余白1.0 GB（変更可）は仮の値で、根拠が得られたら見直します。
VRAM・メインメモリ・統合メモリの「GB」は1,024の3乗バイトとみなし、10億バイト単位のファイルサイズと比べています。
試算ツールの誤りに気づいたら、お問い合わせからご連絡ください。
導入操作はLM Studioの入門ガイドへ
- 手元のPC環境のVRAM容量・メモリ・OS条件を記録する
- この記事の試算ツールとLM Studioの見積もりで概算を確認する
- 必要に応じてパラメータ数・量子化・コンテキスト長を見直す
- 実際の環境でモデルをロードし、出力精度や処理速度（待ち時間）をテストする
導入手順はこちらのガイドで紹介しています。
まずは小さめのモデルから試してみてください！
