70Bモデルをローカルで動かすためのマルチGPU構成ガイド：VRAM計算からPCIe選定まで

「社内の機密データを扱うため、クラウドのAPIは使えない。しかし、数Bクラスの軽量モデルでは複雑な業務要件を満たせるだけの精度が足りない」

機密性の高いデータを扱う環境において、このようなジレンマに直面するケースは少なくありません。その解決策として有力な選択肢となるのが、最新のLlamaシリーズなどに代表される、70B（700億パラメータ）クラスの大規模オープンモデルをオンプレミス（ローカル環境）で運用するアプローチです。最新モデルでは128kの長大なコンテキストウィンドウ（一度に処理できる文章量）への対応や、MoE（Mixture of Experts：専門家モデルの組み合わせ）アーキテクチャの導入による推論効率の向上が図られており、オンプレミス環境でも高度な処理能力を引き出しやすくなっています。

しかし、70Bクラスの大規模モデルのローカル運用は、安易な機材選定で行うと深刻なトラブルを招きます。高額なGPUを購入したにもかかわらず、「VRAM（ビデオメモリ）が数GB足りなくてモデルが読み込めない」「電源容量の計算を誤りシステムが落ちる」「熱暴走によって本来の推論速度が出ない」といった失敗事例が後を絶ちません。

現在では、RTX 50シリーズ（RTX 5090の32GB VRAMなど）の登場によりVRAM容量の標準が底上げされ、さらに新しいデータフォーマット（NVFP4やFP8）の活用によって消費VRAMを最大40〜60%削減できる環境も整いつつあります。とはいえ、これらの最新ハードウェアや技術を導入する際にも、モデルサイズとコンテキスト長に基づいた厳密なメモリ計算は不可欠です。

本記事では、高額なハードウェア投資を無駄にしないために、大規模モデルを安定稼働させるためのマルチGPU構成やハードウェア選定について、物理・論理の両面から論理的かつ明快に解説します。「動くかもしれない」という曖昧な期待ではなく、実証データに基づいた「物理的に確実に動く」という確証を持って最適な機材を選定するための実践的な指標を提示します。

なぜ70Bモデルのローカル運用はハードルが高いのか？

まず、課題の全体像を把握することから始めましょう。なぜ70B（700億パラメータ）クラスのモデルは、これほどまでにハードウェアへの負荷が高いのでしょうか。

7B/13Bモデルとは次元が違うリソース要求

一般的に扱いやすい7Bや13B程度のモデルであれば、コンシューマー向けのハイエンドGPU（VRAM 16GB〜24GB）1枚で十分に対応できます。しかし、70Bモデルはその名の通り、パラメータ数が数倍から10倍近くに跳ね上がります。

単純計算で、モデルのウェイト（重み）データを展開するだけで膨大なメモリを消費します。さらに、推論時には「KVキャッシュ」と呼ばれる一時データを保持する必要があり、コンテキスト長（入力と出力の合計トークン数）が長くなればなるほど、メモリ消費量は指数関数的に増加します。特に最近のモデルは扱える文章量が飛躍的に長くなっているため、このKVキャッシュの管理がボトルネックになりがちです。

「VRAMが足りない」で起こるOOMエラーの現実

GPUのVRAMが不足すると、OOM（Out Of Memory）エラーが発生し、処理は即座に強制終了してしまいます。

メインメモリ（RAM）にデータを逃がして強引に動かすことも技術的には可能ですが、データ転送速度がボトルネックとなり、文章の生成速度は「1秒間に数文字」から「数秒に1文字」レベルまで劇的に低下します。これではチャットボットやリアルタイム処理といった実業務には到底使えません。実用的な速度を出すには、モデル全体をGPUのVRAM内に収めることが絶対条件となります。

クラウドAPIと比較した際の損益分岐点

