RouteLLM 深读：把「谁来做这题」压缩成一个胜率，就是所有 LLM 路由的钥匙

原文：RouteLLM: Learning to Route LLMs with Preference Data（arXiv:2406.18665，ICLR 2025）。工程实现：lm-sys/RouteLLM。发布博客：LMSYS Blog, 2024-07-01。

RouteLLM 论文里最该记住的数字，不是四种路由器的排行榜，而是 MT-Bench 上这一行：只用 14% 的 GPT-4 调用，就能保住 95% 的 GPT-4 质量（用 GPT-4 judge 增强训练数据后的 MF 路由器）。

这个数字之所以值钱，是因为它把「LLM 成本优化」从「换更便宜的模型」这种粗粒度动作，变成了一件可度量、可校准、可 A/B 的事：给一个 prompt 打胜率分，用一个阈值切两半，剩下的都是账。

这篇把 RouteLLM 的核心机制拆到能贴代码的深度——四种路由器算什么、Chatbot Arena 的偏好数据怎么去稀疏、阈值是怎么校准的、以及一次 completion 请求从进入 openai_server 到最终转发给 strong/weak backend 的完整链路。

名词速查

术语	一句话解释
$M_{\text{strong}}$ / $M_{\text{weak}}$	一对成本-质量对比明显的模型，如 GPT-4 Turbo vs Mixtral 8×7B
$P_\theta(\text{win}_s \mid q)$	只看 query $q$，强模型比弱模型答得好的概率——路由器要学的核心量
$\alpha$	用户设定的胜率阈值，把上面这个概率切成”走强/走弱”两段
SW Ranking	Similarity-Weighted Ranking，用向量相似度加权重跑 Elo，无需训练
MF	Matrix Factorization，学 latent 表征来预测胜率，官方默认最强
Causal LLM Router	微调一个小 LLM（Llama 3 8B 级别）当二分类器
PGR	Performance Gap Recovered，路由器恢复了多少「弱到强」的质量差距
APGR	不同预算下 PGR 的积分——路由器整体好坏的单一数字
CPT(x%)	Call-Performance Threshold，要达到 x% PGR 最少需要多少比例强模型调用
Chatbot Arena	LMSYS 的匿名 LLM 人类偏好投票平台，RouteLLM 的核心训练数据来源

一、把路由压缩成一行公式

RouteLLM 的整个框架建立在一个公式上：

$$R_\alpha(q) = \begin{cases} M_{\text{strong}} & \text{if } P_\theta(\text{win}_s \mid q) \geq \alpha \\ M_{\text{weak}} & \text{otherwise} \end{cases}$$

• $P_\theta(\text{win}_s \mid q)$：只看 prompt 本身，估计强模型比弱模型答得好的概率。
• $\alpha$：一个由预算/质量目标反推出来的标量阈值。

四种路由器的所有算法差异，最终都收敛到同一个函数签名——calculate_strong_win_rate(prompt) -> float。这是理解 RouteLLM 链路深度的钥匙：只要你能对任意 prompt 输出一个 [0, 1] 的胜率，剩下的机制就是同一套。

这个抽象的工程好处极大：路由器可以离线训练、离线评估、离线校准；线上只是一次浮点比较；换模型对不需要重训路由器（后面会讲为什么）。

二、四种路由器：从零 GPU 到小 LLM 的全谱

RouteLLM 实现了四种打分器，覆盖了推理成本和数据依赖的整个光谱。

2.1 Similarity-Weighted Ranking (SW)——最轻的一档

思路：为每一条 query 现算一个”个性化 Elo 榜单”。

# routellm/routers/routers.py, SWRankingRouter
prompt_emb   = openai.embeddings.create(input=[prompt], model="text-embedding-3-small")
similarities = arena_conv_embedding @ prompt_emb / norms
weightings   = 10 * 10 ** (similarities / max_sim)
# 把 Chatbot Arena 里与当前 query 相似的历史对战按相似度加权，重跑 Elo
weak_winrate = 1 / (1 + 10 ** ((strong_score - weak_score) / 400))
return 1 - weak_winrate

