Cloudflare AI Gateway はカスタム原価計算にキャッシュトークンの価格設定を追加します

Cloudflare は、AI Gateway のカスタム原価計算にキャッシュ読み取りおよびキャッシュ書き込みトークン レートを追加しました。これは、プロバイダー間でモデルの使用を再販、ルーティング、または調整するチームにとって大きな請求結果をもたらす小さな変更ログ項目です。

9 月 9 日のアップデートにより、開発者は、per_cache_read_token と per_cache_write_token の値をcf-aig-custom-cost ヘッダー。いずれかのキャッシュ固有のレートが存在する場合、Cloudflare は、AI Gateway がキャッシュ トークンの価格設定を有効にし、プロバイダーの違いを考慮して、同じキャッシュの使用量が 2 回カウントされないようにすると言っています。

それは狭いように思えます。そうではない。キャッシュの料金設定は、統合 AI API の課金において、特にプロバイダーが再利用されたコンテキストに異なる名前、単位、課金ルールを使用するため、最も難しい部分の 1 つとなっています。キャッシュされたすべてのトークンを通常の入力トークンとして扱うのは簡単かもしれませんが、再販業者のマージンを消したり、どのワークロードが実際に高価であるかについて顧客に誤解を与えたりする十分な誤りがある可能性があります。

変更点

AI Gateway ではすでにカスタム コスト データをリクエストに添付できるようになっており、チームは公開プロバイダーの価格設定のみに依存するのではなく、交渉された料金や内部価格表を表す方法が提供されます。新しい変更により、そのメカニズムがキャッシュ固有のトークン カテゴリに拡張されます。

実際には、ゲートウェイ オペレーターは、入力トークンまたは出力トークンのコストだけでなく、キャッシュ読み取りまたはキャッシュ書き込みのコストを Cloudflare に伝えることができるようになりました。プロバイダーはプロンプト キャッシングを独自の経済層として価格設定することが増えているため、この違いは重要です。キャッシュ書き込みはキャッシュ読み取りよりもコストがかかる場合があります。キャッシュ読み取りは、新しい入力よりも大幅にコストが低くなる可能性があります。一部のプロバイダーは、使用状況記録でキャッシュの作成とキャッシュの取得を異なる方法で公開する場合があります。

二重カウントを避けるためにプロバイダーの違いを処理するという Cloudflare の注記も重要です。キャッシュ フィールドは、入力トークンの合計から常に明確に分離されているわけではありません。課金システムがプロバイダーから報告された入力使用量に単純にキャッシュ トークンを追加すると、顧客に過大な料金を請求したり、内部コストを膨らませたりする可能性があります。キャッシュ フィールドを無視すると、キャッシュ エントリを頻繁に作成するロングコンテキスト アプリケーションのコストが過小評価される可能性があります。

キャッシュ アカウンティングが今重要になる理由

プロンプト キャッシュは、以前は最適化の詳細でした。多くの実稼働ワークロードでは、これが価格アーキテクチャの一部になりました。

長いシステム プロンプト、検索で拡張されたコンテキスト、コーディング エージェント リポジトリ、法的文書パック、およびサポート ナレッジ ベースはすべて、コンテキストを再利用することで恩恵を受けます。システムが送信するコンテキストが繰り返されるほど、キャッシュの価格設定が実際のユニットエコノミクスに変化します。同様のトークン数を持つ 2 つのリクエストは、一方がキャッシュ エントリを書き込み、もう一方がキャッシュ エントリから読み取る場合、コストが大きく異なる可能性があります。

そのため、キャッシュの可視性は単なるエンジニアリングの問題ではなく、財務上の問題になります。内部エージェントを実行しているチームは、新しいプロンプトの生成が多すぎる、キャッシュが見つからない、大きなキャッシュ ブロックの書き込みが多すぎるなどの理由で、新しいワークフローが高価かどうかを知る必要があるかもしれません。リセラーは、見かけ上のプロンプト サイズが大きいにもかかわらず、あるアプリケーションの請求される使用量が予想よりも低い理由を顧客に示す必要がある場合があります。ゲートウェイ ベンダーは、月末の調整がプロバイダーの請求書と一致するように、ログ、分析、台帳レコードにキャッシュ フィールドを保存する必要がある場合があります。

