我们不再相信模型路由。对于大多数用例，保持使用一个经过战斗考验的模型是你可以做的最好的事情。最近，围绕 AI 模型路由器的炒作非常巨大，这些路由器可以在飞行中选择响应你的请求的模型。最近几周，出现了许多类似的发布，承诺减少推理成本。我们也有自己的 LLM 路由器，但最终决定将其移除。首先提供一些背景：我们在三月份推出了 Manifest LLM 路由器，作为我们 LLM 网关中的一个关键功能，并于六月份弃用了它，最终在九月一日停止了它的运行。我们的路由器将每个请求分类为四种不同复杂度的层次：简单、标准、复杂和推理。与大多数 LLM 路由器一样，我们也是为了降低成本。为什么要为一项简单的任务调用强大且昂贵的模型呢？路由到最具成本效益的模型似乎是一个自然的解决方案，对吧？并不简单。在 7000 个云用户使用四个月后，我们看到了混合的结果以及大量的 GitHub 问题和讨论。让我们深入主要问题。复杂性不能仅仅从提示中推断出来。仅凭提示并不能包含整个任务；它只是一种触发器。很多决定复杂性的上下文只是在后续通过工具调用、网络搜索等过程中发现。举个例子：“评估 $GIT_REPO 的测试并改善它们”，如果你提到的是一个用纯 HTML5 编写的个人网站，这可以是一项非常简单的任务；或者如果你针对的是 Linux 内核库，则可能是一项极其复杂的任务。缓存比路由在降低成本方面更有效。缓存读取比未缓存输入便宜 75% 到 90%。系统提示和对话历史通常代表大量的 tokens。前缀缓存在这些方面工作得非常好，因为它们位于提示的开头。一个注意缓存的模型路由器会考虑这一点，通过增加初始选择的模型的“粘性”来保持对其的持续查询。换句话说，路由器将通过讽刺地“不干预”来完成它的工作。LLM 路由器破坏了行为的一致性 一些人说“工程师不应关心选择适合其任务的最佳 LLM”。我们强烈不同意。就像一位画家准确知道他们需要使用什么画笔一样，工匠仔细选择他们的工具，工程师也应该理解不同模型的权衡和细微差别。在 Manifest，每位工程师根据他们的意图选择模型和努力参数。在工作会话中切换模型会导致整体工作质量降低，并使人们与掌握他们的工具脱节。不可预测性是有代价的。没有人喜欢不可预测性，尤其是软件工程师。在自动代理工作流或自主代理中，管理那额外的层不确定性可能比节省的成本还要高。想想评估、系统提示、可观察性等等。一切突然变得更难以维护。隔离不同的请求并为其设置合适的模型、参数和提示，在大多数情况下似乎自然优越。结论 可能有许多用例在 LLM 路由中是有用的，那些推出这一功能的公司也可能有其充分理由。然而，根据我们的经验，我们得出的结论是，在我们看到的大多数用例中，这并不值得。节省的成本在其他地方都需要支出，而这个成本更难估算。