大規模言語モデル（LLM）をローカル環境で活用するにあたり、初期段階で重要となるのが、必要な計算リソースを適切に見積もることです。モデルのパラメータ数やベンチマーク結果のみを基準にGPUを選定した場合、実運用においてメモリ不足や性能低下が生じ、想定した利用形態を満たせないケースも少なくありません。
特に、社内文書を対象としたRAG（Retrieval-Augmented Generation）の構築や、部門内での継続的な利用を想定する場合には、クラウドLLMのAPI利用に加え、自社環境でのLLM実行を含めた選択肢を検討することが現実的になります。その際、GPUの演算性能以上に、VRAM容量とその消費特性を正しく理解しておくことが、安定した運用を実現するうえでの前提条件となります。
また、ローカルLLMの推論処理では、モデル重みの格納に加え、コンテキスト長に応じたKVキャッシュ（Key-Value Cache）や、同時実行数に応じた作業領域がVRAMを消費します。また、LoRA（Low-Rank Adaptation）などの軽量学習を含めた活用を検討する場合には、推論時とは異なるメモリ要件も考慮する必要があります。

本記事（前編）では、ローカルLLM導入の検討段階において整理しておくべき前提として、モデル規模・コンテキスト長・同時実行数といった要素から、推論向けGPU要件をどのように見積もるかを解説します。導入後の運用や環境構築を見据えつつ、GPU選定における判断基準を、VRAMを軸に体系的に整理します。

また、続く後編では、本記事で整理したGPU要件を前提として、ローカルLLM導入後の運用と環境構築について解説していますのでぜひご参照ください。
【後編記事】
【後編】ローカルLLM導入のためのGPU環境～導入後の運用と環境構築～

1. ローカルLLMの推論に必要なGPU

ローカルLLMとは、LLMをクラウドのAPI経由ではなく、自社のサーバーやPCなどのローカル環境で直接実行する形態を指します。近年では、社内文書を活用したRAG（Retrieval-Augmented Generation）や、データの外部送信を避けたい用途を中心に、ローカルLLMを導入する企業が増えています。ローカルLLMが注目されている背景には、情報漏えいリスクの低減、利用量に応じたAPIコストの抑制、モデルや推論条件を自社で柔軟に制御できる点などがあります。一方で、推論処理をすべてローカル環境で実行するため、クラウドLLMとは異なり、計算リソースの設計がそのまま性能や安定性に直結するという特性があります。

このローカルLLMを実用レベルで安定して稼働させるうえで、中心的な役割を果たすのがGPUです。特にローカルLLMでは、推論に必要なモデルをGPUメモリ（VRAM）上に保持したまま処理を行う構成が基本となるため、GPUの有無やその構成が、ローカルLLM運用の成否を左右します。

ローカルLLMの企業活用やデータガバナンスについては以下の記事もご参照ください。
【関連記事】
セキュア×高速！ローカルLLMが変える企業AI活用とデータガバナンス最前線

1-1. GPU推論の基本特性とVRAMの役割

LLMの推論処理とは、学習済みのモデルを用いて入力された文章に対する応答を生成する処理であり、トークン生成のたびに大規模な行列演算を繰り返し実行する、計算負荷の高い処理です。CPUでも動作はしますが、実運用で求められるレイテンシ（応答速度）や、複数ユーザーによる同時実行を前提とすると、GPUを用いた構成が現実的となります。

ローカルLLMにおいてGPUが有効に機能する理由は、並列演算性能や高いメモリ帯域にあります。特に重要なのが、モデル重みとKVキャッシュをGPUメモリ（VRAM）上に常駐させたまま推論処理を完結できる点です。これにより、推論中のデータ転送を最小限に抑え、安定した応答速度とスループットを維持することが可能になります。

このような特性から、ローカルLLMのGPU設計では、「GPUのVRAM上にモデル重みとKVキャッシュを載せきる」ことが基本的な前提条件となります。言い換えると、VRAM容量が十分に確保されていない構成では、演算性能以前に推論処理そのものが不安定になりやすいという点に注意が必要です。

1-2. VRAM不足時の挙動と設計パラメータ

VRAM不足は、単純に「推論が実行できるかどうか」だけの問題ではありません。実際の運用では、VRAM容量の境界付近で特有の挙動が現れ、性能低下や不安定な動作として顕在化するケースが多く見られます。これらの挙動を事前に理解しておくことで、検証段階で発生する違和感や性能問題を、GPU設計や構成見直しといった設計レベルで回収しやすくなります。
代表的な症状としては、次のようなものが挙げられます。

