LLMのVRAM要件：2026年版マスター表（全モデル・全量子化）

LLMのVRAM要件：2026年版マスター表（全モデル・全量子化）

誰もが驚く数字があります。DeepSeek-V3.2は6710億個のパラメータを持ちますが、任意のトークン処理時に実際に使用されるのは370億個のみです。では、実際にはどれだけのVRAMが必要なのでしょうか？答えは6710億個分すべてであり、Q4量子化で約382GBです。LLMのVRAM要件は直感に反することが多く、「アクティブなパラメータ数」と「読み込む必要があるデータ量」のギャップこそが、ハードウェア予算が膨れ上がる主な原因です。このガイドでは、主要なオープンモデルすべて、各量子化レベル、必要なGB数、およびそれを動作させるGPUを示したマスター表と、わずか10秒程度で任意のモデルのサイズを見積もれる計算式を提供します。

主なポイント

• 重み所需的VRAM ≈ パラメータ数 × パラメータあたりのバイト数：FP16 = 2.0、Q8 = 1.0、Q5_K_M ≈ 0.68、Q4_K_M ≈ 0.57。これにKVキャッシュと約15〜20%のオーバーヘッドを加算します。
• Mixture-of-Experts（MoE）モデル（DeepSeek、GLM-5.2、Qwen3-235Bなど）は、すべてのエキスパートをVRAMに読み込む必要があります。「アクティブなパラメータ数」は速度向上に寄与しますが、メモリ節約にはなりません。
• KVキャッシュは見えないコストです。Llama 3.3 70Bは、8Kコンテキストで約2.6GB、128Kコンテキストで約41GBのキャッシュを必要とし、これは重みとは別に加算されます。
• Q4_K_Mは合理的なデフォルト選択肢です。FP16のフットプリントの約4分の1で、ほぼ同等の品質を実現します。
• Gemma 4のような12BモデルはQ4で8GBカードに収まります。70Bの高密度モデルには約40GBが必要です。671Bクラスの最先端MoEモデルには小規模なサーバー環境が必要です。

モデル別LLM VRAM要件：マスター表

簡潔に言えば、Q4_K_Mの場合、小規模モデル（14B未満）はコンシューマー向けの8〜12GBカードに収まり、中規模モデル（24〜32B）は16〜24GBを必要とし、70Bの高密度モデルには約40GBが必要です。最先端のMoEモデルは、すべてのエキスパートを常駐させる必要があるため、数百ギガバイト単位に跳ね上がります。以下にその全体像をまとめました。すべての数値は重みのみのメモリ容量であり、各モデルのパラメータ数から算出し、Meta AI、Qwen、およびHugging Faceの公式モデルカードと照合しています。

この表から読み取れる重要な点は2つあります。第一に、量子化は最も効果的な手段です。FP16からQ4へ落とすことで、品質低下がほとんど知覚できないまま、フットプリントを約4分の1に削減できます。第二に、MoE行の数値は過酷に見えますが、それが現実です。Qwen3-30B-A3Bはトークンごとに3Bのパラメータのみを活性化するため、小規模モデル並みの速度で動作しますが、すべてのエキスパートを準備しておくために30Bすべてをメモリに保持する必要があります。これらの数値の背景にあるモデル別の詳細を知りたい場合は、ベンチマークとライセンスについて解説しているGemma 4 12B徹底解説および2026年のベストオープンソースLLM roundupをご覧ください。

VRAM計算式：任意のモデルを自分で見積もる

任意のモデルのサイズを見積もるには、パラメータ数に量子化レベルごとの「パラメータあたりのバイト数」を掛け、KVキャッシュとランタイムオーバーヘッド分を少し加算します。それだけです。重みが支配的な要素であり、計算はメモの裏側でもできるほど単純です。

重みのための基本方程式：

VRAM_weights (GB) = parameters (billions) × bits_per_weight ÷ 8

必要な「重みあたりのビット数」（これらはGGUF k-quantファイルの有効レートであり、名目上のビット深度に加え、少量のブロックメタデータを含みます）：