OpenAI APIやAnthropic APIといった最新の商用APIを利用する場合と比べ、ローカル運用の初期投資（GPUサーバー構築費）は確かに高額です。現在、クラウド側のAPIは急速に進化しており、より高度な推論機能を備えた新モデルへの標準化が進んでいます。それに伴い、APIの価格競争により高性能モデルの利用料も低下傾向にありますが、それでも以下の条件に当てはまる場合、長期的な総所有コスト（TCO）やリスク管理の観点でローカル運用に軍配が上がります。

• 機密保持: データが外部のサーバーに送信されることを一切許容できない（オンプレミス必須の要件）。
• レイテンシと安定性: 外部ネットワークの遅延や、API側の障害・利用制限の影響を排除し、一定の応答速度を保証したい。
• 固定費化: 従量課金によるコスト変動（青天井のリスク）を避け、減価償却可能な資産としてコストを固定化したい。
• カスタマイズ性: 特定の専門知識を学習させた追加モデル（LoRA）の適用や、フィルターの調整など、モデルの挙動を完全に制御したい。

このメリットを享受するためには、まず「安定して動く環境」を作ることが大前提です。中途半端なスペックでは、投資が無駄になりかねません。

【Check 1】VRAM容量と帯域幅の「絶対計算式」

ここが最も重要なポイントです。「なんとなく24GBのGPUを2枚買えば48GBだから足りるだろう」という大まかな計算は危険です。以下の論理的なアプローチで必要なVRAM量を算出してください。

モデルウェイト格納に必要なメモリ計算

モデルのサイズは、パラメータ数（P）と量子化ビット数（Q：データを圧縮する度合い）で決まります。

基本式:
$$ \text{必要VRAM (GB)} \approx \frac{P(\text{十億}) \times Q(\text{bit})}{8} $$

70Bクラスのモデルの場合:

• FP16（16bit・圧縮なし）: $70 \times 16 / 8 = 140\text{GB}$
  • これは超ハイエンドな業務向けGPU（80GB）が2枚必要になるレベルであり、一般的なローカル環境では現実的ではありません。
• 8bit量子化: $70 \times 8 / 8 = 70\text{GB}$
  • 80GBのGPUが1枚、または48GBのGPUが2枚必要となります。
• 4bit量子化 (GPTQ/AWQ/GGUFなど): $70 \times 4 / 8 = 35\text{GB}$
  • ここでようやく、コンシューマー向けGPU（24GB）2枚（合計48GB）の射程圏内に入ります。

結論1: 70Bクラスの高性能モデルを現実的なコストで動かすなら、4bit量子化が前提となります。最新の量子化技術を活用することで、実用的な精度を維持したまま動作させることが可能です。

KVキャッシュとコンテキスト長の影響

上記の35GBは「モデルを読み込むだけ」の容量です。推論を行うには、文脈を記憶するためのKVキャッシュ領域が必要です。これはコンテキスト長に依存します。

最新モデルは128kトークンといった非常に長いコンテキストに対応していますが、長く設定すればするほどメモリ消費量は指数関数的に増大します。ここでは一般的な実用ラインである8k（8192トークン）での運用を想定して計算します。

• モデル本体: 約35GB
• KVキャッシュ(8k時目安): 約2〜5GB（最適化技術や設定による）
• その他オーバーヘッド: 約1〜2GB
• 合計: 約38GB〜42GB

注意点: 最大コンテキスト長をフル活用する場合、KVキャッシュだけで数十GBを消費する可能性があります。長文処理を行う場合は、VRAM容量にさらに余裕を持たせるか、システムメモリへのオフロードを検討する必要があります。

結論2: VRAM 24GB × 2枚 = 48GB構成であれば、70Bモデル（4bit）を8k〜16k程度のコンテキストで快適に動かす余裕があります。しかし、もしVRAM 20GB × 2枚 = 40GB構成だと、かなりギリギリか、コンテキスト長を厳しく制限する必要が出てきます。

推論速度を左右するメモリ帯域幅の重要性

