新模型密集上线后的选型与路由教程

一、教程目标：不是追新，而是建立可替换的模型接入体系

在模型更新频率明显提升的阶段，开发者面对的核心问题已经不再是“有没有可用模型”，而是“如何在多个模型之间做出稳定、低成本、可维护的选型”。

本教程的目标是帮助读者完成一套完整的多模型接入方案：

1. 建立统一的模型接入层，避免业务代码直接绑定某一类模型。
2. 设计“轻量模型默认、高能力模型兜底”的分层策略。
3. 通过客户端或服务端路由控制请求流向。
4. 将平台容灾作为辅助能力，而不是唯一依赖。
5. 建立可观测、可灰度、可回滚的模型调用闭环。
6. 在效果、成本、延迟和稳定性之间取得平衡。

适合阅读本教程的读者包括：后端开发者、AI 应用开发者、平台工程师、运维人员、技术负责人，以及正在规划模型服务架构的企业技术团队。

二、适用场景：哪些业务需要多模型路由

当业务开始频繁调用大模型时，单一模型往往难以同时满足效果、成本和延迟要求。以下场景尤其适合采用多模型路由：

1. 智能问答与客服
   简单咨询占比高，可由轻量模型承接；复杂投诉、多轮推理可升级到高能力模型。

2. 代码助手与终端辅助
   代码生成、命令补全、日志分析等任务对上下文理解要求较高，可设置专门的高能力模型通道。

3. 文档摘要与信息抽取
   大量请求属于结构化任务，适合先用低延迟模型处理，失败或低置信度时再切换。

4. 表格处理与结构化生成
   对格式准确性要求较高，需要模型具备较强的指令遵循和结构化输出能力。

5. Agent 与多步骤任务
   单轮请求可能触发多次模型调用，必须考虑超时、重试、降级和成本控制。

6. 批量生成与离线任务
   延迟要求较低，但成本敏感，适合通过缓存、批处理和分级模型降低整体开销。

三、前置准备：开始之前需要具备什么

在开始配置路由之前，需要先完成基础准备。否则即使接入多个模型，也很难判断效果好坏与成本是否合理。

1. 梳理业务请求类型

建议先按任务类型对请求进行分类，例如：

• 短文本问答
• 长文档摘要
• 代码生成
• 终端命令解释
• 表格抽取
• 多轮对话
• 工具调用或流程执行

每一类请求都应记录典型输入长度、期望输出格式、允许延迟和准确率要求。

2. 建立模型池

模型池不一定需要包含所有模型，但至少应分为三类：

• 轻量档：低延迟、低价格，适合高频简单请求。
• 平衡档：效果和成本折中，适合普通业务请求。
• 高能力档：复杂推理、长上下文、代码或终端任务，适合兜底和升级。

模型池应以配置表方式维护，而不是散落在业务代码中。

3. 准备统一调用层

建议所有模型调用都经过统一封装，例如网关、服务层或客户端代理。统一调用层负责：

• 模型选择
• 参数转换
• 超时控制
• 重试与降级
• 日志记录
• 成本统计
• 限流与熔断

4. 准备日志与监控

至少需要记录以下信息：

• 请求唯一标识
• 命中的模型类别
• 输入 token 数
• 输出 token 数
• 请求耗时
• 是否超时
• 是否重试
• 是否触发兜底
• 错误码
• 单次请求成本估算

没有日志和监控，路由策略很快会变成黑盒。

5. 准备评测样本

建议从真实业务中抽取脱敏样本，形成小型评测集。评测集不必很大，但要覆盖典型场景，包括：

• 常见问题
• 边界问题
• 长文本问题
• 格式敏感问题
• 曾出错的样本

四、核心原则：Flash 档默认，Pro 档兜底，路由可控

在多个模型并存时，常见误区是让所有请求都走最强模型。这样虽然可能提升效果，但会显著增加成本和延迟。更稳妥的方式是分层使用。

原则一：轻量模型作为默认

大多数业务请求并不需要最高能力模型。将轻量模型作为默认通道，可以：

• 降低平均延迟
• 降低单次调用成本
• 提高整体吞吐量
• 减少高能力模型被普通请求占满的概率

原则二：高能力模型作为兜底

当出现以下情况时，应升级到高能力模型：

