大模型时代，小模型还有哪些价值，如何在效果、成本和延迟之间取舍？｜快手算法面经解析

60 秒回答模板

我会把小模型的价值放在系统层看，而不是单点能力对比。大模型泛化和推理能力强，但成本高、延迟高、部署重；小模型在分类、召回、排序、意图识别、内容安全初筛、端侧个性化和高并发服务中仍然很有优势。工程上可以做多模型路由：简单请求由小模型处理，置信度低、风险高或复杂推理请求再升级到大模型；也可以用大模型蒸馏小模型，让小模型学习特定领域的决策边界。取舍时要同时看效果指标、P95/P99 延迟、吞吐、单次调用成本、GPU/CPU 资源、隐私要求和可维护性。大模型应该作为能力上限和兜底，小模型则负责规模化、稳定化和成本控制。

考点 系统协同而非替代

难度 真实面经题

回答目标 展示对大模型时代模型体系的系统理解：小模型不是落后方案，而是降低成本、提升延迟、保护隐私和支撑规模化服务的关键组件。

深入解析

小模型适合高频、确定、低延迟任务

很多业务请求并不需要大模型的开放生成能力，例如意图分类、标签预测、内容理解初筛、检索召回、排序特征打分、广告点击率预估、风控规则辅助和端侧推荐。这些任务输入输出结构稳定，指标明确，小模型可以用更低成本实现更好的 P95 延迟和吞吐。在短视频、推荐和搜索场景里，高并发链路往往不能接受每次都调用大模型。

小模型在隐私、端侧和可控性上有优势

端侧模型可以减少数据上传，适合键盘输入、相册理解、设备状态感知、个性化排序等隐私敏感场景。小模型参数少、资源占用低，更容易量化、剪枝和离线部署，也更容易做稳定性验证。对于监管要求高或输出边界清晰的任务，小模型的行为空间更窄，反而更容易控制和审计。

路由和级联比单模型更经济

实际系统可以用小模型先做意图识别、难度判断、风险识别和置信度估计。高置信简单请求直接返回，低置信或复杂请求再交给大模型。也可以采用小模型生成候选、大模型复核；小模型做安全初筛、大模型做深度理解；大模型离线生成标注、小模型在线服务。这样能把大模型调用集中在真正需要的部分，降低平均成本和尾部延迟。

蒸馏、量化和专用化提升小模型性价比

小模型不是简单缩小版的大模型，而应围绕业务任务专用化。可以用大模型生成训练数据或解释链，进行知识蒸馏；用 LoRA、剪枝、量化和混合精度降低部署成本；用领域语料和 hard negative 提升边界样本能力。评估时不能只看通用榜单，而要看具体业务数据、错误类型、置信校准和线上收益。

易错点

简单回答小模型没用了，忽略高并发、低延迟和端侧场景。
只比较模型效果，不比较成本、P95/P99 延迟和部署资源。
认为大模型可以端到端解决所有问题，忽略工程链路中的召回、排序和安全初筛。
路由策略只靠固定规则，没有置信度、风险等级和在线反馈。
蒸馏只追求压缩参数，没有关注真实业务分布和错误边界。
用通用 benchmark 代替业务指标，导致结论不可落地。

面试官追问

什么时候必须上大模型？

当任务需要开放式理解、复杂推理、多步规划、长上下文整合、少样本泛化或自然语言生成质量时，大模型更合适。比如复杂客服问答、创作辅助、跨领域分析和需要解释的决策。但即使使用大模型，也可以让小模型承担前置过滤、路由、召回、排序和安全检测。

多模型路由如何设计？

可以用规则和模型结合。规则层识别高风险、长文本、特殊业务场景；小模型层预测意图、难度和置信度；成本层结合当前负载、SLA 和用户等级决定是否升级。路由效果要用准确率、升级率、误拦截率、平均成本、尾部延迟和用户满意度评估，重点避免把复杂问题错误地留给小模型。

小模型蒸馏有什么风险？

主要风险是学到大模型的错误、覆盖不到真实线上分布、对长尾问题过拟合，以及置信度不准。解决方式是混合人工标注和大模型标注，加入 hard case，做置信校准，保留高风险样本的大模型兜底，并通过线上灰度观察错误类型变化。

如何做效果、成本和延迟的综合决策？

先定义业务目标和 SLA，比如准确率最低要求、P99 延迟上限和单次成本预算。然后比较单大模型、小模型、大模型兜底、级联系统几种方案。最终看单位成本收益，而不是单纯看准确率。如果小模型准确率略低但成本降低明显，且错误能被兜底机制覆盖，它可能是更优方案。