これは、AI API コスト分析 の要求がより厳しくなる場所でもあります。総リクエストコストだけではもはや十分ではありません。チームは、入力、出力、キャッシュ書き込み、キャッシュ読み取りの動作を個別に確認し、それらのカテゴリを API キー、顧客、モデル、ルートに結び付ける必要があります。

影響を受けるのは誰か

当面の対象者は、デフォルトの公開価格設定ではなくカスタムコストに依存する Cloudflare AI Gateway ユーザーです。これには、交渉によるモデル料金を設定している企業、顧客のためにプロバイダーの使用量をマークアップするプラットフォーム、複数のモデルプロバイダーにわたる共有コントロールプレーンとして Cloudflare を使用するチームが含まれます。

再販業者は特に危険にさらされます。リセラーが簡素化されたトークン モデルを使用して顧客に料金を請求し、プロバイダーにはキャッシュを意識した価格設定で料金を支払う場合、その差額は静かに蓄積される可能性があります。キャッシュ書き込みの不足やキャッシュ読み取りの過剰は、単一のリクエストでは現れない可能性がありますが、エージェント セッション、バッチ処理、または大量の取得ワークロード全体で問題になる可能性があります。

OpenAI 互換のゲートウェイ レイヤーを構築している開発者は、Cloudflare を直接使用していない場合でも影響を受けます。この変更は、市場のより広範な方向性を反映しています。プロバイダーの請求対象はより細分化されていますが、顧客は依然としてクリーンな請求書と予測可能な使用状況レポートを期待しています。Model Gate などの製品は、顧客を対象とした正確なレポート、使用制限、複数のプロバイダーにわたるマージン分析が必要な場合、キャッシュ トークン フィールドを第一級の台帳データとして扱う必要があります。

実際的な結果

ゲートウェイ チームは、リクエスト ログ、コスト計算ツール、および請求書がキャッシュ アクティビティをどのように表すかを確認する必要があります。キャッシュの読み取りと書き込みが通常のプロンプト トークンにフラット化される場合、分析は基礎となる請求書よりも単純に見える可能性があります。プロバイダーの使用状況レコードに、取り込み中に削除されたキャッシュ フィールドが含まれている場合、後の調整が困難になります。

価格設定エンジンは、方向ごとに複数のレートをサポートする必要もあります。高度なモデルの会計処理には、古い入力と出力の分割ではもはや十分ではありません。信頼できるモデル台帳には、新しい入力トークン、出力トークン、キャッシュ書き込み、キャッシュ読み取り、および場合によってはこれらのカテゴリのプロバイダー固有のバリアントを収容する余地が必要です。

顧客向けのダッシュボードでは、これらの区別を慎重に公開する必要があります。ほとんどのユーザーは生のプロバイダー テレメトリを読み取りたくありませんが、アプリケーションがコンテキストをより効率的に再利用し始めるとコストが変化する理由を理解する必要があります。最良のインターフェイスは、顧客が各プロバイダーの用語を学習する必要なく、キャッシュの節約とキャッシュの作成のコストを示すコストの内訳です。

アラートと制限には運用上の影響もあります。合計トークンのみに基づいた顧客の予算制限では、高価なキャッシュ エントリを書き込むワークロードをキャッチできない可能性があります。リクエスト数のみに基づくマージン アラートでは、プロバイダーの価格設定の不一致を見逃す可能性があります。顧客ごとのキーを介してアクセスを販売するチームの場合、キャッシュ対応の会計は、支出制御に使用されるのと同じ顧客、プロジェクト、またはアプリケーションの識別子に結び付ける必要があります。

未解決の内容

変更ログでは、キャッシュ読み取りおよびキャッシュ書き込みのカスタム レートのサポートが確立されていますが、ゲートウェイ オペレーターの実装に関するすべての疑問が解決されるわけではありません。チームは、特定のプロバイダーがキャッシュ使用量をどのように報告するか、Cloudflare の計算されたコストがログとエクスポートにどのように表示されるか、既存の請求書を新しいカスタムコストフィールドとどのように比較するかをテストする必要があります。

ただし、より大きな方向性は明らかです。 AI ゲートウェイの請求は、単純なトークン メーターから詳細な使用状況台帳へと移行しています。キャッシュの価格設定はその台帳の一部になりました。詳細を保存するチームは、より明確な調整とより優れた顧客分析を行うことができます。それを折りたたんで削除したチームは、プロバイダーの請求書と顧客の請求書が同じ内容を伝えるのをやめるまで、問題に気付かない可能性があります。