• 轻量模型返回失败
• 响应超时
• 结构化输出解析失败
• 置信度低于阈值
• 输入过长或任务复杂
• 业务规则判断需要升级

原则三：路由逻辑尽量放在客户端或服务端

路由不应完全依赖平台侧自动切换。原因包括：

• 业务规则通常只有应用侧最清楚
• 不同请求需要不同升级条件
• 成本控制策略需要应用侧统一执行
• 平台容灾不一定支持指定备选模型

原则四：平台容灾只能作为辅助

平台级容灾可以提升可用性，但不应假设平台一定会切换到指定模型。应用侧仍需保留：

• 多模型配置
• 本地重试
• 超时降级
• 错误兜底
• 熔断保护

五、实施步骤：从零搭建多模型路由

第一步：定义请求分类规则

首先需要把请求分类。分类可以基于业务字段，也可以基于输入特征。

常见分类依据包括：

• 任务类型：问答、摘要、代码、表格、多轮对话
• 输入长度：短文本、中等长度、长上下文
• 用户等级：普通用户、付费用户、内部系统
• 输出要求：普通文本、JSON 结构、代码片段、表格结构
• 风险等级：普通请求、敏感请求、高风险请求

示例分类逻辑：

if task_type == "code" or input_length > 30000:
    route = "strong"
else:
    route = "light"

这一步的关键是让分类规则可配置、可观测，而不是硬编码在大量业务分支中。

第二步：建立模型能力标签

每个模型都应打上能力标签，例如：

• 是否支持长上下文
• 是否支持结构化输出
• 是否支持工具调用
• 是否适合代码任务
• 是否适合终端任务
• 是否适合表格处理
• 平均延迟
• 价格档位
• 限流情况

这样路由时就不需要逐个模型写死，而是通过标签匹配任务需求。

示例：

model_profile:
  light:
    max_input_tokens: 16000
    strengths: ["qa", "summary", "extraction"]
    cost_level: low
    latency_level: low
  strong:
    max_input_tokens: 128000
    strengths: ["code", "terminal", "table", "complex_reasoning"]
    cost_level: high
    latency_level: medium

第三步：设计路由决策链

路由决策不建议只写一层 if-else。可以采用分层决策：

1. 默认路由：根据任务类型选择默认模型。
2. 复杂度升级：输入过长、任务复杂时升级。
3. 失败升级：默认模型超时或报错时升级。
4. 置信度升级：默认模型输出质量不足时升级。
5. 成本降级：预算不足或限流时降级到轻量模型。

示例：

request
  -> classify task
  -> select primary model
  -> call model
  -> check status and quality
  -> if fail or low confidence:
       call fallback model
  -> return result

第四步：配置超时与重试

超时设置直接影响用户体验和成本。常见建议：

• 连接超时应短，避免无效等待。
• 读取超时应根据模型类型和业务场景设置。
• 轻量模型超时阈值可短于高能力模型。
• 重试次数不宜过多，避免放大流量。
• 重试应采用退避策略，避免瞬时冲击。

配置示例：

timeout:
  connect_ms: 1000
  read_ms: 20000
retry:
  max_attempts: 2
  backoff_ms: 500
  retry_on:
    - timeout
    - rate_limited
    - temporary_error

注意：不应盲目重试所有错误。对于参数错误、内容违规、鉴权失败等错误，重试通常无效。

第五步：实现兜底切换

兜底切换是路由策略中的关键部分。常见兜底条件包括：

• 默认模型返回错误
• 默认模型超时
• 默认模型输出无法解析
• 默认模型结果置信度低
• 默认模型触发限流
• 默认模型超出上下文长度

兜底逻辑示例：

result = call(default_model)
if result.failed or result.confidence < threshold:
    result = call(fallback_model)

如果业务允许，还可以设置多级兜底：

default_model -> balance_model -> strong_model

但兜底层级越多，系统复杂度越高。初期建议只保留一个主兜底。

第六步：设置成本控制

模型调用成本通常与输入长度、输出长度和模型档位相关。成本控制应包括：

1. 限制输入长度
   对超长输入先做摘要、分段或检索式处理。

2. 限制输出长度
   根据业务需求设置最大输出 token 数，避免模型生成过长内容。

