众人都在造LLM路由，我们却弃用了
Everyone is building LLM routers, we deprecated ours
我们不再相信模型路由的价值。在Manifest，我们曾推出LLM router作为LLM gateway的核心功能，试图通过动态选择模型来降低推理成本。但在服务7000名云用户四个月并收到大量反馈后，我们决定在9月1日彻底弃用该功能。我们发现，仅凭prompt无法准确判断任务复杂度，而缓存机制在降低成本上远比路由有效。更关键的是，频繁切换模型破坏了行为一致性，增加了不可预测性，导致维护成本反而上升。工程师应像工匠一样精心选择工具，而非依赖自动路由。最终我们得出结论：省下的钱往往在其他地方付出了更高代价。
HN 评论区
84- overgard
就像画家清楚该用什么画笔，工匠会仔细挑选工具一样，工程师也应该理解不同模型之间的权衡与细微差别。
我对这个想法非常怀疑。从实际角度看：当每周都有新模型出现时，谁有时间去搞懂这些模型的细微差别？而且，由于无法窥探训练过程，判断每个模型擅长什么，基本上就是往墙上乱扔意大利面——只不过这意大利面可能非常昂贵，还可能在你的代码库中埋下一些隐蔽的问题。
- dweez
去年我花了很多时间研究 LLM 路由，也得出了同样的结论：这通常不值得投入精力。因为很难在事前就判断出一个查询的难度。
我遇到的一个具体挑战是：难度很大程度上取决于智能体能否检索到相关信息。以“5 状态忙忙数（busy beaver number）是多少？”这个问题为例（https://en.wikipedia.org/wiki/Busy_beaver）。在 2023 年，这属于 Mythos 级别的难题，但 2024 年已有证明，所以今天任何具备基础智能且配有网页搜索工具的模型都能直接获取答案。在真正开始之前，你根本无法知道哪些查询只是简单的摘要任务，哪些需要深度推理。
- velcrovan
颇具讽刺意味的是，看到下面这句彻底翻车的句子后，我反而更确信这篇文章至少有人类参与撰写或编辑：
> “一个感知缓存的模型路由器会将此纳入考量，通过为初始选定的模型增加‘粘性’，并持续向其发起查询。”
- jeremyjh
我同意其中一点区分——在编码智能体工作流中，可以使用预定义的子智能体角色，并将它们绑定到特定模型上，我发现这种方法非常有效。编排器（orchestrator）正在构建所有上下文来完成这些分配，它可不是一个笨拙的路由器。例如，用 Minimax M3 来处理探索任务和图书管理员任务，既快又便宜——我每月 10 美元的套餐能用整整一个月，还为我主要的编码计划节省了大量 token。
- try-working
我最近写了一篇关于构建模型路由器时所领悟到的模型路由第一性原理的文章。
模型池应该保持精简，池中的模型应界限分明。例如，用一个大型前沿模型保障质量，再用一个小型、快速且廉价的模型（如 DeepSeek V4 Flash）来处理路由工作。
仅凭这两条原则，就能解决缓存和路由决策的问题。我在 GPT 5.4 和 DeepSeek 之间进行路由时，缓存命中率 routinely 超过 99%。