模型路由的第一性原理

背景

随着大语言模型（LLM）生态日趋丰富，开发者经常需要在多个模型之间进行选择，以平衡速度、质量和成本。模型路由（Model Routing）正是为了解决这一问题而出现的技术——它根据请求的特征动态地将任务分配给最合适的模型。近日，一位开发者在 Hacker News 上分享了他在构建模型路由工具 role-model 过程中的经验总结，提炼出三条“第一性原理”，为模型路由的设计和使用提供了实用指导。

核心内容

原文作者基于自己构建模型路由器（包括路由协议和 Pi 扩展）的实践，提出了三条原则，适用于使用或自行搭建模型路由器的所有人。

1. 保持模型的差异性（Keep models distinct）

作者观察到，有人会将最新的 GPT 模型与最新的 Opus 模型分别用于编码工作流中的不同角色。这种做法本身没有错，但从路由角度来看并非最优。因为 GPT 和 Opus 都是通用型模型，且都擅长编码，性能和成本处于同一梯队。这让路由变得困难——首先判断请求的难度以匹配合适的模型已经不容易，而两个模型在所有领域又不相上下时，更难决定该路由到哪一个。

因此，更好的做法不是在两个前沿模型之间路由，而是在一个前沿模型和另一个在速度、质量、成本这个“约束三角形”中至少一端表现出色的模型之间进行路由。例如，将 GPT 5.5 与 DeepSeek V4 Pro 配合使用，通过将中等和简单请求路由到更便宜的 DeepSeek V4 Pro 来扩展订阅配额。因为 DeepSeek V4 Pro 在极难任务上明显较弱，路由决策更容易做出。

2. 保持模型池规模小（Keep the model pool small）

这一条是上一条的推论。你可能会认为增加池中模型的数量是好事。比如，可以配置 role-model 使用 GPT 5.5、Kimi 2.7、DeepSeek V4 Pro、DeepSeek V4 Flash，甚至几个更小的 GPT 模型。但如果每个模型没有独特的特性，增加更多模型只会让路由决策更加困难。在实践中，这样的模型池最终可能只会由于性能原因路由到 GPT 5.5，以及另一个因缓存预热而被保留用于小任务的模型。

因此，除非你拥有特征差异明显的模型，否则不要向池中添加更多模型。默认将池大小限制为 2，只有在能明确定义每个模型角色时才增加。添加一个新模型是否提升了速度、质量或成本？如果没有任何提升，就不要加。

3. 使用相对、真实世界的基准测试（Use relative, real-world benchmarks）

作者发现，一些路由器仅根据模型元数据（如成本）进行路由，另一些路由器则会在元数据中加入来自 Artificial Analysis 等外部基准测试。这比什么都不做强，但还不够理想，因为基准测试可能无法提供足够细粒度的性能画像、不能反映你的真实工作负载、可能不是严格相对的，并且可能缺少某些模型的数据。

关键要点

• 核心原则：模型路由的设计应围绕速度、质量、成本三者之间的权衡，而不是在相似的通用模型之间做无用选择。
• 模型差异性：路由应当在特性差异明显的模型之间进行，例如一个前沿通用模型 + 一个在速度或成本上有突出优势的专长模型。
• 模型池精简：默认只维护 2 个模型，除非能清晰定义每个模型的独特角色并确认其能带来可量化的提升（速度、质量或成本）。
• 基准测试实用化：依赖外部静态基准可能不准确，应该使用相对且反映自身真实场景的基准来辅助路由决策。
• 避免“万能池”：增加无差异的模型只会增加路由决策的复杂度，反而降低效率和效果。

意义与影响

模型路由正成为实际部署 LLM 应用中的关键环节。该文提出的三条原则直击当前实践中的常见误区：一是过度“迷恋”前沿模型间的路由，二是盲目扩大模型池，三是轻信通用基准。这些原则不仅适用于专用路由器（如 role-model），也对任何需要做模型选型的工程团队有参考价值。

在成本敏感或需要控制延迟的生产环境中，合理运用这些原则可以显著降低调用成本、提高响应速度，同时保持可接受的质量。此外，对于模型提供商而言，清晰的差异化定位（而非一味追求全能）反而能更好地融入路由生态。未来，随着模型数量继续增长，模型路由的“第一性原理”将成为构建高效 AI 系统的重要基石。