3. 缓存重复请求
   对高频相同问题，可以缓存结果并设置过期时间。

4. 按用户或业务线限流
   避免单个业务线消耗全部配额。

5. 设置日预算或小时预算
   当成本超过阈值时，自动降级或告警。

6. 定期复盘成本结构
   找出哪些场景使用了高能力模型，是否有优化空间。

第七步：灰度发布与回滚

新模型或新路由策略上线时，不建议全量切换。推荐灰度路径：

1. 内部测试
2. 小流量灰度
3. 单业务线灰度
4. 多业务线灰度
5. 全量发布

灰度期间需要重点观察：

• 成功率
• P95 延迟
• 平均成本
• 用户反馈
• 错误分布
• 兜底触发率
• 评测集得分

一旦发现效果下降或成本异常，应及时回滚。

六、配置说明：常见参数如何理解

在多模型路由中，配置项应尽量语义化，避免业务人员难以理解。

1. default_model

表示默认使用的模型类别。通常设为轻量档。

作用：

• 承接大多数普通请求
• 降低整体成本
• 降低平均延迟

风险：

• 如果默认模型能力不足，会导致兜底率升高，反而增加成本。

2. fallback_model

表示默认模型失败后的兜底模型。

作用：

• 提高成功率
• 避免单次失败影响用户体验

风险：

• 如果兜底条件过于宽松，会导致高成本模型被频繁调用。

3. max_input_tokens

表示允许的最大输入长度。

作用：

• 防止超长输入导致失败或费用过高
• 便于路由到长上下文模型

风险：

• 截断输入可能损失关键信息，应配合摘要或检索增强。

4. timeout_ms

表示单次请求超时时间。

作用：

• 避免请求无限等待
• 保护线程池和连接池

风险：

• 超时过短会导致正常请求被误杀
• 超时过长会拖慢整体系统

5. retry_policy

表示重试策略。

作用：

• 提升瞬时故障下的成功率

风险：

• 重试过多可能放大故障
• 对不可重试错误重试无效

6. confidence_threshold

表示输出置信度阈值。

作用：

• 判断是否需要升级到高能力模型

风险：

• 如果模型本身不返回稳定置信度，需要结合规则、校验器或二次判断。

7. budget_limit

表示成本上限。

作用：

• 防止异常流量导致成本失控

风险：

• 限制过严会影响正常业务
• 需要配合告警和人工确认

七、示例说明：通用路由伪代码

下面是一段通用伪代码，用于说明客户端或服务端路由的基本思路。实际实现时可根据编程语言与平台能力调整。

function handle_request(req):
    task = classify(req)
    if task.type == "code" or req.input_length > LONG_INPUT_THRESHOLD:
        primary = "strong_model"
    else:
        primary = "light_model"
    response = call_model(primary, req)
    if response.error == TIMEOUT:
        log("timeout", primary)
        response = call_model("strong_model", req)
    if response.error == RATE_LIMITED:
        log("rate_limited", primary)
        response = call_model("light_model", req)
    if response.valid == false:
        log("invalid_output", primary)
        response = call_model("strong_model", req)
    if response.confidence < CONFIDENCE_THRESHOLD:
        log("low_confidence", primary)
        response = call_model("strong_model", req)
    record_metrics(req, primary, response)
    return response

该示例的重点不是具体函数，而是展示路由决策应包含：

• 默认模型选择
• 超时兜底
• 限流降级
• 输出校验
• 置信度判断
• 日志记录

八、结果验证：如何判断路由方案是否有效

1. 功能验证

检查以下问题：

• 普通请求是否默认走轻量模型
• 复杂请求是否正确升级
• 失败后是否触发兜底
• 输出格式是否符合要求
• 日志中是否能看到模型切换过程

2. 性能验证

关注指标：

• 平均响应时间
• P95 响应时间
• P99 响应时间
• 超时率
• 重试率
• 兜底触发率

如果轻量模型默认后 P95 明显上升，需要检查是否误判请求复杂度或模型限流。

3. 成本验证

关注指标：

• 单次请求平均成本
• 高能力模型调用占比
• 长输入请求占比
• 缓存命中率
• 成本预算达成情况

如果高能力模型调用占比过高，需要检查路由规则是否过于保守。

