聊到 AI Agent 降本很多团队的第一反应是换便宜的模型。但我在实际项目里发现真正把成本打下来的从来不是单纯换模型而是把整个技术栈重新梳理一遍再根据不同推理请求的特征设计对应的服务模式。过去一年我前后参与了好几个 AI Agent 项目的落地有客服场景、营销内容生成也有企业内部知识库问答。它们有个共性Demo 阶段效果都很惊艳一上线跑真实流量成本立刻失控。一个看似简单的用户问题Agent 可能需要调用 6 到 10 次大模型推理每次还要携带完整的上下文和工具返回结果账单就这么不知不觉翻了好几倍。这篇文章不聊论文也不讲概念就把我在这些项目里验证过、踩过坑的东西拿出来说说。核心是两个骨架五层技术栈和三种推理服务。把这两个骨架搭好AI Agent 的降本路径基本就清晰了。无论你是技术负责人、后端开发还是刚接触大模型应用的产品经理这篇文章应该都能给你一些可以直接拿去用的思路。1. AI Agent 的成本流失点先从账单看清钱花在哪降本的前提是知道钱到底花在哪。我见过不少团队一上来就优化模型单价结果账单没降多少。原因很简单AI Agent 的成本结构跟传统软件完全不一样它不是一个固定开发成本而是一个持续运行的边际成本。传统软件一个请求可能只花几毫秒的 CPUAI Agent 一个请求却可能在几秒钟内烧掉几十万 token。1.1 Token 费用被低估的输出消耗绝大多数人对 token 费用的理解都停留在输入便宜、输出贵这个层面但实际上 Agent 场景下的输出消耗比普通对话严重得多。普通聊天应用一次请求的输出可能只有几百 token但 Agent 在推理过程中会生成思考过程、工具调用参数、结构化输出这些全部算输出 token。我实测过一个多步 ReAct 循环里单步调用的输出 token 平均在 300 到 600 之间五步下来光是输出就可能超过 2000 token而输出单价通常是输入单价的 3 到 4 倍这一块的费用很容易被低估。更隐蔽的是上下文累积消耗。Agent 每执行一步都需要把之前的对话历史、工具返回结果、数据库查询内容重新塞给模型。很多团队只关注当前这一次调用的 token没有意识到每多走一步后面的每一步都在为前面所有步骤重复买单。上下文从 2K 涨到 8K最终成本不是线性增长而是按每一步的输入量逐轮叠加。1.2 隐性成本重复推理、无效轮次与闲置算力除了 token 费用还有三类隐性成本是账单上不会单独列出来的。第一类是重复推理用户问同一个问题Agent 每次都要重新规划、重新调用工具明明上一次的结果可以复用却没有人做缓存。第二类是无效轮次Agent 在工具返回异常或者模型理解偏差时会陷入重试-失败-再重试的循环这种无效推理不仅浪费时间还在白白烧钱。第三类是闲置算力。一个常见场景团队为了保障高峰期体验按峰值 QPS 部署了 GPU 集群但凌晨到早上的流量只有峰值的十分之一卡还是那几张卡账单还是那张账单。我在一个项目里做过统计GPU 平均利用率不到 15%这意味着 85% 的算力成本在空转。这些隐性成本加起来往往比明面上的 token 费用还要高但如果不做细粒度的成本拆解你根本意识不到它们的存在。2. 五层技术栈逐层拆解每一层都有可省的钱把 AI Agent 整体拆开看我会把它分成五层模型层、推理服务层、Agent 编排层、应用集成层、基础设施层。这五层不是严格的分层架构标准而是我看成本账单时的分析框架。每一层都有对应的降本手段而且往往是互相联动的。2.1 模型层分级用模型比追求最强模型更省钱模型层最容易理解的省钱方式就是别让最强的模型干所有的事。我在客服项目里做了一个很简单的路由先让一个 7B 的开源模型做意图分类和实体抽取判断这个问题是简单咨询还是复杂投诉。简单咨询直接交给 7B 模型生成答案只有识别出复杂意图才路由到 70B 级或旗舰商用模型。最终大约 60% 的请求留在了小模型上token 成本直接降了四成而用户体验几乎没有变化因为那些简单问题本来就不需要多强的推理能力。除了模型分级量化也是一个很实用的手段。我们在自建推理服务上用 AWQ 量化把模型压到 INT4显存占用降了一半左右单卡能承载的并发明显提高吞吐上来了单位 token 的算力成本自然就下去了。这里我要提醒一句量化不是无损的数学计算类任务受影响会比较明显但如果你的 Agent 场景以文本理解和工具调用为主INT8 基本无感可以大胆用。另外提示词瘦身很多人容易忽略。我见过一个项目System Prompt 写了 1800 多个 token里面有一大段是给产品经理看的背景说明模型根本不需要。我帮他们精简到 400 token单次调用输入成本直接降了将近八成。如果每天有上百万次调用这就是一笔非常可观的费用。花半天时间做一次全链路提示词审计性价比极高。2.2 推理服务与算力层吞吐效率决定 GPU 账单模型选好之后能不能高效地跑起来是这一层要解决的问题。很多团队第一次自建推理服务时用的是最原始的部署方式模型加载到 GPU请求一个一个排队处理。这种方式吞吐极低GPU 利用率惨不忍睹。后来我们切换到支持连续批处理Continuous Batching的推理框架把多个请求的动态 token 拼在一个批次里计算同样的资源下吞吐提升了大概 8 到 10 倍这个优化比换任何模型都来得直接。长上下文场景还需要考虑 Prefill 和 Decode 的负载差异。Prefill 阶段是密集计算显存带宽吃得凶Decode 阶段是逐个 token 生成算力利用率低。两者混在一起时长上下文的 Prefill 请求会把整卡拖慢。如果业务里有大量 32K 以上长上下文的 Agent 对话可以考虑把 Prefill 和 Decode 拆成独立服务各自弹性伸缩这块优化在长上下文场景下的收益比较可观。当然如果上下文普遍在 4K 以内这个方案的意义不大不用盲目跟风。GPU 选型也要说一句。推理任务真的不需要一上来就上 H 系列训练卡A10、L40S、4090 这类卡在纯推理场景的性价比反而更好。我见过有的团队把训练集群直接拿来跑推理成本高出好几倍性能却没强多少。按自己的 QPS、并发数和模型规模算一下显存和吞吐需求再决定卡型这是最基本的账。2.3 Agent 编排层减少推理次数比降低单价更关键模型单价降了 50%但如果调用次数从 4 次涨到 8 次总成本还是一样。所以 Agent 编排层的核心目标是减少无效推理。这一层最容易出效果的是三件事记忆分层、上下文压缩、规划缓存。记忆分层的意思是把长期记忆、短期记忆和工作记忆分开。很多 Agent 框架默认把所有记忆全部塞进上下文用户聊了半小时每轮都要带着半小时前的原始记录。正确的做法是用向量库存长期记忆只把与当前问题最相关的一小段召回短期记忆可以做摘要化让模型自己把上一阶段的对话总结成几句话再塞进上下文。这样上下文长度能控制住每轮调用的输入成本都会下降。上下文压缩则是针对工具返回结果。工具调用返回的数据往往巨大比如数据库查询出来的 500 行记录、搜索引擎返回的 20 条网页摘要不处理就全量放进上下文下一轮调用的输入会变得非常大。我会在工具层做截断和结构化只保留前几条关键结果把长文本压缩成字段摘要。这样模型拿到的信息足够上下文却小了好几倍。规划缓存是我最近比较常用的手段。同一类任务的规划结果其实高度相似比如查天气这个意图Agent 每次都会走识别城市-调用天气接口-整理回复这套步骤。把这个规划模板缓存下来下次直接复用省掉第一轮和最后一轮的两到三次模型调用。我在一个项目里做了这种模板缓存整体调用次数降了大约 25%。2.4 应用集成层工作流固化与异步化应用层最容易犯的错误是把所有业务流程都交给 Agent 自由发挥。自由意味着不可控不可控意味着要多调很多次模型、多兜很多次底。正确的做法是区分确定性流程和探索性流程。订单查询、物流跟踪这类流程每一步做什么都是明确的完全可以用传统代码写死只在关键节点让模型做实体抽取和语义理解。我做过对比同样一个订单查询请求全 Agent 方案需要调用 6 次模型走固定工作流加小模型抽取的方案只要调用 2 次一次是抽取订单号一次是生成最终回复。用户体验几乎一样成本差了三倍。异步化也是应用层容易忽略的点。很多 Agent 任务其实不需要用户同步等待比如帮我总结一下今天的会议记录生成一份周报这类任务完全可以放进消息队列由后台异步执行。异步的意义在于削峰高峰期的请求不再直接打爆在线推理服务而是排队在夜间或低峰集中处理GPU 资源的使用曲线被抹平了就不用按峰值去预留大量算力。2.5 基础设施层可观测性驱动的成本治理最后一层是基础设施这里最重要的动作是让成本看得见。我们做了一个统一的推理网关所有模型调用都走这个网关每个请求自动打上业务标签按业务线、按功能模块拆分 token 消耗和费用。没有这套体系之前成本高了只能靠猜有了标签之后每个业务的成本变化一目了然哪个功能模块烧钱最多、哪个周上线导致成本飙升都能在几秒钟内定位到。基础设施层的另一个成本点是向量数据库。很多团队的数据量其实只有几十万条却用着分布式的向量库集群这是典型的过度设计。数据量小的时候单机部署加上 HNSW 索引完全够用成本可以降一个数量级。如果数据到了千万级再去考虑分布式方案。存储选型不追新、不追大按数据量和查询 QPS 做适配才是省钱的逻辑。预算告警也是必要的。我们在网关里设置了每日 token 消耗和费用告警超过阈值自动通知。否则等人发现成本异常的时候往往已经烧了好几天的钱了。像这种细碎但必要的机制属于平时感觉不到价值、出事才后悔没早做的典型。3. 三种推理服务模式的选型与落地技术栈的部分解决的是每一层怎么省钱接下来要解决的是不同类型的推理请求该用什么服务模式。在我看来AI Agent 的推理调用可以归为三类实时交互、批量异步、缓存优先。这三种模式对延迟的敏感度不一样对资源的要求不一样降本策略也完全不同。3.1 实时交互推理弹性伸缩与连续批处理实时交互推理对应的是用户正在屏幕上等待的场景比如对话框里那个正在思考的提示。这类请求要求低延迟P95 超过 3 秒用户就会明显不耐烦。它的典型特征是流量波动大白天高峰和深夜低谷可能相差 20 倍但你又不能因为深夜没人用就把服务停掉否则第二天早高峰第一个用户会直接超时。在线推理的核心降本手段是弹性伸缩加上连续批处理。弹性伸缩解决的是低峰期别浪费的问题我们用基于队列长度的自动伸缩策略高峰期扩到 8 个副本低峰期缩到 1 个副本。连续批处理解决的是高峰期同样资源能扛更多请求的吞吐问题。这两件事配合好在线推理服务的 GPU 利用率可以从 15% 提升到 50% 以上成本直接减半。这里要提一个容易被忽略的细节延迟目标不要设得太激进。有的团队把 P95 目标定在 1 秒以内这会导致你必须预留大量冗余算力来应对突发流量。我后来把目标放宽到 P95 3 秒以内同样的业务量GPU 资源需求下降了 40%。用户体验上几乎没有差别但成本是完全不同的量级。别为了一个内部指标跟钱过不去。3.2 批量异步推理错峰利用与抢占式实例批量异步推理对应的是那些不需要立即返回的任务知识库的 embedding 增量更新、批量文档总结、评估集跑分、Agent 生成内容的离线审核。这类请求的特点是延迟不敏感分钟级甚至小时级返回都可以接受。降本的核心就是用便宜的资源去跑这些不着急的任务。我们在云上申请抢占式实例来跑批任务价格通常只有按量付费的 30% 左右运气好的时候甚至更低。代价是实例随时可能被回收所以批任务要做好断点续跑和幂等设计任务拆成小块每个块完成就记录结果回收后从断点继续而不是从头再来。错峰调度也很有用。在线推理服务的高峰在白天批处理任务完全可以放到凌晨执行用夜间的闲置资源。我们在离线任务调度器里加了一个简单的策略优先使用当前空余的抢占式实例如果没有再排队等待避免跟在线服务抢资源。这样 GPU 集群的整体利用率被拉高了单位任务的计算成本降了一大截。3.3 缓存优先轻量推理让大部分请求不经过大模型这是三种模式里最反常识但效果最猛的一种。大部分团队在做 Agent 时默认用户每句话都值得调用一次大模型但实际上高频咨询中大量问题是重复的或者高度相似的。缓存优先的思路就是先想办法让请求不经过大模型。我在客服项目里做了一层语义缓存。用户的问题先转成向量在缓存库里做相似度检索如果找到高相似度的历史问题直接返回当时的答案不再调用任何模型。这个缓存的命中率在我们场景里达到了 30% 到 40%意味着三分之一多的请求是完全零推理成本的。你可能觉得这会导致回复不够灵活但客服场景的高频问题就那几十类用户换着说法问语义向量都能匹配上。语义缓存之外还有一层是用小模型承接。有些请求虽然没有命中缓存但问题很简单比如你们的营业时间是什么退货政策怎么样这类问题用 7B 小模型就能回答得很好完全没必要动用旗舰大模型。在我们的架构里请求经过缓存判断后会再由一个小模型做难度评估简单问题直接小模型回答复杂问题才转大模型。两层过滤之后真正需要走到旗舰大模型的请求只有总量的 30% 左右。这里要特别注意缓存的时效性。如果答案是跟时间、库存、价格相关的动态信息绝不能走缓存否则用户会投诉你给了一个过期的答案。我们的处理方式是给每个缓存答案打上时效标签动态类问题直接跳过缓存层只有静态知识类问题才允许命中。这块的判断逻辑如果做不好缓存省下来的钱会以用户投诉和流失的形式加倍还回去。3.4 三种模式组合的实战配置示例把三种模式放到同一个系统里不是简单的三段式流水线而是按请求特征做动态分流。我画一个我在客服项目里实际用过的分流逻辑。服务模式适用场景典型配置成本特征实时交互推理用户正在等待的对话、复杂推理、多轮任务执行在线 GPU 集群开启连续批处理按队列长度弹性伸缩成本最贵需要精细控制批量异步推理embedding 增量、文档总结、离线审核、评估集跑分抢占式实例 错峰调度任务幂等可断点续跑按量付费的 30% 左右成本缓存优先轻量推理高频重复问答、静态知识咨询、简单意图识别向量库语义缓存 7B 小模型兜底边际成本极低几乎为零一个请求进入系统后先过缓存优先层查语义缓存命中就直接返回。没命中再判断请求是简单还是复杂简单的交给小模型复杂的才进入实时交互推理服务。同时所有不着急的离线任务全部走批量异步推理和在线服务错峰。这套分流逻辑上线后我们整个项目的 token 成本下降了大约 60%GPU 成本下降了大约 40%而用户反馈几乎没有变化。4. 降本效果如何量化一个可复用的成本估算模型光说降了多少钱不够你得有一套能算清楚账的方法才能在项目汇报或预算申请时有底气。这节我给出一个可复用的成本估算模型用公式和案例两件事把 AI Agent 的成本结构算明白。4.1 关键指标定义单次对话成本与 LLM 调用次数第一个指标是单次 LLM 调用的平均成本。它由四个变量决定平均输入 token 数、平均输出 token 数、输入单价、输出单价。计算方法是输入 token 乘以输入单价加上输出 token 乘以输出单价。第二个指标是每个用户问题触发的平均 LLM 调用次数这个数字在 Agent 场景里影响极大通常由 ReAct 步数、工具调用数量和重试机制决定。有了这两个指标单次用户问题的成本就能算出来。我再加一个成本漏斗的概念先把用户问题总量乘以平均 LLM 调用次数得到每天的总调用次数再乘以单次调用平均成本就得到 token 总费用。GPU 成本则单独算GPU 数量乘以单卡每小时价格乘以运行小时数。两者相加就是 AI Agent 每天的运行成本。这套模型的好处是任何优化动作都能对应到公式里的某个变量方便做前后对比。在这里我还要提醒一句如果你的 Agent 有工具调用一定要把工具返回的内容也计入输入 token。很多团队算成本时漏掉这一块实际账单出来比预估高很多就是因为工具的返回结果可能是几千甚至上万 token这些都会成为下一轮调用的输入。4.2 一个客服 Agent 的降本测算案例用一个电商客服 Agent 来跑一遍这个模型。假设日活跃咨询用户 1 万平均每个用户产生 5 轮对话每轮对话触发 2 次 LLM 调用那么每天总调用次数就是 10 万次。单次调用的平均输入是 1500 token平均输出是 300 token按商用旗舰模型的约 2.5 美元每百万输入 token、10 美元每百万输出 token 来算单次调用成本大约是 0.00675 美元一天 token 成本就是 675 美元一个月是 2 万多美元。用前面说的三种推理服务组合来优化第一步加语义缓存命中率 35%这就砍掉了 35% 的调用次数第二步用小模型承接剩余请求中 50% 的简单问题小模型单价只有原来的 5%这部分成本可以忽略第三步把离线任务全部挪到批量异步服务GPU 成本降低 40%。优化后的 token 成本大约是 675 乘以 0.65 再乘以 0.5大概 220 美元一天降幅接近 70%。再加上 GPU 弹性伸缩带来的算力节省整个项目的月度成本可能从 7 万美元降到 2.5 万美元左右。这个案例里的数字是示意性的不同模型、不同渠道的单价差异很大但你只要照这个公式和分流逻辑去套就能得到自己项目里的准确预测。最怕的是不做预测直接上线成本失控时才措手不及。这套方法的价值不是算出一个精确数字而是让你心里有数知道每个优化动作大概能带来多少收益。5. 我在落地中踩过的坑与调整经验理论说再多最后还是要回到实操。这一节分享几个我在实际项目中踩过、改过的坑每一个都是烧过钱之后才明白的。你会发现很多问题不是技术上的难题而是认知上的盲区。5.1 语义缓存命中失效阈值反复调才找到平衡点语义缓存刚上线的时候我把相似度阈值设成了 0.95想着宁可错过也不能错配结果命中率只有 5% 左右几乎没有效果。后来一步步往下调调到 0.85命中率上去了但开始出现错配用户明明问的是 A 商品的退换政策缓存却返回了 B 商品的答案造成了一次不小的客诉。最终我在不同意图类型上用了不同的阈值强意图类问题比如查询订单、退换货政策用 0.93保证准确性闲聊寒暄类问题用 0.85稍微宽松一点问题不大。另外动态信息问题直接跳过缓存层只有静态知识才允许命中。这套调整下来命中率稳定在 35% 左右错配率几乎为零。这个经验说明语义缓存的阈值不是一个通用参数必须结合业务形态反复测、分场景调。5.2 弹性伸缩的冷启动困境保底副本比省到底更重要有一段时间我们把伸缩策略做得非常激进低峰期直接缩到零个副本。结果每到早上 8 点流量开始上涨之前缩到零的服务需要冷启动加载模型、创建推理引擎前后要几分钟第一批用户全部撞上超时。更尴尬的是模型启动本身又需要时间导致虽然扩缩规则触发了但服务在很长一段时间内仍然处于不可用状态。这个问题的解法是给自己留一条底线最低保底一个副本不算缩到零。这个副本在夜间确实有点浪费但它在早高峰保证了服务的可用性。同时我根据一周的历史流量曲线写了一个简单的预测性预热规则在工作日 7 点半提前扩容到两个副本即使 QPS 还没上来也让服务先把模型卡准备好。这个经验就是弹性伸缩的价值在于把浪费降到最低但完全缩到零带来的冷启动成本往往会吃掉你省下来的那点钱。5.3 小模型兜底的质量滑坡置信度机制比硬路由更可靠模型分级刚上线时我们的路由策略很粗暴小模型识别为简单问题就直接让小模型回答结果发现部分回答质量有问题尤其是涉及多个实体关系的咨询小模型偶尔会漏信息或者表述不准确。后来加了一个置信度评估机制小模型除了生成答案还要给自己打一个置信度分数低于阈值时自动转交大模型重新回答。这里的关键是转交不能太频繁否则小模型形同虚设也不能太少否则质量问题会漏到用户端。我们在测试集上反复对比把置信度阈值定在了 0.7 左右大概 82% 的简单问题能自信地回答18% 会转交大模型。最终效果是成本节省了四成左右质量问题基本可控。另外小模型在下游任务上的表现差异很大不要只看榜单分数要拿自己的业务评测集反复测测完再上线。5.4 长上下文场景的 PD 分离别在不适合的场景跟风很多文章都在讲 Prefill 和 Decode 分离但我在实践中发现它并不是所有场景都有效。如果你的业务上下文中位数只有 4K 到 8KPD 分离增加的微服务架构和网络开销反而可能让整体延迟变高、成本变高。只有当业务里长上下文请求占比很高比如动辄 32K 以上的代码分析、长文档 Agent 对话PD 分离才能明显体现出价值。我们在一个代码库分析 Agent 里尝试过 PD 分离效果非常明显长请求的排队时间大幅下降整体吞吐提升了一倍。但在另一个客服项目里同样的方案完全没有必要普通对话的 Prefill 很短分离之后反而多了一层调度开销。所以我想说的是不要为了炫技术而做架构改造先看看你的业务请求分布长上下文占比高再做 PD 分离否则就是给自己找麻烦。踩过这些坑之后我现在做任何 Agent 项目都会在一开始就把成本模型和技术栈分层画出来团队每个成员都清楚一次请求的真实成本是多少哪一层可以在什么条件下做优化。成本治理不是一个单点动作而是一个持续的过程。每次上线新功能我都会顺手看一眼它对成本模型的影响是增加了调用次数还是拉长了上下文、是打高了峰值还是造成了闲置。久而久之团队自然就会形成带着成本意识做 Agent的习惯。
AI Agent 降本实战：五层技术栈与三种推理服务模式
聊到 AI Agent 降本很多团队的第一反应是换便宜的模型。但我在实际项目里发现真正把成本打下来的从来不是单纯换模型而是把整个技术栈重新梳理一遍再根据不同推理请求的特征设计对应的服务模式。过去一年我前后参与了好几个 AI Agent 项目的落地有客服场景、营销内容生成也有企业内部知识库问答。它们有个共性Demo 阶段效果都很惊艳一上线跑真实流量成本立刻失控。一个看似简单的用户问题Agent 可能需要调用 6 到 10 次大模型推理每次还要携带完整的上下文和工具返回结果账单就这么不知不觉翻了好几倍。这篇文章不聊论文也不讲概念就把我在这些项目里验证过、踩过坑的东西拿出来说说。核心是两个骨架五层技术栈和三种推理服务。把这两个骨架搭好AI Agent 的降本路径基本就清晰了。无论你是技术负责人、后端开发还是刚接触大模型应用的产品经理这篇文章应该都能给你一些可以直接拿去用的思路。1. AI Agent 的成本流失点先从账单看清钱花在哪降本的前提是知道钱到底花在哪。我见过不少团队一上来就优化模型单价结果账单没降多少。原因很简单AI Agent 的成本结构跟传统软件完全不一样它不是一个固定开发成本而是一个持续运行的边际成本。传统软件一个请求可能只花几毫秒的 CPUAI Agent 一个请求却可能在几秒钟内烧掉几十万 token。1.1 Token 费用被低估的输出消耗绝大多数人对 token 费用的理解都停留在输入便宜、输出贵这个层面但实际上 Agent 场景下的输出消耗比普通对话严重得多。普通聊天应用一次请求的输出可能只有几百 token但 Agent 在推理过程中会生成思考过程、工具调用参数、结构化输出这些全部算输出 token。我实测过一个多步 ReAct 循环里单步调用的输出 token 平均在 300 到 600 之间五步下来光是输出就可能超过 2000 token而输出单价通常是输入单价的 3 到 4 倍这一块的费用很容易被低估。更隐蔽的是上下文累积消耗。Agent 每执行一步都需要把之前的对话历史、工具返回结果、数据库查询内容重新塞给模型。很多团队只关注当前这一次调用的 token没有意识到每多走一步后面的每一步都在为前面所有步骤重复买单。上下文从 2K 涨到 8K最终成本不是线性增长而是按每一步的输入量逐轮叠加。1.2 隐性成本重复推理、无效轮次与闲置算力除了 token 费用还有三类隐性成本是账单上不会单独列出来的。第一类是重复推理用户问同一个问题Agent 每次都要重新规划、重新调用工具明明上一次的结果可以复用却没有人做缓存。第二类是无效轮次Agent 在工具返回异常或者模型理解偏差时会陷入重试-失败-再重试的循环这种无效推理不仅浪费时间还在白白烧钱。第三类是闲置算力。一个常见场景团队为了保障高峰期体验按峰值 QPS 部署了 GPU 集群但凌晨到早上的流量只有峰值的十分之一卡还是那几张卡账单还是那张账单。我在一个项目里做过统计GPU 平均利用率不到 15%这意味着 85% 的算力成本在空转。这些隐性成本加起来往往比明面上的 token 费用还要高但如果不做细粒度的成本拆解你根本意识不到它们的存在。2. 五层技术栈逐层拆解每一层都有可省的钱把 AI Agent 整体拆开看我会把它分成五层模型层、推理服务层、Agent 编排层、应用集成层、基础设施层。这五层不是严格的分层架构标准而是我看成本账单时的分析框架。每一层都有对应的降本手段而且往往是互相联动的。2.1 模型层分级用模型比追求最强模型更省钱模型层最容易理解的省钱方式就是别让最强的模型干所有的事。我在客服项目里做了一个很简单的路由先让一个 7B 的开源模型做意图分类和实体抽取判断这个问题是简单咨询还是复杂投诉。简单咨询直接交给 7B 模型生成答案只有识别出复杂意图才路由到 70B 级或旗舰商用模型。最终大约 60% 的请求留在了小模型上token 成本直接降了四成而用户体验几乎没有变化因为那些简单问题本来就不需要多强的推理能力。除了模型分级量化也是一个很实用的手段。我们在自建推理服务上用 AWQ 量化把模型压到 INT4显存占用降了一半左右单卡能承载的并发明显提高吞吐上来了单位 token 的算力成本自然就下去了。这里我要提醒一句量化不是无损的数学计算类任务受影响会比较明显但如果你的 Agent 场景以文本理解和工具调用为主INT8 基本无感可以大胆用。另外提示词瘦身很多人容易忽略。我见过一个项目System Prompt 写了 1800 多个 token里面有一大段是给产品经理看的背景说明模型根本不需要。我帮他们精简到 400 token单次调用输入成本直接降了将近八成。如果每天有上百万次调用这就是一笔非常可观的费用。花半天时间做一次全链路提示词审计性价比极高。2.2 推理服务与算力层吞吐效率决定 GPU 账单模型选好之后能不能高效地跑起来是这一层要解决的问题。很多团队第一次自建推理服务时用的是最原始的部署方式模型加载到 GPU请求一个一个排队处理。这种方式吞吐极低GPU 利用率惨不忍睹。后来我们切换到支持连续批处理Continuous Batching的推理框架把多个请求的动态 token 拼在一个批次里计算同样的资源下吞吐提升了大概 8 到 10 倍这个优化比换任何模型都来得直接。长上下文场景还需要考虑 Prefill 和 Decode 的负载差异。Prefill 阶段是密集计算显存带宽吃得凶Decode 阶段是逐个 token 生成算力利用率低。两者混在一起时长上下文的 Prefill 请求会把整卡拖慢。如果业务里有大量 32K 以上长上下文的 Agent 对话可以考虑把 Prefill 和 Decode 拆成独立服务各自弹性伸缩这块优化在长上下文场景下的收益比较可观。当然如果上下文普遍在 4K 以内这个方案的意义不大不用盲目跟风。GPU 选型也要说一句。推理任务真的不需要一上来就上 H 系列训练卡A10、L40S、4090 这类卡在纯推理场景的性价比反而更好。我见过有的团队把训练集群直接拿来跑推理成本高出好几倍性能却没强多少。按自己的 QPS、并发数和模型规模算一下显存和吞吐需求再决定卡型这是最基本的账。2.3 Agent 编排层减少推理次数比降低单价更关键模型单价降了 50%但如果调用次数从 4 次涨到 8 次总成本还是一样。所以 Agent 编排层的核心目标是减少无效推理。这一层最容易出效果的是三件事记忆分层、上下文压缩、规划缓存。记忆分层的意思是把长期记忆、短期记忆和工作记忆分开。很多 Agent 框架默认把所有记忆全部塞进上下文用户聊了半小时每轮都要带着半小时前的原始记录。正确的做法是用向量库存长期记忆只把与当前问题最相关的一小段召回短期记忆可以做摘要化让模型自己把上一阶段的对话总结成几句话再塞进上下文。这样上下文长度能控制住每轮调用的输入成本都会下降。上下文压缩则是针对工具返回结果。工具调用返回的数据往往巨大比如数据库查询出来的 500 行记录、搜索引擎返回的 20 条网页摘要不处理就全量放进上下文下一轮调用的输入会变得非常大。我会在工具层做截断和结构化只保留前几条关键结果把长文本压缩成字段摘要。这样模型拿到的信息足够上下文却小了好几倍。规划缓存是我最近比较常用的手段。同一类任务的规划结果其实高度相似比如查天气这个意图Agent 每次都会走识别城市-调用天气接口-整理回复这套步骤。把这个规划模板缓存下来下次直接复用省掉第一轮和最后一轮的两到三次模型调用。我在一个项目里做了这种模板缓存整体调用次数降了大约 25%。2.4 应用集成层工作流固化与异步化应用层最容易犯的错误是把所有业务流程都交给 Agent 自由发挥。自由意味着不可控不可控意味着要多调很多次模型、多兜很多次底。正确的做法是区分确定性流程和探索性流程。订单查询、物流跟踪这类流程每一步做什么都是明确的完全可以用传统代码写死只在关键节点让模型做实体抽取和语义理解。我做过对比同样一个订单查询请求全 Agent 方案需要调用 6 次模型走固定工作流加小模型抽取的方案只要调用 2 次一次是抽取订单号一次是生成最终回复。用户体验几乎一样成本差了三倍。异步化也是应用层容易忽略的点。很多 Agent 任务其实不需要用户同步等待比如帮我总结一下今天的会议记录生成一份周报这类任务完全可以放进消息队列由后台异步执行。异步的意义在于削峰高峰期的请求不再直接打爆在线推理服务而是排队在夜间或低峰集中处理GPU 资源的使用曲线被抹平了就不用按峰值去预留大量算力。2.5 基础设施层可观测性驱动的成本治理最后一层是基础设施这里最重要的动作是让成本看得见。我们做了一个统一的推理网关所有模型调用都走这个网关每个请求自动打上业务标签按业务线、按功能模块拆分 token 消耗和费用。没有这套体系之前成本高了只能靠猜有了标签之后每个业务的成本变化一目了然哪个功能模块烧钱最多、哪个周上线导致成本飙升都能在几秒钟内定位到。基础设施层的另一个成本点是向量数据库。很多团队的数据量其实只有几十万条却用着分布式的向量库集群这是典型的过度设计。数据量小的时候单机部署加上 HNSW 索引完全够用成本可以降一个数量级。如果数据到了千万级再去考虑分布式方案。存储选型不追新、不追大按数据量和查询 QPS 做适配才是省钱的逻辑。预算告警也是必要的。我们在网关里设置了每日 token 消耗和费用告警超过阈值自动通知。否则等人发现成本异常的时候往往已经烧了好几天的钱了。像这种细碎但必要的机制属于平时感觉不到价值、出事才后悔没早做的典型。3. 三种推理服务模式的选型与落地技术栈的部分解决的是每一层怎么省钱接下来要解决的是不同类型的推理请求该用什么服务模式。在我看来AI Agent 的推理调用可以归为三类实时交互、批量异步、缓存优先。这三种模式对延迟的敏感度不一样对资源的要求不一样降本策略也完全不同。3.1 实时交互推理弹性伸缩与连续批处理实时交互推理对应的是用户正在屏幕上等待的场景比如对话框里那个正在思考的提示。这类请求要求低延迟P95 超过 3 秒用户就会明显不耐烦。它的典型特征是流量波动大白天高峰和深夜低谷可能相差 20 倍但你又不能因为深夜没人用就把服务停掉否则第二天早高峰第一个用户会直接超时。在线推理的核心降本手段是弹性伸缩加上连续批处理。弹性伸缩解决的是低峰期别浪费的问题我们用基于队列长度的自动伸缩策略高峰期扩到 8 个副本低峰期缩到 1 个副本。连续批处理解决的是高峰期同样资源能扛更多请求的吞吐问题。这两件事配合好在线推理服务的 GPU 利用率可以从 15% 提升到 50% 以上成本直接减半。这里要提一个容易被忽略的细节延迟目标不要设得太激进。有的团队把 P95 目标定在 1 秒以内这会导致你必须预留大量冗余算力来应对突发流量。我后来把目标放宽到 P95 3 秒以内同样的业务量GPU 资源需求下降了 40%。用户体验上几乎没有差别但成本是完全不同的量级。别为了一个内部指标跟钱过不去。3.2 批量异步推理错峰利用与抢占式实例批量异步推理对应的是那些不需要立即返回的任务知识库的 embedding 增量更新、批量文档总结、评估集跑分、Agent 生成内容的离线审核。这类请求的特点是延迟不敏感分钟级甚至小时级返回都可以接受。降本的核心就是用便宜的资源去跑这些不着急的任务。我们在云上申请抢占式实例来跑批任务价格通常只有按量付费的 30% 左右运气好的时候甚至更低。代价是实例随时可能被回收所以批任务要做好断点续跑和幂等设计任务拆成小块每个块完成就记录结果回收后从断点继续而不是从头再来。错峰调度也很有用。在线推理服务的高峰在白天批处理任务完全可以放到凌晨执行用夜间的闲置资源。我们在离线任务调度器里加了一个简单的策略优先使用当前空余的抢占式实例如果没有再排队等待避免跟在线服务抢资源。这样 GPU 集群的整体利用率被拉高了单位任务的计算成本降了一大截。3.3 缓存优先轻量推理让大部分请求不经过大模型这是三种模式里最反常识但效果最猛的一种。大部分团队在做 Agent 时默认用户每句话都值得调用一次大模型但实际上高频咨询中大量问题是重复的或者高度相似的。缓存优先的思路就是先想办法让请求不经过大模型。我在客服项目里做了一层语义缓存。用户的问题先转成向量在缓存库里做相似度检索如果找到高相似度的历史问题直接返回当时的答案不再调用任何模型。这个缓存的命中率在我们场景里达到了 30% 到 40%意味着三分之一多的请求是完全零推理成本的。你可能觉得这会导致回复不够灵活但客服场景的高频问题就那几十类用户换着说法问语义向量都能匹配上。语义缓存之外还有一层是用小模型承接。有些请求虽然没有命中缓存但问题很简单比如你们的营业时间是什么退货政策怎么样这类问题用 7B 小模型就能回答得很好完全没必要动用旗舰大模型。在我们的架构里请求经过缓存判断后会再由一个小模型做难度评估简单问题直接小模型回答复杂问题才转大模型。两层过滤之后真正需要走到旗舰大模型的请求只有总量的 30% 左右。这里要特别注意缓存的时效性。如果答案是跟时间、库存、价格相关的动态信息绝不能走缓存否则用户会投诉你给了一个过期的答案。我们的处理方式是给每个缓存答案打上时效标签动态类问题直接跳过缓存层只有静态知识类问题才允许命中。这块的判断逻辑如果做不好缓存省下来的钱会以用户投诉和流失的形式加倍还回去。3.4 三种模式组合的实战配置示例把三种模式放到同一个系统里不是简单的三段式流水线而是按请求特征做动态分流。我画一个我在客服项目里实际用过的分流逻辑。服务模式适用场景典型配置成本特征实时交互推理用户正在等待的对话、复杂推理、多轮任务执行在线 GPU 集群开启连续批处理按队列长度弹性伸缩成本最贵需要精细控制批量异步推理embedding 增量、文档总结、离线审核、评估集跑分抢占式实例 错峰调度任务幂等可断点续跑按量付费的 30% 左右成本缓存优先轻量推理高频重复问答、静态知识咨询、简单意图识别向量库语义缓存 7B 小模型兜底边际成本极低几乎为零一个请求进入系统后先过缓存优先层查语义缓存命中就直接返回。没命中再判断请求是简单还是复杂简单的交给小模型复杂的才进入实时交互推理服务。同时所有不着急的离线任务全部走批量异步推理和在线服务错峰。这套分流逻辑上线后我们整个项目的 token 成本下降了大约 60%GPU 成本下降了大约 40%而用户反馈几乎没有变化。4. 降本效果如何量化一个可复用的成本估算模型光说降了多少钱不够你得有一套能算清楚账的方法才能在项目汇报或预算申请时有底气。这节我给出一个可复用的成本估算模型用公式和案例两件事把 AI Agent 的成本结构算明白。4.1 关键指标定义单次对话成本与 LLM 调用次数第一个指标是单次 LLM 调用的平均成本。它由四个变量决定平均输入 token 数、平均输出 token 数、输入单价、输出单价。计算方法是输入 token 乘以输入单价加上输出 token 乘以输出单价。第二个指标是每个用户问题触发的平均 LLM 调用次数这个数字在 Agent 场景里影响极大通常由 ReAct 步数、工具调用数量和重试机制决定。有了这两个指标单次用户问题的成本就能算出来。我再加一个成本漏斗的概念先把用户问题总量乘以平均 LLM 调用次数得到每天的总调用次数再乘以单次调用平均成本就得到 token 总费用。GPU 成本则单独算GPU 数量乘以单卡每小时价格乘以运行小时数。两者相加就是 AI Agent 每天的运行成本。这套模型的好处是任何优化动作都能对应到公式里的某个变量方便做前后对比。在这里我还要提醒一句如果你的 Agent 有工具调用一定要把工具返回的内容也计入输入 token。很多团队算成本时漏掉这一块实际账单出来比预估高很多就是因为工具的返回结果可能是几千甚至上万 token这些都会成为下一轮调用的输入。4.2 一个客服 Agent 的降本测算案例用一个电商客服 Agent 来跑一遍这个模型。假设日活跃咨询用户 1 万平均每个用户产生 5 轮对话每轮对话触发 2 次 LLM 调用那么每天总调用次数就是 10 万次。单次调用的平均输入是 1500 token平均输出是 300 token按商用旗舰模型的约 2.5 美元每百万输入 token、10 美元每百万输出 token 来算单次调用成本大约是 0.00675 美元一天 token 成本就是 675 美元一个月是 2 万多美元。用前面说的三种推理服务组合来优化第一步加语义缓存命中率 35%这就砍掉了 35% 的调用次数第二步用小模型承接剩余请求中 50% 的简单问题小模型单价只有原来的 5%这部分成本可以忽略第三步把离线任务全部挪到批量异步服务GPU 成本降低 40%。优化后的 token 成本大约是 675 乘以 0.65 再乘以 0.5大概 220 美元一天降幅接近 70%。再加上 GPU 弹性伸缩带来的算力节省整个项目的月度成本可能从 7 万美元降到 2.5 万美元左右。这个案例里的数字是示意性的不同模型、不同渠道的单价差异很大但你只要照这个公式和分流逻辑去套就能得到自己项目里的准确预测。最怕的是不做预测直接上线成本失控时才措手不及。这套方法的价值不是算出一个精确数字而是让你心里有数知道每个优化动作大概能带来多少收益。5. 我在落地中踩过的坑与调整经验理论说再多最后还是要回到实操。这一节分享几个我在实际项目中踩过、改过的坑每一个都是烧过钱之后才明白的。你会发现很多问题不是技术上的难题而是认知上的盲区。5.1 语义缓存命中失效阈值反复调才找到平衡点语义缓存刚上线的时候我把相似度阈值设成了 0.95想着宁可错过也不能错配结果命中率只有 5% 左右几乎没有效果。后来一步步往下调调到 0.85命中率上去了但开始出现错配用户明明问的是 A 商品的退换政策缓存却返回了 B 商品的答案造成了一次不小的客诉。最终我在不同意图类型上用了不同的阈值强意图类问题比如查询订单、退换货政策用 0.93保证准确性闲聊寒暄类问题用 0.85稍微宽松一点问题不大。另外动态信息问题直接跳过缓存层只有静态知识才允许命中。这套调整下来命中率稳定在 35% 左右错配率几乎为零。这个经验说明语义缓存的阈值不是一个通用参数必须结合业务形态反复测、分场景调。5.2 弹性伸缩的冷启动困境保底副本比省到底更重要有一段时间我们把伸缩策略做得非常激进低峰期直接缩到零个副本。结果每到早上 8 点流量开始上涨之前缩到零的服务需要冷启动加载模型、创建推理引擎前后要几分钟第一批用户全部撞上超时。更尴尬的是模型启动本身又需要时间导致虽然扩缩规则触发了但服务在很长一段时间内仍然处于不可用状态。这个问题的解法是给自己留一条底线最低保底一个副本不算缩到零。这个副本在夜间确实有点浪费但它在早高峰保证了服务的可用性。同时我根据一周的历史流量曲线写了一个简单的预测性预热规则在工作日 7 点半提前扩容到两个副本即使 QPS 还没上来也让服务先把模型卡准备好。这个经验就是弹性伸缩的价值在于把浪费降到最低但完全缩到零带来的冷启动成本往往会吃掉你省下来的那点钱。5.3 小模型兜底的质量滑坡置信度机制比硬路由更可靠模型分级刚上线时我们的路由策略很粗暴小模型识别为简单问题就直接让小模型回答结果发现部分回答质量有问题尤其是涉及多个实体关系的咨询小模型偶尔会漏信息或者表述不准确。后来加了一个置信度评估机制小模型除了生成答案还要给自己打一个置信度分数低于阈值时自动转交大模型重新回答。这里的关键是转交不能太频繁否则小模型形同虚设也不能太少否则质量问题会漏到用户端。我们在测试集上反复对比把置信度阈值定在了 0.7 左右大概 82% 的简单问题能自信地回答18% 会转交大模型。最终效果是成本节省了四成左右质量问题基本可控。另外小模型在下游任务上的表现差异很大不要只看榜单分数要拿自己的业务评测集反复测测完再上线。5.4 长上下文场景的 PD 分离别在不适合的场景跟风很多文章都在讲 Prefill 和 Decode 分离但我在实践中发现它并不是所有场景都有效。如果你的业务上下文中位数只有 4K 到 8KPD 分离增加的微服务架构和网络开销反而可能让整体延迟变高、成本变高。只有当业务里长上下文请求占比很高比如动辄 32K 以上的代码分析、长文档 Agent 对话PD 分离才能明显体现出价值。我们在一个代码库分析 Agent 里尝试过 PD 分离效果非常明显长请求的排队时间大幅下降整体吞吐提升了一倍。但在另一个客服项目里同样的方案完全没有必要普通对话的 Prefill 很短分离之后反而多了一层调度开销。所以我想说的是不要为了炫技术而做架构改造先看看你的业务请求分布长上下文占比高再做 PD 分离否则就是给自己找麻烦。踩过这些坑之后我现在做任何 Agent 项目都会在一开始就把成本模型和技术栈分层画出来团队每个成员都清楚一次请求的真实成本是多少哪一层可以在什么条件下做优化。成本治理不是一个单点动作而是一个持续的过程。每次上线新功能我都会顺手看一眼它对成本模型的影响是增加了调用次数还是拉长了上下文、是打高了峰值还是造成了闲置。久而久之团队自然就会形成带着成本意识做 Agent的习惯。