なぜ今さら？LLMルーターの流行に逆行して、私たちは自社ツールを廃止しました

世間ではこぞってLLMルーターが開発されていますが、私たちはあえて自社製のルーターを廃止することにしました。

皮肉なことに、この記事の執筆や編集に人間が少なからず関わっているという確信が、このめちゃくちゃな一文のおかげで高まってしまった。

"A cache-aware model router will take that into account by adding stickiness to the initially chosen model and keeps querying it."

このルーティングの問題は不透明だと思うし、人々が予測しようとしているラベル自体に意味があるのかも怪しいと思ってる。

もし効率的なレスポンスを得るために、入力の複雑さをより高度に判別する必要があるなら、自分の環境に合わせてSFT（教師あり微調整）やRL（強化学習）でチューニングする方がよっぽど効果的だよ。

画家がどの筆を使うべきか正確に知っているように、職人が道具を慎重に選ぶように、エンジニアもモデルごとのトレードオフや微妙な違いを理解しておくべきだ。

この考えにはかなり懐疑的だな。現実的に考えて、毎週のように新しいモデルが出る中で、それらのニュアンスを理解する暇なんて誰にあるんだ？それに、学習プロセスが見えない以上、各モデルが何に優れているかを判断するなんて、壁にスパゲッティを投げつけて反応を見るようなもの。しかもそのスパゲッティは非常に高コストで、コードベースに厄介な問題を混入させる可能性だってある。

複雑さはプロンプト単体から推測できない。例えば「$GIT_REPOのテストを評価して改善せよ」というタスクは、HTML5で書かれた個人サイトなら単純だけど、Linuxカーネルのリポジトリ相手なら極めて複雑になる。

この例えはあまり良くないと思う。最初のステップはドキュメントを読み、テストの概要を把握し、テストを実行するコマンドを叩くことだよね。これは安価なモデルでもできる。でもその後の、テストがどれだけ複雑かをルーターが判断する部分が難しいわけだ。とはいえ、C言語のコードの塊とHTMLの区別がつかないほど難しいとは思えないけど。もし彼らが最初に選んだモデルをずっと変えたくないって言うなら、それは明らかにルーティングの正しいアプローチじゃない。

とにかく、ルーターなんて普遍的なものとして存在させる価値はほとんどないという点には同意する。リポジトリ内のコードやスキル、あるいは指示など、何かを変える方がずっと効率的だ。一度調整すれば永続的でポータブルだし、毎回複雑さを推測するよりずっと洗練されているからね。

昨年、LLMのルーティングをかなり深く調べたけど、結局のところ労力に見合わないという結論に至った。クエリの難易度を事前（a priori）に理解するのは難しすぎるんだ。

一つ具体的な課題として、難易度はそのエージェントがどの情報を取得できるかに大きく依存するということがある。「5状態のビーバー数は？」という質問を考えてみてよ（https://en.wikipedia.org/wiki/Busy_beaver ）。2023年ならMythosレベルの研究課題だったけど、2024年に解法が証明されたから、今ならウェブ検索ツールを持つ最低限の知能のモデルでも回答を持ってこれる。作業を始めてみるまで、どのクエリが単なる要約で済み、どれが深い推論を要するかなんて誰にもわからないんだ。

これは「クエリのコンテキストを理解しない汎用的なルーターシステムは役に立たない」という話に限定すべきだと思う。処理するワークロードの性質を理解し、最も効率的なモデルにリクエストを振り分けられるルーターなら、かなり良い結果が出ているよ。

最近、モデルルーターを構築する中で学んだルーティングの第一原理について書いた。

モデルプールは小さく保ち、プール内のモデルは明確に差別化しておくべきだ。例えば、品質重視の巨大なフロンティアモデルと、ルーティング作業用のDeepSeek V4 Flashのように高速で安価なモデルを組み合わせるといった具合に。

この2つの原則だけで、キャッシュの問題もルーティング判断の問題も解決できる。GPT-5.4とDeepSeekを切り替えながら運用しているけど、ルーティング時のキャッシュヒット率は安定して99%を超えているよ。

https://try.works/first-principles-of-model-routing

一つ付け加えると、コーディングエージェントのワークフローにおいて、特定のモデルに紐付けられたサブエージェントの役割を定義するのは非常に効果的だと感じてる。オーケストレーターが割り当てに必要なコンテキストを全て構築しているから、単なる「おバカなルーター」とは違うんだ。例えば探索やライブラリアンのタスクにMinimax M3を使うと高速で安い。月額10ドルのプランで十分足りるし、メインのコーディング用プランのトークンを大幅に節約できている。

インサイダー視点だけど、ルーティングという仕組みは、少なくともモデルプロバイダーの外部で行われる限り、成功したり長く続くものにはならないだろうね。

モデル開発ラボは、コストと知能の2次元フロンティアで競争しているから、この問題を自分たちで解決するインセンティブがあるんだ。知能を損なわずにコストを下げられるなら、彼らはそれを実行するし、コスト削減分の一部はユーザーに還元される。彼らは抽象化のより深いレベルに介入できる分、外部よりも優れた解決策を持っているからね。

例えば、推論時の「speculative decoding」はルーティングの一形態（かなり保守的だけど）と言えるわけで、これを外部からルーターとして実装するのは無理があるんだ。

君のルーターはどんなアーキテクチャだったの？もしGRPOやRLベースだったなら、なぜパフォーマンスが頭打ちになったのか興味があるよ。

結局のところ、効率的なコスト削減手段にはならないのが真実だと思う。ルーターは、利用するモデルの中で最も賢いもの以外の、すべてのモデルと同等の「賢さ」を持っていないといけない（モデル自体に「これは君が適したタスクか？」と聞いてもまともに答えられないからね）。つまり、高価なルーターモデルを使って、KVキャッシュやプレフィックスキャッシュを含めた複数のプロンプト履歴を保持しなきゃいけない。ほとんどの場合、それで節約できるほど甘くはないんだよ。