LLM量子化モデルの実行に必要なVRAM容量の計算手法とGPU選定基準

LLM実行に必要なVRAM容量の完全計算ガイド:70Bモデルを動かすGPU選定の数学的証明

約17分で読めます
文字サイズ:
LLM実行に必要なVRAM容量の完全計算ガイド:70Bモデルを動かすGPU選定の数学的証明
目次

この記事の要点

  • LLM量子化モデルのVRAM所要量を正確に計算する手法
  • パラメータ数、量子化ビット数、KVキャッシュがVRAMに与える影響
  • ローカルLLM実行に最適なGPUを選定するための具体的な基準

導入

「GPUの専用メモリ(VRAM)を32GB搭載する最新のRTX 5090を複数枚導入したにもかかわらず、Llama 3.3やLlama 4で長い文章を処理しようとすると、メモリ不足による強制終了(OOM:Out of Memory)が発生してしまいます。なぜでしょうか?」

生成AI、特に大規模言語モデル(LLM)を自社環境で構築する際、最も重要でありながら失敗しやすいのがGPUの選定とVRAM容量の正確な見積もりです。

クラウド全盛の時代にあっても、機密データの保護や、回答速度(レイテンシ)の最小化、そして長期的な運用コスト削減の観点から、自社専用の環境(オンプレミスやプライベートクラウド)でのLLM運用を選択するケースは増え続けています。しかし、そこには常に「物理的なメモリ容量の壁」という厳しい制約が存在します。

かつては「70B(700億パラメータ)のモデルだから、70GBのVRAMがあれば動くだろう」といった、パラメータ数のみに依存した大まかな見積もりでハードウェアを選定し、結果的にシステムが稼働しないというケースが実務の現場でもよく見受けられました。さらに現在では、Llama 3.3が12万8000トークン、最新のLlama 4に至っては最大1,000万トークンという極めて長い文章(コンテキスト)に対応し、複数の専門家モデルを組み合わせる仕組み(MoE:Mixture of Experts)を採用するなど、モデルの構造自体が高度化かつ複雑化しています。

また、ハードウェア環境も大きく変化しています。これまで主流だったRTX 4090から、より高速なメモリと大容量VRAMを搭載するRTX 50シリーズへと世代交代が進んでいます。データをより小さく表現する新しい計算形式(FP8やNVFP4など)により、VRAM消費を大幅に削減する技術も登場していますが、計算の前提条件は以前よりも複雑になっています。こうした技術進化の過渡期において、メモリ不足を恐れるあまり過剰なスペックのデータセンター向けGPUを提案し、コスト面で却下されるという課題も珍しくありません。

AIシステム最適化の観点から言えば、VRAM容量は決して「推測」するものではなく、厳密に「計算」するべきものです。モデルの構造、データを圧縮する手法(量子化)、入力する文章の長さ、そして同時に処理する数(バッチサイズ)。これらの変数を数式に正しく当てはめれば、最新のハードウェア環境であっても必要なVRAM容量は1GB単位で論理的に予測できます。

本記事では、曖昧な経験則を排し、理論と最新の技術仕様に基づいた「失敗しないVRAM計算ロジック」を分かりやすく解説します。これは、システム設計において自信を持って最適な構成を導き出し、投資の妥当性を論理的に説明するための確固たる根拠となるはずです。

GPU投資の失敗を防ぐ「成功指標」の再定義

計算式に入る前に、まずGPU選定における「成功」の定義を明確にしておきましょう。単に「モデルを読み込めて動いた」という状態は、ビジネスユースにおいてはスタートラインに過ぎません。

「とりあえずA100」が招くROIの悪化

実務の現場でAIインフラを検討する際、リスク回避のために「とりあえずハイエンドなNVIDIA H100や、最新のBlackwell世代(B200等)を導入しておけば間違いない」と考えがちです。また、実績のあるA100を選択肢に入れることも多いでしょう。確かに80GB以上のVRAMがあれば大抵の処理は可能ですが、1基あたり数百万円から一千万円クラスというコストは、プロジェクトの投資対効果(ROI)を著しく悪化させます。

