大規模言語モデル推論のGPUサイジングにおける失敗の多くは、ハードウェアを発注する前に起きています。チームがモデルを選び、それをロードできるだけのメモリを持つGPUを見つけ、それで完了だと考えてしまうのです。
モデルをロードできることは最初の制約にすぎません。推論の容量は3つの要素の組み合わせで決まります。重みのためのメモリ、アクティブなすべてのリクエストのアテンションキャッシュのためのメモリ、そして約束したレイテンシ目標のもとでGPUがトークンを生成できる速度です。
GPUではなく、ワークロードから始める
アクセラレーターを比較する前に、サービスが何をしなければならないかを書き出します。
- モデルと精度。パラメータ数、アーキテクチャ（レイヤー数、アテンションヘッド数、キー/バリューヘッド数、ヘッドの次元）、そして許容できるサービング時の精度です。
- コンテキスト長。リクエストあたりの入力トークン数の標準値と95パーセンタイル値、そして出力長の標準値と最大値です。
- トラフィックの形。1日の平均ではなく最も混雑する時間帯の毎秒リクエスト数と、ピークの急峻さです。
- レイテンシの目標。最初のトークンまでの時間（ユーザーが何かを目にするまでの時間）と、出力トークンあたりの時間（その後にテキストがストリーミングされる速さ）です。
- 分離とロケーション。プロンプトと出力を特定の環境や国の外に出してよいかどうか。これによって、価格に関係なく共有キャパシティが選択肢から外れることがあります。
対話型チャット、検索拡張型の検索、ドキュメント要約、オフラインのバッチスコアリングは、同じモデルを使っていても、必要なハードウェアの規模がまったく異なります。入力8,000トークン、回答200トークンの要約ジョブは、入力1,000トークン、出力600トークンのチャットアシスタントとは、システムの異なる部分に負荷をかけます。
メモリ その1：モデルの重み
パラメーター数に、サービング時の精度におけるパラメーターあたりのバイト数を掛けます。一般的な目安は、FP16またはBF16でパラメーターあたり2バイト、INT8またはFP8で1バイト、4ビット形式で約0.5バイトで、これに量子化スケール分のわずかな量が加わります。
- 8Bパラメータ。FP16で約16 GB、INT8で8 GB、INT4で4〜5 GBです。
- 70Bパラメータ。FP16で約140 GB、INT8で70 GB、INT4で35〜40 GBです。
- 400Bクラスのパラメータ。FP16で約800 GB、INT8で400 GB、INT4で200〜230 GBです。つまり、量子化してもマルチGPUノードが必要になります。
CUDAコンテキスト、アクティベーションバッファ、テンソル並列の通信バッファ、断片化により、通常GPUあたり数ギガバイトが消費されます。vLLMなどのサービングエンジンでは確保できるGPUメモリの割合を設定でき、計画値として物理メモリの85から90パーセントを使用可能とみなすのが妥当な出発点です。
8ビットの重みは広く使われており、ほとんどのタスクで測定可能な劣化はわずかです。4ビットの重みはメモリをさらに半分に削減しますが、論理的推論、コード、多言語出力の品質がより目に見えて低下することがあるため、それを前提に容量を計画する前に、自社のプロンプトで評価してください。
メモリ その2：KV cacheが同時実行数を決める
生成中、各リクエストはそれまでに処理したすべてのトークンについて、アテンションのキーとバリューを保持します。このKV cacheはコンテキスト長と同時リクエスト数に応じて大きくなり、負荷の高いサーバーでは重みよりも多くのメモリを占めることがよくあります。
トークンあたりのサイズは、2（keyとvalueで1つずつ）×レイヤー数×key/valueヘッド数×ヘッド次元×要素あたりのバイト数です。grouped-query attentionを採用した一般的な70Bクラスのモデル（80レイヤー、key/valueヘッド8、ヘッド次元128）をFP16で動かす場合、2 x 80 x 8 x 128 x 2バイトで、トークンあたり約320 KBになります。
トークンあたり320 KBの場合、4,000トークンのコンテキストを保持する1リクエストは約1.3 GBを使用します。そうしたリクエストが50件あれば約65 GBが必要となり、INT8の重みそのものとほぼ同じサイズになります。
- ページ単位の割り当て。キャッシュを小さなブロック単位で割り当てるエンジン（paged attention）は、実在するトークン分のメモリしか確保しません。そのため、長いリクエストのための余裕を持たせたうえで、最大コンテキストではなく平均コンテキストを基準に計画できます。
- キャッシュの量子化。KV cacheをFP8で保存すると、フットプリントがおよそ半分になり、収まるシーケンス数がおよそ2倍になります。通常、品質への影響は小さいものの、テストで確認すべきです。
- プレフィックスキャッシュ。多くのリクエストが長いシステムプロンプトやドキュメントを共有している場合、そのキャッシュ済みのキーとバリューを再利用することで、メモリとプリフィルの演算の両方を節約できます。
- コンテキストの上限。リクエストあたりの最大コンテキストに上限を設けることは、多くの場合、最も安価なキャパシティ対策です。ごく少数の非常に長いリクエストが、他のすべてのリクエストからリソースを奪うことがあるためです。
スループット、レイテンシ、バッチ処理
推論にはボトルネックの異なる2つのフェーズがあります。プリフィルはプロンプト全体を一度に処理し、演算性能に律速されます。目安は1パラメーター、1トークンあたり2回の浮動小数点演算で、70Bモデルでは入力トークン1つにつき約140 GFLOPが必要です。続くデコードでは、リクエストごとに1トークンずつ生成し、メモリ帯域幅に律速されます。各ステップでGPUメモリから重みとそのリクエストのKV cacheを読み出すためです。
これにより、単一ストリームの速度の単純な上限が得られます。メモリ帯域幅を、トークンあたりに読み出すバイト数で割った値です。それぞれ約2 TB/sのGPU 2基に分散した70 GBのINT8の重みを持つモデルは、重み全体を最大でも毎秒約57回しか読み出せません。そのため、この構成では1リクエストが毎秒約57トークンを超える速度でストリーミングすることはできず、実際にはそれより低くなります。
推論を経済的にしているのはバッチ処理です。vLLMやTritonベースのスタックなどのエンジンで現在標準となっている継続的バッチ処理は、バッチの完了を待つのではなく、ステップごとに新しいリクエストを実行中のバッチに受け入れます。合計スループットは、KV cacheが満杯になるか演算能力が限界に達するまで、バッチサイズとともに急激に向上します。
バッチ処理の代償はレイテンシです。したがって容量計画はトレードオフです。95パーセンタイルで最初のトークンまでの時間と出力トークンあたりの時間の目標を満たす最大のバッチを選び、ベンチマークのグラフに示されたピークスループットではなく、その時点で測定したスループットからフリートの規模を決めてください。
トラフィックから同時実行数を見積もる
KV cacheとバッチのスロットを消費するのは、同時実行数、つまり同時に処理中のリクエストの数です。これはLittleの法則で見積もることができます。平均同時実行数は、到着率と各リクエストがシステム内に滞在する平均時間の積に等しくなります。
ピーク時のトラフィックが毎秒5リクエストで、各リクエストが到着から最後のトークンまで14秒かかる場合（キューイングとプリフィルに約1秒、出力400トークンを毎秒30トークンで生成）、システムは同時に約70件のリクエストを保持します。これにリクエストあたりの平均保持トークン数とトークンあたりのKVサイズを掛けると、ピーク時に必要なキャッシュメモリが求められます。
- 平均ではなくピークを使う。対話型のトラフィックは、最も混雑する時間帯に1日平均の2〜4倍になるのが一般的です。
- 出力長に注意する。同時実行数はリクエストが開いている時間に比例し、出力トークンは処理の遅い部分です。そのため、平均出力長が2倍になると同時実行数もおよそ2倍になります。
- リトライとエージェントを考慮する。ツールを呼び出すエージェントや自動リトライは、ユーザーの1回の操作に対して複数回のモデル呼び出しを発生させることがあり、実質的な到着率を何倍にも増やします。
計算例
Grouped-Query Attentionを採用した70Bクラスのモデルを基盤とし、INT8の重みとFP16のKV cacheでサービングする社内アシスタントを考えます。ピーク負荷は毎秒5リクエストです。リクエストの平均は入力2,000トークン、出力400トークンです。目標は、95パーセンタイル値で最初のトークンまで1.5秒未満、ストリーミングは毎秒25トークン以上です。候補となるハードウェアは、それぞれ約2 TB/sのメモリ帯域幅を持つ80 GBのGPUです。
- 重み。1パラメータ1バイトで70Bパラメータの場合、約70 GBです。80 GBのGPU 1基では、これに加えて実用的なキャッシュを保持できないため、最小単位はテンソル並列による2基のGPUとなります。物理容量は160 GB、90パーセントで使用可能な容量は約144 GBです。
- キャッシュの予算。144 GBから重みの70 GBを差し引くと、KV cacheに使えるのは約74 GBです。
- キャッシュの需要。Littleの法則から、同時リクエストは約70件です。各リクエストは終了時点で約2,400トークンを保持し、1トークンあたり320 KBで約0.8 GBとなるため、ピーク時の需要は約55 GBです。約25パーセントの余裕をもって収まります。
- デコード速度。各ステップでは、GPUごとに約35 GBの重みと、そのGPUが担当するキャッシュ分（ピーク時で約27 GB）を読み出します。2 TB/sでは、オーバーヘッドを除いて1ステップあたり約31 msとなり、ストリームあたり毎秒約30トークン、合計で毎秒約2,000出力トークンになります。これはピーク時に必要な毎秒2,000トークンとちょうど同じで、余裕はまったくありません。
- プリフィルの負荷。5リクエスト×2,000トークンで毎秒10,000入力トークンとなり、約1.4 PFLOP/sの処理量です。これは同じGPUをデコードと奪い合うため、バースト時にはストリーミング速度が目標を下回ります。
結論として、GPU 2基のレプリカ1つでモデルとキャッシュは収まりますが、ピーク時のスループットに余裕がなく、冗長性もありません。ロードバランサーの背後にレプリカを2つ、合計4基のGPUを置けば、レプリカあたりの負荷はほぼ半分になり、バースト時もレイテンシを目標内に保て、閑散時間帯には1つのレプリカをドレインしてメンテナンスできます。
稼働率、スケールアウト、100万トークンあたりのコスト
モニタリングツールが報告するGPU使用率は誤解を招くことがあります。バッチサイズ1のためにメモリを読み込んでいるGPUは、有用な処理をほとんど行っていなくても、使用率が100パーセントに見えるためです。代わりに、キャパシティに対応するメトリクスを追跡してください。毎秒の生成トークン数、KV cacheの使用率、キューで待機しているリクエスト数、そして最初のトークンまでの時間と出力トークンあたりの時間のレイテンシのパーセンタイル値です。
- キューが発生したらスケールアウトする。ピーク時にキューイングが続く場合や、KV cacheの使用率が約90パーセントを超えてリクエストのプリエンプションが発生している場合は、レプリカが満杯です。
- レイテンシが悪化したらスケールアウトする。スループットが横ばいのまま、出力トークンあたりの時間の95パーセンタイル値が目標に近づいている場合、そのレプリカにとってバッチが大きすぎます。
- モデルが収まらない場合はスケールアップする。重みと最小限のキャッシュが収まらない場合や、長いコンテキストが大半を占める場合は、GPUあたりのメモリを増やすか、レプリカあたりのGPU数を増やすことが有効です。
- N+1を維持する。重要なサービスは、ピーク時にレプリカを1つ失っても稼働し続けられる必要があります。多くの場合、レプリカ数を決めるのは単純なスループットよりもこの条件です。
100万トークンあたりのコストは、これらの数値から直接導けます。フリートの1時間あたりのコストを、1時間に生成する100万トークン単位の数で割ります。あくまで仮定として1 GPU時間あたり$2.50とすると、4基のGPUを使う例のコストは1時間あたり$10です。ピーク時の最大出力である毎秒2,000トークンでは、1時間に720万出力トークンを生成し、100万トークンあたり約$1.40となります。1日の平均負荷がピークの30パーセントであれば、同じフリートが生成するのは1時間あたり約220万トークンで、実質コストは100万トークンあたり約$4.60に上がります。
単価を左右するのは、時間単価よりも稼働率です。バッチ要約、埋め込みのバックフィル、評価の実行など、後回しにできるワークロードで対話型容量のアイドル時間を埋めれば、全体の平均コストを下げられます。
キャパシティプランニングのチェックリスト
- パラメーター数、レイヤー数、key/valueヘッド数、ヘッド次元を記録。
- 重みとKV cacheの精度を決め、自社のプロンプトで品質をテスト。
- 重みのメモリとレプリカあたりの最小GPU数を算出。オーバーヘッド用に10〜15パーセントを確保。
- トークンあたりKV cacheバイト数と、重み差引後のキャッシュ予算を算出。
- ピーク時のRPSと平均入出力トークン数を測定または推定します。
- Littleの法則でピーク同時実行数と必要キャッシュを見積もる。
- 最初のトークンまでの時間と出力トークンあたりの時間に、p95の目標を設定します。
- 目標同時実行数でエンジンをベンチマークし、レプリカあたりの持続的な毎秒トークン数を記録。
- ピークスループットに余裕を持たせてレプリカ数を決め、N+1用に1つ追加。
- リクエストごとにコンテキストと出力に上限を設定。繰り返すプロンプトにはプレフィックスキャッシュを。
- スケールアウトはGPU使用率だけでなく、キュー深度、キャッシュ使用率、レイテンシで判断します。
- ピーク時と平均負荷時の100万トークンあたりのコストを算出。バッチ処理はアイドル時間に。
- プロンプト、出力、重みを置ける場所を確認してから、ロケーションを選択。
Vonahostがお手伝いできること
Vonahostは、GPU容量をプロジェクトごとにお見積もりし、GPUのモデル、数量、リードタイムを書面で確定します。また、データとモデルがお客様の環境内にとどまるプライベート導入にも対応しています。導入にはPyTorch、vLLM、Triton、Kubernetesなどの標準ツールを使用するため、前述のサイジング手法を、提案するハードウェアでのベンチマークにそのまま適用できます。
Vonahostのすべての提案書には、構成、ロケーション、責任範囲、米ドル建ての月額料金が明記され、各サーバーを稼働させる国はお客様が選択します。