具体例：Q4_K_MでのGemma 4 12Bの場合、11.95 × 4.5 ÷ 8 = 重みに対して約6.7GBとなります。これは公式モデルカードが示す約6.6GBと一致し、なぜこれが modest なコンテキスト用の余地を残して8GBカードに収まるかを説明しています。同じ計算をQ4の70Bモデルで行うと、70 × 4.5 ÷ 8 = 39.4GBとなり、これが「70Bには24GBカード2枚または48GBカード1枚が必要」という誰もが口にする経験則の理由です。

全体像にはさらに2つの項が加わります：総VRAM ≈ 重み + KVキャッシュ + 約15-20%のオーバーヘッド。オーバーヘッドは活性化バッファ、CUDAコンテキスト、メモリの断片化をカバーし、GPUはドライバー用に約0.5GBを予約するため、表記上のVRAMを100%使用できる計画を立ててはいけません。

KVキャッシュがあなたを苦しめる数字である理由

KVキャッシュは、コンテキスト内に既に存在するすべてのトークンのアテンションキーとバリューを保存し、コンテキスト長に比例して増大します。短いプロンプトでは誤差の範囲ですが、長いコンテキストになると、重み自体に匹敵するか、それを超えることもあります。これが、「収まるはず」のモデルが生成途中でメモリ不足エラーを発生させる最も一般的な原因です。

トークンあたりの計算式：

KV_cache_per_token (bytes) = num_layers × 2 × kv_dim × precision_bytes
kv_dim = num_kv_heads × head_dim   (grouped-query attention shrinks this)

Llama 3.3 70Bを例にとります。80層、8つのKVヘッド、ヘッド次元128のため、kv_dimは1024です。FP16の場合、80 × 2 × 1024 × 2 = トークンあたり327,680バイト、約0.31MBとなります。これをコンテキスト長で乗算すると状況は明白です。8Kトークンではキャッシュは約2.6GB、32Kでは約10GB、128Kでは約41GBに膨れ上がります。最後の数値は40GBの重みに加算されるため、「40GBのモデル」はウィンドウがいっぱいになった瞬間に静かに「80GBの問題」へと変貌します。

実用的な回避策は2つあります。グループドクエリアテンション（最近のモデルすべてが採用）は、従来のマルチヘッド設計と比較してkv_dimを大幅に削減するため、現代のモデルはこの点でLlama 2よりも遥かに親切です。また、ほとんどの推論エンジンはKVキャッシュを8ビットまたは4ビットに量子化でき、小さな品質コストでサイズを半分または4分の1にできます。本番環境で長いコンテキストを提供する場合、どのバックエンドがページドアテンションでこのメモリを最も効率的に管理するかについては、vLLM vs SGLang比較で解説しています。

MoEモデル：なぜ「アクティブなパラメータ」はVRAMを節約しないのか

これが人々に最も大きな出費を強いる罠です。DeepSeek-V3.2（合計671B、アクティブ37B、V3アーキテクチャを共有）やGLM-5.2（合計744B、アクティブ40B）のようなMixture-of-Expertsモデルは、各トークンをエキスパートの小さなサブセットを通じてルーティングします。マーケティングではアクティブな数値が強調されますが、それは速度を説明するためです。トークンあたり37Bパラメータ分の計算コストのみを支払うため、モデルサイズに対する推論速度は高速です。しかし、すべてのエキスパートは選択される準備ができている状態でメモリに存在しなければならず、这意味着あなたのVRAM予算はアクティブなパラメータ数ではなく、総パラメータ数によって決定されます。

したがって、上記の表の正直な解釈は次の通りです。GLM-5.2は40Bモデルの速度で動作しますが、744Bモデルのメモリを占有します。これが、単一のフォワードパスは安価であっても、これらの最先端オープンモデルに8-GPUサーバーまたは大規模な統一メモリマシンが必要な理由です。Qwen3-235B-A22Bも同様の形状で、スケールは小さめですが、トークンあたりの処理は迅速で、ホスティングは重いです。

