14. 如果要把你的系统从单模型切换到多模型路由架构，你会怎么设计？

简单回答

多模型路由架构的核心是一个 Router——根据请求的特征（难度、类型、成本约束等）把请求分发到不同的模型。设计要点包括：路由策略（基于规则、基于分类器还是基于 LLM）、模型池的选择和管理、统一的接口抽象（不同模型的 API 差异要在网关层屏蔽）、fallback 机制（主模型失败时自动切换到备用模型）、以及效果和成本的监控。

详细解释

为什么要多模型路由

单模型架构简单但有局限——你只能用一个模型，要么选贵的保效果（成本高），要么选便宜的省成本（效果可能不够）。多模型路由的价值在于"因材施教"——简单任务用便宜模型，复杂任务用强模型，既控制了总成本又保证了复杂任务的效果。

另一个驱动因素是可用性——如果只依赖一个模型 Provider，它出故障（限流、宕机、API 变更）整个系统就挂了。多模型路由天然支持 fallback，提升了系统的健壮性。

路由策略

基于规则的路由是最简单的方式。根据请求的显式特征做分发——比如按输入长度（短 query 走小模型、长 query 走大模型）、按任务类型（分类任务走小模型、生成任务走大模型）、按用户等级（免费用户走便宜模型、付费用户走强模型）。优点是简单可控、延迟几乎为零。缺点是规则可能覆盖不全，需要人工维护。

基于分类器的路由训练一个轻量级的分类模型来判断每个请求应该走哪个模型。训练数据可以这样构造——让所有候选模型都回答同一批问题，标注哪个模型在哪个问题上表现最好或"足够好"，用这些标注训练 Router 分类器。

分类器通常是一个小的 BERT 或 Embedding + 线性层，推理延迟几毫秒，不会成为瓶颈。但需要定期用新数据重新训练以适应请求分布的变化。

基于 LLM 的路由更灵活但成本更高。用一个 LLM 分析请求的复杂度和需求，决定路由。优点是能处理复杂的判断逻辑，缺点是多了一次 LLM 调用的延迟和成本——这在一定程度上抵消了路由的成本节省。通常只有在路由逻辑非常复杂时才值得用。

统一接口层

不同模型的 API 格式各不相同——OpenAI 的消息格式和 Anthropic 的不一样，参数命名不同，返回结构不同。需要一个统一的接口层（LLM Gateway）屏蔽这些差异——业务代码调用统一接口，Gateway 内部做协议转换。

OpenAI 的 API 格式已经成为事实标准——很多框架和工具都兼容。可以选择把所有模型的接口统一成 OpenAI 格式。LiteLLM 是一个开源的统一接口库，支持 100+ 模型 Provider。

Fallback 机制

当主模型不可用时（API 限流、超时、返回错误），自动切换到备用模型。Fallback 的设计需要考虑：优先级顺序（先试哪个备用模型）、重试策略（是否重试原模型、最多重试几次）、以及降级逻辑（所有模型都不可用时怎么办——排队等待还是返回错误提示）。

效果和成本监控

多模型路由增加了监控的复杂度。需要分模型监控——每个模型的调用量、延迟、成功率、效果指标（如果有自动评测的话）。还需要监控路由的准确性——有没有"该用大模型的请求被路由到了小模型导致效果差"的情况。

成本监控要分模型统计 token 消耗和费用，并和路由前（全部用大模型）做成本对比，量化路由带来的节省。

A/B 测试

多模型路由系统需要能方便地做 A/B 测试——比如验证"在路由策略 A 下效果/成本比路由策略 B 好"。需要流量分配能力（按比例把流量分到不同路由策略）和效果对比能力。

面试时可以这样答

多模型路由架构我会从几个方面设计。

路由策略上先做基于规则的简单路由——按任务类型或输入复杂度分发。如果规则覆盖不够再训练一个轻量级分类器来做路由，推理几毫秒不会增加延迟。

统一接口层很重要——不同模型的 API 格式不同，需要一个 Gateway 层做协议转换。业务代码调用统一接口，不感知底层用的是哪个模型。LiteLLM 可以作为起点。

Fallback 机制是必须的——主模型限流或超时时自动切备用模型，保证可用性。这也是多模型架构的核心价值之一。

监控要分模型统计调用量、延迟、成功率和效果指标。还要监控路由准确性——有没有应该用强模型的请求被误分到弱模型的情况。成本方面要和全量用大模型做对比，量化路由带来的节省。

常见追问

1. 路由分类器的训练数据怎么构造？
2. 不同模型的输出风格不一致怎么处理？
3. 如果路由分错了影响到用户体验怎么办？