模型选型

大部分请求用不上最贵的那档，但主模型一定会挂。分档、备用、格式归一、留痕，四件事都做在同一层薄封装里。

不是所有请求都值得用最贵的那个模型，而备用模型只有真的跑过才算数。这两件事必须在同一层里解决，否则分档省下的钱会被一次故障全部收回。

读完你能回答：

• 挑厂商时该比哪几件事，而不是比谁家模型分高？
• 怎么按任务分档，为什么多数时候不需要动态路由？
• 备用通道必须验证什么，切换时最容易在哪里崩？
• 换了模型，怎么知道效果没变差？

挑厂商不能只比谁家模型分高

榜单每个月都在翻，背下来没有意义；而模型能力是明面上的东西，谁都能测。真正决定你会不会出事的是另外几件。

一、数据怎么处理。输入会不会被用于训练、留存多久、能不能写进合同。这一条决定你能不能接客户数据。

二、区域可用性。用户在哪、合规要求在哪，服务就得在哪。数据跨区这件事，在有些行业里直接不成立。

三、模型名稳不稳定。你今天固定的那个名字，半年后是不是还指向同一个东西。

四、一个版本能不能消失。能不能钉住一个具体版本、它什么时候下线、下线前给多少通知。

后两条最容易被忽略，因为平时不出问题。但你的产品建立在「它会一直这么表现」这个假设上，而这个假设只有厂商能保证。

能力那一条当然也要比，但比法不是看榜单，而是拿自己的用例跑一遍。便宜与贵的排序、自家场景的强弱，都只能由这一次实测给出。

你怎么够到模型，决定了出事时谁负责

同一个模型，从哪条路接进来，差别不在功能，在责任归属。

• 直接调厂商。版本、额度、故障处理都由它一家负责，代价是每家单独开户结算。
• 通过云平台调同一个模型。多一层采购和合同流程，换来发票与合规资质，也换来一个中间环节。
• 从模型托管平台取权重自己跑。责任全在你，换到的是控制权。
• 经过一个聚合服务中转。省去逐家对接的麻烦，但请求内容经过你不完全掌握的第三方，链路随时可能被上游切断。

要问清的只有一句：你钉住的那个版本是不是你真拿到的那个，你的数据经过了谁。中间环节越多，出事时定位越慢。

不是所有请求都值得用最贵的那个

很多团队的做法是选一个最强的模型，全站都用它。这种做法最省事，代价是又贵又脆：账单贵，是因为大量请求本来够不上那个档次；系统脆，是因为那一个模型出问题，全线就跟着停。

先接受一个前提：你收到的请求本来就不是同一类。「把这张发票的金额和税号抽成字段」和「依据三年的销售记录推演明年该收缩哪条产品线」，难度根本不在一个量级上，现实中却经常交给同一个模型处理。

分档只需要守住一条：小模型够用就别上大的。这条纪律在厂商自己的工程指南里也是同一个口径：能用简单方案解决的，不要往上加复杂度。anthropic-agents

• 轻档：归到这里的活是分类、打标、字段抽取、格式转换。这类任务可能的答案很少、对错一目了然，小模型完全够，而且响应更快、价格更低。
• 中档：问答、摘要、内容生成、日常改写都归这一档。它是主力，大部分场景靠它覆盖。
• 重档：多步推演、复杂代码、方案权衡才用得上。需要推理模型，但要控制它在总量里的比例。

怎么判断某个请求该走哪一档？顺序是先看能不能过线，再看谁做得更好。先让轻档试一遍，过线就到此为止——自己攒的那一小撮真实用例 在这里起的作用就是那条及格线。

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

分档靠功能入口，不靠猜复杂度

多数场景下「智能路由」是多余的。按功能入口做静态分配就能解决问题：发票字段抽取这个功能固定走轻档，客服回复润色固定走中档。

真正需要动态判断的只有一种情况：同一个入口进来的请求，复杂度分布得很开。何况动态判断本身往往也要调用一次模型，它有开销，也有判错的可能——省下来的钱得先能覆盖它自己。

静态分配还带来一个额外的好处：同一条链路的输入结构固定下来，前缀缓存 就更容易命中。而动态路由会让同一个入口的请求落到不同模型上，命中率随之变差。可见分档与缓存之间存在牵制，两者要一起考虑。

