バッチ ジョブとプロンプト キャッシュで LLM API コストを削減: 実践的なプレイブック

多くのチームは、すべてのリクエストを同じ同期パス経由で送信するため、LLM API に過剰な料金を払っています。これは、チャット、コーディング アシスタント、サポート エージェント、支払いフローなど、ユーザーを待っているあらゆるものに適しています。これは、評価、タグ付け、エンリッチメント、モデレーション スイープ、埋め込みバックフィル、夜間レポート、コンテンツの前処理にとって無駄です。

実際的な問題は、「どのモデルが最も安いですか?」ということではありません。それは次のとおりです: 実際に即時応答が必要な作業はどれですか? これに答えると、AI API のコスト管理がエンジニアリング ワークフローになります。トラフィックを分類し、サポートされている場合はレイテンシ耐性のあるジョブをバッチ処理に送信し、キャッシュ用に繰り返されるプロンプトを構成し、失敗、再試行、運用オーバーヘッド後の実際の節約量を測定します。

モデルごとではなく、ワークロードごとのコスト監査から始めます

アーキテクチャを変更する前に、API の最近の使用状況のサンプルをエクスポートし、ワークロードごとにグループ化します。有用な監査テーブルには次のものが含まれている必要があります:

• エンドポイントとモデル: チャットの完了、応答、埋め込み、モデレーション、またはプロバイダー固有のエンドポイント。
• 平均入力トークンと出力トークン: 長いプロンプトを短い分類タスクから分離します。
• プロンプトの形状: 安定したシステム命令、再利用可能なサンプル、スキーマ、取得コンテキスト、および動的ユーザー データ。
• レイテンシ要件: 秒、分、時間、または翌営業日。
• ユーザーの可視性: ユーザーが結果を待っているかどうか。
• 再試行と失敗率: 不正なリクエスト、検証の失敗、プロバイダーのタイムアウト、期限切れのジョブ、重複した送信。
• 所有権: プロジェクト、チーム、顧客、API キー、またはパートナー アカウント。
• ビジネス SLA: 結果がまだ役立つ最新の時間。

この監査では通常、「LLM トラフィック」が 1 つのワークロードではないことが明らかになります。これは、インタラクティブな製品機能、内部自動化、レポート作成、データ準備、品質評価が組み合わされたものです。これらを 1 つのコストセンターとして扱うと、最も簡単な節約が隠れてしまいます。

3 レーンのワークロード分類子を使用する

シンプルな分類子により、チームが間違ったトラフィックをバッチに移動し、予想外の事態に驚くことを防ぎます。

レーン 1: リアルタイムのインタラクティブなリクエスト

これらを同期させてください。これらには、チャット UX、副操縦士、サポート エージェント、人間参加型レビュー、ライブ検索または取得フロー、即時の副作用を伴うツール呼び出しが含まれます。ユーザーが待機している場合、より安価な応答の価値は待ち時間によって消去される可能性があります。

推奨事項: モデルの選択、プロンプト トリミング、レート制限管理、該当する場合はキャッシュ、および慎重な再試行により、このレーンを最適化します。製品がバックグラウンド タスクとして明示的に提示しない限り、24 時間のバッチ キューに送信しないでください。

レーン 2: 数分間待機できるニアライン リクエスト

これらのジョブはページの読み込みをブロックする必要はありませんが、同じセッションまたは同じ時間が期待される場合があります。例には、アップロード後のドキュメント分析、フォーム送信後の CRM 強化、準備ができたらユーザーに通知できるレポートなどがあります。

推奨事項: ニアライン作業を明示的なステータス状態を持つキューの後ろに配置します。プロバイダーのサポートと期限に応じて、小さなバッチで実行するか、優先度の低い同期ワーカーで実行します。このレーンは、ジョブ ID、Webhook、およびユーザーに表示される進行状況の恩恵を受けます。

レーン 3: 最大 24 時間待機できるオフライン バッチ リクエスト

これがコスト最適化のメインレーンです。適切な候補者は次のとおりです:

• 大規模な評価;
• データセットのラベル付け;
• カタログまたは CRM の強化;
• 夜の要約;
• コンプライアンスレビューキュー;
• バックフィルの埋め込み;
• モデレーションスイープ;
• 定期的なレポートの生成;
• インデックス作成または公開前のコンテンツの前処理。

