費用とパフォーマンスの最適なバランスを見つける方法

※この投稿は米国時間 2026 年 4 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud のお客様の多くは、「アプリケーションに求められるパフォーマンスと可用性を犠牲にすることなく、生成 AI の費用を効果的に管理するにはどうすればよいか」という課題に直面しています。

これは、賞金 100 万ドルレベルの難問、あるいはより正確には「1 分あたりのトークン数」の問題です。重要なのは、単に最も安価なオプションを選択することではなく、ワークロードのパターンに合ったツールとサービスの適切な組み合わせを見つけることです。

このガイドでは、Google Cloud の柔軟な生成 AI インフラストラクチャ オプションについて説明し、費用とパフォーマンスの効率的フロンティアで最適なバランスを見つける方法を紹介します。まず、基本となる従量課金制（PayGo）モデルから始め、より専門的なオプションを重ねて、堅牢で費用対効果の高い生成 AI 戦略を構築する方法を検討します。

基礎を理解する: 従量課金制（PayGo）オプション

多くのワークロードでは、Google Cloud の Standard PayGo サービスが強力で柔軟な出発点となります。これらのサービスを最大限に活用するには、パフォーマンスと可用性を左右するメカニズムを理解することが不可欠です。

1. 動的共有割り当て（DSQ）

Standard PayGo の環境は、動的共有割り当て（DSQ）と呼ばれる公平性と効率性の原則に基づいて運用されています。DSQ は、お客様ごとに厳格な制限を設けるのではなく、利用可能な生成 AI の容量をすべてのお客様にインテリジェントに分配します。

その仕組みは次のとおりです。

• 高優先度レーン: 組織には、1 秒あたりのトークン数（TPS）に対してデフォルトのしきい値があります。このしきい値内に収まる送信リクエストは優先度が高くなります。このレーンは、99.5% の SLO を目標に、高可用性を提供するように設計されています。

• ベスト エフォート レーン: トラフィックが急増して TPS のしきい値を超えた場合、超過したリクエストはすぐにドロップされません。これらのリクエストは低い優先度で処理され、空き容量がある場合にスループットが割り当てられます。

このシステムは、1 社のお客様からのトラフィックの急増が、他社のベースライン パフォーマンスに悪影響を及ぼさないように設計されています。日常的なニーズに対して信頼できるレベルのサービスが提供され、システムに空き容量がある場合はバーストの可能性もあります。

2. 使用量ティア: 投資に対する報酬

生成 AI の使用量の増加に伴い、より予測可能なパフォーマンスを提供するために、Google Cloud は対象となる Vertex AI サービスの 30 日間のローリング支出に基づいて、組織を自動的に使用量ティアに配置します。ティアが高いほど、保証される 1 分あたりのトークン数（TPM）の上限が高くなります。

この記事の執筆時点では、一般的なモデル ファミリーのティアは次のとおりです。

重要: 最新のモデルとしきい値については、常にドキュメントを参照してください。

重要な点として、ティアの上限は、最高限度ではなく最低限度として考えます。

• 重要なトラフィック: 組織のティアの上限までのトラフィックが保護されます。このベースラインの範囲内であれば、429（リソース不足）エラーは最小限に抑えられます。

• 日和見的バースト: ティアの上限を超えても、ベスト エフォートでシステムの空き容量を利用するバーストが可能です。システム全体に大きな負荷がかかっている場合、この超過トラフィックに対してフェアシェア スロットリングが適用されます。重要なポイントは、アイドル状態の容量がある場合、パフォーマンスが人為的に制限されることはないということです。

3. Priority PayGo: トラフィック急増に対する保険

ワークロードで予測不能なトラフィック急増が発生しやすく、429 エラーのリスクを負うことはできないが、固定容量モデルにコミットする準備ができていない場合はどうすればよいでしょうか。このような場合に役立つのが Priority PayGo です。Priority PayGo は、PayGo の柔軟性と、重要なトラフィックに必要な高可用性を併せ持つように設計されています。

プレミアム料金を支払うことで、特定の API リクエストにタグを付けて優先度を上げることができます。

重要: 現在、Priority PayGo 機能はグローバル エンドポイントでのみご利用いただけます。リージョン エンドポイントでもリリースの可能性はありますが、保証されるものではありません。

Priority PayGo の使用方法: API 呼び出しにヘッダーを追加するだけです。登録やコミットメントは不要です。

引き上げの際は上限に注意してください。以下の画像に示すように、優先リクエストを急激に増やすと、容量が制約されている場合に一部のリクエストが標準の優先度にダウングレードされる可能性があります。より緩やかなペースで段階的に増やすことで、最適なエクスペリエンスを確保し、ダウングレードを軽減できます。

次に例を示します。

Priority PayGo を使用したリクエストは、こちらのドキュメントに沿ってモニタリングできます。

妥協を許さないワークロード向け: プロビジョンド スループット（PT）

生成 AI のワークロードがビジネスに不可欠であり、明示的な可用性の保証が必要な場合は、PT を検討します。

PT では、モデル処理容量の特定量を固定の月額料金で予約します。可用性の SLA を確保するには、この方法しかありません。Standard PayGo モデルには、稼働時間の SLA（モデルが稼働している）がありますが、PT には可用性の SLA（リクエストが処理される）があります。

「エラー率」の定義について、もう少し詳しく見てみましょう。エラー率とは、HTTP ステータス 5XX とコードの「内部エラー」で応答した有効なリクエスト数を、その期間中の有効なリクエストの合計数で割った値です。ただし、測定期間中の有効なリクエストの合計数が 2,000 件未満の場合は対象外となります。

