LLMのモデルルーティングとカスケード設計｜全部を最上位モデルに投げないための振り分け基準と、判定ミスの被害を小さくする作り方

LLMアプリを本番で回し始めてしばらくすると、請求額を見た誰かが言い出します。「この問い合わせの半分くらいは、あいさつや定型の質問ですよね。全部に最上位モデルを使う必要はあるんですか」。もっともな指摘です。そこで安いモデルを混ぜることになり、最初に書かれるのはたいていif len(text) < 200: model = smallのような1行です。これでコストは確かに下がります。ところが数週間後、「短いけど難しい質問」に小さいモデルが自信たっぷりに間違えた回答を返していた、という報告が上がってきます。

この記事は、その1行を設計に置き換える話です。リクエストごとに使うモデルを変える方法には、入力を見て振り分けるルーティングと、小さいモデルから試して検証に落ちたら上位へ回すカスケードの2つがあります。どちらを選ぶにしても、中心になる問いは同じです。何を根拠に振り分けるのか。振り分けを間違えたとき、何が起きるのか。研究の裏付けにはFrugalGPTとRouteLLMを使いますが、論文が示した削減率はその論文の条件での結果であり、自分のサービスで同じだけ下がる保証はありません。数字は条件とセットで紹介します。

ルーティングとカスケードを、まず言葉として分ける#

「モデルを使い分ける」と一口に言っても、実装の形は大きく2つに分かれます。混ざったまま議論すると、遅延やコストの見積もりが噛み合いません。

RouteLLMの論文は、この違いをはっきり書いています。FrugalGPTのようなカスケードや、小さいモデルに自己検証させてから大きいモデルへ回すAutoMixは複数回のLLM呼び出しに依存するため遅延が増えうる、それに対して自分たちの方式は各クエリを1つのLLMに送る、という整理です。またルーティングは報酬モデルと違って、回答が生成される前に適切なモデルを選ぶ必要があり、そのためにはクエリの難しさとモデルの能力を理解しなければならない、とも述べています。つまりルーティングは判定材料が少ないかわりに速く、カスケードは判定材料が多いかわりに遅い、というトレードオフです。

実務では、この2つを組み合わせることも普通にあります。入力を見て明らかに難しいものは最初から上位へ送り、それ以外を小さいモデルで試してから検証する、という形です。以降は、ルーター(ルーティングの判定器)と、カスケードの昇格基準を分けて見ていきます。

最初に確かめること:振り分ける価値があるか#

設計に入る前に、振り分けで削れる余地がどれくらいあるかを見積もってください。ここを飛ばすと、手間をかけたのにほとんど下がらない、ということが起こります。

見るべきは、トラフィックの中身の偏りです。ログから無作為に200〜300件を抜き、「小さいモデルでも十分に答えられそうか」を人が大まかに仕分けてみます。その割合が1割程度なら、振り分けで得られる削減は小さく、先にプロンプトの短縮やキャッシュ、バッチ化を検討するほうが効きます。逆に定型の質問が大半を占めるなら、振り分けの効果は大きくなります。

もう1つは、コストがどこで発生しているかです。1リクエストあたりのトークンの大半が、長いシステムプロンプトや参照文書の再送で占められているなら、モデルを安くするより、まずそこをキャッシュで削るほうが先です。後で触れるとおり、ルーティングはキャッシュの効きを悪くする方向に働くため、両方をまとめて皮算用すると見誤ります。

ルーターの3種類:ルールベース・分類器・LLM判定#

入力を見てモデルを選ぶ判定器には、大きく3つの作り方があります。

ルールベース:地味だが、最初に置くべきもの#

もっとも軽視されがちですが、実務で最初に効くのはこれです。「FAQ画面からの問い合わせ」「社内規程の検索」「契約書のレビュー」のように、機能や画面ごとに求められる能力がはっきり違うなら、それ自体が強い判定材料になります。判定の理由をログに1行で残せるので、事故が起きたときに原因を追えるのも利点です。

弱いのは、入力の表面から難しさを推し量る使い方です。冒頭の「短ければ小さいモデル」がその典型で、短くて難しい質問(「この条項は有効ですか」)も、長くて簡単な質問(ログを貼り付けて「これを箇条書きにして」)も普通にあります。ルールで扱うなら、難しさではなく、機能や用途のように確実に分かるものを根拠にしてください。

分類器:データを作り続けられるなら強い#

