前阵子我把一个跑在云端大模型上的智能体服务做了次大改从“所有请求都丢给云端大模型”换成“本地小模型先消化解决不了再上报云端”。最开始的目的很单纯就是想省钱。没想到跑了两周除了账单肉眼可见地降下来端到端响应速度也比原来快了将近5倍。更巧的是我后来读到一篇来自某顶尖高校团队的研究他们从信息论视角把智能体设计重新推了一遍——本地小模型为什么能带来这种收益背后其实有一套完整的理论解释而不是单纯靠量化压缩。这篇文章就是我对这套思路的完整复盘既有原理层面的拆解也包含可落地的工程做法适合正在做大模型智能体、AI客服、自动化工流、工具调用系统并且对成本和延迟敏感的朋友参考。1. 传统智能体为什么会“又慢又贵”先从一次请求说起1.1 一次简单请求里真正有用的信息往往不到1%在动手改造之前我做过一个很无聊的统计随机抽了500条真实用户请求逐条检查发送给大模型的完整请求数据包里到底有多少内容跟最终决策有关。结果相当扎心。就拿最简单的“查询订单状态”来说请求里包含了几十轮历史对话、上一轮工具返回的原始结果、系统提示词里几百行的业务规则、各种无关的按钮点击日志甚至还有用户在某次闲聊里提到的无关信息。真正帮助模型判断“该调用哪个查询接口、参数怎么填”的内容压缩起来往往不到200个token。但在传统架构里模型必须把这200个token以外的几千个token全部读完才能稳定地给出答案。这里就产生了第一个浪费长上下文输入让预填充阶段的耗时和费用都线性上涨但大量token对决策的贡献趋近于零。信息论里这叫“冗余信息”。一个智能体如果对冗余信息不做任何筛选它的效率必然被这些背景噪音拖垮。我原来一直有个错觉上下文越长模型越“懂”用户。后来才知道所谓“懂”很大程度是靠模型在长文本里翻找关键信息而不是它真的理解了所有细节。一旦上下文超过某个长度模型还会出现“注意力分散”的问题——关键信息被淹没回答反而变差。也就是说长上下文不只是慢和贵它还可能让准确率下降属于典型的负收益堆积。1.2 云端往返和上下文预填充才是延迟的大头很多人以为智能体响应慢是生成token太慢其实在多数真实场景里模型“生成”的时间根本不是大头。我拆过一份端到端延迟报告一个典型的多步工具调用请求总耗时大概4秒分布大概是这样的网络往返两次云端调用每次约300到500毫秒合计约1秒。上下文预填充系统提示词加历史对话加工具返回一次可能输入5000个token预填充耗时接近1.5秒。推理生成模型输出最终答案可能需要600到900毫秒。其他开销框架排队、工具调度、结果校验大约500到800毫秒。看到没有真正花在“思考”上的时间不到四分之一剩下的全是信息搬运。而本地小模型恰好可以同时解决信息搬运和信息冗余两个问题本地推理没有网络排队把输入压缩成很小的结构化状态之后无论本地还是云端预填充的时间都会大幅缩短。这也是为什么我后来看到那篇信息论视角的研究时会有一种“原来如此”的感觉。他们给了一个很简洁的判断智能体本质上是一个信息处理系统优化的目标不是让模型变得更大而是让系统在“保留决策所需信息”和“减少不必要信息传输”之间找到最优平衡。2. 信息论视角下的智能体设计从“塞满上下文”到“只传关键状态”2.1 智能体是一条感知-决策-行动的信息管道把智能体抽象成一条信息管道是我觉得那篇研究里最有价值的视角。用户输入、工具返回、环境状态这些都是“感知信息”模型内部推理是“决策”调用工具、生成回复、执行动作是“行动”。整条链路跑起来本质上就是信息不断被采集、传递、变换和消耗的过程。传统设计的问题在于我们习惯把感知信息原封不动地喂给决策模块也就是让大模型阅读所有内容。这在信息论里等于让决策端承受全部输入熵把所有不确定性都留给模型去处理。而更合理的设计是在感知和决策之间加一个“信息压缩”层把原始信息转换成决策真正需要的低维状态。这就好比人眼每秒接收的视觉数据超过千万比特但大脑真正用于判断“前面有没有障碍物”的信息只有几百比特。我们不会把所有像素都传给大脑的决策中枢而是先做特征提取。把这个思想落到智能体系统里就是让本地小模型担任“特征提取器”和“信息压缩器”把原始对话和历史工具结果转成一小段结构化JSON只把这段JSON交给云端大模型。云端模型不需要再面对长篇累牍的原始信息只需要基于压缩状态做高难度决策。2.2 信息瓶颈用最小的信息量保住最多的决策相关性那篇研究里反复出现“信息瓶颈”这个术语。通俗来说信息瓶颈思想是我们希望找到一个压缩表示Z让Z和任务目标Y之间的互信息尽量大同时让Z和原始输入X之间的互信息尽量小。翻译成人话就是压缩表示要丢掉那些跟任务无关的细节但保留所有对决策有用的关键信息。在智能体系统里本地小模型就是信息瓶颈的编码器。它把原始对话X压缩成结构化状态Z目标是让Z包含用户意图、关键槽位、必要的上下文摘要、工具调用参数而不包含废话、重复描述、过期信息、无关闲聊。衡量这个编码器好不好不只看压缩率更看压缩后信息是否足以支撑下游决策。我实测的一个体感同样一个“改签机票”任务原来发给云端大模型的完整上下文约4200个token经过本地小模型压缩后发给云端的上下文只有大约450个token信息量却覆盖了用户原始需求、出发地、目的地、时间、会员等级、旧订单号。下游模型只用450个token就能做出和原来准确率几乎相同的决策。说白了你帮大模型把作业里的干扰项都划掉了它当然能做得又快又稳。2.3 “5倍性能”是怎么测出来的延迟和吞吐两本账这里要解释清楚“5倍性能”到底指什么。只提升10%不算5倍但我实际测试中简单任务确实达到了5倍以上的提升。我做了一个基准测试集包含2000条经过脱敏处理的真实用户请求主要场景是“查询信息”“简单工具调用”“业务规则判断”。对比指标是端到端延迟和系统吞吐量。老架构全云端大模型的平均端到端延迟大约是3.8秒其中预填充和网络往返占去了约2.5秒。新架构里约65%的请求被本地小模型直接消化这些请求的平均延迟降到了0.7秒左右剩下35%需要上报云端的复杂请求因为上下文被压缩了平均延迟从3.8秒降到了2.1秒。整体混跑下来系统平均延迟约为1.2秒相比原来的3.8秒提升超过3倍。但如果只看“纯本地直接处理”的那部分简单请求延迟从3.8秒降到0.7秒就是5倍多的提升。系统的吞吐量也很有意思原架构单节点每秒最多处理约2.2个请求新架构单节点每秒能处理约10个简单请求因为本地模型不需要排队等远程服务。成本方面单次请求平均消耗的云端token下降了约85%加上云端调用次数减少了60%整体推理成本大概降了一个数量级。所以标题里“5倍性能成本极低”不是空话只是需要说明这是针对“本地可处理的那部分任务”而言不是所有任务都能跑出这个倍数。3. 复现这套设计时我的具体做法和关键决策3.1 整体架构一个本地小模型承担三个职责真正落地时我把本地小模型设计成“一拖三”它同时是信息压缩器、路由判断器和简单任务执行器。这三个职责不能拆成三个模型来做否则延迟和内存都受不了。7B量级的模型在4-bit量化后同时跑这三个任务完全够用。整个请求流程是这样的用户输入到达系统先拼上系统时间、用户信息、当前会话摘要。本地小模型生成一个结构化决策包包含意图、槽位、任务摘要、所需工具列表、置信度分数、决策熵。如果决策熵低于阈值且本地模型生成的结果能通过规则校验就直接返回答案请求结束。如果决策熵超过阈值系统会先调用必要的工具获取信息然后把压缩后的决策包和信息片段发给云端大模型。云端大模型完成复杂推理后返回结果本地再做一个合法性校验再返回给用户。这里有一个容易忽略的点本地小模型不是“尽可能多干活”而是“先判断自己能不能干好”。很多失败案例就是小模型硬扛它不擅长的任务导致准确率崩盘。所以路由判断和信息压缩比“直接回答”更重要。3.2 本地模型选型和量化我为什么选7B4-bit实验阶段我试过从1B到13B的好几个开源指令模型。结论是1B到3B的模型做信息抽取太容易丢槽位压缩结果不靠谱13B模型精度更好但FP16下显存占用接近26GB普通消费级显卡直接劝退。最后落在7B量级用4-bit量化部署显存占用大概5GB左右普通24GB显卡毫无压力甚至可以在部分16GB显卡上运行。量化对信息抽取能力的影响其实很小。我做了一组A/B测试同一个模型FP16和4-bit量化版本在同一批压缩任务上的槽位准确率只差了0.6个百分点可以忽略。但推理速度和内存占用差别巨大。如果你只有CPU建议选择更小的3B模型并配合一些加速方案延迟也能控制在可接受范围内。部署层面我推荐把模型导出成GGUF格式再用支持这种格式的本地推理引擎加载。这样内存占用低还自带缓存和批处理功能。推理服务可以暴露一个标准的HTTP接口内部业务代码完全不用关心模型跑在哪里。3.3 用信息熵做路由阈值怎么定才不容易翻车路由是整个系统里最核心的决策点。如果阈值太松本地模型乱答一气如果阈值太紧所有请求都上报云端省钱和省时都无从谈起。我没有单纯用模型输出的“置信度”而是用了信息熵来量化模型的不确定性。具体做法是本地小模型在输出最终决策时会同时输出各个意图类别的概率分布。我计算这个分布的标准化熵H -Σ(p_i × log p_i) / log N其中N是意图类别的数量p_i是第i个类别的概率。熵值越接近1说明模型越犹豫越接近0说明模型越笃定。我花了一天时间在一批验证样本上做了一个小网格搜索最终确定了一个三层策略熵值低于0.6本地直接处理。熵值在0.6到0.85之间先尝试用规则和工具补充信息再做一次判断。熵值高于0.85直接上报云端大模型不冒险。这个方案比直接用softmax概率靠谱很多因为有些小模型的概率输出会过度自信概率百分百的答案也可能是错的但多类别分布熵能把这种“看似自信、其实不确定”的情况暴露出来。3.4 信息压缩模板逼着本地模型只吐出关键字段为了让本地小模型稳定输出结构化决策包我给提示词设计了一个固定的“信息压缩模板”。模板大致长这样请根据以下信息输出JSON决策包 - 用户原始请求{用户输入} - 当前会话摘要{最近几轮摘要} - 工具返回结果{最近一次工具返回的关键片段} - 当前时间{系统时间} 输出字段 - intent用户意图分类 - slots关键实体/参数用JSON存储 - task_summary50字以内的任务摘要 - required_tools可能需要的工具列表 - confidence0到1之间的置信度 - entropy你对自己判断的不确定度0到1这个模板看起来简单但有两个细节很关键。第一必须把“当前时间”喂进去否则大模型和小模型都会把“明天”“周五”等相对时间解析错。我在踩坑测试里发现晚上11点50分用户说“明天提醒我”本地模型很容易解析成当天日期加上系统时间强制约束后错误率直接下降了一半。第二输出的字段必须是JSON并且字段名固定这样下游解析不容易出错。云端大模型拿到这个决策包后还要能看懂。我在发给云端的系统提示词里明确说不要使用本提示词之外的原始对话内容只基于JSON决策包做推理。这一步很关键否则云端模型还是会尝试从上下文里找更多信息上下文压缩的效果就大打折扣。4. 实测结果与踩坑记录性能数字背后的真实代价4.1 成本、延迟、准确率的量化对比改造后的系统在同一批测试集上跑了大概一周我汇总了一份对比表这里分享给大家参考指标全云端大模型方案本地云端混合方案变化幅度简单任务端到端延迟3.8秒0.7秒提升约5.4倍复杂任务端到端延迟3.8秒2.1秒提升约45%平均云端token消耗每请求约5200 token每请求约780 token下降约85%云端调用次数所有请求约35%请求下降约65%本地直接处理比例0%约65%新增端到端任务成功率94.2%92.8%下降约1.4%看到成功率实际下降时我心里是有些犹豫的。但仔细分析后那1.4个百分点的损失几乎都出现在信息压缩阶段丢掉了某些关键约束条件比如用户说过“不要发短信”这类容易被忽略的偏好。这类问题可以通过调整压缩模板、增加偏好字段来修复并不是本地模型能力不够导致的。另外云端调用量下降65%但云端费用下降远不止65%因为剩余复杂请求的输入token也压缩了。最后看账单混合方案的推理总成本大约是原来的8%到10%这个节省幅度在规模化场景下非常显著。4.2 踩坑一上下文截断把关键指令截没了第一个让我头疼的问题出在信息压缩阶段。最初我为了控制token长度把本地小模型的输入压缩到“最近两轮对话当前请求”。看似合理结果用户之前设置的偏好、约束、上下文信息全被截掉了。比如用户第一轮说“帮我订机票尽量选靠窗的”第二轮补充说“时间改成后天下午”但本地模型只看到第二轮以为用户没有偏好压缩结果里就丢了“靠窗”这个槽位。后来我改进了输入组织方式。不再按“最近几轮对话”裁剪而是把每一轮历史对话都先让本地小模型抽取出“用户偏好”“未完成任务”“关键事实”三类结构化信息随请求一起存入会话状态。等到新请求进来时本地模型读到的是“经过压缩的历史记忆”而不是原始对话轮次。这样丢信息的概率大幅降低输入长度也从原来的每轮200个token压缩到整个历史摘要约150个token。这个经验的教训是上下文压缩不是简单截断而是要把历史信息预先结构化。对着一份杂乱对话日志硬截还不如一开始就建立一个“结构化记忆库”。4.3 踩坑二本地小模型会出现“过度自信”信息熵路由帮我过滤掉了很多真正不确定的请求但另一个现象反复出现本地小模型在某些样本上输出熵很低看起来很有把握结果答案却是错的。我后来分析了一下发现这跟模型输出的概率校准有关。小模型的softmax分布经常过于尖锐它在熟悉的数据分布上会给出非常高的置信度一旦输入偏离训练分布自信程度也不会立刻下降。为了治这个毛病我在最终回答前加了一层规则校验。本地模型输出无论多自信都必须先通过一个轻量校验器检查必填槽位是否齐全、时间解析是否合理、工具参数是否符合类型要求。如果校验不通过即使熵值再低也强制上报云端。加上这层校验之后端到端准确率从91.5%恢复到92.8%比较接近云端方案的水平。这里我想额外提醒一句信息熵是很有用的信号但不能信仰它。它应该和规则校验、工具返回结果交叉验证才能构成一个可信的路由决策。4.4 踩坑三本地模型硬扛复杂推理得不偿失有一次我图省事把“合同条款合规判断”这个任务也放进本地模型直接处理的列表里。第一次测试成功率只有八成左右而且失败案例全是那种需要逐条对比条款、进行多轮确认的场景。本地模型虽然能压缩信息但它百科式知识和逻辑链条的容量上限摆在那里强行让它处理复杂推理只会让整个系统的准确率变成一个不稳定的定时炸弹。所以后来我在路由逻辑里加了“领域黑名单”本地模型永远不直接处理数学计算、合同审核、法律咨询、代码生成这类高复杂度任务。遇到这些领域本地模型只做“意图识别和上下文压缩”真正的推理判断全部交给云端大模型。这样虽然牺牲了一部分“本地直答率”但换来的是整体稳定性和可预期性。我一直认为智能体系统的第一目标是可靠其次才是省钱。5. 这套方法适合什么场景以及我认为不必硬套的场景5.1 最合适的场景高频、结构性强、工具调用固定这套设计最适合那些业务模式非常固定的智能体场景。比如售后客服用户报问题系统查订单、判断常见原因、回复处理结果。工单分类和分流把不同业务请求自动分给不同后端流程。内部数据查询助手用户问“上个月销售额是多少”系统查库、算聚合、返回结果。定时任务和个人助理提醒、待办、日历查询。信息收集型对话先了解用户需求再调用工具补全信息最后生成确认话术。这些场景有一个共同特点任务类型有限工具调用模式固定输入输出结构高度重复。本地小模型只需要记住有限的意图和工具规则就够了信息压缩的容错率很高即使偶尔漏掉一个次要参数规则校验也能兜住。5.2 完全不适合的场景长尾开放域和高专业门槛我也要泼盆冷水。如果任务是开放域的比如“帮我想一个营销方案”“帮我分析这份法律合同的漏洞”“给这个产品做一套品牌故事”这类任务的答案高度依赖广泛知识储备和深层的语义理解本地小模型即使做了信息压缩压缩过程本身就会丢失大量有价值的背景知识。系统再高效也扛不住“答案质量差”这个硬伤。我的处理方式是让本地小模型在遇到这类问题时直接识别出来并整包转发给云端大模型并且不强行做压缩。注意这时候本地模型只做“分类”不做“压缩”。既然云端需要大量背景知识那就让它看原始上下文没必要用小模型的风险换token。5.3 后续可以扩展的方向在我自己的系统上下一步准备做两件事。第一是把“本地小模型”升级成“多级模型梯队”用一个3B模型做最快校验一个7B模型做信息压缩和简单任务一个云端大模型做复杂推理。这样大部分请求会先被3B模型拦截7B模型只在需要更精细解析时介入整体延迟和成本还能进一步优化。第二是让路由策略从“静态阈值”变成“自适应策略”。现在信息熵阈值是手工调的后续我打算用强化学习或简单的在线学习根据每个任务的实时反馈动态调整阈值。比如某个用户的请求历史表明他很喜欢多轮追问那么路由可以适当偏向云端处理如果用户只做简单查询就尽量留在本地。这种个性化路由本质上也是在优化“决策所需信息”的传递效率和信息论视角很契合。最后再分享一个小经验。这套系统上线后不要只盯着成本报表还要定期回看本地小模型的“决策熵分布”。如果发现本地处理请求的熵值普遍偏高说明模型对当前业务数据不熟悉要补充微调数据如果发现熵值普遍很低但准确率下降说明规则校验层出了问题。这两个信号可以帮助你在模型效果和成本之间持续找到更合适的平衡点而不用等到用户投诉才发现问题。 
长河君 · 2026/10/17 19:19:01 · 阅读 1.2k 本地小模型+信息压缩：智能体延迟降5倍的成本优化实践
前阵子我把一个跑在云端大模型上的智能体服务做了次大改从“所有请求都丢给云端大模型”换成“本地小模型先消化解决不了再上报云端”。最开始的目的很单纯就是想省钱。没想到跑了两周除了账单肉眼可见地降下来端到端响应速度也比原来快了将近5倍。更巧的是我后来读到一篇来自某顶尖高校团队的研究他们从信息论视角把智能体设计重新推了一遍——本地小模型为什么能带来这种收益背后其实有一套完整的理论解释而不是单纯靠量化压缩。这篇文章就是我对这套思路的完整复盘既有原理层面的拆解也包含可落地的工程做法适合正在做大模型智能体、AI客服、自动化工流、工具调用系统并且对成本和延迟敏感的朋友参考。1. 传统智能体为什么会“又慢又贵”先从一次请求说起1.1 一次简单请求里真正有用的信息往往不到1%在动手改造之前我做过一个很无聊的统计随机抽了500条真实用户请求逐条检查发送给大模型的完整请求数据包里到底有多少内容跟最终决策有关。结果相当扎心。就拿最简单的“查询订单状态”来说请求里包含了几十轮历史对话、上一轮工具返回的原始结果、系统提示词里几百行的业务规则、各种无关的按钮点击日志甚至还有用户在某次闲聊里提到的无关信息。真正帮助模型判断“该调用哪个查询接口、参数怎么填”的内容压缩起来往往不到200个token。但在传统架构里模型必须把这200个token以外的几千个token全部读完才能稳定地给出答案。这里就产生了第一个浪费长上下文输入让预填充阶段的耗时和费用都线性上涨但大量token对决策的贡献趋近于零。信息论里这叫“冗余信息”。一个智能体如果对冗余信息不做任何筛选它的效率必然被这些背景噪音拖垮。我原来一直有个错觉上下文越长模型越“懂”用户。后来才知道所谓“懂”很大程度是靠模型在长文本里翻找关键信息而不是它真的理解了所有细节。一旦上下文超过某个长度模型还会出现“注意力分散”的问题——关键信息被淹没回答反而变差。也就是说长上下文不只是慢和贵它还可能让准确率下降属于典型的负收益堆积。1.2 云端往返和上下文预填充才是延迟的大头很多人以为智能体响应慢是生成token太慢其实在多数真实场景里模型“生成”的时间根本不是大头。我拆过一份端到端延迟报告一个典型的多步工具调用请求总耗时大概4秒分布大概是这样的网络往返两次云端调用每次约300到500毫秒合计约1秒。上下文预填充系统提示词加历史对话加工具返回一次可能输入5000个token预填充耗时接近1.5秒。推理生成模型输出最终答案可能需要600到900毫秒。其他开销框架排队、工具调度、结果校验大约500到800毫秒。看到没有真正花在“思考”上的时间不到四分之一剩下的全是信息搬运。而本地小模型恰好可以同时解决信息搬运和信息冗余两个问题本地推理没有网络排队把输入压缩成很小的结构化状态之后无论本地还是云端预填充的时间都会大幅缩短。这也是为什么我后来看到那篇信息论视角的研究时会有一种“原来如此”的感觉。他们给了一个很简洁的判断智能体本质上是一个信息处理系统优化的目标不是让模型变得更大而是让系统在“保留决策所需信息”和“减少不必要信息传输”之间找到最优平衡。2. 信息论视角下的智能体设计从“塞满上下文”到“只传关键状态”2.1 智能体是一条感知-决策-行动的信息管道把智能体抽象成一条信息管道是我觉得那篇研究里最有价值的视角。用户输入、工具返回、环境状态这些都是“感知信息”模型内部推理是“决策”调用工具、生成回复、执行动作是“行动”。整条链路跑起来本质上就是信息不断被采集、传递、变换和消耗的过程。传统设计的问题在于我们习惯把感知信息原封不动地喂给决策模块也就是让大模型阅读所有内容。这在信息论里等于让决策端承受全部输入熵把所有不确定性都留给模型去处理。而更合理的设计是在感知和决策之间加一个“信息压缩”层把原始信息转换成决策真正需要的低维状态。这就好比人眼每秒接收的视觉数据超过千万比特但大脑真正用于判断“前面有没有障碍物”的信息只有几百比特。我们不会把所有像素都传给大脑的决策中枢而是先做特征提取。把这个思想落到智能体系统里就是让本地小模型担任“特征提取器”和“信息压缩器”把原始对话和历史工具结果转成一小段结构化JSON只把这段JSON交给云端大模型。云端模型不需要再面对长篇累牍的原始信息只需要基于压缩状态做高难度决策。2.2 信息瓶颈用最小的信息量保住最多的决策相关性那篇研究里反复出现“信息瓶颈”这个术语。通俗来说信息瓶颈思想是我们希望找到一个压缩表示Z让Z和任务目标Y之间的互信息尽量大同时让Z和原始输入X之间的互信息尽量小。翻译成人话就是压缩表示要丢掉那些跟任务无关的细节但保留所有对决策有用的关键信息。在智能体系统里本地小模型就是信息瓶颈的编码器。它把原始对话X压缩成结构化状态Z目标是让Z包含用户意图、关键槽位、必要的上下文摘要、工具调用参数而不包含废话、重复描述、过期信息、无关闲聊。衡量这个编码器好不好不只看压缩率更看压缩后信息是否足以支撑下游决策。我实测的一个体感同样一个“改签机票”任务原来发给云端大模型的完整上下文约4200个token经过本地小模型压缩后发给云端的上下文只有大约450个token信息量却覆盖了用户原始需求、出发地、目的地、时间、会员等级、旧订单号。下游模型只用450个token就能做出和原来准确率几乎相同的决策。说白了你帮大模型把作业里的干扰项都划掉了它当然能做得又快又稳。2.3 “5倍性能”是怎么测出来的延迟和吞吐两本账这里要解释清楚“5倍性能”到底指什么。只提升10%不算5倍但我实际测试中简单任务确实达到了5倍以上的提升。我做了一个基准测试集包含2000条经过脱敏处理的真实用户请求主要场景是“查询信息”“简单工具调用”“业务规则判断”。对比指标是端到端延迟和系统吞吐量。老架构全云端大模型的平均端到端延迟大约是3.8秒其中预填充和网络往返占去了约2.5秒。新架构里约65%的请求被本地小模型直接消化这些请求的平均延迟降到了0.7秒左右剩下35%需要上报云端的复杂请求因为上下文被压缩了平均延迟从3.8秒降到了2.1秒。整体混跑下来系统平均延迟约为1.2秒相比原来的3.8秒提升超过3倍。但如果只看“纯本地直接处理”的那部分简单请求延迟从3.8秒降到0.7秒就是5倍多的提升。系统的吞吐量也很有意思原架构单节点每秒最多处理约2.2个请求新架构单节点每秒能处理约10个简单请求因为本地模型不需要排队等远程服务。成本方面单次请求平均消耗的云端token下降了约85%加上云端调用次数减少了60%整体推理成本大概降了一个数量级。所以标题里“5倍性能成本极低”不是空话只是需要说明这是针对“本地可处理的那部分任务”而言不是所有任务都能跑出这个倍数。3. 复现这套设计时我的具体做法和关键决策3.1 整体架构一个本地小模型承担三个职责真正落地时我把本地小模型设计成“一拖三”它同时是信息压缩器、路由判断器和简单任务执行器。这三个职责不能拆成三个模型来做否则延迟和内存都受不了。7B量级的模型在4-bit量化后同时跑这三个任务完全够用。整个请求流程是这样的用户输入到达系统先拼上系统时间、用户信息、当前会话摘要。本地小模型生成一个结构化决策包包含意图、槽位、任务摘要、所需工具列表、置信度分数、决策熵。如果决策熵低于阈值且本地模型生成的结果能通过规则校验就直接返回答案请求结束。如果决策熵超过阈值系统会先调用必要的工具获取信息然后把压缩后的决策包和信息片段发给云端大模型。云端大模型完成复杂推理后返回结果本地再做一个合法性校验再返回给用户。这里有一个容易忽略的点本地小模型不是“尽可能多干活”而是“先判断自己能不能干好”。很多失败案例就是小模型硬扛它不擅长的任务导致准确率崩盘。所以路由判断和信息压缩比“直接回答”更重要。3.2 本地模型选型和量化我为什么选7B4-bit实验阶段我试过从1B到13B的好几个开源指令模型。结论是1B到3B的模型做信息抽取太容易丢槽位压缩结果不靠谱13B模型精度更好但FP16下显存占用接近26GB普通消费级显卡直接劝退。最后落在7B量级用4-bit量化部署显存占用大概5GB左右普通24GB显卡毫无压力甚至可以在部分16GB显卡上运行。量化对信息抽取能力的影响其实很小。我做了一组A/B测试同一个模型FP16和4-bit量化版本在同一批压缩任务上的槽位准确率只差了0.6个百分点可以忽略。但推理速度和内存占用差别巨大。如果你只有CPU建议选择更小的3B模型并配合一些加速方案延迟也能控制在可接受范围内。部署层面我推荐把模型导出成GGUF格式再用支持这种格式的本地推理引擎加载。这样内存占用低还自带缓存和批处理功能。推理服务可以暴露一个标准的HTTP接口内部业务代码完全不用关心模型跑在哪里。3.3 用信息熵做路由阈值怎么定才不容易翻车路由是整个系统里最核心的决策点。如果阈值太松本地模型乱答一气如果阈值太紧所有请求都上报云端省钱和省时都无从谈起。我没有单纯用模型输出的“置信度”而是用了信息熵来量化模型的不确定性。具体做法是本地小模型在输出最终决策时会同时输出各个意图类别的概率分布。我计算这个分布的标准化熵H -Σ(p_i × log p_i) / log N其中N是意图类别的数量p_i是第i个类别的概率。熵值越接近1说明模型越犹豫越接近0说明模型越笃定。我花了一天时间在一批验证样本上做了一个小网格搜索最终确定了一个三层策略熵值低于0.6本地直接处理。熵值在0.6到0.85之间先尝试用规则和工具补充信息再做一次判断。熵值高于0.85直接上报云端大模型不冒险。这个方案比直接用softmax概率靠谱很多因为有些小模型的概率输出会过度自信概率百分百的答案也可能是错的但多类别分布熵能把这种“看似自信、其实不确定”的情况暴露出来。3.4 信息压缩模板逼着本地模型只吐出关键字段为了让本地小模型稳定输出结构化决策包我给提示词设计了一个固定的“信息压缩模板”。模板大致长这样请根据以下信息输出JSON决策包 - 用户原始请求{用户输入} - 当前会话摘要{最近几轮摘要} - 工具返回结果{最近一次工具返回的关键片段} - 当前时间{系统时间} 输出字段 - intent用户意图分类 - slots关键实体/参数用JSON存储 - task_summary50字以内的任务摘要 - required_tools可能需要的工具列表 - confidence0到1之间的置信度 - entropy你对自己判断的不确定度0到1这个模板看起来简单但有两个细节很关键。第一必须把“当前时间”喂进去否则大模型和小模型都会把“明天”“周五”等相对时间解析错。我在踩坑测试里发现晚上11点50分用户说“明天提醒我”本地模型很容易解析成当天日期加上系统时间强制约束后错误率直接下降了一半。第二输出的字段必须是JSON并且字段名固定这样下游解析不容易出错。云端大模型拿到这个决策包后还要能看懂。我在发给云端的系统提示词里明确说不要使用本提示词之外的原始对话内容只基于JSON决策包做推理。这一步很关键否则云端模型还是会尝试从上下文里找更多信息上下文压缩的效果就大打折扣。4. 实测结果与踩坑记录性能数字背后的真实代价4.1 成本、延迟、准确率的量化对比改造后的系统在同一批测试集上跑了大概一周我汇总了一份对比表这里分享给大家参考指标全云端大模型方案本地云端混合方案变化幅度简单任务端到端延迟3.8秒0.7秒提升约5.4倍复杂任务端到端延迟3.8秒2.1秒提升约45%平均云端token消耗每请求约5200 token每请求约780 token下降约85%云端调用次数所有请求约35%请求下降约65%本地直接处理比例0%约65%新增端到端任务成功率94.2%92.8%下降约1.4%看到成功率实际下降时我心里是有些犹豫的。但仔细分析后那1.4个百分点的损失几乎都出现在信息压缩阶段丢掉了某些关键约束条件比如用户说过“不要发短信”这类容易被忽略的偏好。这类问题可以通过调整压缩模板、增加偏好字段来修复并不是本地模型能力不够导致的。另外云端调用量下降65%但云端费用下降远不止65%因为剩余复杂请求的输入token也压缩了。最后看账单混合方案的推理总成本大约是原来的8%到10%这个节省幅度在规模化场景下非常显著。4.2 踩坑一上下文截断把关键指令截没了第一个让我头疼的问题出在信息压缩阶段。最初我为了控制token长度把本地小模型的输入压缩到“最近两轮对话当前请求”。看似合理结果用户之前设置的偏好、约束、上下文信息全被截掉了。比如用户第一轮说“帮我订机票尽量选靠窗的”第二轮补充说“时间改成后天下午”但本地模型只看到第二轮以为用户没有偏好压缩结果里就丢了“靠窗”这个槽位。后来我改进了输入组织方式。不再按“最近几轮对话”裁剪而是把每一轮历史对话都先让本地小模型抽取出“用户偏好”“未完成任务”“关键事实”三类结构化信息随请求一起存入会话状态。等到新请求进来时本地模型读到的是“经过压缩的历史记忆”而不是原始对话轮次。这样丢信息的概率大幅降低输入长度也从原来的每轮200个token压缩到整个历史摘要约150个token。这个经验的教训是上下文压缩不是简单截断而是要把历史信息预先结构化。对着一份杂乱对话日志硬截还不如一开始就建立一个“结构化记忆库”。4.3 踩坑二本地小模型会出现“过度自信”信息熵路由帮我过滤掉了很多真正不确定的请求但另一个现象反复出现本地小模型在某些样本上输出熵很低看起来很有把握结果答案却是错的。我后来分析了一下发现这跟模型输出的概率校准有关。小模型的softmax分布经常过于尖锐它在熟悉的数据分布上会给出非常高的置信度一旦输入偏离训练分布自信程度也不会立刻下降。为了治这个毛病我在最终回答前加了一层规则校验。本地模型输出无论多自信都必须先通过一个轻量校验器检查必填槽位是否齐全、时间解析是否合理、工具参数是否符合类型要求。如果校验不通过即使熵值再低也强制上报云端。加上这层校验之后端到端准确率从91.5%恢复到92.8%比较接近云端方案的水平。这里我想额外提醒一句信息熵是很有用的信号但不能信仰它。它应该和规则校验、工具返回结果交叉验证才能构成一个可信的路由决策。4.4 踩坑三本地模型硬扛复杂推理得不偿失有一次我图省事把“合同条款合规判断”这个任务也放进本地模型直接处理的列表里。第一次测试成功率只有八成左右而且失败案例全是那种需要逐条对比条款、进行多轮确认的场景。本地模型虽然能压缩信息但它百科式知识和逻辑链条的容量上限摆在那里强行让它处理复杂推理只会让整个系统的准确率变成一个不稳定的定时炸弹。所以后来我在路由逻辑里加了“领域黑名单”本地模型永远不直接处理数学计算、合同审核、法律咨询、代码生成这类高复杂度任务。遇到这些领域本地模型只做“意图识别和上下文压缩”真正的推理判断全部交给云端大模型。这样虽然牺牲了一部分“本地直答率”但换来的是整体稳定性和可预期性。我一直认为智能体系统的第一目标是可靠其次才是省钱。5. 这套方法适合什么场景以及我认为不必硬套的场景5.1 最合适的场景高频、结构性强、工具调用固定这套设计最适合那些业务模式非常固定的智能体场景。比如售后客服用户报问题系统查订单、判断常见原因、回复处理结果。工单分类和分流把不同业务请求自动分给不同后端流程。内部数据查询助手用户问“上个月销售额是多少”系统查库、算聚合、返回结果。定时任务和个人助理提醒、待办、日历查询。信息收集型对话先了解用户需求再调用工具补全信息最后生成确认话术。这些场景有一个共同特点任务类型有限工具调用模式固定输入输出结构高度重复。本地小模型只需要记住有限的意图和工具规则就够了信息压缩的容错率很高即使偶尔漏掉一个次要参数规则校验也能兜住。5.2 完全不适合的场景长尾开放域和高专业门槛我也要泼盆冷水。如果任务是开放域的比如“帮我想一个营销方案”“帮我分析这份法律合同的漏洞”“给这个产品做一套品牌故事”这类任务的答案高度依赖广泛知识储备和深层的语义理解本地小模型即使做了信息压缩压缩过程本身就会丢失大量有价值的背景知识。系统再高效也扛不住“答案质量差”这个硬伤。我的处理方式是让本地小模型在遇到这类问题时直接识别出来并整包转发给云端大模型并且不强行做压缩。注意这时候本地模型只做“分类”不做“压缩”。既然云端需要大量背景知识那就让它看原始上下文没必要用小模型的风险换token。5.3 后续可以扩展的方向在我自己的系统上下一步准备做两件事。第一是把“本地小模型”升级成“多级模型梯队”用一个3B模型做最快校验一个7B模型做信息压缩和简单任务一个云端大模型做复杂推理。这样大部分请求会先被3B模型拦截7B模型只在需要更精细解析时介入整体延迟和成本还能进一步优化。第二是让路由策略从“静态阈值”变成“自适应策略”。现在信息熵阈值是手工调的后续我打算用强化学习或简单的在线学习根据每个任务的实时反馈动态调整阈值。比如某个用户的请求历史表明他很喜欢多轮追问那么路由可以适当偏向云端处理如果用户只做简单查询就尽量留在本地。这种个性化路由本质上也是在优化“决策所需信息”的传递效率和信息论视角很契合。最后再分享一个小经验。这套系统上线后不要只盯着成本报表还要定期回看本地小模型的“决策熵分布”。如果发现本地处理请求的熵值普遍偏高说明模型对当前业务数据不熟悉要补充微调数据如果发现熵值普遍很低但准确率下降说明规则校验层出了问题。这两个信号可以帮助你在模型效果和成本之间持续找到更合适的平衡点而不用等到用户投诉才发现问题。