CloudflareがWorkers AIとAI Gatewayを単一のコントロールプレーンに統合

CloudflareはWorkers AIとAI Gatewayの境界を崩しています。ホスト型モデル推論用と任意のプロバイダーへのプロキシ用という2つの別々の製品として始まったものが、今や単一のコントロールプレーンに収束しています。目標は、単一のエントリーポイント、単一の請求システム、単一のログセット、そして最終的にはプロバイダーではなくモデルを重視するルーティングです。

単一のバインディング、単一のAPI、選択の余地なし

最初のステップはエントリーポイントの統合です。Workers AIバインディングとREST APIはどちらも同じパスを通るようになり、gatewayオプションでゲートウェイIDを指定できます。ゲートウェイを作成したことがない場合、defaultを渡すと初回使用時に自動的に作成されます。REST APIでも同様で、cf-aig-gateway-idヘッダーで対応できます。

つまり、Workers AIとAI Gatewayのどちらかを事前に選択する必要がなくなります。すべての呼び出しでデフォルトでオブザーバビリティ、ロギング、コスト追跡が得られ、後でカスタムキャッシュやトラフィック分割用に名前付きゲートウェイを作成するオプションもあります。

セットアップ不要のオブザーバビリティ

以前はWorkers AIトラフィックの可視性を得るには、AI Gatewayを明示的に設定する必要がありました。現在では、デフォルトゲートウェイがリクエスト/レスポンスロギング、モデルごとのトークン数、コスト帰属を自動的に提供します。ダッシュボードにはレイテンシの内訳、エラーレート、正確なプロンプトとレスポンスが表示され、モデルの動作をデバッグしたり出力を監査したりするチームにとって大きなアップグレードです。

統一請求と引き上げられたレート制限

Cloudflareはまた、AI GatewayのクレジットをWorkers AIで使用できるようにしています。ウォレットにチャージして、OpenAI、Anthropic、Workers AI、またはサポートされている任意のプロバイダーで使用できます。インセンティブとして、統一請求を使用するとWorkers AIモデルのレート制限が引き上げられ、詳細は開発者向けドキュメントに記載されています。

モデルファーストルーティングの展望

より大きな狙いはモデルファーストルーティングです。プロバイダーを指定する代わりに、モデルを指定してゲートウェイにプロバイダー選択、フェイルオーバー、ロードバランシングを任せます。Workers AIにキャパシティがあればマネージドインフラを利用でき、キャパシティに達している場合は同じ重みをホストする別のプロバイダーにトラフィックが移行します。これはアプリケーションレベルのリトライなしで回復性を向上させるように設計されています。

さらに、Cloudflareはスマートルーティングに取り組んでいます。Workers AI上の分類器がプロンプトを読み取り、タスクタイプと複雑さを予測し、厳選されたプールから最適なモデルを選択します。これはまだ内部パイロット段階ですが、ゼロコンフィグパスが独自のルーティングロジックを維持する必要性をなくす可能性があります。

はじめに

既存のWorkers AIユーザーは、デフォルトゲートウェイを介したルーティングを開始して、すぐにロギングとコスト帰属を得ることができます。AI Gatewayユーザーは、モデルを呼び出してウォレットにチャージするだけでWorkers AIを追加できます。統合コントロールプレーンは現在利用可能で、モデルファーストルーティングは今後数ヶ月でパイロット運用が開始されます。