RouteLLMは、この系統を研究として詰めた例です。強いモデルと弱いモデルのどちらの回答が好まれるかという人間の選好データ(Chatbot Arenaの公開データ)から、「このクエリで強いモデルが勝つ確率」を予測するモデルを学習し、その確率が閾値を超えたら強いモデルへ送ります。ルーターとして、類似度重み付きランキング、行列分解、BERT分類器、因果LLM分類器の4種類を試しています。

同じ論文で見逃せないのは、学習データと実際の質問の分布がずれると性能が落ちる、という結果です。Chatbot Arenaのデータだけで学習したルーターは、MMLUやGSM8Kでは質問の大半が分布外になるため性能が振るわず、ゴールドラベルやGPT-4による判定でデータを拡張すると改善した、と報告されています。論文の限界の節でも、実運用の分布はベンチマークと大きく異なりうるので、少量のドメイン内データを集めて拡張することで改善できる、と書かれています。分類器を選ぶなら、評価データを継続して作る体制とセットで考えてください。

LLM判定:始めやすいが、判定にもお金と時間がかかる#

小さめのLLMに「この質問は簡単か難しいか」「どのカテゴリか」を答えさせる方法です。準備がほとんど要らないので、データがない立ち上げ期には現実的な選択肢です。ただし、判定のためにLLMを1回呼ぶ以上、そのぶんの遅延とコストが毎回乗ります。判定用のモデルが本番用の小さいモデルとほぼ同じ料金帯なら、判定をやめて最初から小さいモデルに答えさせ、カスケードで検証するほうが安いこともあります。

判定のぶれにも注意が必要です。同じ質問でも、言い回しによって判定が揺れます。判定の出力は自由記述にせず、easy/hardや定義済みのカテゴリの列挙に絞り、判定理由も短く残させると、後から検証しやすくなります。

カスケードで「上に回すか」を決める3つの基準#

カスケードは、小さいモデルの出力を見てから上位へ回すかを決めます。何をもって「この出力は信用できない」と判断するかで、信頼性が大きく変わります。

1. 専用のスコアリング:信頼できるが、作るのに手間がかかる#

FrugalGPTのカスケードはこの形です。論文によれば、カスケードの主要な要素は「生成のスコアリング関数」と「LLMルーター(どのAPIをどの順で並べるか)」の2つで、スコアリング関数は質問と回答のペアを受け取って0〜1の信頼度を返します。スコアが閾値を超えればその回答を返し、下回れば次のAPIを呼びます。スコアリング関数は、回答が正しいかどうかを質問と回答から予測する単純な回帰モデルとして学習できる、とされています。

論文のケーススタディ(金融ニュースの見出しから金価格の動きを判定するHEADLINESデータセット)では、DistilBERTを回帰用に調整したものをスコアリング関数に使い、予算をGPT-4のコストの5分の1に設定した条件で、GPT-J、J1-L、GPT-4の順に呼ぶカスケードが学習されています。GPT-Jの回答はスコアが0.96を超えれば採用、そうでなければJ1-Lを呼び、そのスコアが0.37を超えれば採用、それも下回ればGPT-4を呼ぶ、という形です。

この方式の強みは、判定器が回答生成とは独立に学習・評価されている点です。弱みは、正解付きのデータが要ることです。論文の限界の節も、カスケードの学習にはラベル付きの例が必要で、うまく機能するには学習データがテスト時と同じか近い分布から来ている必要がある、と明記しています。

2. 構造化出力の検証失敗:安くて確実だが、分かるのは形の崩れだけ#

出力をJSONで受け取る設計なら、パースできない、必須項目がない、列挙値が定義外、といった失敗は機械的に検出できます。コストはほぼゼロで、判定もぶれません。カスケードの昇格条件として最初に入れるべきものです。

ただし、この基準が拾えるのは形の崩れだけです。しかもスキーマ準拠を強制する機能を使う構成では、形の崩れ自体が起きにくくなります。OpenAIのStructured Outputsのドキュメントは、指定したJSON Schemaに従った応答を常に生成するため、必須キーの欠落や無効な列挙値を心配する必要がない、と説明する一方で、Structured Outputsの出力にも誤りは含まれうると書いています。拒否や出力トークン上限への到達で応答がスキーマに合わない場合がある点も同じページに記載があります。つまり「スキーマに通った」は「内容が正しい」ではありません。