もし、想定する用途が「社内文書などを検索して回答を生成する仕組み(RAG)」であり、同時アクセス数が数名程度であれば、旧世代のエンタープライズGPUや、コンシューマー向けのハイエンドカード(RTX 4090等)を組み合わせた構成で十分な可能性があります。逆に、24時間365日の高負荷運用が必要な場面で、冷却性能やデータの転送速度に制約のあるコンシューマー機を選べば、熱暴走によるシステム停止のリスクが高まります。

OOM(Out of Memory)リスクと推論速度のトレードオフ

GPUのメモリ(VRAM)が不足すると発生するOOMエラーは、システムを強制終了させる致命的な問題です。これを回避するために「CPUオフロード(足りないメモリ分を通常のパソコンのメインメモリで補う技術)」を使う手法もありますが、データ転送経路(PCIeバス)の速度がボトルネックとなり、回答の生成速度は劇的に低下します。

  • VRAM内に全て収まる場合: 非常に高速(数十〜百トークン/秒)
  • CPUオフロードする場合: 非常に低速(数トークン/秒以下)

実用的なチャットボットやコード生成アシスタントを構築するなら、「モデル全体と一時記憶領域(キャッシュ)が完全にVRAMに収まること」が重要な条件となります。

目指すべきゴール:必要最小限のコストで要求レイテンシを満たす

システム構築において目指すべきは、以下の3点を満たすラインを見極めることです。

  1. 完全なVRAM常駐: モデルのデータ(ウェイト) + 一時記憶領域(KV Cache) + 作業領域が、VRAM容量の90%以下に収まること。
  2. 要求スループットの達成: ユーザーがストレスを感じない生成速度(一般に人間が読む速度以上の30トークン/秒程度)を維持できること。
  3. 拡張性の確保: 将来的に入力できる文章の長さを拡張したり、LoRA(Low-Rank Adaptation)のような追加学習モジュールを適用したりする余地があること。

これらの条件を満たすために、必要な要素を分解して論理的に考えていきましょう。

VRAM消費量を決定づける4つの重要変数(KPI)

VRAMを消費する要因は、主に以下の4つに分類されます。これらを正しく理解することが、正確な計算の第一歩となります。

1. モデルパラメータ数と精度の関係

まずは基本となるモデルのサイズです。パラメータ数とは、AIの脳内にある神経網の結びつきの数を指します。「7B(70億)」や「70B(700億)」といった数字がこれに当たります。

通常、AIモデルの学習時はFP32(32ビット浮動小数点)BF16/FP16(16ビット)といった精度で行われます。1つのパラメータを表現するために何バイト使うかで、全体の容量が決まります。

  • FP32: 1パラメータ = 4バイト
  • FP16 / BF16: 1パラメータ = 2バイト

つまり、70BモデルをFP16で動かす場合、単純計算で 70 × 10^9 × 2 バイト = 140GB が必要になります。これでは80GBのVRAMを持つハイエンドGPU単体でも動作しません。そこで登場するのが「量子化」という技術です。

2. 量子化ビット数(4bit/8bit)による圧縮効果

実際にAIに回答を生成させる「推論」の段階では、パラメータの精度を落としても出力の品質があまり劣化しないことが実証されています。このデータ圧縮技術を量子化(Quantization)と呼びます。

  • INT8 (8bit): 1パラメータ = 1バイト
  • INT4 (4bit): 1パラメータ = 0.5バイト

現在、自社環境でLLMを動かす際の主流は4ビット量子化(GGUF、AWQ、GPTQ、EXL2など)です。70Bモデルなら 70 × 0.5 = 35GB まで圧縮でき、これなら24GBのGPUを2枚(合計48GB)用意すれば収まる計算になります。

3. コンテキスト長(KV Cache)の影響力