事実: 主要プロバイダは現在、適切なワークロード向けに非同期バッチ API を提供しています。 OpenAI のバッチ API は、アップロードされたファイルからリクエストを読み取り、結果を出力ファイルに書き込み、24 時間以内の処理を目標としています。 OpenAI は、サポートされているバッチ API の使用が同期 API と比較して 50% のコスト割引で提供されることを示しています。 Anthropic のメッセージ バッチ API は、大量のメッセージ リクエスト、非同期処理、高いスループット、50% 低いコスト向けに設計されています。 Google の Gemini バッチ API は、標準コストの 50% で大量の非同期リクエスト向けに設計されており、目標所要時間は 24 時間です。

トレードオフ: 「最大 24 時間」はバックフィルや評価には優れていますが、対話型ワークフローには受け入れられません。バッチはスケジューリング戦略であり、同期推論の普遍的な代替品ではありません。

ジョブのライフサイクルとしてバッチ パスを設計する

避けるべき実装上の間違いは、バッチを単一の API 呼び出しとして扱うことです。これはライフサイクルです。作業を受け入れ、検証し、永続化し、送信し、ポーリングし、調整し、結果を公開します。

リファレンス アーキテクチャ

1. 正規化されたリクエストを受け入れる: 可能な限り、リクエストの形式を既存の OpenAI 互換の API 形式に近づけてください。プロジェクト、チーム、顧客、べき等キー、要求された期限、コスト センターなどのメタデータを追加します。
2. ワークロードを分類します: リクエストをリアルタイム、ニアライン、またはオフライン バッチに割り当てます。これはポリシーベースである必要があり、アプリケーション コード内に隠蔽することはできません。
3. ジョブ ID を作成します: ニアラインおよびオフライン作業のジョブ ID をすぐに返します。
4. 互換性の検証: 選択したプロバイダーとモデルが、要求されたエンドポイント、モダリティ、ファイル サイズ、ツール、応答形式、その他の機能のバッチをサポートしているかどうかを確認します。
5. リクエスト行の永続化: 正規化された JSONL 行またはプロバイダー固有のペイロードを保存します。調整のために安定した行 ID を含めます。
6. バッチを送信します: プロバイダーの制限とジョブ サイズに応じて、リクエスト ファイルまたはインライン バッチ ペイロードをアップロードします。
7. ポーリング ステータス: プロバイダの状態 (該当する場合、検証中、進行中、完了、失敗、期限切れ、キャンセル、キャンセルなど) を追跡します。
8. 出力行の保存: 成功した応答、行レベルのエラー、トークンの使用状況、キャッシュされたトークン数 (可能な場合)、およびプロバイダー ID を書き込みます。
9. 消費者に通知: 取得エンドポイント、Webhook、ダッシュボード通知、または Telegram アラートを公開します。
10. 請求の調整: コストを元のプロジェクト、チーム、顧客、API キー、ジョブ ID に関連付けます。

このパターンにより、アプリケーションはシンプルになります。製品チームは作業を送信し、ジョブの状態を受け取ります。ゲートウェイまたはオーケストレーション層は、プロバイダーの違い、バッチ ファイル、再試行、およびアカウンティングを処理します。

明示的なジョブ状態を使用する

各プロバイダーが異なる名前を使用している場合でも内部状態を定義します:

• queued: 承認されましたが、送信されていません;
• validating: プロバイダーまたはゲートウェイがファイルをチェックしています;
• running: 送信され処理中;
• completed: 利用可能なすべての結果が収集されました;
• completed_with_errors: 一部の行が検証または実行に失敗しました;
• expired: すべての行が完了する前に期限を過ぎました;
• cancelled: ユーザー、システム、またはポリシーによって停止されました;
• failed: 介入が必要なジョブレベルの障害。

事実: OpenAI には、検証中、失敗、in_progress、完了、期限切れ、キャンセル、キャンセルなどのバッチ ステータスが記載されています。また、バッチの有効期限が切れた場合、すでに完了した作業は返されて請求され、残りの作業はキャンセルされることにも注意してください。

推奨事項: バッチ ジョブがオール オアナッシングであるとは決して想定しないでください。行レベルのステータス処理を最初から構築します。

障害後の節約額とオーバーヘッドを計算する

ほとんどのチームにはシンプルな節約モデルで十分です:

baseline_cost = synchronous_input_cost + synchronous_output_cost
batch_cost = discounted_batch_input_cost + discounted_batch_output_cost
adjusted_batch_cost = batch_cost + orchestration_cost + storage_cost + rerun_cost
estimated_savings = baseline_cost - adjusted_batch_cost

