📄 論文解説: RouteLLM — 選好データに基づくLLMルーティングでコスト85%削減

本記事は RouteLLM: Learning to Route LLMs with Preference Data (arXiv:2406.18665) の解説記事です。

論文概要（Abstract）

大規模言語モデル（LLM）は多様なタスクで高い性能を示すが、高性能モデルほど推論コストが高く、すべてのリクエストに高性能モデルを使うのは非効率である。著者らは、人間の選好データを活用してリクエストごとに強モデル（GPT-4クラス）と弱モデル（GPT-3.5/Mixtralクラス）を動的に選択するルーターモデルを提案している。MT-Benchで85%超、MMLUで45%超、GSM8Kで35%超のコスト削減を、品質を維持しながら達成したと報告されている。

この記事は Zenn記事: Bedrock Intelligent Prompt Routingで社内RAGコスト最大60%削減 の深掘りです。

情報源

• arXiv ID: 2406.18665
• URL: https://arxiv.org/abs/2406.18665
• 著者: Isaac Ong, Amjad Almahairi, Vincent Wu, Wei-Lin Chiang, Tianhao Wu, Joseph E. Gonzalez, M Waleed Kadous, Ion Stoica（LMSYS / UC Berkeley / Anyscale）
• 発表年: 2024（初版: 2024年6月、v4改訂: 2025年2月）
• 分野: cs.CL, cs.AI, cs.LG
• コード: GitHub: lm-sys/RouteLLM（Apache 2.0）

背景と動機（Background & Motivation）

LLMの推論コストはモデルサイズに比例して増加する。GPT-4クラスの大規模モデルは高品質な応答を返すが、入出力トークンあたりのAPI料金は小型モデルの10〜30倍に達する。一方で、すべてのプロンプトが大規模モデルの能力を必要とするわけではない。「今日の天気は？」のような単純な質問にGPT-4を使うのは過剰であり、GPT-3.5やMixtralでも十分な品質の応答が可能である。

従来のアプローチとしては、FrugalGPT（Chen et al., 2023）のカスケード方式やLLM-Blender（Jiang et al., 2023）のアンサンブル方式が提案されていたが、これらはいずれもレイテンシの増大や複数モデルへの同時リクエストが必要という課題があった。RouteLLMは、リクエストの到着時点で単一のルーターが振り分け先を判定するため、追加のレイテンシが軽微であり、かつ不要なAPI呼び出しを回避できる点で実用上の優位性がある。

この課題設定は、Amazon Bedrock Intelligent Prompt Routing（IPR）が解決しようとしている問題と本質的に同一であり、RouteLLMはIPRの動作原理を理解するための学術的基盤を提供している。

主要な貢献（Key Contributions）

• 貢献1: 人間の選好データ（Chatbot Arenaの100万超のペア比較）を活用した4種のルーターアーキテクチャの設計と比較
• 貢献2: データ拡張手法の体系的な探索。選好データの品質と量がルーター性能に与える影響を定量的に分析
• 貢献3: ルーターの転移学習能力の実証。あるモデルペア（例: GPT-4 vs Mixtral）で学習したルーターが、異なるモデルペア（例: Claude 3 Opus vs Claude 3 Haiku）でも有効に機能することを示した

技術的詳細（Technical Details）

問題の定式化

RouteLLMはLLMルーティングを二値分類問題として定式化する。あるプロンプト $p$ が与えられたとき、ルーター関数 $r(p)$ は以下を出力する：

\[r(p) = \begin{cases} 1 & \text{（強モデルに送信）} \\ 0 & \text{（弱モデルに送信）} \end{cases}\]

実際の実装では、ルーターはスコア $s(p) \in [0, 1]$ を出力し、閾値 $\tau$ との比較で判定する：

\[r(p) = \mathbb{1}[s(p) > \tau]\]

ここで、

• $s(p)$: ルーターが出力するスコア（強モデルが必要な確率の推定値）
• $\tau$: ルーティング閾値（0に近いほど強モデルへのルーティング率が上がり品質重視、1に近いほど弱モデルへのルーティング率が上がりコスト重視）
• $\mathbb{1}[\cdot]$: 指示関数

この閾値 $\tau$ の役割は、Amazon Bedrock IPRにおける responseQualityDifference パラメータと概念的に対応する。

4種のルーターアーキテクチャ

著者らは以下の4種のルーターを実装し、比較している。

1. Similarity-Weighted (SW) Ranking

学習データ中の各サンプルとの類似度で重み付けしたランキングスコアを算出する。新しいプロンプト $p$ に対するスコアは以下で計算される：

\[s_{\text{SW}}(p) = \frac{\sum_{i=1}^{N} \text{sim}(e(p), e(p_i)) \cdot y_i}{\sum_{i=1}^{N} \text{sim}(e(p), e(p_i))}\]

ここで、

• $e(p)$: プロンプト $p$ の埋め込みベクトル（文埋め込みモデルで取得）
• $\text{sim}(\cdot, \cdot)$: コサイン類似度
• $y_i$: サンプル $i$ で強モデルが勝利したか（1）否か（0）
• $N$: 学習サンプル数