ここが最も見落とされがちなポイントです。LLMは「入力された指示(プロンプト)」と「これまで生成した回答」を記憶しながら次の文字を予測します。この一時的な記憶領域をKV Cache(Key-Value Cache)と呼びます。

KV Cacheのサイズは、モデルのパラメータ数ではなく、「入力する文章の長さ(トークン数)」と「モデルの層の深さ」に比例します。最近のモデルは非常に長い文章を扱えますが、入力が長くなればなるほど、このキャッシュがVRAMを大量に消費します。「短いテストでは動いたのに、長い文章を入れたらエラーで停止した」という現象の原因は、大抵このKV Cacheの肥大化にあります。

4. バッチサイズと並列処理のオーバーヘッド

単一の処理であればバッチサイズ(一度に処理するまとまり)は「1」ですが、サーバーとして複数ユーザーからのリクエストを同時に処理する場合、バッチサイズを上げる必要があります。バッチサイズを上げると、先ほどのKV Cacheも同時に処理する数だけ必要になります。

【実践】必要VRAM容量の厳密計算式と安全マージン

【実践】必要VRAM容量の厳密計算式と安全マージン - Section Image

それでは、具体的な計算手順を見ていきましょう。ここからが本題の計算パートです。

基本公式

必要VRAM総量 ($M_{total}$) は以下の要素の合計で論理的に導き出せます。

$M_{total} = M_{model} + M_{kv} + M_{activation} + M_{buffer}$

それぞれの要素を計算していきましょう。

A. モデル本体の容量 ($M_{model}$)

$M_{model} (GB) = \frac{P \times B}{8}$

  • $P$: パラメータ数(単位:Billion)
  • $B$: 量子化ビット幅(4, 8, 16など)

例:Llama を 4bit量子化する場合
$35GB = \frac{70 \times 4}{8}$

B. KV Cache容量の算出 ($M_{kv}$)

少し複雑に見えるかもしれませんが、Transformerモデルにおける正確な見積もりに不可欠な要素です。KV Cacheのサイズ(バイト)は以下の式で近似できます。

$M_{kv} (Bytes) = 2 \times L \times N_{kv_heads} \times D_{head} \times C \times P_{prec} \times Batch$

  • $2$: KeyとValueの2つ分
  • $L$: レイヤー数(モデルの層の深さ)
  • $N_{kv_heads}$: KVヘッド数(記憶領域を効率化する技術であるGQAを使用している場合、通常のヘッド数より少なくなります)
  • $D_{head}$: ヘッドの次元数(通常は Hidden Size / Heads数)
  • $C$: コンテキスト長(入力するトークン数)
  • $P_{prec}$: キャッシュの精度(バイト数。FP16なら2、FP8なら1)
  • $Batch$: バッチサイズ(同時処理数)

例:Llama のスペック

  • Layers ($L$): 80
  • Hidden Size: 8192
  • Attention Heads: 64
  • KV Heads ($N_{kv_heads}$): 8 (GQA採用のため)
  • Head Dim ($D_{head}$): $8192 / 64 = 128$

設定:コンテキスト8192、バッチサイズ1、FP16キャッシュの場合
$M_{kv} = 2 \times 80 \times 8 \times 128 \times 8192 \times 2 \times 1$
$= 2,684,354,560 \text{ Bytes} \approx 2.5 \text{ GB}$

もしコンテキストを32k(32,768トークン)まで拡張すると、これだけで約10GBを消費します。さらにバッチサイズを4にすれば40GBに達します。長文脈の処理において、KV CacheがいかにVRAMを消費するかが実証データからもお分かりいただけると思います。

C. 推論用バッファとシステム予約領域 ($M_{activation} + M_{buffer}$)

推論時の一時的な計算領域(Activation)や、GPUを制御するシステム自体が使用するメモリ、OSの画面表示用メモリなどです。

  • Activation: コンテキスト長に依存しますが、推論のみなら数GB程度。
  • System/CUDA: 通常 1〜2GB。

