モデルルーティングの複雑さとは
IBM Research の研究者らが、LLM のモデルルーティングが単純なラベル付けから始まるものの、コスト最適化や複雑な要件を満たすためには高度な推論と動的調整が必要になるという課題を指摘し、その解決策の重要性を説いている。
キーポイント
モデルルーティングの複雑性の本質
単純なタスク分類（例：翻訳か要約か）は容易だが、コスト、レイテンシ、精度、コンテキストの長さなど複数の制約条件を同時に最適化する「真の」ルーティングは極めて困難である。
静的ルールから動的推論へ
固定されたルールベースや単純な分類器では対応できず、入力内容やリアルタイムのコスト変動に応じて最適なモデルを判断する高度な推論機構が必要となる。
コストとパフォーマンスのトレードオフ管理
大規模モデルでなくてもタスクが完了できる場合でも、過剰な計算リソースを使わないよう、あるいは逆に複雑な問題には適切なリソースを割り当てるための精密な制御が求められる。
次世代ルーティングアーキテクチャの必要性
従来の手法では限界が見えており、より賢く適応的なルーティングシステム（例：LLM を用いたルーティングや強化学習ベースのアプローチ）の実装が業界の次のステップとなる。
重要な引用
Model Routing Is Simple. Until It Isn't.
The moment you add constraints like cost, latency, or specific model capabilities, the problem becomes significantly harder.
影響分析・編集コメントを表示
影響分析
この記事は、LLM の実運用において「どのモデルをいつ使うか」という意思決定が、単なる設定項目ではなく、システム全体の経済性と性能を左右する中核的なアルゴリズム課題であることを浮き彫りにしています。業界全体がマルチモデル環境への移行を進める中で、単純なラベル付けでは対応できない複雑な要件を満たすための新しいルーティング戦略の確立が急務であることを示唆しており、開発者やアーキテクトにとって重要な指針となります。
編集コメント
「モデルルーティング」という用語は、マルチモデル環境におけるリソース配分の最適化という文脈で急速に重要性を増しています。IBM Research のこの分析は、単なる技術的な課題提起にとどまらず、コスト効率を追求する実務家にとって、次のステップとしてどのようなアーキテクチャが必要かを示唆する重要な指針となっています。
- 1. コストはモデル価格だけではない
- 2. 複雑さはタスクの難易度だけではない
- 3. レイテンシはモデル速度だけではない
- では、私たちはどう対応したのか？
- 全体像
- おわりに
エージェントにルーターを組み込むのは、一見すると簡単な勝利のように思える。単純なリクエストを安価なモデルへ送り込み、難しいタスクには高価なモデルを割り当てる。あるいは専門性で振り分ける——コードなら Claude、マルチモーダルなら Gemini、といった具合だ。分類器やヒューリスティックが判断を下せば、コストは下がりパフォーマンスも維持される。これで完了。
しかし、現実はそう単純ではない。多くのルーティングシステムは、モデル選択を単なる分類問題だと考えている。だが、エージェントシステムにルーターを実装してきた私たちの経験では、一見するとモデル選択の問題に見えるものが、すぐにシステム最適化の課題へと変貌してしまう。私たちが直面した難しさには、主に 3 つの側面があった。
1. コストはモデル価格だけではない
GPT-4.1 は Claude Sonnet 4.6 より安価になると予想していたが、結果は逆だった。
CodeAct エージェントを用いて AppWorld Test Challenge の 417 タスクを評価したところ、Sonnet の総コストは 79 ドル（タスクあたり 0.19 ドル）だったのに対し、GPT-4.1 は 155 ドル（同 0.37 ドル）となり、ほぼ倍額になった。紙面上ではこれは説明がつかない。GPT-4.1 のトークン価格は入力・出力ともに Sonnet よりも安く設定されているし、Sonnet は同じタスクを完了するために推論ステップを約 3 倍必要としている。定価だけで見れば、GPT-4.1 が楽勝で勝つはずだ。
必ず JSON 形式で返してください。translation フィールドのみ。他のフィールドは一切追加しないこと — 余計なフィールドを書こうとして本文がトークン上限で打ち切られる事故を防ぐため:
{"translation": "リライト全文"}
その理由はキャッシュです。多くのルーティング議論ではこの点が完全に無視されています。
エージェントのワークロードでは、ステップ間でコンテキストの大きな断片が再利用される傾向があります。キャッシュヒット率が高い場合、実質的な入力コストは劇的に低下します。Sonnet はキャッシュ読み取り料金が安いため、このパターンから不釣り合いなほど恩恵を受けました。その結果、高い基本料金や長いトランザクション（トラジェクトリー）という不利さを克服できるまでになったのです。
結論として、実際のコストはモデル、ワークロード、そしてサービングインフラの相互作用によって決まります。単に価格表だけを見てルーティングを行うシステムでは、間違った数値に対して最適化を行ってしまっています。
2. 複雑さはタスクの難易度だけでは測れない
一般的なルーティング戦略として、「タスクがどれほど難しいかを推定し、難しいタスクをより強力なモデルに振り分ける」というものがあります。直感的には正しく見えますが、実は二つの点で破綻します。
第一に、ルーティング時点では難易度が見えないことが多いのです。「この契約書を要約して」といったリクエストは一見単純に見えますが、実際にはデータ取得やコンプライアンスチェック、ツールの利用、そして複数回の改良ラウンドを経て完了する場合があります。一方、非常に専門的なプロンプトであっても、小さな専用モデルによって効率的に処理できるケースがあります。タスクの実際の難易度がどれほど高いかは、実行が始まってみないとわからないのです。
第二に、仮にタスクの難易度を完璧に推定できたとしても、それは単なる一つの指標に過ぎません。本番環境では、ルーターはコスト、レイテンシ、モデルの専門性、信頼性を同時にバランスさせる必要があります。さらに企業向け展開では、コンプライアンス要件、データの所在地規制、プライバシー制約、承認済みモデルリストなど、追加の条件が重なります。本来ならあるモデルに振り分けるべきタスクも、ガバナンス上の理由で別のモデルへ回さなければならず、ルーターはこれを柔軟かつ適切に処理できなければなりません。
ルーターは単一の課題を解決するものではなく、コスト、品質、レイテンシ、コンプライアンス、信頼性という複数の要素を常に同時に調整し続けています。
3. レイテンシはモデル速度だけではない
「モデルサイズが大きいほど遅く、小さいほど速い」という単純な図式でレイテンシを考えがちですが、ユーザーが実際に体感する速度はそれだけでは決まりません。
ルーティング自体にもオーバーヘッドが発生します。さらに重要なのはインフラ要因です。モデルがどのハードウェア上で動作しているか、キャッシュが有効化されているか（ウォーム状態か）、エンドポイントの混雑状況などは、エンドツーエンドの応答時間を決定づける主要因となり得ます。理論上は高速なモデルでも、サービング環境が整っていなければ、ユーザー体験としては遅く感じられてしまいます。
また、ルーティングの粒度も影響します。タスクごとに一度だけルーティングする場合はオーバーヘッドは最小限ですが、実行中の各ステップで都度ルーティングを行うと、柔軟性は高まるものの、意思決定ポイントが増えるたびにレイテンシと運用複雑度が上昇します。
サービングシステムを無視したルーター設計は、現実の課題に対して間違った最適化を行ってしまっているのです。
これらの教訓が、私たちがルーターを構築する際の指針となりました。最大の転換点は、ルーティングを「分類問題」として扱うのをやめ、「最適化問題」として捉え直したことです。「どのモデルがこのタスクに最も適しているか？」と問うのではなく、アルゴリズムはコスト、品質、レイテンシのすべてを同時に最適化します。その上で、ルーター自身がボトルネックにならないよう、軽量な設計を維持しています。
下の図は、CodeAct エージェントを用いた AppWorld テストチャレンジでの結果を示しています。各青い四角形はルーターの異なる設定を表しており、コストと精度のトレードオフ曲線（フロンティア）を描いています。重要なのは特定の一点ではなく、コスト、レイテンシ、精度のいずれを優先するかによって、最適な運用ポイントを自由に選べる点です。
例えば、レイテンシ最適化の設定 1 では、84% の精度で $93、83 秒という結果が出ました。これは Opus モデル単体で実行した場合と比較して、コストが 21%、レイテンシが 9% 削減され、精度はわずか 4% しか低下しないことを意味します。設定 2 ではさらにコストを下げることが可能です。
標準的な難易度ベースのルーター（水色のダイヤモンド）も同程度の精度範囲に達していますが、コストが高くなっています。これは、最適化アプローチが持つようなトレードオフ空間全体を十分に探索できていないためです。また、最適化処理自体が軽量であること（タスクあたり約 6 ミリ秒、メモリ使用量は約 2 キロバイト）も幸いし、ルーターが前述したボトルネックになる心配はありません。
The Bigger Picture
この研究から得た教訓は、ルーティングの本質が「モデルを選ぶこと」にあるわけではないということです。重要なのはシステム全体の最適化です。モデルは変数の一つに過ぎず、キャッシュの挙動やインフラの状態、コンプライアンスの制約、ワークロードのパターンなど、数多くの要素の中の一つでしかありません。
ルーティングがうまく機能している場合、それは特定のタスクに対して「最良」なモデルを選んだからではありません。システム全体にとって最適な運用ポイントを見つけたからです。これは分類問題よりも難しい課題ですが、取り組む価値のある問題です。
今後の投稿では、このアプローチの技術的な詳細について詳しく解説する予定です。その間、ご自身でエージェント型システムにルーティングを実装されている方は、どのようなトレードオフに直面しているかぜひ教えていただければ幸いです。
謝辞
本記事は、多くの同僚との議論から影響を受けました。彼らの鋭い質問やフィードバック、そして洞察が、私たちの考え方を洗練させるのに大きく貢献しました。
原文を表示
- 1. Cost Is More Than Model Pricing
- 2. Complexity Is More Than Task Difficulty
- 3. Latency Is More Than Model Speed
- So How Did We Handle This?
- The Bigger Picture
- Acknowledgement
Building a router into your agent sounds like an easy win. Send simple requests to cheaper models, reserve expensive ones for harder tasks, or route by specialty — Claude for code, Gemini for multimodal, and so on. A classifier or heuristic makes the call, costs go down, performance stays up. Done.
Except it’s not. Most routing systems assume that model selection is a classification problem. In our experience building routing into agentic systems, what looks like a model-selection problem quickly becomes a systems optimization problem. Three dimensions made this surprisingly hard for us.
1. Cost Is More Than Model Pricing
We expected GPT-4.1 to be cheaper than Claude Sonnet 4.6. It wasn’t.
Across 417 tasks on the AppWorld Test Challenge using the same CodeAct agent, Sonnet cost $79 total ($0.19/task) while GPT-4.1 cost $155 ($0.37/task) — nearly double. On paper, this makes no sense. GPT-4.1’s token pricing is lower on both input and output, and Sonnet takes roughly three times as many reasoning steps to finish the same tasks. By sticker price alone, GPT-4.1 should win easily.
The explanation? Caching — something most routing discussions ignore entirely.
Agent workloads tend to reuse large chunks of context across steps. When cache hit rates are high, effective input costs drop dramatically. Sonnet’s lower cache-read pricing meant it benefited disproportionately from this pattern, enough to overcome both its higher base pricing and its longer trajectories.
The takeaway: actual cost depends on the interaction between the model, the workload, and the serving infrastructure. A router that only looks at pricing sheets is optimizing against the wrong numbers.
2. Complexity Is More Than Task Difficulty
A common routing strategy is to estimate how hard a task is and send harder tasks to stronger models. Intuitive, but it breaks down in two ways.
First, difficulty is often invisible at routing time. A request like "summarize this contract" looks simple, but might trigger retrieval, compliance checks, tool use, and multiple rounds of refinement before it’s done. Meanwhile, a highly technical prompt might be handled efficiently by a smaller specialized model. You often don’t know how hard a task actually is until execution is underway.
Second, even if you could perfectly estimate difficulty, it’s only one signal among many. In production, routers need to balance cost, latency, model specialization, and reliability simultaneously. Enterprise deployments pile on more: compliance requirements, data residency rules, privacy constraints, approved model lists. A task that would ideally go to one model might need to go elsewhere because of governance — and the router has to handle that gracefully.
Routers aren’t solving one problem. They’re constantly juggling cost, quality, latency, compliance, and reliability all at once.
3. Latency Is More Than Model Speed
It’s tempting to think about latency purely in terms of model size — bigger models are slower, smaller ones are faster. But what the user actually experiences depends on much more than that.
Routing itself adds overhead. Infrastructure factors — which hardware a model is running on, whether the cache is warm, how busy the endpoint is — often dominate end-to-end response times. A theoretically faster model can still produce a slower experience if the serving conditions aren’t right.
Then there’s routing granularity. Routing once per task adds minimal overhead. But routing at every step — which gives you more flexibility to adapt mid-execution — means every additional decision point introduces latency and operational complexity.
A router that ignores the serving system is optimizing against the wrong reality.
So How Did We Handle This?
These lessons shaped how we built our router. The key shift: we stopped treating routing as a classification problem and started treating it as an optimization problem. Rather than asking "which model is best for this task?", our algorithm optimizes across cost, quality, and latency simultaneously — while staying lightweight enough to avoid becoming a bottleneck itself.
The figure below shows the result on the AppWorld Test Challenge with a CodeAct agent. Each blue square is a different configuration of our router, tracing out a cost-accuracy frontier. The important thing isn't any single point — it's that the router gives you a range of operating points to choose from depending on whether you want to prioritize cost, latency, or accuracy. Configuration 1 (latency-optimized) lands at 84% accuracy for $93 and 83s — a 21% cost reduction and 9% latency reduction compared to running Opus alone, with only a 4% accuracy drop. Configuration 2 pushes cost even lower.
Notice that a standard difficulty-based router (the teal diamond) lands in a similar accuracy range but at higher cost — it doesn't explore the full tradeoff space the way an optimization-based approach can. And because the optimization itself is lightweight (roughly 6 ms and 2 kB of memory per task), the router doesn't become the bottleneck we warned about earlier.
The Bigger Picture
The lesson we took away from this work is that routing isn’t really about choosing models. It’s about optimizing systems. Models are one variable — an important one, but just one among caching behavior, infrastructure state, compliance constraints, and workload patterns.
When routing works well, it’s rarely because it found the "best" model for a given task. It’s because it found the best operating point for the entire system. That’s a harder problem than classification, but it’s the one worth solving.
We’ll be sharing more about the technical details behind our approach in a follow-up post. In the meantime, if you’re building routing into your own agentic systems, we’d love to hear what tradeoffs you’re running into.
Acknowledgement
This post was influenced by numerous conversations with colleagues, whose thoughtful questions, feedback, and insights helped refine our thinking.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み