混合模型策略：端侧秒回与云端兜底，打造毫秒级AI应用

1. 先搞明白“混合模型策略”到底在解决什么问题做AI应用落地这两年我最大的感受是模型能力再强用户等不起也是白搭。去年我们内部启动了一个代号叫“衡石”的项目目标是在客服辅助、办公问答、端侧语音助手这类高并发场景里把智能响应的体感压到毫秒级同时又不想牺牲太多回答质量。一开始我们尝试过两种极端方案效果都不太理想。纯端侧方案把模型塞进用户手机或本地网关延迟确实低首字响应能到一两百毫秒但遇到复杂推理、长文总结、专业领域问题时小模型明显力不从心回答经常前言不搭后语用户反而觉得更“智障”。纯云端方案直接调大模型的API回答质量好可首字延迟动不动上800毫秒甚至2秒在高并发时段还会排队和超时客服坐席根本等不住体验是灾难级的。于是我们换了个思路与其在“快但笨”和“聪明但慢”之间二选一不如两个都上做一个混合策略。简单说就是把高频、简单、确定性强的请求交给本地轻量级微调模型秒回把低频、复杂、需要深层推理的请求交给云端大模型兜底。中间加一道智能路由做分发。这套架构跑通以后P50首字响应从之前的1.2秒降到了180毫秒左右P95控制在450毫秒以内同时准确率还比纯端侧方案提升了近十个百分点。这篇文章不聊概念只讲我们是怎么拆需求、怎么选型、怎么训练端侧模型、怎么做路由分流、以及踩过的那些坑。如果你也在做类似的应用建议花几分钟看完至少能少走两个月的弯路。2. 整体架构设计轻量和云端的边界到底划在哪架构设计的第一件事不是画拓扑图而是先回答一个核心问题哪些请求该留在本地哪些请求该上云这个边界划得准不准直接决定了整个系统的体验和成本。2.1 三条路径的分流体系“衡石”最终采用了三条路径分流而不是简单的两条端侧直达请求被判定为高频标准问题直接走轻量微调模型不经过网络响应最快成本几乎为零。云端加速请求需要一定的泛化能力但意思明确通过网络请求云端小参数模型或专用模型耗时中等。云端精算请求涉及复杂推理、长上下文、专业领域才真正调用云端大模型。为什么要拆成三条因为云端大模型和云端小模型的价格差异很大延迟差异也大。很多场景其实不需要动用大模型用中型模型就能解决得不错。把这两类混在一起全走大模型成本会失控全都降级到中型模型部分复杂问题又答不好。于是中间这层“加速带”非常有必要。2.2 一个请求从进入系统到返回完整走一遍以我们最典型的客服辅助场景为例一次用户提问的完整链路是这样的用户输入问句后客户端先把文本交给一个极轻量的意图识别模块。这个模块本质上是一个蒸馏过的文本分类器只有几十MB跑在端上负责判断三类信息这是不是高频问题、是否涉及多轮上下文、是否包含复杂推理需求。根据这些信号请求会被打上标签走对应路径。如果是端侧直达微调模型直接把答案连同置信度分数一起返回如果置信度低于阈值系统会触发“二级确认”机制把截断的上下文同步发往云端做二次验证。这里有个细节端侧模型返回结果的同时会附带一个“对答案的自信程度”而不是只给一个答案。这个信号是路由策略的灵魂。云端路径的请求会先经过语义缓存层。缓存命中就直接返回不要浪费一次模型调用。缓存未命中才进入模型服务层云端小模型和大模型分别监听在不同的队列里根据请求的priority进行调度。2.3 为什么要用“置信度阈值”而不是“硬规则”做路由一开始我们想过用规则路由比如“包含‘怎么退’、‘如何操作’就走端侧”但很快就发现维护成本高得离谱。用户的话术千奇百怪规则要不停加白名单、加模板而且无效。后来我们把路由决策改成了“置信度为主、规则为辅”。规则只负责拦截那些绝对不能走端侧的请求比如涉及“投诉、转人工、安全风控”等敏感信号其余全部交给分类器打分分数超过0.85走端侧低于0.5走云端精算中间的部分走云端加速。这套逻辑看起来简单但运行起来非常稳。它的优势在于模型不确定的东西不强推宁可多花一点钱上云也不要让用户得到一个质量很差的本地答案。3. 轻量级微调模型是怎么训练出来的端侧模型是整个系统的地基。它如果不行路由再好、云端再强整体的体验也不会好。我们在这块投入的时间最多。3.1 基座选型不能只盯着参数量市面上开源的小模型不少但真正适合端侧部署的并不多。我们选型时锁定了三个硬性指标支持长上下文的推理、量化后精度损失小、移动端推理框架兼容性好。最终选择的基座是参数量在7B级别的一个开源模型经过INT4量化后体积大概在3.5GB左右可以跑在主流手机和边缘网关设备上。选择这个参数量是经过权衡的1~3B的模型虽然更快但泛化能力明显不足复杂一点的改写、总结任务就拉胯13B以上量化后体积太大低端机上推理速度又不行。3.2 数据构造不要急着找公开数据集微调效果不好八成是数据有问题。我们的训练数据全部来自真实业务日志但直接拿原始日志训练也不行。原始用户提问噪声太大有很多错别字、口语化省略、歧义表达模型学不到正确的模式反而会学会一些怪癖。我们做了一套半自动的数据清洗流程先从线上日志里筛出高频的Top 200意图簇每个意图簇下人工标注50~200条不等的标准问法然后利用云端大模型对每个标准问法做近义改写扩充到每个意图500条以上。改写的时候控制两个变量句式多样性要够但语义绝对不能漂移——这也是需要人审核的原因。纯粹靠大模型扩写会出现改写后意思微妙变了的情况这种数据一旦混进训练集模型就会被带偏。3.3 微调实操参数与避坑记录我们使用的是LoRA微调没有动全量参数因为全量微调在数据量不够的情况下非常容易灾难性遗忘。简单解释一下LoRA它不是去调整基座模型的原始权重而是在模型的特定层旁挂了一条低秩的旁路分支训练时只更新这条分支上的参数。这样做的直接好处是基座原本的通识能力被完整保留了我们注入的只是特定任务上的“肌肉记忆”。最终保存的增量权重只有不到200MB而且和基座模型是解耦的随时可以单独替换和回滚。LoRA的配置参数我们是这么设的rank取值16alpha取值32这两个参数控制旁路分支的表达能力设得太大容易过拟合太小则学不进东西学习率取2e-4训练轮数和数据量挂钩大概3个epoch最大序列长度根据业务实际情况截断到2048超过的部分直接用截断策略不要硬塞否则训练显存压力太大而且几乎学不到有效内容。训练完成后我们专门留了10%的干净数据做评估没有用训练集里的数据验证这样做出来的指标才有参考意义。3.4 量化部署时的一个关键教训模型训练完后先用INT8量化跑了一轮精度几乎无损但推理速度还没达到我们的目标。于是尝试INT4量化速度是上来了但在几个多步推理的测试集上精确匹配率掉了将近8个百分点。后来排查发现问题出在部分层的激活值对量化特别敏感。解决办法有两条一是采用混合精度量化敏感层保留INT8其余层压到INT4体积和速度只稍微牺牲一点但精度失分收回到3%以内二是做了一个简单的量化校准用真实业务流采样了一千条数据重新统计激活值分布后再做量化比内置的默认校准集效果好了不少。这里的核心经验是量化不是点一下就完了要结合你的数据分布做校准而且一定要对量化后的模型做全面的回归测试不能只看一个benchmark。4. 云端大模型接入与协同配置端侧模型解决的是量大面广的高频问题但系统要撑起“智能”两个字云端大模型这个外援必须接好。4.1 云端能力池划分我们没有把所有云端请求都堆到同一个模型上而是划分了两个能力池。池子A是一个中等规模的模型处理中等复杂度的问题成本低、速度快池子B才是真正的大参数模型处理复杂推理、长文分析、多轮深度对话等。划分的依据是路由层给出的请求复杂度评分而不是看用户说了几个关键词。复杂度评分由一个小模型计算输入是问句文本和意图类型输出一个1~5分的复杂度分4以上才允许进入池子B。4.2 语义缓存的多级设计云端服务的延迟很大一部分来自重复请求。用户在客服场景里问的问题重复度极高十个坐席同一天可能问同样的问题几十次。为了削掉这部分延迟和成本我们在云端入口做了一个语义缓存层。准确说是两级一级是精确缓存对问句做规范化处理后直接哈希匹配命中即返回耗时几乎为零二级是语义缓存利用句向量模型将当前问句与最近一小时的高频问句做相似度检索相似度超过0.93且答案类型一致就直接复用答案。语义缓存上线后效果非常明显云端大模型的调用量直接下降了将近三成P95延迟也从原来的900多毫秒降到了600多毫秒。缓存这里最大的坑不是命中率而是新鲜度。如果业务规则变了、政策调整了旧缓存里的答案可能已经是错的。所以每一条缓存都要带业务标签和过期时间并且提供一个主动失效接口业务侧发生变更时能精准地把相关缓存全部清掉而不是一刀切清全库。4.3 断连与降级预案云端大模型接入链路再稳也架不住客户现场的网络波动。所以在设计系统的时候我们就强制要求端侧模型必须能够离线兜底。哪怕所有云端请求都挂了系统也要能靠端侧完成基础答疑。具体做法是当网络检测模块连续三次请求超时时系统自动进入降级模式所有请求强制走端侧同时端侧模型会降低置信度阈值——意思是它不确定答案时也都尽量给出最好的猜测而不是报错并且在回答末尾附上一句提示告诉用户“当前处于离线模式部分内容可能不够准确”。这个离线兜底机制在演示和实际部署中救了我们好几次。有时候客户现场网络就是不好如果系统因为云端不可用就全局瘫痪那这个方案基本就被一票否决了。5. 毫秒级响应的实测数据与调优过程这套系统上线后的核心指标是与传统方案相比体感响应从秒级进入毫秒级。只讲架构不讲数据是耍流氓我把实测情况摊开来说。5.1 首字响应与总耗时的分位分布我们在模拟客户环境做了连续48小时的压测模拟会话中高频的混合请求。端侧直达路径的中位首字响应是80毫秒P95是150毫秒——这个数字对用户来说完全是秒开。云端加速路径中位首字响应在250毫秒左右P95约420毫秒。真正调用云端大模型的路径中位首字响应是650毫秒P95接近920毫秒这部分慢一些但占比只有全部的15%左右。把这个占比加权到整个系统整体中位首字响应是180毫秒。和一开始纯大模型方案的1.2秒相比这个提升是实打实能感知到的。5.2 正确率与成本的变化正确率方面端侧模型在高频意图上的准确率做到了91%云端兜底路径因为模型能力更强回答正确率能到95%上下系统整体加权正确率约93%明显优于纯端侧方案和纯云端方案相比也只落后不到一个点。成本上从单条请求看端侧路径成本约等于云端路径的零头云端加速路径大概是大模型路径的五分之一。混合策略让整体的单请求平均成本下降了七成以上。对小团队或者成本敏感的业务来说这个数字比延迟指标还重要。5.3 提升响应速度的第二步基础调优除了模型路由分流我们还做了一系列常规动作来榨取速度比如端侧模型推理框架开了int4加速模式端侧模型加载和常驻内存预热让首包时间进一步压缩云端小模型的部署直接走容器热启动加上快速的推理框架尽可能缩短网络链路。这些单个动作每个只能省几十毫秒但叠加起来效果就放大了。调试技巧上网络上建议直接开启连接池复用和HTTP的流式首包响应不要让模型一次算完整个答案才发出来而是第一个token生成后立刻发给客户端用户在感知上会觉得快了一倍。语音合成场景下这一点尤其明显。6. 上线踩坑与排查实录这套系统从开发到上线踩过的坑能列一长串。挑几个最典型、最有代表性的记录在这里也算给同行们排雷。6.1 路由置信度阈值一刀切的坑上线初期我们给所有意图统一设了0.85这个路由阈值结果某些意图簇的请求上云率奇高。排查后发现这些意图簇在训练数据里的样本分布不够均匀导致端侧模型对它们整体偏低。解决方法是按意图簇设置差异化阈值。高频低频、简单复杂都分开统计分别找最佳阈值。这个调参过程不是一劳永逸的要每周根据日志里的路由分布做一次复盘。6.2 微调数据的“代际污染”我们在做第二批训练数据时直接从云端大模型的历史回答里抽了一批作为标准答案没做人工复核。结果这批数据里混入了一些大模型的“幻觉答案”端侧微调模型把这些内容当成标准学了进去导致某个领域的回答准确率直接掉了十几个点。后来在数据管线里加了一道强制规则所有来自云端生成的训练样本必须经过至少两轮人工抽检抽检比例不低于5%任何可疑样本一律剔除。数据质量的红线不能退让宁可少数据也不能要脏数据。6.3 端侧与云端答案不一致最麻烦的一个线上问题是同一个问题端侧模型和云端大模型的回答口径不一致。比如端侧说“退款需要3个工作日到账”云端说“退款1-2个工作日到账”用户两头都问了发现对不上直接投诉。我们最终的处理方案是在端侧模型训练时加入一致性约束刻意构造一批云端标准答案和端侧简化答案的对照样本让端侧模型学习在“不改变核心语义”的前提下使用更稳妥的表达方式。同时所有端侧答案在返回时都临时生成一个“语义指纹”如果用户后续又触发了云端请求云端检测到同一问题指纹不一致会自动用后一次答案做修正说明。这属于体验层面的兜底。6.4 缓存膨胀与命中率劣化语义缓存上线一个月后命中率开始缓慢下降排查发现是无界缓存导致库里积累了大量历史长尾内容占用了太多内存检索速度也变慢了。后来改成了一个“大小双桶”策略热桶存最近一小时的请求容量控制在几千条以内秒级淘汰冷桶存近期内但超过一小时的内容按热度降序淘汰。这个改动既保住了缓存命中率又控制了检索延迟。6.5 低端设备上的性能翻车我们的端侧模型在客户的高端测试机上跑得很顺畅结果到了现场用户的低端安卓机上推理时间直接翻倍整机温度也明显上升。后来做了一套分级加载策略安装时先只部署更小参数量的通用模型等用户在WiFi环境下再静默下载完整的领域模型。同时推理框架根据当前设备性能和温度动态调整线程数——温度超过阈值就自动降低线程宁肯慢一点也不能烫手。这个细节对做终端落地的人来说尤其重要。7. 最后分享几条实战心得项目收尾后复盘我认为“衡石”能成核心不是哪个模型选得好而是整套系统把“快”和“聪明”这两个矛盾的指标通过分流机制统一了。我个人的几点体会是第一点是路由层是整个系统的大脑值得投入比模型训练更多的精力去打磨。端侧模型训练得再好路由判断错了也白搭。一定要让路由具备“不确定性感知”能力也就是输出置信度并且这个置信度要和业务效果联动监控、持续校准。想要真正做扎实可以把意图识别模型的日志单独拉出来分析定期更新训练数据里没有覆盖的新表达。第二点是混合模型的边界是一个动态平衡不存在一劳永逸的最优解。每过一段时间端侧模型的能力会随着新数据的注入而变强原本要上云的请求可能就可以下沉到本地了反过来某个新业务上线后端侧数据覆盖不足又要临时抬高上云比例。建议把路由阈值、意图清单、模型版本都做成可动态调整的配置项方便灰度验证后再全量。第三点是不要追求端侧模型解决所有问题。端侧模型的能力天花板是客观存在的把大量的长尾、复杂问题硬往端侧塞只会让模型权重越来越大、推理越来越慢最后两头不讨好。承认“有些问题就是该上云”反而能让系统的整体性价比更高。如果你也在设计类似的混合模型系统建议先别急着写代码找一个真实场景把上面说的路由边界、数据准备、降级策略想清楚再动手。架构本身不算复杂真正的复杂度都在细节里。