我们不再相信模型路由。对于大多数用例，坚持使用一个经过充分验证的单一模型是最佳选择。尽管近期AI模型路由器因降低成本而备受追捧，但我们在7000名云用户中测试四个月后，发现效果参差不齐，最终决定弃用该功能。

好的，这是根据您的要求，对原文进行中文重述和精简后的版本：

标题：我们为何放弃了自己的大模型路由方案

我们不再看好模型路由。对大多数应用场景而言，坚持使用一个经过充分验证的单一模型是最佳选择。

近期，AI模型路由器（能动态选择模型来响应用户请求）备受追捧，许多公司宣称它能降低推理成本。我们曾开发过自己的大模型路由功能，但最终决定将其移除。

背景是：我们于今年3月推出了Manifest LLM路由器，作为我们LLM网关的核心功能，但在6月宣布弃用，并于9月1日彻底关闭。该路由器将每个请求按复杂度分为四个等级：简单、标准、复杂和推理。

和大多数LLM路由器一样，我们的设计初衷也是为了降低成本——毕竟，处理简单任务无需调用昂贵的大模型。然而，经过4个月、覆盖7000名云用户的实践，结果喜忧参半，并引发了大量GitHub讨论。主要问题如下：

1. 复杂度无法仅凭提示词判断 提示词本身只是任务的触发器，并不包含全部上下文。许多决定任务复杂度的关键信息（如工具调用、网络搜索等）只有在执行过程中才会显现。例如，“评估并改进仓库$GIT_REPO的测试”这个任务，如果仓库是一个简单的个人网站，任务就很简单；但如果目标是Linux内核仓库，任务则极其复杂。

2. 缓存比路由更能有效降低成本 缓存读取的成本比未缓存的输入低75%到90%。系统提示和对话历史通常包含大量令牌，而前缀缓存对这些位于提示词开头的部分效果极佳。一个考虑缓存的模型路由器，会倾向于“粘住”最初选定的模型并持续查询它。讽刺的是，路由器为了高效，反而要“不作为”。

3. LLM路由器破坏了行为一致性 有人认为“工程师不应操心为任务选择最佳模型”，但我们强烈反对。正如画家和工匠深知自己需要何种工具，工程师也应理解不同模型的优劣与细微差别。在Manifest，每位工程师都根据意图自行选择模型和参数。在工作会话中频繁切换模型，会降低整体工作质量，并让使用者无法精通其工具。

4. 不可预测性本身就有成本 没有人喜欢不可预测性，尤其是软件工程师。在自动化工作流或自主智能体中，管理模型路由带来的额外不确定性层，其成本可能超过节省的费用。评估、系统提示、可观测性等一切都会变得难以维护。将不同请求隔离，并为它们分别配置合适的模型、参数和提示词，在大多数情况下是更优的选择。

结论 模型路由在某些场景下或许有用，推出相关产品的公司也自有其理由。但根据我们的经验，在大多数我们看到的用例中，它并不值得。节省下来的成本，会在别处以更难估算的方式付出代价。

以下是对评论内容的总结，涵盖主要观点、论据及不同立场，并保留了关键引用。

主要观点与论据

1. 路由器的有效性普遍受质疑 - 核心观点：多数评论者认为，基于提示词复杂度进行路由的通用型路由器效果不佳，难以实现预期价值。 - 关键论据： - 任务复杂度无法从提示词中预先判断，需依赖执行过程中的上下文（如工具调用结果）。 - 路由器本身需足够“智能”，成本高昂，且可能不如直接使用单一优质模型。 - 关键引用： - "I find this routing problem to be opaque and I’m generally skeptical that the label people are trying to predict is meaningful." (mmargenot) - "I spent a lot of time researching LLM routing last year and also came to the conclusion that it's generally not worth the effort." (dweez)

2. 路由器的适用场景与条件 - 核心观点：路由器在特定条件下有价值，如处理合规问题、实现故障转移、或用于上下文明确的代理工作流。 - 关键论据： - 在受监管行业中，路由器可处理GDPR、数据驻留等法律问题。 - 对于生产关键服务，故障转移是路由器的重要职责。 - 在代理工作流中，为特定子任务分配固定模型（如编码用Claude，通用知识用Gemini）效果显著。 - 关键引用： - "Some routing services not just route to different LLMs, they also handle all the legal issues..." (coffinbirth) - "I think fail-over for a production critical service is an equally important responsibility of the router." (robertclaus) - "I've gotten routing working well for typical chatbot prompts... You want Gemini to answer General Knowledge and you want Claude to answer coding." (seizethecheese)

3. 路由器的设计原则与替代方案 - 核心观点：成功的路由器应保持模型池小而精，或采用更智能的架构（如基于初始轨迹路由），而非简单分类复杂度。 - 关键论据： - 模型池应包含少数明确差异化的模型（如一个前沿模型+一个快速廉价模型），以解决缓存和决策问题。 - 基于模型初始输出轨迹的路由（如让多个模型开始工作，再择优保留）可能更有效。 - 直接对模型进行微调或强化学习，可能比通用路由器更高效。 - 关键引用： - "The model pool should be kept small, and models in the pool should be clearly differentiated." (try-working) - "It routes based on the models' initial trajectories. This is like having multiple developers get started..." (seizethecheese) - "If you really need more discrimination... sft or rl tuning something for your harness would be more effective." (mmargenot)

4. 对路由器未来发展的不同看法 - 核心观点：部分评论者认为路由器是过渡方案，模型提供商最终会内部解决成本优化问题；另一些人则认为路由器在代理工作流中仍有发展空间。 - 关键论据： - 模型提供商有动力通过内部技术（如推测解码）降低成本，外部路由器难以与之竞争。 - 随着小型模型能力增强，“智能模型协调小模型”的编排模式可能成为主流。 - 路由器在代理工作流中需跳出“输入-路由-输出”的传统思维，转向更动态的融合设计。 - 关键引用： - "The labs are incentivized to solve this problem themselves... There are nicer solutions available to them because they can cut into lower levels of abstraction." (scionaura) - "I think the orchestrator pattern of a smart model coordinating smaller models for work will end up being the way to go." (maherbeg) - "I think the author need to rethink... how a router would work in agentic workflow." (blackcat201)

平衡性总结

• 反对派：多数评论者认为通用路由器不实用，主要障碍在于无法预判任务复杂度、成本高、且模型提供商可能内部解决。
• 支持派：少数评论者指出路由器在合规、故障转移、特定代理工作流中有明确价值，但需精心设计（如小模型池、基于轨迹路由）。
• 中立派：部分评论者认为路由器在规模化查询下可能值得投入，但需结合具体场景，且未来可能被更智能的编排模式取代。