次に、これをグローバルではなくワークロードごとに計算します。夜間評価スイートを使用すると、大幅に節約できる可能性があります。多数の不正な行、緊急のフォールバック、または繰り返しの再実行を含むニアライン ワークフローでは、予想よりも節約できる可能性があります。

少なくとも次の指標を追跡します:

• 同期とバッチ トークンの使用量;
• モデルごとの入力トークンと出力トークン;
• バッチジョブ数とジョブごとの平均行数;
• 行レベルの失敗率;
• 期限切れジョブ率;
• 再実行コスト;
• 同期へのフォールバックのコスト;
• チーム、プロジェクト、キー、顧客、パートナー アカウントごとのコスト。

推奨事項: 自動同期フォールバックをデフォルトではなく例外として扱います。期限は守られますが、使いすぎると、期待されていた節約効果が失われる可能性があります。 「業務期限が 2 時間以内でジョブが開始されていない場合にのみフォールバックする」などのポリシーを追加します。

長いプレフィックスが繰り返される場合のプロンプト キャッシュを追加します

バッチ処理により、対象となる作業の単価が下がります。プロンプト キャッシュは、プロバイダーの動作がサポートしている場合に、繰り返される長いプロンプトの効果的なコストと遅延を削減します。

事実: OpenAI プロンプト キャッシュは、サポートされているモデルの 1,024 トークンを超えるプロンプトに自動的に適用され、以前に計算された最長のプレフィックスをキャッシュし、API の使用状況の詳細に cached_tokens をレポートします。 OpenAI によると、プロンプト キャッシュは通常、非アクティブ状態が 5 ～ 10 分間続いた後にクリアされ、最後の使用から 1 時間以内に削除され、プロンプト キャッシュは組織間で共有されないそうです。

実装パターンは単純です。安定したコンテンツを最初に配置し、揮発性のコンテンツを最後に配置します。

キャッシュ用のプロンプト構造の改善

System instructions
Stable policy text
Stable output schema
Stable examples
Reusable reference context
---
Dynamic record-specific input
Dynamic user or row metadata

たとえば、カタログ エンリッチメント ジョブでは、50,000 個の製品にわたって同じ分類法、出力スキーマ、ブランド ルール、およびサンプルを再利用できます。各行では、製品のタイトル、説明、属性のみが変更されます。再利用可能なプレフィックスを最初に配置すると、サポートされている場合、プロバイダーはキャッシュされた計算を再利用できる可能性が高くなります。

トレードオフ: キャッシュは永続的なストレージではないため、保証されたものとして扱うべきではありません。キャッシュ ウィンドウ、分離、プロンプトの最小長、レポートはプロバイダーによって異なります。節約額を想定するのではなく、キャッシュされたトークンを測定します。

送信前にプロバイダーのサポートを検証する

バッチ API は異なります。ゲートウェイは、ジョブを送信する前に資格を検証する必要があります。

事実: OpenAI バッチ API はストリーミングをサポートしておらず、個別のバッチ レート制限があります。 Anthropic には、100,000 リクエストまたは 256 MB のバッチ サイズ制限、24 時間の有効期限、29 日間の結果の可用性、レート制限、バッチが構成されたワークスペースの使用制限をわずかに超える可能性など、バッチ制限が記載されています。 Google は、20 MB 未満の小規模なジョブのインライン バッチ リクエストと、より大きなバッチ リクエストの JSONL 入力ファイルをサポートします。

互換性チェックリストを使用します:

• 要求されたモデルは、そのプロバイダーのバッチ API を通じて利用できますか?
• エンドポイントはサポートされていますか?
• リクエストにはストリーミングが必要ですか? 「はい」の場合、バッチを拒否します。
• 直ちに発生しなければならないツールや副作用を使用していますか?
• バッチ ファイルはプロバイダーの制限を超えていますか?
• 予想される結果はプロバイダーの完了ウィンドウ内でも役に立ちますか?
• 下流システムが出力を取得できるのに十分な期間、出力が利用可能ですか?
• ワークロードは部分的な完了を許容できますか?

推奨事項: 明確な理由で検証を早期に失敗させます。拒否されたバッチ候補は、後でやり直す必要がある期限切れまたは不正なジョブよりもコストがかかりません。

チーム、代理店、パートナーのための保護策

バッチ システムはバックグラウンドで大きなファイルを処理するため、静かに多額の費用を費やす可能性があります。広範囲に展開する前にコントロールを追加します:

• チームごとのバッチ予算: オンラインとオフラインの個別の支出制限。
• 最大ファイル サイズと行数: プロバイダの制限と独自の操作制限を適用します。
• デッドレター キュー: 検証エラーのある無効な行をレビューのために保存します。
• 冪等キー: 誤って再送信されることによる重複請求を防ぎます。
• PII レビュー: バッチ ファイルにより、新たなデータ保持義務とプライバシー義務が生じる可能性があります。
• 保持ポリシー: リクエスト ファイル、出力ファイル、ログの保存期間を定義します。
• 通知ポリシー: ジョブが失敗した場合、期限切れになった場合、または予算を超過した場合に所有者に警告します。
• 属性: レコード プロジェクト、チーム、顧客、API キー、モデル、プロバイダー、ジョブ ID、および行 ID。

代理店や再販業者にとって、帰属は特に重要です。 1 つのパートナーが多くのクライアントに対してエンリッチメントまたは評価ジョブを実行する場合、システムはプロバイダーの請求書ごとだけでなく、クライアントごとおよびジョブごとのコストを報告する必要があります。

これを AI にマッピングする方法 API ゲートウェイ

AI API ゲートウェイは、すでにアプリケーションとモデル プロバイダーの間に配置されているため、これを実装するのに自然な場所です。ゲートウェイは、開発者向けに OpenAI 互換の API サーフェスを保持しながら、その背後にコストを意識したスケジューリングを追加できます。

便利なゲートウェイ機能には次のものがあります:

• 統合請求: 同期、バッチ、キャッシュ、およびフォールバックの支出を 1 か所で比較します。
• AI 使用状況分析: モデル、プロバイダー、エンドポイント、チーム、プロジェクト、API キーごとに使用状況を分析します。
• チーム管理: インタラクティブなワークロードとオフラインのワークロードに個別の予算を設定します。
• API - キーの属性: 各ジョブを作成したサービスまたは顧客を特定します。
• ステータス通知: バッチ ジョブが完了、失敗、期限切れになったとき、または期限が近づいたときにアラートを送信します。
• パートナー API ワークフロー: 代理店または再販業者は、クライアント レベルの会計を維持しながら、クライアントに代わってジョブを作成し、結果を取得できます。

予測: 個以上のチームが、モデルの置換だけでなく、スケジュール ポリシーを使用して LLM コストを管理するようになるでしょう。バッチ サポートがプロバイダー間で成熟するにつれて、優れたアーキテクチャは、モデルの価格によってルーティングされる前に、緊急性、機能の互換性、アカウンティング要件によってルーティングされます。

実装チェックリスト

• 30 日間の LLM API 使用量をエクスポートします。
• 各ワークロードをリアルタイム、ニアライン、オフラインに分類します。
• 明確な所有権と寛容な期限を持つオフライン ワークロードを 1 つ選択してください。
• 必要なエンドポイントとモデルに対するプロバイダーのバッチ サポートを検証します。
• 内部ジョブの状態と行レベルのステータスを定義します。
• 冪等キー、ジョブ ID、行ごとの ID を追加します。
• 正規化されたリクエストとレスポンスのレコードを保持制御を使用して保存します。
• 機能フラグを付けて最初のバッチを送信します。
• 同期ベースライン コストと調整されたバッチ コストを測定します。
• 安定したプレフィックスを最初に配置するように、繰り返される長いプロンプトを再構成します。
• キャッシュされたトークン、失敗した行、期限切れのジョブ、フォールバック費用を追跡します。
• コスト削減と運用動作が分析で確認された後にのみ拡張します。

実用的な結論

すべてのチームに安価なモデルを使用するように依頼して AI API コスト管理を始めないでください。まずは、緊急の仕事と待ってもよい仕事を区別することから始めましょう。インタラクティブなリクエストの同期を維持します。プロバイダーのサポートとビジネスの期限が合ったときに、評価、強化、タグ付け、バックフィル、モデレーション スイープ、およびレポートをバッチに移動します。構造体はキャッシュを求める長いプロンプトを繰り返しました。次に、失敗、再実行、ストレージ、フォールバックのコスト後の実際の節約コストを測定します。

最良の実装は、ジョブ ID、検証、行レベルのステータス、予算、使用状況分析、明確な所有権など、意図的に退屈なものです。この運用層こそがプロバイダ割引を確実な節約に変えるものです。

関連資料

• API 主要なアトリビューションとチーム支出の制御
• LLM API のルーティング、再試行、フォールバック ポリシー
• 関連Model Gate 実装メモ