• モデルロード時点でメモリエラー（Out of Memory）が発生し、プロセスが停止する
• 一定の入力長を超えたタイミングでエラーが発生し、長文入力時に不安定になる

これらは、空きVRAMが少ない状態でメモリアロケーションの断片化や管理オーバーヘッドが増加することが主な要因です。そのため、実運用では「VRAMをギリギリまで使い切る」構成ではなく、ピーク時の負荷も考慮した一定の余白を前提とした設計が重要になります。

こうした観点から、ローカルLLMのGPU設計では、以下の4つの設計パラメータを事前に整理しておくことが有効です。

• 対象タスク
  チャット中心か、RAGか、要約か、コード生成か。
• 最大コンテキスト長
  プロンプト＋RAGの実行＋AIの応答を含めた上限(4K / 8K / 16K トークン等)。
• 同時実行セッション数の目安
  PoCなら 1〜3、部門運用なら 5〜20 （いずれも目安の例）。
• 許容レイテンシ・スループット
  何秒/1リクエストまで許容するか、tokens/sec の目標値など。

これら4つの前提条件が定まると、「どのクラスのモデルを候補とすべきか」が大きく絞り込まれます。以降のVRAM見積もりやGPU構成の検討は、この前提に基づいて進めていくことになります。

2. ローカルLLMのモデル規模と代表例

2026年時点では、ローカル実行を前提としたオープン／オープンウェイト系のLLMが充実してきており、用途や規模に応じたモデル選択が現実的になっています。その一方で、モデルの選択肢が増えたことで、「どのモデルを基準にGPUを設計すべきか」が分かりにくくなっているのも事実です。

GPU設計の観点では、個別のモデル名や細かな性能差を比較する前に、どの程度のパラメータ規模のモデルを前提に設計を行うのか、また グローバルモデルで行うか、日本語特化モデルを採用するか といった基本方針を先に整理しておくことが重要です。
これらの前提を明確にしておくことで、後続のVRAM要件やGPU構成の検討を一貫した軸で進めやすくなります。

2-1. パラメータ規模とGPU設計の考え方

LLMの規模はパラメータ数によって連続的に変化しており、「軽量」「大規模」といった呼称に業界全体で統一された定義があるわけではありません。GPU設計においては、明確なクラス分けを行うよりも、パラメータ規模が大きくなるにつれて、GPUに求められる要件がどのように変化するかという観点で整理する方が実務的でしょう。

パラメータ規模とGPU設計上の考慮点は、概ね次のような関係で捉えることができます。

なお、MoE（Mixture of Experts）アーキテクチャを採用したモデルでは、全体のパラメータ数と推論時に実際に使用されるアクティブパラメータ数が異なる点に注意が必要です。
例えば、GPT-OSS 120B（gpt-oss-120b）は全体のパラメータ数が約117Bですが、推論時に実際に使用されるアクティブパラメータ数はトークンあたり約5.1Bとされています。このため、GPU設計においては次のように整理できます。

• 全体のパラメータ数 → VRAM容量（モデル重み）の要件に影響
• アクティブパラメータ数 → 推論の計算量（速度の上限）に影響

MoEモデルは、総パラメータ数だけを見ると「重い＝遅い」と誤解されがちですが、実際にはアクティブパラメータが抑えられることで計算量を抑えられる場合があります。なお、実測のレイテンシは推論エンジン、バッチング、コンテキスト長（KVキャッシュ）などにも依存するため、想定条件での検証を前提に設計することが重要です。

こうした特性も踏まえると、GPU設計で重要なのは、「どのモデル系統を採用するか」を早期に確定することではなく、どの程度のパラメータ規模を“基準”としてインフラを設計するのかを明確にすることです。
基準となるパラメータ規模が定まれば、必要なVRAM容量、同時実行数の上限、現実的なGPU構成を、ぶれのない前提のもとで検討できるようになります。

2-2. 日本語特化・国産モデルの位置づけ

ローカルLLMやオンプレミス環境での運用を前提とする場合、モデルの性能そのものだけでなく、開発主体や学習プロセス、運用時の前提条件も重要な検討要素になります。その文脈において、国産モデルは「日本語対応モデル」という枠にとどまらず、運用要件を明確に想定して設計されたモデル群として位置づけることができます。特に、GPU構成やコストを抑えつつ、業務文書を中心としたタスクを安定して処理したい場合、国産モデルは現実的な選択肢になり得ます。