那一层薄封装值在哪里

上面每一件事——分档、切换、格式归一、打点——都发生在同一个位置：你自己代码里那一层薄封装。

它存在的理由不是架构美观，而是业务代码不应该直接绑在某一家厂商的接口上。绑上去之后，换模型的成本不是改一个地方，而是翻遍整个代码库。

这一层至少负责三件事：

• 统一入口。业务代码只说「做这个任务」，不说「用哪家」。
• 格式归一。不管哪个模型返回什么，出到业务代码那里的都是同一个结构。备用模型的格式差异必须在这里被吸收掉，不能漏到上层。
• 留痕。每次调用用了哪个模型、花了多少、有没有降级，都在这里记录。

顺带说一个现象：现在多数厂商的请求格式都向同一个事实标准靠拢，这让「换一家试试」变得很容易。但容易换不等于可以随便换——格式相似掩盖了行为差异，同一段提示词在不同模型上的表现可以差很远，这一点只能靠实测发现。所以封装层真正值钱的地方，是它让实测和切换都变成低成本的动作。

备用通道没跑过就等于没有

模型服务会限流、会超时、会报错、会某天下线一个版本。这些都属于日常，而不是意外。

降级做起来比预想的更容易出岔子，三个最容易踩的地方：

备用通道从未真实运行过。配置里填了它，却没有人在你的提示词下验证过它到底表现如何。等到真出事切过去，才发现它返回的格式都和主模型不一样，解析逻辑当场就对不上了。没跑过的备用不能算备用，比较稳妥的做法是让它长期分担一部分真实流量。

两边的输出格式不兼容。这一条最常见。你的解析逻辑是照着主模型的输出写的，一换就变样。格式约束 在主模型身上管用，不代表备用模型也管用。

降级发生了却没人知道。切换悄无声息地完成、没有留下任何记录，接着有人来反馈「今天回答不太对」，排查半天找不出原因。每一次降级都必须留痕，降级率要能在监控上看得到。

还有一条产品决策必须提前定下来：降级之后要不要告知用户？如果降级明显损害了质量，含糊地照常输出，往往比坦白说明更糟。

效果有没有变差，只能靠一组固定的题

调档位也好，换模型也好，启用备用也好，每次动作之后都得回到同一个疑问上：效果有没有变差？这件事凭感觉判断不了。

方法很朴素：准备一组固定的用例。素材取自真实请求，先攒三十条左右即可，既要覆盖常见情况，也要留几条特别刁钻的边界。每次打算动模型，先让它跑一遍，然后和上一轮结果摆在一起逐条对照。评估这件事怎么做得更系统，官方有一整套工具和做法可以直接借。openai-evals

三条实践提醒：

换了模型，提示词通常也要跟着调。各家模型对同一段提示词的响应方式差别很大。第一轮结果不理想时，先针对新模型改一版提示词再评价——直接判死刑往往冤枉了它。

平均值会掩盖问题。平均分持平，底下可能是「多数情况变好、少数情况崩掉」。真正要盯的是最差的那几条，用户投诉的正是它们。

先让一部分流量走过去。小范围放几天再全量，比在测试环境里反复跑一百遍更容易暴露真实问题。上线不是开关 讲的是同一套节奏。

这组用例会跟着产品一起变，所以它本身也是要维护的资产——评估集本身要养。

这一条推不出什么

推不出「所以选型是一次决定」。模型半年换一代，价格也在动，选型是每隔几个月要重做一次的事。

也推不出「所以分档越细越好」。每多一档就多一条链路要评测、要监控、要准备备用。档位数量应该由任务差异决定，不由成本焦虑决定。

真正的判断标准只有一条：同一批请求，整体表现不变的前提下，账单更低。达不到这一条，任何分档都只是给自己增加维护面。而这件事能做成的前提是成本本身可归因——成本要能归因到每一步 讲的是怎么让它可归因。

到这里，怎么把它用得又稳又省，能讲的方法都讲了。还剩一类它给不了的东西：你们自己的业务、文档和内部概念，不在它语料里。怎么补上这块，从一次请求能装下多少说起。