生成AIの推論GPUを勘で選ばない

生成AIモデルを自前で配備するとき、GPUの価格表だけを見て構成を決めると、安いのに遅い、速いのに使われない、想定した同時接続で急に詰まるといった問題が起きます。

AWSはAmazon SageMaker AIで、モデルと想定ワークロードを渡すと、複数の推論構成を実GPUで比較し、配備可能な推奨構成を返す仕組みを案内しています。この記事では公式ドキュメントを確認し、実行前に何を決めるべきかを具体的な運用手順へ落とし込みます。

先に結論

GPUを選ぶ前に、次の順番を守ります。

1. 実際の入力・出力トークン量と同時接続数を定義する

2. コスト、初回トークン時間、処理量のうち、優先する目標を1つ決める

3. 比較するインスタンスを最大3種類まで絞る

4. 実トラフィックに近い負荷でベンチマークする

5. 平均値ではなくP90・P99と1リクエスト当たりの費用で判断する

最も重要なのは、先にGPUを選ばないことです。モデル名が同じでも、入力長、出力長、同時実行数、応答速度の目標が変われば、適切な構成も変わります。

AWS公式資料で確認できたこと

AWS公式ドキュメントによると、生成AI向けの推論推奨機能は、モデルの構造とワークロード条件を分析し、複数のGPU構成を実際の基盤上でベンチマークします。結果には、初回トークンまでの時間を示すTTFT、トークン間遅延、P50・P90・P99のリクエスト遅延、トークン処理量、構成ごとの費用が含まれます。

準備するものは、Hugging Face形式のSafeTensorを含むS3上のモデル、結果を書き出すS3バケット、モデルと出力先へアクセスできるIAM実行ロールです。ワークロードには入力・出力トークンの分布と同時接続数を設定し、最適化目標はコスト、低遅延、高スループットから1つ選びます。

比較するインスタンスは最大3種類に制限できます。また、許可した場合は投機的デコーディングやカーネル調整などの最適化も候補へ含まれます。結果の構成にはコンテナイメージ、インスタンスタイプ、台数、環境変数が含まれ、そのまま配備判断へ使える設計です。

この機能自体の追加料金はないと説明されていますが、ベンチマーク中に使う計算資源には通常の費用が発生します。東京リージョンも対応地域に含まれます。

今回実際に試したこと

今回はAWSアカウント上で有料の推奨ジョブを開始していません。代わりに、公式のBoto3例に合わせたダミー構成を作り、秘密値や実在ARNを入れずにJSONとして読み込めること、実行前に必要な項目が揃っていることをローカルで確認しました。

確認した項目は次の6つです。

ジョブ名
モデルを置くS3 URI
結果を保存するS3 URI
TTFTなどの性能目標
ワークロード構成ID
最小権限のIAMロールARN

さらに比較対象を3種類までに絞る欄を追加し、最適化を有効にするかを明示しました。サンプルは公開用のダミー値だけで、認証情報や実環境の識別子は含めていません。

“`json

{

“AIRecommendationJobName”: “dry-run-example”,

“ModelSource”: {

“S3”: {“S3Uri”: “s3://DOC-EXAMPLE-BUCKET/models/my-model/”}

“OutputConfig”: {

“S3OutputLocation”: “s3://DOC-EXAMPLE-BUCKET/recommendations/”

“PerformanceTarget”: {

“Constraints”: [{“Metric”: “ttft-ms”}]

“ComputeSpec”: {

“InstanceTypes”: [“ml.g5.12xlarge”, “ml.p4d.24xlarge”]

“OptimizeModel”: true,

“AIWorkloadConfigIdentifier”: “dry-run-workload”,

“RoleArn”: “arn:aws:iam::111122223333:role/ExampleRole”

}

“`

ローカルではPowerShellの`ConvertFrom-Json`で読み込み、インスタンス候補が3件以下であること、性能目標が1つだけであることを確認しました。これはAPI通信や性能測定ではなく、課金前の入力チェックです。

