如何根据场景、任务、成本、时延和效果动态选择模型？

核心回答

动态模型选择可以分两步：先筛出能够且允许处理本次请求的候选，再在满足业务效果要求的候选中权衡成本、时延与当前可用性。任务类型、输入模态、上下文长度、工具调用需求和数据边界决定候选范围；业务评测、剩余时间、预算、配额和服务状态决定本次选择。

第一版通常用配置化规则就能落地：为不同场景维护候选集合和默认策略，每次请求结合输入特征与实时状态做选择。任务分类复杂、请求分布较稳定且已有足够评测数据时，再引入轻量分类器或学习型路由。低成本模型先试、校验失败再升级也是一种方案，但它会增加调用与等待，只有存在可靠校验且允许额外延迟时才适合。

路由效果最终看整个任务的成功率、端到端时延和总成本，而不是只看某次模型调用便宜了多少。模型更贵、参数更多或某个公开榜单更高，都不能代替它在当前任务上的效果依据。

先把“选模型”和“选服务实例”分开

业务路由解决“这次任务适合哪个模型或能力组合”。例如，视频场景要先判断输入是原生视频、抽帧图片还是语音转写，任务是识别单帧对象、理解连续动作，还是结合多源信息给出结论。支持图片不等于能直接处理任意视频输入，抽帧也可能丢掉任务需要的时序信息。

模型选定后，服务路由再在其可用部署、地域或供应商之间选择后端，处理排队、延迟、配额和故障。两层可以放在同一个组件里，但决策依据不同：按权重分流或选低延迟实例，不会自动证明该模型适合业务内容。

例如，客服分类与技术分析可以有不同候选集合；同一个候选模型也可以有多个服务端点。先确定当前任务的能力要求，再选择可用端点，避免把负载均衡当作语义模型选择。

建立可更新的模型能力与任务画像

模型注册信息至少包括实际模型标识和版本、输入输出模态、上下文及输出限制、工具与结构化输出能力、服务地域、价格和可用端点。服务状态另记录近期延迟、错误、配额、排队或限流情况。

请求侧保留场景、输入规模、所需能力、数据范围、任务截止时间和预算。复杂度可以参考问题类别、需要跨多少份证据、是否有多步计算或多轮工具调用等特征，不能只按问题字数判断：一句话也可能需要复杂分析，长输入也可能只是格式转换。

业务效果则来自同类任务的评测。对视频系统，可以按光照、遮挡、事件类型和时序要求分组；对代码助手，可以按补全、局部修复、跨文件修改等分组。任务画像与模型质量都需要随版本和数据分布更新，而不是一次填入后长期不变。

一次路由怎样执行

先执行硬约束

排除不满足数据与授权范围、输入模态、上下文、必要工具能力或当前服务可用条件的候选。预留输出空间时也要考虑系统提示词、工具定义、历史消息和检索片段，不能只数用户问题。

这些条件不能被综合打分抵消。比如某模型价格最低，但不能处理任务输入，或者不在允许的数据处理范围内，就不应进入最终选择。

再在合格候选中比较

按业务目标选择：交互场景重点关注首 Token 和完整响应时延；异步报告可以接受较长等待，但仍有任务截止时间；高错误代价场景先满足质量与业务约束，再比较成本。

可以将目标表述为“在达到任务质量要求并满足时延预算的候选中，选择预计总成本较低者”。质量和延迟是估计值，需要用评测及线上结果校准。若使用加权打分，要先统一各指标的量纲与方向，并根据业务调整权重；不存在一组对所有场景通用的系数。

成本也不能只比较每百万 Token 的标价：输入输出规模、缓存计费、思考模式、路由分类、失败重试和结果校验都会影响实际费用。较慢的低价模型若频繁触发超时重试，完成同一任务未必更省。

固定本次调用的路由结果

执行前确定具体模型、端点、参数和策略版本，并记录选择原因。动态选择发生在明确的决策点，不是在一段流式回答中途随意换模型；否则输出、工具状态和费用容易混淆。

多轮 Agent 可以在步骤边界重新评估，例如证据已收集齐后换成适合汇总的候选。但要保留必要上下文与工具执行结果，并确认新模型的消息格式、工具调用和上下文限制兼容。角色不同不必然意味着要用不同模型。

规则、分类与级联怎么取舍

规则路由适合场景已知、约束清楚的系统。规则可以按场景和能力选候选，再根据健康状态、预算和剩余时间调整；这种实现已经可以是动态路由，不必先训练专门的模型。

分类或语义路由适合类别有明显差别、能够稳定分类的请求。分类结果决定候选集合，但不能越过硬约束。分类不确定时，可以采用满足质量要求的保守路径、澄清输入或回到默认策略；分类器给出的分数也需要校准，不能直接等同任务成功概率。

级联路由先尝试成本较低的候选，再根据独立校验决定是否升级。触发条件可以是结构解析失败、缺少必要证据、代码测试不通过等。模型自己说“我有信心”不足以替代这些信号。初次结果与升级结果都要计入总成本，额外判断与重试都占用时延预算。

如果缺少可靠校验，低质量输出可能被直接接受，级联反而掩盖错误。对严格实时的任务，也可能直接选择更合适的模型更快，而不是串行试多遍。

超时、失败和误路由怎样兜底

服务不可用、限流与网络故障可以触发预算内的等待、短重试或切换合格备用端点；参数错误应先修正请求，上下文超限应调整输入或选择兼容候选。业务质量不足与服务故障是不同问题，需要分别记录。

所有候选都不满足条件时，可以排队、明确失败或进入业务已有的人工处理路径，不能为了返回结果而跳过能力和数据约束。安全拒答也不应被当作普通故障，反复换模型寻找能够绕过限制的输出。

带工具调用的 Agent 还要处理重放：已经完成的数据库写入、发信或支付等动作不能因换模型而再次执行；保存执行状态和幂等标识，再决定恢复位置。已经向用户发送的流式文本也不能直接拼接另一模型的新答案，应按产品约定重启或结束本次响应。

如何证明路由策略值得使用

先固定一套覆盖真实场景、长短输入、边界和故障的任务集。对同批任务比较固定基线与路由策略，成功标准一致，允许各模型使用其正确的模板和参数，并记录完整任务开销。

重点看：

• 总体及各任务分组的成功率，是否某类请求被误分后明显退化。
• 首 Token、完整任务耗时和尾部时延，以及超时、重试和升级比例。
• 每个完成任务或成功任务的总成本，包括路由、所有模型尝试、工具与校验。
• 新模型或新策略在小流量下是否保持效果，以及能否回滚到已验证的策略。

线上每次保留请求关联、候选过滤原因、选中模型与端点、路由策略版本、实际用量、校验和重试结果。只看到被选模型的成功率，还不足以判断其他候选会怎样；可以用离线回放和受控对照补充比较，避免把不同难度的请求直接混在一起归因。

常见追问

每次先调用一个强模型，让它决定用哪个模型，可以吗？

可以作为方案之一，但路由本身的延迟与费用也要计算。若简单规则或轻量分类器已能区分任务，额外强模型调用可能抵消收益；敏感输入也要遵守路由服务的数据范围。

动态路由是不是一定要用在线学习？

不需要。请求特征、配额和服务健康参与配置规则，已经能动态选择。学习型策略需要可用的质量反馈和评测，线上探索还要限制在允许试验的任务范围内。

模型低价且很快，就应该增加它的流量吗？

先看它在对应任务上的成功率和约束满足情况。流量变化也会改变排队与限流状态；增加权重后要继续观察任务效果与时延，不能只依据空闲时的一次调用。

对应教程

参考资料