OpenRouter は、非同期 LLM 推論用のバッチ API を開始し、即時の同期応答に料金を支払う代わりに結果を待つことができるチームに新しいコスト面を追加しました。
9 月 22 日のリリースにより、ユーザーはチャットの完了、応答、メッセージ、埋め込みのためにバッチ ワークロードを /api/v1/batches に送信できるようになります。 OpenRouterによると、この機能は70以上のモデルで動作するという。また、プロバイダは通常、24 時間以内に作業を完了できる場合、通常のトークンごとの価格の 50% 以下の料金を請求するとも述べています。
これにより、この発表は他のエンドポイントよりも重要なものとなります。これは、多くの AI チームがすでに非公式に管理している分割を正式なものとします。つまり、一部のモデル呼び出しはユーザーの待機中に実行する必要がありますが、他の多くの呼び出しはバックグラウンドで実行できます。評価、分類ジョブ、埋め込み、ドキュメント強化、ラベル付け、バックフィル、レッドチーム テスト スイート、および大規模な要約キューでは、多くの場合、低遅延の応答は必要ありません。これまで、これらのジョブは、インタラクティブな製品機能と同じ同期 API パターンを介してプッシュされることがよくありました。
変更点
OpenRouter のバッチ API では、キューに入れて非同期で完了できる作業用の別のパスが作成されます。 1 つのリクエストを作成して応答パスを開いたままにする代わりに、ユーザーはバッチを送信してそのステータスを追跡し、後で完成した出力を取得します。
実際的な変更は、技術的なものであると同時に経済的なものでもあります。 OpenRouter の発表によると、プロバイダーは通常、24 時間以内に作業を完了できる場合、これらのワークロードの価格を標準のトークンあたりの料金の半分以下に設定します。同社はまた、ベータ版では 230,000 を超える完了バッチを処理し、完了時間の中央値は 7 分だったと報告しました。
これらの数字を普遍的なサービス レベルの保証として解釈すべきではありません。利用可能な割引はプロバイダーのサポートとルーティングによって異なり、完了時間はモデル、キューの深さ、ワークロードの形状、プロバイダーの容量によって異なります。しかし、方向性は明確です。API プラットフォームは、意図的なコスト管理手段としてレイテンシを露呈し始めています。
AI チームにとってそれが重要な理由
開発者にとって、バッチ処理は LLM の動作の設計方法を変えます。製品チームは、チャット、コード支援、エージェント ツールの使用、または顧客対応ワークフローのために同期呼び出しを引き続き使用する可能性があります。しかし、同じチームは、定期的な評価の実行、夜間のナレッジベース処理、埋め込み生成、オフライン分析を低コストのキューに移動できます。
トークンの支出が多くの隠れた運用タスクに分散されることが増えているため、これは重要です。企業は目に見える AI 機能のコストに最初に気づくかもしれませんが、チームが評価、品質チェック、コンテンツモデレーション、データセット変換、取得メンテナンスを大規模に実行し始めると、内部ジョブが推論ボリュームの大部分を占める可能性があります。バッチ API により、これらのバックグラウンド ワークロードの分離、予算設定、最適化が容易になります。
このリリースでは、AI API コスト管理の広範なパターンも強化されています。企業は、サポートされているモデルのリスト以上のものを必要としています。インタラクティブ推論と遅延推論の運用上の違いを理解するルーティング、可観測性、ポリシー、使用状況分析、課金ロジックが必要です。
マルチモデル ゲートウェイを使用しているチームにとって、バッチ推論はすぐにガバナンスの問題を引き起こします。どのプロバイダーがバッチ ジョブに適格ですか?一部のモデルはユーザー向けの同期使用のみが承認されていますが、オフライン評価には安価なモデルが優先されますか?失敗したバッチ項目はどのように再試行されますか?財務チームやプラットフォーム チームは、非同期トークンの使用を適切な製品、顧客、環境、または内部チームのせいにすることができますか?
影響を受けるのは誰ですか
最も明らかな恩恵を受けるのは、大量のレイテンシー耐性のある LLM 作業を行うチームです。 AI 評価チームは、すべてのプロンプトをリアルタイム トランザクションとして扱うことなく、より広範なテスト スイートを実行できます。データ チームは、サポート チケット、ドキュメント、トランスクリプト、製品カタログのバックログを低コストで処理できます。取得チームは、バックグラウンドで埋め込みとメタデータを生成できます。セキュリティ チームとガバナンス チームは、運用レイテンシの予算と競合することなく、ポリシー チェックを実行したり、ワークロードを監査したりできます。
バッチ料金設定により実験が安価になるため、スタートアップや小規模チームにもメリットが生じる可能性があります。チームは、要約や分類のために複数のモデルを比較し、実稼働ルートにコミットする前に、より大規模なオフライン テストを実行できます。とはいえ、コスト削減は自動的に行われるわけではありません。ワークフローがまだユーザーをブロックしている場合、またはダウンストリーム システムが完了をポーリングして部分的な障害を処理するように構築されていない場合、バッチ モデルに強制的に組み込むと、価値以上に複雑さが生じる可能性があります。
プラットフォーム チームとインフラストラクチャ チームにとって、この発表は、普及する可能性が高い製品要件を示しています。バッチ価格設定がより一般的になるにつれて、内部 AI プラットフォームには、クォータ、承認フロー、保持ルール、キャンセル動作、ステータス監視、コスト帰属などの非同期ジョブに対する個別の制御が必要になります。単一の集約トークン カウンタでは十分ではありません。
依然として不確実な点
主な不確実性は、モデルやプロバイダ間で節約効果がどの程度一貫しているかということです。 OpenRouter は 50% レベルを一般的なプロバイダー パターンとして説明しており、すべてのモデルやルートが常にその割引で利用できることを約束するものではありません。購入者は、どのモデルがバッチ モードをサポートしているか、ログや請求書に価格がどのように表示されているか、ルーティングの変更によって予想される経済性が変化するかどうかを確認する必要があります。
また、完了ウィンドウに関する運用上の問題もあります。多くのオフライン ワークロードでは 24 時間の枠が妥当ですが、企業は依然として、ほとんどのジョブが数分以内に終了するか、数時間以内に終了するか、それとも期限近くに終了するかを把握する必要があります。 OpenRouter のベータ完了時間の中央値が 7 分であると報告されているのは心強いですが、パフォーマンスの中央値では、大規模な運用バッチのテール レイテンシに関する質問には答えられません。
より大きな重要性は、LLM インフラストラクチャがモノリシックではなくなりつつあることです。古いモデルは単純でした。プロンプトを送信し、応答を受け取り、リストされたトークン価格を支払います。新しいモデルはクラウド インフラストラクチャの価格設定に似ており、タイミング、ルーティング、ワークロード クラス、プロバイダーの選択、およびポリシーのすべてがコストに影響します。 OpenRouter のバッチ API は、開発者が遅延推論を最上級のワークフローとして扱うようにシステムが設計されている場合に、その違いを活用する新しい方法を開発者に提供します。