1. 从模型越多越好到每笔调用都要算账的转折点过去两年我参与过好几个企业级 AI 应用的落地项目从最早的能跑通就行到后来的多接几个模型试试效果再到最近半年频繁被业务方追问这个月 Token 花了多少、值不值整个节奏变化非常明显。标题里说的模型越接越多、Token 越烧越快几乎是所有中大型团队都会经历的阶段一开始大家兴奋于能力边界GPT 系、Claude 系、国产开源系、自部署的 Qwen、DeepSeek 全都接进来路由层越写越复杂等到账单出来财务和老板开始问为什么这个月比上个月翻了三倍团队才意识到——AI 应用已经进入算账阶段。这篇文章想聊的不是某个具体框架怎么用而是把算账这件事拆开Token 到底花在哪里、模型接多了为什么反而更贵、Agent 架构对成本的放大效应、算力约束下怎么配置资源、以及一套可落地的成本观测与优化方法。适合正在做 AI 应用、Agent 开发、或者负责 AI 平台成本的同学参考也适合刚接触这块、想提前避坑的开发者。全文基于我在实际项目中的观察和踩坑经验涉及具体数字的地方会说明测算逻辑你可以按自己团队的单价替换。先说一个反直觉的结论模型接得越多单位请求的平均成本往往不是下降而是上升。原因后面会详细拆但核心在于——多模型带来的路由复杂度、重试、降级、缓存失效、以及反正有便宜模型兜底的心理会让调用量在不知不觉中膨胀。算账阶段真正要做的不是砍模型而是把每一笔 Token 的去向搞清楚。2. Token 账单到底被谁吃掉了拆解成本结构2.1 输入、输出、缓存三者的价格差异很多人第一次看账单会懵明明请求量没涨多少费用却涨了一大截。这里第一个要搞清楚的是 Token 的计价结构。以主流 API 为例输入 Tokenprompt和输出 Tokencompletion的单价通常差 3 到 5 倍输出更贵而缓存命中cache hit的输入 Token 往往只有正常输入价格的 10% 到 25%。这意味着同样一段对话是否命中缓存、输出多长对成本的影响远大于请求次数。我做过一个粗略测算假设某模型输入单价为 1 元/百万 Token输出为 4 元/百万 Token缓存命中输入为 0.2 元/百万 Token。一个典型的 RAG 问答请求系统提示词加检索上下文约 3000 Token 输入输出约 500 Token。如果不命中缓存单次成本约 0.003 0.002 0.005 元如果系统提示词部分命中缓存假设 2000 Token 命中成本降到约 0.0002 0.001 0.002 0.0032 元。看起来差别不大但乘以每天十万次调用一个月就是几万块的差距。提示不同厂商对缓存的定义不一样有的要求前缀完全一致才命中有的支持自动缓存。接入前一定要把计费文档读清楚别想当然。2.2 系统提示词和工具描述是隐形大户Agent 场景下最容易被忽视的成本来源是系统提示词和工具function/tool描述。一个功能完整的 Agent系统提示词加上十几个工具的定义轻松突破 2000 到 4000 Token。这部分内容每次请求都要带上而且往往放在最前面如果缓存策略没做好就是纯纯的重复付费。我见过一个项目工具描述写了 5000 多 Token里面大量重复的字段说明和示例。后来把工具描述精简到 1500 Token同时把不常用的工具做成按需加载单次请求的输入 Token 直接降了六成。工具不是越多越好能按场景动态挂载的就别全量塞进上下文。2.3 多轮对话的上下文膨胀多轮对话是另一个成本黑洞。很多实现是把历史消息全部带上轮次一多输入 Token 线性增长。一个 20 轮的对话如果每轮平均 300 Token到最后一轮输入就接近 6000 Token。如果用户还会来回追问成本会更快累积。常见的处理方式有三种滑动窗口只保留最近 N 轮、摘要压缩把早期对话总结成一段、以及向量检索召回只带相关历史。三种方式各有取舍滑动窗口实现最简单但可能丢上下文摘要压缩需要额外调用模型又是一笔成本向量召回适合长对话但工程复杂度高。实际项目里我一般用滑动窗口 关键信息抽取的组合把用户明确表达的偏好、约束单独存下来每轮拼回去比无脑带全量历史省很多。成本来源典型占比优化手段优化难度系统提示词与工具描述20%~40%精简、按需加载、前缀缓存低多轮历史上下文15%~35%滑动窗口、摘要、检索召回中检索增强的文档片段10%~30%控制 top-k、重排后截断中模型输出15%~30%限制 max_tokens、结构化输出低重试与失败请求5%~15%幂等、退避、错误分类中这张表是我在几个项目里观察到的经验区间具体比例因业务而异但系统提示词和工具描述排第一这一点在 Agent 类应用里几乎是一致的。3. 模型接多了为什么反而更贵路由层的隐性成本3.1 路由策略带来的额外调用多模型架构的初衷是用便宜模型处理简单请求贵模型处理复杂请求听起来很合理。但实际落地时判断这个请求该用哪个模型本身就需要成本。常见做法是先用一个轻量模型做意图分类或难度评估再路由到目标模型。这就意味着每个请求至少多了一次调用如果分类模型本身也不便宜或者分类准确率不高导致频繁走错成本反而上升。我遇到过一种情况路由层用一个小模型判断难度但小模型对复杂的判断过于保守把大量简单请求也路由到了大模型。结果是大模型调用量没降多少还多付了一层分类费用。后来改成基于规则的预判比如按输入长度、是否包含代码块、是否涉及多步推理的关键词先做粗筛只有边界情况才调用分类模型整体成本才降下来。3.2 降级与重试的放大效应多模型架构通常配有降级链主模型失败就切备用模型。这个机制在稳定性上是好事但在成本上是隐患。如果主模型因为限流或超时失败请求会重试重试的 Token 照样计费如果降级到更贵的模型单次成本还会上升。更麻烦的是失败请求往往带着完整的上下文重发一次失败可能等于两三次正常调用的成本。我的经验是重试一定要做错误分类。限流429和超时适合退避重试参数错误400重试多少次都没用直接失败更快也更省。另外重试时可以考虑裁剪上下文只保留必要部分而不是原样重发。3.3 缓存失效的连锁反应多模型环境下缓存命中率会明显下降。原因很简单同一个问题如果这次路由到 A 模型、下次路由到 B 模型缓存键就不一样之前缓存的响应用不上。如果缓存键里还带了模型版本、温度参数等命中率会更低。解决办法是把缓存层前置到路由之前用规范化后的请求内容做键命中就直接返回不进入路由。对于确定性要求高的场景比如 FAQ、固定流程问答这一步能省下大量重复调用。对于需要模型发挥的场景缓存意义不大但也别让缓存键设计得太细碎。4. Agent 架构下的算力与 Token 双重消耗4.1 Agent 循环为什么天然费 TokenAgent 和普通问答最大的区别在于循环。一个任务型 Agent 可能要经历思考—调用工具—观察结果—再思考好几轮每一轮都要把之前的全部上下文重新发给模型。假设一个任务平均 5 轮每轮上下文 3000 Token那这个任务的总输入 Token 就是 15000 左右是单次问答的好几倍。更关键的是Agent 的轮数是不确定的。简单任务 2 轮搞定复杂任务可能 10 轮以上甚至陷入循环。如果没有轮数上限和终止条件成本会失控。我在项目里一般会设置硬性轮数上限比如 8 轮和预算上限单任务 Token 超过阈值就强制收尾并在提示词里明确告诉模型如果信息足够就尽快给出结论。4.2 工具调用的往返开销Agent 调用工具时工具的执行结果要作为新的消息塞回上下文。如果工具返回的内容很长比如一次数据库查询返回几百行这部分内容会显著增加后续每一轮的输入 Token。所以工具设计上要控制返回体积能返回摘要就不返回全量能分页就不一次性拉完能在工具内部做过滤就不把原始数据丢给模型。我见过一个查订单的 Agent工具直接把订单的全部字段和物流轨迹返回一次几千 Token。后来改成只返回状态、金额、预计到达时间三个字段需要详情时再单独查Token 消耗降了一个数量级。4.3 并发场景下的算力约束Agent 扛并发是另一个现实问题。每个 Agent 任务占用模型调用时间较长多轮循环并发一高要么排队要么触发限流。自部署模型的话还要考虑 GPU 显存和吞吐。RTX 3090 这类消费级卡跑 7B 到 14B 模型做推理单卡并发能力有限请求一多延迟就上去了。实际做法通常是分级并发轻量任务走小模型或规则重任务进队列限流。同时给每个用户或每个租户设置配额避免单个用户把资源占满。算力约束下与其追求所有请求都实时响应不如把任务分成实时和异步两类异步任务批量处理能显著提升整体吞吐。5. 一套可落地的 Token 成本观测方案5.1 埋点要埋哪些字段想算账先得有账本。Token 成本观测的第一步是在调用层统一埋点。我建议至少记录这些字段请求 ID、用户/租户 ID、场景标识、模型名称、输入 Token 数、输出 Token 数、缓存命中 Token 数、是否重试、耗时、是否成功。这些字段能支撑后续按场景、按模型、按用户多维分析。埋点位置要放在最靠近模型调用的那一层而不是业务层。因为业务层可能一次请求触发多次模型调用比如 Agent 循环只有调用层的数据才准确。如果用的是统一 SDK 或网关直接在网关层记录最省事。5.2 用聚合指标定位异常有了原始数据接下来是聚合。我常用的几个指标单请求平均 Token、单场景日均 Token、缓存命中率、重试率、单任务平均轮数。这几个指标一旦有异常波动基本能定位到问题。比如某天单请求平均 Token 突然翻倍大概率是系统提示词被改长了或者检索返回的文档变多了缓存命中率下降可能是路由策略变了或者缓存键改了重试率上升通常是上游限流或超时。把这些指标做成看板比事后翻日志高效得多。5.3 按场景分摊成本最有用的一步是按业务场景分摊成本。同样是模型调用智能客服和内部文档问答的成本敏感度完全不同。把 Token 消耗按场景拆开才能判断哪些场景值得优化、哪些场景可以接受。我一般会做一个简单的表格列出每个场景的日均调用量、平均 Token、日均成本、以及业务价值比如转化率、人工替代率。这样在跟业务方沟通时不是笼统地说AI 很贵而是能具体到这个场景每次成本 0.05 元替代了 3 分钟人工很划算那个场景每次 0.5 元但价值不明显建议降级或限制。6. 从算账到省钱几个真正有效的优化动作6.1 提示词瘦身与结构化最直接、见效最快的优化是提示词瘦身。把系统提示词里冗余的礼貌用语、重复的规则、过长的示例砍掉保留核心指令。工具描述同理字段说明能简则简示例给一个就够。我做过对比一个原本 3500 Token 的系统提示词精简到 1200 Token 后效果基本没变成本降了六成多。结构化输出也值得做。让模型返回 JSON 而不是自然语言配合 max_tokens 限制能有效控制输出长度。注意要在提示词里明确字段和格式否则模型可能自由发挥。6.2 分级模型与规则前置不是所有请求都需要大模型。把高频、确定性强的请求用规则或小模型处理只有真正需要推理的才走大模型。比如意图明确的查询、格式转换、简单分类规则或小模型完全够用。这一步的关键是先把请求分类清楚再决定路由而不是反过来。分级之后还要定期复盘小模型处理的那部分准确率是否可接受如果错误率偏高导致用户反复追问反而更贵。所以分级不是一劳永逸要持续看数据。6.3 缓存与批处理缓存前面提过这里补充一点缓存要分层。完全相同的请求走精确缓存语义相近的请求可以考虑语义缓存用向量相似度匹配但语义缓存有误命中风险适合对准确性要求不极端的场景。批处理则适合异步任务把多个请求合并成一次调用如果模型支持能摊薄开销。6.4 给 Agent 设预算和熔断Agent 场景一定要有预算控制。我的做法是给每个任务设一个 Token 预算循环过程中累计消耗超过阈值就强制让模型基于已有信息给出结论或者直接返回任务未完成请补充信息。同时设轮数上限防止死循环。这些限制要写进 Agent 的调度逻辑里不能只靠提示词因为模型不一定听话。7. 算力约束下的资源配置思路7.1 自部署还是调 API 的判断算力约束下第一个决策是自部署还是调 API。判断逻辑其实不复杂如果调用量稳定且大自部署的单位成本可能更低如果调用量波动大、或者对模型能力要求高需要最新的大模型调 API 更灵活。自部署还要考虑运维、显存、并发、模型更新等隐性成本不能只算 GPU 电费。我一般会算一个盈亏平衡点自部署一张卡的成本含折旧、电费、运维分摊除以单卡日均能处理的 Token 量得到自部署的单位成本再和 API 单价对比。低于平衡点用 API高于平衡点考虑自部署。注意这个平衡点会随模型大小、量化方式、并发策略变化要定期重算。7.2 量化与推理优化的取舍自部署时量化是省显存的常用手段。4-bit 量化能让 7B 模型在更小的显存上跑起来但会带来一定的效果损失。我的经验是对准确性要求高的场景用高精度对成本敏感的场景用量化并且一定要做 A/B 对比确认量化后的效果在可接受范围内。推理框架的选择也重要合适的框架能提升吞吐、降低延迟间接降低成本。7.3 算力调度与配额多团队共用算力时配额和调度是必须的。给每个团队或场景分配 Token 配额或 GPU 时长超出就排队或降级。调度上实时任务优先异步任务填谷。这样既能保证关键业务又能把闲置算力利用起来。配额不是限制创新而是让成本可预期避免某个实验把整体预算吃光。8. 我在实际项目里踩过的几个坑第一个坑是只看总账单不看结构。早期我们只盯着月度总费用涨了就慌但不知道涨在哪。后来做了埋点和分摊才发现是某个内部工具的 Agent 在疯狂循环单它一个就占了四成成本。定位到之后加了轮数上限成本立刻回落。第二个坑是缓存键设计太随意。有段时间缓存命中率忽高忽低排查后发现缓存键里带了时间戳和随机 session ID导致几乎每次都 miss。把键改成规范化后的请求内容加模型标识命中率才稳定下来。第三个坑是重试没有分类。一开始所有失败都重试三次结果遇到参数错误时白白多花了两倍 Token。后来按错误码分类只对可恢复错误重试省了不少冤枉钱。第四个坑是工具返回体积失控。前面提过的订单查询就是例子工具设计时图省事返回全量结果上下文膨胀。后来定了规矩工具返回必须控制在 500 Token 以内超出的在工具内部做摘要。这些坑的共同点是都不是模型能力问题而是工程和设计问题。算账阶段真正要改的往往不是换个更便宜的模型而是把调用链路里的浪费堵住。9. 关于算账阶段的一点个人体会走到算账阶段其实是好事。它说明 AI 应用已经从能不能做进入值不值得做的务实区间。我个人的体会是成本优化和效果优化并不矛盾很多优化动作精简提示词、控制上下文、限制轮数本身也让系统更稳定、响应更快。真正需要警惕的是为了省钱而牺牲核心体验那就本末倒置了。如果让我给正在经历这个阶段的团队一个建议先把观测做起来别急着砍。数据会告诉你钱花在哪哪些该省、哪些该花。算账不是为了省钱而省钱而是让每一笔投入都清楚、可控、可解释。做到这一点AI 应用才算真正落地。