蒸馏有一个营销版故事和一个真实版故事。营销版的故事是：你用一个便宜的 7B 学生替掉昂贵的前沿模型，还能保留 95% 的效果。真实版的故事是：大多数尝试这么干的团队，会发现学生在评测集上还行，在生产环境里凑合，一旦漂移就完全无从调试。蒸馏是一个真的有用的工具——但"什么时候把它从工具箱里掏出来"这个决策，值得比通常花的更多的心思。

这篇文章讲的是决策框架，不是教程。如果你正在权衡要不要把 Claude 蒸馏到某个具体的工作负载上，下面就是你该看的信号、要盘算的经济账，以及那些能让你不至于把整个产品押在一个学生模型上的路由模式。

那个虚假的承诺（为什么"用 7B 替 Opus"多半是错的）

推销话术很诱人：你的 Claude 账单越涨越高，一个小型开源模型只需一小部分成本就能微调完，自己 GPU 上的推理一旦摊薄基本等于免费。换上去，继续发版。

实际发生的事更微妙一点。学生模型在你蒸馏所用的那份分布上表现不错，然后在长尾上悄悄失败。用户问了一个稍微超出范围的问题、或者用不熟悉的方式表达了一个常见需求，学生就自信地胡说八道，而 Claude 本来会去 hedge、追问、或者拒答。你几周都不会发现，因为你的评测集和训练数据是同一分布抽出来的。

第二个问题：你没测的那些维度上，能力会崩塌。你按"分类这条工单"来蒸馏，学生分类做得很好。但流水线里的某处，你其实还在依赖 Claude 给这条工单写一句连贯的摘要放进审计日志。学生生成的摘要能过随手一瞥的检查，通不过一次认真阅读。没人注意到，直到审计员注意到。

第三个问题：如果你算得诚实，那个"便宜的 7B 学生"经常比 API 还贵。GPU 租金、运维投入、搭建维护训练流水线的工程师月数、每次数据分布漂移都要来一次的重训周期——这些成本都是真的，而且是前置的。不管蒸馏模型最后有没有上生产，你都得付。

以上都不代表蒸馏是错的。它代表"用 7B 替 Opus"这个提问方式是错的。正确的提问方式是：我的工作负载里，哪一小片有那种让蒸馏真正划算的属性？

5 个信号：你的任务适合蒸馏

那些蒸馏能挣回自己成本的任务，共享一组属性。当你看到大多数都成立时，账才真的算得过来。

1. 任务是窄的。 不是"客服"，而是"给一条工单，把它归到 12 个类别中的一个，并抽出受影响的产品 SKU"。窄任务的输入分布有界、输出空间有界、需要广博世界知识的边界情形少。Claude 的通用性用在这上面是浪费——这恰恰是学生能追上来的原因。

2. 行为是稳定的。 这个任务过去半年基本没变，也不打算变。要是你产品经理下个季度就要加三个新类目，那每次改动都是一次重训周期。蒸馏奖励稳定，惩罚变动。

3. 调用量是大的。 你一个月是千万次调用级别，不是几千次。蒸馏有固定成本——老师推理造数据集、训练、评测、部署——和一份按次省下来的钱。大调用量摊薄固定成本，小调用量摊不平。

4. 推理理由像程序。 在这个任务上，Claude 做的推理看起来像在照清单走或者按规则套，而不是在合成新的洞察。程序型的推理理由能被压缩进小模型；开放式推理不行。如果你能想象把这套逻辑写成一棵很长的决策树，那大概率能蒸馏。

5. 结果是可验证的。 你能低成本、自动地判断学生的输出对不对。结构化输出、抽取型任务、能编译并通过测试的代码、有 ground truth 的分类——这些都是可验证的。"这个模型的回复写得好不好"就不是——除非你另有一个可信的验证器。

蒸馏的强论证是：五条中命中四五条。命中两三条，你大概率还是留在 Claude、优化点别的更划算——提示词长度、缓存、路由。

5 个反向信号：其实不适合

反过来同样重要。下面这类任务在纸面上让蒸馏看起来很诱人，到生产里让你失望。

1. 任务宽或者开放。 "回答任何客户问题"、"写一封贴心的回复"——这些任务在拉动通用能力。学生只学过某个具体分布上的样本，一旦现实漂离那个分布就会翻车，而现实总在漂。

2. 推理需要世界知识或者判断力。 任何地方 Claude 是在调用广博知识、在权衡取舍、在拿捏分寸的，都是差的蒸馏对象。老师在这类任务上的输出，不是输入的函数，而是"输入 + 老师全部训练"的函数。你没法把这一整坨压进一个 7B。

3. 分布在漂移。 你的输入每个月都在变——新产品、新用户行为、新术语。蒸馏模型在训练那一刻就被冻住了。如果前沿模型能自然适应一个变动中的世界而学生不行，你就会为了"跟得上"烧掉一大把工程师月。

