誰もがLLMルーターを構築しているが、我々はそれを非推奨にした

私たちはもうモデルルーティングを信じていません。ほとんどのユースケースでは、単一の十分にテストされたモデルに固執するのが最善のことです。 最近、リクエストに対してオンザフライでモデルを選択するAIモデルルーターの周りで大きな話題となっています。推論コストの削減を謳う同様の発表がここ数週間で多数ありました。私たちもLLMルーターを持っていましたが、それを削除することにしました。 まず、背景を説明します。私たちは3月にManifest LLMルーターをLLMゲートウェイの主要機能としてローンチしましたが、6月にそれを非推奨にし、9月1日に完全にシャットダウンしました。私たちのルーターは、各リクエストを単純、標準、複雑、推論の4つの異なる複雑さのレベルに分類していました。ほとんどのLLMルーターと同様に、私たちのルーターもコスト削減のために作られていました。単純なタスクに、強力で高価なモデルを呼び出すのはなぜでしょうか？最もコスト効率の良いモデルにルーティングするのは、当然の解決策のように思えますよね？しかし、それほど単純ではありません。 7000人のクラウドユーザーによる4ヶ月間の使用を経て、私たちは混合的な結果と、それに関する多くのGitHubのIssueや議論を目にしました。主な問題点を掘り下げてみましょう。 プロンプトだけでは複雑性を推測できない プロンプトだけではタスク全体が含まれているわけではなく、それは単なるトリガーにすぎません。複雑性を決定する多くのコンテキストは、ツールの呼び出しやウェブ検索などを通じて後から発見されるものです。例を挙げましょう。「リポジトリ$GIT_REPOのテストを評価して改善する」というリクエストは、プレーンなHTML5で書かれた個人ウェブサイトを対象とする場合は非常に単純なタスクかもしれませんが、Linuxカーネルリポジトリを対象とする場合は信じられないほど複雑なタスクになり得ます。 キャッシュはルーティングよりもコスト削減に効果的 キャッシュの読み取りは、キャッシュされていない入力よりも75%から90%安価です。システムプロンプトや会話履歴は、しばしば多くのトークンを表します。プレフィックスキャッシュは、プロンプトの先頭にあるため、これらに対して非常にうまく機能します。キャッシュを認識するモデルルーターは、最初に選択されたモデルにスティッキーさ（固執性）を追加し、それをクエリし続けることによって、それを考慮に入れます。言い換えれば、ルーターは皮肉なことに、それをしないことによってその仕事をすることになります。 LLMルーターは動作の一貫性を損なう 「エンジニアは、タスクに最適なLLMを選択することを気にかけるべきではない」と言う人もいます。しかし、私たちは強く反対します。画家がどの筆を使うべきかを正確に知っており、職人が道具を注意深く選ぶように、エンジニアは異なるモデルのトレードオフと微妙な違いを理解する必要があります。Manifestでは、すべてのエンジニアが意図に基づいてモデルと努力パラメータを選択します。作業セッション中にモデルからモデルへとジャンプすることは、全体的な作業の質を低下させ、人々がツールを習得することを妨げます。 予測不可能性にはコストがかかる 誰も予測不可能性を好みません、特にソフトウェアエンジニアは。自動化されたエージェントワークフローや自律エージェントでは、その追加の不確実性のレイヤーを管理することは、節約できる以上のコストがかかる可能性があります。評価、システムプロンプト、オブザーバビリティなどを考えてみてください。すべてが突然、維持するのが難しくなります。異なるリクエストを分離し、それらに適切なモデル、パラメータ、プロンプトを設定することは、ほとんどの場合、自然に優れているように思えます。 結論 LLMルーティングが有用である可能性のあるユースケースはたくさんあり、それらをローンチした企業にはおそらく正当な理由があるでしょう。しかし、私たちの経験に基づくと、私たちが目にしたほとんどのユースケースでは、それだけの価値はないと結論付けました。節約された金額はどこかで支払われ、そのコストは推定がより困難です。