ローカルLLMに​必要な​GPUと​VRAM｜モデル別早見表

「70Bの​モデルには​GPUが​何枚必要か」と​いう​問いは、​実は​答えられない。​必要な​VRAMは​モデルの​パラメータ数だけでは​決まらないからだ。

必要VRAMはモデルの重み・KVキャッシュ・オーバーヘッドの3つの合計である。​このうち見積もりを​外す原因は​ほぼKVキャッシュ側に​あり、​しかも​それは​モデルではなく使い方（コンテキスト長と​同時実行数）で​決まる。​同じ​モデルでも、​社内文書の​要約に​使うか100万トークンの​長文脈で​使うかで、​必要な​GPU枚数は​数倍変わる。

本記事は​ローカルLLMの​調達判断に​必要な​VRAM見積もりの​手順を、​計算式・モデル別早見表・単一ノードの​限界と​いう​順で​整理する。​モデル​その​ものの​選定はローカルLLM比較2026｜オープンウェイトモデルの​選び方を​参照して​ほしい。

この​​記事の​​対象読者

• オンプレでの​LLM運用を​検討し、​GPU調達の​見積もりを​作る​必要が​ある​インフラ担当者
• 「H100を​何枚買えば​いいのか」を​経営層に​説明する​必要が​ある​AX推進責任者
• クラウドGPUの​インスタンスサイズを​決めかねている​プラットフォームエンジニア
• PoCでは​動いたが​本番の​同時実行数で​VRAMが​足りなくなった​経験の​ある​方

必要VRAMは​​3つの​​合計で​​決まる

拡大 ⤢

重みは​公表値から​機械的に​出る。​問題は​残り​2つで、特にKVキャッシュは「モデルのスペック」ではなく「業務の使い方」の関数である。​調達見積もりが​外れるのは​ほぼ​ここである。

1. 重み — 総パラメータ×精度

重みに​必要な​VRAMは、​総パラメータ数に​精度​あたりの​バイト数を​掛けるだけで​概算できる。

300億パラメータ（30B）のモデルはFP8で約30GB、と​いう​対応を​覚えておくと​現場の​暗算が​速くなる。

MoEは​​「アクティブ」ではなく​​「総パラメータ」で​​見積もる

ここが​最も​多い​間違いである。

2026年の​オープンウェイトモデルの​多くは​MoE​（Mixture of Experts）​構成で、​モデルカードには​「総2.4兆パラメータ、​うち950億が​アクティブ」と​いった​書き方を​される。​この​「アクティブ」は1トークンを生成するときに計算に使われるパラメータ数であり、​演算量と​レイテンシの​話である。

一方で​VRAMは​違う。どのエキスパートが選ばれるかは入力によって変わるため、全エキスパートの重みをVRAM上に常駐させなければならない。つまり:

• 演算量・レイテンシ → アクティブパラメータで​見る
• 必要VRAM → 総パラメータで見る

Mistral-Small-4-119B-2603は​アクティブが​65億​（128エキスパート中​4つが​活性）だが、​必要VRAMは​1,190億パラメータ分、​FP8で​約119GBである。​「アクティブ6.5Bだから​小型GPUで​動く」と​読むと、​調達を​1桁間違える。

MoEは​「速いが​軽くはない」。​この​理解が​調達の​前提に​なる。

2. KVキャッシュ — 長文脈では​​重みを​​超える

生成の​途中経過​（各トークンの​Keyと​Value）を​保持する​領域が​KVキャッシュである。​これは​トークンが​増える​ほど​線形に​増える。

概算式は​次の​とおり。

KVキャッシュ = 2（KとV） × 層数 × KVヘッド数 × ヘッド次元
               × コンテキスト長 × 精度バイト数 × 同時実行数

具体例で​​桁感を​​掴む

仮に、​層数48・KVヘッド8・ヘッド次元128と​いう​GQA構成の​30Bモデルを、​FP8の​KVキャッシュで​動かすと​する​（実際の​値は​モデルごとに​異なる​ため、​あくまで​桁感を​掴むための​仮定である）。

1トークンあたり: 2 × 48 × 8 × 128 × 1バイト = 約98KB

