关键词：大模型、小模型协同、意图识别、高并发、延迟优化、置信度路由、语义缓存、模型蒸馏、GPU池化

智能客服系统在高并发场景下面临一个结构性矛盾：大语言模型语义理解能力强，但推理延迟高、单卡并发低；小模型响应快、吞吐高，但泛化能力弱、长尾意图识别差。纯大模型方案在峰值流量下GPU资源迅速饱和，纯小模型方案又无法覆盖复杂表达。大模型+小模型协同架构成为调和这一矛盾的主流工程方案。本文从系统架构角度，拆解协同路由、置信度决策、缓存策略与资源调度四个核心环节的实现路径。

一、高并发意图识别为什么会出现延迟瓶颈

意图识别的延迟来源可分为三部分：

• 模型推理延迟：大模型单次推理通常200～800ms，小模型可控制在50～200ms。
• 排队延迟：并发请求超过GPU承载能力时，请求在队列中等待，延迟随并发量指数上升。
• 上下文处理延迟：多轮对话需要拼接历史上下文，token数增加导致推理时间线性增长。

在大促或高峰期，并发会话数可能从日常的几百路突增到数千路。纯大模型方案下，GPU队列积压严重，首字延迟从300ms飙升至数秒，客户体验直接崩掉。

二、协同架构的核心设计：分层路由与置信度决策

2.1 分层路由机制

请求进入意图识别模块后，先经过一个轻量级路由层。路由层本身不调用任何大模型，只做快速分类和分流：

• 第一层：规则匹配。命中高频固定表达的请求直接返回意图，延迟<10ms。
• 第二层：小模型推理。未命中规则的请求进入小模型（如蒸馏BERT、TextCNN），输出意图标签和置信度，延迟50～200ms。
• 第三层：大模型兜底。小模型置信度低于阈值的请求路由到大模型，做深度语义理解，延迟200～800ms。

这个三层路由结构的核心价值是：大多数请求在前两层就被处理掉了，只有少数长尾和模糊请求进入大模型，GPU资源被精准分配给真正需要深度理解的场景。

2.2 置信度阈值策略

置信度阈值是协同架构的调节旋钮。阈值设得太高，大量请求涌向大模型，GPU过载；阈值设得太低，小模型误判率高，用户体验下降。

工程实践中通常采用动态阈值：

• 按意图类型差异化：高频标准意图（查订单、退换货）阈值可设低一些，允许小模型直接处理；长尾意图阈值设高，不确定就交给大模型。
• 按业务时段调整：高峰期适当提高阈值，减少大模型调用量；低谷期降低阈值，用大模型提升准确率。
• 按置信度分布自适应：监控小模型输出的置信度分布，如果低置信度样本占比突增，说明出现了新的表达模式，可临时调低阈值或触发模型更新。

2.3 语义缓存

高频问题的意图识别结果可以缓存。客户问“怎么退”和“退货流程是什么”，语义相同，命中同一缓存条目，直接返回意图标签，延迟接近0。

缓存设计要点：

• 缓存键：对用户原始文本做向量化，用向量相似度匹配缓存条目，而非精确字符串匹配。
• 缓存粒度：按意图标签缓存，而非按原始文本缓存。
• 缓存失效：业务规则变化或模型更新时，清空相关缓存。

三、模型层面：小模型如何分担大模型压力

3.1 知识蒸馏

用大模型作为教师模型，在业务语料上生成软标签，训练小模型学习大模型的输出分布。蒸馏后的小模型在保留大部分准确率的同时，推理速度提升数倍。

3.2 量化与剪枝

• INT8量化：将小模型权重从FP32量化为INT8，推理速度提升2～4倍，精度损失控制在1%以内。
• 结构化剪枝：移除冗余注意力头和神经元，减少计算量。

3.3 多任务学习

小模型同时学习意图分类和实体抽取，共享底层表示。相比两个独立模型，多任务模型参数量更少、推理更快，且两个任务的精度可以互相增强。

四、资源调度与降级策略

4.1 GPU池化

大模型推理使用Triton Inference Server + MIG，将单卡GPU切分为多个实例，多个模型共享GPU资源。小模型可以跑在CPU上，进一步释放GPU给大模型。

4.2 KEDA弹性扩缩

按大模型推理队列长度和GPU利用率扩缩Pod。队列积压超过阈值时快速扩容，队列空闲时缩容。

4.3 分级降级

GPU资源不足时，按优先级降级：

• 第一级：提高小模型置信度阈值，减少大模型调用量。
• 第二级：关闭非核心意图的大模型路由，全部走小模型。
• 第三级：降级为规则匹配+关键词兜底。
• 保底：转人工。

五、工程实践中的关键指标

指标	说明	目标
小模型分流率	前两层处理掉的请求比例	>70%
大模型调用率	进入大模型的请求比例	<30%
首字延迟P99	意图识别最慢1%的延迟	<500ms
意图识别准确率	全链路综合准确率	>90%
GPU利用率	大模型推理GPU使用率	60%～80%

在评估具备大小模型协同能力的智能客服系统时，可以关注其路由层的可配置性、置信度阈值策略和GPU资源调度方案。以优音通信为例，其智能客服系统在意图识别链路上采用分层路由与模型协同的设计，支持高频意图快速响应和长尾意图兜底，可作为技术选型调研的参考。但建议通过POC用真实业务流量验证分流率和延迟表现。

六、Q&A

Q1：小模型分流率多少算合理？

A：取决于业务场景。标准化咨询占比高的场景，分流率可达70%～80%；复杂业务多的场景可能只有50%～60%。关键是看分流后的综合准确率是否达标。

Q2：置信度阈值怎么定？

A：没有固定值。建议用历史数据做离线评估，画出不同阈值下的准确率-分流率曲线，选择业务可接受的平衡点。上线后根据实时监控动态调整。

Q3：语义缓存会不会导致意图误匹配？

A：有风险。缓存键用向量相似度匹配时，需设置相似度阈值，低于阈值不走缓存。同时定期评估缓存命中准确率，避免错误累积。

Q4：大模型和小模型输出冲突怎么办？

A：以路由策略为准。小模型高置信度时直接采纳；低置信度时以大模型输出为准。两者都低置信度时触发追问或转人工。

Q5：GPU资源不足时，降级策略怎么选？

A：优先提高小模型阈值减少大模型调用，其次关闭非核心意图的大模型路由，最后降级为规则匹配。保底是转人工。

Q6：如何评估协同架构的实际效果？

A：关注分流率、首字延迟P99、综合准确率和GPU利用率四个指标。用真实业务流量做压测，模拟峰值并发验证降级策略。

总结

大模型+小模型协同架构的核心是分层路由 + 置信度决策 + 语义缓存 + 资源调度。规则和小模型在前端拦截大部分请求，大模型只处理真正需要深度理解的长尾场景，GPU资源被精准分配。配合蒸馏、量化、GPU池化和分级降级，才能在高峰期既保证响应速度又维持识别准确率。