ローカルLLMは自分のGPUで動く？必要VRAM計算ツール【2026年版】

ローカルLLMを使ってみたいと思っても、「自分のGPUでどのモデルが動くのか」「長い文章を読ませると、どれくらいVRAMが必要になるのか」は、モデル名やGPU名だけでは判断できません。

このページでは、GPUまたは統合メモリ、コンテキスト長、KVキャッシュ型を選ぶと、Llama、Qwen、DeepSeekなどの主要モデルがメモリへ収まりそうかを量子化別に概算できます。先にツールを試し、その後で判定の意味と計算方法を初心者向けから順に説明します。

このツールが判定するのはメモリ容量です。「メモリ余裕あり」は、必ず起動する、高速に生成できる、快適に使えるという保証ではありません。GPUの演算性能、メモリ帯域、実行ソフトとGPUの対応、実際の生成速度は別に確認する必要があります。

まずは3項目を選んで判定する

初めて使う場合は、次の設定から始めてください。専門用語が分からなくても、いったん判定できます。

1. NVIDIA、AMD、IntelのGPUなら「専用VRAM」を選び、自分のGPUを選択します。Apple Siliconなど、CPUとGPUが同じメモリを使う環境では「統合メモリ」を選びます。
2. コンテキスト長は、迷ったら8Kを選びます。長い資料や多くの会話履歴を扱うときだけ、16K、32Kと増やします。
3. 詳細設定のKVキャッシュ型は、最初は標準のF16のままにします。

判定後は、まず「メモリ余裕あり」と表示されたモデルを確認してください。各モデルには、メモリに収まり得る最高品質の量子化と、モデル重み・KVキャッシュ・固定余裕の内訳が表示されます。

判定結果の読み方

結果は4種類です。「動くかどうか」を断定する表示ではなく、選択した条件でメモリ容量に収まる可能性を分類しています。

結果にある「Q5_K_M」「Q4_K_M」などは、モデル本体の量子化形式です。数字が小さいほどモデル重みを軽くできますが、一般に圧縮による品質への影響は大きくなります。表示された形式のGGUFファイルが実際に配布されているかは、モデルの配布ページで確認してください。

「メモリ余裕あり」でも、CUDA、ROCm、Vulkan、Metalなどのバックエンド対応やGPU性能によって速度と安定性は変わります。このツールはGPU同士の速度比較や起動保証をするものではありません。

初心者向け：最初に知っておきたい4つの用語

GPUとVRAM

GPUは、LLMの計算を並列に処理する装置です。VRAMは、そのGPUが直接使う専用メモリです。ローカルLLMでは、モデル本体や会話処理に必要なデータの多くをVRAMへ置けるほど、GPUだけで処理しやすくなります。

ただし、同じ16GBのVRAMを持つGPUでも生成速度は同じではありません。GPUの世代、演算性能、メモリ帯域、実行ソフトの最適化が異なるためです。このツールがGPU名を使うのは容量を選びやすくするためで、速度を評価するためではありません。

メインメモリと統合メモリ

Windows PCなどで一般に「メモリ」「RAM」と呼ばれるものがメインメモリです。専用GPUのVRAMとは別の領域で、VRAMからあふれたモデルの一部を置ける場合がありますが、GPUだけで処理する場合より遅くなりやすくなります。

Apple Siliconなどの統合メモリ環境では、CPUとGPUが同じメモリ領域を共有します。ツールへ入力するのは搭載量そのものではなく、OSやほかのアプリが使う分を除いて、モデルへ割り当てられる容量です。たとえば搭載メモリが64GBでも、64GBすべてをモデルへ使えるわけではありません。

8B、14B、70Bの「B」

Bはbillion、つまり10億を表します。8Bモデルなら約80億、70Bモデルなら約700億のパラメータを持つという意味です。一般にはパラメータが多いほどモデル重みも大きくなりますが、Bの数字だけで回答品質や必要メモリのすべては決まりません。

MoEモデルの「30B-A3B」のような表記は、全体で約30Bの重みを持ち、1回の計算で約3B分を主に使うという意味です。計算量が軽くなっても、通常は全体の重みを保存する必要があるため、必要メモリが3Bモデル相当になるわけではありません。

量子化

