新文章：LLM Routing

点击阅读：https://t.co/grhxFDXsCt https://t.co/afsK1jkouz

LLM Routing

来源：https://outcomeschool.com/blog/llm-routing LLM Routing

在这篇博客中，我们将学习 LLM Routing——它是什么、为什么重要，以及如何根据成本、延迟和质量将每个用户查询发送给合适的 LLM。

我们将涵盖以下内容：

• 整体概览
• 什么是 LLM Routing
• 为什么需要 LLM Routing
• LLM Router 的组成结构
• 路由策略
• 完整追踪示例
• LLM Routing 与混合专家模型的区别
• LLM Routing 的适用场景
• 常见错误及解决方法
• 快速总结

我是 Amit Shekhar，Outcome School (https://outcomeschool.com/) 创始人。我教导和辅导过许多开发者，帮助他们成功获得高薪技术职位，协助众多科技公司解决独特难题，并创建了多个被顶级公司使用的开源库。我热衷于通过开源、博客和视频分享知识。

我在 Outcome School 教授 AI 和机器学习。

让我们开始吧。

整体概览

LLM Routing 是位于多个 LLM 前端的一个层。它查看每个用户查询，并决定由哪个 LLM 来回答。目标很简单——将简单的查询发送给小型、廉价、快速的 LLM，将困难的查询发送给大型、智能、昂贵的 LLM。这样，我们就能在不牺牲质量的前提下节省成本。

简单来说：

LLM Routing = 为每个查询挑选合适的 LLM。

什么是 LLM Routing

LLM Routing 是一种为每个用户查询选择合适 LLM 的做法，而不是将所有查询都发送给同一个 LLM。

让我们拆解这个术语：

LLM Routing = LLM + Routing。

• LLM 是大语言模型（Large Language Model）的缩写，即生成答案的模型。我们有一篇关于 Transformer 架构的详细博客，解释了每个现代 LLM 背后的架构，包括其中多头注意力机制的工作原理。
• Routing（路由） 意味着决定一个请求应该走哪条路径。

也就是说，LLM Routing 决定了查询的路径——由哪个 LLM 来处理它。

打个比方，我们走进一家医院，带着某个问题。接待员看了看我们的问题，然后把我们引导到合适的医生那里。普通感冒去找全科医生，心脏问题去找心脏科医生，脑部问题去找神经科医生。

接待员就是路由器，医生就是各个 LLM，患者就是我们的用户查询。

这与 LLM Routing 的思路如出一辙。

为什么需要 LLM Routing

如今，我们有许多可用的 LLM——前沿 LLM（市场顶端最大、最智能的 LLM，如 OpenAI、Anthropic 和 Google 的最新产品）、中等规模 LLM、小型 LLM，甚至还有专门用于代码、数学或视觉任务的专用 LLM。它们在三个方面存在差异：

• 成本。 前沿 LLM 价格昂贵，小型 LLM 则非常便宜。
• 延迟。 更大的 LLM 速度更慢，更小的 LLM 速度更快。
• 质量。 有些查询需要最智能的 LLM，但很多查询并不需要。

让我们用真实数据来说明：

• 前沿 LLM：约 $15 每 100 万输出 token。
• 小型 LLM：约 $0.50 每 100 万输出 token。

这是 30 倍 的成本差距。

问题在于，大多数用户查询都很简单——“2 + 2 等于多少？”、“帮我总结这封邮件”、“法国的首都是哪里？”。将每个这样的查询都发送给前沿 LLM，是对成本和时间的浪费。

因此，LLM Routing 应运而生。它根据我们的使用场景，将每个查询发送给最合适的 LLM。

LLM Router 的组成结构

让我们看看如下高层次示意图：

┌────────────────┐
   user query  →  │                │
                  │   LLM Router   │
                  │                │
                  └───────┬────────┘
                          │
              ┌───────────┼───────────┐
              ▼           ▼           ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │  Small   │ │   Mid    │ │ Frontier │
        │   LLM    │ │   LLM    │ │   LLM    │
        └──────────┘ └──────────┘ └──────────┘

这里，我们可以看到四个部分。让我们逐一解读。

1. 查询（Query）。 来自用户的原始输入，这是路由器唯一能看到的内容。

2. 路由器（Router）。 一个小型、快速的组件，决定哪个 LLM 应该处理此查询。路由器可以是一组规则、一个小型分类器、一次嵌入向量检索，甚至本身就是一个小型 LLM。

3. LLM 池（LLM Pool）。 一组具有不同优势、成本和速度的 LLM。池中可以包含小型 LLM、中等规模 LLM、前沿 LLM 以及代码专用 LLM。

4. 选定的 LLM（Selected LLM）。 路由器为此查询所选择的那一个 LLM。查询随后被转发给它，响应返回给用户。

这就是 LLM Router 的结构。

注意： 路由器本身必须非常快。一个实用的经验法则是：路由器自身的延迟应控制在所选 LLM 延迟的 10% 以内。如果选定的 LLM 需要 1 秒，路由器最多增加 100 毫秒。

路由策略

现在，让我们了解构建路由器最常见的几种方式。我们将介绍五种策略。

1. 基于规则的路由

最简单的策略。通过查看查询中的关键词、长度或模式来选择 LLM。

示例代码：

def route(query: str) -> str:
    q = query.lower()
    if "code" in q or "function" in q or "bug" in q:
        return "code-llm"
    if len(q) < 50:
        return "small-llm"
    if len(q) < 200:
        return "mid-llm"
    return "frontier-llm"

这里，我们有一个小函数，根据简单规则来选择 LLM。关于代码的查询去代码 LLM，非常短的查询去小型 LLM，中等长度的查询去中等 LLM，更长的内容则去前沿 LLM。

优点： 非常快、非常便宜。路由无需调用任何模型。

缺点： 脆弱。像“为什么我的 Python 脚本坏了？“这样的查询可能绕过关键词检查，因为其中没有出现 code、function 或 bug。新的模式会打破规则。

2. 基于分类器的路由

这里，我们在 (查询, 最佳LLM) 历史数据对上训练一个小型分类器。运行时，分类器接收查询并预测合适的 LLM。

分类器可以是基于查询嵌入的简单逻辑回归，也可以是一个小型神经网络。

优点： 从真实数据中学习，能捕捉简单规则遗漏的模式。

缺点： 需要有标注的训练数据和重新训练的流程。

3. 基于嵌入的路由

这里，我们将每个查询转换为嵌入向量——一组捕捉其语义的数字向量。我们还保存一小组参考嵌入，每个 LLM 对应一个，代表该 LLM 最擅长处理的查询类型。

对于每个新查询，我们找到最近的参考嵌入，由拥有该参考的 LLM 来处理查询。

优点： 无需训练。添加新 LLM 很容易——只需再加一个参考嵌入即可。

缺点： 质量取决于参考嵌入的好坏。

4. LLM 作为路由器

这里，我们使用一个小型、廉价的 LLM 作为路由器。路由器 LLM 是一个独立的 LLM，其唯一职责是读取查询并决定由哪个目标 LLM 来回答。其思路很简单：路由器与查询“说同一种语言“，因此它理解意图和难度的能力远超固定规则。

示例代码：

def route_with_llm(query: str) -> str:
    prompt = f"""Pick the best LLM for this query.
Options: small-llm, mid-llm, frontier-llm, code-llm.
Query: {query}
Answer with one word from the options:"""
    return router_llm(prompt).strip()

这里，router_llm 是充当路由器的小型、廉价 LLM。它读取查询，并输出要使用的目标 LLM 的名称——small-llm、mid-llm、frontier-llm 或 code-llm 之一。路由器本身与这些目标 LLM 是分开的。

优点： 非常灵活。无需训练。只需修改提示词即可更改路由规则。

缺点： 在主调用之前额外增加一次 LLM 调用。我们必须保持该路由器 LLM 小巧快速。

5. 级联路由

这是成本节省效果最好的策略。先将查询发送给最便宜的 LLM。如果答案看起来置信度较低或有误，则升级到更大的 LLM。

query  →  small LLM  →  confident? ── yes ──▶ return answer
                          │
                          no
                          ▼
                       mid LLM  →  confident? ── yes ──▶ return answer
                                     │
                                     no
                                     ▼
                                  frontier LLM ───────▶ return answer

这里，我们可以看到一个链式结构。每个 LLM 要么回答查询，要么将其传递给更大的 LLM。

“confident（置信度）？“的判断可以是 LLM 的自评分、一个验证模型，或简单的启发式方法，例如答案长度和是否出现“我不知道”。

简单的代码示例：

def cascade(query: str) -> str:
    answer = small_llm(query)
    if is_confident(answer):
        return answer
    answer = mid_llm(query)
    if is_confident(answer):
        return answer
    return frontier_llm(query)

这里，我们使用了一个简单的级联。每一步要么返回答案，要么升级到下一个 LLM。

优点： 成本节省效果出色。大多数查询由最便宜的 LLM 解决。

缺点： 对困难查询来说速度较慢，因为需要支付两到三次 LLM 调用的代价。

策略对比

让我用表格对比各路由策略的差异，帮助你更好地理解，以便根据使用场景做出选择。

这里没有绝对的赢家。我们根据使用场景选择策略。对于查询类型少且明确的小型系统，基于规则的方式已经足够。对于查询类型混合的大型产品，级联或 LLM 作为路由器的方式效果更好。

如需系统掌握编排与路由、嵌入和逻辑回归的实践技能，我们提供完整的课程项目——欢迎了解 Outcome School 的 AI 和机器学习项目。

完整追踪示例

假设我们运行一个聊天机器人，路由器后端有四个 LLM——small-llm、mid-llm、frontier-llm 和 code-llm。

为便于理解，我们使用简单的基于规则的路由器。

查询 1： “What is 2 + 2?”

• 路由器决策：small-llm（长度短，无代码关键词）。
• 成本：非常低。延迟：约 100 毫秒。
• 响应：“4”。

查询 2： “Summarize this 3-line email for me: Hi John, can you please review my Q3 sales report draft by Friday? Thanks, Sarah.”

• 路由器决策：mid-llm（长度中等，无代码关键词）。
• 成本：低。延迟：约 500 毫秒。
• 响应：简洁的一行摘要。

查询 3： “Fix the bug in this Python function that calculates Fibonacci.”

• 路由器决策：code-llm（“bug” 和 “function” 均匹配代码关键词）。
• 成本：低。延迟：约 700 毫秒。
• 响应：修正后的 Python 函数。

查询 4： “Design a comprehensive multi-agent system for medical diagnosis that covers symptom analysis, differential diagnoses, treatment recommendations, edge cases like rare diseases, ethical considerations, and the trade-offs between accuracy and latency.”

• 路由器决策：frontier-llm（长度大，无代码关键词）。
• 成本：高。延迟：约 3 秒。
• 响应：详细的多步骤设计方案。

将四个查询整合如下：

"What is 2 + 2?"           ──▶ router ──▶ small-llm     ──▶ 快速且廉价
"Summarize this email..."  ──▶ router ──▶ mid-llm       ──▶ 均衡
"Fix the bug in..."        ──▶ router ──▶ code-llm      ──▶ 专用
"Design a multi-agent..."  ──▶ router ──▶ frontier-llm  ──▶ 智能但较慢

可以看到，每个查询都根据其性质被路由到了合适的 LLM。简单的数学题去了小型 LLM，摘要去了中等 LLM，代码去了代码 LLM，复杂推理去了前沿 LLM。接待员做出了正确的判断。

现在考虑一下成本。如果没有路由，四个查询都会发送给前沿 LLM。有了路由，只有其中一个发送给了它。在数百万次查询中，这是巨大的成本节省。

效果非常好。

LLM Routing 与混合专家模型

一个自然的问题浮现——LLM Routing 与混合专家模型（Mixture of Experts）是一回事吗？

答案是：不是，但思路相似。

• LLM Routing 在查询层面，从多个完整 LLM 中选择一个完整的 LLM。
• 混合专家模型 在 token 层面，在一个 LLM 内部选择几个小型专家子网络。

让我用表格对比 LLM Routing 与混合专家模型的差异，帮助你更好地理解。

两者都使用路由器，都是选择一部分计算资源。但 LLM Routing 工作在系统层面，而混合专家模型工作在单个模型内部。我们有一篇关于混合专家模型的详细博客，解释了模型内部的路由机制。

如需深入了解混合专家模型及更广泛的 LLM 内部原理，我们提供完整的课程项目——欢迎了解 Outcome School 的 AI 和机器学习项目。

LLM Routing 的适用场景

LLM Routing 有真实的工程成本，因此只有在物有所值时才应引入。以下信号表明它是值得的：

• 查询量大。 每天几千次查询很少值得引入路由。每天数百万次查询则几乎总是值得的。
• 查询难度参差不齐。 如果大多数查询很简单，但有些很复杂，路由的收益非常大。如果每个查询难度相当，一个 LLM 就足够了。
• 成本压力。 如果 LLM 费用较高，路由能快速降低成本。
• 已在使用多个 LLM。 如果我们因不同原因已经在使用两个或更多 LLM，路由器可以整理这些临时逻辑。

如果以上情况都不适用，选择单个中等规模的 LLM 可能更适合我们的场景。

常见错误及解决方法

让我们逐一介绍常见错误及其解决方法。

1. 路由器本身过于庞大。

如果我们用前沿 LLM 作为路由器，路由器的成本可能高于节省的成本。应使用微型 LLM、分类器或简单规则作为路由器。

2. 没有回退路径。

所选的 LLM 可能失败、超时或返回错误答案。始终保留一个备用 LLM。如果小型 LLM 失败，回退到中等 LLM，以此类推。

3. 路由器增加了过多延迟。

路由器在真正调用前增加 500 毫秒会严重影响用户体验。保持路由器快速——规则在微秒级，分类器在几毫秒，小型 LLM 在 200 毫秒以内。

4. 将路由与编排混为一谈。

路由为单个查询选择一个 LLM。编排是在多个步骤中协调多个 LLM。不要混淆二者。将路由器构建为一个专注的独立组件。

5. 没有可观测性。

我们必须记录哪个 LLM 处理了哪个查询、成本、延迟和质量。没有这些日志，我们就无法调优路由器或发现错误的路由决策。

6. 基于错误信号进行路由。

仅根据查询长度路由是不够的。像“证明黎曼猜想“这样的短查询很困难，而像“请帮我总结这封邮件，谢谢“这样的长查询很简单。应使用意图和难度信号。