AI推論におけるGPU選定とTCO最適化の手法を解説

AI の普及が急拡大し、チャットボットからコンテンツ生成まであらゆる分野を変革しています。しかし、依然として共通の課題があります。組織はどのようにして推論ワークロードに対して GPU リソースを確実に見積もり、総所有コスト（TCO）を最適化できるのでしょうか？レイテンシの目標、モデルの選択、独特なトラフィックパターン、予算制約などが入り混じる中で、1 つでもモデルを展開する前に迷子になってしまうのは容易いことです。

現在の推論環境は、ハードウェア仕様や「1 秒あたりのトークン数」だけで決まるものではありません。チームはますます増える見積もり判断に直面しています。本当に重要なのはどの種類のレイテンシか？初回トークンまでの時間（TTFT）の平均値、99 パーセンタイルのレイテンシ、トークン間のレイテンシ、あるいは別の指標なのか。使用ケースにおけるトークンのパターンは、GPU メモリと計算能力にどのような影響を与えるのか。オンプレミスのコア容量とクラウドベースのエラスティシティ（柔軟性）の間で、どのバランスが適切か。

本稿では、使用ケースを適切な GPU フットプリントにマッピングし、推論用 GPU インフラを実際のワークロードの挙動に基づいて見積もるための実践的なフレームワークを提供します。最も重要な入力要素、つまり使用ケース、トークンのパターン、レイテンシ目標、同時接続数、キャッシュヒット率、モデル選択、デプロイ戦略について順を追って解説します。その過程で、開発者やインフラチームは、コアとフレックスのキャパシティプランニング、適切なサイズの GPU 選定、そして量子化（quantization）、プルーニング（pruning）、知識蒸留（distillation）といったモデル最適化技術が、パフォーマンス向上と TCO の削減にどう寄与するかを理解できます。

使用ケースを明確に：サイズ設計とTCOの起点

ノイズをかき分ける第一歩は、一見単純ながら本質的な問いから始まります。「どのような課題を解決しようとしているのか？」です。使用ケースによって必要となるインフラの規模は大きく異なります。

大まかに分類すると、推論（Inference）ワークロードは主に以下の4つのカテゴリに分類されます。

• AI チャットボット／コパイロット
• AI エージェント（深層調査および推論タスク）
• コンテンツ生成
• 翻訳アプリ

表 1: さまざまなワークロードシナリオにおける GPU の入力トークンと出力トークンのユースケース（注：これは例示の数値であり、実際の運用環境で観測される値は大きく異なる可能性があります）

より賢い TCO を実現するための重要 sizing インプット

ユースケースをマッピングした後は、以下の要素を軸にサイズ設計プランを立てましょう。

• モデル選定 (LLM): 大きいほど良いわけではありません。Nemotron 3.5 Lightning、Inkling Small、Muse Glimmer など、自社のデータ要件やレイテンシ要件に適した主流のモデルを検討してください。小規模なファインチューニング済みモデルを採用する選択肢もあります。

• アプリのスケーリング: アプリケーションの規模を把握し、ユーザーベースの成長を見越して設計します。

• DAU と並行処理数: 日次アクティブユーザー数 (DAUs) を把握するとともに、同時に発生するリクエスト数を理解しましょう。純粋な DAU の数よりも、高い並行処理数が GPU メモリとレイテンシに与える負荷の方が大きくなります。

• ISL/OSL: プロンプトあたりのトークン数（入力文字列長・出力文字列長）を予測します。文字列が長いほど、GPU のメモリ使用量と計算リソースの需要は高まります。

• キャッシュヒット率: 各リクエスト間で重複する入力トークンの割合を見積もり、KV キャッシュから提供できる部分を特定します。キャッシュヒット率が高まれば、それらのトークンに対するプレフィル処理をスキップでき、TTFT（Time to First Token）と1 リクエストあたりのコストが削減されます。その結果、同じトラフィック量を捌くために必要な GPU 容量を抑えることが可能になります。