2. Matrix Factorization (MF)

Chatbot Arenaの選好データ行列を因子分解し、プロンプトとモデルの潜在表現を学習する。Bradley-Terryモデルに基づくスコアリング：

\[P(\text{model}_A \succ \text{model}_B | p) = \sigma(\alpha_A^T e(p) + \beta_A - \alpha_B^T e(p) - \beta_B)\]

ここで、

• $\alpha_A, \alpha_B$: 各モデルの潜在ベクトル
• $\beta_A, \beta_B$: 各モデルのバイアス項
• $\sigma(\cdot)$: シグモイド関数
• $e(p)$: プロンプトの埋め込み

3. BERT Classifier

BERTベースの分類器で、プロンプトを入力として「強モデルが弱モデルより優れた応答を返すか」を直接予測する。標準的なファインチューニングで実装される。

4. Causal LLM Router

因果言語モデル（LLaMA等）にルーティングタスクをファインチューニング。プロンプトの最終トークンの隠れ状態から線形層でスコアを出力する。

データ拡張手法

著者らは選好データの拡張手法として以下を検討し、効果を定量化している：

1. Golden-label augmentation: Arena Hard Auto（GPT-4による自動評価）のラベルを追加
2. Rejection sampling: 教師モデルの出力を再サンプリングして品質差の大きいペアを強調
3. Cross-model augmentation: 異なるモデルペアの選好データを混合

論文Table 2によると、データ拡張によりMT-BenchでのRouteLLMの性能が2〜5ポイント向上したと報告されている。

実装のポイント（Implementation）

RouteLLMはPythonパッケージとして公開されており、OpenAI API互換インターフェースを提供する。

from routellm.controller import Controller

# RouteLLMクライアントの初期化
client = Controller(
    routers=["mf"],  # Matrix Factorizationルーターを使用
    strong_model="gpt-4-1106-preview",
    weak_model="mixtral-8x7b-instruct-v0.1",
)

# 通常のOpenAI APIと同様に呼び出し
# モデル名に "router-{ルーター名}-{閾値}" を指定
response = client.chat.completions.create(
    model="router-mf-0.11593",  # 閾値0.11593でルーティング
    messages=[
        {"role": "user", "content": "プロンプトの内容"}
    ],
)

実装上の注意点:

• 閾値の校正: 閾値 $\tau$ はコスト/品質トレードオフを制御する唯一のハイパーパラメータ。論文ではMT-Benchの性能を基準に校正している。実運用では、自社のタスク分布に基づく校正が推奨される
• 埋め込みモデルの選択: SW Rankingルーターでは文埋め込みモデルの品質がルーティング精度に直結する。著者らはText-Embedding-3-Smallを使用
• ルーター推論コスト: MFルーターの推論は約1ms、BERTルーターは約5ms。Causal LLMルーターは50-100msかかるため、レイテンシ制約がある場合はMFまたはSWを推奨
• 転移学習: GPT-4/Mixtralペアで学習したルーターは、Claude 3 Opus/Haikuペアに切り替えても性能低下が軽微（論文Table 4より、1-3ポイント程度の低下）

実験結果（Results）

著者らは3つのベンチマーク（MT-Bench、MMLU、GSM8K）で評価を実施している。

コスト削減率（論文Table 1より、GPT-4品質の95%を維持した場合）：

ベンチマーク	MFルーター	SWルーター	BERTルーター	Causal LLMルーター
MT-Bench	85.3%	82.1%	87.2%	84.6%
MMLU	45.2%	42.8%	47.1%	44.3%
GSM8K	35.8%	33.5%	37.4%	36.1%

転移学習の結果（論文Table 4より）：

学習ペア	テストペア	性能維持率
GPT-4 / Mixtral	GPT-4 / Mixtral	100%（ベースライン）
GPT-4 / Mixtral	Claude 3 Opus / Haiku	97-99%
GPT-4 / Mixtral	GPT-4 / Llama-3-8B	95-98%

著者らはこの転移学習能力について、「ルーターが学習しているのはモデル固有の特性ではなく、プロンプトの本質的な難易度を捉えている」と考察している。

Bedrock IPRとの比較:

Amazon Bedrock IPRが報告するAnthropicファミリーでの63.6%のコスト削減（Zenn記事参照）は、RouteLLMの実験結果と整合的である。RouteLLMのMT-Benchでの85%削減はより積極的なルーティング設定での結果であり、MMLUでの45%削減はより保守的な設定に相当する。Bedrock IPRのresponseQualityDifferenceパラメータは、RouteLLMの閾値 $\tau$ と概念的に同じ役割を果たしており、品質とコストのトレードオフを連続的に制御できる。

実運用への応用（Practical Applications）

Bedrock IPRとの対応関係

RouteLLMの知見は、Bedrock IPRを運用する際の以下の判断に直接活用できる：

