用前沿模型跑编码和其他任务可能非常贵，但有时也非常有效。人们很容易想用更小或更老的模型来替代前沿模型，因为它们更便宜，尽管效果可能差一些。对任何给定任务来说，理想模型往往取决于任务的复杂度。根据请求和上下文自动挑出最合适的模型，这种做法叫模型路由。

模型路由怎么运作

实现模型路由有好几种方式。总体而言，它取决于可用的模型池、选择模型的标准，以及路由器试图优化的目标。不同厂商给出的实现各不相同。

Databricks的Unity Gateway提供了（测试中的）面向Codex或Claude Code的Smart Routing。Smart Routing会自动选择能够处理每项任务的最低成本模型，开发者不必为每一次请求挑模型。

微软的模型路由器是一个训练过的语言模型，会根据复杂度、推理需求、任务类型等属性实时分析你的提示词。它不存储你的提示词，只把请求路由到你有权访问、且部署类型允许的模型，并遵守数据区域边界。你可以选择均衡模式、成本模式或质量模式。

Not Diamond Code使用一个轻量的本地代理，计算出路由所需的派生元数据，用来评估更完整的会话，包括预期的下游工作和缓存状态，并选出能让预期质量与总会话成本最优的模型和推理力度。当更强的模型更可能改善结果或减少步骤时，它会用更强的模型；当额外的智能不太可能带来价值时，它就用更划算的模型。

英伟达的NeMo Switchyard有一整套可用的路由算法。其中包括LLM分类器，用一个LLM当裁判来挑选候选LLM，并在后续轮次中与该模型保持会话亲和；阶段路由器，检查最近的工具调用活动，判断智能体需要多少模型能力；升级路由器，让每段对话从低成本模型开始，一旦检测到持续困难就升级到更强的模型；还有可训练的预填充路由器，从工作负载数据中学习，预测模型成功的可能性。

OpenRouter的Auto Router会分析你的提示词，根据OpenRouter社区总体上在这类工作里用什么模型来做选择。选择受你的成本档位和护栏约束。如果自动选出的首选模型失败，路由器会使用备用方案。

Replit的Intelligent Model Routing把任务匹配到最适合它们的模型，目标是平衡质量、速度和成本。

Snowflake的Cortex AI Gateway使用动态模型路由，在智能体执行的每一步选出能够有把握完成任务的最便宜模型。复杂度较低和重复性的任务可以导向更高效的模型，而需要更深推理的工作负载可以路由到前沿模型。

还有一点值得注意：2024年的RouteLLM论文提出了几种高效的路由器模型，在推理过程中动态地在较强和较弱的LLM之间做选择，目标是优化成本与响应质量之间的平衡。论文还为这些路由器提出了一个训练框架，利用人类偏好数据和数据增强技术来提升表现。

省钱这笔账

模型路由有可能带来大幅成本下降、更低的平均延迟、更优的质量、更少的供应商锁定、更强的隐私保护，以及更好的运营韧性。单纯从成本角度看，日活跃用户超过10万时，模型路由很可能就能收回投入。即使只省下20%的LLM账单，节省也相当可观，而50%的成本下降很常见，95%的降幅也并非闻所未闻。

可惜，推理成本并不能说明全部问题。还有一些间接成本，包括质量评估的开销、人工复核和基础设施。

还有一种糟糕的失败模式，能把你的推理成本节约变成四到五倍于此的客户留存与支持成本，这就是帕累托陷阱。要理解它，得从Vilfredo Pareto在1906年的观察说起：意大利王国80%的土地由20%的人口拥有。1941年，Joseph M. Juran把这套说法改编用于质量控制：80%的问题源自20%的原因。帕累托陷阱指的是只盯着并过度优化前20%，而忽略了剩下的80%。

本质上，如果你的模型路由器只针对复杂度最高的20%查询做了调优、把它们交给前沿模型，就有风险把过多边缘情况（也就是中等复杂度的查询）送给那些答不对的便宜模型。这会造成便宜模型的隐性失败，进而对业务产生昂贵的后果。

怎么绕开帕累托陷阱

有多个步骤可以避开这个陷阱。一是更广泛的监控，即使失败出现在别的部门也能被暴露出来。二是对模型路由器做更保守的调优。第三，使用更复杂的路由模型，更准确地预测查询复杂度。

模型路由优化的是为特定任务选择合适的模型，在成本、质量和延迟之间取得平衡。各厂商实现方式不同，会利用任务复杂度、推理需求、成本等因素来判断最佳模型。模型路由能带来显著的成本节省和性能提升，但也带来挑战，比如帕累托陷阱——过度优化成本，会导致较简单的查询出现隐性失败。