• 训练：不需要，是一个”近邻 + 加权 Elo”的记忆式模型。
• 推理：一次 embedding + 一次矩阵乘法。无 GPU 依赖。
• 代价：每次都要打 OpenAI embedding API，请求量大时 embedding 费用可能反超省下的模型费。

2.2 Matrix Factorization (MF)——官方默认，效果最好

思路：把”query × model → 胜率”当作一个巨大的稀疏矩阵，用矩阵分解学 latent 表征。

# routellm/routers/routers.py, MatrixFactorizationRouter
winrate = self.model.pred_win_rate(
    self.strong_model_id, self.weak_model_id, prompt
)
return winrate

内部实际上是把 prompt embedding、strong model id、weak model id 拼进一个双塔式打分网络。Chatbot Arena 的模型-模型对比是极度稀疏的（任意两个模型直接对战 < 0.1%），矩阵分解正好是处理这种稀疏偏好数据的经典武器。

头条数据（MT-Bench，GPT-4 Turbo vs Mixtral 8×7B）：

• 只用 Arena 数据训练：MF 达到 GPT-4 95% 质量时只用 26% 的 GPT-4 调用，比 random 便宜 48%。
• 加上 GPT-4 judge 数据增强：只用 14% 的 GPT-4 调用 就达到同样质量，比 random 便宜 75%。

2.3 BERT Classifier——判别式路由器

思路：直接把它当成”哪个模型会赢”的文本分类。

# routellm/routers/routers.py, BERTRouter
inputs   = self.tokenizer(prompt, return_tensors="pt", padding=True, truncation=True)
logits   = self.model(**inputs).logits.numpy()[0]
softmax  = np.exp(logits - np.max(logits)) / np.sum(...)
binary_prob = np.sum(softmax[-2:])
return 1 - binary_prob

• 直接 fine-tune 一个 BERT，正样本是”强模型赢”的对战。
• 优点：可解释、可微调、可蒸馏到更小的 encoder。
• 缺点：在低数据 regime 下会退化到 random——这也是论文里最重要的经验教训之一：不是模型容量越大越好，preference 数据里的”软标签”信息才是决胜手。

2.4 Causal LLM Classifier——用小 LLM 当路由器

思路：微调一个小 LLM（如 Llama 3 8B），让它二分类地”预测强模型会不会赢”。

# routellm/routers/routers.py, CausalLLMRouter
input["messages"] = self.to_openai_messages([prompt])
output = self.router_model(input)
return 1 - output["binary_prob"]

• 优点：能处理新颖表达、跨语言、指令类问题。
• 缺点：为了省 LLM 钱而先多花一次 LLM 钱。适合本地部署小模型，不适合 API 转发式部署。

一张表看清取舍

路由器	训练成本	推理开销	外部依赖	论文里的效果
SW Ranking	无	一次 embedding + 矩阵乘	OpenAI embedding API	好，但每次要付 embedding 费
MF（默认）	中	一次前向	内置小模型	最好，CPT(80%) 减半
BERT	中	一次前向	本地 BERT	中；低数据下退化到 random
Causal LLM	高	一次 LLM 推理	本地/远端 LLM	好，但引入额外一次 LLM 调用

三、训练数据：稀疏偏好的两步处理

RouteLLM 最有洞见的一步在数据侧，而不是模型侧。

原始信号：Chatbot Arena 上 8 万条人类偏好投票（“我更喜欢 A 的回答”）。

稀疏性处理：任意两个模型之间的直接对战 < 0.1%，绝大多数模型对没有直接可比样本。论文的做法是把所有模型按 Arena 排行榜聚成 10 个 tier，用动态规划最小化 tier 内方差；Top 2 tier 当 $M_{\text{strong}}$，第 3 tier 当 $M_{\text{weak}}$。这里有一个关键取舍：训练时只保留 winner 身份，扔掉具体回答内容——避免路由器学到”生成质量的某种统计特征”而不是”模型能力差异”。