形の検証に加えて、業務ルールでの検証を足すと、この基準はかなり強くなります。抽出した金額の合計が明細と一致するか、日付が契約期間の中に収まっているか、引用した条文番号が参照文書に実在するか。こうした整合性チェックは、正解データがなくても書ける検証です。

3. 自己評価:手軽だが、いちばん当てにならない#

小さいモデル自身に「この回答に自信があるか」を答えさせる、あるいは別の呼び出しで自分の回答を検証させる方法です。追加の学習が要らないので手軽ですが、信頼性はもっとも低いと考えてください。小さいモデルが間違えるのは、まさにその問題を理解できていないときであり、理解できていない問題について自分の回答の正しさを判定させても、同じ理由で外れやすいからです。

この方向を研究として詰めたAutoMixも、少数例による自己検証の仕組みを提案する一方で、アブストラクトの中で自己検証はノイズを含みうると認め、その不確かさを前提にしたルーターを別に設計しています。自己評価を使うなら、単独の昇格条件にはせず、他の基準と組み合わせる補助の信号として扱うのが安全です。

# カスケードの最小構成の擬似コード(エラー処理は簡略化)
# 前提: small / large は同じインターフェースのクライアント。
#       ALWAYS_LARGE はルールで上位固定にした機能の集合

def answer(req):
    # 0. ルールで上位固定の領域は、判定に触らせずに最初から上位へ
    if req.feature in ALWAYS_LARGE:
        return call(large, req, route="rule:always_large")

    first = call(small, req, route="cascade:small")

    # 1. 形の検証(スキーマ・必須項目・列挙値)。落ちたら上位へ
    if not schema_ok(first):
        return escalate(req, first, reason="schema")

    # 2. 業務ルールの検証(金額の整合、日付の範囲、引用の実在など)
    if not business_rules_ok(req, first):
        return escalate(req, first, reason="business_rule")

    # 3. 専用スコアラーがあれば使う。閾値は評価セットで決めた値
    if scorer and scorer(req, first) < THRESHOLD:
        return escalate(req, first, reason="low_score")

    return first


def escalate(req, first, reason):
    # 上位へ回した理由と、小さいモデルの出力を必ずログに残す。
    # ここが残っていないと、閾値の見直しも、昇格率の監視もできない
    log_escalation(req.id, reason=reason, small_output=first)
    return call(large, req, route=f"cascade:large:{reason}")

この擬似コードで大事なのは、判定の順番とログです。安くて確実な検証から先に置き、自己評価のような当てにならない信号は後ろに回すか、最初は入れずに始めます。そして、どの理由で上位へ回ったかを必ず記録します。昇格率が急に上がったとき、原因が形の崩れなのか業務ルール違反なのかで、打ち手がまったく違うからです。

判定ミスの被害は非対称#

振り分けの判定は、必ず一定の割合で間違えます。問題は、間違いの方向によって被害の大きさがまったく違うことです。

前者の被害はお金で、しかも上限が見えています。後者の被害は品質事故で、どこまで広がるか分かりません。しかもカスケードの検証をすり抜けた誤答は「検証済み」の顔をして出ていきます。したがって、判定器を評価するときは正解率だけを見ず、難しいものを簡単と判定した取りこぼしの率を別に見てください。閾値もこの非対称性を前提に、迷ったら上位へ倒れる側に置きます。

被害を小さくする設計としては、次のようなものがあります。

閾値は評価セットで「品質とコストの曲線」を描いて決める#

判定器の閾値を「0.5くらいで」と決めると、たいてい外れます。閾値は、品質とコストの曲線の上で選ぶものです。

RouteLLMの論文は、この曲線を評価の中心に置いています。ルーターの閾値を動かしながら、強いモデルへの呼び出し割合を横軸、全体の性能を縦軸に取った曲線を描き、「強いモデルと弱いモデルの性能差のうち何割を取り戻せたか」を指標にしています。あわせて、目標とする性能に届くために必要な強いモデルへの呼び出し割合の最小値も、評価指標として定義しています。比較対象は、同じ割合でランダムに振り分けるベースラインです。ランダムより良くなければ、そのルーターには意味がありません。

閾値は一度決めて終わりではありません。RouteLLMのリポジトリは、強いモデルへ回したい割合を指定して閾値を算出するキャリブレーションの手順を用意したうえで、閾値は既存のデータセットで較正しているため、実際に届くクエリによって各モデルへ回る割合は変わる、自分が受け取る種類のクエリに近いデータセットで較正することを勧める、と注意書きしています。本番では上位へ回った割合を日次で監視し、評価時の想定から大きくずれたら評価セットを作り直してください。

