5 篇博文 含有标签「model-routing」

某中型 SaaS 公司的团队六个月前部署了一套模型路由器，目标明确：不再为 70% 的简单查询和格式转换任务支付前沿模型的高昂费用。他们运行了三个月，直到有人做了一道算术题。总推理成本上涨了 12%。

路由器本身并不贵——一个轻量级分类器，每个请求增加约 2ms 的开销。但分类器的决策边界校准有误：它将 60% 的查询升级到了昂贵模型，而非预期的 30%。那 40% 在本地处理的请求质量较差，导致用户重试率上升，进而拉高了总请求量。路由器的遥测数据显示"路由运行正常"，因为它确实在路由——只是路由得不好。

这种失败模式远比成功案例更为普遍。以下是如何构建真正能省钱的路由系统。

每个部署 LLM 路由的团队都是同样的起步方式：按价格排列模型，将简单查询发送给便宜的模型，复杂查询发送给昂贵的模型，然后庆祝成本降低了 60%。六周后，有人发现合同分析准确率从 94% 降到了 79%，编码助手开始虚构不存在的 API 端点，复杂支持工单的客户满意度直线下滑——而路由仪表盘上仍然显示"质量保持 95%"。

问题不在于路由本身。问题在于，仅优化成本的路由将所有质量下降视为等同，而实际上你降级的那些查询恰恰是质量最重要的那些。

人们的本能总是去选择最大的模型。GPT-4o、Claude Opus、Gemini Ultra——选一个前沿模型，把问题丢给它，然后寄希望于强大的能力来弥补架构上的懒惰。这在演示中行得通，但在生产环境中会失败。

2025 和 2026 年，那些交付最可靠 AI 系统的团队并没有使用单一模型。他们将三个、四个甚至五个专业化模型组合成流水线，每个组件只做好一件事。分类器负责路由，生成器负责产出，验证器负责检查。最终得到的系统不仅优于任何单一模型，而且成本只是"万事皆用前沿模型"方案的一小部分。

大多数团队都会选择一个阵营：要么将所有任务运行在云端，要么将所有任务推向边缘。对于大多数生产负载来说，这两种做法都是错误的。有趣的工程挑战发生在它们之间的路由层（routing layer）——这个组件根据每个请求来决定：该查询是需要 H100 上的 70B 前沿模型，还是在本地芯片上运行的 3B 量化模型。

这种路由决策不仅仅关乎延迟。它是一个涉及成本、隐私和能力的三变量优化过程——而最优的分配方案会根据你的流量模式、监管环境以及对每种查询类型“足够好”的定义而改变。正确处理路由的团队在降低 60–80% 推理成本的同时，还能优化 p95 延迟。处理不当的团队要么在简单的查询上过度消耗云端 GPU，要么让无法处理复杂任务的边缘模型提供质量下降的回答。

大多数生产环境中的 AI 系统在成本管理上都会犯同样的错误：它们上线时仅使用单一的最强模型 (frontier model) 来处理每个请求，眼睁睁看着 API 账单随流量线性增长，然后才手忙脚乱地添加缓存或缩减上下文窗口来补救。真正的解决方法——根据每个查询的实际需求将其路由到不同的模型——事后看来显而易见，但很少能被很好地实现。

数据能够清楚地说明问题。当前的最强模型 (frontier model)，如 Claude Opus，每百万输入 token 的成本约为 5 美元，每百万输出 token 为 25 美元。同系列的高效模型成本分别为 1 美元和 5 美元——比例达 5 倍。使用 RouteLLM 的研究表明，通过合理的路由，你可以在将 85% 的查询路由到更便宜的模型的同时，保持 95% 的最强模型质量，从而根据工作负载实现 45–85% 的成本降低。这不仅仅是边际改进；它改变了大规模部署 AI 的单位经济效益。