ローカルLLMやオンプレミス運用を前提とする場合、モデルの性能指標だけでなく、どのような前提で学習・チューニングされ、どの運用形態を想定して設計されているかも重要な検討要素になります。特に、社内文書や業務データを自社環境で扱うケースでは、学習データの性質や設計思想が、そのまま運用適性に影響します。

基準モデルを明確にすることで、VRAM要件、GPU構成、同時実行数といった後続の設計判断を、一貫した前提のもとで進めやすくなります。

3. 推論向けGPUスペックの検討

推論向けGPUの設計は、GPUの型番や世代を先に決めるのではなく、「どのモデル規模を、どの条件（コンテキスト長・同時実行数）で運用するか」を明確にしたうえで、VRAM容量・演算性能・推論エンジンをセットで検討するプロセスになります。

ここでは、推論向けGPU設計を進めるうえでの検討ステップを、大きく2つに分けて整理します。

3-1. VRAMとモデル規模・コンテキスト・同時実行の整理

推論向けGPUのVRAM設計では、VRAM使用量を構成要素ごとに分解して考えることが重要です。ここでは、モデル規模・コンテキスト長・同時実行数をVRAMに落とし込むための基本的な整理方法を示します。
まずは、「どの条件で推論を行うか」を定義します。具体的には、最大コンテキスト長と同時実行セッション数を先に想定しておくと良いでしょう。

推論時にVRAMを消費する主な要素は、次の3つに分解して考えると整理しやすくなります。

• モデル重み（weights）
  学習済みモデルのパラメータを保持するための領域。モデルが学習を通じて獲得した「知識の実体」にあたる数値データです。推論ではこの重みを参照して次のトークンを計算するため、まずこの分がVRAMを占有します。モデル規模（パラメータ数）が大きいほど、重みの格納に必要なVRAMも増えます。
• KVキャッシュ（key-value caches）
  入力した文脈（これまでのトークン）を保持して、毎回の再計算を減らすためのメモリです。コンテキスト長（入力の長さ）が長いほど、また同時に処理するセッション数が多いほど、KVキャッシュは増えてVRAMを圧迫しやすくなります。
• 作業領域（workspace）
  推論中に一時的に使う“作業用の領域”です。推論エンジンや設定（バッチング等）によって必要量が変わるため、見積もりでは一定の余白を確保し、実際の設定で計測しながら調整するのが安全です。

まず、モデル重みについては、パラメータ数 × 量子化精度*1を基準に概算することができます。例えば、数十B規模のモデルであれば、4bit量子化では「パラメータ数 × 約0.5バイト」、8bit量子化では「パラメータ数 × 約1バイト」を起点として、モデル重みが占有するVRAMのおおよその規模感を把握できます。量子化方式や実装によってオーバーヘッド（量子化の管理情報や内部表現、推論エンジン内部処理のために、モデル重みとは別に消費される追加のVRAM）は変動するため、まずはどの量子化精度を前提にするかを先に決めておくことが重要です。

一方で、KVキャッシュと作業領域の使用量は、モデル規模だけでは決まりません。例えば、コンテキスト長を長く設定するほど、1セッションあたりに必要なKVキャッシュは増加します。また、同時に複数の推論セッションを処理する場合、その分だけKVキャッシュはほぼ直線的に積み上がります。このため、「短い入力を単発で処理する構成」と「長文コンテキストを複数同時に扱う構成」では、同じモデルであっても必要なVRAMは大きく異なります。

このように、GPU設計ではまずモデル重みのサイズを起点に、どのクラスのGPUが候補になるかを大まかに絞り込み、そのうえで、想定する最大コンテキスト長や同時実行数の条件を設定した状態で、KVキャッシュと作業領域がどの程度追加で必要になるかを検証によって確認していく、という段階的な進め方が有効です。表や概算値だけで確定させず、可能であれば、実際に使用する推論エンジンや設定条件（コンテキスト長・同時実行数）をシミュレートした検証環境上でPoCを行い、その結果を踏まえて構成を補正していくのが良いでしょう。