重みが30GBのモデルで、100万トークンの文脈を1本張るとKVキャッシュだけで約98GBに​なる。​重みの​3倍以上である。

ここから​2つの​実務的な​結論が​出る。

「1M対応」と「1Mを業務で常用できる」は別物である。 モデルカードの​コンテキスト長は​上限値であり、​その​長さを​同時に​何本張れるかは​手元の​VRAMが​決める。​100万トークンを​謳う​モデルでも、​48GBの​GPU1枚では​実際には​数万トークンの​運用しか​できない。

同時実行数の設計がGPU枚数を決める。 社内向けチャットで​同時20人が​使う​想定なら、​KVキャッシュは​20本分を​見込む。​PoCで​1人が​動かして​足りた​VRAMは、​本番では​足りない。

削る​手段

• KVキャッシュの量子化（FP8/INT8）で​およそ​半減〜4分の​1に​なる。​多くの​推論基盤が​対応している
• GQA / MLA構成のモデルを選ぶ。​KVヘッド数が​少ない​ほど​キャッシュは​小さい。​同じ​パラメータ数でも​モデル構造で​KVキャッシュは​数倍変わる
• コンテキスト長の上限を業務要件に合わせて絞る。​推論基盤側で​最大長を​制限すれば、​その​分だけ確保領域が​減る

3. オーバーヘッド

アクティベーション、​CUDAグラフ、​メモリ断片化、​推論基盤自体の​使用分が​加わる。重みとKVキャッシュの合計に対して1〜2割を​上乗せして​見積もるのが​実務的な​目安である。

VRAMを​使い切る​構成は​避ける。​断片化で​確保に​失敗し、​ピーク時にだけ落ちる​障害は​原因追跡が​難しい。

モデル別VRAM早見表​（2026年8月時点）

重みのみの​概算である。KVキャッシュとオーバーヘッドは別途加算すること。 パラメータ数は​各モデルの​公式モデルカードで​確認した​値を​用いている。

配布フォーマットが低精度の場合、実効VRAMは表より小さくなる。 実例と​して​ gpt-oss-120b は​MoEの​重みが​MXFP4で​後訓練されており、​公式モデルカードは80GB GPU 1枚（H100やMI300X）で動作すると​明記している。​総パラメータ117Bから​機械的に​計算した​FP8の​117GBではなく、​実質は​INT4列に​近い値に​なる。導入前に必ずモデルカードの配布形式を確認すること。 表の​FP8列は​「配布形式が​不明な​場合の​上限見積もり」と​して​読む。

単一ノードの​​限界

拡大 ⤢

GPUを​何枚束ねられるかには​物理的な​上限が​ある。​8基構成の​HGXプラットフォームの​搭載VRAMは​次の​とおり。

HGX B200の​総メモリ1.4TB、​HGX B300の​総メモリ2.1TBは​NVIDIAの​公表値である。

ここから​読み取れる​ことは​明確だ。Kimi K3（2.8T）とQwen3.8-2.4T（2.4T）は、2026年8月時点で最大構成のHGX B300（2.1TB）にも単一ノードでは収まらない。 複数ノードに​またがる​テンソル並列・パイプライン並列が​必要に​なり、​ノード間インターコネクトの​設計が​そのまま​推論性能を​左右する​領域に​入る。​これは​自社オンプレの​検討ではなく、​データセンター事業の​設計である。

フラッグシップ級はAPIまたはマネージド推論で使い、自社に建てるのは30B〜120B級。​これが​2026年8月時点の​現実的な​切り分けである。

構成パターン3つ

実務で​組まれる​構成は​おおむね​3つに​収束する。

パターンA：GPU 1枚​（27〜33B級）

• 構成: RTX 6000 Ada​（48GB）または​H100​（80GB）​1枚
• できること: 要約・分類・抽出・​一次回答・社内文書検索の​生成部​分
• 向く規模: 同時実行数が​一桁、​コンテキストが​数万トークンまで
• 調達感: GPU単体で​数千〜2万ドル台​（2026年8月時点の​参考値。​実勢価格は​需給で​大きく​振れる​ため、​必ず​個別に​見積もりを​取る​こと）。​サーバ・​冷却・電源を​含めると​1.5倍程度を​見込む