LLMの推論は、計算性能よりもメモリ帯域幅（データを転送する道の太さ）に制限されやすいという特徴があります。データをVRAMから読み出す速度が、そのままテキスト生成速度に直結します。

• RTX 3090/4090: 約936〜1,008 GB/s
• RTX 4060 Ti (16GB): 約288 GB/s

たとえVRAM容量が足りていても、帯域幅の狭いミドルレンジモデルで構成すると、生成速度はハイエンドモデルの3分の1以下になる可能性があります。実用的な応答速度を求めるなら、メモリ帯域幅の太いハイエンドモデルを選ぶことが重要です。

【Check 2】GPU・マザーボード・CPUの選定基準

VRAM計算ができたら、次はそれを実現するハードウェア構成です。特にコンシューマー向けパーツを流用する場合、物理的な制約が多く潜んでいます。

RTX 3090/4090(24GB) × 2枚構成のコスパと注意点

現在、コストパフォーマンスに優れているのは、RTX 3090（24GB）またはRTX 4090（24GB）を2枚使用する構成です。これで48GBのVRAMを確保できます。

しかし、これらのカードは物理的に巨大です。多くのモデルが3スロットから4スロット分を占有します。一般的なマザーボードに2枚挿そうとすると、物理的に干渉するか、隙間がなさすぎて上のカードが吸気できずに熱暴走を起こします。

対策:

• マザーボード選び: スロットの間隔が広いワークステーション向けマザーボードを選ぶ。
• ライザーケーブル: 2枚目のGPUを別の場所に配置するために延長ケーブルを使用する。
• 水冷化: 厚みを減らすために本格水冷を導入する（難易度高）。

コンシューマー機でマルチGPUをする際のPCIeレーン問題

一般的なコンシューマー向けCPUとマザーボードの組み合わせでは、データ通信の経路（PCIeレーン）の総数が限られています。GPUを2枚挿すと、通常は帯域が半分ずつ（x8 / x8）に分割されます。

「速度が半分になるのでは？」と心配されるかもしれませんが、LLMの推論においては、モデル読み込み時などを除き、PCIe帯域がボトルネックになることは比較的少ないです。

実証データに基づく一般的な傾向として、PCIe Gen4 x8接続であれば、推論速度への悪影響は数%程度と軽微です。ただし、Gen3接続やx4接続になると、モデルのロード時間が長くなり、生成速度にも影響が出始めます。

プロフェッショナル向けの検討:
予算が許すなら、PCIeレーン数が豊富なプロフェッショナル向けプラットフォーム（ThreadripperやXeonなど）を選ぶのが理想的です。フル帯域接続が可能になり、将来的な増設時も安心です。

NVLink/P2P通信の有無と推論速度への影響

かつてはNVLinkという専用ブリッジでGPUを物理的に繋ぐことが推奨されていましたが、RTX 4090世代ではこの機能が削除されました。では、マルチGPU推論は遅いのでしょうか。

答えはNoです。最近の推論エンジンは、標準的なPCIeバス経由での通信に最適化されており、専用ブリッジなしでも十分高速に動作します。70Bモデル程度であれば、この点の有無に神経質になる必要はありません。

【Check 3】電源・冷却・物理インフラの準備

スペック表に現れない部分こそ、安定稼働の要となります。

1000Wでは足りない？ピーク電力の計算

RTX 4090の消費電力の目安（TDP）は450Wです。2枚で900W。これにCPUや周辺機器を加えると、1200Wでもピーク時には心許ない計算になります。

推論時は常にフルパワーではありませんが、モデル読み込み時やプロンプト処理時には瞬間的に大きな電流が発生します。

推奨:

• 電源容量: 最低でも1500W〜1600Wの電源ユニットを用意してください。
• 電圧低下対策: 一般家庭の100Vコンセント（通常1500W上限）では、ブレーカーが落ちるリスクがあります。可能なら2系統に分けるか、200V電源の利用、あるいは電力制限設定でGPUの出力を70%程度に抑える運用を検討します。実証データとして、出力を70%〜80%に絞っても推論性能はそれほど落ちず、電力効率は劇的に向上することが分かっています。

