ユーザーのクエリ内容・複雑さ・コスト制約に応じて、最適なLLMモデルへリクエストを自動振り分けする技術。簡単な質問にはHaikuクラスの軽量モデル、複雑な推論にはOpusクラスの高性能モデルを割り当てることで、品質とコストを同時に最適化する。
LLM Model Routing（LLMモデルルーティング）とは、受信したプロンプトやクエリの特性を分析し、複数のLLMモデルの中から最適なモデルへ自動的にリクエストを振り分ける技術である。単一のモデルですべてのリクエストを処理するのではなく、タスクの複雑さ・要求品質・レイテンシ制約・コスト予算に基づいて動的にモデルを選択する。
LLMの運用コストはモデルサイズに比例して増大する。例えば、Claude Opus 4は入力$15/MTok・出力$75/MTokであるのに対し、Claude Haiku 4.5は入力$0.80/MTok・出力$4/MTokと約19倍の価格差がある。しかし全リクエストをHaikuで処理すると複雑なタスクの品質が低下する。
実際の本番トラフィックでは、70-80%のリクエストは単純な質問・定型応答・分類タスクであり、軽量モデルで十分対応できる。残りの20-30%が複雑な推論・コード生成・長文分析などの高難度タスクである。モデルルーティングはこの分布を活用して、平均コストを50-70%削減しながら品質を維持する戦略である。
| 指標 | 説明 | 軽量モデル判定条件 | 高性能モデル判定条件 |
|---|---|---|---|
| クエリ複雑度 | 構文解析・意図分類による難易度 | FAQ・単純分類・挨拶 | 多段推論・コード生成・分析 |
| トークン数 | 入出力の想定トークン量 | 入力<500tok・出力<200tok | 入力>2000tok・出力>1000tok |
| ドメイン | タスクの専門分野 | 一般知識・日常会話 | 医療・法律・金融 |
| レイテンシ要件 | 応答時間の制約 | リアルタイム（<1s） | バッチ処理（許容>10s） |
| コスト予算 | ユーザー/テナント別の予算上限 | 予算残少 | 予算潤沢 |
正規表現やキーワードマッチングで振り分ける最もシンプルな手法。「こんにちは」系は軽量モデル、「コードレビューして」系は高性能モデル、のようなルールを静的に定義する。実装が容易だが、曖昧なクエリへの対応が困難。
BERTやDistilBERTなどの小型分類器でクエリの難易度を予測し、閾値に基づいてモデルを選択する。ルールベースより柔軟だが、分類器の学習データが必要。
軽量LLM（Haiku相当）にクエリの難易度を判定させ、その結果に基づいて本番モデルを選択する。「メタLLM」がルーターとして機能する構成。判定精度は高いが、ルーター自体のコストが加算される。
クエリの埋め込みベクトルを生成し、事前定義されたクラスタ（簡単/中程度/困難）との距離でモデルを決定する。セマンティックな判定が可能で、ルーターのレイテンシオーバーヘッドが小さい。
| プラットフォーム | ルーティング方式 | 対応モデル | 特徴 |
|---|---|---|---|
| LiteLLM | ルールベース+フォールバック | 100+プロバイダ | OSS、OpenAI互換API、コスト追跡 |
| Martian Router | ML分類器 | 主要クラウドLLM | 品質予測ベースの自動ルーティング |
| Portkey AI Gateway | ルールベース+重み付け | 200+モデル | エンタープライズ向け、A/Bテスト対応 |
| Unify AI | ベンチマーク連動 | 主要クラウドLLM | 品質/コスト/速度の三次元最適化 |
基本的なルーティングロジックの構成：
一般的なチャットボット運用での試算（月間100万リクエスト）：
A1: あります。複雑なクエリを軽量モデルに誤送信すると品質が低下します。対策としてカスケードルーティング（軽量モデルの応答品質が低い場合に自動的に上位モデルへエスカレーション）や、信頼度スコアに基づく動的再ルーティングが用いられます。
A2: ルールベースは1ms未満、分類器ベースは5-20ms、LLMベースは100-500ms程度です。LLMの応答時間（500ms-数秒）と比較すると、ルールベースと分類器ベースのオーバーヘッドは無視できるレベルです。LLMベースルーターはコスト削減効果がオーバーヘッドを上回る場合にのみ採用を検討します。
A3: まずLiteLLMなどのOSSゲートウェイを導入し、ルールベースのシンプルなルーティングから始めることを推奨します。本番トラフィックのログを2-4週間収集し、クエリの難易度分布を把握してからルールを最適化するアプローチが低リスクで効果的です。