一、项目背景

我们几个高频场景一开始都硬上大模型，单次推理成本高、延迟也大。结果就是少数几个"大户"场景把显卡资源吃满，新业务想排个队都排不上。小模型不是没考虑过，但效果总觉得差一口气，业务方不愿用。卡资源一天天紧绷，成本账单却月月涨，这事迟早要破。最难受的是，每次申请扩容都被财务问"为什么越用越贵"，我们却给不出细到场景的账。

有次一个大客户临时要上一个实时审核场景，排期排到两周后，因为卡全被几个长摘要占着。那次丢单让我们下定决心：不能让少数场景绑架整池算力，得把贵的大模型从"高频简单活"里解放出来，留给真正难的任务。

二、落地场景

我们用大模型当教师，蒸馏出小模型去接那些高频但简单的请求，比如意图分类、短文本摘要、简单问答。蒸馏数据不是随便采的，按真实流量分布构建，还专门补了一批难例。小模型上线后走路由切换，简单请求直接进小模型，只有拿不准的才升级到大模型。成本和精度每日对账，效果一旦回归就亮红灯。上线前还有一道回归门禁，精度掉到阈值以下不许发，业务方再急也得等模型达标。

为了不让路由变成新的瓶颈，我们把路由判断本身也做成轻量的，几毫秒内出结果，绝不为了省算力反而加了延迟。小模型的版本迭代也接进了流水线，每次更新自动跑难例集。

三、关键技术挑战与解决思路

蒸馏数据是最容易偷懒的地方。我们第一版只覆盖了头部流量，长尾那些低频但刁钻的请求，小模型全翻车，业务方一用就骂。后来专门挖了难例补进去，长尾精度才爬上来。路由切换也不能太刚，简单判错就升级大模型，升级多了成本省不下来；判松了又漏。我们拿真实流量做了离线回放，把路由阈值调到"宁可多升一点也别误判"的偏保守位置，再靠后续精排兜底。

成本对账要日更，不然小模型偷偷退化，账单先报警、效果后报警，顺序就反了。我们还踩过一个坑：早期回归门禁只看平均分，结果整体过了但某类长尾掉得厉害没被发现，后来改成分桶看精度，长尾桶不达标同样不许发。

案例片段（已脱敏）： 蒸馏数据构建与路由切换的核心配置如下：yaml distill:  teacher: big-model-v3  student: small-model-v1  data_mix: {head: 0.6, hard: 0.4}   # 难例占四成 route:  student_first: true  upgrade_if_conf_lt: 0.82           # 置信度低于0.82升级大模型 gate:  min_accuracy: 0.90                 # 低于九成不许发上线后，高频简单请求的小模型覆盖率达 73%，单请求成本下降约 58%，长尾桶精度也稳定在九成以上。

教师模型的版本管理也得跟上。教师升级后，旧的小模型是用旧教师蒸馏的，能力天花板被锁死，我们建立了教师变更即触发重蒸馏的机制，教师发新版，小模型流水线自动跟一轮。版本对齐这事一开始没人管，导致线上线下小模型来源不一致，回归门禁还按旧标准放，后来统一了版本溯源才踏实。蒸馏不是一锤子买卖，是跟着教师一起进化的。

四、效果数据

高频简单请求里，小模型覆盖率达到约七成三，这部分单次成本下降约百分之五十八。整体推理成本月账单下降约四成，释放出来的显卡让三个新业务提前上了线，那次丢的单子后来也接回来了。精度保持率稳定在九成以上，回归坏 case 从上线初期的每周十几条，压到每月两条以内。路由升级比例控制在两成七，没有因为过度升级把成本省空。业务方从"不愿用"变成"默认走小模型"，态度反转，连财务都认可了这笔账。

五、可复用经验总结

不是所有场景都值得上大模型，高频简单的请求用小模型接，成本和延迟都划算，把贵的算力留给真正难的活。蒸馏集别只采头部，长尾的难例才是小模型能不能用的关键，我们在这上面栽过跟头，平均分过了不等于每类都过。路由阈值偏保守一点没关系，多升几次大模型的成本，远小于误判放错一个答案的代价。精度门禁必须日更对账，还要分桶看，让账单先于效果报警，顺序反了就晚了。讲句实在话，降本不是把大模型换掉，而是让对的模型干对的活，这是调度问题，不是选型问题，账算清楚了，扩容的申请也好开口了。

业务方对小模型的接受度，是慢慢养出来的。一开始他们只要看到小模型三个字就皱眉，我们干脆不在产品里提模型大小，只说这条链路更快更省，等他们习惯了快和便宜，再回头告诉他们背后换了模型，抵触自然没了。技术落地有时候得先给甜头，再讲道理。

结语

后来我们把小模型的版本也接进了回归门禁的自动流水线，每次迭代自动跑一遍难例集，退化一票否决。降本这件事，靠人盯容易松，交给流水线才稳，人也从天天看精度里解放出来。