LLM 路由器过时了，技术团队为何弃用

我们不再相信模型路由。对于大多数使用场景，坚持使用一个久经实战检验的模型，就是你能做出的最佳选择。

最近，AI 模型路由器的热度非常高。它们会即时选择用哪个模型响应你的请求。过去几周，不少产品相继发布，都做出了类似的承诺：降低推理成本。我们也曾推出自己的 LLM 路由器，但最终决定将它移除。

先补充一些背景：今年 3 月，我们发布了 Manifest LLM 路由器，将其作为 LLM gateway 的一项核心功能；6 月，我们将它标记为弃用，并于 9 月 1 日彻底关闭。我们的路由器会将每个请求划分为四种复杂度等级之一：简单、标准、复杂和推理。

与大多数 LLM 路由器一样，我们的产品也是为了降低成本。一个简单任务，为什么要调用能力强大、因而价格高昂的模型？把请求路由到性价比最高的模型，看起来是个顺理成章的解决方案，对吧？事情没那么简单。经过 4 个月的实际使用，覆盖 7000 名云端用户后，我们看到的结果喜忧参半，同时 GitHub 上也出现了大量相关 issue 和讨论。下面具体看看其中的主要问题。

无法仅凭 prompt 推断复杂度

prompt 并不包含任务的全貌，它只是触发任务的起点。许多决定任务复杂度的上下文，要到后续执行 tool call、网页搜索等操作时才会被发现。

举个例子：“评估仓库 $GIT_REPO 的测试并加以改进。”如果你指的是一个用纯 HTML5 编写的个人网站，这项任务可能非常简单；但如果目标是 Linux 内核仓库，它也可能复杂得难以想象。

在降低成本方面，缓存比路由更有效

读取缓存的成本比处理未缓存输入低 75%～90%。system prompt 和对话历史往往包含大量 token。由于它们位于 prompt 的开头，前缀缓存对这类内容非常有效。

具备缓存感知能力的模型路由器会考虑这一点：它会为最初选中的模型增加粘性，并持续向该模型发送请求。换句话说，颇具讽刺意味的是，路由器恰恰通过“不执行路由”来完成自己的工作。

LLM 路由器会破坏行为一致性

有人认为，“工程师不应该操心如何为自己的任务选择最合适的 LLM”。对此，我们强烈反对。

正如画家清楚自己究竟该用哪支画笔，工匠也会仔细挑选自己的工具一样，工程师应该理解不同模型之间的权衡与细微差异。在 Manifest，每位工程师都会根据自己的意图选择模型和 effort 参数。

在工作过程中不断从一个模型切换到另一个模型，会降低整体工作质量，也会让人们逐渐失去真正掌握工具的能力。

不可预测性是有成本的

没有人喜欢不可预测性，软件工程师尤其如此。

在自动化 Agent 工作流或自主 Agent 中，管理这一额外的不确定性层，付出的成本可能比节省的成本还要高。想想 eval、system prompt、可观测性等方面：一切都会突然变得更加难以维护。

在大多数情况下，将不同请求隔离开来，并分别为它们配置合适的模型、参数和 prompt，显然是更好的选择。

LLM 路由可能确实适用于许多使用场景，推出相关产品的公司大概也有充分的理由。

不过，根据我们的实践经验，我们得出的结论是：在我们见到的大多数使用场景中，LLM 路由并不值得。省下来的成本，最终会从其他地方付出去，而且那部分代价更加难以估算。