MoEの利点は、統一メモリハードウェアで顕著になります。512GBの統一メモリを搭載したMac Studioは、Q4で671Bモデルを保持し、依然として実用的な速度で実行できます。これは、37Bのみが活性化するため、トークンあたりのメモリ帯域幅要求が合理的な範囲に収まるからです。ローカルでの実行を始めたばかりの場合は、ハードウェアへの投資前にローカルLLMセットアップガイドから始めることをお勧めします。

どの量子化を選ぶべきか？

ほぼすべての人にとって、Q4_K_Mが正しいデフォルトです。FP16のフットプリントを約4分の1に削減しながら、ほぼ完全な品質を維持します。予備のVRAMがあり、品質に敏感なタスクを行う場合にのみQ5_K_MまたはQ8にステップアップし、リファレンスとの比較やファインチューニングを行う場合のみFP16を選択してください。Q4を下回ると品質低下が急速に顕著になるため、Q3以下は genuinely に小さすぎるカードにモデルを押し込む際の最終手段です。

注意点：量子化の品質はモデルによって同一ではありません。非常に小規模なモデル（4B未満）は大規模モデルよりもQ4の影響を強く受けます。冗長性が少ないためです。70Bモデルでは、ほとんどのタスクでQ4とQ8の区別は困難です。1.7Bモデルでは、その差は明確です。

実際にはどのGPUが必要か？

マスター表のQ4列を、KVキャッシュ用の少しの余裕を持たせたカードと照合してください。以下は、予算重視のコンシューマーハードウェアからデータセンターまで、各クラスがQ4で快適に実行できるモデル tier との実用的な対応表です。

Apple Siliconは特筆すべき存在です。統一メモリにより計算式が変わるためです。MacはVRAMとシステムRAMを分割しないため、128GBのMシリーズマシンは、複数のディスクリートGPUを必要とするモデルを読み込むことができ、ピークスループットと引き換えに、巨大な重みを1台のデスクトップに収める能力を得ています。これらのカードの性能を最大限に引き出すバックエンドについては、LLMをローカルで実行するためのベストツールのroundupで、実世界での速度差をベンチマークしています。

クライアント導入におけるVRAMサイジング方法

Techsyでは、クライアント向けにオープンモデルを頻繁に導入しており、VRAMサイジングはモデル選択、プロンプト作成、その他あらゆる作業に先立つ最初の議論事項です。私たちの手法は意図的に退屈です。なぜなら、失敗モード（実際のコンテキスト負荷下での本番環境でのOOM）が高コストだからです。以下は、私たちが実際に実行しているプロセスです。

私たちは表計算から始め、その後測定します。モデルを読み込んだ後、見積もりを信頼するのではなく、実際の常駐フットプリントを確認します。

# What the GPU is actually holding
nvidia-smi --query-gpu=memory.used,memory.total --format=csv

# For an Ollama-served model, its real memory + how much sits on GPU vs CPU
ollama ps

# llama.cpp: control the split explicitly and cap context to bound KV cache
llama-server -m model-Q4_K_M.gguf --n-gpu-layers 999 --ctx-size 8192

繰り返し教訓となるのは、チームは重みのサイズを見積もるがKVキャッシュを忘れ、デモ中に長いリクエストが3つ続いた時点でモデルがクラッシュする理由を不思議に思うということです。私たちは、アプリが実際に使用する最大コンテキストにおける重みプラスKVキャッシュ、さらに余裕を加えてサイジングし、暴走したリクエストがボックスをOOMさせないように--ctx-sizeを制限します。顧客Facingのanythingについては、負荷下でOOMするFP16 70Bよりも、決して倒れない量子化32Bを実行することを好みます。

オープンモデルのセルフホストとホスト型APIの利用のどちらを検討しているかに関わらず、そのトレードオフ（ハードウェアコストと運用負担対トークン単価と制御性）は、まさに私たちのチームがAI統合エンゲージメントの中でスコープ定義するものです。実際のワークロードに対して数値を検証する必要がある場合は、無料相談にご連絡ください。一緒にサイジングを行います。

著者について

Mert Batur GurbuzはTechsy.ioの共同創業者であり、同社チームはB2Bクライアント向けにAIエージェント、自動化システム、および音声/SDRパイプラインを提供しています。彼はバーミンガム大学で学び、Techsyチームが生産環境で実際に使用しているLLMツールスタックについて執筆しています。

