模型选择的工程约束

单一供应商的供应链风险

供应链管理中有一条基本原则：关键零部件不能只有一个供应商。LLM 应用对单一模型的依赖不仅如此，而且风险更大——模型提供商的变化速度远超传统供应商。

模型的变化有四种形态。升级就是破坏性变更：模型行为的变化弥散、统计、难以预测，你的 prompt 在旧版本上精心调优的效果可能在新版本上完全失效。模型下线：当你依赖的特定版本被停止服务，迁移意味着重新调优所有 prompt、重新运行所有评估。定价变化：涨价或改变计费方式可能让你的成本模型瞬间失效。质量退化：最隐蔽的风险，模型在某次更新后在你的特定用例上表现变差，而 benchmark 衡量的是平均表现，不会替你发出预警。

锁定是一个渐进的过程。在三个层面上越来越深：prompt 层面（针对特定模型调优的 prompt 在其他模型上可能需要重做）、API 层面（不同提供商的接口不完全兼容）、能力层面（依赖特定模型独有的功能）。三个层面的锁定相互强化，切换成本随时间越来越高。

成本是架构约束

几乎所有 LLM 应用的开发都从一个让人兴奋的原型开始，API 调用成本几分钱，完全不值得关注。然后上线了，月底账单可能让你怀疑这个项目还做不做得下去。

这个故事反复发生的原因是：成本是乘法结构。

总成本 = (输入 token 单价 x 输入 token 数 + 输出 token 单价 x 输出 token 数) x 调用频次

原型阶段通常只关注单价，而忽略了 token 数和频次这两个乘数。当乘数从"手动测试几次"变成"生产环境中每天十万次调用"时，成本增长五个数量级。一个典型的 RAG 问答场景，日调用十万次，月成本可达六位数美元——这个数字在设计阶段用乘法就可以估算，不需要上线后才知道。

成本的隐性来源经常被忽略：RAG 中每次注入的检索上下文、多轮对话中累积的历史、重试和验证产生的冗余调用、输出 token 高于输入 token 的价格差异。这些乘数叠加后，实际调用成本可能是业务逻辑所需的 2-3 倍。

模型选择是多维约束优化

模型依赖风险和成本约束不是两个独立的问题。它们是模型选择这个决策空间中的不同维度。正确的做法是在设计阶段将两者纳入同一个决策框架：

按任务复杂度路由。 不同任务适配不同规模的模型。简单分类用小模型，复杂推理用大模型，延迟敏感的任务用响应快的模型。业务逻辑依赖你自己定义的接口，具体模型是接口的实现——当需要切换时，修改的是实现和路由表，不是散布在代码库中的 API 调用。

在架构层面保持可替换性。 接口按能力划分（文本生成、结构化输出、分类），具体绑定哪个提供商是实现细节。价值不在于抽象本身的复杂度，而在于在架构层面确立了一个原则：业务逻辑不直接依赖具体的模型提供商。

在设计阶段就考虑成本。 缓存相同或相似的查询；压缩检索上下文和对话历史；通过 prompt 设计和 max_tokens 控制输出长度；对延迟不敏感的任务批量处理。这些是设计阶段就应该做出的架构选择。

评估体系是多模型策略的前提

没有评估体系的多模型策略是空谈。你需要为每个关键任务维护一个评估集，并定期在多个模型上运行评估。根据评估结果决定路由：哪个模型在哪类任务上性价比最优。当某个模型升级后表现退化时，评估结果会捕获这个变化，路由策略随之调整。

第二章讨论的这条原则在这里直接适用——模型提供商的未来行为是不确定的，成本也是不确定的，在架构上得给这两种不确定性留出余量。