模型路由的第一性原理

# 模型路由的第一性原理 — Try-Works 来源：https://try.works/first-principles-of-model-routing 以下是几条我在构建 role-model（https://github.com/try-works/role-model）——一个模型路由器、路由协议及 Pi 扩展——的过程中总结出的模型路由原则。这些原则对使用或自行构建模型路由器的人都会有所帮助。 **1. 保持模型之间的差异性** 我有时会看到有人将最新的 GPT 模型与最新的 Opus 模型配合使用，在编码工作流中让它们扮演不同角色。这种做法本身没有错，但从路由角度看并非最优。 虽然人们对 GPT 和 Opus 模型有不同的体验和偏好，但它们都是擅长编码的通才模型，处于相同的性能和成本层级。 这意味着在两者之间进行路由非常困难——因为判断请求难度并匹配合适的模型已经不易，而在这之后，当两个模型在所有方面都旗鼓相当时，要决定将请求发给哪一个就更难了。 更好的做法不是在两个前沿模型之间路由，而是在一个前沿模型与另一个至少能在速度、质量、成本“三角约束”中的某一方面表现突出的模型之间进行路由。 例如，将路由器与 GPT 5.5 配合使用，通过将中等和简单的请求路由到 DeepSeek V4 Pro 来扩展你的订阅配额。DeepSeek V4 Pro 明显更便宜，在非常困难的任务上也明显能力更弱，因此路由决策更容易做出。 **2. 保持模型池规模小** 这一点是上一点的延伸。你可能会认为增加池中路由的模型数量是件好事。 例如，我可以配置 role-model 使用 GPT 5.5、Kimi 2.7、DeepSeek V4 Pro、DeepSeek V4 Flash，甚至加上几个小型的 GPT 模型。 但如果每个模型没有独特的特性，添加更多模型只会让路由决策更加困难。实际上，这个池很可能最终只会将请求路由到 GPT 5.5（因为性能）和另一个被选中并因缓存升温而保留给较小任务的模型。 因此，除非你拥有具有明显差异的模型，否则不要往池中添加更多模型。默认将池大小限制为 2，只有当你能够清晰定义每个模型扮演的角色时才增加更多模型。添加一个模型能提升速度、质量或成本吗？如果不能，就不要添加。 **3. 使用相对的、基于真实场景的基准测试** 我有时看到一些路由器仅基于成本等模型元数据进行路由，另一些路由器则会在元数据中加入来自 Artifical Analysis 等外部来源的基准测试数据。这聊胜于无，但并不理想，因为基准测试可能无法提供足够细致的性能画像，可能无法反映你的真实工作负载，可能不是严格相对的，并且可能缺少某些模型的数据。 此外，模型在不同远程端点上表现不同，会随时间变化，在不同本地系统上表现也不同。 为了获得池中模型画像的清晰数据，最好在你的路由器中运行基准测试，对每个测试用例标记能力（工具使用、视觉等）、任务或角色，然后让模型相互比较性能表现，以构建更丰富的路由画像。 **4. 评估历史决策以丰富路由决策数据** 基准测试应仅被视为起点。当我们路由请求时，实际上是在以某种方式预测未来：给定包括成本和速度在内的各种参数，哪个模型能在该请求上表现最优？ 应该通过基于历史请求创建用户特定的评估，并将这些评估作为基准测试在模型池中运行，来重新审视这些决策。这是你能获得的关于模型如何表现以及如何路由它们的最佳信号。 此外，遥测数据能告诉我们端点的稳定性、请求的周转时间以及其他元数据目录中未捕获的信息。 如果你读到了这里，你可以用自己选择的模型通过 role-model 尝试模型路由。查看下方评论中的仓库链接。