4. 一次隐性失败的代价很高。 蒸馏模型和老师的失败方式不一样。它们倾向于"自信地失败"，输出听起来合理但错的方式人工复核未必抓得到。一次错误答案很贵的场景——法律审阅、医疗分诊、财务建议——蒸馏的尾部风险通常不值得那点运行时省下的钱。

5. 你造不出验证器。 没有自动方式检验学生输出，你就跑不了持续评测、搭不了"低置信度就 fallback 到 Claude"的路由、也测不出回归。没有验证器的蒸馏就是一次盲注。

注意这里的不对称：需要多个正向信号才配得上做蒸馏，任何一个强负向信号往往就足以毙掉它。这个比例是对的。蒸馏是一种优化，优化只在证据清晰时才该动手。

经济账：老师端成本 vs. 运行时省下的钱

真正的经济问题不是"我学生的推理是不是比 API 便宜"，而是"在我在意的时间视窗内，蒸馏的总成本能不能打过继续用 API 的总成本"。这是一道盈亏平衡题，先用符号算一遍再上数字。

设：

一直用老师，总成本大致是 N · c_t。

蒸馏 + 路由，总成本大致是 D + T + M + N · ((1 - q) · c_s + q · c_r)。

蒸馏胜出的条件是：

N · c_t > D + T + M + N · ((1 - q) · c_s + q · c_r)

改写一下：每次调用的省钱幅度 (c_t - (1 - q) · c_s - q · c_r) 必须足够大，乘以 N 次调用后能把 D + T + M 赚回来。

有几件事一眼就能看出来。规模在实践中几乎是二次决定性的，因为 N 越大，一边摊薄固定成本，一边把节省额度放大到肉眼可见。质量差距的影响比人们预想的大得多——如果 q 是 20%、c_r 又接近 c_t，你省下来的钱多半在回落路径上就吃掉了。维护成本不是可选项；你不预算 M，你就会在事故里付它。

不要在这个公式里塞假数字。它的意义就是逼你把每一项诚实估一遍。多数团队走一遍下来会发现：要么 N 太小、要么 q 太高、要么 M 被无视了，盈亏平衡时间比这个功能的生命周期还长。

当公式算得通时，通常是压倒性通——省 5 倍、10 倍，不是省 20%。如果你估出来的收益是 15%，你多半漏算了什么，真实答案是负的。

3 种路由模式

即便蒸馏值得做，单独把学生模型部署上去也很少是对的架构。真正有意思的问题，是怎么在学生、老师、和其他组件之间做路由。三种模式覆盖了大多数生产场景。

级联（Cascade）

每次调用先走学生。如果学生的输出过了某个置信阈值——logit 分数、验证器检查、分布外信号——就直接返回；过不了，就 fallback 到老师。

这是主力模式。它在高置信的大头流量上抓住了大部分运行时省下的钱，同时在长尾上保留了老师的质量。工程复杂度中等：你需要一个真的置信信号（不是模型自报的那个自信度，那玩意通常没用），而且要把 fallback 率作为漂移的先行指标监控起来。

Cascade 失败的场景是置信信号不好。要是学生"自信地错"，级联就会把这些错放行。要把钱花在信号上，别光花在学生上。

蒸馏 + 校验（Distill + verify）

学生给出输出，一个独立的验证器——有时是老师，有时是一小段规则引擎，有时是第二个蒸馏出来的小模型——去检查它。校验不过，就重试老师或者升级处理。

这种模式在验证器远比老师便宜、又远比学生自报置信度可靠时最出彩。抽取型任务（有没有拉对字段？）、结构化输出（这段 JSON 校验通过吗？）、代码（能编译、能跑通测试吗？）都是天然场景，因为验证近乎免费又近乎完美。

陷阱是：所谓"验证器"如果本质上只是另一个和学生有同样盲区的模型，那你只加了延迟，没加安全。

集成（Ensemble）

学生和老师并行跑，结果做合并或者仲裁。有时用学生做便宜的首答、老师做权威答，第二路流回来覆盖。有时做加权投票。

集成是成本敏感场景里最少见的模式，因为它通常比只用老师还贵。它挣回自己价值的地方是延迟敏感的链路：学生的答案立刻流给用户，老师的答案在后台完成，如果不同意就覆盖。这是 UX 上的赢，不是成本上的赢。

多数团队应该先够到级联，等有了合适验证器再叠上校验，只有在遇到"其他办法达不到"的延迟需求时才去搭集成。

真正该问的问题

真正该问的不是"我们要不要蒸馏 Claude"。是"我们的工作负载里，哪一小片有那种属性——窄、稳、大量、程序化、可验证——让蒸馏真的对得起持续的成本"。对大多数团队，答案是"一两片，不是整个产品"。这一两片值得认真去做。剩下的都留在老师那边。

如果你确信自己有一个好候选，接下来的问题就变得非常具体：怎么造一份真的能把 Claude 所懂教给学生的推理理由数据集？怎么让蒸馏聚焦在解释上、而不是模仿上？那些是另外的文章。