LLM セルフホスティングに必要なサーバー規模の見積もり — VRAM 計算から同時ユーザーまで

「社内に LLM を一つ立てるにはサーバーがどれくらい必要ですか?」という質問に決まった答えはありませんが、決まった計算の手順はあります。モデルサイズから VRAM を計算し、同時使用量から余裕分を取り、目標速度から帯域を確認する手順です。この記事はその手順をたどりながら、シナリオ別の構成例までつなぎます。学習と推論の違いから続く記事で、ここで扱うのは推論(サービング)側です。LLM の動作原理そのものは解説記事、アプリケーション開発は LLM アプリ開発シリーズで扱いました。

ステップ 1 — モデルの重みの VRAM: パラメータ × バイト #

出発点は単純な掛け算です。モデルの重みが占めるメモリは、パラメータ数 × パラメータあたりのバイト数です。

ここから実務の感覚が二つ出てきます。第一に、BF16 の 70B(140GB)はたいていの単一 GPU に収まりません(H100 80GB には入らず、B200 192GB には入ります)。複数枚に分けるテンソル並列が必要になり、その瞬間、要件が NVLink のある機材へ一気に上がります。第二に、量子化が規模の見積もりを丸ごと変えます。 同じ 70B が 4 ビットでは 48GB 級カード一枚 + 余裕分の構成で済むようになります。品質の損失はありますが、多くの社内用途では受け入れられる水準なので、予算検討は量子化あり/なしの 2 行で行うのが実用的です。

ステップ 2 — KV キャッシュ: 同時リクエストが食うメモリ #

重みだけ計算して終えると、リリース初日にメモリ不足に遭遇します。LLM のサービングはリクエストごとに KV キャッシュ(進行中の会話のアテンションのキー・値の保管場所)を維持しますが、このサイズが同時リクエスト数 × コンテキスト長に比例して膨らみます。モデルと設定によりますが、長いコンテキストの同時リクエストが数十件積もれば、KV キャッシュだけで数十 GB になるのが普通です。

実務のルールはこうです。

• 重みのほかに VRAM の 20〜40% を KV キャッシュとランタイムの余裕に残します。 80GB のカードに 70GB の重みを載せる構成は、同時実行数 1〜2 ですでに破綻します。
• コンテキスト長の上限をポリシーとして決めます。 「最大 128K 対応」をそのまま開けておくと、少数の長いリクエストがメモリを独占します。用途に合った上限(例: 社内文書の質問応答なら 16K〜32K)が規模見積もりの前提になります。

ステップ 3 — 速度と同時実行数: 帯域が決めます #

必要な GPU 数を決める最後の変数は目標速度です。指標は二つに分けて見ます。最初のトークンまでの時間(TTFT)と、トークンあたりの生成時間(TPOT)です。体感品質は、TTFT が数秒を超えないことと、毎秒 20〜30 トークン以上の生成速度(読む速度より速い)が目安になります。

トークン生成は前回見たとおりメモリ帯域に左右されます。単純化すると、単一リクエストの生成速度の上限 ≈ メモリ帯域 ÷ 重みのサイズです。3,000GB/s 級の帯域に 40GB の重みなら、理論上は毎秒 70 トークン台が上限で、実効はその下です。同時リクエストは vLLM のようなサービングエンジンの continuous batching がバッチにまとめて GPU を埋めるので、総スループットは上がりますが、リクエストあたりの速度は同時実行数が上がるほど下がります。 同時ユーザー数が倍になったら GPU を増やすのではなく、まず「リクエストあたりの速度が SLO 内で持ちこたえる同時実行数の上限」をベンチマークで探すのが順序です。

シナリオ例 — 三つの規模 #

計算をシナリオにつなぐと感覚がつかめます。具体的な GPU の選択は名前の読み方の VRAM・帯域の基準を適用します。

• 小規模の社内ツール(同時ユーザー〜10 名、8B 級モデル) — 4 ビットの 8B は 5GB 前後なので、24GB 級の推論カード(L4 級)一枚で KV キャッシュまで余裕があります。サーバー一台、月額はクラウド基準で数万円台からです。この規模でフラッグシップ GPU は過剰投資です。
• 中規模のサービス(同時実行数十件、32B〜70B の量子化) — 4 ビットの 70B(約 40GB+キャッシュ)は、48GB カード 2 枚か 80GB 級 1 枚が出発点です。テンソル並列を使うなら NVLink のある構成が有利になります。冗長化まで考えると、同一構成 2 ノード + ロードバランサーが実務の最低ラインです。
• 大規模・高品質(非量子化の 70B 級以上、多数の同時リクエスト) — 80GB 級複数枚のテンソル並列ノードを水平に広げる構成で、ここからは学習サーバー級のインフラの話(電力・冷却・稼働率)がサービングにも適用されます。この規模の投資の前には、下の損益分岐の計算が特に重要です。

セルフホスティングの前に — API との損益分岐 #

規模見積もりの最後のステップは「本当にセルフホスティングが安いのか?」という検算です。商用 API はトークンごとの課金なので使用量が少ないほど有利で、セルフホスティングは固定費なので使用量が多く安定しているほど有利です。月間トークン使用量の推定値で API 料金を計算し、GPU コスト(クラウドのレンタル費用または購入の償却 + 電力 + 運用人員)と並べれば損益分岐が出ます。実務でセルフホスティングが正当化されるよくある根拠は、コストよりデータを外に出せない要件、応答レイテンシの要件、カスタムモデルです。コストだけが理由なら、稼働率の仮定(GPU が一日何時間働くか)を保守的に置いて計算し直すことをおすすめします。遊休 GPU は最も高くつく形の無駄だからです。

決定手順のまとめ #

1. モデルと品質要件の確定 — 候補のモデルサイズと量子化の許容可否を決めます。
2. VRAM の計算 — パラメータ × バイト + KV キャッシュ・余裕 20〜40% で、カードの容量と枚数を算出します。
3. 速度要件の確認 — TTFT・生成速度の SLO を決め、帯域を基準に候補 GPU を絞り込みます。
4. ベンチマーク — 候補の構成で vLLM などを使い、実際のワークロードの形(コンテキスト長、同時実行数)を再現して同時実行数の上限を実測します。スペック計算は候補を絞り込むところまでに使い、最終決定は実測で行います。
5. API との損益分岐の検算 — 推定使用量で比較し、コスト以外の要件(データ・レイテンシ・カスタム)を明示します。

まとめ #

• 規模の見積もりは掛け算から始まります。重みの VRAM = パラメータ数 × 精度のバイト数で、量子化がこの数字を半分以下に変えます。
• 重みのほかに KV キャッシュの分として VRAM の 20〜40% を残し、コンテキスト長の上限をポリシーとして決めます。
• 生成速度はメモリ帯域が決め、同時実行数はバッチングでスループットと引き換えになります。SLO 内の同時実行数の上限は実測で探します。
• 小規模は推論カード一枚で十分で、フラッグシップ GPU が必要になるのは非量子化の大型モデルと多数の同時リクエストからです。
• 最後の検算は API との損益分岐です。セルフホスティングの正当化の根拠がコストだけなら、稼働率の仮定を疑います。