← 一覧へ戻る

AI / ルーティング

LiteLLMのRouter機能について

作成日: 2026年6月23日

要点

  • 質問の「Routet」は LiteLLM の Router を指す前提で整理します。
  • LiteLLM の router は 1 つの機能ではなく、基本の load balancing、semantic auto routing、complexity routing、adaptive routing、fallback を含む系統です。
  • まず使うべき土台は通常の Router で、内容ベース振り分けが必要なときだけ auto / complexity / adaptive を追加するのが自然です。

結論

LiteLLM の Router 機能は、単なる「複数 API に round-robin する機能」ではありません。2026年6月23日時点の公式 docs では、可用性のための load balancing と fallback を土台にして、内容ベースの Auto Routing、ルールベースの Complexity Router、学習型の Adaptive Router まで用意されています。

LiteLLM Router Load Balancing 同一 alias 内で 配分と再試行 Fallbacks 失敗時に 別 model へ退避 Auto Routing embedding 類似度で intent 振り分け Complexity ルールベースで 難度別に分岐 Adaptive 実績学習で cost と quality 調整
LiteLLM の Router は、可用性系の機能と最適化系の機能をまとめて抱える入口です。

基本のRouterは何をするか

LiteLLM の基本 Router は、同じ model_name に複数 deployment をぶら下げて、どれに送るかを選ぶ層です。OpenAI と Azure OpenAI、あるいは複数リージョンの Azure deployment を 1 つの alias にまとめて扱えます。

  • 同一 alias 内で load balancing します。
  • 失敗時は retries、timeouts、cooldowns を組み合わせて別 deployment に逃がせます。
  • SDK でも Proxy Server でも使えます。
  • routing strategy は simple-shuffle が既定かつ production 推奨です。

Auto Routingとは

Auto Routing は semantic routing です。入力メッセージの embedding を作り、route ごとに用意した utterance 群との類似度で、どの model へ送るかを決めます。

入力メッセージ Embedding utterance 群と 類似度比較 最大 score threshold 超過を確認 対象 model
route の順番ではなく、全 route を横断した最大類似度で選ばれるのがポイントです。
  • embedding model が別途必要です。
  • router.json に utterance、description、score_threshold を定義します。
  • 意図別の振り分けに向きます。例: coding は Claude、要約は GPT、のような分岐です。
  • embedding 呼び出しぶんの追加レイテンシと追加コストがあります。

Complexity Routerとは

Complexity Router は semantic routing の別案です。embedding API を呼ばず、ルールベースのスコアリングで「簡単」「中程度」「複雑」「reasoning」を見積もって tier ごとの model に送ります。

速い

docs では sub-millisecond latency とされています。

安い

routing のための追加 API call が不要です。

向き先

intent 分類より cost optimization 寄りです。

  • token 数、code presence、reasoning markers、technical terms など 7 次元でスコアします。
  • reasoning marker を 2 個以上検出すると、重み付き合計を待たずに REASONING tier に送る特例があります。
  • 簡単な問い合わせを安い model に逃がしたいときに向いています。

Adaptive Routerとは

Adaptive Router は beta 機能です。cheap model と expensive model のどちらを出すべきかを、過去の満足シグナルと request type ごとの実績から学習します。

  • LiteLLM Proxy と Postgres が必要です。
  • request type は code_generation、technical_design、factual_lookup など 7 分類です。
  • weights.quality と weights.cost で、品質優先かコスト優先かを調整します。
  • 起動初期は宣言した quality_tier に頼り、十分なサンプルがたまると実績主導へ寄ります。

Auto Routing が「事前に route を設計する」方式なのに対し、Adaptive Router は「運用しながら学ぶ」方式です。運用の重さは増えますが、固定ルールのチューニング作業は減らせます。

FallbackとBudget Routingの位置付け

Router を production で使うなら、model selection より先に reliability を押さえる必要があります。LiteLLM docs では fallbacks と budget routing が別ページで整理されています。

  • Fallbacks は model_name 単位で次の候補へ順番に退避します。
  • content_policy_fallbacks、context_window_fallbacks、通常の fallbacks を分けて持てます。
  • Budget Routing は provider ごとの spend を見て、予算超過した provider を routing 対象から外します。
  • Budget Routing は Redis 前提です。

どれを選ぶべきか

まず導入

基本 Router + fallbacks。最初の production 入口です。

意図別分岐

Auto Routing。route 設計を明示したいときです。

コスト最適化

Complexity Router。まず安く速く試せます。

  • 運用品質を上げたいだけなら、Auto Routing より前に fallback、timeout、cooldown を整えるべきです。
  • 入力内容に応じて専門モデルへ振りたいなら Auto Routing です。
  • 難問だけ高価な model へ寄せたいなら Complexity Router が始めやすいです。
  • 実トラフィックの学習で自動最適化したいなら Adaptive Router ですが、beta と Postgres 前提を受け入れる必要があります。

まとめ

LiteLLM の Router 機能は、可用性のための gateway 機能と、品質対コストの最適化機能が重なった集合です。最初の土台は基本 Router と fallback で、その上に intent 重視なら Auto Routing、コスト重視なら Complexity Router、継続学習まで欲しければ Adaptive Router を足す、という順番で考えると整理しやすいです。

参考URL