小模型在分类场景的工程胜利：阈值路由降本99%

"应该用哪个模型"这个问题本身就是个错误。对于分类形态的工作，答案是两个模型加一个阈值。

模式：大的打标签，小的上线

当一条流水线需要大规模做分类时——无论是类目、垃圾邮件、意图、语言——我们不会对每个样本都调用前沿模型。我们按数据集调用一次：让大模型用精心设计的 rubric 给 30,000 条历史样本打标签，人工抽检一部分样本，然后将这批标签蒸馏到一个跑在我们自己的机器上的小模型。前沿模型的判断被编译成一个可以在 15 毫秒内完成、只花电费的服务。

路由处理困难的长尾

const p = small.classify(x);            // ~15 ms, on-box, effectively free
if (p.confidence >= 0.92) return p.label;
return frontier.classify(x);            // ~1.5 s, the 7% that deserve it

在我们的分布上，93% 的样本在本地就超过了阈值，而在这一部分与前沿模型的一致性超过 99%。模糊不清的那 7% 则动用最强大脑。综合成本比所有样本都走前沿模型低两个数量级，而且 p50 延迟从秒级降到毫秒级——当分类器位于面向用户的请求链路中时，这一点至关重要。

微调实际上输在哪里

我们持续反复测试微调，它在我们的工作形态上持续败给提示词工程。风格、格式、策略合规这些事情，用一个带有少量示例的版本化提示词配合热前缀缓存可以做得更好：变更在几分钟内部署，回滚在秒级完成，A/B 测试也很干净。微调是一个构建产物，迭代周期要好几天，而且每次基础模型升级它就会过时——最近这种升级很频繁。上面的蒸馏模式是值得例外的那一种，而且即使在那里我们也是蒸馏到我们自己托管的小型开源权重模型，这样产物就是我们的。

蒸馏出来的模型是冻结的；但世界不是。所以路由会持续将 1% 的影子样本双写到前沿模型，当分歧超过某个阈值时就通知我们重新打标签、重新蒸馏。小模型运行成本低、易于托管，但容易被人遗忘。影子样本就是防止"我们去年春天自动化了这个"悄悄退化成"自从春天以来我们一直在错误分类"的关键机制。