• レイテンシ指標: レスポンシブなユーザー体験には TTFT が不可欠です。99 パーセンタイル値やトークン生成間隔のレイテンシ指標も併せて考慮しましょう。

1 日あたりの DAU ごとのリクエスト数

DAU（月間アクティブユーザー）の数がわかれば、ユーザーあたりのリクエスト数を乗じて、1 日の総ワークロードを推定できます。

契約期間

安定して予測可能なトラフィックであれば、長期契約やオンプレミスインフラの導入を検討してもよいでしょう。一方、変動が激しい実験的なワークロードでは、柔軟なオンデマンド（クラウドまたはスポット）リソースを活用する方がメリットが大きくなります。

コアとフレックスモデルの実装：コストリスクを減らし、支出を最適化

予測不能なワークロードに振り回されてコストが増大しないよう、「コアとフレックス」の戦略を採用しましょう。

• コア: 定常的なワークロードに対して、オンプレミスまたは予約済みクラウド GPU のベースライン容量を確保します。これにより価格変動リスクを低減し、主要ユーザー層に対するサービスの信頼性を担保できます。

• フレックス: 突発的な需要増や新機能リリース、実験的試行に対応するため、パブリッククラウドの弾力性（スポットまたはオンデマンド GPU）を追加で活用します。これにより運用コストをバッファとして使いながら、過度な投資を抑えたままイノベーションを推進できます。

このモデルは、資本効率（CapEx）と運用アジリティ（OpEx）のバランスを取るものであり、過剰な設備投資や成長の阻害を防ぎます。

実務的な要素を見落とさない

• コロケーション: データがオンプレミスにあり、かつ容量需要が安定している場合は、この項目を省略しても構いません。ただし、急激な拡張が必要になったり、データ所在地に関する規制要件がある場合などは、スケールアウトのためにコロケーションパートナーの活用を検討する必要があります。

GPU の適切なサイズ選定：ワークロードに合わせた最適化

GPU を選択する際は、ワークロードのメモリ使用量、レイテンシ目標、同時実行プロファイルに合わせて選定することが重要です。必要以上に大きな容量を確保するとリソース利用率が低下し、トークンあたりのコストが増加します。逆に、メモリの要件や計算能力に対して不足している場合、スループットとレイテンシが制約されます。使用するモデルやプロンプトの長さに合わせて GPU を最適化することで、パフォーマンスとコストのバランスを保つことができます。

具体的なユースケース例

以下の事例は、異なるエンタープライズワークロードにおける GPU のサイズ選定と TCO（総所有コスト）の見積もり方法を説明するためのものです。実際の GPU 台数や構成、コスト結果は、使用するモデルの種類、ワークロードの複雑さ、同時実行数、パフォーマンス目標などによって変動します。

1. 金融サービス：関係者向けコパイロット

ある地元の信用組合では、関係者（リレーションシップマネージャー）向けの AI コパイロットを導入しています。このシステムは、複雑な顧客メールを分析し（入力トークン数が多く、出力は短い）、迅速で個別化された回答や知識の検索を提供します。

• TTFT (Time To First Token): 顧客とのコミュニケーションにおいて応答性とシームレスな体験を提供するため、1 秒未満のレイテンシを目指します。

• 同時実行数: 小規模から中規模のチームの場合、10〜50 の並行セッションを想定すれば十分なケースが多いです。ただし、トラフィックが集中する期間にはバースト対応のスケーリングが必要になる可能性があります。

・精度：知識集約型タスクやコンプライアンスが重要な業務では、一貫性のある正確な出力を得るため、高精度（FP16 または BF16）の推論モードを使用してください。

・LLM モデルの種類：中規模（70 億〜130 億パラメータ）で推論、要約、および内部ナレッジベースを活用した検索拡張生成（RAG）に最適化された指令微調整モデルは、文章のニュアンスを深く理解する必要があるタスクに適しています。

