この連載について
「自前でLLMを動かすと、いくら／何人で／何が載るか」を現場で説明できる粒度で整理する3部構成です。
型番・モデル名・価格は 2026年6月時点 のスナップショット（ここが一番早く陳腐化します）。
対象は テキスト生成LLM（チャット／要約／RAG／コード生成等）。マルチモーダルや画像・動画生成（拡散モデル）は VRAM の食い方が異なるため別途見積りを。
⚠️ 数値はすべて 机上の概算。調達・容量設計・SLAの根拠にはせず、具体化の際は各ベンダー・提供元に要件・見積りを確認してください。
3部構成の第2回。占有したGPUで 何人で・何が載る・どれくらい速い を VRAM から読み解きます。価格・3形態は ① コスト編、モデル選定・構成は ③ モデル・構成編へ。
占有GPUでどれくらい使える? ── VRAMを「予算」で考える
ここからは占有の話です（従量課金は容量の悩みがありません）。
VRAM＝AIの“作業机の広さ”。 モデルの重みも、会話の途中経過も、すべてこの机に載せる必要があり、載る量が使える量 を決めます。VRAMは固定の予算で、これを固定費と変動費が食い合います。
VRAM ≧ ①モデル重み(固定費) + ②文脈長 × ③同時数(= KVキャッシュ, 変動費) + バッファ
- 固定費＝モデル重み：ロードした時点で常駐。モデルを選んだ時点で確定。
- 変動費＝KVキャッシュ：会話ごとの作業メモリ。コンテキスト長 × 同時接続数で増減。ここが設計の主戦場。
-
バッファ（余白）：活性化・CUDA context・断片化などの余白。固定値ではなく目安で、実務では vLLM の
gpu_memory_utilization（既定 0.9 前後）等で VRAMの1割程度を空ける運用が一般的（40GBなら約4GB）。本記事の試算は概算として数GB（≒3）を見込んでいます。
補足：VRAMは揮発性です。「常駐」は“起動中ずっと居座る”意味で、電源を切れば消え、次回起動時にストレージから再ロードされます。70Bは重みが大きいので、この再ロードに時間がかかる（＝1台構成だと復帰に数分）点は可用性（③モデル・構成編で扱う）に効いてきます。
試算：小型「8B」を VRAM「40GB」で
Llama系8BはGQA構成で、KVキャッシュは 1Kトークン ≒ 0.125GB（重みはFP16で16GB）として計算します。
| ケース | 重み(GB) | 文脈長/人 | 同時 | KVキャッシュ(GB) | 合計(GB) | 40GB枠 |
|---|---|---|---|---|---|---|
| 1人で利用 | 16 | 8K | 1 | 1.0 | 20 | ✅ 余裕 |
| 5人で同時 | 16 | 8K | 5 | 5.0 | 24 | ✅ 余裕 |
| 10人で同時 | 16 | 8K | 10 | 10.0 | 29 | ✅ OK |
| 1人が最大長 | 16 | 128K | 1 | 16.0 | 35 | ⚠️ ギリギリ |
| 5人が最大長 | 16 | 128K | 5 | 80.0 | 99 | ❌ 枠超過 |
※ 概算値。実数はベンダー/提供元に要確認（KVキャッシュの実効サイズはモデル構造・推論基盤で変動）。
ポイント：
- 「同時利用」＝同じ瞬間に生成中のリクエスト数。登録人数ではありません（10人登録＝10件同時、はまず起きない）。
- 普段使い(8K)なら10人でも余裕、最大長(128K)を出すと1人でほぼ満杯。これが 「長さ × 人数」のトレードオフ の実体です。
性能は「長さ」と「同時数」の2軸
-
軸①：1回で扱える長さ＝コンテキスト長。モデルが決める（上限は
max_position_embeddings。Llama 3.3なら128K）。 - 軸②：同時に・どれだけ速く＝スループット。GPUメモリ(VRAM)が決める。
文脈長は設定で決めるツマミです。モデル上限以下で、広げれば1人あたりのKVキャッシュが増えて同時数が減り、短く抑えれば大人数をさばけます。
結局、速さは何で決まるの?
「カタログのTFLOPSが大きい＝速い」は誤解のもと。LLMの処理は2段階あり、効く指標が違います。
| フェーズ | 何をする | ボトルネック | 効く指標 |
|---|---|---|---|
| プロンプト処理（プリフィル） | 入力を一気に読む | 計算 | FLOPS（演算性能） |
| 生成（デコード） | 1トークンずつ出す | メモリ読み出し | メモリ帯域 |
- FLOPS ＝ 1秒あたりの浮動小数点演算回数（＝計算の速さ）。TFLOPS の「T」は兆(10¹²)で、単位の桁が違うだけで指標は同じ。なお紛らわしいが FLOPS（大文字S＝per Second＝性能） と FLOPs（小文字s＝演算“量”） は別物。
- FLOPSが効くのは 長い入力を一気に処理する場面（長文要約・大量RAG）と 学習。最初の1文字が出るまでの時間（TTFT＝Time To First Token）に効く。
- 一方、体感の“ツラツラ出る速さ”はメモリ帯域 が決める（生成は1トークンごとに重み全体を読むため）。ここがFLOPSと混同されやすい。
- まとめ：入力を読む＝FLOPS／出力を作る＝メモリ帯域。「TFLOPSが大きい＝速い」とは限らず、用途で見る指標が変わる。
GPUは、この6指標で見る（借りても買っても共通）
| 指標 | 単位 | 何を決めるか | 勘所 |
|---|---|---|---|
| VRAM容量 | GB | モデル＋KVが「載るか」 | 最重要。足りなければ起動しない |
| メモリ帯域 | GB/s・TB/s | 生成（出力）の速さ | 生成速度は実はここ |
| 演算性能 | TFLOPS | プロンプト処理・学習の速さ | 長い入力ほど効く |
| 対応精度 | FP16/FP8/FP4 | どこまで軽量化できるか | 新世代ほど低精度に強い |
| GPU間接続 | NVLink / PCIe | 複数GPUを束ねる速さ | 大規模トレーニングや複数GPUにまたがる推論で重要（1枚に載るなら影響小）。モデルを分割する時はPCIeだと頭打ち |
| 消費電力 | W (TDP) | 設置・電源・冷却の制約 | ハイエンドは1枚700W級（B200は1000W） |
「PCIeだと頭打ち」とはどういう時か
GPU間の“道幅”は規格で大きく違います ── PCIe 5.0 x16 ≒ 64 GB/s に対し、NVLink(H100/H200世代) ≒ 900 GB/s/GPU と一桁以上の差。これが効く/効かないは「GPU間でどれだけ通信するか」で決まります。
- 頭打ちになる：1つのモデルを複数GPUに分割（テンソル並列でFP16 70Bを2枚に等）→ レイヤー通過のたびに中間結果を交換。大規模分散トレーニングの勾配同期(all-reduce)も同様。GPUの計算（数TB/s級）に対しPCIe(64GB/s)が細く、計算が通信待ちになる。
- 関係ない：1枚に載るモデル（8B・量子化70B）はGPU間通信が無い。複数GPUに別々のリクエストを割り当てるデータ並列（レプリカ）も通信量が小さくPCIeで十分。
- ひとことで：「1つの仕事を複数GPUで分担し、途中で頻繁に会話する」時だけ NVLinkが効く。
参考までに、データセンター級GPUのVRAM/帯域（2026年6月時点）：
| GPU | VRAM | 帯域 | TDP |
|---|---|---|---|
| H100 | 80GB HBM3 | 3.35 TB/s | 700W |
| H200 | 141GB HBM3e | 4.8 TB/s | 700W |
| B200 | 192GB HBM3e | 8.0 TB/s（FP4対応） | 1000W |
参考（出典）
- meta-llama/Llama-3.3-70B-Instruct — Hugging Face（70B / 128K / config）
- Meta Llama 3.3 (70B) — Oracle Generative AI（標準版と公式FP8版）
- nvidia/Llama-3.1-70B-Instruct-FP8 — Hugging Face（FP8でメモリ約50%削減）
- NVIDIA H200 / NVIDIA B200（VRAM・帯域・TDP）
- 量子化：GPTQ / AWQ / bitsandbytes
- 推論基盤：vLLM（PagedAttention・文脈長/同時数の制御）
本記事は2026年6月時点の情報に基づく机上での整理です。型番・価格・モデル名は時点依存であり、最新は各一次情報をご確認ください。