做API接入这几年“Token”这个词绝对是我见过最容易让人产生误解的概念。第一次看账单的时候我整个人是懵的明明提示词只写了几百字为什么扣费显示消耗了好几千Token后来把一份几十万字的文档喂进去输入价格看着还行结果模型一输出费用又跳了一截。更让我意外的是在很多模型里输入和输出根本不是同一个价输出通常要贵出3到5倍。这篇文章不聊虚的就把这本账摊开算清楚Token到底怎么数、输入和输出为什么差价这么大、一次真实调用的费用怎么精确计算以及怎么把Token成本压到最低。1. Token是什么计费单位为什么非它不可1.1 Token不是字数也不是字符数大模型并不像人一样按“字”阅读。模型在拿到文本之后第一个动作叫分词Tokenization把一整段文字切成一个一个Token。Token可以是英文的一个完整单词也可以是被拆出来的半个单词可以是一个标点也可以是几个字符某些中文场景下甚至可以是一整个汉字。那为什么不按字数计费因为不同语言的信息密度差别太大。一个汉字承载的信息量往往要对应英文三四个字符甚至更多。如果按字符数收费中文用户会觉得自己怎么动不动就这么贵英文用户又觉得便宜得离谱。Token本质上是模型内部的“思维积木”它的数量更贴近模型真正处理的计算量所以各家不约而同选择了Token。这里有一个很关键的认知误区不同模型的分词器不一样。以我测试过的几个模型为例同一段中文“你好今天天气不错”在OpenAI的cl100k_base词表下可能消耗十几个Token在DeepSeek或Qwen自己的分词器下可能就是几个Token。也就是说1 Token等于多少个汉字不存在一个全球通用答案谁家计费就按谁家分词器算这一点一定记牢。1.2 中英文、代码的Token换算经验值虽然不能跨模型完全通用但平时做成本预估还是需要一些经验值。我常用的估算口径是英文1个Token大约等于4个字符约0.75个单词。1000 Token大概对应750个英文单词。中文1个汉字通常占1到2个Token不同模型浮动很大。按经验估算1000 Token大约对应500到700个汉字。中英混合按“英文0.25 Token/字符、中文1.5 Token/字”来毛估再乘1.2的安全系数。代码一个Token大约2到4个字符受缩进、符号密度影响很大。想要精确数字最靠谱的办法是拿官方分词工具直接算一次。OpenAI生态里可以用tiktokenDeepSeek也提供在线tokenizer工具。下面这段代码演示了怎么用tiktoken统计token数import tiktoken enc tiktoken.get_encoding(cl100k_base) text 大模型API按Token计费输入和输出价格差别很大。 print(len(enc.encode(text)))我习惯在项目动工之前把预计要用的中文文档丢进这类工具里跑一遍。跑完之后你对“中文Token是什么量级”才有真实体感而不是对着线上usage数据猜来猜去。2. 输入和输出价格为什么差那么多2.1 各家模型的公开报价参考先直接看一组主流模型的输入输出价格。注意模型价格调整非常频繁各家打价格战时尤其夸张下面表格里的价格只代表某个时间段的数量级参考真正的计费要以官方定价页和你的账户账单为准模型输入价美元/百万Token输出价美元/百万Token输入输出比约DeepSeek-V30.271.101:4DeepSeek-R10.552.191:4OpenAI GPT-4o mini0.150.601:4OpenAI GPT-4o2.5010.001:4Claude 3.5 Sonnet3.0015.001:5Gemini 2.0 Flash0.100.401:4这张表里最稳定的规律不是谁贵谁便宜而是输出价基本固定在输入价的4到5倍。哪怕不同模型绝对价格差出好几十倍输入输出比却出奇一致。这说明输入输出差价不是厂商随便拍脑袋定的而是背后有着很硬的计算成本结构。2.2 输入是一次性“阅读理解”输出是逐字“现场写作”要理解为什么输出更贵得先明白大模型推理的两个阶段。第一个阶段叫预填充也就是处理输入Token。模型把你给它的整段文本一次性、并行地读进去为每个Token算好中间状态并缓存下来。这个阶段虽然计算量大但并行度高单位Token成本反而被摊薄了。第二个阶段叫解码也就是生成输出Token。模型每生成一个Token都要依赖前面已经生成的所有Token只能一个接一个地串行计算。生成第500个Token时它其实等于把前499个Token的历史全部重新“过”了一遍。这个过程中模型还需要反复读取缓解中间结果的KV Cache内存带宽会变成瓶颈。一句话总结输入像复印资料放进仓库一次复印多少本都行输出像让专家现场写文章每写一个字都得把之前的草稿重新看一眼。这就是为什么输出Token永远是更贵的那部分。2.3 输入价格里还藏着一档缓存命中价很多模型服务商其实把输入价拆成了两档一档是“缓存未命中”一档是“缓存命中”。还是拿DeepSeek举例缓存未命中的输入价格约0.27美元/百万Token缓存命中只要0.07美元直接打了个骨折价。OpenAI的prompt caching也是同样思路。这套机制的底层逻辑是如果你在一段时间内向同一个模型重复发送相同的固定前缀比如system prompt、工具定义、固定上下文服务商可以直接复用之前算好的KV Cache不需要把这批Token从头再算一遍。对多轮对话或知识库问答这类应用来说用户问题一直在变但大段大段的系统提示是不变的。只要你把不变内容稳定放在请求最前面命中率可以非常高。想吃到这波红利最需要避免的操作是频繁修改system prompt哪怕只是改了一个字也很可能导致整个前缀缓存失效成本瞬间回到原价。这个坑我印象非常深。3. 一笔真实账单的完整拆解3.1 从API返回里读取Token消耗不管对接哪家模型只要是OpenAI兼容协议标准响应里都会带usage字段。一次典型的返回长这样{ usage: { prompt_tokens: 501000, completion_tokens: 2000, total_tokens: 503000, prompt_tokens_details: { cached_tokens: 400000 } } }prompt_tokens本次请求的输入Token总数。completion_tokens本次请求的输出Token总数。total_tokens两者之和。prompt_tokens_details.cached_tokens其中有多少Token命中了缓存。这里最容易栽跟头的地方是你发出去的“输入Token”绝不只是最后一次输入。在Chat Completion接口里Messages数组里的system提示、所有历史对话、工具定义全都会被累加到prompt_tokens里。也就是说一段多轮对话走到第10轮第1轮的问题和回答仍然在暗地里按输入价格计费。3.2 一个知识库问答请求费用具体是多少我拿一个很常见的落地场景来算账。假设你要做一个企业文档问答文档被整体塞进上下文里约有50万Token中文系统提示和用户问题加起来约1000Token模型最后输出2000Token回答。先按DeepSeek-V3的公开参考价计算输入费用501000 / 1000000 * 0.27 0.13527美元输出费用2000 / 1000000 * 1.10 0.0022美元总费用大约0.1375美元按汇率7.2折合人民币差不多1块。同样的请求如果打给GPT-4o输入费用501000 / 1000000 * 2.5 1.2525美元输出费用2000 / 1000000 * 10 0.02美元总费用约1.27美元折合人民币9块多。这个例子里输入显然才是成本大头。换一个场景如果文档只有2000Token但要求模型输出5000Token的长文章费用结构立刻反转输出单价高的劣势会被放大到非常明显。所以做成本模型时不要只盯着单价表格必须按自己业务里的真实输入输出比例来计算否则预算铁定失真。3.3 多轮对话里的Token滚雪球效应再展开说说多轮对话为什么是成本杀手。假设每轮用户提问约200Token模型回答约300Token并且系统不做任何历史裁剪。跑到第20轮时第20次请求要携带前19轮的全部内容也就是大约200300* 19 9500Token再加上当轮问题约200Token输入总Token接近9700Token而模型的输出依然是300Token。真正在干活的只有最后那300Token输出但账单上却要为9700Token的输入历史买单而且下一轮还会更多。这就是很多聊天类应用越跑越贵的根因。成熟的方案一般会在会话中做滑动窗口截断、历史摘要压缩或者干脆只保留最近N轮。省钱这件事很多时候省输入Token比省输出Token更容易见效。4. 控制Token成本的几个实操方法4.1 提示词瘦身先砍输入再管输出成本优化第一板斧永远是整理提示词。我见过太多人的System Prompt里堆满客套话比如“你是一个很厉害的AI助手请认真仔细回答我的问题”这种句子每个请求都会被重复计费纯属白花钱。更麻烦的是很多人喜欢把几十条示例全部塞进提示词输出没优化多少输入Token倒是猛涨。我自己的处理习惯是能删的客套话全部删掉能把多个指令合并的合并固定示例只要能向量化就放到外部知识库里按需回填而不是常驻在上下文里。对历史消息我常用的策略有三种滑动窗口只保留最近N轮超出部分直接丢弃。摘要压缩每隔几轮让模型把前面的对话压成200Token摘要替换原始对话。向量检索知识库场景不把整篇文档灌进上下文先通过检索把相关片段挑出来只发几千Token。这三种策略不是互斥的实际产品里我经常混合使用。关键要记住任何优化都要拿数据说话每天记录一下prompt_tokens总量优化之后对比降幅不是凭感觉说“好像少了一点”。4.2 给输出装上“闸门”max_tokens与结构化生成输出Token单价是输入的好几倍所以限制输出长度是性价比极高的事。调用接口时一定要设置max_tokens有的平台叫max_completion_tokens。不设或者设得太大模型很可能洋洋洒洒写出一大篇费用瞬间失控。但max_tokens不是越小越好设得太小会截断回答用户拿不到完整结果反而要再来一次总费用更高。比较科学的做法是先估算任务正常需要多少字按Token粗估后加一点余量作为上限。明确要求结构化输出比如JSON格式让模型按字段填空不要自由发挥写散文。要生成超长文本时不要幻想一次吐完改成多次生成先出大纲再逐章生成最后汇总结论。每个任务在开发阶段就定好“输出预算”上线后监控completion_tokens是否经常贴近预算上限预算到了但输出经常被截断就说明设计不合理要么拆任务要么换更长上下文的模型。4.3 利用缓存和批量接口省出固定成本除了提示词优化还有两个相对隐蔽的省钱渠道多数人容易忽略。第一个是前文提到的prompt caching。所有固定内容都要放在请求最前面并且保持稳定不要轻易修改。像工具定义、角色设定、系统级安全规则这类常年不变的东西是缓存命中的主力。需要注意的是缓存有有效期且会在一定量Token之后才生效不是随便发一次就命中。还是那句话把固定前缀看成一笔资产别手痒去改动。第二个是批量接口。很多服务商为不需要实时响应的任务提供Batch API价格通常是实时接口的5折甚至更低。大批量数据清洗、离线文档总结、周末跑批任务完全可以用批量接口处理。实时聊天与离线批处理流量分开不仅便宜还不会挤占在线业务的TPM限额。4.4 别忘了限速TPM和RPM才是隐形天花板按Token计费只是问题的一半。很多平台还按TPM每分钟Token数和RPM每分钟请求数限制流量。就算预算充足一个5万Token的长文档请求也可能把整个TPM配额吃掉大半后面再来几十个请求就会返回429限流错误。TPM通常按输入和输出合计统计。在TPM只有8万的小套餐下一个输入6万Token的请求发出去这一分钟基本就干不了别的事了。所以做容量规划时千万不能只看单价便宜就冲还要确认套餐里的TPM、RPM以及上下文上限是否匹配你的请求特征。很多低价服务会在这里卡脖子真跑起业务来才明白坑在哪里。5. 和Token相关的报错与常见坑5.1 提示“已达到输出Token上限回答被截断”怎么办做生成任务时最常遇到的报错“已达到输出Token上限回答被截断”背后大概率是两种原因没设置max_tokens或设得偏小模型输出到一半被强行掐断。平台或模型对单次输出有硬性上限比如某些模型单次最多只能输出8192Token。遇到这种情况先不要急着投诉模型。第一步把本次请求的max_tokens调大再试一次如果已经到模型单次输出上限就改成分段生成让模型先写大纲再一章一章地写有些平台支持“继续”机制可以让模型从上次断点接着写。这里有个容易误会的点截断并不代表后面的Token不收费。所有已经成功生成的Token不管最后有没有被截断都照常计入completion_tokens。所以设计提示词时不如直接告诉模型“控制在400字以内”让它在输出端自己收敛好过事后重新请求。5.2 报“输入过长”和限流很多时候不是同一件事模型有最大上下文窗口比如128K或200K。一旦输入Token总数超过窗口直接报错。但还有一种情况是输入并没有超过窗口请求却因为TPM限流被拒报错文案有时也会带类似“maximum context”或“rate limit”的字样容易让人误判。排查时建议分两路走先看请求里的prompt_tokens是否超过模型上下文上限。再看账户当前TPM/RPM是否被打满可以在服务商控制台查实时用量。长文本场景下的最优解是拆分任务。不要试图把数据库整表结构、完整技术文档、几十轮聊天记录一次性塞进请求。先拆模块再分别处理最后汇总结果。这既解决了窗口超限也能显著改善限流和成本。5.3 此Token非彼TokenJWT续签和API计费Token别搞混很多刚入门的朋友都会被“Token”这个词搞晕今天聊计费按Token明天登录又碰见Token到底是不是一回事答案是不是一回事。计费Token是分词后的文本单元而JWTJSON Web Token是一种身份认证令牌本质上是一串携带用户信息和过期时间的加密字符串。两者只是碰巧都叫Token底层毫无关系。如果你的项目并没有接大模型却报出类似“token exchange failed”这种错误那多半是OAuth/OIDC或API网关的令牌交换环节出了状况。我排查这类问题一般按这个顺序来确认client_id和client_secret配置是否正确确认授权码是否已经过期或被重复使用确认服务器时间是否同步JWT校验依赖时间窗口时钟偏移会导致验签失败确认scope权限是否匹配缺少权限会在换取访问令牌时被拒确认网关是否有地区或来源限制403类错误往往和这一层有关。至于“JWT实现Token续签”常规套路是access token短时效负责业务访问refresh token长时效负责续命。access token过期后拿refresh token换新的access token。这里有一个必须处理的细节并发刷新会导致refresh token被反复使用而失效一定要在客户端实现刷新互斥服务端也要在刷新成功后立即使旧token失效。这套逻辑跟大模型计费毫无关系但它总是一个项目里会同时出现所以我单独拎出来讲清楚。5.4 Token相关高频问题排查速查表放一张我自己工作里经常用的速查表现象可能原因优先排查顺序回答写到一半被截断max_tokens过小 / 模型单次输出上限调大max_tokens再考虑分段生成报输入过长总Token超过上下文窗口检查prompt_tokens总数拆分上下文请求返回429TPM/RPM限流查看配额用量降并发或升级套餐计费异常偏高历史消息重复计费 / 缓存未命中精简messages固定前缀并放最前面登录报token exchange failedOAuth配置或令牌过期查网关日志核对client信息、时间、scopeJWT刷新后无法访问refresh token并发刷新或旧token未失效实现刷新互斥更新token存储这张表不能覆盖所有场景但能把大多数“玄学问题”变成可快速排查的技术项。核心思路是先分清是计费Token还是身份Token再看是否与上下文窗口或限流有关最后检查缓存和日志不要一上来就怀疑模型写崩了。最后分享一点我实际干活中的体会。刚用大模型API那会儿我对Token计费毫无概念账单出来一度怀疑是不是被重复扣款。后来我养成了一个笨但有效的习惯每个请求都把usage字段完整记录到日志里每周汇总一次输入输出Token的占比和费用。坚持统计之后哪些提示词在烧钱、哪个模型选贵了一眼就能暴露出来。很多成本问题不是靠猜解决的是靠数据暴露的。还有一个顺手的小技巧所有固定提示词尽量放在请求最前面并且保持一字不变让缓存命中率尽量高。单次请求看着只省几分钱请求量大了之后这笔数字会非常可观。