AI モデルの提供における GPU クラスタの限界と最適化：単価・ユーザー数・コスト概算

製品のサービススタックに AI モデルを提供する場合、**「GPU クラスタで処理可能なユーザー規模の上限」**は常に重要な検討事項です。ハードウェア知識があれば、ナプキン数学（簡易推計）で一人あたりのコストを概算できます。以下に主要な計算要素と結論を整理しました。

• シングル GPU のリソース
• 行列乗算のコスト
• ランゲージ・モデルの概要
• アテンションの詳細解説
• KV-Cache を用いた計算量削減
• トークンの単価と GPU 稼働率
• 現実的なユーザー数と最適化手法

---

シングル GPU のリソース

GPU の仕様書には以下の 2 つの主要な指標が記載されています。

• ピークスループット: 浮動小数点演算能力（TFLOP）。通常、$1 \text{ TFLOP/s} = 10^{12} \text{ 演算/秒}$ と表されます。
• メモリーブैंンド幅: グローバルメモリ（VRAM）からレジスタへ転送可能なデータ量（TB/sec）。

注意点: 計算スループットの評価は、FP-8 量子化を前提としています。必要に応じて数式は FP-16 に調整可能です。

---

行列乗算のコスト

AI モデルは膨大な行列に対して多数の行列乗算を行います。コスト評価はこの基本ステップから始まります。 2 つの行列 $A_{N \times d}$ と $B_{d \times M}$ を積 $O_{N \times M}$ にします。各要素 $O^{i,k}$ は以下の式で計算されます。

$$ O^{i,k} = \sum_{j=1}^{d} A^{i,j} * B^{j,k} $$

処理手順:

1. メモリから $A^{i,j}$ を読み込む。
2. メモリから $B^{j,k}$ を読み込む。
3. 掛け算を実行し、累積和に足す。 1 要素につき $d$ 回繰り返すため、サイズ $(N, d) \times (d, M)$ の行列積コストは以下の通りです。

• メモリアクセス: $2NMd$
• 浮動小数点演算: $2NMd$

最適化（タイル化）の場合: メモリアクセス量を削減できる最適化技法があります。

• メモリアクレス量: 約 $d(N+M)$ に削減可能。
• 詳細については別ブログ記事「Alvin」を参照してください。

---

ランゲージ・モデルの概要

LLM（大規模言語モデル）の本質は非常にシンプルです。入力された単語シーケンスに対して、次に来る単語を生成するタスクを行います。各単語は $d$ 次元ベクトルで表され、アテンション関数によって次の単語が予測されます。

単一フォワードパスの概要（Python パseudo-code）:

y = input() # y は (N x d) 次元の行列
for each layer in the network:
    y = attention(y)

# ファイナルレイヤーの出力を単語確率に変換する。
# W_vocab はサイズが (d x vocab_len) の行列、
# vocab_len はモデル辞書に含まれる全ての単語数。
token_probs = softmax(y * W_vocab)
next_tok    = token_probs.argmax(token_probs) # 次トークンを抽出

これが LLM が**「自動回帰的（auto-regressive）」**と呼ばれる所以です。 トークン生成まで、自身の出力を再度入力として扱い、ループを繰り返します。

---

アテンションの詳細解説

アテンション計算は以下の手順で行われます。入力は $X \in \mathbb{R}^{N \times d}$ 行列です。

$$ Q = X.W_Q,\quad K = X.W_K,\quad V = X.W_V $$ $$ Attention(Q,K,V) = softmax(Q.K^T/\sqrt{d}).V $$

Python コード:

def attention(X, W_q, W_k, W_v):
    Q, K, V = X @ W_q, X @ W_k, X @ W_v
    Q_KT = Q @ K.transpose(2,1)
    return softmax(Q_KT / sqrt(d_model)) @ V

バッチ処理: 実際の推論は複数回の対話を並列化（Batching）で行います。入力 $X \in \mathbb{R}_{B \times N \times d}$ となります。

メモリ・計算コストの課題: 単一の行列乗算 $K = X.W_k$ に着目します。例えば、対話を 20 万トークンまで許容する場合（$N \approx 200,000$）、以下のコストがかかります。

• 浮動小数点演算: $2BNd^{2}$
• メモリアクセス: $Bd(N+d)$

仮定：$d = 8192$（標準的なモデル）。 結果: 新しいトークンを生成するために、GPU は過去の履歴を再度処理せざるを得ず、演算量がメモリアクセス量より圧倒的に多くなります。これにより、次のバッチを待たなければならない数十万サイクルの待ち時間が発生します。

---

KV-Cache を用いた計算量削減

この待機問題を解決するのがKV-Cacheです。LLM は自動回帰的であるため、過去のトークンに対して行列積を再度計算する必要はありません。

1. 入力 $X$ を受け取り行列乗算を行う。
2. Attention を適用して新トークンを生成する。
3. 生成した K, V をキャッシュし、次回以降に再利用する。

このようにすることで、履歴全体ではなく「最新のトークンのみ」を処理すればよく、計算量が劇的に低下します。

推論エンジンの役割: vLLM などの推論エンジンでは、プログラム上では VRAM の一部を KV-Cache に割り当てることが可能です。これは高度な技術（Pagerank など）が適用されていますが、簡易見積もりの文脈では以下の単純化が成り立ちます。

処理内容の変化: 履歴全体 $N \times d$ を処理する代わりに、最新トークンのみ $1 \times d$ を処理します。

X   = tensor(B, 1, d) # 最新のトークンのみ (B バッチ)
W_k = tensor(d, d)
O   = tensor(B, 1, d)

