バッチ API: 緊急でないジョブは 50% オフ

バッチ API とは

バッチ API を使用すると、リアルタイムで一度に 1 つずつではなく、多数のリクエストを 1 つのジョブとして一度に送信できます。すべてのプロンプトを含むファイルをアップロードすると、プロバイダーがプロンプトを一定期間にわたって非同期に処理し、準備ができたら結果をダウンロードします。

あなたが行っている取引は簡単です: 速度を放棄して価格を安くする。数秒で応答が得られるのではなく、数分から数時間かかる場合があります。その代わりに、トークンごとのコストは通常​​、標準の同期レートと比較して約半分に削減されます。

プロバイダーが割引を提供できる理由

リアルタイム API トラフィックは急増しており、予測できません。プロバイダーは需要のピークに備えて予備のキャパシティを確保しておく必要があり、そのアイドル状態のヘッドルームは高価です。バッチ ジョブは柔軟性があり、空き容量があるときはいつでも実行できるため、負荷が軽減されます。

プロバイダーが静かな時間帯に作業をスケジュールできるようにすることで、プロバイダーはハードウェアをより効率的に使用し、その節約の一部をユーザーに還元することができます。割引は低品質のモデルではなく、まったく同じモデルをゆったりとしたスケジュールで実行するものです。

ワークフローの様子

一般的なバッチ フローには 4 つのステップがあります。

• ファイルを準備する ここで、各行は 1 つのリクエストであり、通常はカスタム ID を持つ構造化形式になっており、結果を入力と照合できます。
• バッチを送信する そしてジョブIDを受け取ります。
• ステータスをポーリングする 一方、プロバイダーはキューを処理し、多くの場合、24 時間以内などの完了目標が指定されています。
• 出力ファイルを取得する 完了したら、ID を使用して各結果をリクエストにマッピングします。

アプリケーションのロジックはほとんど変更されず、同じプロンプトと同じモデルが使用されます。変化するのは、応答ごとにブロックしないことです。

どのジョブがバッチ モデルに適合するか

人間が答えを待っていない場合には、バッチが理想的です。

• 一括分類またはタグ付け 大規模なデータセット。
• コンテンツの生成 事前に作成されたカタログ、製品説明、概要など。
• データ抽出 大規模な文書コレクションから。
• 評価とバックテスト ここでは、何千ものテスト ケースにわたってプロンプトを実行します。
• 埋め込み コーパス全体を一度に生成します。

これは、チャットボット、ライブ検索、またはユーザーがローディング スピナーを見つめる機能など、インタラクティブなものにはあまり適していません。

待つことの経済学

節約の理由は簡単です。ジョブの標準料金で 200 ドルの費用がかかり、バッチ割引が 50% である場合、同一の出力に対して、代わりに 100 ドルの費用がかかります。毎月変動する大規模な繰り返しワークロード。

ここでは、具体的なレートを示した実際の例を示しているので、計算は具体的です。それぞれ 500 の入力トークンと 20 の出力トークンで 100 万の短いドキュメントを分類すると、合計で 5 億の入力トークンと 2,000 万の出力トークンになります。 100 万の入力トークンあたり 0.15 ドル、100 万の出力トークンあたり 0.60 ドルの例示的な料金では、ジョブ全体の同期価格設定は約 75 ドル + 12 ドル = 87 ドルとなります。同じジョブをバッチ エンドポイント経由で半額で実行すると、その額は約 43.50 ドルに下がります。つまり、翌月の実行を数える前に、1 回の実行で 43.50 ドルの節約になります。 LLM コスト計算ツールを使用すると、独自のトークン数と量を入力し、合計を半分にして、現在のプロバイダー レートを使用したリアルタイムのシナリオと比較してバッチ シナリオをプレビューできます。

注意すべきこと

実用的な注意点がいくつかあります。完了時間は目標であり、保証ではないため、変動する遅延を許容できるようにパイプラインを構築してください。非常に大きなバッチにはサイズまたはレート制限が適用される場合があるため、巨大なジョブをいくつかのチャンクに分割する必要がある場合があります。また、入力トークンと出力トークンの両方の料金を支払う必要があり、割引はトークン数ではなくレートに適用されるため、迅速な効率性が依然として重要です。

バッチ内で失敗したリクエストには通常、料金は請求されません。 入力ファイル内の 1 行が不正な形式であるか、単一のリクエストでエラーが発生した場合、プロバイダーは通常、失敗したリクエストではなく、実際に完了したリクエストに対してのみ料金を請求します。つまり、少数の不良行によって残りのジョブの割引が損なわれることはありませんが、どのリクエストを再送信する必要があるかを確認するために、出力ファイルを入力 ID と照合してチェックする必要があることも意味します。

最後に、/models ページで各プロバイダーの詳細を確認してください。正確な割引、納期目標、サポートされる機能 (キャッシュやツールがバッチ内で動作するかどうかなど) はプロバイダーによって異なるためです。

学び続ける

関連ツール

よくある質問

バッチ API は弱いモデルですか?

いいえ。リアルタイム API と同じモデルと同じ品質の出力が得られます。唯一の違いは結果が届くのが遅く、そのため価格が安くなることです。

バッチジョブにはどれくらい時間がかかりますか?

プロバイダーは通常、24 時間以内などの完了目標を示しており、キャパシティーが利用可能な場合、多くのジョブははるかに早く終了します。即時ではないため、誰も答えを待っていない場合にのみ使用してください。

バッチ API は通常どのくらい節約できますか?

標準のトークンごとのレートの約 50% 割引は、主要プロバイダーでは共通であり、入力トークンと出力トークンの両方に適用されます。特定のプロバイダーとモデルの現在の割引を常に確認してください。

バッチ内で失敗したリクエストに対して料金を支払う必要がありますか?

一般的にはノーです。通常、プロバイダーは実際に正常に完了したバッチ内のリクエストに対してのみ請求するため、不正なプロンプトや偶発的なエラーによって残りのジョブの割引が適用されることはありません。送信した ID と出力ファイルを照合して、どのリクエストが失敗したかを確認し、再送信する必要があります。