操作を中断せずにバッチ処理を使用して LLM API コストを削減する方法
SLA 境界、再試行、冪等性、調整、コスト帰属を維持しながら、対象となる LLM ワークロードを同期リクエストからバッチ処理に移行するための実践的なガイドです。
すべてのリクエストが同じ同期パスを通過するため、多くのチームは LLM ワークロードに対して過剰な料金を支払います。これは、チャット、エージェント ループ、ユーザー対応のアクション、およびすぐに回答が必要な意思決定に適したパターンです。これは通常、評価、ドキュメントの強化、分類のバックフィル、埋め込みの更新、夜間の品質チェック、コンプライアンス スキャン、および待機できるレポート ジョブの間違ったパターンです。
難しいのは、一括割引が魅力的かどうかを判断することではありません。難しいのは、運用制御を失わずに作業を非同期処理に移行することです。バッチ処理はシステムの形を変えます。リクエストはジョブになり、障害は後で到着し、結果は部分的になる可能性があり、コストの帰属は即時応答のメタデータではなく調整に依存します。
このガイドでは事実、推奨事項、予測を分離して、チームがバッチ処理を同期 API の普遍的な代替品として扱うことなく、実際的な実装の決定を下せるようにします。
LLM バッチ API についての事実
いくつかの主要なモデルプロバイダーは、大量の非同期作業用のバッチ API を提供するようになりました。具体的な形式と制限は異なりますが、商用パターンは似ています。多くのリクエストを送信し、非同期処理を待機し、後で結果を取得します。
- 事実: OpenAI には、24 時間以内に完了が返され、50% 割引が適用される大規模な非同期バッチのバッチ API が文書化されています。サポートされているエンドポイントには、応答、チャット完了、埋め込み、完了、モデレーションが含まれており、JSONL 入力ファイルがアップロードされて処理されます。
- 事実: Anthropic 文書化された大量の非同期メッセージ リクエストのメッセージ バッチにより、コストが 50% 削減され、スループットが向上します。そのドキュメントには、ほとんどのバッチは 1 時間未満で終了し、このパターンは即時の応答が必要ない場合に適していると記載されています。
- 事実: Anthropic には、バッチ エンドポイントの制限や同時に処理キューに入れることができるバッチ リクエストの数など、メッセージ バッチの個別のレート制限動作についても文書化されています。
- 事実: Google には、標準コストの 50% で大量の非同期リクエストを処理するための Gemini バッチ API が記載されており、その価格設定ドキュメントには、50% のコスト削減機能としてバッチ API が記載されています。
- 事実: Amazon Bedrock モデルの呼び出しログは、サポートされているランタイム呼び出しのリクエスト データ、応答データ、メタデータを収集し、CloudWatch Logs に配信できます。および/またはS3。ログに記録されるフィールドには、requestId、operation、modelId、requestMetadata、入力トークン数、出力トークン数を含めることができ、これらは調整に役立ちます。
これらの事実は、明確な推奨事項を裏付けています。つまり、ワークロードが完了の遅延を許容でき、単位コストの低いビジネス価値が非同期実行の運用の複雑さを上回る場合には、バッチ処理を使用してください。
プロバイダーから始めないでください。 API
実装でよくある間違いは、アプリケーション コードをプロバイダのバッチ ファイル形式またはステータス モデルに直接バインドすることです。これはプロトタイプでは機能しますが、チームが 2 番目のプロバイダーを追加したり、モデルを変更したり、同期トラフィックと非同期トラフィック全体で一貫したレポートを必要としたりする場合には、回避可能な移行コストが発生します。
より良い開始点は、内部バッチジョブの抽象化です。複雑にする必要はありませんが、プロバイダーに関係なくプラットフォームに必要な操作フィールドを正規化する必要があります。
バッチ ジョブの最小フィールド
- job_id: バッチ ジョブの内部識別子。
- provider: のために選択されたプロバイダー実行。
- provider_batch_id: 送信された外部バッチ ID。
- workflow: eval_run、embedding_refresh、doc_enrichment、qa_scan などのビジネス ワークフロー。
- team_id またはcustomer_id: 割り当て、レポート、コスト割り当てに対する責任のある所有者。
- model: 要求されたモデルまたはモデル ポリシー。
- endpoint: プロバイダのエンドポイント タイプ（チャット、応答、埋め込み、モデレーション、メッセージ。
- submitted_at および deadline_at: SLA 処理に必要なタイムスタンプ。
- status: キューに入っている、送信済み、処理中、完了、completed_with_errors、失敗、キャンセル、期限切れなどの正規化された状態。
- input_uriおよび result_uri: 永続的な入力および出力アーティファクトへのポインター。
- item_count、success_count、failure_count: ジョブレベル調整の合計。
- input_tokens および output_tokens: 以降の使用を実現処理。
- estimated_cost および realized_cost: 送信時の見積もりと調整後のコスト。
- cost_basis: バッチ割引が適用されたかどうかを含む、使用された価格設定ルール。
この抽象化により、組織の残りの部分に 1 つの契約が与えられます。プロバイダ固有のフィールドは引き続きデバッグ用に保存できますが、すべてのアプリケーション チームが学習する必要があるインターフェイスになるべきではありません。
ルーティング前に SLA によってワークロードを分類する
バッチ処理は、支出を削減したいという包括的な願望によってではなく、サービス レベルの期待によって推進されるべきです。シンプルなルーティング ポリシーは、賢いルーティング ポリシーよりも操作が簡単です。
インタラクティブ クラス
インタラクティブなリクエストは、ユーザー向けまたは時間に依存します。例としては、チャット UX、ツール呼び出しを必要とするエージェント ループ、オペレーターが待機しているサポート ワークフロー、詐欺または支払いの決定、部分的な出力の遅延が出力がないよりも悪いワークフローなどがあります。これらは、製品がユーザー エクスペリエンスを明示的に変更しない限り、同期を維持する必要があります。
遅延クラス
遅延ワークフローは、ユーザーやビジネス プロセスに悪影響を与えることなく待機できます。例には、オフライン評価、ドキュメントのタグ付け、分類バックフィル、埋め込み更新、履歴管理、夜間の QA チェック、レポート生成などがあります。これらはプロバイダ バッチ API の最適な候補です。
境界クラス
一部のワークロードは完全にインタラクティブではありませんが、それでも期限があります。たとえば、顧客がインポートしたドキュメントは、すぐではなく 20 分以内にエンリッチメントが必要になる場合があります。これらには、期限付きの内部キューを使用します。ジョブが期限近くになっても保留中の場合は、ポリシーに従って同期処理に移行したり、キャンセルしたり、再ルーティングしたりすることができます。
ここで、AI API コスト管理 が価格設定の問題ではなくインフラストラクチャの問題になります。システムには、ルーティング ポリシー、期限の認識、アカウンティング、オブザーバビリティが同じ場所に必要です。
すべてのアイテムに安定したリクエスト ID を使用します
バッチ ジョブは、同期呼び出しよりもさまざまな方法で失敗します。プロバイダーがファイルを拒否する場合があります。ジョブは項目レベルのエラーで完了する場合があります。再試行すると、部分的に成功した作業が再送信される場合があります。一部の結果を書き込んだ後、ジョブを完了としてマークする前に、取り込みプロセスがクラッシュする可能性があります。
最も重要な保護は、各アイテムの安定したリクエスト キーです。このキーは、送信時にランダムに生成されるのではなく、独自のデータから決定的である必要があります。
たとえば、ドキュメント エンリッチメント リクエスト キーは次のようになります。
doc_enrichment:v3:customer_812:document_9912:section_04:model_policy_standard埋め込み更新キーは次のようになります。
embedding_refresh:v2:workspace_44:asset_2107:chunk_18:embedding_model_smallキーには、ワークフロー、バージョン、テナント境界、ソース レコード、アイテム境界、および必要に応じてモデルまたはモデル ポリシーを含める必要があります。これにより、ダウンストリーム書き込みが冪等になるようになります。同じ結果を 2 回受け取った場合、データベースは、重複行を作成したり使用量を二重にカウントしたりするのではなく、request_key によって更新/挿入できます。
ステート マシンを明示的に設計します
プロバイダーの状態は異なるため、内部ステート マシンは小さく耐久性のあるものでなければなりません。実際のバージョンは次のようになります:
- created: ジョブは内部に存在しますが、パッケージ化されていません。
- validated: 入力レコードはスキーマと適格性チェックに合格しました。
- submitted: プロバイダーがバッチを受け入れました。 submit.
- processing: プロバイダが実行を開始したか、キューに登録されました。
- completed: すべての項目が正常な終了状態に達しました。
- completed_with_errors: ジョブは終了しましたが、一部の項目は失敗したため、レビューまたは必要がありますrestart.
- failed: ジョブはプロバイダーまたはオーケストレーション層で失敗しました。
- キャンセルされました: システムまたはオペレーターが完了前にジョブを停止しました。
- 期限切れ: ジョブは期限を過ぎたため、通常の結果を書き込む必要はありません。 review.
各遷移はイベント テーブルに追加専用である必要があります。これにより、ジョブが期限を過ぎた場合、または下流システムがレコードが処理されたかどうかについて異議を唱えた場合に、運用チームに監査証跡が得られます。
第一級のワークフローとして調整を構築する
送信はシステムの半分にすぎません。負荷の高い操作上のバグは通常、結果の取り込み中に発生します。
調整ワーカーは、完了したバッチを処理するたびに次の 5 つのことを実行する必要があります。
- 送信されたリクエスト キーの元のマニフェストを読み込みます。
- 出力ファイル、結果エンドポイント、またはプロバイダ ログからプロバイダの結果を読み込みます。
- すべてのプロバイダの結果を 1 つの内部リクエスト キーにマッピングして戻します。
- 書き込み成功の結果は宛先システムに冪等に送信されます。
- 失敗、欠落アイテム、トークン数、実現コストのターミナル レコードを送信します。
調整プロセスでは、送信されたすべてのアイテムがターミナル状態であることを確認する必要があります。欠落した結果が静かに消えてはいけません。プロバイダの応答とポリシーに従って、それらを欠落、失敗、または再試行可能としてマークします。
コストの帰属もここで行う必要があります。送信時間の見積もりは予算のチェックに役立ちますが、実際のコストは、実際のトークン数、プロバイダーの出力、請求のエクスポート、または利用可能な場合は呼び出しログから導き出す必要があります。これにより、再発する問題が回避されます。チームは推定節約額を報告するが、後で財務台帳には別の数値が表示されます。
すべてを再現せずに部分的な障害を処理する
バッチ システムは部分的な障害を想定する必要があります。プロンプト スキーマはレコードの 2% で失敗する可能性があります。リクエストのサブセットが長さの制限に達する可能性があります。一部の入力はモデレーションまたはコンテンツ ポリシーに違反する可能性があります。結果ファイルには、ほとんどの項目については有効な出力が含まれ、残りについては構造化エラーが含まれる場合があります。
通常、正しい対応は、バッチ全体を再実行しないことです。 parent_job_id と retry_attempt を使用して、失敗したリクエスト キーまたは欠落しているリクエスト キーのみを新しいジョブに再生します。これにより、コストが制限され、重複書き込みが減り、元のジョブの監査証跡がそのまま維持されます。
有用な再試行記録含まれるもの:
- request_key
- parent_job_id
- retry_attempt
- original_error_code
- retry_reason
- new_job_id
- final_status
するすべてのエラーを自動的に再試行するわけではありません。一時的なプロバイダーの障害、キューのタイムアウト、回復可能なトランスポートの問題は再試行できる場合があります。プロンプト検証の失敗、スキーマの不一致、およびサポートされていない入力サイズのエラーは、通常、再生前に修正する必要があります。
バッチ サイズとバージョン管理で爆発範囲を制御
大規模なバッチはスループットを向上させ、オーケストレーションのオーバーヘッドを削減できますが、不適切なプロンプト、間違ったスキーマ、または間違ったモデル選択によるコストも増加します。バッチを小さくすると、フィードバックが速くなり、爆発範囲が小さくなりますが、追跡するジョブが多くなります。
実際的なアプローチは、プログレッシブ ロールアウトです。
- 代表的な入力を使用して小さな検証バッチを実行します。
- スキーマの有効性、出力品質、トークン範囲、調整動作を確認します。
- ワークフローごとにバッチ サイズを増やす最初の実行が成功した後。
- プロンプト バージョン、スキーマ バージョン、およびモデル ポリシーをリクエスト キーまたはマニフェストに保持します。
- 失敗率、トークン使用量、または出力検証がしきい値を超えた場合は自動的に停止します。
これはバックフィルの場合に特に重要です。バックフィルでは、予期せぬ冗長なプロンプトや出力形式で何百万ものレコードを処理する場合、割引があってもすぐに多額の請求書が作成される可能性があります。
推定および実現した節約額を明らかにする
バッチ割引は魅力的ですが、レポートでは見積もりと実際の値をぼかしてはいけません。
送信時に、プラットフォームは、予想されるトークン数、選択したモデル、アイテム数、既知のバッチ割引ルールを使用して推定コストを表示できます。調整後、プラットフォームは、実際のトークン使用量とプロバイダーの請求または使用状況データに基づいて実現コストを表示する必要があります。
便利なダッシュボードには次のものが含まれます:
- ワークフローとプロバイダー別のキュー経過時間
- 最も古い保留ジョブ
- 完了率
- 失敗アイテム率
- 再試行数
- 提出された見積コスト
- 調整された実現コスト
- 取得された有効割引
- 同期フォールバック量
- 期限が近づいているジョブ
この区別は、財務とエンジニアリングが同じ言語を話すのにも役立ちます。エンジニアリングにより、ルーティングと再試行を最適化できます。財務は実現した支出を調整することができます。製品チームは、どのワークフローが処理の遅延によって実際に恩恵を受けているかを確認できます。
実装に関する推奨事項
ワークロードをバッチ処理に移行する前に、次のチェックリストを使用してください。
適格性チェックリスト
- ワークフローは、ユーザーに向けた即時の応答を必要としません。
- 企業は許容可能な完了を定義できます。 window.
- 各アイテムには安定したリクエスト キーがあります。
- 宛先の書き込みはべき等である可能性があります。
- 部分的な結果は許容され、調整可能です。
- 失敗は選択的に再試行できます。
- プロンプトとスキーマのバージョンは次のとおりです。
- 使用状況は、チーム、顧客、製品、または環境に起因する可能性があります。
- 機密ペイロードのログ記録は、プライバシーと保持義務について検討されています。
運用チェックリスト
- プロバイダのステータスを内部ステート マシンに正規化します。
- 元の入力を保存します
- スケジュールに従ってプロバイダ完了イベントをポーリングまたは受信します。
- すべての結果を予想されるスキーマに対して検証します。
- 送信されたリクエスト キーと受信した端末状態を比較します。
- 使用状況レコードは調整後にのみ出力します。
- 推定コストと実現コストを分離します。コスト。
- キューの経過時間、失敗したアイテムの割合、結果の欠落、期限のリスクに関するアラート。
- 同期を維持する必要があるワークロードを文書化します。
明示的なトレードオフ
推奨事項: バッチ処理を、バッチ処理の背後に隠れた最適化ではなく、別個の実行クラスとして扱います。同期 API パス。チームは、ワークフローがいつ遅延するか、どの期限が適用されるか、期限を過ぎた場合に何が起こるかを知っておく必要があります。
トレードオフ: バッチ API はトークンのコストを大幅に削減できますが、単純な要求と応答の動作をキューイング、ポーリング、結果の取り込み、遅延エラー、より複雑なサポート ワークフローに置き換えます。
トレードオフ: プロバイダー バッチAPI は同一ではありません。正規化された内部モデルによりアプリケーションの複雑さは軽減されますが、プラットフォームはデバッグ用にプロバイダ固有の識別子とエラーを保持する必要があります。
トレードオフ: 完全なプロンプトと出力をログに記録すると、監査可能性と調整が向上しますが、プライバシー、セキュリティ、データ保持の義務が生じる可能性もあります。機密コンテンツは、必要に応じて分類、編集、または除外する必要があります。
予測: より多くの LLM インフラストラクチャ チームが、バッチ実行を同期呼び出し、ストリーミング呼び出し、フォールバック ルートと並んで標準ルーティング クラスとして扱うようになるでしょう。最も利益を得るチームは、財務や運用担当者が数値が一致しない理由を尋ねた後で調整と原価計算を追加するのではなく、早期に調整と原価計算を構築するチームです。
実用的な結論
バッチ処理は、遅延したワークロードの LLM ユニット コストを削減する最も明確な方法の 1 つですが、単に安価なエンドポイントではなく、運用システムとして実装する必要があります。ワークロードの適格性、安定したリクエスト キー、正規化されたジョブ モデル、および送信されたすべてのアイテムが終了状態に達したことを証明する調整ワークフローから始めます。
インタラクティブなリクエストの同期を維持します。遅延したワークフローを、コストと完了ウィンドウが合理的なプロバイダー バッチ API に移動します。明示的な期限があるギリギリのワークロードには内部キューを使用します。提出時に推定節約額を報告しますが、実際の使用量から実現コストを調整します。これは、下流の記録、チームの台帳、または SLA の期待を損なうことなくバッチ割引を取得するパターンです。