LLM 路由不是要解决的问题；token 效率才是

我最近看到市场上出现了 10 多个模型路由器，来自 Ramp、martian（再次）、Coinbase、Devin、cursor 等。而且大家都搞错了（某种程度上）。模型路由不是要解决的问题，真正的问题是 token 效率。如何将其作为闭环系统来衡量，并找到最佳方式来为正确的场景使用正确的模型，同时考虑到偏好、缓存和任务所需的输出 token。基准测试是地图，不是路由表。首先，我认为基于基准测试的路由器完全是失败的。基准测试让我们在受控、可重复的条件下比较模型。它们有助于缩小庞大的模型目录，识别大致的优势，并在应用拥有足够的真实流量进行评估之前引导路由。这使得它们成为 DigitalOcean 预设的宝贵起点。但模型性能取决于其周围的应用：系统提示词、工具定义、上下文、输出约束、对话历史以及成功的定义。改变测试框架，模型的相对排名也可能随之改变。一个在独立编码基准测试中表现最好的模型，可能并不适合在大型代码库中运行、拥有数十个工具和长对话历史的编码智能体。此外，一位开发者可能偏好某个特定模型的图像生成视觉风格。另一位可能更重视指令遵循、工具调用可靠性、延迟或成本。这些偏好都无法从通用排行榜中推断出来。因此，仅凭基准测试分数来预选模型并不是智能路由。路由必须首先理解开发者在优化什么。随着时间推移，这会变成一个个性化问题。但即使是感知偏好的路由器，如果孤立地评估每个请求，也可能做出错误的经济决策。更好的默认设置、更好的路由、更好的缓存。行业对快速增长的推理账单的第一反应往往是限制用量。但 91% 的 Coinbase 员工并未达到现有的使用上限。降低这些上限只会产生更多警报和更多摩擦，而无法解决大部分支出。Coinbase 转而采用更便宜的默认设置、任务感知路由和更好的缓存——并报告称将 LibreChat 的缓存命中率从 5% 提升到了 60%。这三个控制手段相互增强：更好的默认设置可以防止每个请求都从最昂贵的模型开始。偏好感知路由根据任务和开发者的价值观选择模型。缓存感知路由保留智能体会话中累积的经济价值，而不是在轮次之间将其丢弃。没有任何单一技术可以单独胜任。便宜的默认模型可能无法满足复杂任务的质量要求。基准驱动路由器可能无法反映应用的真实评估。缓存感知系统也不应该在某个热门模型不再适合当前工作时继续保留它。目标不是最大化 token 或盲目压低价格，而是在保持每个应用所需的质量、延迟和可靠性的同时，最大化每美元获得的有用智能。最后一块是通过对场景的 token 效率进行评估，并用不同模型进行模拟运行，从而创建最佳的全自动路由器。但这需要数据，并且要清楚“成功”是什么样的。所有想走捷径的人都不愿意在这方面投入那么多精力。没有人从整体上做这件事。这正是我愿意花钱买的东西。