Vertex AI には、生成モデルを使用する際にコンピューティング リソースを取得して使用するためのオプションが複数用意されています。これらの使用量オプションは、初期プロトタイピングから本番環境へのデプロイまで、あらゆるワークロードのニーズを満たすように設計されています。適切なオプションを選択することは、パフォーマンス、信頼性、費用のバランスを取るうえで非常に重要です。
このガイドでは、使用可能な消費オプションについて詳しく説明し、特定のワークロード要件にマッピングする方法と、レイテンシ、可用性、費用を最適化するための戦略について説明します。
使用オプション
Vertex AI には、さまざまなトラフィック パターンとビジネスニーズに合わせて調整された 5 つの消費オプションが用意されています。
| 使用オプション | 説明 | 推奨用途 | 料金 | |
|---|---|---|---|---|
| プロビジョンド スループット | コミットメント期間のスループットを保証する | SLA が必要な、重要で安定した常時稼働のワークロード | コミットメント ベース（1 週間、1 か月、3 か月、1 年のプランで利用可能） | |
| 従量制 | Standard | 前払いのコミットメントなしの柔軟な従量課金制オプション | トラフィック需要の変動に対応できる柔軟性を備えた、日常的なユースケース向けのデフォルト オプション | トークン単位（プレミアム レート） |
| 優先度 | 優先処理により信頼性を高めながら、従量課金制の柔軟性を維持します | 標準の PayGo よりも高い信頼性と上限を必要とする重要なワークロード | トークン単位（標準レート） | |
| フレックス | レイテンシ許容ワークロード向けの費用対効果の高いオプション | 応答時間が遅く、スロットリングが高くても許容できるタスク。料金が安い | トークン単位（割引料金） | |
| バッチ推論 | 大量の非同期処理向けに最適化されたコスト | 結果がより長い期間内に必要な大規模なジョブ | トークン単位（割引料金） | |
料金については、料金ページをご覧ください。
ワークロードに適したオプションを選択する
レイテンシの影響を受けやすいワークロード
組織は、適切な消費モデルを選択する際に、信頼性と費用のバランスを取る必要があります。プロビジョニングされたスループットは信頼性が最も高いですが、トラフィックが急増すると使用率が低下する可能性があります。同様に、PayGo は最大限の柔軟性を提供しますが、サービス品質を保証することはできません。次のセクションでは、これらのメカニズムを最適に組み合わせて最適な結果を得る方法について説明します。
- プロビジョンド スループットでベースライン トラフィックをカバーします。これにより、予約済み容量の使用率が向上し、経済的でありながら、トラフィックのコアの信頼性が保証されます。これを行う手順は以下のとおりです。
- 分単位または秒単位のトラフィック パターンを分析します。
- プロビジョニングされたスループットでカバーするトラフィック量を決定します。優先度の高いトラフィックをカバーする必要があります。
- 標準または優先の PayGo でスピルオーバー トラフィックを管理する: デフォルトでは、プロビジョンド スループットのベースラインを超えるトラフィック（スピルオーバー トラフィック）は、標準の PayGo で処理されます。TPM 上限を超えるリクエストのパフォーマンスの分散が大きい場合は、最適化によって軽減できます。Priority PayGo では、ランプアップの上限を条件として、プレミアム価格で信頼性の高いパフォーマンスを実現できます。
非同期の大規模ワークロード
リクエストのバックログが大きい場合（要約するドキュメントが数百万件ある場合など）、レイテンシがすぐに問題にならない場合は、リクエストを JSON ファイルまたはスプレッドシートに作成して、バッチジョブを送信する必要があります。これは、画像ラベリング、ドキュメントの一括処理、過去のデータに対する感情分析などのユースケースに役立ちます。
このオプションは、大量の推論に最も費用対効果の高いオプションです。
レイテンシ許容型でコスト重視のワークロード
アプリケーションがレスポンスを待つことができ、コスト削減が優先されるリクエスト（データ アノテーションやカタログの作成など）を処理する必要がある場合は、Flex PayGo を使用する必要があります。Flex PayGo では、即時実行を必要としないリクエストに対して、トークンあたりの料金が割引されます。このオプションは、オフライン分析、データ アノテーション、商品カタログの構築、翻訳などのユースケースに役立ちます。
最適化戦略
消費モデルを選択したら、次の戦略を使用して、レイテンシ、可用性、費用をさらに最適化します。
レイテンシ
レイテンシを最適化するには:
- ユースケースに適したモデルを選択する: Vertex AI には、さまざまな機能とパフォーマンス特性を持つさまざまなモデルが用意されています。速度と出力の品質に関する要件を慎重に評価し、ユースケースに最適なモデルを選択します。使用可能なモデルの一覧については、Model Garden をご覧ください。
- プロンプトのサイズを小さくする: 不要な詳細や冗長性のない、意図を効果的に伝える明確で簡潔なプロンプトを作成します。プロンプトを短くすると、最初のトークンまでの時間が短縮されます。
- 出力トークンを制限する:
- システム指示を使用して、レスポンスの長さを制御します。簡潔な回答を提供するようモデルに指示するか、出力の文または段落を特定の数に制限します。この戦略により、最後のトークンまでの時間を短縮できます。
- 上限を設定して出力を制限します。
max_output_tokensパラメータを使用して、生成されるレスポンスの長さに上限を設定し、出力が長くなりすぎないようにします。レイテンシは生成されるトークンの数に比例します。生成されるトークンが少ないほど、レスポンスは速くなります。ただし、文の途中でレスポンスが途切れる可能性があるため、注意が必要です。
- プロビジョンド スループットを使用する: 最も一貫したパフォーマンスを実現するには、プロビジョンド スループットを使用します。これにより、トラフィックが多いときに PayGo モデルで発生する可能性があるコールド スタートやキューイングによる変動を排除できます。
- 思考予算を制限する: 思考をサポートするモデルを使用している場合は、思考予算を減らすことでレイテンシを短縮できます。モデルが回答する前に生成する内部推論トークンを制限することで、処理時間全体を短縮できます。ただし、回答の品質が低下しないように、タスクの複雑さに対応できる十分な予算を確保する必要があります。
対象
可用性を最適化するには:
- 再試行ロジックを実装する: 429 エラーに対して指数バックオフを実装します。特に Standard PayGo を使用する場合は、この処理が必要です。
- ハイブリッド実装を使用する: 前のセクションで説明したように、重要な本番環境アプリで PayGo のみに依存しないでください。プロビジョニングされたスループットと PayGo を組み合わせることで、リソースの枯渇（429 エラー）に対する保証が最大になります。
- プロビジョニングされたスループットの割り当てを管理する: TPM の使用量を定期的にモニタリングし、トラフィックが急増するイベント（プロダクトのリリースなど）の前に PT GSU を増やします。アラート ポリシーを使用して、モニタリングを自動化できます。
- グローバル エンドポイントを使用する: グローバル エンドポイントを使用して、Google のグローバル容量プールを活用し、リージョン容量の制約によるスロットリングを最小限に抑えます。
- 可能な限りトラフィックを平滑化してスパイクを減らす: PayGo トラフィック レート（TPM）が高いほど、スロットリング レートが高くなる傾向があります。
- トラフィックをオフピーク時にシフトする: モデルの使用量は、一般的に日周パターンに従います。ワークロードをオフピーク時や週末にタイムシフトすると、可用性を大幅に向上させることができます。
費用
費用を最適化するには:
- プロビジョニングされたスループットのサイズを適正化する: 通常、ピーク時に PT をプロビジョニングする必要はありません。ピーク時に PT をプロビジョニングすると、PT の全体的な使用率が低下し、総費用が増加します。リスク許容度に応じてトラフィックの特定のパーセンタイルを目標とし、残りのトラフィックは Standard PayGo と Priority PayGo に処理させます。
- 長期のプロビジョニングされたスループットを購入する: 1 年間の PT の料金は 1 か月間の PT の 26% 割引で、大幅なコスト削減につながります。購入したプロビジョンド スループット GSU は、常に異なるモデル間で切り替えて、最新のモデル機能を利用できます。
- Flex PayGo を使用する: レイテンシの影響を受けないパイプラインの一部（バックグラウンドの要約、データ抽出など）を特定し、Flex に移動して費用を約 50% 削減します。
- バッチ処理を使用する: 大規模なデータセットの処理などの非同期ジョブの場合、バッチ処理は、Standard PayGo を使用してリクエストを順番に処理するよりも大幅に安価（50%）です。
- コンテキスト キャッシュ保存を使用する: コンテキスト キャッシュ保存は、繰り返されるコンテンツを含むリクエストの費用とレイテンシを削減するのに役立ちます。大規模で一般的なコンテンツをプロンプトの先頭に配置し、類似した接頭辞を含むリクエストを短時間で送信することで、キャッシュ ヒット率を高めます。
- 低価格のモデルを選択する: ユースケースで許容できる場合は、Flash-Lite などの小規模なモデルを使用します。これらのモデルは、高機能のフル機能モデルよりもトークンあたりの価格が低くなっています。