Cloudflare は、AI Gateway のパブリック ベータ版 Auto Router をリリースしました。これにより、すべてのルーティング決定をアプリケーション コードに任せるのではなく、ゲートウェイ層に自動モデル選択が追加されました。この新機能は、各リクエストを評価し、求められているタスクの種類を推定し、予想される品質、トークン コスト、レイテンシ、可用性シグナルを使用して適格なモデルから選択します。
モデル ルーティングがエンタープライズ AI インフラストラクチャの中核部分になりつつあるため、このリリースは重要です。複数のプロバイダーを使用しているチームにとって、難しい問題はモデルへのアクセスだけではなくなりました。どのモデルが特定のリクエストをどのコストとレイテンシの制約の下で処理すべきかを、後で決定を説明するのに十分な可視性を持って決定します。
Cloudflare の答えは、AI Gateway 内にそのロジックをさらに組み込むことです。 Auto Router は、最初に選択したモデルを試し、プロバイダーがリクエストを処理できない場合は、別の適格なモデルにフォールバックできます。これにより、ゲートウェイは API 呼び出しのパススルー プロキシだけでなく、ポリシーおよび実行ポイントになります。
変更点
このリリース前は、多くのチームがアプリケーション コード、オーケストレーション フレームワーク、またはカスタム ルーティング サービスでモデルの選択を処理していました。このアプローチは機能する可能性がありますが、製品やチーム全体でエンジニアリング作業が繰り返されることになります。すべてのアプリケーションは、コストルール、モデル設定、フォールバック動作、プロバイダ固有の処理をエンコードする必要があります。
Auto Router は、その決定の一部を Cloudflare AI Gateway に移します。 Cloudflareによると、ルーターはエッジに導入された分類器を使用してタスクの種類と複雑さを評価しているという。次に、期待される応答品質、トークン コスト、レイテンシー、モデルがリクエストに対応できるかどうかなど、いくつかの実際的な側面に基づいて、適格なモデルをスコアリングします。
この組み合わせは重要です。 「最初に最も安価なモデルを使用する」などの単純なルーティング ルールでは、より難しいタスクの出力品質が低下する可能性があります。常にフロンティア モデルにトラフィックを送信するルールでは、日常的な分類、抽出、書き換え、またはフォーマット ジョブで予算が無駄になる可能性があります。 Auto Router は、チームが許可した一連のモデル内で動作しながら、リクエストごとにトレードオフを行うように設計されています。
フォールバック動作により、運用状況も変わります。選択したプロバイダーがリクエストを処理できない場合、AI Gateway は別の適格なモデルを試行できます。運用システムの場合、プロバイダーの停止、レート制限、または一時的な容量障害の影響を軽減できます。また、フォールバック モデルは動作、コスト、レイテンシ、コンテキスト ウィンドウ、安全性プロファイルが異なる可能性があるため、チームは「適格」の意味について慎重に考える必要があることも意味します。
コスト管理にとって重要な理由
LLM の支出は、ルーティングの決定によって形作られることが増えています。同じユーザー向け機能には、短いプロンプト、長いプロンプト、キャッシュされたコンテキスト、ツール呼び出し、コード生成、および低リスクのバックグラウンド ジョブが含まれる場合があります。すべてのトラフィックを 1 つのモデルに送信するのは簡単ですが、経済的であることはほとんどありません。
自動ルーターは、ゲートウェイ レベルでの AI API コスト管理 への広範な移行を反映しています。企業は、モデルの選択を純粋に開発者が所有する選択として扱うのではなく、共有プラットフォームの問題として管理し始めることができます。これは、同じプロバイダー アカウント上で AI 機能を構築する複数のチームを持つ組織に特に当てはまります。
すべての導入において実際の効果が保証された節約であるわけではありません。 Cloudflareによると、Auto Routerはパフォーマンスを維持しながらAI支出を削減できるが、実際の結果はワークロードの組み合わせ、許可されるモデル、品質のしきい値、プロンプトのパターン、プロバイダーの切り替えに対する許容度によって左右されるという。ほとんどが困難な推論ワークロードを実行している企業では、日常的な要約、抽出、分類、サポートの自動化を大量に実行している企業に比べてメリットが少ない可能性があります。
それでも、方向性は明確です。コストの最適化では、手動で 1 つのモデルを選択することよりも、どのモデルが承認されるか、いつ安価なモデルを使用できるか、いつプレミアム モデルが必要か、いつフォールバックが許容されるかなどの制約を定義することが重要になってきています。
誰が影響を受けるか
マルチモデル アプリケーションを構築する開発者が最も直接的な対象者です。 Auto Router は、特にアプリケーションがすでに Cloudflare AI Gateway の背後にある場合に、維持する必要があるルーティング コードの量を削減する可能性があります。すべてのタスクを固定モデルに結び付ける代わりに、チームは適格なモデル セットを定義し、その境界内でゲートウェイに決定させることができます。
ゲートウェイが AI コントロール プレーンになりつつあるため、プラットフォーム チームとインフラストラクチャ チームは影響を受けます。ルーティング ポリシーがグローバルなのか、プロジェクト固有なのか、環境固有なのか、それとも製品リスクに関連付けられているのかを決定する必要があります。カスタマー サポート ボット、内部コーディング アシスタント、コンプライアンス ワークフローは、必ずしも同じ自動ルーティング動作を共有する必要はありません。
財務チームと運用チームも関係しています。自動ルーティングによってリクエストを処理するモデルが変わる場合は、コストの帰属を明確にしておく必要があります。ブレンド トークンの請求額が低いことは、どの製品、顧客、プロジェクト、または API キーが支出を生み出したかをチームが理解できる場合にのみ役立ちます。ここで、使用状況分析とタグ付けがルーティングの決定自体と同じくらい重要になります。
B2B LLM の顧客および同様のプラットフォームのユーザーは、より大きな市場の動きの一環としてこのリリースを読む必要があります。統合 API アクセスには、ガバナンス、分析、予算管理、ルーティング ポリシーが含まれることがますます期待されています。モデル カタログは 1 つのレイヤーのみです。そのカタログに関する運用ルールが差別化要因になりつつあります。
実際的な結果
最初の結果はポリシー設計です。自動ルーティングを採用しているチームは、どのワークロードがモデルの置き換えを許容できるかを文書化する必要があります。内部要約はリスクが低い可能性があります。契約分析、規制された顧客とのコミュニケーション、コード変更、またはエージェント ツールの使用には、より厳しい制約と明示的なレビューが必要になる場合があります。
2 つ目はテストです。自動ルーティングでは、評価の重要性が低下するのではなく、さらに重要になります。チームは、特にエッジケース、長いプロンプト、構造化された出力、安全性を重視したリクエスト、およびドメイン固有の用語について、許可する対象モデル全体で出力を比較する必要があります。ゲートウェイがモデルを選択できる場合、評価セットは単一のデフォルト モデルではなくルート セット全体をカバーする必要があります。
3 つ目は可観測性です。開発者は、どのモデルが選択されたか、フォールバックが発生したかどうか、レイテンシーとトークンの使用状況、コストがどのように割り当てられたかを示すログが必要です。この記録がないと、ユーザーが行動の変化を報告したり、財務チームが請求書が移動した理由を尋ねたりしたときに、自動ルーティングのデバッグが困難になる可能性があります。
4 つ目は、調達規律です。 Auto Router を使用すると、新しいプロバイダーやモデルを簡単に追加できますが、追加するたびにポリシーの対象範囲が拡大します。企業は、モデルが実験、内部ワークロード、運用顧客トラフィック、機密データ、または規制された使用に対して承認されるかどうかを決定する必要があります。これらのカテゴリは、非公式なチームの慣例に埋もれるのではなく、ゲートウェイ構成に反映される必要があります。
まだ不確実なことは何ですか
最大の未解決の問題は、Auto Router が実際のエンタープライズ ワークロードでどの程度優れたパフォーマンスを発揮するかです。 Cloudflareは設計と意図した節約について説明しましたが、本番環境の結果は異なります。一般的なプロンプトに対して良好なパフォーマンスを発揮するルーターには、特殊なコードベース、法律用語、医療コンテンツ、財務分析、または企業固有の知識作業を中心に慎重な調整が必要な場合があります。
また、チームが自動最適化と予測可能性のバランスをどのようにとるかも不明です。企業によっては、コストと回復力を理由にモデルの切り替えを歓迎する場合があります。監査、評価、または顧客体験の理由から、安定したモデルの動作を好む人もいます。おそらく結果は 1 つの普遍的なポリシーではなく、階層化された制御になります。つまり、機密性の高いワークフローには厳格なルーティング、ルーチン ジョブには柔軟なルーティング、新しいモデル候補には個別の実験が行われます。
Cloudflare のリリースは、製品の明確な方向性を示すものであるため、依然として重要です。マルチモデル ルーティングは、もはや単なるアプリケーション アーキテクチャ パターンではありません。これはマネージド ゲートウェイ機能になりつつあり、企業がモデル全体でコスト、信頼性、ガバナンスを管理できると主張するすべての AI プラットフォームへの期待が高まります。