选型与降级

按任务分档配模型，主模型挂了怎么自动退到备用。

很多团队的做法是：选一个最强的模型，全站都用它。这样最省事，也最贵、最脆——贵在大部分请求根本用不上那个档次，脆在它一挂你就全挂。

你会遇到的现象：

• 账单里绝大部分钱，花在了「判断这条消息是不是垃圾信息」这类简单活上
• 模型服务抖一下，整个产品的 AI 功能全线不可用
• 换了个便宜模型，上线后才发现某类请求的效果掉得厉害

按任务分档

第一件事是承认：你的请求不是同一种。

「判断这条评论是不是负面」和「根据这份需求文档写一个模块」，难度差着量级，却常常用同一个模型在跑。前者用最便宜的小模型就绰绰有余，后者才需要推理模型。分档的原则是「能用小的就别用大的」——Anthropic 的 agent 指南也提醒：从最简单的方案开始，证明不够了再加码。anthropic-agents

分档的做法是给每类任务配一个档位——

**轻档：**分类、打标、抽字段、格式转换、简单改写。这类任务答案空间小、对错分明，小模型足够，而且更快更便宜。

**中档：**问答、摘要、内容生成、常规代码补全。主力模型，覆盖大部分场景。

**重档：**多步推演、复杂代码、方案权衡。用推理模型，但要限制它的占比。

怎么判断一个请求该走哪档？多数时候不需要智能路由——按功能入口静态分配就够了。「垃圾评论检测」固定走轻档，「写周报」固定走中档。只有当同一个入口的请求复杂度差别很大时，才值得做动态判断。

收益很可观：把量最大的几个简单功能降到轻档，账单能降一大截，用户完全感觉不到。

降级不只是换一个

模型服务会挂。会限流、会超时、会返回错误、会某天下线一个版本。这是常态，不是意外，产品必须有准备。

但降级这件事，做得比想象中容易出错。有三个坑。

**坑一：备用模型从来没真跑过。**配置里写了一个备用，但没人验证过它在你的提示词下表现如何。等真出事切过去，才发现它的输出格式对不上，程序直接崩了。备用通道必须定期真实跑一遍，最好放一部分线上流量过去。

坑二：输出格式不兼容。这是最常见的。你的程序按主模型的输出格式在解析，切到备用之后格式变了——尤其是要求 JSON 输出的场景，各家的稳定程度差别很大。所以那一层封装里必须做格式归一化：不管哪个模型返回什么，出到业务代码那里都是同一个结构。

**坑三：不知道自己降级了。**降级悄悄发生，没有任何记录，然后有人反馈「今天回答质量怪怪的」，查了半天查不出原因。每次降级都要打点，并且要能在监控上看到降级率。

还有一条产品决策要提前定：**降级之后要不要告诉用户？**如果降级会明显影响质量，含糊地照常输出可能比诚实说明更糟。多数情况下，一句「当前使用备用服务，结果可能不如平时」比让用户自己怀疑要好。

怎么验证没变差

换模型、调档位、切备用——每一次都要回答同一个问题：**效果掉了没有？**靠感觉是答不了的。

方法很朴素：留一组固定的测试用例。

20 到 50 条真实请求，覆盖常见情况和几个刁钻的边界。每次要动模型，就用这组跑一遍，和上次的结果并排比。这组用例是你所有模型决策的尺子——选型那一节说的也是同一件事，它是整个环节里回报最高的一次性投入。openai-evals

三条实践提醒。

**一、换模型往往要重调提示词。**不同厂商对同一段提示词的反应差别很大。一轮结果不好，先给它一次针对性调整的机会，再下结论——直接判死刑经常是冤枉的。

**二、别只看平均值。**平均分持平，可能是「大部分变好了，少数崩得很惨」。要看最差的那几条，那才是用户会投诉的。

**三、灰度切换。**先放一小部分流量到新模型，观察几天再全量。这比在测试环境里跑一百遍更能发现真问题。

最后回到一条贯穿的原则：**这些事之所以做得成，前提是模型调用被封装在你自己的一层里。**分档路由、主备切换、格式归一化、打点监控，全都发生在那一层。如果业务代码里散落着各家的 SDK，这一节讲的每一件事都会变得极其昂贵。