前两天有个朋友问我他们在做的一个对话机器人客户那边反馈“也没聊几句怎么账单就快爆了”。我让他把请求日志翻出来一算才发现问题不在并发量也不在模型选型而是他们压根没弄明白大模型 API 是按什么计费的。这个“什么”就是 Token。Token 计费机制直接决定你调用一次大模型接口要花多少钱、一个上下文窗口到底能塞多少字、以及你的业务模型在规模化之后成本曲线是陡还是平。不管是做 AI 应用的开发者、运营同学还是帮客户落地大模型项目的技术负责人只要你在碰大模型 API就必须把这套机制吃得透透的。否则测试阶段风平浪静一旦上了生产、接了真实流量月底账单能让你怀疑人生。这篇文章我从 Token 怎么来、官方按什么规则收费、到一个真实请求如何手动算账、再到生产环境里怎么省钱和避坑一条线给你理顺。全程是实操视角不堆概念看完你就能拿出自己的账单逐条对着看。1. 为什么大模型计费偏偏盯着 Token 这个单位1.1 先搞清楚 Token 是什么别再把“字数”当“Token”很多人有一个误区以为大模型按字符数或者按字数计费。实际上主流大模型 API 全部按 Token 计费Token 是模型处理文本的最小单位。所谓 Tokenization分词就是把一段自然语言切成模型能理解的最小片段。这个片段有时候是一个英文单词有时候是一截单词甚至可能是一个标点。举一个最直观的例子。英文里 AI 通常是一个 Token但 tokenization 这个词会被拆成 token 和 ization 两个 Token。中文没有天然空格分词规则各家略有差异但大体上常见的一个汉字在多数模型里约等于 0.6~1 个 Token三个汉字大概占 1~2 个 Token。这意味着一段 1000 个汉字的 Prompt实际 Token 数往往在 800~1200 之间浮动绝不是你肉眼看到的“1000 字”。为什么要这么计费因为大模型内部处理时注意力机制是按 Token 做矩阵运算的输入的 Token 数越多计算量就越大。你每次请求模型都要把全部输入 Token 读一遍、算一遍生成结果时每一个新 Token 也都是一次前向计算。成本和你交出去的字数、拿回来的字数直接挂钩所以供应商按 Token 收费最公平也最透明。1.2 上下文窗口和 Token 的关系为什么上下文越长越烧钱上下文窗口Context Window是大模型一次能接受的最大 Token 数量包括输入和输出。注意不是只看你这一轮问了什么而是整个对话历史累积的 Token 数。一个经典场景你做一个客服机器人用户聊天记录越滚越长你每次都把全部历史拼进 Prompt 发给模型很快就会发现两个问题一是请求报错“超出上下文长度”二是账单金额直线上升。这里面的计算逻辑是每一次请求的计费 Token 数 全部输入 Token 数 模型生成的输出 Token 数。即使模型一句话都没输出只返回了一个“好的”你每轮发送的输入中仍包含所有历史对话。假设用户聊了 20 轮每轮平均 300 Token那第 20 轮你发的输入就是 20×3006000 Token这个数字会随着对话轮数线性增长。我见过不少团队在生产环境里犯了“无限拼接”的错。有人甚至把知识库全文不分青红皂白往上下文里塞一个 200KB 的文档直接转成几万 Token 塞进去单次请求成本比模型生成文本的贵一个数量级。所以理解上下文窗口的真正含义是整个计费机制里最重要的一环窗口越大单次可处理的内容越多但单次成本也越高两者是直接绑定的。2. 一套请求的计费规则拆解输入、输出、缓存、超额2.1 输入和输出单价不相等这是最容易被忽视的规则几乎所有主流大模型 API 的定价表里输入单价都明显低于输出单价。原因很实在输入 Token 只需要并行计算一次注意力而输出 Token 是逐个生成的每生成一个都在做一次自回归采样计算开销大得多。我记得某个主流模型的定价是输入百万 Token 收费十几块人民币输出百万 Token 收费几十块输出价格大约是输入的 3~4 倍。这个差异直接影响你的成本结构。如果是一个问答产品用户问题短、回答长那钱主要花在输出 Token 上如果是一个文档总结工具每次塞进去一大段文本、输出只要一行结论那钱主要花在输入 Token 上。做成本预算时必须分别估算输入和输出的量级再按各自单价去算不能笼统按“平均 Token 单价”估。很多小伙伴会盯着“百万 Token 多少钱”这个指标但千万要看清是“输入百万 Token”还是“输出百万 Token”。同一家厂商输入和输出价格差出三倍以上是常态不看单位直接对比很容易在选型时做出错误判断。还有一个细节某些服务商对系统提示词System Prompt单独计费或对特殊内容加收处理费这些都要在计价文档里逐字看清。2.2 缓存命中你以为没花钱其实计费规则里还有一条隐藏车道为了让你把同一份知识库、同一套系统提示词反复发送时不再全额计费服务商设计了提示词缓存Prompt Caching。核心机制是如果请求中的前缀 Token 和之前某次请求完全一致这部分命中的 Token 按一个很低的折扣价计费通常只有原价的 10% 左右甚至更低。比如系统提示词 5000 Token每次请求都带着没缓存时每次都是全价有缓存后第二次开始这 5000 Token 很可能只需付零头。但要注意几个触发条件。第一缓存前缀必须完全一致哪怕中间多了一个空格、改了一个字整段前缀就失效了。第二不同服务商对缓存时效有要求有的要求两次请求间隔不超过几分钟超过时间缓存自动过期。第三缓存的 Token 数和未命中的 Token 数在账单里是分开列出的需要辨认识别。这里有一个实际收益案例我之前优化过某智能客服项目系统提示词加历史对话模板占了总输入 Token 的 70%开启缓存后整体 API 成本直接降了近四成。实现方式也不复杂就是把固定不变的内容系统提示词、固定的工具说明放在最前面让变动内容排在后部保证前缀稳定可缓存。相反如果你把用户名、时间戳这些动态内容塞在 Prompt 的最前面缓存就永远无法命中这个隐性损失很多人根本不会注意到。2.3 上下文超出上限怎么办截断策略直接决定你多花多少钱当你的 Prompt 总 Token 超过模型上下文窗口时请求会直接失败这是最直接的结果。但生产中还有另一种情况服务商允许你“超额”请求后台自动截断最前面的内容只把后半段送入模型。这种策略很危险因为你完全没有感知还以为模型在正常回答实际上最早的对话历史已经被丢弃而且这部分的输入 Token 仍然可能被计费具体看服务商规则。我遇到过一个案例某团队做长文档问答文档 4 万 Token模型窗口 8K他们想着“超了就超了模型会自己处理”结果文档后半部分进了上下文前半部分被静默丢弃。用户问“第一章的核心结论是什么”模型一本正经答非所问。排查了半天才发现是截断策略惹的祸更尴尬的是被截掉的那部分 Token 照常计费。所以做长上下文应用时绝不能依赖服务商的默认截断行为一定要在代码里主动控制发送给模型的 Token 数。可以在发送前调用 Tokenizer 计算长度超过阈值就触发摘要、滑动窗口、或者分段处理。控制逻辑掌握在自己手里才不会既丢了内容又丢了钱。3. 动手算账从一个真实请求看 Token 费用的完整计算过程3.1 如何精确获取一段文本的 Token 数而不是靠猜每个模型都有对应的 Tokenizer 工具绝大多数服务商提供在线调试页面或者提供开源的分词器库支持你用 Python 或 JS 本地调用。你在本地算出来的 Token 数和线上计费系统基本一致。这个是做成本管理的基础设施每个团队都必须封装成一个公共方法。我自己常用的做法是维护一个 Python 工具函数输入任意文本输出 Token 数量和计数明细。平时做需求的时候顺手把用户可能输入的最长 Prompt 拿进去跑一遍立刻就能评估单次请求成本。下面是基于常见的开源分词库的示例这里用 OpenAICli100k_base 类似的分词器做演示你在实际项目中换成你用的模型对应的库即可import tiktoken # 按你使用的模型选择对应的编码器 encoder tiktoken.get_encoding(cl100k_base) def count_tokens(text: str) - int: return len(encoder.encode(text)) prompt 请总结以下会议纪要并提炼出三个待办事项... input_tokens count_tokens(prompt) print(f输入 Token 数: {input_tokens})不同模型可能使用不同的分词器有的甚至官方不提供本地库只提供在线 API。这种情况下你在估算阶段可以用近似比例中文按“1 汉字 ≈ 1 Token”做上限预估英文按“1 单词 ≈ 1.3 Token”做粗略算。注意这些只是估算真正上生产前一定要用目标模型对应的标准 Tokenizer 验证过再批量上线。3.2 手把手算一笔完整账单输入、输出、缓存分开算假设你选的模型定价如下仅为举例非真实厂商价格计费项目单价人民币 / 百万 Token输入未命中缓存12 元输入缓存命中1.2 元输出36 元现在用户连续发起两次请求每次请求的系统提示词固定为 2000 Token用户问题平均 500 Token模型回答平均 800 Token。第一次请求输入 2500 Token2000 固定 500 问题全部未命中缓存输出 800 Token。费用为 2500×12/1000000 0.03 元800×36/1000000 0.0288 元合计约 0.0588 元。第二次请求系统提示词命中缓存2000 Token 按缓存价计费用户问题 500 Token 未命中缓存。费率为 2000×1.2/1000000 0.0024 元500×12/1000000 0.006 元输出 800 Token 还是 0.0288 元合计约 0.0372 元。你发现问题没有第二次请求因为有缓存总成本比第一次便宜了约 37%。如果这个系统每天有 100 万次请求缓存开没开一个月下来就是几万块的差额。把这个计算逻辑固化到代码里每次上线新功能前先跑一遍就能在开发阶段预判成本而不是等月底账单出来再追悔莫及。3.3 并发量、限流、Token 耗尽之后会发生什么计费 Word 之外还要掌握 API 返回状态码的含义。常见的是 429 限流和 400 上下文超长但有些服务商在账户余额不足时也会返回特殊错误。这里有一个很容易踩的坑某些平台允许你设置“最大生成 Token 数”一旦回答长度触顶API 返回正常但内容被截断。此时系统会计费完整的已生成 Token而你拿到的是不完整结果用户只会觉得模型“答到一半就停了”。生产环境中必须对这类截断状态做响应识别。很多模型的返回结构里会包含 finish_reason 字段如果它的值是 “length”说明是触达限制而非正常结束。此时你应该主动做后续处理比如把现有内容作为中间结果再做一轮续写而不是直接当成最终答案返回给用户。忽略了这一步你不但白花了钱用户体验还会被打折扣。这个细节我建议你在联调阶段就写进测试用例。4. 生产环境里的省钱实操三种策略帮你把 Token 账单打下来4.1 Prompt 压缩花最少的钱保留最多的语义Prompt 里非必要的内容越少单次输入成本就越低。这听起来像废话但真正执行的人不多。我看过太多项目的 Prompt 里残留着大量冗余注释、重复指令、无效示例。比如一个系统提示词里写了三个功能说明其中两个已经很久没用了却仍然跟随每次请求一起发送白白占用几百上千 Token。我的习惯是每隔一两周做一次 Prompt 体检把当前线上 Prompt 导出逐行审视每句话是否依然有效把输出格式说明用最精简的方式重写把示例从三段合并成一段如果某些工具函数说明只在特定场景才需要就改成动态拼接而不是全局常驻。经过几次压缩同样的功能输入 Token 能减少 30% 以上。还有个经验是能用 10 个 Token 说清的指令绝不用 50 个 Token 写一大段限定语。模型的指令遵循能力并不完全和 Prompt 字数成正比写得再长该不听还是不听但钱是按字数实打实收的。把 Prompt 当作代码一样去精简是每个 AI 应用负责人应有的基本素养。4.2 模型分级与路由让便宜模型先干 80% 的活生产环境里没必要所有流量都上最强模型。我常用的策略是分级路由先花几毫秒和极少的 Token 成本用一个小分类模型判断用户请求的复杂度简单请求比如查天气、查时间、固定格式问答直接路由到便宜的轻量模型复杂请求需要推理、需要长文生成才转发给高性能大模型。这样可以显著拉低整体成本毕竟轻量模型的价格往往只有旗舰模型的十分之一甚至更低。这个策略在落地时要注意两个点一是分类模型的误判率如果 30% 的简单请求被误判为复杂请求成本优势直接消失二是轻量模型在某些任务上的质量可能不足你需要提前设定一个降级标准比如用户追问“你确定吗”就自动升级重答。我身边有团队靠这套做法把月成本压低了五成以上质量和成本之间的平衡是可以被精密调出来的。4.3 批量处理和异步合并把多次请求合并成一次很多业务场景根本不需要实时返回。比如夜间批量总结用户反馈、周期性的文档处理这类任务可以攒一批、合并成一个大请求让模型一次处理多条内容。这样做有两个好处第一大请求中固定开销系统提示词等被摊薄到更多业务内容上单位成本下降第二可以利用服务商可能提供的批量 API 折扣价部分厂商对 Batch 请求额外打折。举个例子你要逐个总结 100 条用户评论每条评论 200 Token如果分开请求每个请求都要附带一份 1000 Token 的说明性指令总输入就是 100×(1000200)120000 Token如果合并成一个数组发送指令只带一次输入大约 1000100×20021000 Token输入成本直接降到原来的六分之一。这种思路在数据清洗、批处理场景里非常普遍收益也非常可观。5. 常见误区与排查技巧实录那些账单爆掉时的自救指南5.1 为什么代码没报错Token 却消耗极快一个典型场景应用在后台循环调用模型但每次请求都带上了一个巨大的历史记录对象而你并没有意识到这个对象一直在累加。我有一个学员的项目就是这样用户在聊天页面停留一个小时后前端会不断把新的用户输入追加进数组后端未做裁剪就拼接进 Prompt。结果单次请求 Token 从最初的 200 涨到 20000他还在奇怪“用户没问几个问题API 费用怎么这么高”。排查方法是把每次请求的 token 消耗日志单独拉出来按时间排序观察增长曲线。如果 Token 数随着请求次数近乎线性上涨且不是因为你主动实现了记忆功能那大概率是历史消息忘清了。解决办法很简单在代码里设置一个 MAX_HISTORY_TOKENS 常量超过就启动滑动窗口或摘要压缩。5.2 缓存命中率低的排查方向动态位置、隐藏字符、时间过期如果你的服务商支持缓存但账单显示命中率等于零按从常见到不常见的顺序排查这几个点动态内容是否放在了 Prompt 前部比如时间戳、用户名、随机 ID 放在最前面前缀每次不同缓存必然失效。是否引入了隐藏字符从数据库读出的文本可能自带换行符、空格、BOM肉眼看不出来却足以让缓存前缀失配。建议打印每个字符的 Unicode 编码对比。是否超过了缓存的 TTL有效时间间隔太久的请求缓存已服务商侧过期命中率自然低。以上三个原因基本覆盖 90% 的缓存未命中场景。实际工作中我把排查步骤写成自检清单每接入一个新服务商就照着走一遍。5.3 快速定位成本异常的账单分析方法我建议所有使用大模型 API 的团队从上线第一天就把 Token 使用日志结构化落地至少记录请求时间、模型名、输入 Token 数、输出 Token 数、缓存命中 Token 数、请求所属功能模块。这些字段可以按天聚合做成一张简单的日报表。一旦账单出现问题你可以快速定位是哪个模块、哪个模型、哪个时段消耗异常。有一次客户找到我说某天的账单突增两倍。我拉出日志一看发现某个模块的输入 Token 平均值没有变化但请求量翻了倍再一查是营销团队给该模块加了新入口导流力度远超预估。这不是技术故障而是业务调整带来的成本变化但因为日志结构清晰五分钟就定位了原因。反过来如果当时没有日志面对一脸黑的账单数据只能靠猜那就非常被动了。5.4 一个小教训别把“Token 上限设大”当成“性能调优”有些开发者认为把 max_tokens 调大就能让模型回答得更多更好于是直接按上下文上限去设动不动就是几千。表面上确实是“模型能输出更多内容”实际上绝大多数交互用不到这么长的输出但这部分预留的 max_tokens 虽然多数平台不会提前扣费却会影响调度和用户体验。更危险的是在部分按“最大生成量”预留资源的服务商那里这一项会直接抬高你每次请求的计费基数和实际生成量无关。正确做法是先统计你业务场景的真实输出长度分布。比如大多数回答在 200~500 Token 之间那就把 max_tokens 设置为 600 左右留点余量而不是无脑怼到 4096。一个简单的统计脚本就能解决的事太多人懒得做最后被账单教育。结尾一点个人经验分享大模型 API 的 Token 计费机制说白了就是两件事搞懂 Token 怎么被计算的搞懂计费规则里哪些地方能优化。我在这些年做过的项目里发现真正把成本控制得好的团队往往不是技术最炫的而是把“每一次请求花多少钱”这件事做成常态化观察的人。他们会在每次联调时看一眼 Token 消耗在每个版本上线的同时更新成本预算表而不是等到月末收到账单才如梦初醒。如果你刚开始接触这一块我建议你先把今天这篇文章里提到的计算公式自己手动跑一遍找一个真实请求拆出输入、输出、缓存各项算出单次成本再乘上你预估的日活和调用频次。做过这一步你对 Token 计费的理解就会从“知道”变成“掌握”。后续再优化 Prompt、接入缓存、做模型路由你都能清楚地看到每一分钱省在哪里。要是你手边正好有被账单困扰的项目就拿文中的排查清单逐项核对我敢说至少有一半的问题当场就能找到答案。
前两天有个朋友问我他们在做的一个对话机器人客户那边反馈“也没聊几句怎么账单就快爆了”。我让他把请求日志翻出来一算才发现问题不在并发量也不在模型选型而是他们压根没弄明白大模型 API 是按什么计费的。这个“什么”就是 Token。Token 计费机制直接决定你调用一次大模型接口要花多少钱、一个上下文窗口到底能塞多少字、以及你的业务模型在规模化之后成本曲线是陡还是平。不管是做 AI 应用的开发者、运营同学还是帮客户落地大模型项目的技术负责人只要你在碰大模型 API就必须把这套机制吃得透透的。否则测试阶段风平浪静一旦上了生产、接了真实流量月底账单能让你怀疑人生。这篇文章我从 Token 怎么来、官方按什么规则收费、到一个真实请求如何手动算账、再到生产环境里怎么省钱和避坑一条线给你理顺。全程是实操视角不堆概念看完你就能拿出自己的账单逐条对着看。1. 为什么大模型计费偏偏盯着 Token 这个单位1.1 先搞清楚 Token 是什么别再把“字数”当“Token”很多人有一个误区以为大模型按字符数或者按字数计费。实际上主流大模型 API 全部按 Token 计费Token 是模型处理文本的最小单位。所谓 Tokenization分词就是把一段自然语言切成模型能理解的最小片段。这个片段有时候是一个英文单词有时候是一截单词甚至可能是一个标点。举一个最直观的例子。英文里 AI 通常是一个 Token但 tokenization 这个词会被拆成 token 和 ization 两个 Token。中文没有天然空格分词规则各家略有差异但大体上常见的一个汉字在多数模型里约等于 0.6~1 个 Token三个汉字大概占 1~2 个 Token。这意味着一段 1000 个汉字的 Prompt实际 Token 数往往在 800~1200 之间浮动绝不是你肉眼看到的“1000 字”。为什么要这么计费因为大模型内部处理时注意力机制是按 Token 做矩阵运算的输入的 Token 数越多计算量就越大。你每次请求模型都要把全部输入 Token 读一遍、算一遍生成结果时每一个新 Token 也都是一次前向计算。成本和你交出去的字数、拿回来的字数直接挂钩所以供应商按 Token 收费最公平也最透明。1.2 上下文窗口和 Token 的关系为什么上下文越长越烧钱上下文窗口Context Window是大模型一次能接受的最大 Token 数量包括输入和输出。注意不是只看你这一轮问了什么而是整个对话历史累积的 Token 数。一个经典场景你做一个客服机器人用户聊天记录越滚越长你每次都把全部历史拼进 Prompt 发给模型很快就会发现两个问题一是请求报错“超出上下文长度”二是账单金额直线上升。这里面的计算逻辑是每一次请求的计费 Token 数 全部输入 Token 数 模型生成的输出 Token 数。即使模型一句话都没输出只返回了一个“好的”你每轮发送的输入中仍包含所有历史对话。假设用户聊了 20 轮每轮平均 300 Token那第 20 轮你发的输入就是 20×3006000 Token这个数字会随着对话轮数线性增长。我见过不少团队在生产环境里犯了“无限拼接”的错。有人甚至把知识库全文不分青红皂白往上下文里塞一个 200KB 的文档直接转成几万 Token 塞进去单次请求成本比模型生成文本的贵一个数量级。所以理解上下文窗口的真正含义是整个计费机制里最重要的一环窗口越大单次可处理的内容越多但单次成本也越高两者是直接绑定的。2. 一套请求的计费规则拆解输入、输出、缓存、超额2.1 输入和输出单价不相等这是最容易被忽视的规则几乎所有主流大模型 API 的定价表里输入单价都明显低于输出单价。原因很实在输入 Token 只需要并行计算一次注意力而输出 Token 是逐个生成的每生成一个都在做一次自回归采样计算开销大得多。我记得某个主流模型的定价是输入百万 Token 收费十几块人民币输出百万 Token 收费几十块输出价格大约是输入的 3~4 倍。这个差异直接影响你的成本结构。如果是一个问答产品用户问题短、回答长那钱主要花在输出 Token 上如果是一个文档总结工具每次塞进去一大段文本、输出只要一行结论那钱主要花在输入 Token 上。做成本预算时必须分别估算输入和输出的量级再按各自单价去算不能笼统按“平均 Token 单价”估。很多小伙伴会盯着“百万 Token 多少钱”这个指标但千万要看清是“输入百万 Token”还是“输出百万 Token”。同一家厂商输入和输出价格差出三倍以上是常态不看单位直接对比很容易在选型时做出错误判断。还有一个细节某些服务商对系统提示词System Prompt单独计费或对特殊内容加收处理费这些都要在计价文档里逐字看清。2.2 缓存命中你以为没花钱其实计费规则里还有一条隐藏车道为了让你把同一份知识库、同一套系统提示词反复发送时不再全额计费服务商设计了提示词缓存Prompt Caching。核心机制是如果请求中的前缀 Token 和之前某次请求完全一致这部分命中的 Token 按一个很低的折扣价计费通常只有原价的 10% 左右甚至更低。比如系统提示词 5000 Token每次请求都带着没缓存时每次都是全价有缓存后第二次开始这 5000 Token 很可能只需付零头。但要注意几个触发条件。第一缓存前缀必须完全一致哪怕中间多了一个空格、改了一个字整段前缀就失效了。第二不同服务商对缓存时效有要求有的要求两次请求间隔不超过几分钟超过时间缓存自动过期。第三缓存的 Token 数和未命中的 Token 数在账单里是分开列出的需要辨认识别。这里有一个实际收益案例我之前优化过某智能客服项目系统提示词加历史对话模板占了总输入 Token 的 70%开启缓存后整体 API 成本直接降了近四成。实现方式也不复杂就是把固定不变的内容系统提示词、固定的工具说明放在最前面让变动内容排在后部保证前缀稳定可缓存。相反如果你把用户名、时间戳这些动态内容塞在 Prompt 的最前面缓存就永远无法命中这个隐性损失很多人根本不会注意到。2.3 上下文超出上限怎么办截断策略直接决定你多花多少钱当你的 Prompt 总 Token 超过模型上下文窗口时请求会直接失败这是最直接的结果。但生产中还有另一种情况服务商允许你“超额”请求后台自动截断最前面的内容只把后半段送入模型。这种策略很危险因为你完全没有感知还以为模型在正常回答实际上最早的对话历史已经被丢弃而且这部分的输入 Token 仍然可能被计费具体看服务商规则。我遇到过一个案例某团队做长文档问答文档 4 万 Token模型窗口 8K他们想着“超了就超了模型会自己处理”结果文档后半部分进了上下文前半部分被静默丢弃。用户问“第一章的核心结论是什么”模型一本正经答非所问。排查了半天才发现是截断策略惹的祸更尴尬的是被截掉的那部分 Token 照常计费。所以做长上下文应用时绝不能依赖服务商的默认截断行为一定要在代码里主动控制发送给模型的 Token 数。可以在发送前调用 Tokenizer 计算长度超过阈值就触发摘要、滑动窗口、或者分段处理。控制逻辑掌握在自己手里才不会既丢了内容又丢了钱。3. 动手算账从一个真实请求看 Token 费用的完整计算过程3.1 如何精确获取一段文本的 Token 数而不是靠猜每个模型都有对应的 Tokenizer 工具绝大多数服务商提供在线调试页面或者提供开源的分词器库支持你用 Python 或 JS 本地调用。你在本地算出来的 Token 数和线上计费系统基本一致。这个是做成本管理的基础设施每个团队都必须封装成一个公共方法。我自己常用的做法是维护一个 Python 工具函数输入任意文本输出 Token 数量和计数明细。平时做需求的时候顺手把用户可能输入的最长 Prompt 拿进去跑一遍立刻就能评估单次请求成本。下面是基于常见的开源分词库的示例这里用 OpenAICli100k_base 类似的分词器做演示你在实际项目中换成你用的模型对应的库即可import tiktoken # 按你使用的模型选择对应的编码器 encoder tiktoken.get_encoding(cl100k_base) def count_tokens(text: str) - int: return len(encoder.encode(text)) prompt 请总结以下会议纪要并提炼出三个待办事项... input_tokens count_tokens(prompt) print(f输入 Token 数: {input_tokens})不同模型可能使用不同的分词器有的甚至官方不提供本地库只提供在线 API。这种情况下你在估算阶段可以用近似比例中文按“1 汉字 ≈ 1 Token”做上限预估英文按“1 单词 ≈ 1.3 Token”做粗略算。注意这些只是估算真正上生产前一定要用目标模型对应的标准 Tokenizer 验证过再批量上线。3.2 手把手算一笔完整账单输入、输出、缓存分开算假设你选的模型定价如下仅为举例非真实厂商价格计费项目单价人民币 / 百万 Token输入未命中缓存12 元输入缓存命中1.2 元输出36 元现在用户连续发起两次请求每次请求的系统提示词固定为 2000 Token用户问题平均 500 Token模型回答平均 800 Token。第一次请求输入 2500 Token2000 固定 500 问题全部未命中缓存输出 800 Token。费用为 2500×12/1000000 0.03 元800×36/1000000 0.0288 元合计约 0.0588 元。第二次请求系统提示词命中缓存2000 Token 按缓存价计费用户问题 500 Token 未命中缓存。费率为 2000×1.2/1000000 0.0024 元500×12/1000000 0.006 元输出 800 Token 还是 0.0288 元合计约 0.0372 元。你发现问题没有第二次请求因为有缓存总成本比第一次便宜了约 37%。如果这个系统每天有 100 万次请求缓存开没开一个月下来就是几万块的差额。把这个计算逻辑固化到代码里每次上线新功能前先跑一遍就能在开发阶段预判成本而不是等月底账单出来再追悔莫及。3.3 并发量、限流、Token 耗尽之后会发生什么计费 Word 之外还要掌握 API 返回状态码的含义。常见的是 429 限流和 400 上下文超长但有些服务商在账户余额不足时也会返回特殊错误。这里有一个很容易踩的坑某些平台允许你设置“最大生成 Token 数”一旦回答长度触顶API 返回正常但内容被截断。此时系统会计费完整的已生成 Token而你拿到的是不完整结果用户只会觉得模型“答到一半就停了”。生产环境中必须对这类截断状态做响应识别。很多模型的返回结构里会包含 finish_reason 字段如果它的值是 “length”说明是触达限制而非正常结束。此时你应该主动做后续处理比如把现有内容作为中间结果再做一轮续写而不是直接当成最终答案返回给用户。忽略了这一步你不但白花了钱用户体验还会被打折扣。这个细节我建议你在联调阶段就写进测试用例。4. 生产环境里的省钱实操三种策略帮你把 Token 账单打下来4.1 Prompt 压缩花最少的钱保留最多的语义Prompt 里非必要的内容越少单次输入成本就越低。这听起来像废话但真正执行的人不多。我看过太多项目的 Prompt 里残留着大量冗余注释、重复指令、无效示例。比如一个系统提示词里写了三个功能说明其中两个已经很久没用了却仍然跟随每次请求一起发送白白占用几百上千 Token。我的习惯是每隔一两周做一次 Prompt 体检把当前线上 Prompt 导出逐行审视每句话是否依然有效把输出格式说明用最精简的方式重写把示例从三段合并成一段如果某些工具函数说明只在特定场景才需要就改成动态拼接而不是全局常驻。经过几次压缩同样的功能输入 Token 能减少 30% 以上。还有个经验是能用 10 个 Token 说清的指令绝不用 50 个 Token 写一大段限定语。模型的指令遵循能力并不完全和 Prompt 字数成正比写得再长该不听还是不听但钱是按字数实打实收的。把 Prompt 当作代码一样去精简是每个 AI 应用负责人应有的基本素养。4.2 模型分级与路由让便宜模型先干 80% 的活生产环境里没必要所有流量都上最强模型。我常用的策略是分级路由先花几毫秒和极少的 Token 成本用一个小分类模型判断用户请求的复杂度简单请求比如查天气、查时间、固定格式问答直接路由到便宜的轻量模型复杂请求需要推理、需要长文生成才转发给高性能大模型。这样可以显著拉低整体成本毕竟轻量模型的价格往往只有旗舰模型的十分之一甚至更低。这个策略在落地时要注意两个点一是分类模型的误判率如果 30% 的简单请求被误判为复杂请求成本优势直接消失二是轻量模型在某些任务上的质量可能不足你需要提前设定一个降级标准比如用户追问“你确定吗”就自动升级重答。我身边有团队靠这套做法把月成本压低了五成以上质量和成本之间的平衡是可以被精密调出来的。4.3 批量处理和异步合并把多次请求合并成一次很多业务场景根本不需要实时返回。比如夜间批量总结用户反馈、周期性的文档处理这类任务可以攒一批、合并成一个大请求让模型一次处理多条内容。这样做有两个好处第一大请求中固定开销系统提示词等被摊薄到更多业务内容上单位成本下降第二可以利用服务商可能提供的批量 API 折扣价部分厂商对 Batch 请求额外打折。举个例子你要逐个总结 100 条用户评论每条评论 200 Token如果分开请求每个请求都要附带一份 1000 Token 的说明性指令总输入就是 100×(1000200)120000 Token如果合并成一个数组发送指令只带一次输入大约 1000100×20021000 Token输入成本直接降到原来的六分之一。这种思路在数据清洗、批处理场景里非常普遍收益也非常可观。5. 常见误区与排查技巧实录那些账单爆掉时的自救指南5.1 为什么代码没报错Token 却消耗极快一个典型场景应用在后台循环调用模型但每次请求都带上了一个巨大的历史记录对象而你并没有意识到这个对象一直在累加。我有一个学员的项目就是这样用户在聊天页面停留一个小时后前端会不断把新的用户输入追加进数组后端未做裁剪就拼接进 Prompt。结果单次请求 Token 从最初的 200 涨到 20000他还在奇怪“用户没问几个问题API 费用怎么这么高”。排查方法是把每次请求的 token 消耗日志单独拉出来按时间排序观察增长曲线。如果 Token 数随着请求次数近乎线性上涨且不是因为你主动实现了记忆功能那大概率是历史消息忘清了。解决办法很简单在代码里设置一个 MAX_HISTORY_TOKENS 常量超过就启动滑动窗口或摘要压缩。5.2 缓存命中率低的排查方向动态位置、隐藏字符、时间过期如果你的服务商支持缓存但账单显示命中率等于零按从常见到不常见的顺序排查这几个点动态内容是否放在了 Prompt 前部比如时间戳、用户名、随机 ID 放在最前面前缀每次不同缓存必然失效。是否引入了隐藏字符从数据库读出的文本可能自带换行符、空格、BOM肉眼看不出来却足以让缓存前缀失配。建议打印每个字符的 Unicode 编码对比。是否超过了缓存的 TTL有效时间间隔太久的请求缓存已服务商侧过期命中率自然低。以上三个原因基本覆盖 90% 的缓存未命中场景。实际工作中我把排查步骤写成自检清单每接入一个新服务商就照着走一遍。5.3 快速定位成本异常的账单分析方法我建议所有使用大模型 API 的团队从上线第一天就把 Token 使用日志结构化落地至少记录请求时间、模型名、输入 Token 数、输出 Token 数、缓存命中 Token 数、请求所属功能模块。这些字段可以按天聚合做成一张简单的日报表。一旦账单出现问题你可以快速定位是哪个模块、哪个模型、哪个时段消耗异常。有一次客户找到我说某天的账单突增两倍。我拉出日志一看发现某个模块的输入 Token 平均值没有变化但请求量翻了倍再一查是营销团队给该模块加了新入口导流力度远超预估。这不是技术故障而是业务调整带来的成本变化但因为日志结构清晰五分钟就定位了原因。反过来如果当时没有日志面对一脸黑的账单数据只能靠猜那就非常被动了。5.4 一个小教训别把“Token 上限设大”当成“性能调优”有些开发者认为把 max_tokens 调大就能让模型回答得更多更好于是直接按上下文上限去设动不动就是几千。表面上确实是“模型能输出更多内容”实际上绝大多数交互用不到这么长的输出但这部分预留的 max_tokens 虽然多数平台不会提前扣费却会影响调度和用户体验。更危险的是在部分按“最大生成量”预留资源的服务商那里这一项会直接抬高你每次请求的计费基数和实际生成量无关。正确做法是先统计你业务场景的真实输出长度分布。比如大多数回答在 200~500 Token 之间那就把 max_tokens 设置为 600 左右留点余量而不是无脑怼到 4096。一个简单的统计脚本就能解决的事太多人懒得做最后被账单教育。结尾一点个人经验分享大模型 API 的 Token 计费机制说白了就是两件事搞懂 Token 怎么被计算的搞懂计费规则里哪些地方能优化。我在这些年做过的项目里发现真正把成本控制得好的团队往往不是技术最炫的而是把“每一次请求花多少钱”这件事做成常态化观察的人。他们会在每次联调时看一眼 Token 消耗在每个版本上线的同时更新成本预算表而不是等到月末收到账单才如梦初醒。如果你刚开始接触这一块我建议你先把今天这篇文章里提到的计算公式自己手动跑一遍找一个真实请求拆出输入、输出、缓存各项算出单次成本再乘上你预估的日活和调用频次。做过这一步你对 Token 计费的理解就会从“知道”变成“掌握”。后续再优化 Prompt、接入缓存、做模型路由你都能清楚地看到每一分钱省在哪里。要是你手边正好有被账单困扰的项目就拿文中的排查清单逐项核对我敢说至少有一半的问题当场就能找到答案。