資格：共同創業者、Techsy.io、バーミンガム大学。LinkedInでつながる。

よくある質問

70Bモデルを実行するにはどのくらいのVRAMが必要ですか？

Llama 3.3 70Bのような70B高密度モデルは、Q4_K_Mで重みに約40GBのVRAMを必要とするため、48GBカード（RTX 6000 Ada）または24GBカード2枚を想定してください。長いコンテキストを使用する場合は、KVキャッシュ用にさらに数ギガバイトを加算する必要があり、実用的な要件は48GB以上になります。

Llama、Qwen、またはDeepSeekにはどのくらいのVRAMが必要ですか？

それはバリエーションによって完全に異なります。Llama 4 ScoutはQ4で約62GB、Qwen3-32Bは約18GB、Qwen3-8Bは5GB未満を必要とします。DeepSeek-V3.2（671B MoE）は、すべてのエキスパートを読み込む必要があるため、約382GBを必要とします。MoEモデルについては、常にアクティブなパラメータ数ではなく、総パラメータ数を確認してください。

8GB GPUでLLMを実行できますか？

はい、快適に実行できます。RTX 4060などの8GBカードは、Q4_K_Mで最大約12Bパラメータのモデルを実行できます。Gemma 4 12Bは約6.8GBに収まり、modest なコンテキスト用の余地が残ります。それより大きい場合は、より強い量子化、短いコンテキスト保持、またはより大きなカードへの移行が必要です。

RTX 4090のような24GB GPUは何を実行できますか？

24GBカードは、Q4_K_Mで最大約32Bの高密度モデルを、合理的なコンテキスト用の余裕を持って処理できるため、Qwen3-32BやMistral Small 3.2 24Bは快適に動作します。また、Qwen3-30B-A3B MoEも実行でき、これは30Bの重みを読み込みますが、スパース活性化のおかげで3Bモデルの速度で生成を行います。

量子化はモデル品質を損ないますか？

Q4_K_M以上では、品質低下は小さく、特に13B以上のモデルでは実際のタスクで知覚できないことがよくあります。量子化レベルを下げるほど、またモデルが小さくなるほどギャップは広がります。そのため、70BでのQ4はほぼ無料ですが、1.7BでのQ4は顕著です。メモリに余裕がある場合、Q8は実質的に無損失です。

MoEモデルは高密度モデルよりも少ないVRAMを必要としますか？

いいえ、これが最も一般的な誤解です。Mixture-of-ExpertsモデルはすべてのエキスパートをVRAMに保持する必要があり、そのメモリは総パラメータ数によって決定されます。アクティブパラメータ数値は推論速度のみを記述します。GLM-5.2は40Bモデルの速度で動作しますが、744Bモデルのメモリを必要とします。

統一メモリはVRAMと同じですか？

機能的には、モデル読み込みに関してはYesです。Apple Siliconおよびその他の一部のシステムは、CPUとGPU間で1つのメモリプールを共有するため、128GBのMacは、 otherwise 複数のディスクリートGPUを必要とするモデルを読み込むことができます。トレードオフは帯域幅です。統一メモリは通常、ハイエンドのデータセンターGPUよりも低いピークスループットを提供するため、トークン/秒は低くなります。

モデルの一部をシステムRAMまたはCPUにオフロードできますか？

はい。llama.cppやOllamaなどのエンジンは、--n-gpu-layersのようなフラグを使用して、一部の層をGPUに、残りをシステムRAMに保持することを可能にします。これにより、VRAMに収まらないモデルを実行できますが、CPU上の層ごとに生成速度が急激に低下するため、モデルを「可能」にするために使用し、「高速」にするためには使用しないでください。

表にないモデルのVRAMを計算するにはどうすればよいですか？

パラメータ数（十億単位）に量子化の「重みあたりのビット数」を掛け、8で割ります。Q4_K_Mの場合は約4.5ビットを使用するため、40Bモデルは40 × 4.5 ÷ 8 = 重みに対して約22.5GBを必要とします。実際の要件には、約15-20%のオーバーヘッドとKVキャッシュを加算してください。