コスト削減効果:

• メモリアクセス: 約 2620 万回
• 演算: 約 5240 万回（メモリ 1 アクセスに対し 2 演算）

これにより、メモリアクセスに対する演算効率は向上し、GPU の待機時間が解消されます。

---

トークンの単価は？ GPU 稼働率の最大化

B200 を例に取った場合、以下の性能を有します。

• メモリーブैंンド幅: 8 TB/s
• 計算密度（Compute）: 4500 TFLOP/s

Blackwell クラスの GPU は、データを処理する能力が読み込み速度の562 倍あります。最大限のパフォーマンスを出すためには、読み込んだバイト量あたり 562 回の演算を行う必要があります。

しかし、前述の KV-Cache を使用した最適化であっても、実際の処理は「最新のトークンのみ（1 要素）」なので、読み込みに対して演算が不足しています（メモリ帯域制限）。

理論的な最大稼働率計算: $$ 2B = 562 \implies B = 331 $$

• 一つの NVIDIA B200 GPU で理論的に扱える同時対話数（バッチサイズ）: 約 331 ユーザー

ただし、これは演算能力の限界であり、実際のボトルネックは VRAM の容量制限となります。

---

現実的にどの程度のユーザー数をサポートできるか

ここでは320 億パラメータ（32B）モデルを前提とします。

• モデル重み: 32GB 使用。
• コンテキスト長 ($N$): 20 万トークン、次元 ($d$): 8192、レイヤー数 ($L$): 64 を仮定。

KV-Cache サイズの計算: 初期にすべての履歴を保持する場合、必要なメモリ量は膨大になります。 $$ KV \ cache \ size = 2 * N * L * d = 2 * 200,000 * 64 * 8192 = \mathbf{263.5 \text{ GB}} $$

これは単一の B200 の VRAM（通常 96GB など）を大きく超えています。これを解決する手法としてGrouped-Query-Attention (GQA) を適用します。

• GQA: 複数の Query ヘッドに対して、同じキー・バリューヘッドを共有することでメモリ削減を実現。

最適化後の結果: GQA を適用し、メモリの効率的な割当（vLLM の PagedAttention など）を行うと、一人あたりの KV-Cache サイズは約 26GB へと削減されます。

• 残り VRAM で許容される並列ユーザー数: $160 \text{ GB} / 26 \text{ GB} \approx \mathbf{6 \text{ ユーザー}}$

しかし、現実にはほとんどの対話は 20 万トークンの全長には達しません。

• 中央値: 4,000〜40,000 トークン程度。
• 不活性な対話の管理: チャンク（断片）化し、使用量に応じて割り当て。使われないスレッドは削除。

これらによる最適化により、Blackwell チップあたり40〜60 ユーザーをサービス可能です。さらにアプリの使用実態（ChatGPT 風の待機時間が多いなど）を考慮すると、実際の GPU 稼働率は 20% 程度となります。

結論: 一つのパッケージで快適にサポート可能なユーザー数は、約 300〜800 人程度と考えられます。チャット以外（API サーバー等）の場合は、この指標を厳密に測定する必要があります。

---

秒間トークン数（Tokens Per Second）

理論上の最大バッチ数 $B=6$ の場合でも、体感速度はどのくらいでしょうか？メモリと計算のバランスから導かれます。

1 回の生成サイクルの時間分解:

• データ移動時間: 23.75 ms （VRAM からレジスタへの転送限界）
• 計算時間: 0.5 ms （演算能力がボトルネックではないため、ほぼ瞬時）

合計で約 24ms を要しますが、この間 $B=6$ の処理を並列に行います。

• 1 秒あたりの生成数: 約 40 トークン / ユーザー（全体では 250 トークン/秒）。

LLM の出力を読む人間の読解速度（通常 30〜60 文字/秒）と比較すると、この速度は読み手が追いつくか、あるいは少し速すぎます。ただし、これは「生成」の話であり、SQL クエリ実行などのバックグラウンド処理とは速度感が異なります。

---

一人あたりのドルコスト

ハードウェアの所有形態によってコスト構造が大きく異なります。

1. 自営（所有モデル）

• B200 の購入価格: 約 4 万ドル。
• 最大稼働率時 ($B=331$): 一人あたり約 6,667 ドル。
• 現実的な稼働率時 ($B=300$): 一人あたり約 133 ドル（データセンター費・保守費込み）。

2. レンタルクラウド

• GPU の時給: 約 43 ドル。
• 最大バッチ数時: $43 / 331 \approx$ 0.13 ドル/人/時間。
• 現実的な稼働率時 ($B=300$): 約 0.14 ドル/人/時間（月間換算で約 9.36 ドル）。

---

まとめと今後の展望

NVIDIA B200 で 32B モデルを運用する場合、以下の点が結論となります。

• 理論上のユーザー上限: 演算帯域制約により約 331 ユーザー（VRAM 制限により現実には少なくなる）。
• 最適化による現実値: KV-Cache チャンク化などで 40〜80 ユーザー程度が許容される。
• コスト効率: レンタル利用の方が、小規模・中規模のスタートアップにとっては導入障壁が低いです。

注意点:

• エージェントが高負荷なワークフロー（ツール呼び出しループ等）を実行する場合は、上記見積もりには余裕を持たせる必要があります。
• 複数の GPU を保有している場合でも、単純なスケーリングではなく、モデルサイズやバッチ数の最適化計算が必要です。
• ナプキン数学は方向性を示すには有効ですが、プロダクション環境では詳細なベンチマークテストを推奨します。