・メモリ推奨事項：70 億〜80 億パラメータの小型モデルには VRAM 約 24GB の GPU を、130 億パラメータのモデルには KV キャッシュ用の余裕を持たせるため VRAM 48GB を推奨します。これにより、複数ユーザー対応や高速な検索処理を最適化できます。

2. ライフサイエンス分野 — 創薬のための AI エージェント

製薬スタートアップのラボでは、AI エージェントが研究チームをサポートしています。このエージェントは、極めて長いコンテキストを持つ全文の研究論文を処理し、洞察の抽出や結果サマリーの生成を行います。クエリには通常、20,000 トークンの入力と 2,000 トークンの出力が必要です。

・TTFT（Time to First Token）：非常に大きなコンテキストを扱うため、応答性と全文科学データの処理ニーズのバランスを取り、目標は 2 秒未満に設定します。

・同時実行性：共同研究に対応するため、20〜30 ユーザー分の並列処理リソースを用意し、ピーク時の負荷に備えて余裕を持たせてください。

・精度：技術的・科学的コンテンツを扱う際、事実の正確性を保つため、高精度（FP16 以上）が不可欠です。

LLM モデルの種類：生体医学文献やドメイン固有のコーパスを用いて継続事前学習（continued pretraining）によって微調整または適応させた、16K〜32K トークンの長文コンテキスト対応モデルを採用します。

メモリ推奨事項：ISL/OSL リクエストに対応し、バッチ処理や並列ワークフロー中も安定したパフォーマンスを発揮させるため、1 台あたり 80GB を超える非常に大容量のメモリを最適に選択してください。

1. メディア・マーケティング – リアルタイムコンテンツ生成器

中規模のデジタルマーケティング代理店が、短いブリーフ（入力 500 トークン、出力 2,000 トークン）からパーソナライズされたメールや広告コピーを自動生成するシステムを構築しました。キャンペーン開始時には利用者が急増するため、制作サイクルにおいてクリエイティブな出力速度とコスト効率のバランスが強く求められます。

• TTFT（Time to First Token）：短い入力と中程度の長さの出力に対して 1 秒未満の応答性を確保することで、クリエイティブ生成のレスポンス性が向上します。

• 同時実行性：キャンペーン駆動型のバースト的な利用に対応できるよう急速なスケーリングを計画し、マーケティングのピーク時には 50〜100 人以上の同時ユーザーをサポートできる設計とします。

• プレシジョン（精度）：クリエイティブコピー生成やパーソナライゼーションタスクにおいて、品質と効率性の最適なバランスを実現するため、FP16 精度を採用します。

• LLM モデルの種類：マーケティングプロンプトや文体スタイルに従うよう、軽量な微調整またはプロンプトエンジニアリングで適応させた、汎用指令チューニング済みまたは会話型 LLM（30〜70 億パラメータ）を使用します。

メモリ推奨事項

GPU 1 基あたり 16〜24GB のメモリがあれば、広告プロンプトのサイズに対応でき、大規模なバッチスケジューリングも効率的に実行できます。

4. テクノロジーコンサルティング — 大規模翻訳プラットフォーム

ある企業の IT 部門は、クライアント向けに多言語コードおよびドキュメントの翻訳ツールを開発しています。各リクエスト（入力・出力ともに 1,000 トークン）は、世界中に分散したチームから発生します。

• TTFT（Time to First Token）: 滑らかでインタラクティブな翻訳体験、特に自動化されたワークフローにおいては、低 TTFT（1 秒を大幅に下回る値）が不可欠です。

• 同時実行性: 夜間のバッチ処理やグローバルな需要の急増に対応するため、数百件の並行リクエストを処理できる規模でシステムを設計し、オートスケーリングを活用した弾力的な拡張計画を立てる必要があります。

• 精度: 言語翻訳やコード変換においては、FP16 または INT8 の精度で十分です。これにより、高いスループットとコスト削減を実現できます。