4. 稳定性验证

关注指标：

• 错误率
• 超时率
• 限流率
• 熔断次数
• 连续失败次数
• 兜底成功率

如果兜底成功率很低，说明备用模型能力与主模型差距过大，或兜底触发条件不合理。

5. 效果验证

使用评测集对比：

• 新路由方案与单一模型方案
• 轻量模型与高能力模型
• 上线前后同一批样本

如果整体效果下降，即使成本降低，也不建议全量上线。

九、常见问题与排查思路

1. 轻量模型效果不稳定

可能原因：

• 任务复杂度被低估
• 输入信息不足
• 输出格式要求过高
• 模型不适合该任务类型

处理方式：

• 收紧默认模型适用范围
• 增加置信度校验
• 对关键场景强制使用高能力模型
• 增加输出后校验

2. 成本高于预期

可能原因：

• 高能力模型兜底率过高
• 输入长度过大
• 缓存命中率低
• 重试策略过激进

处理方式：

• 压缩输入
• 增加摘要或检索式输入
• 限制最大输出长度
• 调整兜底阈值
• 增加缓存

3. 长文本请求频繁失败

可能原因：

• 输入超过模型上下文限制
• 长文本导致延迟升高
• 长文本解析结果不稳定

处理方式：

• 分段处理
• 先做摘要再分析
• 使用检索增强方式提取关键片段
• 将长文本请求路由到长上下文模型

4. 路由规则频繁误判

可能原因：

• 分类特征不足
• 任务类型定义模糊
• 用户输入表达不清

处理方式：

• 增加任务标签
• 引入更细粒度的分类器
• 保留人工修正入口
• 根据日志持续优化规则

5. 平台容灾无法指定备选模型

可能原因：

• 平台容灾策略由平台侧决定
• 应用无法控制具体切换目标
• 容灾后模型能力或价格发生变化

处理方式：

• 在应用侧保留独立路由
• 配置多个模型入口
• 使用多账号、多区域或多服务通道
• 将平台容灾视为最后一道保障

6. 重试导致流量放大

可能原因：

• 重试次数过多
• 退避时间不足
• 对不可恢复错误也进行重试

处理方式：

• 区分可重试错误与不可重试错误
• 增加指数退避
• 设置全局重试上限
• 增加熔断机制

十、优化建议：让模型路由更稳定、更省钱、更易维护

1. 性能优化

• 使用连接池减少握手开销
• 对高频请求使用结果缓存
• 对可并行请求进行并行调用
• 对长文本先做预处理
• 对输出采用流式返回以降低感知延迟

2. 安全优化

• 密钥统一托管，避免硬编码
• 对输入输出进行内容审核
• 对敏感数据进行脱敏
• 按业务线分配访问权限
• 保留审计日志

3. 稳定性优化

• 设置熔断与隔离
• 为不同业务线分配独立配额
• 对高成本模型设置更严格限流
• 对关键链路保留人工兜底
• 定期进行故障演练

4. 成本优化

• 建立模型成本看板
• 按场景统计成本占比
• 定期清理低效高成本请求
• 对重复问题建立缓存
• 对长输入采用摘要或检索替代

5. 可维护性优化

• 模型名称使用别名，不直接绑定具体模型
• 路由规则配置化
• 模型能力标签化
• 配置版本化管理
• 每次模型切换都附带灰度与回滚方案

十一、总结：模型越多，越需要工程化选型

面对密集上线的新模型，开发者最重要的不是第一时间接入所有新模型，而是建立一套可控的选型机制。

本教程的核心结论可以概括为：

1. 轻量模型做默认：承担大多数高频、简单、低成本请求。
2. 高能力模型做兜底：处理复杂任务、失败请求和低置信度结果。
3. 路由靠客户端或服务端：业务侧应掌握请求分发逻辑。
4. 平台容灾只能辅助：不能假设平台会自动切换到指定模型。
5. 可观测先行：没有日志、指标和评测，就无法持续优化。
6. 灰度发布与回滚：新模型上线必须小步验证，避免全量风险。

通过分层模型池、统一调用层、明确兜底条件、成本预算和监控闭环，开发者可以在模型快速更新的环境中保持架构稳定，同时兼顾效果、成本和运维复杂度。