研究が示したこと、示していないこと#

2つの研究の数字は、導入の説得材料としてよく引用されます。引用するなら、条件とセットで扱ってください。

FrugalGPT(2023年5月にarXivで公開)は、アブストラクトで、最良の単一LLM(たとえばGPT-4)と同等の性能を最大98%のコスト削減で達成できる、あるいは同じコストでGPT-4より4%精度を上げられる、と報告しています。実験は、当時の5社の12種類のLLM APIを使い、HEADLINES(金融ニュース見出しの分類)、OVERRULING(法律文書の判定)、COQA(読解)などのデータセットで、カスケード長3に絞って行われています。いずれも答えの正誤を判定しやすいタスクで、スコアリング関数の学習にはそのデータセットの一部を使っています。

RouteLLM(2024年6月にarXivで公開、ICLR 2025採択)は、LMSYSのブログで、GPT-4だけを使う場合と比べて、GPT-4の性能の95%を保ちながらMT Benchで85%超、MMLUで45%、GSM8Kで35%のコスト削減を達成したと報告しています。強いモデルはGPT-4 Turbo、弱いモデルはMixtral 8x7Bで、学習にはChatbot Arenaの公開選好データと、その拡張データを使っています。LMSYSのブログでは、学習し直さずにClaude 3 OpusとLlama 3 8Bの組み合わせへ入れ替えても、MT Benchで元の組み合わせと同程度の性能が出たことも示しています(論文の最新版では、Claude 3 OpusとClaude 3 Sonnet、Llama 3.1 70BとLlama 3.1 8Bの2組で同様に検証しています)。ルーター自体の追加コストについては、最も重いルーターでもGPT-4での生成に比べて0.4%以下、と報告されています。

この2つが示しているのは、「条件が合えば、振り分けで大きな削減が得られる余地がある」ということです。示していないのは、「あなたのサービスでも同じだけ下がる」ということです。削減率は、モデル間の料金差、トラフィックの中で小さいモデルで足りる割合、判定器の精度の3つで決まり、どれもサービスごとにまったく違います。RouteLLM自身も、学習データと評価データが似ているほど性能が高いことを示し、限界の節で実運用の分布がベンチマークと大きく異なりうると書いています。FrugalGPTも、学習データとテストデータが同じか近い分布から来ている必要があると明記しています。自社での削減率は、前節の評価セットで自分で測るしかありません。

副作用:キャッシュ・ログ・観測がモデルごとに割れる#

振り分けを入れると、コスト以外のところで確実に手間が増えます。導入前の見積もりに入れておいてください。

プロンプトキャッシュの効きが悪くなる#

プロンプトキャッシュは、先頭から一致する入力の処理結果を再利用する仕組みです。OpenAIのドキュメントは、キャッシュの再利用にはレンダリングされたプレフィックス全体の一致が必要だと書いています。さらに、キャッシュされるプレフィックスに影響する設定の1つとしてmodelを挙げ、モデルが違えば重みもキャッシュの挙動も異なりうると説明しています。あるモデルで作られたキャッシュを、振り分け先の別のモデルで使い回せる前提では設計しないでください。

振り分けを入れると、同じ長いシステムプロンプトを使うリクエストが複数のモデルに分散します。それぞれのモデルに届く件数が減るので、キャッシュが有効期限内に再利用される確率も下がります。さらに、キャッシュできる最小の長さもモデルによって違います。Anthropicのドキュメントでは、最小キャッシュ長がモデルごとに512〜4,096トークンの範囲で示されており、あるモデルではキャッシュされていたプロンプトが、振り分け先のモデルでは短すぎてキャッシュされない、ということが起こりえます。

カスケードでは、この影響が二重になります。小さいモデルで一度処理し、上位へ回すと上位モデルで最初から入力を処理し直します。上位モデル側のキャッシュが冷えていれば、長いプロンプトを満額で払い直すことになります。キャッシュで入力コストを大きく下げている構成では、振り分けで出力側を安くしても、キャッシュのヒット率低下で入力側が高くなり、差し引きで思ったほど下がらないことがあります。

ログと観測が「どのモデルが答えたか」を前提にする必要がある#

振り分けを入れた瞬間から、品質の数字は「どのモデルが答えたか」で分けて見ないと意味をなさなくなります。全体の満足度が下がったとき、それが小さいモデルの担当範囲で起きているのか、上位モデルでも起きているのかで、原因がまったく違うからです。

