上个月做技术复盘时，我们团队盯着监控大屏上那条持续走高的推理成本曲线，一时间没人说话。做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万元（主要成本在混合路由和少量API） |
| 1000万次（约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成本”为口径，按业务线、模型类型、请求类型三个维度每天记录成本数据。这样当某个业务线成本异常上涨时，你能立刻定位是请求量涨了、模型路由出了问题，还是缓存命中率下降了。
这些坑并不是什么高深的问题，但在忙碌的迭代节奏里，特别容易被忽略。每一步踩过的坑，最后都变成了我后面控制成本的经验。降本不是一次性的项目，它应该像调优性能一样，持续迭代、持续观察。下一次当你再看到推理账单突然上涨时，别急着换模型，先从五层技术栈和三种推理服务这张全景图出发，找到真正的冗余点再说。
