AI Agent推理成本优化：从模型路由到混合推理服务的实战指南

上个月做技术复盘时我们团队盯着监控大屏上那条持续走高的推理成本曲线一时间没人说话。做AI Agent快两年我见过太多项目把“降本”简单理解为“换更便宜的模型”结果换来的是重试率飙升、用户体验下降最后账单反而更高。真正管用的思路是先把整条技术栈拆开逐层找消耗点再把推理服务拆成三种形态分别算账。这篇文章把我验证过的方法完整写出来适合正在做Agent应用、月请求量在百万级以上的团队参考。1. 为什么降本失败只盯模型价格忽视五层技术栈的联动1.1 一张Agent请求的隐形账单很多团队做成本分析时习惯拿单次模型调用的价格乘以总调用次数。这套算法在纯问答场景下勉强成立但在AI Agent场景下误差极大。一个Agent请求从来不是一次模型调用。以“帮我查一下上个月销售数据并生成报告”这个任务为例完整链路可能是意图识别、判断是否需要调数据库、检索历史上下文、生成Query、执行查询、根据结果修正Query、再次查询、总结生成报告。这里面每一步都可能消耗token而且前面的错误会成倍放大后面的消耗。比如检索阶段没查准模型就会在思考链里反复兜圈子多冒出30%的token再比如意图识别错误整套流程白跑一遍还要追加一次重试。所以我把这种成本模型称为“概率式账单”实际成本 单次任务成功概率 × 平均重试次数 × 单次调用成本。任何降本方案如果只动最后一项很难见效。1.2 五层技术栈每一层都有钱可省基于这两年的经验我会把AI Agent的技术栈切分成五层逐层去抠成本交互与编排层包含Agent框架、Prompt设计、工具调用逻辑、多轮会话管理。这一层本身不直接消耗GPU但它决定了调用路径的长短。编排得烂一个请求会重复触发同一工具。知识与数据层包含RAG索引、向量库、数据管道、上下文组装。这一层决定模型看到的信息是否精准。检索出来的噪音越多模型推理的token消耗就越大。模型层包含基础模型选型、微调、蒸馏、量化。这一层是单次token成本的总闸门。推理服务层包含部署框架、并发控制、推理服务形态。同一个模型放在不同推理服务里跑单位成本可以差出数倍。基础设施层包含GPU机型、存储、网络、集群调度。这一层决定固定成本和资源利用率。各层不是孤立的。数据层检索质量差模型层就会用更多推理token来弥补模型层选了超大规模模型推理服务层就必须堆更多显卡基础设施层资源利用率低最后摊到每个请求上的成本就高。1.3 成本联动的本质是“冗余消耗”这三年来我观察到的最大误区是把降本当作单点优化。团队买了一个更便宜的模型API结果因为能力下降每个任务多跑两轮总账反超。这是把“单价”当成了“总价”。成本联动的另一面是“冗余消耗”多余的参数不需要的大模型、多余的上下文塞进无关文档、多余的重复推理没命中缓存、多余的空闲算力GPU利用率低于20%。这四类冗余才是真正能把成本拉高的元凶。所以合理的降本路线不是“砍价格”而是“砍冗余”。这篇文章后面提到的所有手段本质上都是对着这四类冗余逐个击破。2. 模型层降本用路由、量化和知识压缩把Token花在刀刃上2.1 建立模型路由让简单任务走小模型我见过最夸张的用法是让一个几百B参数的模型去判断“用户是否在问好”。这类简单意图识别和基础信息抽取任务用7B甚至1.5B模型就足够了。所以模型层的第一个动作是在入口处加一个模型路由。具体做法是先用一个轻量级模型比如4-bit量化的7B模型对请求做快速分类判断任务复杂度。任务被分为三类简单抽取、中等推理、复杂规划。简单任务直接交给小模型回答中等任务交给自建中等模型或者托管API只有复杂规划任务才交给最大模型。要注意的是路由层必须带有“不确定性回退”机制当小模型对分类结果置信度较低时不要硬扛直接升级到大模型处理。我曾经在客服Agent项目里做过一次统计有60%的请求都是查订单状态、退换货进度这类简单查询完全不需要复杂推理。用路由把这一部分引流到量化的7B模型后整体token成本立刻下降了40%。路由层的开销非常小每次注入又不需要多少token整体收益极其可观。2.2 提示词压缩给模型减负而不是堆料模型层第二个容易被忽略的浪费点是上下文塞了太多不相关的内容。很多Agent实现会把整段历史对话、完整工具返回JSON、甚至一整个知识库片段全部丢给模型。模型不得不消耗注意力去过滤噪音token成本自然水涨船高。我的经验是建立一套“提示词压缩流水线”System Prompt固定部分单独缓存不要每轮都重复发送完整、冗长的系统设定。历史消息做摘要超过五轮之前的对话用模型生成摘要而不是把原始消息全部留给孩子。工具返回结果只保留关键字段比如数据库查询返回20个字段只提取模型需要用到的3个字段。检索文档先过滤再拼接先让小模型判断哪些片段与当前问题最相关再拼入上下文。你可以把提示词压缩理解成给一个注意力有限的人准备会议材料只给他看结论和关键论据而不是把整个原始文档拍在他面前。这样既不损失结果质量又能明显少烧token。2.3 微调与蒸馏让“老员工”学会重复劳动如果Agent的某个任务链路非常固定比如“根据销售数据生成周报”与其每次都让大模型从头推理不如把这条链路的输入-输出对整理成数据集用大模型生成的样本去蒸馏一个小模型。蒸馏后的模型在特定任务上的能力接近大模型但推理成本可以低一个量级以上。需要注意微调不是万能的。它只适合封闭域、输入输出模式稳定的任务。对于开放域问答或者需要大量外部知识的场景微调小模型容易一本正经地胡说八道。我的判断标准是如果任务模式在三个月内没有超过20%的变化就值得做蒸馏如果任务每天都在变先别动用路由和缓存顶上去。3. 三种推理服务的成本模型别再只按API单价做决定五层技术栈里推理服务层是最能决定总成本盘子的地方。同一个模型采用不同的服务形态经济模型完全不同。我把推理服务分成三种形态自建推理服务、托管推理服务、端侧轻量推理服务。它们之间不是替代关系而是对应不同业务场景的组合关系。3.1 自建推理服务固定成本换边际成本自建推理服务的典型技术栈是vLLM、SGLang、TensorRT-LLM这类高性能推理框架。用它们跑开源模型配合Continuous Batching连续批处理和PagedAttention能把GPU利用率拉得很高。这种形态的优势是当业务规模稳定且持续增长时边际成本会越来越低。机器折旧、电费、带宽、运维人力属于固定成本一旦摊薄到足够多的token上单位成本可以远低于托管API。它的缺点是门槛和风险都高需要运维GPU集群还要处理模型版本升级、网络调优、故障恢复这些问题。以我自己的项目为例一台8卡A100服务器月成本机器折旧电力基础运维大概在5万元左右。如果这条集群能稳定支撑每月的在线请求算下来单token成本可能只有托管API的四分之一到三分之一。但如果请求量很小GPU大部分时间闲置那自建的每一秒空转都在烧钱。3.2 托管推理服务用弹性换取确定性托管推理服务指直接调用云厂商或模型服务商提供的API按token计费。这个形态的最大价值是零运维和完全弹性。业务量从每天几百次突增到几十万次你不需要提前囤显卡也不需要考虑扩容。它特别适合快速验证新功能、处理流量尖峰、或者那些一周只跑一次的辅助任务。但托管API的单价通常会包含“省心溢价”。另外每次请求都要走外部网络延迟比自建要高并且很难做更细粒度的Prompt缓存或响应缓存。如果你的Agent对延迟敏感比如工单辅助实时生成全走托管API可能体验会打折扣。我的建议是把托管API当作“水位调节器”稳态流量走自建突发流量、新场景探索流量走托管。两边用统一网关路由避免被单一服务商绑死。3.3 端侧轻量推理把成本降到无限接近零端侧轻量推理是一种很不一样的形态把量化到4-bit甚至更小的模型跑在用户的手机、浏览器、或者边缘服务器上。浏览器里可以直接跑WebLLM笔记本上可以用Ollama跑离线模型移动端可以集成TFLite或MNN。这种形态的成本无限接近零没有单次API费用延迟极低隐私性最好因为数据不需要离开设备。但它有明显的能力天花板复杂推理、大量外部知识查询、多步工具调用都做不了。所以我的用法是让端侧模型专干“预处理”的活意图分类、实体抽取、上下文摘要、敏感信息过滤。只有端侧模型判断任务需要云端能力时才去请求云端服务。比如在客服机器人里用户输入“我要退货运费险”端侧模型可以识别出这是一个退款相关意图然后直接触发退款查询工具如果用户说“如果退货会亏多少”端侧模型判断需要综合计算再转到云端大模型。这样大部分请求都被拦截在端侧云端的token消耗量自然就下来了。3.4 三种推理服务的成本对照这里我用一个简化的模型做对比。假设一个Agent系统平均每个任务消耗1000输入token和500输出token不同月调用量下的成本结构大概是这样月调用量托管API全走同级别模型自建GPU集群端侧云混合100万次约15亿token约3-5万元约4-6万元含闲置成本约1-2万元主要成本在混合路由和少量API1000万次约150亿token约30-50万元约12-18万元约5-8万元受限于端侧模型能力这个表格里的数字是基于市面主流模型的中位价格粗算的不同模型和机型会有波动但趋势很明确规模越大自建越划算能力要求越低端侧参与度越高的方案越省钱。最忌讳的是不做拆分把不同场景的请求全部打到一个形态里。3.5 现实落地方案混合编排最实用的架构是三层混合端侧小模型处理简单请求自建推理服务处理稳态中等复杂请求托管API处理突发和超复杂请求。用一个路由网关把三者串起来对用户透明。我落地时会在网关层做动态比例控制当自建集群的GPU利用率超过80%时把超出的流量切到托管API当利用率低于40%时切回来。这样既保证了延迟又把自建集群的闲置浪费降到最低。混合编排不是锦上添花在流量有波动的Agent产品里它是降本的核心手段。4. 落地降本四板斧缓存、批处理、弹性伸缩和代价感知4.1 语义缓存别让模型做重复题Agent场景里大量用户请求是相似的。哪怕是不同用户问“退款多久到账”和“退款几天能到”本质上都在问同一件事。如果每个请求都去调用大模型就是让模型反复做同一道题。我推荐的方案是语义缓存把用户请求做embedding然后在缓存里做相似度检索。当相似度超过阈值比如0.92时直接复用之前的回答不再调模型。在客服Agent场景这个命中率能到30%到40%。这是一个巨大的降本杠杆。缓存不只能缓存最终答案。RAG检索结果、工具返回结果、模型生成的中途计划凡是可复用的计算都可以进缓存。甚至模型输出的长文本摘要也可以做成按用户维度粒度的缓存下次只针对增量部分调用模型。4.2 批处理把非实时请求压缩到低峰期Agent应用里有很多非实时任务日报生成、周报总结、大批量用户数据清洗、午夜数据标签生成。这些任务对延迟完全没有要求完全没必要在白天和在线请求抢计算资源。做法很直接把这些任务放进消息队列在凌晨低峰期统一执行。如果使用托管API很多服务商提供Batch接口费用比实时API便宜不少如果使用自建推理服务夜间正好可以把GPU利用率跑满。批处理不仅降低单价还让在线请求的并发压力小了一截相当于间接改善了高峰期延迟。4.3 弹性伸缩GPU利用率不是越高越好而是越匹配越好很多搞基础设施的同学喜欢看到GPU利用率接近100%但在Agent服务里这不是唯一正确指标。利用率过高往往意味着请求在排队响应变慢甚至超时重试。重试一次的成本完全可能抵消省下的GPU费用。我的经验是把目标利用率设在60%到80%之间超出阈值就扩容低于阈值就缩容。对于自建集群可以做基于KEDA等组件的自动伸缩监控指标可以是队列长度、平均等待时延、GPU利用率。对于托管API弹性是天然自带的不需要额外操作。另外如果对延迟容忍度比较高可以抢些抢占式实例来跑批量推理。抢占式实例的价格通常是按量付费的三分之一甚至更低只要上面跑的都是可重试的批处理任务在中途被回收也没关系重跑就行。4.4 代价感知让Agent自己控制预算这部分比较进阶但效果很好。我通常会在Agent的决策循环里加入一个“代价预算”信号。比如设定每个任务的平均预算为0.1元Agent在每轮决策前先检查当前已消耗成本如果快接近预算就自动选择更经济的策略不再调用昂贵的外部知识API改成基于已有信息生成结论或者不再生成完整的Markdown报告而是给出一段精简摘要。在LangGraph这类框架里这样的逻辑非常好实现。可以把它想象成给Agent一个“钱包”每调用一次工具钱包就少一点钱钱包空了就切换到省电模式。这种机制对用户更透明也逼着我们把每一个工具调用的价值都想清楚。5. 复盘这几个坑我建议你提前绕开5.1 坑一一刀切换小模型有一段时间我们为了降本把线上Agent的模型从大模型切到7B模型结果发现复杂查询的失败率明显上升用户不满运营人员不得不人工介入处理。最后算总账省下的模型费用和增加的人工成本抵消了。换小模型不是不能做但必须配合回退机制。正确姿势是让路由层根据置信度动态切换同时监控“单次成功成本”这个指标而不是只看模型的单价。单次成功成本 总成本 / 成功完成任务数这个指标才反映真实效率。5.2 坑二只算GPU机器钱不算运维人力自建推理服务能省钱但有一个隐性坑运维成本。vLLM升级、GPU驱动打补丁、模型镜像构建、监控告警、容灾恢复这些都非常消耗工程师时间。如果你只有一个两三个人的算法团队自建集群很可能把大家变成运维工程师。我的判断标准是看GPU平均利用率能否稳定超过70%、持续三个月以上。如果只是偶尔有几波流量那托管API更划算。另外自建初期不要贪多先买一台或租一台GPU试运行把延迟、吞吐和故障率都摸清楚再决定要不要扩容。5.3 坑三忽略Token计量差异成本看板不清晰不同服务商对token的计量方式差异很大有的按输入输出分开计价有的把命中缓存的token打折有的对工具调用额外收一笔“函数调用费”。如果只看API单价很容易在账单里发现意料之外的“隐形费用”。一定要在公司内部统一以“千token成本”为口径按业务线、模型类型、请求类型三个维度每天记录成本数据。这样当某个业务线成本异常上涨时你能立刻定位是请求量涨了、模型路由出了问题还是缓存命中率下降了。这些坑并不是什么高深的问题但在忙碌的迭代节奏里特别容易被忽略。每一步踩过的坑最后都变成了我后面控制成本的经验。降本不是一次性的项目它应该像调优性能一样持续迭代、持续观察。下一次当你再看到推理账单突然上涨时别急着换模型先从五层技术栈和三种推理服务这张全景图出发找到真正的冗余点再说。