ダッシュボードも、モデル別・判定理由別に切れるようにしておきます。見るべき指標は、上位へ回った割合、モデル別の品質指標、モデル別のキャッシュヒット率、判定を含めた総所要時間です。どれか1つだけを見ていると、コストが下がった裏で品質が落ちていることに気づけません。

モデル移行の手間が増える#

扱うモデルが1つから2つ以上になると、モデルの更新や廃止への追従もそのぶん増えます。しかも振り分けの閾値は、特定のモデルの組み合わせで評価して決めた値です。片方のモデルを新しい版に替えたら、評価セットで曲線を描き直す必要があります。RouteLLMは、学習し直さずに別のモデルの組み合わせへ入れ替えても性能が保たれたと報告していますが、これも前述の条件での結果です。入れ替えのたびに評価を回す前提で、評価の手順を自動化しておいてください。

レイテンシ:二段呼び出しで遅くなるケース#

カスケードのいちばん大きな弱点は遅延です。上位へ回したリクエストは、小さいモデルの応答を待ち、検証し、それから上位モデルの応答を待ちます。総所要時間は、概ね両方の所要時間と検証時間の合計になります。上位へ回る割合が小さければ平均への影響は限られますが、二段になったリクエストは一段で済んだものより遅くなりやすいため、遅いほうの裾(p95やp99)には上位へ回ったリクエストが集まりやすくなります。しかもそれは難しい質問、つまり利用者がじっくり答えを待っている質問です。

ストリーミングとの相性も悪くなります。小さいモデルの出力を検証してから返す構成では、検証が終わるまで利用者に何も見せられません。小さいモデルの出力をストリーミングで先に見せてしまうと、上位へ回したときに表示中の回答を差し替えることになり、利用者から見て不自然です。

ルーティングでも、判定そのものの遅延は乗ります。ルールベースならほぼゼロ、軽量な分類器ならごく小さく済みますが、LLM判定では1回分の往復が加わります。RouteLLMの論文は、ルーターごとに処理できるリクエスト数と費用を測って示し、単一モデルに比べた振り分けの負担を論点として扱っています。判定の遅延も、評価のときに総所要時間として測っておいてください。

振り分けに向かない場面#

入れないほうがよい場面を先に決めておくと、判断が速くなります。

トラフィックが少ないサービスは向きません。月の請求額が小さいなら、評価セットの作成と運用の手間に見合いません。上位モデル1本で運用し、件数が増えてから考えれば十分です。

誤答の被害が大きく、しかも誤答に気づきにくい用途も向きません。前述のとおり、取りこぼしの被害は品質事故として現れます。こうした用途で振り分けるなら、判定の対象から外すか、小さいモデルの回答すべてに検証をかける構成が必要になり、削減の余地はかなり小さくなります。

評価データを作れない、あるいは作り続けられないチームも、分類器やスコアリングを使う振り分けは避けたほうが安全です。閾値の根拠がないまま運用すると、トラフィックの変化で取りこぼしが増えても気づけません。その場合は、機能や画面単位のルールベースの振り分けにとどめ、判定理由を説明できる範囲で運用してください。

よくある質問#

まとめ#

全部を最上位モデルに投げない、という判断そのものは簡単です。難しいのは、何を根拠に振り分け、間違えたときにどうするかです。

振り分けには、答える前に選ぶルーティングと、答えを見てから上位へ回すカスケードがあります。ルーターはルールベース・分類器・LLM判定の3種類で、最初に置くべきは説明できるルールです。カスケードの昇格基準は、専用のスコアリング、形と業務ルールの検証、自己評価の順に信頼できます。そして判定ミスは非対称で、難しいものを簡単と判定する取りこぼしのほうが危険です。迷ったら上位へ倒し、被害の大きい領域は判定の対象から外してください。

閾値は評価セットで品質とコストの曲線を描いて決めます。FrugalGPTやRouteLLMが示した大きな削減率は、それぞれの条件での結果です。自社の削減率は、自社の評価セットで測るしかありません。導入の皮算用には、キャッシュのヒット率低下、モデル別に割れるログと観測、カスケードの二段呼び出しによる遅延も入れてください。この記事に書いた論文と各社ドキュメントの記述は、確認できた範囲にとどめています。仕様は改定されるため、採用時には必ず最新の公式情報を確認してください。