これらをまとめて、実証に基づいたアプローチとして「モデル本体 + KV Cache」の合計値に対して20%の安全マージン(余裕を持たせた容量)を乗せることを推奨します。

Llama (4bit) の計算実例

それでは、Llama(4ビット量子化)をコンテキスト8kで動かすための総容量を計算してみましょう。

  1. モデル本体: 35 GB
  2. KV Cache (8k): 2.5 GB
  3. 小計: 37.5 GB
  4. 安全マージン (x1.2): 45 GB

結論: 45GBのVRAMが必要です。24GBのGPUが2枚(合計48GB)あれば、動作する公算が大きいです。もしコンテキストをもっと長くしたい場合は、2枚では不足するため、3枚構成にするか、より大容量のGPUが必要になることが論理的に導き出せます。

ROIを最大化するGPU選定マトリクスとベンチマーク

ROIを最大化するGPU選定マトリクスとベンチマーク - Section Image

必要な容量がわかったところで、どのGPUを選ぶべきでしょうか。ここでは投資対効果(ROI)の観点から比較します。

メモリ帯域幅が支配する推論速度(Tokens/sec)

LLMの推論速度は、GPUの純粋な計算能力(FLOPS)よりも、メモリからデータを読み出す速度(メモリ帯域幅)に大きく依存します。この状態を「メモリバウンド(メモリ律速)」と呼びます。

生成速度(トークン/秒)の理論上限は以下の式で概算できます。

$\text{Tokens/sec} \approx \frac{\text{Memory Bandwidth (GB/s)}}{\text{Model Size (GB)}}$

例えば、Llama (35GB) を動かす場合:

  • RTX 4090 (帯域幅 1,008 GB/s): $1008 / 35 \approx 28$ tokens/sec
  • RTX 3090 (帯域幅 936 GB/s): $936 / 35 \approx 26$ tokens/sec
  • A100 80GB (帯域幅 1,935 GB/s): $1935 / 35 \approx 55$ tokens/sec

※実際には複数のGPU間の通信による遅延や計算時間が加わるため、実測値はこの理論値の60〜80%程度に落ち着く傾向があります。

コンシューマー機(RTX 3090/4090)vs データセンター機(A100/H100)

特徴 RTX 3090/4090 (24GB) RTX 6000 Ada (48GB) A100/H100 (80GB) 推奨ユースケース
VRAM単価 非常に安い (約1万円/GB) 普通 (約2.5万円/GB) 高い (約4万円~/GB) PoC、社内ツール、開発環境
メモリ帯域 高い (1TB/s級) 普通 (960GB/s) 超高速 (2-3TB/s) リアルタイム性が重要なサービス
相互接続 PCIeのみ (遅い) PCIe NVLink (爆速) 大規模モデルの学習・推論
耐久性 低い (連続稼働向きでない) 高い 非常に高い (24/365前提) 基幹システム、商用サービス
冷却 空冷 (3-4スロット占有) シロッコファン (2スロット) パッシブ (サーバー筐体必須) データセンター設置

マルチGPU構成(モデル並列化)の損益分岐点

RTX 3090や4090を複数枚組み合わせる構成は、コストパフォーマンスが高いと言えます。例えば、RTX 3090を2枚導入すれば、比較的抑えたコストで48GBのVRAM環境を構築でき、Llamaクラスのモデルを動かすことが可能です。これはデータセンター向けのハイエンドGPUと比較して大幅なコスト削減につながります。

ただし、注意点が一つあります。コンシューマー向けGPU(特にRTX 4090など)は、GPU同士を直接つなぐ高速通信規格(NVLink)が省かれています。データのやり取りは標準的な経路(PCIeバス)を経由するため、推論速度は若干低下します。それでも、同時アクセス数が限られる環境であれば、この構成は十分に実用的です。

意思決定のためのチェックリストと稟議用データ

ROIを最大化するGPU選定マトリクスとベンチマーク - Section Image 3