• LLM モデルの種類: エンタープライズグレードのプラットフォームには、中規模から大規模な多言語モデル（例：エキスパート混合アーキテクチャや拡張語彙を持つアーキテクチャ）が最適です。コード変換やドメイン固有の翻訳に対応できるアーキテクチャサポートが必要です。

• メモリ推奨事項: エントリーレベルの GPU（8〜16GB のメモリ）で十分対応可能です。特に、分散型かつスケーラブルなクラウド環境でオーケストレーションする際に有効です。

より良い TCO を実現するためのモデル最適化

TCO（総所有コスト）の最適化は、モデルのメモリ使用量を戦略的に削減することに尽きることが多く、これは最も効果的な施策の一つです。メモリフットプリントを小さくすることで、コンパクトな GPU や低価格帯の GPU でサービスを提供できるようになり、多くの場合、GPU の階層自体を一つ減らすことも可能になります。これを実現する主な手段として、エンジニアリング工数の少ない順に以下の 3 つが挙げられます。

• 量子化（Quantization）: 数値精度を下げ（FP16 から FP8/INT8 へ）、メモリ使用量を 25〜50% 削減します。再学習は不要です。
• プルーニング（Pruning）: 重要度の低い層やニューロンを削除し、パラメータ数と計算リソースを削減します。
• 知識蒸留（Knowledge distillation）: 大規模な教師モデルの能力を、より小さく高速な学生モデルへ転移させます。

これらは一度きりの作業ではなく、モデルやワークロードの変化に応じて随時見直す必要があります。企業規模での運用では、ハードウェア、電力、運用オーバーヘッドにおける累積的な節約効果が、これらの取り組みへの投資に見合う価値をもたらします。

量子化：即効性のある最適化手法

モデルは通常、パラメータあたり 2 バイトの 16 ビット浮動小数点形式（FP16/BF16）で提供されます。量子化では、重みだけでなく、必要に応じて活性化値や KV キャッシュも 8 ビット形式（FP8 または INT8）に変換し、パラメータあたり 1 バイトに圧縮します。これにより、重みのメモリ使用量が約半分になります。

このように解放されたメモリを活用すれば、より小型の GPU で動作させたり、同じ GPU 上でバッチサイズを大きくしたり KV キャッシュの長さを延伸したりして、スループットを向上させ、トークンあたりのコストを下げることが可能になります。

これは「すぐに成果が出る」手法です。再学習が不要だからです。

ポストトレーニング量子化（PTQ）は、すでに訓練済みモデルをその場で変換します。これには、FP16の範囲を8ビットにマッピングする層ごとのスケーリング係数を設定するためのキャリブレーションパスとして、ごく少数の代表的なプロンプトのみを使用し、歪みを最小限に抑えます。

FP8 が推奨される出発点です。推論においては通常は損失なしに近い精度を維持でき、INT8 や INT4 よりも余裕があります。許容できる誤差の範囲はユースケースによって異なりますが、本番環境へ投入する前に自社のワークロードで検証を行う必要があります。

PTQ による精度低下が許容閾値を超えた場合は、量子化をフォワードパス内でシミュレートして微調整し、重みが低精度に適応させる量子化対応トレーニング（QAT）へと移行します。詳細は ModelOpt をご参照ください。

NVIDIA の ModelOpt を使えば、PTQ は数行のコードで実現できます：

PyTorch をインポートします。

modelopt.torch.quantization モジュールを mtq という別名でインポートします。

modelopt.torch.export モジュールから、Hugging Face チェックポイントのエクスポート関数 export_hf_checkpoint を読み込みます。 （原文の技術表記: import、import、modelopt.torch.quantization as mtq、from）

from transformers import AutoModelForCausalLM, AutoTokenizer
``` （原文の技術表記: `from`、` `）

model` `= AutoModelForCausalLM.from_pretrained(

    `

tokenizer` `= AutoTokenizer.from_pretrained("meta-llama/Llama-3.1-8B-Instruct")

