选型决策框架是什么
模型选型不是比榜单分数，而是四层逐级过滤：先看能力（推理、多模态、上下文长度、工具调用），再看合规（数据能否出域、供应商资质与合同），再看成本与延迟预算，最后看工程性（协议兼容、限流配额、SDK 与运维支持）。每层筛完剩下的 2-3 个候选，用 20-50 条真实业务样本固定参数盲测定案。产出物不是「选中的模型」，而是一套可替换的配置：主模型、备用模型、路由规则与评测集。
基本信息
| 过滤顺序 | 能力 → 合规 → 成本延迟 → 工程性 |
|---|---|
| 产出物 | 主模型、备用模型、路由规则、评测集 |
| 评测方式 | 20-50 条真实业务样本，固定参数盲测 |
| 降级策略 | 供应商级容灾，主模型不可用时自动切换 |
| 复测周期 | 建议每季度一次，模型换代后立即复测 |
典型使用场景
- 新项目立项：在写业务代码之前先锁定模型与降级方案
- 成本压降：把简单请求路由到小模型，复杂请求才走旗舰模型
- 合规审查：数据不能出域时切换为私有化部署模型
- 供应商容灾：主模型限流或故障时自动切换到备用通道
- 模型换代：用固定评测集判断新版本是否值得替换
网关路由配置示例
网关路由配置示例
# 按业务复杂度与合规要求分流，模型标识全部走配置
rules:
default: small-model # 常规问答与改写，成本优先
complex_reasoning: reasoning-model # 多步推理与规划
long_document: long-context-model # 超长输入场景
sensitive_data: self-hosted-model # 数据不出域，走内网部署
fallback: backup-vendor-model # 主通道故障时的降级目标
log: usage_and_latency # 记录用量与延迟用于复测四层过滤怎么落地
| 层次 | 要回答的问题 | 跳过它的后果 |
|---|---|---|
| 能力 | 需要多模态、超长上下文还是工具调用 | 上线后靠分块与补丁硬凑，效果上限低 |
| 合规 | 数据能否出域，供应商资质与合同是否齐备 | 业务上线后被叫停，返工代价最大 |
| 成本延迟 | 每千次调用单价与 P95 延迟是否在预算内 | 用量起来后预算失控 |
| 工程性 | 协议是否兼容、限流是否够、SDK 能否维护 | 切换模型的改动量被严重低估 |
评测集要用真实业务问法，包含边界与失败的样本。只用公开榜单或自造的顺畅样本，结论会明显偏乐观。
把模型标识写成配置项并保留降级目标，是应对型号下线的唯一低成本方案；硬编码在生产环境里迟早会变成一次紧急发布。