Cloudflare は、AI ゲートウェイの地味だが重要な部分、つまり上流の AI プロバイダーが顧客の認証情報を拒否した場合に何が起こるかを変更しました。
Cloudflare の AI Gateway 変更ログによると、POST /ai/run はプロバイダーが認証情報を拒否した場合に、より一貫した応答を返すようになりました。最も具体的な例は Google 頂点です。以前はアップストリームの再試行で HTTP 500 応答を生成していた拒否された Vertex 認証情報は、Cloudflare エラー コード 2009 で HTTP 401 を返すようになりました。Cloudflare は、アプリケーションは HTTP 401 を無効または拒否されたプロバイダー認証情報として解釈する必要があると述べています。対照的に、Cloudflare 管理の統合請求におけるプロバイダーの拒否は HTTP 503.
それは、狭い範囲のエラー契約の更新のように思えます。 AI ゲートウェイを運用するチームにとって、それはそれだけではありません。不正なプロバイダー キーを一時的なインフラストラクチャ障害のように扱うべきではありません。そうなると、アプリケーションは成功しない作業を再試行し、フォールバック システムが間違った理由でトラフィックをシフトする可能性があり、カスタマー サポート チームは事後的に認証の失敗とプロバイダの不安定性を区別する必要があります。
ゲートウェイ契約の変更点
この変更により、本番環境で重要な区別、つまり誰が障害を修正できるかが標準化されます。
ユーザーが独自のプロバイダー キーを持参し、そのキーが無効であるか、取り消されているか、期限切れであるか、適切なプロジェクト権限がない場合、またはプロバイダーによって拒否された場合、顧客またはプラットフォーム管理者は資格情報を修復する必要があります。 401 を返すとそれが表示されます。これは、認証がプロバイダー境界で失敗し、ブラインド再試行では解決する可能性が低いことをアプリケーションに伝えます。
以前、少なくとも拒否された Google Vertex 認証情報については、失敗が HTTP 500 として表面化し、アップストリームの再試行がトリガーされる可能性があると Cloudflare は述べています。 500 応答は通常、サーバー側の障害、または自然に解決される可能性のある上流の問題を意味します。多くのクライアント ライブラリとゲートウェイ ラッパーは、そのクラスのエラーを再試行可能なものとして扱います。 AI トラフィックの場合、リクエストには長いプロンプト、ツールのコンテキスト、または大量のバッチ作業が含まれる可能性があるため、コストがかかる可能性があります。
新しい分割により、統合請求の動作も明確になります。 Cloudflare によると、統合請求に基づくプロバイダーの拒否は HTTP 503 に対応しているとのことです。これにより、エラーは顧客独自の重要な問題として提示されるのではなく、サービス可用性ファミリー内にとどまります。 Bring-Your-Own-Key トラフィックとゲートウェイ課金トラフィックの両方をサポートするソフトウェアの場合、この区別により、再試行ルールとユーザー向けメッセージの両方が形成されるはずです。
BYOK と再販業者の製品にとってそれが重要な理由
このアップデートは、より多くの AI プラットフォームがゲートウェイ課金のアクセスと顧客指定の認証情報を組み合わせている市場に導入されます。 チームAPI ゲートウェイ は、1 つのリクエストをプラットフォーム アカウント経由でルーティングし、別のリクエストを顧客の OpenAI キー経由でルーティングし、3 番目のリクエストをエンタープライズ バイヤーが管理する Google クラウド プロジェクト経由でルーティングできます。 HTTP ステータス コードは、多くの場合、何か問題が発生したときにコントロール プレーンが最初に認識する信号です。
BYOK ワークフローの場合、プロバイダーの資格情報の拒否を 401 として扱うことで、よりクリーンな運用パスが可能になります。ダッシュボードでは、資格情報を拒否としてマークし、影響を受けるルートのみを一時停止し、適切な所有者に通知して、再度失敗するリクエストに再試行予算を費やすことを回避できます。また、主要な衛生状態とモデルの可用性を区別するのにも役立ちます。取り消された Vertex 認証情報は、プロバイダーの停止やレート制限イベントと同じインシデントではありません。
再販業者とパートナーのプラットフォームにも同様の問題がありますが、より顧客に影響を及ぼします。 AI API 再販プラットフォーム は、多くの下流クライアントのキー、請求状態、プロバイダー ルートを管理できます。拒否された認証情報が一般的なサーバー エラーのように見える場合、サポート チームは間違った根本原因を報告したり、より高価なルートにフェイルオーバーしたり、顧客の認証情報の設定ミスに起因するはずのコストを吸収したりする可能性があります。
したがって、実質的な変更はエラー解析だけではありません。オペレーターは、再試行ポリシー、アラートラベル、ダッシュボードのコピー、およびインシデントの分類を再検討する必要があります。ゲートウェイ パスからの 401 は通常、プロバイダーの自動再試行を停止し、問題を認証情報の修復に移行します。管理対象請求の 503 であっても、製品のアーキテクチャに応じて、プロバイダーの健全性チェック、フェイルオーバー ロジック、またはステータス ページのインシデントが保証される場合があります。
開発者が更新すべき内容
Cloudflare AI Gateway を使用する開発者は、広範な HTTP クラスを通じてプロバイダーの障害を処理するクライアント ロジックをチェックする必要があります。現在、401 応答がゲートウェイ トークンの問題としてのみ処理されている場合、そのコードは、アプリケーションの Cloudflare 認証情報と、Cloudflare エラー コード 2009 で表されるアップストリーム プロバイダーの認証情報を区別する必要がある可能性があります。
チームはフォールバック ルーティングも確認する必要があります。フォールバックは、プロバイダーが利用できない場合、過負荷になっている場合、または遅延の目標を超えている場合に役立ちます。元の障害が顧客の資格情報の問題である場合、リスクはさらに高くなります。拒否された BYOK ルートからプラットフォーム課金ルートにトラフィックを自動的に移行すると、予期せぬ料金、ポリシー違反、またはデータ処理の変更が発生する可能性があります。 統合 AI API 請求を備えた製品では、その動作を明示する必要があります。
サポート ツールもより正確になるはずです。ダッシュボードの状態としては、プロバイダーが構成された資格情報を拒否したことが示され、影響を受けたプロバイダーのルートが特定され、最後の失敗時間が表示される場合があります。これは、一般的なアップストリーム エラーよりも対処しやすいものです。企業顧客の場合、チームがリクエストが失敗したか、再試行されたか、別の請求パスに移動したかを説明できるように、監査ログにステータス コード、プロバイダー、認証情報の参照、およびルーティングの決定を保存する必要があります。
まだ不確実なことは何ですか
Cloudflare の変更ログでは、Google Vertex が特定の修正されたケースとして特定され、より広範なプロバイダー認証情報のコンテキストで イレブンラボの名前が挙げられていますが、公開メモには、すべてのプロバイダーと考えられるすべての認証情報の失敗の完全なマトリックスのようには読めません。ゲートウェイ オペレータは、拒否されたキー シナリオがすべて同じように動作すると仮定するのではなく、依存するプロバイダをテストする必要があります。
AI Gateway 上に構築されたプラットフォームの製品設計に関する質問もあります。それは、Cloudflare のエラー語彙をどの程度エンド顧客に公開する必要があるかということです。生のコードは開発者にとって便利ですが、再販業者のポータルでは多くの場合、「ゲートウェイ課金が利用不可」や「プロバイダーが一時的に利用不可」とは別に、「プロバイダーの認証情報が拒否されました」など、より耐久性のある顧客向けのカテゴリが必要です
大きな方向は明らかです。 AI ゲートウェイは、モデル呼び出しの単純なパススルー プロキシではなくなりました。これらはポリシーと課金のコントロール プレーンであり、エラー セマンティクスのわずかな違いによって、システムが再試行するか、フェイルオーバーするか、顧客に請求するか、管理者にプロバイダー アカウントの再接続を要求するかが決まります。