*1： 量子化は、モデル重みを低精度（例：8bit/4bit）で表現してサイズを圧縮し、必要VRAMを減らす手法です。一般に精度を下げるほどVRAMは節約できますが、出力品質や速度、対応する推論エンジン／量子化方式によって挙動が変わるため、用途に合わせて量子化精度を選びます。

3-2. GPU構成と推論の実行基盤（エンジン／運用ツール）選定のポイント

VRAM要件の目安が見えたら、以下のようにGPU構成（単一GPU／複数GPU）と推論エンジンをセットで検討します。

1. 単一GPUで行くか、複数GPUを前提にするか。
2. どの推論エンジンを使い、どのような実行特性（同時実行・バッチング・量子化）を前提に設計するか。

この2つは独立した選択ではなく、組み合わせによって性能・安定性・運用難易度が大きく変わります。

単一GPU構成が成立するケース

モデル重みとKVキャッシュを含めた推論要件が単一GPUのVRAMに収まる場合、基本的には単一GPU構成が最もシンプルで安定します。
GPU間の通信オーバーヘッドを考慮する必要がなく、構成・運用ともに管理しやすい点がメリットです。

複数GPU構成が必要になるケース

一方で、次のような条件では複数GPU構成を前提とした設計が必要になります。

• 単体GPU（1枚）のVRAMでは要件を満たせない場合（例：重み＋KVキャッシュ等が収まらない）
• 長文コンテキストと高い同時実行数を同時に満たしたい場合
• 将来的にVRAMおよび演算性能をスケールさせたい場合

複数GPU構成では、Tensor Parallel、Pipeline Parallel、Data Parallel などをどのように組み合わせるかによって、必要なネットワーク帯域の要件も変わってきます。「70B級モデルを1GPUでギリギリ載せるか」「2GPU以上で余裕を持たせるか」といった判断は、ここまで整理してきたVRAM見積もりに加え、コスト・冗長性・運用負荷のバランスを踏まえて行います。

推論の実行基盤（エンジン／運用ツール）選定の考え方

同じGPU構成であっても、推論エンジンの選択と設定次第でスループットは大きく変わります。
代表的な選択肢は次のとおりです。

• vLLM
  PagedAttention／Continuous Batching による高い同時実行性能。同時実行やバッチングを前提とした設計に向いており、RAGや社内ボット系の本番運用に適する。
• TensorRT-LLM
  NVIDIAが提供するLLM推論性能を高速化・最適化するための包括的なオープンソースライブラリ。チャットAIや文書生成AIといったサービスの根幹を支える重要な技術。
• Ollama
  ローカルLLMを手早く動かすための実行環境。モデルの取得・起動・切り替えをまとめて扱え、外部ツールやアプリから呼び出せる形（API）で提供しやすい。
• llama.cpp
  CPU／軽量GPU／スタンドアロン環境向け。強いバッチングや大規模同時実行は前提とせず、検証用途やローカル利用、ポータビリティ重視の構成に向く。

これらの点をあらかじめ明確にしておくことで、「VRAMは足りているのにスループットが出ない」「GPUを増やしたのにピーク時の遅延が改善しない」といった状況を避けやすくなります。

4. 推論向けGPU設計と学習向けGPU設計の違い

本記事では推論向けGPU設計を主軸に解説していますが、ローカルLLMの検討においては「学習用途も同じGPUで対応できるのか」という点で誤解が生じやすいため、ここで簡単に違いを整理しておきます。

学習では、推論にはない次の要素が追加でVRAMを消費します。

• 勾配（gradients：パラメータ更新方向を示す値）
• オプティマイザ状態（optimizer states：学習を安定させるための内部状態）
• 中間活性化（activations：逆伝播のために保持される中間計算結果）

このため、学習時（FP16/BF16）には、推論時と比べて数倍以上のVRAMを要求されるケースが一般的です。一方、LoRA や QLoRA のように更新対象を限定する手法を用いることで、学習時のVRAM消費を大きく抑えることは可能です。
実務では、「推論は中〜大規模モデル、追加学習は LoRA／QLoRA 前提の小〜中規模モデル」と役割を分けてGPUを設計するケースも多く見られます。

このように、GPU設計の段階では「学習用途も想定するのか」「推論中心で必要に応じて軽量学習を行うのか」を切り分けて考えることが重要です。

5. 構成パターン別の技術要件

最後に、実際によくある構成パターンごとにGPU要件を整理します。ここでは「検証」「部門運用」「全社運用」の3レベルに分けて考えます。

