Gemini を使用したバッチ予測

Gemini のバッチ予測機能を使用すると、大規模なデータ処理のニーズに対応する非同期、高スループット、費用対効果の高い推論を実現できます。このガイドでは、バッチ予測の価値、仕組み、制限事項、最適な結果を得るためのベスト プラクティスについて説明します。

バッチ予測を使用する理由

現実のシナリオでは、言語モデルからの即時応答は必要ないことが多くあります。代わりに、効率的かつ費用対効果の高い方法で処理する必要があるプロンプトの大きなデータセットがあるかもしれません。バッチ予測が威力を発揮するのは、このような場合です。

主なメリットは次のとおりです。

  • 費用対効果: バッチ処理は、リアルタイム推論と比較して 50% 割引された料金で提供されるため、大規模で緊急性のないタスクに最適です。
  • 高いレート制限: リアルタイムの Gemini API よりも高いレート制限で、1 回のバッチで数十万件のリクエストを処理します。
  • ワークフローの簡素化: 個々のリアルタイム リクエストの複雑なパイプラインを管理する代わりに、単一のバッチジョブを送信し、処理が完了したら結果を取得できます。このサービスは、形式の検証、同時処理のためのリクエストの並列化、自動再試行を行い、24 時間の処理時間で高い完了率を目指します。

バッチ予測は、次のような大規模な処理タスク用に最適化されています。

  • コンテンツ生成: 商品説明、ソーシャル メディア投稿、その他のクリエイティブなテキストを一括で生成します。
  • データのアノテーションと分類: ユーザー レビューの分類、ドキュメントの分類、大規模なテキスト コーパスに対する感情分析を行います。
  • オフライン分析: 記事の要約、レポートからの重要な情報の抽出、ドキュメントの翻訳を大規模に行います。

バッチ予測をサポートする Gemini モデル

次のベースモデルとチューニング済み Gemini モデルはバッチ予測をサポートしています。

割り当てと上限

バッチ予測は強力ですが、次の制限事項に注意することが重要です。

  • 割り当て: 使用量に事前定義された割り当て上限はありません。バッチサービスは、リソースの可用性と、そのモデルに対するすべてのお客様のリアルタイムの需要に基づいて動的に割り当てられる、大規模な共有リソースプールへのアクセスを提供します。アクティブなユーザーが増え、容量が飽和状態になると、バッチ リクエストが容量不足のためにキューに登録されることがあります。
  • キュー時間: サービスでトラフィックが多い場合、バッチジョブは容量のキューに入ります。ジョブは、有効期限が切れるまで最大 72 時間キューに登録されます。
  • リクエストの上限: 1 つのバッチジョブに含めることができるリクエストは最大 200,000 件です。Cloud Storage を入力として使用する場合、ファイルサイズの上限は 1 GB です。
  • 処理時間: バッチジョブは非同期で処理され、リアルタイム アプリケーション向けに設計されていません。ほとんどのジョブは、実行開始後 24 時間以内に完了します（キュー時間は含まれません）。24 時間が経過すると、未完了のジョブはキャンセルされ、完了したリクエストに対してのみ課金されます。
  • サポートされていない機能: バッチ予測は、コンテキスト キャッシュ保存、RAG、グローバル エンドポイントをサポートしていません。

ベスト プラクティス

Gemini でバッチ予測を最大限に活用するには、次のベスト プラクティスをおすすめします。

  • ジョブを結合する: スループットを最大化するには、システムの上限内で、小さなジョブを 1 つの大きなジョブに結合します。たとえば、20 万件のリクエストを含む 1 つのバッチジョブを送信すると、それぞれ 200 件のリクエストを含む 1,000 個のジョブよりもスループットが向上します。
  • ジョブのステータスをモニタリングする: API、SDK、UI を使用してジョブの進行状況をモニタリングできます。詳細については、ジョブのステータスをモニタリングするをご覧ください。ジョブが失敗した場合は、エラー メッセージを確認して問題を診断し、トラブルシューティングします。
  • コストを最適化する: 即時のレスポンスを必要としないタスクについては、バッチ処理によるコスト削減を活用します。

次のステップ