バッチ ジョブとプロンプト キャッシュで LLM API コストを削減: 実践的なプレイブック
レイテンシー耐性のあるワークロードのための AI API コスト管理の実践的なガイド: トラフィックの分類、対象となるジョブのバッチ API への移動、プロンプト キャッシュの使用、請求の分かりやすさの維持。
多くのチームは、すべてのリクエストを同じ同期パス経由で送信するため、LLM API に過剰な料金を払っています。これは、チャット、コーディング アシスタント、サポート エージェント、支払いフローなど、ユーザーを待っているあらゆるものに適しています。これは、評価、タグ付け、エンリッチメント、モデレーション スイープ、埋め込みバックフィル、夜間レポート、コンテンツの前処理にとって無駄です。
実際的な問題は、「どのモデルが一番安いですか?」ということではありません。それは次のとおりです。どの作業が実際に即時応答が必要で、どの作業が待つことができるのか?これに答えると、AI API のコスト管理がエンジニアリング ワークフローになります。トラフィックを分類し、サポートされている場合はレイテンシー耐性のあるジョブをバッチ処理に送信し、キャッシュ用に繰り返されるプロンプトを構成し、失敗、再試行、運用オーバーヘッド後の実際の節約量を測定します。
モデルごとではなく、ワークロードごとのコスト監査から始めます
アーキテクチャを変更する前に、最近の API 使用状況のサンプルをエクスポートし、ワークロードごとにグループ化します。有用な監査テーブルには以下を含める必要があります。
- エンドポイントとモデル: チャットの完了、応答、埋め込み、モデレーション、またはプロバイダー固有のエンドポイント。
- 平均入力トークンと出力トークン: 長いプロンプトを短い分類タスクから分離します。
- プロンプトの形状: 安定したシステム命令、再利用可能なサンプル、スキーマ、取得コンテキスト、動的なユーザー データ。
- レイテンシ要件: 秒、分、時間、または翌営業日
- ユーザーの可視性: ユーザーが結果を待っているかどうか。
- 再試行率と失敗率: 不正なリクエスト、検証の失敗、プロバイダーのタイムアウト、期限切れのジョブ、重複した送信
- 所有権: プロジェクト、チーム、顧客、API キー、またはパートナー アカウント。
- ビジネス SLA: 結果がまだ役立つ最新の時間
この監査では通常、「LLM トラフィック」が 1 つのワークロードではないことが明らかになります。これは、インタラクティブな製品機能、内部自動化、レポート作成、データ準備、品質評価が組み合わされたものです。これらを 1 つのコストセンターとして扱うと、最も簡単な節約が隠れてしまいます。
3 レーンのワークロード分類子を使用する
シンプルな分類子により、チームが間違ったトラフィックをバッチに移動し、期待外れになって驚くことを防ぎます。
レーン 1: リアルタイムのインタラクティブなリクエスト
これらを同期させてください。これらには、チャット UX、副操縦士、サポート エージェント、人間参加型レビュー、ライブ検索または取得フロー、即時の副作用を伴うツール呼び出しが含まれます。ユーザーが待機している場合、より安価な応答の価値は遅延によって消失する可能性があります。
推奨事項: モデルの選択、迅速なトリミング、レート制限管理、該当する場合はキャッシュ、および慎重な再試行により、このレーンを最適化します。製品がバックグラウンド タスクとして明示的に提示しない限り、24 時間のバッチ キューに送信しないでください。
レーン 2: 数分間待機できるニアライン リクエスト
これらのジョブはページの読み込みをブロックする必要はありませんが、同じセッションまたは同じ時間が期待される場合があります。例としては、アップロード後のドキュメント分析、フォーム送信後の CRM 強化、準備ができたらユーザーに通知できるレポートなどがあります。
推奨事項: ニアライン作業は、明示的なステータス状態を持つキューの後ろに配置します。プロバイダーのサポートと期限に応じて、小さなバッチで実行するか、優先度の低い同期ワーカーで実行します。このレーンは、ジョブ ID、Webhook、およびユーザーに表示される進行状況の恩恵を受けます。
レーン 3: 最大 24 時間待機できるオフライン バッチ リクエスト
これがコスト最適化のメインレーンです。適切な候補者は次のとおりです。
- 大規模な評価;
- データセットのラベル付け;
- カタログまたは CRM の強化
- 毎晩の要約;
- コンプライアンス レビューのキュー;
- バックフィルの埋め込み;
- モデレーションスイープ;
- 定期的なレポートの生成;
- インデックス作成または公開前のコンテンツの前処理
事実: 主要プロバイダは現在、適切なワークロード向けに非同期バッチ API を提供しています。 OpenAI の Batch API は、アップロードされたファイルからリクエストを読み取り、結果を出力ファイルに書き込み、24 時間以内の処理を目標とします。 OpenAI は、サポートされている Batch API の使用が同期 API と比較して 50% のコスト割引で提供されると述べています。 Anthropic のメッセージ バッチ API は、大量のメッセージ リクエスト、非同期処理、より高いスループット、50% のコスト削減を目的として設計されています。 Google の Gemini Batch API は、標準コストの 50% で大量の非同期リクエストを処理できるように設計されており、所要時間は 24 時間です。
トレードオフ: 「最大 24 時間」はバックフィルや評価には優れていますが、対話型ワークフローには受け入れられません。バッチはスケジュール戦略であり、同期推論の普遍的な代替品ではありません。
ジョブのライフサイクルとしてバッチ パスを設計する
避けるべき実装上の間違いは、バッチを単一の API 呼び出しとして扱うことです。これはライフサイクルです。作業を受け入れ、検証し、永続化し、送信し、ポーリングし、調整し、結果を公開します。
リファレンス アーキテクチャ
<オル>このパターンにより、アプリケーションがシンプルになります。製品チームは作業を送信し、ジョブの状態を受け取ります。ゲートウェイまたはオーケストレーション層は、プロバイダーの違い、バッチ ファイル、再試行、アカウンティングを処理します。
明示的なジョブ状態を使用する
各プロバイダーが異なる名前を使用している場合でも、内部状態を定義します。
キューに入れられています: 受け入れられましたが、送信されていません;検証中: プロバイダーまたはゲートウェイがファイルをチェックしています。running: 送信され、処理中です。completed: 利用可能なすべての結果が収集されました。completed_with_errors: 一部の行が検証または実行に失敗しました。expired: すべての行が完了する前に期限が過ぎました。キャンセル: ユーザー、システム、またはポリシーによって停止されました。failed: 介入が必要なジョブレベルの失敗。
事実: OpenAI は、検証中、失敗、進行中、完了、期限切れ、キャンセル中、キャンセルなどのバッチ ステータスを文書化します。また、バッチの有効期限が切れた場合、すでに完了した作業は返されて請求され、残りの作業はキャンセルされることにも注意してください。
推奨事項: バッチ ジョブが全か無かであると想定しないでください。行レベルのステータス処理を最初から構築します。
障害後の節約額とオーバーヘッドを計算する
ほとんどのチームには、シンプルな節約モデルで十分です。
ベースラインコスト = 同期入力コスト + 同期出力コスト
バッチコスト = 割引バッチ入力コスト + 割引バッチ出力コスト
調整済みバッチコスト = バッチコスト + オーケストレーションコスト + ストレージコスト + 再実行コスト
推定節約額 = ベースラインコスト - 調整済みバッチコスト次に、これをグローバルではなくワークロードごとに計算します。夜間評価スイートを使用すると、大幅に節約できる可能性があります。多くの不正な行、緊急のフォールバック、または繰り返しの再実行を含むニアライン ワークフローでは、予想よりも節約できない可能性があります。
少なくとも次の指標を追跡します:
- 同期トークンとバッチ トークンの使用量;
- モデルごとの入力トークンと出力トークン;
- バッチ ジョブ数とジョブあたりの平均行数;
- 行レベルの失敗率;
- 期限切れジョブ率;
- 再実行コスト;
- 同期へのフォールバックのコスト;
- チーム、プロジェクト、キー、顧客、パートナー アカウントごとのコスト
推奨事項: 自動同期フォールバックはデフォルトではなく例外として扱います。期限は守られますが、使いすぎると、期待されていた節約効果が失われる可能性があります。 「業務期限が 2 時間以内でジョブが開始されていない場合にのみフォールバックする」などのポリシーを追加します。
繰り返される長いプレフィックスに対するプロンプト キャッシュを追加する
バッチ処理により、対象となる作業の単価が下がります。プロンプト キャッシュにより、プロバイダーの動作がサポートしている場合、繰り返しの長いプロンプトによる効果的なコストとレイテンシが削減されます。
事実: OpenAI プロンプト キャッシュは、サポートされているモデルの 1,024 トークンを超えるプロンプトに自動的に適用され、以前に計算された最長のプレフィックスをキャッシュし、API 使用状況の詳細で cached_tokens をレポートします。 OpenAI によると、プロンプト キャッシュは通常、非アクティブ状態が 5 ～ 10 分間続くとクリアされ、最後の使用から 1 時間以内に削除され、プロンプト キャッシュは組織間で共有されないという。
実装パターンは単純です。安定したコンテンツを最初に配置し、揮発性のコンテンツを最後に配置します。
キャッシュ用のプロンプト構造の改善
システム命令
安定したポリシーテキスト
安定した出力スキーマ
安定した例
再利用可能な参照コンテキスト
---
動的レコード固有の入力
動的なユーザーまたは行のメタデータたとえば、カタログ エンリッチメント ジョブでは、50,000 個の製品にわたって同じ分類法、出力スキーマ、ブランド ルール、およびサンプルを再利用できます。各行では、製品のタイトル、説明、属性のみが変更されます。再利用可能なプレフィックスを最初に配置すると、サポートされている場合、プロバイダーはキャッシュされた計算を再利用できる可能性が高くなります。
トレードオフ: キャッシュは永続的なストレージではないため、保証されたものとして扱うべきではありません。キャッシュ ウィンドウ、分離、プロンプトの最小長、レポートはプロバイダーによって異なります。節約を想定するのではなく、キャッシュされたトークンを測定します。
送信前にプロバイダーのサポートを検証する
バッチ API は異なります。ゲートウェイは、ジョブを送信する前に資格を検証する必要があります。
事実: OpenAI Batch 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、検証、行レベルのステータス、予算、使用状況分析、明確な所有権など、意図的に退屈なものです。この運用層により、プロバイダー割引が確実な節約に変わります。