量子化は、モデルの重みを少ないbit数で表して容量を減らす方法です。FP16からQ8、Q6、Q5、Q4、Q3へ進むほど軽くなりますが、圧縮率、速度、品質のバランスはモデルと実行環境によって変わります。

この記事では、似た名前の2種類の量子化が登場します。

• モデル本体の量子化：Q5_K_M、Q4_K_Mなど。モデル重みの容量を変える
• KVキャッシュの量子化：F16、Q8、Q4。会話履歴などを処理する作業領域の容量を変える

モデル本体がQ4_K_Mでも、KVキャッシュまで自動的にQ4になるわけではありません。この2つを分けて考えることが、判定結果を正しく読むポイントです。

コンテキスト長とは

コンテキスト長とは、LLMが1回の処理で参照できるトークン数の上限です。8Kは約8,000トークン、32Kは約32,000トークンを表します。トークンは文字数と同じではなく、日本語、英語、コードなど内容によって1文字あたりの使われ方が変わります。

コンテキストの枠には、質問文だけでなく次の情報が含まれます。

• システムプロンプト
• ユーザーの入力
• 過去の会話履歴
• 読み込ませた文書やコード
• 対応モデルへ渡した画像などをトークン化した情報
• LLMがこれから生成する回答のための余白

たとえば32Kの枠へ30K分の資料を渡すと、システムプロンプトや回答に使える残りはわずかです。コンテキスト長は「過去の会話を永久に記憶する機能」ではなく、そのリクエストでモデルへ渡す作業領域の広さと考えると分かりやすいでしょう。

コンテキスト長の目安

最初から最大値にする必要はありません。まず8K〜16Kで試し、入力が収まらないときだけ増やすほうが、VRAMをほかの処理へ残せます。

ローカルLLMの必要メモリを決める3要素

このツールでは、必要メモリを次の3つに分けています。

推定メモリ ＝ 量子化後のモデル重み ＋ KVキャッシュ ＋ 固定余裕

• モデル重み：LLM本体。モデルのパラメータ数と量子化形式で大きく変わる
• KVキャッシュ：入力や会話履歴を効率よく処理するための作業領域。コンテキスト長で増える
• 固定余裕：ランタイムや各種バッファのために、このツールが一律で加えている1.5GB

短いコンテキストではモデル重みが大部分を占めやすく、長いコンテキストではKVキャッシュの割合が大きくなることがあります。そのため、「Q4モデルのファイルがVRAMより小さいから収まる」とは限りません。

コンテキスト長を増やすとVRAMが必要になる理由

LLMは文章を生成するとき、過去のトークンを毎回最初から計算し直さないよう、Attentionの途中結果であるKeyとValueをKVキャッシュへ保存します。保存するトークンが増えるほどKVキャッシュもおおむね増えるため、同じモデルと同じ量子化でも、8Kより128Kのほうが多くのメモリを使います。

KVキャッシュの増え方はモデル構造によって異なります。パラメータ数が同じでも、Attention層数、KVヘッド数、head dimensionが異なれば、同じコンテキスト長で必要なKVキャッシュも変わります。

判定ツールの「KVキャッシュ型」とは

判定ツールにある「KVキャッシュ型」は、過去のトークンについて保存するKeyとValueを、1要素あたり何bitで保持するかを選ぶ項目です。KVキャッシュの個数を指定する項目ではありません。

Q8_0やQ4_0は、値そのものに加えてブロック単位のスケール情報を持ちます。そのため「8bitだから正確に1byte」「4bitだから正確に0.5byte」とはなりません。32要素あたりQ8_0は34byte、Q4_0は18byteとして、ツールでは1要素あたり約1.06byte／0.56byteで概算します。

たとえばF16でKVキャッシュが8GBと推定される条件なら、このツール上ではQ8が約4.24GB、Q4が約2.24GBになります。ただし、減るのはKVキャッシュ部分だけです。必要メモリ全体が同じ割合で減るわけではありません。

llama.cppでは、K・VキャッシュともF16が標準です。Q8やQ4も指定できますが、対応する型や組み合わせはバックエンド、ビルド、バージョンによって変わります。詳しくはllama.cppの公式CLIオプションを確認してください。

Q8やQ4では、環境によって速度や回答品質へ影響が出る可能性があります。迷った場合はF16を選び、メモリが足りないときだけQ8、Q4の順に比較するのが安全です。

上級者向け：このツールの判定方法