`def` `calibration_loop(model):`

```python
for prompt in ["このクライアントのメールを要約してください", "ここでの主要なリスクは何ですか"]:
    pass
``` （原文の技術表記: ` `、` `）

inputs = tokenizer(prompt, return_tensors="pt").to(model.device)

` （原文の技術表記: ）

with torch.no_grad():

`model(*inputs)`

model = mtq.quantize(model, mtq.FP8_DEFAULT_CFG, forward_loop=calibration_loop)

export_hf_checkpoint(model, export_dir="./llama-3.1-8b-fp8")

図 1 に示す通り、FP8 量子化により Llama-3.1-8B の重量メモリは 16.06GB から 9.08GB に減少し、再学習を必要とせずに43.5% の削減を実現します。詳細な手順については、以下の記事もご参照ください。

ポストトレーニング量子化による LLM のパフォーマンスと精度の最適化、

NVIDIA NeMo と TensorRT Model Optimizer を用いた LLM のポストトレーニング量子化、

TensorRT で FP8 チェックポイントを高性能推論エンジンに変換する。

プルーニングと蒸留：さらに踏み出す

量子化だけでは不十分な場合、プルーニング（剪定）と知識蒸留によってより深い圧縮が可能になります。プルーニングでは、重要な度合いの低いコンポーネントを削除します。具体的には、層全体を削る「深度プルーニング」や、アテンションヘッド、FFN チャンネル、埋め込み次元を削減する「幅プルーニング」などです。知識蒸留は、剪定された学生モデルを元の教師モデルに対して訓練することで精度を回復させます。

一度の計算コストは、ハードウェア利用率、電力消費、運用オーバーヘッドにおける持続的な節約によって相殺されます。

以下の例では、NVIDIA NeMo を使用し、Qwen3-8B を教師モデルとして、約 6B の学生モデルを対象としています。まず Hugging Face のモデルを NeMo チェックポイント形式に変換し、WikiText-103-v1 で前処理を行った後、プルーニングを実行します。このプルーニングステップで実際にアーキテクチャが再構築されます。深度プルーニングでは層数を 36 から 24 に削減し、幅プルーニングでは ffn_hidden_size を 12288 から 9216、hidden_size を 4096 から 3584 に縮小します。これにより、パラメータ数は概ね 6B になります。

前提条件として、NVIDIA H100 または A100 80GB GPU を 2 台用意し、Docker 対応環境と NeMo コンテナ（nvcr.io/nvidia/nemo:25.11, nvidia-modelopt==0.37.0）を用意してください。

ステップ：プルーニング（深度または幅）

NEMO_TEACHER_PATH="./nemo_ckpt/Qwen3-8B.nemo"

`PRUNE_COMMON="--devices 1 --tp_size 1 --pp_size 1 \

"restore_path ${NEMO_TEACHER_PATH} --legacy_ckpt \

"seq_length ${SEQ_LENGTH} --num_train_samples ${NUM_TRAIN_SAMPLES} --mbs ${MICRO_BATCH_SIZE} \

"data_paths ${DATA_PATHS} --index_mapping_dir ${INDEX_MAPPING_DIR}"`

PRUNE="torchrun --nproc_per_node 1 ${NEMO_ROOT}/scripts/llm/gpt_prune.py" （原文の技術表記: PRUNE_COMMON="--devices 1 --tp_size 1 --pp_size 1 \）

Qwen3-8B-nemo-depth-pruned の場合:

PRUNE PRUNE_COMMON --save_path ${ROOT_DIR} /Qwen3-8B-nemo-depth-pruned

--target_num_layers 24

Qwen3-8B-nemo-width-pruned の場合:

PRUNE PRUNE_COMMON --save_path ${ROOT_DIR} /Qwen3-8B-nemo-width-pruned

--target_ffn_hidden_size 9216 --target_hidden_size 3584

トレーニング実行コマンド:

TRAIN="torchrun --nproc_per_node ${DEVICES} ${NEMO_ROOT}/scripts/llm/gpt_train.py"

${TRAIN} （原文の技術表記: ${TRAIN} \）

--name depth_distill --model_path ${ROOT_DIR}``/Qwen3-8B-nemo-depth-pruned` `

  ``--teacher_path ${NEMO_TEACHER_PATH} --log_dir ${ROOT_DIR}``/depth_distill_logs` `--legacy_ckpt `

  ``--data_paths ${DATA_PATHS} --index_mapping_dir ${INDEX_MAPPING_DIR} --seq_length ${SEQ_LENGTH} `
``` （原文の技術表記: ` `、` `）

