LLMのモデルルーティングとは？小さいモデルと高性能モデルを安全に使い分ける
すべての依頼を最も高性能なモデルへ送れば構成は単純だが、分類や定型抽出まで同じモデルで処理すると、費用と待ち時間が増える。反対に、すべてを小さいモデルへ寄せると、曖昧な依頼や重要な判断で品質が落ちる。
モデルルーティングは、仕事の種類、難しさ、危険度、期限に応じて使うモデルや推論量を選ぶ仕組みである。目的は最安の一回を選ぶことではない。必要な品質を守りながら、一件の仕事が成功するまでの総費用と時間を小さくすることだ。
まず一つの高性能モデルで基準を作る
最初から複数モデルへ分けると、失敗がモデルの能力不足なのか、振り分けの誤りなのか分からない。まず高性能な構成で対象タスクを動かし、成功条件、評価データ、処理時間、トークン、道具の回数を測る。
OpenAIの本番運用資料も、能力の高いモデルで動作を成立させた後、同じ仕事をより小さいモデルで実現できるか調べる流れを示している。基準がなければ、安くなった代わりに何を失ったかを測れない。
評価は全体平均だけでなく、簡単な依頼、曖昧な依頼、長い文脈、安全上重要な依頼などに分ける。どの分類なら小さいモデルでも基準を満たすかを確認し、そこからルーティングを始める。
固定ルールで分けられる仕事を先に分ける
モデル自身に毎回難易度を判断させる前に、コードで確実に分けられる条件を使う。音声入力には音声対応モデル、画像には画像対応モデル、厳密な低遅延が必要な画面には応答の速いモデル、といった能力と運用要件による分岐である。
定型分類、明確なSchemaへの抽出、短い言い換え、既知のラベル選択は、小さいモデルの候補になりやすい。複数文書を横断する判断、曖昧な依頼、長い計画、専門的な検証は高性能モデルの候補になる。
ただし、入力長だけで難しさを決めない。短い質問でも、法的判断、安全上の判断、取消不能な操作を含む場合がある。仕事の形式と危険度を別の軸として扱う。
小さいモデルから必要時だけ昇格する
モデルカスケードでは、まず小さいモデルへ依頼し、その結果が受入条件を満たさない場合だけ高性能モデルへ送る。FrugalGPTの研究は、複数のLLMを組み合わせ、問い合わせごとに利用するモデルを選ぶカスケードを、費用と品質の両立方法として検討した。
重要なのは昇格条件である。モデルに「自信があります」と言わせるだけでは、その自信が正しさと対応しない可能性がある。次のような観測可能な信号を組み合わせる。
- 必須の出力Schemaを満たさない
- 参照すべき根拠を取得できない
- 複数回の判定が一致しない
- 安全性や権限に関する分類へ入る
- 評価器が合格基準を満たさない
- 道具の結果が不足または矛盾している
昇格時に、小さいモデルの回答をそのまま正しい前提として高性能モデルへ渡さない。元の入力、取得根拠、道具の結果を渡し、候補回答は参考情報として区別する。誤った初期回答が後段を誘導することを防ぐ。
ルーター自身を評価する
各モデルを単体で評価しても、ルーティング全体の品質は分からない。必要な依頼を高性能モデルへ送れなかった失敗と、簡単な依頼を不必要に昇格した無駄を分けて測る。
評価データには、各例の期待モデルを一つだけ固定するより、許容される経路と最終的な成功条件を持たせる。小さいモデルが正しく完了できたなら合格であり、難しい例を適切に昇格して成功した場合も合格である。
確認する指標には、最終品質、分類別の失敗率、昇格率、平均と上位の遅延、一件当たりの総トークン、総費用、再試行数、道具の回数がある。ルーターの精度だけを上げても、二段階処理で遅延が増え、利用者の体験が悪くなることがある。
特に、誤って小さいモデルへ送った場合の損失が大きい分類を個別に見る。権限変更や外部送信では、費用より安全性を優先し、最初から高性能モデルと人の承認へ送る選択がある。
安いモデルが総費用を下げるとは限らない
一回の単価が低くても、回答が長い、再試行が多い、検索や道具を繰り返す、人が修正するなら、成功までの総費用は高くなる。OpenAIの費用最適化資料は、小さいモデル、要求回数、トークン数を調整する考え方を示しているが、モデル選択は精度を保てることが前提である。
費用はAPI料金だけでなく、遅延、失敗による再処理、人の確認、外部道具、事故対応まで含める。高性能モデルが一度で終える仕事を、小さいモデルが三回試して昇格するなら、最初から高性能モデルへ送る方がよい場合がある。
入力を分類するためだけに別のモデルを一回呼ぶ設計も、処理時間と費用を増やす。コードで分けられる条件、既存のメタデータ、同じ呼び出しで得られる構造化判定を優先する。
失敗時のフォールバックを限定する
モデルAPIの一時的な失敗時に、別モデルへ切り替えるフォールバックは可用性を高める。ただし、代替モデルが同じ道具、出力形式、文脈長、安全要件を満たすとは限らない。
モデルごとの能力差を確認し、代替できる仕事だけを定義する。安全上重要な仕事では、性能の低いモデルへ自動で落とすより、操作を止めて再試行や人への引き継ぎを選ぶ。フォールバック後の回答には、異なる構成で処理したことを内部記録し、品質指標を混ぜない。
障害時に全通信が代替モデルへ集中すると、そちらの上限も超える。切り替え量、再試行回数、待ち時間を制限し、機能を縮小した応答も用意する。
ルーティング版を記録して小さく変更する
同じ入力でも、ルールの変更で異なるモデルへ送られる。結果を再現するには、選んだモデルだけでなく、ルーターの版、判断に使った分類、昇格理由、最終構成を記録する。
変更時は影の実行で、現行ルーターと候補ルーターがどの例で異なる判断をするか比較する。次に少量の通信へ出し、品質、遅延、費用、安全指標を確認する。平均費用が下がっても、重要分類の失敗率が上がれば広げない。
本番で誤った経路が見つかったら、その入力を匿名化してルーターの回帰例へ追加する。モデルの性能が更新されたときも、以前の分岐が妥当とは限らないため、同じ評価セットで再測定する。
モデルルーティングは、モデル名を条件分岐へ並べるだけの仕組みではない。仕事の境界、昇格条件、危険度、総費用を測り、誤った振り分けを回帰評価する運用である。固定ルールから小さく始め、成功一件当たりの品質、時間、費用で判断すれば、複数モデルを使う複雑さに見合う効果を確認できる。