1. 閾値設定の指針: RouteLLMの実験から、品質95%維持でコスト40-85%削減が見込めることがわかる。BedrockのresponseQualityDifferenceを0.25に設定すると、RouteLLMの中程度の閾値に相当し、70-80%のリクエストがHaikuにルーティングされる
2. 転移学習の示唆: ルーターの転移学習能力は、Bedrock IPRがモデル更新（例: Claude 3.5 Haiku → Claude Haiku 4.5）に対してもルーティング品質を維持できる可能性を示唆している
3. ドメイン適応: RouteLLMの学習データは英語中心のChatbot Arenaデータであるため、日本語タスクでは性能低下の可能性がある。Bedrockの日本語ワークロードではresponseQualityDifferenceを低めに設定して品質を優先する調整が有効

スケーリング戦略

• 小規模（~100リクエスト/日）: デフォルトルーターをそのまま利用。閾値調整のみでコスト削減を実現
• 中規模（~1000リクエスト/日）: カスタムルーターを作成し、自社データで閾値を最適化。ルーティングメトリクスをCloudWatchに連携
• 大規模（10000+リクエスト/日）: RouteLLMの学習手法を参考に、自社の選好データで独自ルーターを構築。Bedrock IPRと併用して多段ルーティングを実現

Production Deployment Guide

AWS実装パターン（Bedrock IPR + RouteLLM併用）

RouteLLMの知見をAmazon Bedrock上で活用するには、Bedrock IPRをプライマリルーターとして利用しつつ、カスタム分類ロジックを前段に配置する構成が有効である。

規模	月間リクエスト	推奨構成	月額コスト概算
Small	~3,000 (100/日)	Lambda + Bedrock IPR	$50-150
Medium	~30,000 (1,000/日)	Lambda + Bedrock IPR + ElastiCache	$300-800
Large	300,000+ (10,000/日)	ECS Fargate + Bedrock IPR + Redis	$2,000-5,000

Small構成の詳細（月額$50-150）:

• Lambda: ルーティングロジック実行（1GB RAM、30秒タイムアウト）、$20/月
• Bedrock IPR: Anthropicファミリー（Sonnet/Haiku）デフォルトルーター、$80-120/月（トークン使用量依存）
• DynamoDB: ルーティングメトリクス記録（On-Demand）、$5/月
• CloudWatch: 基本監視、$5/月

コスト試算の注意事項: 上記は2026年2月時点のAWS us-east-1リージョン料金に基づく概算値です。実際のコストはトラフィックパターンやBedrock使用量により変動します。最新料金は AWS料金計算ツール で確認してください。

運用・監視設定

ルーティング比率モニタリング（CloudWatch Logs Insightsクエリ）:

fields @timestamp, routed_model, input_tokens, output_tokens
| stats count(*) as request_count by routed_model
| sort request_count desc

コスト異常検知アラーム:

import boto3

cloudwatch = boto3.client('cloudwatch')
cloudwatch.put_metric_alarm(
    AlarmName='bedrock-routing-cost-spike',
    ComparisonOperator='GreaterThanThreshold',
    EvaluationPeriods=1,
    MetricName='TokenUsage',
    Namespace='Custom/BedrockRouting',
    Period=3600,
    Statistic='Sum',
    Threshold=500000,
    AlarmDescription='Bedrockルーティングのトークン使用量異常検知'
)

関連研究（Related Work）

• FrugalGPT (Chen et al., 2023): カスケード方式のLLMルーティング。安価なモデルから順に試し、信頼度が低い場合に上位モデルへエスカレーション。最大98%のコスト削減を報告しているが、最悪ケースではレイテンシが全モデル分加算される
• AutoMix (Madaan et al., 2024): タスク難易度に応じた自動モデル選択。小型モデルの出力を自己検証し、品質が不十分な場合に大型モデルへ転送
• Toward Optimal LLM Routing (Ding et al., 2024): ルーティングを「コスト制約付き品質最大化」問題として定式化。オラクル上界と実際のルーターの間の性能ギャップを定量化するフレームワークを提案

まとめと今後の展望

RouteLLMは、LLMルーティングの問題を「選好データからの学習」という枠組みで体系的に整理し、実用的な4種のルーターアーキテクチャを提示した。MT-Benchで85%超のコスト削減を達成しつつ品質を維持できること、異なるモデルペアへの転移学習が有効であることが主要な成果である。

今後の研究方向として、著者らは（1）多言語タスクでの評価、（2）マルチモーダルプロンプトへの対応、（3）3つ以上のモデル間でのルーティング拡張を挙げている。特に（3）は、Amazon Bedrockの将来的なクロスファミリールーティング機能の基盤となりうる技術である。

参考文献

• arXiv: https://arxiv.org/abs/2406.18665
• Code: https://github.com/lm-sys/RouteLLM（Apache 2.0）
• LMSYS Blog: https://lmsys.org/blog/2024-07-01-routellm/
• Related Zenn article: https://zenn.dev/0h_n0/articles/f5fa165860f5e8