Standard PayGo では、「リソース不足」の場合に 429 が返され、その呼び出しはエラー率にカウントされませんが、標準のプロビジョンド スループットでは、使用量が購入量よりも少ない場合、通常なら 429 になるエラーが 5XX として返され、SLA のエラー率にカウントされます。これが、PT と PayGo の SLA の違いとなります。

このため、プロビジョンド スループットは、以下のような場合に最適です。

• 大規模で予測可能な本番環境ワークロード。

• スロットリングが許されない、厳しいパフォーマンス要件があるアプリケーション。

PT リクエストのきめ細かい制御

デフォルトでは、PT の注文量を超える使用量は自動的に PayGo に移行します。ただし、HTTP ヘッダーを使用してリクエスト レベルでこの動作を制御できます。

超過を防止する: PT のコミットメントを超過しないようにし、超過リクエストを拒否するには、専用ヘッダーを追加します。これは、予算を厳格に管理する場合に便利です。

オンデマンドで PT をバイパスする: PT の注文があるにもかかわらず、意図的に優先度の低いリクエストを PayGo プールに送信するには、共有ヘッダーを使用します。これは、予約済み容量を消費せずに、重要度の低いジョブをテストしたり、実行したりするのに最適です。

支出のモニタリング

Cloud Monitoring で aiplatform.googleapis.com/PublisherModel リソースの指標を使用すると、プロビジョンド スループットの使用状況を綿密にモニタリングできます。主な指標は次のとおりです。

• /dedicated_gsu_limit: 生成スケール ユニット数（GSU）で表した専用の上限。

• /consumed_token_throughput: モデルのバーンダウン率を考慮した、実際のスループット使用量。

• /dedicated_token_limit: 1 秒あたりのトークン数で表した専用の上限。

これにより、支払った金額に見合う価値を得られているかを確認し、時間の経過とともにコミットメントを適正な規模に調整できます。Vertex AI での PT について詳しくは、こちらのガイドをご覧ください。

最適な結果を得るためのオプションの組み合わせ

1 日のベースラインが予測可能で、いくつかのピークが予想され、予期しない急増が時折発生するワークロードを考えてみましょう。最適な組み合わせは次のようになります。

• プロビジョンド スループット: 予測可能なミッション クリティカルなベースロードをカバーします。これにより、アプリケーションのコアの可用性 SLA を確保できます。

• Priority PayGo: PT のコミットメントを超える予測可能なピークへの対応や、頻度が低い重要なトラフィックに使用します。これは、特に重要な変動トラフィックで 429 エラーに対する費用対効果の高い保険として機能します。

• Standard PayGo（ティアの上限内）: 組織の使用量ティアに余裕をもって収まる、重要度の低い一般的なトラフィックの基盤となります。

• Standard PayGo（日和見的バースト）: 重要度が低く、レイテンシの影響を受けにくいジョブ（バッチ処理など）の場合は、Standard PayGo モデルのベスト エフォート バーストを利用できます。これらのリクエストの一部がスロットリングされても、コア ユーザー エクスペリエンスに影響はなく、プレミアム料金も発生しません。

これらの強力なツールを理解して組み合わせることで、単に費用を管理するだけでなく、生成 AI 戦略を真に最適化し、パフォーマンス、可用性、価値の完璧なバランスを実現できます。

追加ボーナス: Batch API と Flex PayGo

最初に Batch API を紹介します。すべての LLM リクエストで、最初のトークンまでの時間（TTFT）が 1 秒未満である必要はありません。ユーザーがカスタマー サービスの bot とチャットしている場合、低レイテンシは不可欠です。しかし、前月の数百万件のサポート チケットを分類したり、評価を実行したり、1 日のサマリー レポートを生成したりする場合、リアルタイム ストリームを画面の前で待っている人はいません。このような場合に Gemini Batch API が役立ちます。お客様は、大量のリクエスト ペイロードを 1 つのファイルにまとめて非同期で送信できます。インフラストラクチャは、オフピークの時間帯やアイドル状態のコンピューティング容量が利用可能なときに、これらのワークロードを処理します。目標の所要時間は 24 時間ですが、実際には通常、はるかに短時間で完了します。即時実行を非同期処理に置き換えることで、標準のトークン費用が 50% 割引になります。

Batch API がオフラインの重い処理を担う一方で、ライブアプリにはリアルタイムの計算が必要です。しかし、すべてのリクエストがレイテンシ重視ではありません。お客様は、標準のトークン費用が割引になるならば、少し長く待つことを受け入れるかもしれません。Flex PayGo は、Gemini モデルにアクセスするための費用対効果に優れた方法で、Standard PayGo と比較して 50% の割引が適用されます。最大 30 分の応答時間も許容できる重要度の低いワークロード向けに最適化されており、コードの変更を最小限に抑えながら、プロビジョンド スループット（PT）、Standard PayGo、Flex PayGo の間をシームレスに移行できます。最適なユースケースは次のとおりです。

• テキスト ファイルとマルチモーダル ファイルのオフライン分析。

• モデルの品質評価とベンチマーク。

• データのアノテーションとラベル付け。

• 商品カタログの自動生成。

使ってみる

1. Vertex AI のモデルを確認する: Model Garden で、Google の幅広いファーストパーティ モデルと、100 以上のオープンソース モデルを確認できます。

2. ドキュメントで詳細を確認する: 最新の技術的な詳細、しきい値、コードサンプルについては、公式の Vertex AI ドキュメントをご覧ください。

3. 料金の詳細を確認する: Vertex AI の料金ページで、トークンの費用、プロビジョンド スループットの料金、Batch API と Flex API の最新の割引の詳細を確認できます。

- Google Cloud、テクニカル アカウント マネージャー、Federico Vibrati

- Google Cloud、データおよび AI アーキテクト、Federico Preli