AI API 多模型路由上线后怎么做健康检查？
AI API 接入多模型路由后，应按延迟、错误率、模型命中、回退链路、成本标签和业务样本持续做健康检查。
适用场景：备用模型有了，但不知道是否真的可用
很多团队完成 AI API 接入后，会很快加上多模型路由：主模型负责日常问答，备用模型处理超时，低成本模型跑摘要，高质量模型处理代码或合同。这套设计听起来完整，但上线后最容易忽略健康检查。等到用户反馈“有时很慢、有时风格变了、有时失败重试很久”，才发现路由规则、模型命中和回退链路没有被持续记录。
这篇适合开发者 AI 调用、AI 自动化办公、客服摘要、知识库问答和 Codex 接入场景。永沃云枢在 https://ai.jn83.com 的建议是：多模型路由不是配完就结束，而是要像普通后端服务一样观察延迟、错误率、成本和业务样本。规范说法是 AI 模型接口接入与调用管理，新手搜索的“GPT 中转”只是其中一类入口词，不适合作为系统设计目标。
操作步骤：用固定样本检查主路由和回退路由
第一步，列出所有路由规则。至少包括业务场景、默认模型、备用模型、超时阈值、重试次数、最大输出长度、成本标签和负责人。规则不要只写在代码里，最好在运维文档或配置说明中同步一份，方便 Codex 或同事排查。
第二步，准备固定健康样本。文本摘要、JSON 抽取、代码解释、知识库问答和长文档处理各选一到两个样本，输入保持不变。每天或每次发布后跑一次，记录命中模型、首 token 时间、总耗时、状态码、输出长度和人工评分。这样能发现模型质量回退，而不是只看接口是否 200。
第三步，主动验证失败路径。把主模型临时设为不可用的测试 profile，或在本地模拟超时，确认请求是否进入备用模型，用户是否看到合理提示，日志里是否能看出回退原因。注意这类验证应在测试环境或灰度流量里做，不要对正式用户制造故障。
第四步，核对成本和标签。多模型路由常见问题不是一次失败，而是某类任务悄悄走到高成本模型。日志里要保留 user_id 或业务标签、request_id、模型名、输入输出长度、重试次数和缓存命中情况。CCSwitch 配置中如果有不同 profile，也要能区分测试、正式和临时排错。
验收标准：每条路由都有可解释结果
健康检查通过的标准不应只是接口返回 200，而是每条路由都能解释“为什么选这个模型、有没有触发重试、最终输出是否符合业务契约”。例如摘要任务要看长度和事实保留，JSON 抽取要看字段完整度，知识库问答要看引用来源，Codex 接入任务要看是否保留文件路径和验证命令。
建议把检查结果分成绿色、黄色和红色。绿色代表主模型正常且样本合格；黄色代表触发备用模型但用户体验可接受；红色代表输出格式失败、成本超过阈值或用户需要人工介入。这样产品、开发和运营讨论时不会只围绕“模型好不好”争论，而是围绕明确证据做取舍。
常见问题/避坑：只看成功率会漏掉体验问题
接口成功率很高，不代表用户体验稳定。首 token 变慢、输出格式变散、JSON 字段缺失、引用来源缺失、风格突然改变，都可能来自路由变化。另一个坑是备用模型没有同等提示词约束，主模型能输出合法 JSON，备用模型却输出自然语言解释，业务系统照样解析失败。
还要避免无限重试。429、超时、上游 500 和本地参数错误要分开处理。参数错误不应换模型重试，限流可以进入队列，超时可以降级，业务关键任务则需要人工复核。模型调用管理的目标是可控，不是把所有失败都塞进重试循环。
检查清单：健康检查至少覆盖这些项
- 主模型和备用模型是否都有固定样本。
- 日志是否记录模型名、路由原因和 request_id。
- 首 token、总耗时和错误率是否分开统计。
- 备用模型是否满足同一输出契约。
- 高成本模型是否有预算阈值。
- 限流、超时、参数错误是否有不同处理策略。
- 用户提示是否说明“稍后重试”还是“已降级处理”。
FAQ：什么时候应该切回单模型？
如果团队还没有日志字段、固定样本和回退验收，多模型会增加排错难度。可以先用单模型跑通核心业务，再增加一个备用模型，并只在明确错误类型下触发。等健康检查稳定后，再把路由扩展到更多 AI 自动化办公任务。复杂系统需要逐步放量，不能靠一次配置解决所有问题。