1. 代表的なワークロードを先に作る

ベンチマークへ渡すリクエストが短文だけでは、長文要約やコード生成の実態を再現できません。直近のログから、個人情報と秘密値を除いた代表サンプルを作ります。

最低でも次の3群に分けます。

| 群 | 入力の例 | 確認すること |

|—|—|—|

| 短い対話 | 質問、分類、抽出 | TTFTと同時接続 |

| 長文入力 | 要約、検索結果の整理 | 入力長による遅延 |

| 長文出力 | コード、記事、報告書 | トークン処理量と費用 |

平均的なリクエストだけでなく、上位10%の長い入力と出力も含めます。急増時の同時接続数も別に用意し、通常時とピーク時を混ぜないことが重要です。

2. 目標を1つに絞る

コスト、低遅延、高スループットを同時に最適化しようとすると、結果を選べません。まず利用者にとって譲れない指標を1つ決めます。

対話UIならTTFTを優先する
バッチ処理なら1時間当たりの処理量を優先する
利用頻度が低い社内ツールなら費用を優先する

残りの指標は合否条件にします。たとえば「TTFTを最小化する。ただし月額試算は上限以内、P99は5秒以内」のように分けます。

指標の整理方法はAI導入効果、まず測るべき4指標にもまとめています。

3. 平均値ではなく裾を見る

平均レイテンシが良くても、P99が大きいと一部の利用者だけが長く待ちます。推奨結果では、TTFT、P90・P99、トークン毎秒、費用を同じ表へ並べます。

判断表には次を記録します。

| 指標 | 採用前の基準 |

|—|—|

| TTFT | 対話開始まで許容できる時間以内か |

| P90・P99 | 混雑時でもタイムアウトしないか |

| 出力トークン/秒 | 長文生成が実用時間内に終わるか |

| 1リクエスト費用 | 月間件数を掛けても予算内か |

| エラー率 | 負荷上昇時に失敗が増えないか |

遅延の観測箇所はAIエージェントが遅い時に見る5項目も参考になります。

4. 更新のたびに再測定する

一度選んだGPU構成を固定しません。モデル、コンテナ、推論ライブラリ、入力長、同時接続数のどれかが変わったら再測定します。

特に、量子化、投機的デコーディング、vLLMなどの推論基盤変更は、速度だけでなくメモリ使用量と応答品質も確認します。推奨構成が出ても、既存の評価セットで出力差分を確認してから本番へ進めます。

GPU追加前に測る指標はAI計算コスト、GPU追加前に測る3指標と合わせて確認してください。

今日できる3つの作業

1. 直近ログから短文、長文入力、長文出力の代表サンプルを各10件選ぶ

2. コスト、TTFT、処理量から最優先の目標を1つ決める

3. 比較するGPU候補を3種類以内に絞り、P90・P99と費用の合格条件を書く

ここまで決めてから推奨ジョブを開始すれば、結果を見た後に都合の良い指標へ変更することを防げます。最初は小さいサンプルと短い実行時間で入力を検証し、条件が正しいと確認してから本番規模へ広げます。

まとめ

生成AIの推論構成は、GPUの型番や時間単価だけでは決められません。実際の入力・出力長、同時接続、優先目標を定義し、実負荷に近いベンチマークで比較する必要があります。

SageMaker AIの推論推奨機能は、その比較を実GPU上で行い、配備可能な構成と性能指標を返します。ただし、入力条件と採用基準を決めるのは運用側です。まず代表ワークロードと合格条件を作り、勘ではなく測定結果で選んでください。

著者情報

しろのあ。AIとCodexを使ったWordPress、note、アプリ制作、ゲームサーバー運用の自動化を実践し、確認できた手順と判断材料を記録しています。

出典

1. LLM optimization integration for Amazon SageMaker Python SDK / AWS Machine Learning Blog

2. Optimized generative AI inference recommendations / AWS Documentation

3. Get generative AI inference deployment recommendations / AWS Documentation