多くの​社内ユースケースは​ここで​足りる。まずこの構成で業務が回るかを検証してから上を検討するのが​失敗の​少ない​順序である。

パターンB：H100〜H200 1〜2枚​（120B級）

• 構成: H100​（80GB）〜H200​（141GB）​1〜2枚
• できること: パターンAで​精度が​届かなかった​業務、​複雑な​指示追従
• 注意: MoEモデルは​総パラメータで​載るかを​確認する。​ただし配布形式が​低精度なら​要件は​下がる​（gpt-oss-120bは​80GB 1枚で​動く）

パターンC：HGX 8基​（300B〜750B級）

• 構成: HGX H200​（1,128GB）​等
• できること: 自社で​持てる​最上位。​ただし投資は​桁が​変わる
• 判断: この​規模を​自社で​持つ理由は、​ほぼ​「データを​外に​出せない」​制約に​限られる。​コスト最適化が​目的なら​クラウドAPIや​マネージド推論の​ほうが​安い

よく​​ある​​見積もりの​​間違い

1. MoEのアクティブパラメータでVRAMを見積もる。 前述の​とおり全エ​キスパートが​常駐する。​総パラメータで​見る。

2. コンテキスト長の上限値で常用できると考える。 100万トークン対応は​上限であって​定員ではない。​同時実行数と​掛けた​実効値で​設計する。

3. PoCの実測をそのまま本番に持ち込む。 1人で​動かした​ときの​VRAM使用量に​同時実行数を​掛ける。​KVキャッシュは​同時実行数に​比例する。

4. 量子化を前提に調達し、精度検証を後回しにする。 INT4で​重みは​半分に​なるが、​業務に​よっては​精度低下が​許容できない。量子化前提の構成を組むなら、自社の評価セットで量子化版を先に測る。

5. VRAMを使い切る構成にする。 断片化と​ピーク時の​確保失敗を​招く。​1〜2割の​余裕を​持たせる。

FAQ

Q1. 70Bモデルには​​GPUが​​何枚必要か？

コンテキスト長と同時実行数を決めないと答えは出ない。 重みだけなら​FP8で​約70GB、​H100​（80GB）​1枚に​載る。​ただし同時実行8本・​12万トークンの​運用なら​KVキャッシュが​数十GB乗る​ため1枚では​足りない。​まず​「何トークンの​文脈を、​同時に​何本」を​決めてから​計算する。

Q2. MoEモデルは​​アクティブパラメータが​​小さいのに、​​なぜVRAMは​​総パラメータ分必要なのか？

どの​エキスパートが​選ばれるかは​入力トークンごとに​変わる​ため、​事前に​絞り込めないからである。​全エ​キスパートの​重みを​VRAM上に​置いておく​必要が​ある。​アクティブパラメータが​効くのは​演算量と​レイテンシであって、​メモリ容量ではない。

Q3. 量子化すれば​​どこまで​​小さく​​できるか？

FP8で​半分、​INT4で​さらに​半分が​目安である。​ただし精度は​業務に​よって​落ち方が​違う。​要約・分類のような​課題は​比較的耐えるが、​数値の​正確性や​長い​指示追従が​求められる​業務では​劣化が​出やすい。自社の評価セットで量子化版と非量子化版を比較してから決める。

Q4. KVキャッシュを​​減らす一番​​効果的な​​方​法は？

コンテキスト長の上限を業務要件に合わせて絞ることである。​推論基盤側で​最大長を​制限すれば​確保領域が​そのまま​減る。​次に​効くのが​KVキャッシュの​量子化で、​多くの​推論基盤が​対応している。​モデル選定の​段階なら、​KVヘッド数の​少ない​GQA/MLA構成の​モデルを​選ぶのも​有効である。

Q5. コンシューマ向けGPU​（RTX 4090など）を​​業務で​​使って​​よいか？

技術的には​動くが、​業務利用では​ライセンスと​運用の​両面を​確認する​必要が​ある。​データセンターでの​利用条件、​ECC非対応、​連続稼働時の​熱設計、​保守体制が​業務要件を​満たすかを​見る。検証はコンシューマGPU、本番はデータセンター向けと​いう​切り​分けが​実務的である。