5-1. 検証環境の構成

検証環境では、「とりあえず動作するか」を確認するだけでなく、どの条件で性能や安定性が崩れるかを把握することが重要になります。この段階で限界点を把握しておくことで、部門運用・全社運用への移行時に設計の手戻りを減らすことができます。

例えば、次のような点を確認できると良いでしょう。

• 最大コンテキスト長を指定した際の挙動：長文入力時にOut of Memoryが発生しないか、極端なレイテンシ増加が起きないか。
• 同時リクエスト実行時のスループット：複数セッションを並行実行した場合に、応答時間やtokens/secがどの程度低下するか。
• 長時間稼働時の安定性：数時間〜1日程度の連続稼働において、VRAM使用量の増加やメモリリーク、プロセスの不安定化が発生しないか。

検証環境におけるGPU要件の目安は、想定用途ごとに次のようなイメージになります。

※ 本表は、単一セッション・制限付きコンテキスト長を前提とした「検証用途での最小構成イメージ」です。実運用では、同時実行数やコンテキスト長に応じて追加のVRAM余白を見込む必要があります。

5-2. 部門運用環境の構成

部門運用に移行すると、検証環境とは前提条件が大きく変わります。複数ユーザーによる同時利用が発生するため、単発の応答速度だけでなく、ピーク時におけるスループットや全体の安定性が重要な設計要件となります。検証環境では問題にならなかったVRAM使用量の揺らぎや、同時実行時のレイテンシ増加が、部門運用では顕在化しやすくなる点に注意が必要です。

そのため、部門運用では「検証時に動作した構成をそのまま横展開する」のではなく、同時実行を前提としたGPU構成や、用途に応じたモデルの使い分けをあらためて設計することが求められます。

5-3. 全社運用環境の構成

全社運用では、利用部門や用途が多岐にわたり、ピーク負荷の発生タイミングも読みづらくなります。そのため、単一GPUや単一サーバーで完結させる構成よりも、最初からスケールアウトを前提とした設計としておく方が現実的です。

具体的には、次のような構成が典型例になります。

• 複数GPUノードによるマルチノード構成
  高メモリGPUを複数基用いたGPUクラスタを前提とし、1台に負荷を集中させない。
• ロードバランサによるリクエスト分散
  複数の推論サーバーにリクエストを分散し、ピーク時の遅延や輻輳を抑制する。
• GPUおよび推論指標のモニタリング
  GPU使用率、VRAM使用率、レイテンシ、キュー長などを継続的に監視し、しきい値を超えた場合にスケール判断を行う。

実務的には、最初から大規模な全社専用基盤を構築するのではなく、部門運用レベルの構成を全社で共用しつつ、モニタリング結果をもとに「どこがボトルネックになっているか」を確認しながら、段階的にGPUノードを増設していく進め方が現実的になります。

6. まとめ

本記事では、ローカルLLMを実運用で活用するための前提として、推論処理を中心に据えたGPU要件の考え方を整理しました。ローカルLLMのGPU設計では、単にモデルのパラメータ数やベンチマーク結果を見るのではなく、モデル規模・コンテキスト長・同時実行数といった運用条件からVRAM要件を逆算することが重要です。特に、推論時にはモデル重みだけでなく、KVキャッシュや作業領域がVRAMを消費するため、余裕を持った設計が安定運用の前提となります。また、検証・部門運用・全社運用といった利用段階によって、GPU設計で重視すべきポイントは大きく異なります。検証段階では限界点の把握、部門運用では同時利用を前提とした安定性の確保、全社運用ではスケールアウトを見据えた構成設計が求められます。

なお、学習用途については推論とは異なるVRAM消費構造を持つため、推論用GPU設計とは切り分けて検討することが現実的です。まずは推論を安定して回すことを優先し、必要に応じてLoRAなどの軽量学習を検討する、という進め方が多くの企業にとって無理のない選択肢となります。続く後編では、本記事で整理したGPU要件を前提に、オンプレミスやクラウド環境への配置、Dockerを用いた構成分割、部門・全社利用を見据えた運用設計について解説します。
▶︎ お問い合わせはこちら

※「Llama」はMeta Platforms, Inc.の商標または登録商標です。
※「NVLink」「TensorRT-LLM」はNVIDIA Corporationの商標または登録商標です。
※「vLLM」はは vLLM Project の商標です。