常時稼働に耐えうるエアフローと冷却設計

GPUを2枚密接させて配置する場合、排熱処理は死活問題です。特にファンでケース内に熱を撒き散らすタイプのGPUを2枚並べると、ケース内温度が急上昇し、システム全体に悪影響を及ぼします。

対策:

• ケース: サーバーグレードの大型ケース、またはオープンフレームを使用する。
• ファン設定: ケースファンを全開にし、強制的に吸排気を行う。
• GPU選定: 可能であれば、外排気タイプのGPUやプロ向けカードを選ぶと熱管理が容易になります。

【Check 4】ソフトウェアスタックと推論エンジンの適合性

ハードウェアが準備できたら、それを動かすソフトウェアの選定です。70Bを動かすためのエンジンは主に3つあります。

llama.cpp, ExLlamaV2, vLLMのメモリ効率比較

1. llama.cpp (GGUFフォーマット)

   • 特徴: CPUとGPUのハイブリッド実行が可能。VRAMが少し溢れてもメインメモリを使って動かせる（遅くなりますがシステムは落ちません）。
   • 適した用途: 実験段階や、VRAM容量がギリギリの場合。

2. ExLlamaV2 (EXL2/GPTQフォーマット)

   • 特徴: 現在最速クラスのローカル推論エンジンの一つ。VRAM使用効率が極めて高く、コンテキストキャッシュの管理も優秀です。
   • 適した用途: NVIDIA GPU環境で、とにかく高速に推論させたい場合。実務の現場でも推奨されることが多い選択肢です。

3. vLLM

   • 特徴: サーバー用途向け。高スループットで、複数リクエストの並列処理に強い。ただし、VRAM消費量は多めです。
   • 適した用途: 社内APIとして多数のユーザーからのアクセスを捌く場合。

マルチGPU対応（Tensor Parallelism）の設定難易度

これらのエンジンは、いずれもマルチGPUに対応しています。設定は起動時のコマンドで指定するだけとシンプルです。

• llama.cpp: 全レイヤーをGPUへ割り当てるオプションや、負荷分散比率を指定するオプションを使用します。
• ExLlamaV2: 自動的に複数GPUにメモリを割り当ててくれます。

ドライバーは、最新のNVIDIA DriverとCUDA Toolkitを入れておけば基本的には問題ありませんが、PyTorchのバージョンとの整合性には注意が必要です。Dockerコンテナを利用すると、環境構築のトラブルを減らすことができます。

準備完了度診断：発注前の最終確認リスト

最後に、機材を決定する前に、以下のチェックリストで抜け漏れがないか論理的に確認してください。

• VRAM容量: 4bit量子化モデル + 8kコンテキストに対し、総VRAM容量に10%以上のマージンがあるか？
• 物理干渉: 選定したマザーボードに、GPU 2枚が物理的に挿さるスペースがあるか？
• 電源容量: GPU 2枚 + CPUの最大消費電力に対し、電源ユニット容量に20%以上の余裕があるか？（または電力制限運用を計画しているか？）
• 設置環境: 1000W近い熱源を処理できる空調と、騒音が許容される環境があるか？
• 拡張性: 将来的にGPUを増やせるスロットや電源の余地はあるか？

これらをクリアしていれば、ローカルLLMプロジェクトは成功への第一歩を確実に踏み出しています。

ローカル環境での70Bモデル運用は、確かにハードルが高い挑戦です。しかし、一度環境が整えば、機密情報を気にすることなく、強力なAIを専有できる大きな武器になります。ぜひ、実証に基づいた堅実なハードウェア選定で、安定したAI基盤を構築してください。

導入にあたっては、一般的な導入事例や構成スペックを参考に、慎重に検証を進めることをおすすめします。