モデルルーターは「どのモデルを最初に使うか決めるのに役立つ」スケジューリングレイヤーとして理解できます。 質問に直接答えるわけではなく、要求がシステムに入った後、タスクの種類、予算、速度要件、コンテキストの長さ、ツール要件などに応じて、より適切なモデルや提供者にリクエストを分配します。 近年、マルチモデルが選択式問題から運用問題へと変化し、多くの製品が一つのモデルだけで世界を支配できなくなったため、この概念はますます人気を集めています。
初期の頃、多くのチームは非常にシンプルでした。最も強力なモデルを選び、すべてのシナリオで使うというものでした。 問題はすぐに明らかになりました。 最も高価なモデルである廃棄物の単純な作業; 長いコンテキストタスクはウィンドウモデルが短く、クラッシュします。 低遅延を必要とするリアルタイムシーンは遅いモデルで、体験も悪くなります。 その結果、ますます多くのチームがモデルの前面にルーターを追加し、システムが最初にトリアージを行い、その後誰が応答するかを決めるようになった。
良いモデルルーターは通常、複数の種類の信号を組み合わせています。 例えば、それがコードなのか、数学なのか、長いドキュメントなのか、音声リアルタイムのタスクなのか、どのプロバイダーが現在より安価か安定しているか、モデルが現在の制限をトリガーしたか、コンテキストが閾値を超えているかなどが問題です。 実際にはリアルタイムのトレードオフであり、品質、コスト、遅延の間でより良い解決策を見つけることです。
これもモデルゲートウェイとの違いの一つです。 ゲートウェイは、統一認証、ログ、請求、互換性インターフェースを担うインフラ入口です。 ルーターはより意思決定権を持ち、「今回は誰が行くか」を決める責任があります。 もちろん、現実のシステムでは両者はしばしば一緒に現れるので、みんなで一緒に話し合います。
なぜ今ではますます標準的なものになってしまったのでしょうか? モデル生態系があまりにも速すぎるからです。 新しいモデルが絶えず登場し、価格は絶えず変わり、能力の境界も変わっています。 もし積がデッドオーダーモデルを書くなら、反復速度は低下します。 ルーティング層が独立していれば、チームはモデルの変更、A/Bの管理、コスト管理、そして収益管理をより柔軟に行えます。 企業向けアプリケーションでは、単に最強モデルを追いかけるよりも現実的です。
しかしルーターは単に追加するわけではありません。 評価基準、予備ロジック、監視、履歴データサポートが必要です。 あまりにも致命的すぎるルーティングルールはシステムをますます複雑にします。 ルーティングを別のモデルに任せると、追加のコストや遅延が増える可能性があります。 さらに厄介なのは、一度ルートが間違っていると、ユーザーはたいてい「今日この製品はどうしておかしくなったんだ」としか考えず、トリアージ戦略に問題があることに気づくことはほとんどないということです。
したがって、Model Routerの人気は業界の焦点が「利用可能なモデルがあるかどうか」から「マルチモデル機能の組織化」へとシフトしたことを示しています。 将来的には、多くのAI製品がアシスタントのように見えますが、実際にはスケジューリングシステムのような存在です。 ユーザーは答えしか見ておらず、実際に最初に決定を下すのはルーティング層であることが多いです。