--max_steps ${MAX_STEPS} --gbs ${GLOBAL_BATCH_SIZE} --mbs ${MICRO_BATCH_SIZE} \

--val_check_interval ${VAL_CHECK_INTERVAL} --precision bf16-mixed

![Line graph comparing validation loss curves for depth pruning and width pruning of a Qwen3-8B model targeting approximately 6B parameters. Width pruning achieves a lower final validation loss (3.21) while depth pruning converges faster. Final validation loss for depth pruning: 3.60.](https://developer-blogs.nvidia.com/wp-content/uploads/2026/08/image3-6.webp)

**図 2. プルーニング検証損失：深さと幅の関係**

※ 本記事で使用したデータセットはデモンストレーション用であり比較的小規模なため、提示された数値は参考例として捉えてください。図 2 に示す通り、今回の実行では幅方向のプルーニング（width pruning）がより低い最終検証損失（3.21 vs 3.60）を達成し、深さ方向のプルーニング（depth pruning）の方が収束が早かったです。

規模感の目安として、NVIDIA が公開した実行では、Qwen3-4B よりも 30% 高速で、かつ MMLU の精度も高い（72.5 vs 70.0）6B の深さ方向プルーニング済みモデルが生成されています。

完全なパイプラインの詳細、エンドツーエンドのドキュメント、およびアーキテクチャに関する推奨事項については、以下の記事をご参照ください。

- [NVIDIA NeMo Framework を用いた LLM モデルのプルーニングと知識蒸留](https://developer.nvidia.com/blog/llm-model-pruning-and-knowledge-distillation-with-nvidia-nemo-framework/)
- [NVIDIA TensorRT Model Optimizer による LLM のプルーニングと知識蒸留](https://developer.nvidia.com/blog/pruning-and-distilling-llms-using-nvidia-tensorrt-model-optimizer/)
- [Llama-3.1 を Minitron へ変換する方法（8B から 4B へのプルーニング・蒸留）](https://developer.nvidia.com/blog/how-to-prune-and-distill-llama-3-1-8b-to-an-nvidia-llama-3-1-minitron-4b-model/)

## 次のステップ

GPU の選定は、デプロイ時に一度決めたら終わりという固定された選択ではなく、継続的な最適化のプロセスです。量子化（quantization）、プルーニング（pruning）、蒸留（distillation）といった手法を使えば、パフォーマンスを犠牲にすることなくインフラコストを実質的に削減できます。

まずは量子化から始め、即座にモデルのサイズを縮小しましょう。その後、ワークロードが成熟するにつれてプルーニングや蒸留を組み合わせていき、モデルが進化するたびに再評価を行うことで、モバイル、エッジ、組み込みアプリケーションなど幅広い領域で AI の利用範囲を広げる、より小さく高速なモデルを実現できます。

モデル最適化の第一歩として、NVIDIA Model Optimizer [GitHub](https://github.com/NVIDIA/Model-Optimizer) や [Hugging Face](https://huggingface.co/docs/diffusers/en/quantization/modelopt) をチェックしてください。また、Model Optimizer を用いたポストトレーニング量子化の詳細については、[こちらの記事](https://developer.nvidia.com/blog/model-quantization-post-training-quantization-using-nvidia-model-optimizer/) で深掘りしています。