AI应用进入算账阶段：Token成本观测与优化实战

1. 从"模型越多越好"到"每笔调用都要算账"的转折点

过去两年，我参与过好几个企业级 AI 应用的落地项目，从最早的"能跑通就行"，到后来的"多接几个模型试试效果"，再到最近半年频繁被业务方追问"这个月 Token 花了多少、值不值"，整个节奏变化非常明显。标题里说的"模型越接越多、Token 越烧越快"，几乎是所有中大型团队都会经历的阶段：一开始大家兴奋于能力边界，GPT 系、Claude 系、国产开源系、自部署的 Qwen、DeepSeek 全都接进来，路由层越写越复杂；等到账单出来，财务和老板开始问"为什么这个月比上个月翻了三倍"，团队才意识到——AI 应用已经进入"算账"阶段。

这篇文章想聊的不是某个具体框架怎么用，而是把"算账"这件事拆开：Token 到底花在哪里、模型接多了为什么反而更贵、Agent 架构对成本的放大效应、算力约束下怎么配置资源、以及一套可落地的成本观测与优化方法。适合正在做 AI 应用、Agent 开发、或者负责 AI 平台成本的同学参考，也适合刚接触这块、想提前避坑的开发者。全文基于我在实际项目中的观察和踩坑经验，涉及具体数字的地方会说明测算逻辑，你可以按自己团队的单价替换。

先说一个反直觉的结论：模型接得越多，单位请求的平均成本往往不是下降，而是上升。原因后面会详细拆，但核心在于——多模型带来的路由复杂度、重试、降级、缓存失效、以及"反正有便宜模型兜底"的心理，会让调用量在不知不觉中膨胀。算账阶段真正要做的，不是砍模型，而是把每一笔 Token 的去向搞清楚。

2. Token 账单到底被谁吃掉了：拆解成本结构

2.1 输入、输出、缓存三者的价格差异

很多人第一次看账单会懵：明明请求量没涨多少，费用却涨了一大截。这里第一个要搞清楚的是 Token 的计价结构。以主流 API 为例，输入 Token（prompt）和输出 Token（completion）的单价通常差 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 轮）、摘要压缩（把早期对话总结成一段）、以及向量检索召回（只带相关历史）。三种方式各有取舍，滑动窗口实现最简单但可能丢上下文，摘要压缩需要额外调用模型（又是一笔成本），向量召回适合长对话但工程复杂度高。实际项目里我一般用"滑动窗口 + 关键信息抽取"的组合，把用户明确表达的偏好、约束单独存下来，每轮拼回去，比无脑带全量历史省很多。

这张表是我在几个项目里观察到的经验区间，具体比例因业务而异，但系统提示词和工具描述排第一这一点，在 Agent 类应用里几乎是一致的。

3. 模型接多了为什么反而更贵：路由层的隐性成本

3.1 路由策略带来的额外调用

多模型架构的初衷是"用便宜模型处理简单请求，贵模型处理复杂请求"，听起来很合理。但实际落地时，判断"这个请求该用哪个模型"本身就需要成本。常见做法是先用一个轻量模型做意图分类或难度评估，再路由到目标模型。这就意味着每个请求至少多了一次调用，如果分类模型本身也不便宜，或者分类准确率不高导致频繁走错，成本反而上升。

我遇到过一种情况：路由层用一个小模型判断难度，但小模型对"复杂"的判断过于保守，把大量简单请求也路由到了大模型。结果是大模型调用量没降多少，还多付了一层分类费用。后来改成基于规则的预判（比如按输入长度、是否包含代码块、是否涉及多步推理的关键词）先做粗筛，只有边界情况才调用分类模型，整体成本才降下来。

3.2 降级与重试的放大效应

多模型架构通常配有降级链：主模型失败就切备用模型。这个机制在稳定性上是好事，但在成本上是隐患。如果主模型因为限流或超时失败，请求会重试，重试的 Token 照样计费；如果降级到更贵的模型，单次成本还会上升。更麻烦的是，失败请求往往带着完整的上下文重发，一次失败可能等于两三次正常调用的成本。

我的经验是：重试一定要做错误分类。限流（429）和超时适合退避重试，参数错误（400）重试多少次都没用，直接失败更快也更省。另外，重试时可以考虑裁剪上下文，只保留必要部分，而不是原样重发。

3.3 缓存失效的连锁反应

多模型环境下，缓存命中率会明显下降。原因很简单：同一个问题，如果这次路由到 A 模型、下次路由到 B 模型，缓存键就不一样，之前缓存的响应用不上。如果缓存键里还带了模型版本、温度参数等，命中率会更低。

解决办法是把缓存层前置到路由之前，用规范化后的请求内容做键，命中就直接返回，不进入路由。对于确定性要求高的场景（比如 FAQ、固定流程问答），这一步能省下大量重复调用。对于需要模型发挥的场景，缓存意义不大，但也别让缓存键设计得太细碎。

4. Agent 架构下的算力与 Token 双重消耗

4.1 Agent 循环为什么天然费 Token

Agent 和普通问答最大的区别在于循环。一个任务型 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 应用才算真正落地。