为什么"换更大的模型"常常不是答案：AI 系统的选型与降级链

上次一个朋友被线上故障逼到墙角，第一反应是"把 GPT-4 换成更大、更贵的模型"。结果故障没好，账单倒是翻了一倍。这个反应本身没错——大模型确实更强。但大多数真实的线上问题，并不是"模型不够聪明"，而是工程侧没把冗余、成本、延迟这几件事理顺。先把这个区分清楚，后面所有选型决策才不至于跑偏。

先看清问题出在哪一层

一次对话延迟高、答非所问、还是报错，对应的解法完全不同。延迟高，往往不是模型弱，而是上下文太长、KV Cache 没命上、或者请求没并发好；答非所问，可能是提示词写漏了约束、结构化输出没锁死格式；报错率飙升，那多半是流控超限或网络抖动。把"延迟高"归因到"模型不够大"，你只会花大价钱请一个更慢的演员来演同一出戏。换句话说，先定位到是模型能力层、推理优化层，还是工程层的问题，再动手。

能小就不要大

这是一个被反复验证、但也最常被忽略的原则。分类、抽取、简单问答、格式转换这类任务，一个小模型或蒸去过的小学生模型，在实际指标上常常打平甚至超过大模型，而成本能差一到两个数量级，延迟也低得多。真正需要大模型的场景很窄：真正的多步推理、复杂代码、开放性创作。别图省事全堆到旗舰模型上，那是把 90% 用不上的算力当成保费在交。

搭一条降级链，而不是押单一模型

生产系统里，单一模型就是你的单点故障。本地小模型挂了、云端 API 限流、或者某家服务整体抖动，只要你的链路只有一条，用户就看得见。常见的做法是分层：优先走本地或便宜的小模型处理大部分请求，命中不了或置信度低，再升级到更强的云端模型；同时接第二家云端模型作为备份。哪一层hung住就往下走，哪一层超预算就往上退。关键不在于某一层多完美，而在于整条链能在任何单点失效时继续给出"能用"的回答，哪怕质量降一档。

成本是设计出来的，不是算出来的

一个回答到底值多少钱，取决于它走了哪条链、消耗了多少 token、缓存命了多少。把这条账拆开看，你会发现三件事经常比"换模型"更省钱：复利用前缀缓存止血重复请求，用结构化输出减少无效重生成，对高频任务蒸馏一个小模型专门顶上。这些手段不碰模型本身，却能把整个系统的有效成本压下去一大截。等到哪天你发现账单又涨了，别再想"要不要换更大的"，先问"这条链还能不能缩"。

小结

"模型更大"是一个直觉，不是一个方案。真正的系统能力来自分层编排：先准确定位问题在哪一层，能小就小、该大才大，把降级链搭厚、把成本拆细。模型会一颗一颗地换、一版一版地迭代，但你搭的这套架构能一直用下去。下次再遇到线上问题，先别急着升配，先问一句：这到底要更大的脑子，还是要更好的接线？