Q6. クラウドGPUと​​オンプレは​​どちらが​​安いか？

稼働率で​決まる。​24時間365日フル稼働なら​オンプレが​有利に​なりやすく、​日中のみ​・断続利用なら​クラウドが​有利である。​詳細な​試算はローカルLLM比較2026の​TCO試算を​参照して​ほしい。なおコスト削減だけが目的なら、そもそもクラウドAPIのほうが安いケースが多い。 オンプレを​選ぶ理由は​通常データガバナンス側に​ある。

Q7. 見積もりは​​どこから​​始めれば​​よいか？

順序は​「業務要件 → コンテキスト長と​同時実行数 → モデル候補 → VRAM計算 → GPU構成」である。モデルから入らない。 使い方が​決まらないと​VRAMは​決まらず、​VRAMが​決まらないと​GPUは​決まらない。

次に​​読むべき記事

• ローカルLLM比較2026｜オープンウェイトモデルの​選び方 — モデル​その​ものの​選定基準と​ライセンス
• オープンウェイトモデルとは？​定義と​ライセンスの​読み方 — 商用利用​可否の​判断
• LLMトークン節約5パターン｜本番運用で​コストを​70%削る​ハーネス設計 — 運用コスト側の​設計
• AIガバナンスと​実装セキュリティ｜6つの​制御点 — オンプレ化の​動機に​なる​ガバナンス要件

まとめ

• 必要VRAMは​「重み＋KVキャッシュ＋オーバーヘッド」の​合計で​決まる。​見積もりを​外す原因は​ほぼKVキャッシュ側に​ある
• 重みは​総パラメータ×精度バイト数。​FP8なら​30Bで​約30GBと​いう​対応を​押さえる
• MoEは総パラメータで見積もる。 アクティブパラメータは​演算量の​話であり、​全エ​キスパートが​VRAMに​常駐する
• KVキャッシュは​コンテキスト長と​同時実行数に​比例する。​30Bモデルでも​100万トークンを​1本張れば​約98GBに​達し、​重みを​超える
• 「1M対応」は​上限であって​定員ではない。​同時実行数と​掛けた​実効値で​設計する
• 2026年8月時点で​1T超の​フラッグシップは​最大構成の​HGX B300​（2.1TB）にも​収まらない。​自社で​建てるのは​30B〜120B級、​フラッグシップは​APIで​使う
• 見積もりは​業務要件から​始める。​モデルから​入らない

FDXの​​ローカルLLM導入支援

FDXは​AX​（AI Transformation）の​実装パートナーと​して、​業務要件の​分解と​AI適用範囲の​見極めを​支援している。​オンプレLLMに​ついては​「そも​そも​自社で​持つべきか」の​判断と、​業務要件から​必要な​構成要件を​整理する​ところまでが​対応領域である。​GPU​その​ものの​調達や​データセンター設計は​扱わない。

「オンプレで​LLMを​持つべきか」の​判断自体から​迷っている​場合は、​まず業務を​分解して​適用範囲を​見極める​ところから​着手するのが​早い。AX診断では、​どの​業務に​どの​構成が​要るのかを​整理した上で​投資判断の​材料を​作る。

出典・参考文献

モデルの​パラメータ数は​各モデルの​公式モデルカードで​確認した値である​（2026年8月26日確認）。

• Moonshot AI​「Kimi-K3 Model Card」
• Alibaba​「Qwen3.8-2.4T-A95B / Qwen3.8-27B Model Card」
• DeepSeek AI​「DeepSeek-V4-Pro-0813 / DeepSeek-V4-Flash-0731 Model Card」
• Z.ai​「GLM-5.2 Model Card」
• Mistral AI​「Mistral-Small-4-119B-2603 Model Card」
• OpenAI​「gpt-oss-120b Model Card」
• Google​「gemma-4-31B-it Model Card」
• Meta​「Muse-Glimmer-30B Model Card」
• 国立情報学研究所​「llm-jp-4-33b-thinking Model Card」
• Preferred Networks​「plamo-3-nict-31b-base Model Card」
• NVIDIA​「HGX Platform 製品ページ​（HGX B200 総メモリ1.4TB / HGX B300 総メモリ2.1TB）」