数据增强：用 GPT-4 当 judge 合成 12 万条额外偏好对。BERT 和 Causal LLM 这两个高容量路由器只有在这一步之后才追上 MF——高容量模型是数据饥饿的，Arena 那 8 万条不够喂。

模型对可迁移：Arena 训出来的四种路由器都是”tier vs tier”的偏好，不是”GPT-4 Turbo vs Mixtral”的偏好。所以论文实测：把 strong/weak 换成另一对模型（例如 Claude 3 Opus vs Llama 3 70B），不需要重训路由器，效果依然优于 random。这是 preference-based 路由能落地的另一个必要条件——如果换模型就要重训，路由器就不划算了。

四、阈值校准：三个必须记住的指标

PGR（Performance Gap Recovered）：路由器恢复了多少”弱到强”的质量差距。

$$\text{PGR} = \frac{\text{router quality} - \text{weak quality}}{\text{strong quality} - \text{weak quality}}$$

APGR（Average PGR）：把不同成本预算下的 PGR 积分——路由器整体好坏的单一数字。

CPT(x%)（Call-Performance Threshold）：要达到 x% 的 PGR，最少需要多少比例的强模型调用。这才是真正的钱袋子指标——CPT 越低越省钱。

阈值 $\alpha$ 是靠离线数据集反推的：

python -m routellm.calibrate_threshold \
  --task calibrate --routers mf \
  --strong-model-pct 0.2 --config config.example.yaml
# 输出：α = 0.1881
# 使用：把请求的 model 字段写成 "router-mf-0.1881"，就是"20% 走强模型"

论文里给的另一个基准值：--strong-model-pct 0.5 时 MF 的 $\alpha \approx 0.11593$。

生产上必须记住的一件事：校准基于历史分布反推，你线上的请求分布跟 Arena 不一样，实际强模型占比一定会漂移。上线后要在线上定期观测重标。

五、链路深度：一次 completion 请求走了什么

RouteLLM 提供 OpenAI 兼容的 HTTP 端点，用户只需要把 model 字段从 gpt-4-turbo 换成 router-mf-0.1881。以下是从请求进入到最终转发给后端模型的完整调用链——贴到代码，不是抽象讲述。

POST /v1/chat/completions                                       [openai_server.py]
        │  body.model = "router-mf-0.1881"
        ▼
Controller.completion(...)                                      [routellm/controller.py]
        │
        ▼
Controller._parse_model_name(model)
        │  → router = "mf", threshold = 0.1881
        ▼
Controller._get_routed_model_for_completion(messages, router, threshold)
        │  prompt = messages[-1]["content"]     ← 只用最后一条消息!
        ▼
Router.route(prompt, threshold, model_pair)                     [routers.py 基类]
        │
        ▼
Router.calculate_strong_win_rate(prompt)         ← 四选一
        │  返回 P_θ(win_s | q) ∈ [0, 1]
        ▼
if win_rate >= threshold:   return strong_model
else:                       return weak_model
        │
        ▼
Controller.model_counts[router][routed_model] += 1              # 观测计数
        │
        ▼
litellm.completion(model=routed_model, messages=...)            # 转发给真实后端
        │
        ▼
上游模型 (GPT-4 Turbo / Mixtral / ...) 的响应

这个链路里有四个设计点值得放大：

1. 只用最后一条消息做路由决策。 这是官方实现里一个非常大的简化——多轮对话的上下文完全不进路由器。chatbot 场景一般够用，但在 agent 场景（tool call 后半段）会翻车：最后一条 message 可能是空 assistant 消息或者只有工具结果。自建路由时这是最值得改的一处——至少要把 system prompt 和最近 N 轮拼进去做特征。

2. calculate_strong_win_rate 是唯一可插拔面。 想接自己训练的路由器，只要实现这一个方法。这个抽象干净到几乎没有任何耦合。

