人人都在做LLM路由器，我们却弃用了

人人都在做LLM路由器，我们却弃用了。我们不再相信模型路由。对大多数用例而言，坚持使用一个经过实战检验的模型是最好的选择。最近，AI模型路由器备受炒作，它能即时选择响应你请求的模型。近几周有许多类似产品发布，都承诺降低推理成本。

我们也有自己的LLM路由器，并决定移除它。先交代背景：我们于3月推出Manifest LLM路由器，作为LLM网关的关键功能，6月弃用，9月1日彻底关闭。我们的路由器将每个请求分为四个复杂度等级：简单、标准、复杂和推理。

和大多数LLM路由器一样，我们的设计初衷是降低成本。为何要为简单任务调用强大且昂贵的模型？路由到最具成本效益的模型似乎是自然解决方案，对吧？其实没那么简单。经过7000名云用户四个月的使用，我们看到了好坏参半的结果，以及大量GitHub问题和讨论。

让我们深入探讨主要问题。复杂度不能仅从提示词推断。提示词本身并不包含整个任务，它只是触发器。许多决定复杂度的上下文是在后续的工具调用、网络搜索等过程中才发现的。

举个例子：“评估仓库$GIT_REPO的测试并改进它们”如果针对的是用纯HTML5编写的个人网站，可能非常简单；但如果目标是Linux内核仓库，则极其复杂。缓存比路由更能降低成本。缓存读取比未缓存输入便宜75%到90%。

系统提示词和对话历史通常占据大量token。前缀缓存对这些非常有效，因为它们位于提示词开头。缓存感知的模型路由器会通过向初始选择的模型添加粘性并持续查询它来考虑这一点。换句话说，路由器会通过不路由来履行职责，这很讽刺。

LLM路由器破坏行为一致性。有人说“工程师不应担心为任务选择最佳LLM”。我们强烈反对。正如画家清楚自己需要什么画笔，工匠精心选择工具，工程师也应理解不同模型的权衡和细微差别。在Manifest，每位工程师都根据意图选择模型和努力参数。

工作期间频繁切换模型会降低整体工作质量，并使人们无法精通自己的工具。不可预测性有代价。没人喜欢不可预测性，尤其是软件工程师。

在自动化智能体工作流或自主智能体中，管理额外的不确定性层可能得不偿失。想想评估、系统提示词、可观测性等，一切都变得更难维护。在大多数情况下，隔离不同请求并为其设置正确的模型、参数和提示词似乎自然更优。

结论：LLM路由可能在某些用例中有用，推出这些产品的公司或许有充分理由。然而，根据我们的经验，在我们看到的大多数用例中，它并不值得。节省的金额会在别处付出代价，而那种成本更难估算。