大模型蒸馏真相：便宜模型才是生产级AI的真正地基

大多数人对AI系统的想象，是这样的：一台超级计算器，配一个最强的模型，处理所有任务。

现实恰恰相反。

我去扒了一下几家真正把AI系统跑在生产环境的团队——不是Demo，是每天处理百万级请求的那种——发现一个反直觉的共同点：他们都在用便宜模型做大量过滤工作，把最贵的模型留在最后一步。

这不是抠门。这是架构。

---

你为全用最强模型多付了多少钱？

先算一笔账。

一个典型的工作流：用户发来一个请求，模型需要判断意图、从知识库检索、生成结构化回答、最后输出。

如果全程用 o3 或 Claude Sonnet 4，每千 token 的成本是几分钱。听起来不贵，但乘以每天几十万次请求，每月的账单就能让你心悸。

更关键的是：这里面80%的请求，其实根本不需要最强模型。

用户问"今天天气怎么样"，不需要 o3。用户说"我要退款"，不需要推理模型过一遍。用户说"你好"，你让 GPT-4o mini 回答，成本降低十倍，效果没什么区别。

真正需要顶级推理能力的，是那20%的复杂问题——多步骤推理、模糊需求拆解、高风险决策。

但如果你让最强模型处理所有请求，你等于在为20%的需求，100%买单。

---

级联架构：让每个模型干最该干的活

生产级AI系统的核心架构，叫 Model Cascading——模型级联。

原理很简单：先用小模型过滤，轻重分拣，把复杂请求路由到强模型，把简单请求在廉价模型层解决。

三层结构：

第一层：分发路由器。 用 GPT-4o mini 或 Qwen3 这种级别的模型，0.1秒内判断用户意图，评估问题复杂度，决定这条请求应该进入哪条处理通道。成本极低，速度极快。

第二层：任务专用模型。 路由分发之后，不同类型的问题进入不同的处理通道。结构化查询走专用优化过的模型；长文本分析走长上下文模型；创意任务走专用生成模型。每个模型都在它最擅长的场景里工作，没有浪费。

第三层：推理模型做最终校验。 只有在任务专用模型输出不确定、或者涉及高风险决策时，才把请求交给 o3、o4 或者 Claude Sonnet 这种顶级推理模型。这一步成本最高，但触发频率最低——可能只占总请求量的5%。

整个系统的成本结构因此重构：80%的请求在第一层和第二层被处理，成本是顶级模型的1/10到1/50。只有20%真正需要大算力的请求，才会用到最贵的模型。

---

真实案例：GitHub Copilot 背后的路由逻辑

GitHub Copilot 是最早大规模采用级联架构的消费级AI产品之一。

据内部工程师在公开访谈里透露，Copilot 的代码补全系统并不是全程用最大模型跑。它的做法是：

1. 本地轻量模型做第一轮补全建议——延迟低于50毫秒，用户几乎无感知
2. 如果本地模型对补全结果置信度不够，再向云端更强模型发起请求
3. 极其复杂的代码理解任务（比如多文件上下文关联分析），才触发最高规格的模型

这个架构让 Copilot 的 P95 延迟保持在用户可接受范围内，同时控制了成本。

对比一下：如果 Copilot 全程用云端大模型跑，每次敲键盘都触发一次 API 调用，P50 延迟会直接击穿用户体验。便宜模型在这里不只是成本优化工具，它是保证用户体验的基础设施。

---

反直觉的结论：便宜模型反而更稳定

这里有个有意思的观察。

顶级推理模型的能力上限更高，但它的输出稳定性反而更差——因为模型越强，越倾向于在推理过程中"过度发挥"，给出过长、过复杂、过度解读的答案。

便宜模型恰恰相反：能力边界清晰，不知道的时候更倾向于说"不知道"或者给出一个简短但有用的回答，而不是长篇大论地胡编。

在需要快速闭环的工作流里，一个"知道自己边界在哪"的模型，往往比一个"能力很强但不知道边界在哪"的模型更可靠。

这就解释了为什么很多 Agent 系统里，第一层路由任务往往交给最弱的模型——不是因为它便宜，是因为它足够保守，不会引入额外的不可预测性。

---

上下文工程和级联架构是什么关系？

你可能已经在另一篇文章里读到过"上下文工程"的概念——设计让AI在正确时间得到正确计算资源的系统。

级联架构是上下文工程在模型选择维度上的实现。

上下文工程讲的是：给模型什么信息，在什么时机给。

级联架构讲的是：用哪个模型处理，在什么复杂度下切换。

两者结合，构成了生产级AI系统的核心：精准的上下文设计，加上精准的模型路由。

上下文工程解决的是"信息密度"问题。级联架构解决的是"计算资源分配"问题。

合在一起，才是完整的"AI算力分配哲学"。

---

你现在应该做什么？

如果你正在构建AI产品，第一件事不是选最强模型。

是先画出你的请求分布图。

哪类请求占80%？哪类请求占15%？哪类请求占5%？

把这三个数字拆出来，你的架构就已经完成了一半。

剩下的问题是：80%那部分的请求，能不能用便宜模型处理？如果能，全用顶级模型就是在烧钱。如果不能，瓶颈在哪——是模型能力不足，还是你的任务定义本身有问题？

大多数时候，答案是后者。

把一个模糊的"帮我处理这个"拆成清晰的子步骤，每一步用最适合的模型处理，这是工程问题，不是模型问题。

而工程问题，是有解的。

---

（全文约 1800 字）