3. route() 里的判断只是一次浮点比较。 路由本身的延迟远小于任何一次模型调用；真正的路由延迟来自 calculate_strong_win_rate——SW 要打 OpenAI embedding、Causal LLM 要跑一次 LLM，MF/BERT 是本地几毫秒。MF 是延迟最优也是效果最优的，这不是巧合——它是唯一一个”训练成本、推理成本、外部依赖、效果”都不吃亏的选项。

4. litellm 作为下游转发层。 RouteLLM 不自己发 HTTP 请求，而是委托 litellm 做 provider 抽象——所以你想把 weak 换成本地 vLLM、把 strong 换成 Bedrock Claude 都是配置一行的事。这也是为什么模型对可以替换而路由器不需要重训。

六、生产落地要注意的三个坑

坑 1：分布外查询会让路由器接近随机。 论文里 MMLU 上，只用 Arena 训练的所有路由器都退化到 random——因为 Arena 是开放式对话，MMLU 是选择题，是彻底的 OOD。上线前必须用你自己业务的 query 采样跑一次 APGR，别信 MT-Bench 上的头条数字。经验做法：抽 1000 条真实生产 query，人工或用 judge 打偏好标签，跑一次 APGR，然后再决定用不用这套路由。

坑 2：决策边界附近的 query 才是最贵的错误。 RouteLLM 论文和 Rerouting LLM Routers (arXiv:2501.01818) 都指出：分错的 query 大多集中在阈值附近——“弱模型勉强能答但会答错，强模型稳赢”。工程上应对方式是在阈值附近开一个小窗口强制走强模型（比如 $[\alpha - 0.05, \alpha + 0.05]$），或者做二次 verify。这是一个用极少额外成本换尾部质量的操作。

坑 3：偏好数据训的是”人类喜欢哪个回答”，不是”任务能不能完成”。 如果你的 backend 需要严格 JSON schema、tool call、多步推理，preference-based 路由器可能会把 weak model 高估——因为 Arena 的人类投票也不太关心 schema 合规。Agent 系统里的路由器最好用任务成功率（execution success）当训练信号，而不是直接复用 Arena 数据。参考 How Robust Are Router-LLMs? (arXiv:2504.07113) 里对路由器脆弱性的分析——他们发现哪怕小小的 prompt 扰动，路由器的强模型占比都会发生几十个百分点的漂移。

七、什么时候用 RouteLLM，什么时候另起炉灶

• 直接用：chatbot / 开放对话产品，query 分布与 Arena 相近，只需要”便宜 + 保质量”，不想自己训模型。
• Fork + 换训练数据：领域 chatbot（客服、医疗、法律），拿自家的偏好数据或 A/B 数据重训 MF。骨架不用动。
• 自己造轮子：Agent、代码 IDE、多步推理这种任务型场景——路由决策要看 tool call 历史、上下文长度、schema、历史成功率，preference-based 路由已经不够用了。走”预测任务成功率”的路线，比预测”人类偏好”更直接。

结语

RouteLLM 真正的工程含金量不在四种路由器谁强，而在它把一件模糊的事——“这题该谁做”——变成一件可测量、可校准、可 A/B 的事。PGR、APGR、CPT 三个指标 + 一个 threshold，就是所有 LLM 路由系统的最小充分统计量。

一句话记住：把路由问题压缩成”给一个 prompt 打胜率分”，用 Chatbot Arena 偏好数据学这个分，再用一个可校准的阈值 $\alpha$ 把胜率切成两半——这就是 RouteLLM 的全部秘密。

参考资料

• RouteLLM: Learning to Route LLMs with Preference Data (arXiv:2406.18665)
• ICLR 2025 Proceedings — Learning to Route LLMs with Preference Data
• RouteLLM: An Open-Source Framework for Cost-Effective LLM Routing — LMSYS Blog, 2024-07-01
• GitHub: lm-sys/RouteLLM
• Rerouting LLM Routers (arXiv:2501.01818)
• How Robust Are Router-LLMs? (arXiv:2504.07113)
• BerriAI / litellm — 下游 provider 抽象层