最後に、実際に導入を進めるためのチェックリストと、組織内で意思決定を行うための論理的な材料を整理します。

導入前に確認すべき5つの技術要件

  1. マザーボードのPCIeスロット間隔: ハイエンドなコンシューマーGPUは厚みがあります(3〜4スロット分)。複数枚を設置する場合、物理的に干渉しないか、あるいは延長ケーブル(ライザーケーブル)で対応できるか確認が必要です。
  2. 電源容量: 大規模モデルの推論時、GPUは瞬間的に数百ワットの電力を消費します。複数枚構成なら、システム全体を安定稼働させるための十分な容量を持つ電源ユニットが必要です。
  3. PCIeレーン数: CPUとマザーボードが、適切な帯域幅の分割(x8 + x8など)に対応しているか確認します。帯域幅が極端に狭くなると転送速度がボトルネックになり、生成が遅くなる可能性があります。
  4. 冷却エアフロー: 複数のGPUが密着すると、排熱が滞り熱暴走の原因となります。排熱効率の高いファンを搭載したGPUを選ぶか、強力なケースファンによるエアフローの確保が必要です。
  5. 量子化フォーマットの互換性: 使用する推論エンジン(vLLM、llama.cpp、AutoGPTQなど)が、選定したGPUのアーキテクチャに対応しているか事前に検証しましょう。

将来のモデルサイズ拡大に備えるスケーラビリティ評価

「現在は70Bクラスで十分だが、将来的にはさらに大規模なモデルを活用するかもしれない」。このような仮説に対しては、「拡張(スケールアウト)可能な筐体」を選定しておくアプローチが有効です。最初から複数のGPUを搭載できるワークステーションやサーバーベースを用意しておき、初期は最小構成でスタートし、必要に応じてGPUを追加していく戦略が、コストとリスクのバランスを最適化します。

上層部を説得するためのコスト対効果試算表

導入の提案には、以下のような論理的な根拠を盛り込むことをおすすめします。

  • クラウドAPIとの比較: 「外部の生成AI APIを全社員が日常的に利用した場合の継続的なランニングコストと、ローカルGPUサーバーの初期投資を比較し、どの程度の期間で投資回収(ROI)が可能か」を明確な数値で示します。
  • セキュリティ価値の換算: 「機密情報を外部に出さないことによるリスク回避」を評価します。万が一の情報漏洩による損害額と比較すれば、オンプレミス環境への投資は合理的なセキュリティ対策であることを論理的に説明できます。
  • 資産価値: 「GPUはハードウェアとしての資産価値が落ちにくく、プロジェクト終了後も他の用途への転用が可能である」という点を強調します。

まとめ

LLMのためのGPU選定は、もはや「勘」に頼るものではありません。パラメータ数、量子化ビット、KV Cacheという変数を数式に代入すれば、必要なスペックは論理的に導き出されます。

  • 成功の鍵はKV Cacheの計算: 長い文章(コンテキスト)を扱う場合、この領域の消費量を正確に見積もることが不可欠です。
  • 安全マージン20%: 実証データに基づき、余裕を持ったスペック選定を行うことが安定稼働につながります。
  • 帯域幅で選ぶ: VRAM容量と同じくらい、メモリからデータを読み出す速度(メモリ帯域幅)が推論速度に直結します。

今回解説した計算式を活用すれば、それぞれの環境に最適な構成が論理的に見えてくるはずです。

しかし、実際の導入現場では「推論エンジンの最適な設定パラメータは?」「マルチGPUでの推論パイプラインはどう構築するべきか?」「RAGシステム全体のアーキテクチャはどう設計するか?」といった、さらに実践的な課題に直面する可能性があります。常に改善点を探求し、効率的な解決策を追求していくことが、AIシステム最適化の鍵となります。

LLM実行に必要なVRAM容量の完全計算ガイド:70Bモデルを動かすGPU選定の数学的証明 - Conclusion Image

コメント

コメントは1週間で消えます
コメントを読み込み中...