选型与降级 | 大模型 | 做产品

选型与降级

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

你会遇到的现象

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

「判断这条评论是不是负面」和「根据这份需求文档写一个模块」，难度差着量级，却常常用同一个模型在跑。前者用最便宜的小模型就绰绰有余，后者才需要推理模型。

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

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

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

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

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

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

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

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

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

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

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

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

模型服务会挂、会限流、会下线——这是常态，不是意外

坑一备用从没真跑过配置里写了一个备用，但没人验证过它的表现对策：定期真实跑一遍，最好放一部分线上流量过去

坑二输出格式不兼容切过去之后格式变了，解析代码直接崩对策：在封装层做格式归一，出到业务代码永远同一结构

坑三不知道自己降级了有人说「今天回答怪怪的」，查半天查不出原因对策：每次降级都打点，监控上要看得到降级率

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

这三个坑有同一个前提条件：模型调用被封装在你自己的一层里。分档路由、主备切换、格式归一化、打点监控全都发生在那一层——业务代码里散落着各家 SDK 的话，这一节讲的每件事都会变得极其昂贵。

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

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

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

三条实践提醒。

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

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

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

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

调用一个模型需要什么分档和降级都建在那一层封装上，先把它做出来。

主流模型厂商的差异六个选型维度，以及为什么要选两个而不是一个。

推理模型与普通模型重档留给它，但要控制占比。