ここからは、計算の前提を確認したい人向けです。このツールの数値は実測値ではなく、GGUFを1人でテキスト生成に使う状況を想定した構造計算です。

モデル重みの計算

モデル重みは、総パラメータ数に量子化形式ごとの概算bytes/parameterを掛けています。

GGUFにはテンソルごとの形式、メタデータ、アライメントなどがあるため、実際のファイルサイズと完全には一致しません。MoEモデルもactiveパラメータ数ではなく総パラメータ数で計算します。Qwen3は公式モデルカードの8.2B、14.8B、32.8B、30.5Bを使用しています。一方、「8B」「70B」のように公式が丸めた呼称のみを示すモデルは、その呼称を概算値として使うため、購入判断では実際のGGUFファイルサイズも確認してください。

KVキャッシュの計算

KVキャッシュは、次の式で十進表記のGBへ換算しています。

KVキャッシュ ＝ 2 × Attention層数 × KVヘッド数 × head dimension × 1要素のbytes × トークン数

先頭の2はKeyとValueの2種類を表します。1Kは1,000トークンとして扱い、モデルごとの層数、KVヘッド数、head dimensionには公開設定値を使っています。

この式は、通常のTransformer構造を比較するための単純化です。Sliding Window Attention、MLA、状態空間モデル、複数ユーザー向けのKV管理など、別の仕組みを持つモデルやランタイムへそのまま適用できるとは限りません。

固定余裕と判定基準

モデル重みとKVキャッシュへ、ランタイム用の固定余裕として1.5GBを加えます。その合計を選択した容量と比較し、次のように分類します。

• 容量から10%または1GB以上残る：メモリ余裕あり
• 合計は容量以内だが、上記の余裕を下回る：メモリ上限に近い
• Q3_K_Mでも容量を超える：メモリ不足
• 選択したコンテキスト長がモデル上限を超える：モデル上限超過

固定余裕1.5GBは、あらゆる環境の使用量を保証する値ではありません。GPUドライバー、ランタイム、バッファ、画像処理、同時実行によって追加メモリが必要です。固定した誤差率では表せないため、購入判断には実際のGGUFファイルサイズと同じ環境での実測値も使ってください。

このツールで分かること・分からないこと

実際の使用量は、次の条件でも変わります。

• llama.cpp、Ollama、LM Studioなどのバージョン
• GPUへ割り当てるレイヤー数
• Flash Attentionの有無
• バッチサイズと同時実行数
• 画像・音声入力や長い回答の生成
• GPUドライバーと、ほかのアプリのVRAM使用量
• CUDA、ROCm、Vulkan、Metalなどの対応と最適化

「専用VRAMでは不足」でも動く場合がある

GGUFを利用するllama.cpp、Ollama、LM Studioなどでは、モデルの一部をメインメモリへ置くCPUオフロードを利用できます。そのため、専用VRAMだけでは不足するモデルも、十分なメインメモリがあれば起動できる場合があります。

ただし、GPUへすべて載せる場合より生成速度が落ちやすく、メインメモリの容量と帯域も必要です。ツールの「統合メモリ」はCPUオフロード量を計算する機能ではなく、モデルへ割り当て可能な共有メモリ容量との比較です。専用VRAMからどれだけメインメモリへ逃がせるか、どの程度遅くなるかは、実際のオフロード設定で確認してください。

対応モデルと公式仕様

ツールには、公開されたTransformer構造からKVキャッシュを比較的単純に計算できる次のモデルを収録しています。

• Llama 3.1 8B、Llama 3.3 70B
• Qwen3 8B、14B、32B、30B-A3B
• Qwen3-Coder 30B-A3B
• Mistral Small 3 24B
• DeepSeek-R1 Distill 14B、32B、70B

主な構造とコンテキスト長は、次の公式資料で確認しています。

• Meta Llama公式モデル一覧：Llama 3.1と3.3は128Kコンテキスト
• Qwen3 8B公式モデルカード：総パラメータ8.2B、ネイティブ32,768、YaRN利用時は最大131,072トークン。標準configは40,960
• Qwen3 14B公式モデルカード：総パラメータ14.8B、40層、KVヘッド8
• Qwen3 32B公式モデルカード：総パラメータ32.8B、64層、KVヘッド8
• Qwen3 30B-A3B公式モデルカード：総パラメータ30.5B、アクティブ3.3B
• Qwen3-Coder 30B-A3B公式モデルカード：ネイティブ256K、48層、KVヘッド4
• Mistral Small 3公式設定：32K、40層、KVヘッド8
• DeepSeek-R1-Distill-Qwen-32B公式モデルカード：蒸留モデルとベースモデルの対応関係

