一条消息最近在技术圈里传开微软内部开始提醒工程师别再把 Token 当免费水龙头一样刷有人一个月烧掉几千美元 Token。起初大家当段子看但做过 AI 应用的人都知道这不是微软一家的问题而是所有把大模型接入真实业务的人都正在逼近的拐点。Token 从开发期的“几分钱”变成生产期的“几千块”往往只需要一次线上并发、一个 Agent 任务、一条没做上下文裁剪的多轮会话。与其说 AI 变贵了不如说我们过去对 AI 消耗的管理还停留在“用完再说”的阶段。真正要解决的不是临时让工程师少用一点而是把 Token 当成一项有预算、有计量、有告警、有优化周期的工程资源来管理。1. 为什么 Token 成本会从“零头”变成“失控项”1.1 按调用次数思考的习惯在 Token 计费下失灵在传统 API 时代一次请求费用基本固定超出免费额度后会有一个相对清晰的单价。我们习惯了用“调用次数”来估算成本一天 1 万次每次几分钱一个月就几千块。但这个模型放到大模型 API 上几乎没什么用。一次请求里的 Token 数量可以相差数十倍模型生成的输出长度由业务逻辑决定输入上下文也由对话历史和工具返回结果决定。同样一个接口用户问一句“你好”和贴一份 5000 字文档成本能差出两个数量级。更麻烦的是大模型不会自动记住前面的对话。它不是把人聊过的内容存在服务器上而是每次请求都把历史记录重新发过来。这意味着多轮对话的次数越多输入 Token 就越大成本不是线性增长而是接近二次增长。很多团队之所以到月底看到账单才震惊就是因为他们还在按“调用次数”做预算而不是按“Token 消耗总量”做预算。1.2 Agent 和自动化循环会把消耗放大到个人级如果只是普通对话成本再高也有限。真正的放大器是 Agent 和自动化任务。Agent 为了完成一个目标会拆成多个步骤每个步骤都调用模型。它要先理解任务、再调用工具、看到工具返回结果、再判断下一步每一步都要把当前上下文重新发送一遍。这时候一个人写一个自动化脚本跑一晚上消耗的 Token 可能比办公室里几十个普通用户一个月还要多。我习惯用一个假设来估算这种放大效应。假设一个 Agent 任务分 10 步每步输入 2 万 Token、输出 2000 Token一次任务就是 22 万 Token。如果这脚本又加上失败重试可能直接翻倍。跑 100 次就是几千万 Token。你不需要精确到每一分钱也能感受到为什么“一个人烧掉几千美元”并不是夸张。这里的底层逻辑是AI 的能力越强我们越倾向于让它“自主完成”而自主完成意味着多次决策、多轮调用、更多试错。传统软件的性能优化关注 CPU、内存、数据库查询现在则要额外关注模型调用次数和 Token 总量。忘掉这一层预算很容易被 Agent 的一夜任务烧穿。1.3 缺少预算意识是比费用本身更严重的问题我见过不少团队花很多精力选模型、调 prompt但从来没有看过 API 返回里的 usage 字段。他们没有成本看板没有每日消耗告警也没有给不同项目、不同用户分配 Token 配额。等到财务拿账单来找人的时候才发现一个误写的循环、一个没有上限的 Agent已经烧掉了几个月的预算。成本失控的第一步常常不是单价太贵而是没有任何计量。这不是说要把每一分钱都盯死而是至少要建立“每次调用都会消耗可量化的 Token”这个意识。对个人开发者如此对团队更是如此。2. 先搞清楚 Token 是怎么算钱的再谈控制2.1 Token 不是字数更不是“字符数”很多初次接触大模型 API 的人会以为 Token 等于英文单词数或中文字数。实际上Token 是模型分词器切分后的最小文本单元。一个英文单词通常会被拆成一个或几个 Token中文的情况更复杂一个汉字可能对应半个到一个 Token不同模型、不同分词算法会给出不同结果。这意味着你很难通过“这篇文章有多少字”来直接估算费用。在实际开发中我建议不要靠推算而是直接看 API 返回的 usage 字段。大多数主流模型服务商在返回结果时都会带上 prompt_tokens、completion_tokens、total_tokens。把它们记录下来才是成本管理的起点。很多线上问题比如同一个系统在相同上下文上来回调用几十次只有靠这些数据才能定位。2.2 输入和输出分开计价长上下文会重复计费Token 计费的另一个特点是输入和输出通常分开计价而且不少模型对输出的定价比输入更高。原因也简单输出是模型实时生成的计算成本更高输入虽然也要计算但可以通过缓存等手段优化。真正的隐藏成本在于每次请求的输入里都会包含你传进去的全部 messages。如果你在一个会话里连续问 20 个问题每问一个新问题系统都会把前面 19 轮的对话历史重新发一遍。这些历史会被重复计费而不是“记住”后只收一次费。所以对话历史越长成本越高很多时候高的不是单次回答而是重复发送的历史。我常用一个例子提醒团队假设前 9 轮对话每轮平均消耗 500 Token第 10 轮请求的输入里已经至少带了 4500 Token 的历史这还没算当前用户新输入的内容。一旦对话到了 50 轮输入成本就完全不可忽视了。2.3 缓存和模型档位是成本差异最大的两个变量不同模型的价格差异可以很大。一个大参数量旗舰模型的价格可能是小型快速模型的几十倍。如果一个任务只需要分类、抽取、改写却每次都走旗舰模型预算很容易失控。更合理的方式是搭建一条模型分级路由简单任务走小模型复杂任务才走大模型同样一个任务如果前缀固定还可以考虑提示词缓存。很多服务商对相同前缀的输入会提供折扣等于把重复的历史信息变成低成本命中。但缓存不是自动生效的。有的平台需要你在请求里显式开启有的缓存有 TTL有的只有命中完全相同的精确前缀才会生效。如果什么都不配置缓存命中率通常很低省钱的预期也会落空。2.4 记录用量是成本管理所有动作的前提如果说这一节只能留下一句话那就是把每次请求的 Token 用量记录下来。最简单的方式是在调用模型后把 usage 写入日志或监控系统。# 常见 SDK 返回结构示例 response client.chat.completions.create( modelyour-model, messagesmessages, max_tokens512 ) usage response.usage log_data { prompt_tokens: usage.prompt_tokens, completion_tokens: usage.completion_tokens, total_tokens: usage.total_tokens, model: response.model, request_id: response.id, timestamp: datetime.now().isoformat(), }这段代码只是一个示例各家的 SDK 字段名可能略有差异但思路完全一样把用量变成一个可聚合、可查询的指标。没有这一步后面所有限额、调优、告警都无从谈起。3. 给 Token 消耗“限额”的四个实操手段3.1 在服务端加硬性额度和配额先区分一个概念限制模型输出长度、调整参数属于“软约束”在网关或业务层规定某个项目本月最多花多少钱、某个用户每天最多调用多少次属于“硬约束”。真正要在生产环境防止预算失控两类都需要但硬约束往往更重要。如果你用的是云厂商的模型服务可以在控制台配置账号级月度预算通知甚至设置支出上限。但只靠服务商控制台通常不够因为你的业务可能有多个项目、多个用户你需要更细的配额管理。常见做法是在自己的后端代理层维护一个配额表对每个用户/项目分配每天的 Token 额度或者每分钟的请求速率。超出后直接返回 429或降级到更便宜的模型。这里的核心原则是限额必须落在服务端不能只在前端按钮上遮遮掩掩。3.2 用参数控制单次请求的“出钱上限”每次调用模型时max_tokens 是一个最直接的限量开关。它限制了模型最多能生成多少个 Token防止因为一个长尾问题生成一篇超长内容。另一个常见参数是 temperature调低可以让输出更稳定也在某种程度上减少无意义的发散至于 stop 参数则可以在模型生成到某个标记时提前结束从而减少不必要的输出。但要注意max_tokens 只限制输出不能限制输入。输入 Context 的控制要靠上下文裁剪、历史压缩、检索只返回必要片段来实现。把这两个维度混在一起是很多团队做了“限额”后仍然超支的原因。3.3 模型分级路由不是所有任务都用最大模型我见过一个很典型的项目所有请求都走同一个旗舰模型只因为最开始测试时它效果最好。等到业务上线发现成本是预算的三倍多。实际上任务之间差异很大判断一段文本的情感、提取几个字段、做简单分类不需要长篇推理用一个尺寸更小、价格低很多的模型就足够只有涉及复杂推理、生成长代码、进行综合判断时才需要更大模型。工程上可以做一个路由表在调用模型前根据规则选择模型档位。下面是一个示意结构具体参数要根据你的模型厂商能力来调整任务类型上下文长度推荐模型档位说明文本分类 / 信息抽取短文本小型快速模型延迟低成本低客服对话 / 上下文相关中长文本中档模型平衡效果与成本复杂推理 / 长代码生成超长上下文旗舰模型高频任务需重点配额路由规则可以写在代码里也可以放到配置中心。关键是先有“模型选择”这个意识而不是所有流量都打到同一个模型上。3.4 缓存与批处理让重复计算变成一次性成本成本优化的另一个方向是减少重复计算。提示词缓存针对的是固定前缀比如系统提示词、工具定义、长文档上下文。如果每次请求都带相同的大段内容只因为后半段不同那么前半段其实可以命中缓存从而以更低价格计费。结果缓存则更直接对于相同或相似的用户输入如果答案可以直接复用就不需要再调用一次模型。另外非实时任务可以使用批量接口。很多服务商的 Batch API 价格明显更低代价是延迟更长。适合的场景包括离线数据清洗、内容审核、报表生成、批量总结。不要把所有实时请求都改成批量要评估业务对延迟的要求。注意缓存不是免费的自动服务。开启缓存前要确认平台的缓存粒度、命中和失效规则否则可能加了存储成本却没有省下 Token 费用。4. 不能只靠“省”还要建立可观测和告警4.1 把用量变成一张可以回看的“账本”前面的代码示例已经把 Token 用量记录下来了但在生产环境里这只是开始。你需要把每次调用的 model、project、user_id、接口名、token 数、耗时、时间戳做成结构化日志或者直接上报到 Prometheus/Grafana 这类监控系统。从经验看最开始不需要做得很复杂三个维度就够每个项目每天消耗多少 Token、每个用户每天消耗多少 Token、每个模型每天消耗多少 Token。等这三个指标能稳定看到再继续往接口和 Prompt 维度拆。比做复杂分析更重要的是让团队形成“先看消耗、再讨论功能”的习惯。4.2 设置分级告警而不是只等月度账单成本告警最好分两层一层是总量告警比如当天消耗达到日预算的 80%、90% 时通知相关负责人另一层是异常增长告警比如某个用户的 Token 消耗在半小时内翻了三倍、某个接口的 completion_tokens 突然远超历史基线。还有一种容易被忽视的告警是“重试风暴”。当某个下游模型服务不稳定时代码里的重试逻辑可能会在短时间内多次调用同一模型Token 消耗瞬间放大。建议对单次任务的重试次数设置上限并观察重试率与 Token 消耗的关系。如果不监控这类异常告警维度再多也会漏掉真正烧钱的那个动作。4.3 每周做一次成本复盘告警只能解决“正在失控”复盘才能解决“为什么会失控”。我建议每周花半小时拉一下本周 Token 消耗的 Top10 接口、Top10 用户逐个看是否合理。比如某个用户可能是因为导入了一个巨大文档每次都要把全文发给模型比如某个 Agent 任务因为工具返回结果太长反复把同一段内容塞进上下文。这些问题听起来不高深但占了大部分成本浪费。复盘时不要只盯着钱也要看单位成本。一个接口虽然消耗高但如果它带来的业务价值也高比如是核心生成接口那就要考虑优化粒度另一个接口消耗不高但天天被无关的批处理任务调用才更需要治理。5. 工程上真正会“烧穿预算”的几个坑5.1 多轮对话历史不裁剪费用随轮数快速上升最经典的崩溃场景就是聊天机器人上线后用户聊了 50 轮系统仍然把全部历史塞进 messages。在这种情况下输入 Token 越来越大每一轮新请求都会把前面所有轮次重复计费。用户可能只是在正常使用但单用户成本已经远远超过预算。处理方式有很多只保留最近的 N 轮对更早的内容做摘要并替换原文本如果历史文本很长把它存到向量数据库检索相关片段再填入而不是全量携带。没有哪个方案适合所有场景但原则是明确的不要无脑携带全部上下文。5.2 Agent 循环和 Tool 返回结果过长一次任务烧出几十次调用的钱Agent 是另一个重灾区。一个 Agent 任务可能包含规划调用、工具调用、读取工具结果、反思下一步、再次调用。如果每一步都传入几百 KB 文本十步下来就是几百万 Token。更隐蔽的是失败重试。工具调用一旦报错代码可能在短时间内重试多次每次重试都重新计费。如果不设最大尝试次数成本会指数级上升。我的建议是给 Agent 设置最大迭代轮数对工具返回结果做截断只保留关键字段对失败任务使用指数退避而不是立即重试在必要的情况下把中间的推理过程切换到更便宜的小模型只在最终决策时使用大模型。5.3 并发和用户量放大你以为只跑了一次实际跑了上千次很多成本事故发生在灰度或上线之后。早期测试只模拟几十个请求掩盖了真实用户并发对 Token 消耗的放大效应。比如一个 AI 问答功能假设平均每次请求消耗 5000 Token每日活跃用户 1000 人人均 10 次每天就是 5000 万 Token。在没有缓存、没有配额、没有路由的情况下月底账单会很难看。所以在功能上线前一定要做成本压测。不需要精确到美元但至少要估算出峰值并发时每分钟 Token 消耗是多少一天的预算能支撑多长时间。否则“免费试用”可能会变成“一夜返贫”。5.4 开发环境和生产环境共用账号额度容易被测试任务抢走最后一个常见坑是开发、测试、生产共用同一个 API Key 或同一个账号。开发者在本地改个 Prompt跑一次全量回归可能就把生产环境的当日配额烧掉一大半。更危险的是如果测试脚本里写了无限循环或重试生产环境什么流量都没进预算就已经被测试任务消耗完了。解决方案很简单每个环境创建独立的 API Key分别设置月度限额开发测试环境使用廉价模型或缩小上下文规模生产环境的 Key 严格加密保存权限最小化。如果成本异常时建议按“用户→接口→上下文→重试→模型档位→缓存”的顺序排查这个链路我在多个项目的故障复盘里都验证过。6. 从“临时限额”到“成本治理框架”6.1 六步法预算、计量、路由、缓存、告警、复盘前面讲了大量细节最终可以把它们收拢成一个框架。我把它叫做 AI Token 成本治理六步法适用于团队也适用于个人开发者升级自己的使用习惯。这六步是预算、计量、路由、缓存、告警、复盘。预算在业务层或控制台为每个项目/用户/环境设置额度计量把每次请求的 usage 记录成结构化日志或指标路由按任务复杂度和上下文长度选择合适的模型档位缓存给固定前缀和重复结果设缓存告警当消耗达到阈值或异常增长时及时通知复盘周期性检查成本 Top 场景优化调用策略。步骤关键动作需要的基础设施预算项目/用户/环境配额月度上限配额系统配置中心计量记录 usage、project、user、model日志系统监控系统路由模型分级、任务分类路由规则模型网关缓存prompt 缓存、结果缓存缓存服务平台缓存开关告警日/周报阈值告警异常检测告警平台消息通知复盘Top 消耗分析优化动作跟盯报表服务周会机制6.2 落地顺序先能看到再限制再优化很多团队拿到这个框架后容易想一口气全做完。我的建议是分三步走。第一步先把计量做起来至少能看到每个项目、每个模型的日消耗第二步加预算和告警让成本不可能在没人知道的情况下失控第三步再去做路由、缓存、Agent 循环优化。顺序很重要因为如果没有计量你做了路由和缓存也说不清优化效果是多少。对于个人开发者前两步可以在一天内完成写一个记录 usage 的日志函数并在服务商控制台设置预算提醒。第三步等你遇到真实成本压力再做也不迟。6.3 适用边界这个方法适合谁不适合谁这套框架适合的是已经接入大模型 API希望稳定控制成本的生产项目正在进行 AI Agent 开发担心自动化任务耗尽的团队以及所有准备把模型能力接入商业产品的个人开发者。它不适合的是只是随手调接口做验证的临时脚本这种场景不需要复杂治理给一个固定预算提醒就够了对延迟极度敏感、不能接受批处理或缓存延迟的实时交互系统需要在成本和体验之间重新取舍纯离线研究、模型效果优先的场景可以适当放宽 Token 消耗限制。成本治理不是要让工程师不敢用 AI而是让每一分 Token 花得清楚并且在失控之前有机制介入。再回到微软那条提示信息。一家卖 AI 基础设施的公司提醒员工别乱刷 Token不是因为他们用不起而是因为他们比任何人都清楚Token 消耗一旦失去度量就会很快失去控制。对技术团队来说这其实是一个值得感谢的信号它把“AI 很便宜”的幻觉提前戳破了。真正成熟的 AI 应用团队不是只在出账单时才想起来看用量而是从第一天就明白Token 不是免费的无限资源而是需要预算、计量、路由、缓存和告警共同管理的工程资源。限额不是目的让每一分 Token 都变成真正有用的产出才是目的。