Qwen3の通常モデルは、入力と出力を合わせたネイティブコンテキストが32,768トークンです。公式configの40,960は、公式説明では典型的な入力8,192トークンと出力32,768トークンのために確保された総系列長であり、「入力だけで40Kまで拡張設定なし」という意味ではありません。本ツールのスライダーは入力・履歴・出力予約を含むコンテキスト全体として扱うため、32Kを超えた場合にYaRNなどの拡張設定と対応ランタイムの確認を促します。

2026年のローカルLLMおすすめランキングで扱うモデルは構造や配布形式が大きく異なります。Qwen3.6はGated DeltaNetとGated Attention、Gemma 4はSliding Window AttentionとFull Attentionを組み合わせ、gpt-oss-20bはSliding Window AttentionとFull Attentionにattention sinkを使います。また、MXFP4・NVFP4などGGUF以外の配布形式もあります。同じ単純式へ当てはめると誤差が増えるため、このツールには含めていません。

判定後に実機で確認する手順

ツールの結果は候補を絞るために使い、最後は実際の環境で確認します。

1. 「メモリ余裕あり」のモデルから、表示された量子化形式のGGUFが配布されているか確認します。
2. GGUFのファイルサイズがツールのモデル重み概算から大きく外れていないか確認します。
3. ツールと同じコンテキスト長、同じKVキャッシュ型で起動します。KV型を変更していない場合はF16を使います。
4. ほかの重いアプリを閉じ、実際のVRAMまたは統合メモリ使用量を確認します。
5. 短い入力から始め、長い入力、生成速度、回答品質、安定性を順番に試します。

「メモリ上限に近い」場合は、コンテキスト長を下げる、モデル本体を一段軽い量子化へ変える、ブラウザやゲームを終了する、KVキャッシュの低bit化を対応確認後に試す、という順で余裕を増やせます。

よくある質問

VRAMが多ければ必ず速くなりますか

いいえ。VRAM容量は大きなモデルを載せるために重要ですが、生成速度にはGPUの演算性能、メモリ帯域、バックエンド、モデル構造も影響します。容量が同じGPUでも速度は異なります。

16GBのメインメモリは16GBのVRAMと同じですか

同じではありません。専用VRAMはGPUが直接使う高速なメモリです。メインメモリへオフロードして起動できる場合はありますが、専用VRAMへすべて載せる場合より遅くなりやすくなります。

モデル本体がQ4ならKVキャッシュもQ4ですか

いいえ。モデル本体の量子化とKVキャッシュ型は別設定です。モデル本体がQ4_K_Mでも、KVキャッシュは標準のF16で動いている場合があります。

最大コンテキスト長を選べば性能を引き出せますか

必ずしもそうではありません。コンテキスト長は入力できる情報量の上限であり、回答の賢さを直接上げる設定ではありません。不要に長くするとメモリ使用量が増えるため、実際に必要な長さから始めてください。

まとめ

ローカルLLMがメモリへ収まるかは、モデルのB数やGGUFのファイルサイズだけでは決まりません。次の順で考えると整理しやすくなります。

1. GPUの専用VRAMか、モデルへ割り当て可能な統合メモリを確認する
2. 必要なコンテキスト長を8K〜16Kから選ぶ
3. モデル本体の量子化とKVキャッシュ型を分けて考える
4. 「メモリ余裕あり」の候補を、同じ設定で実測する

このツールは、モデル重み、KVキャッシュ、固定余裕を合計し、メモリへ収まる可能性を比較するためのものです。速度、起動可否、回答品質を保証するものではないため、最終判断は配布ファイルの仕様と実機テストを組み合わせてください。

モデルの特徴や用途まで含めて選びたい場合は、ローカルLLMおすすめランキングと必要スペック比較も参考にしてください。

あわせて読みたい

• ローカルLLMとAPIはどちらが安いか？損益分岐点シミュレーター【2026年8月版】
• ローカルLLM向けGPUおすすめランキング｜VRAM別・モデル規模別に選ぶ【2026年8月版】