1. 先把账算明白token 计费这件事为什么值得单独拎出来聊 token 计费与计算绕不开一个工具tiktoken。很多团队做模型应用第一版跑通之后就开始被账单打脸——功能没问题日志也正常就是费用比预期高出一截而且高得毫无规律。追查下去十有八九是同一个原因对 token 的估算方式还停留在字数除以二这种拍脑袋阶段。这篇文章想做的事情很具体把 token 从一个模糊的计费单位变成一个你能在代码里精确算出、提前预估、事后对账的数值同时把 tiktoken 这个分词库的用法、坑点和工程化封装讲透。文章偏实操面向的是已经接过模型接口、手上有真实调用量、需要控制成本或者做预算评估的开发者以及准备把原型转成正式产品的团队。纯理论的部分我会点到为止重点放在怎么算准怎么算省怎么对得上账这三件事上。先说清楚 token 这个东西的定位。它是模型处理文本的最小切分单位既不是字符也不是单词更不是汉字。模型内部没有字的概念它看到的是一串整数编号每个编号对应词表里的一个条目。这个条目可能是一个完整的英文单词可能是单词的一部分可能是一个汉字也可能是两三个汉字凑成的一个组合甚至可能只是半个标点。计费系统统计的就是这些编号的个数所以我这段文本才 800 字怎么算了 1600 个 token这种事非常正常尤其是在中英混排、代码片段、emoji 混入的场景下偏差会大到让你怀疑接口在乱扣费。为什么要把计费单独拎出来说而不是直接看账单因为账单是滞后的。一次调用发出去了钱就花掉了你事后看到数字只能接受。真正的成本控制在请求发出之前就已经完成你要能预估这次请求大概多少 token能不能塞进上下文窗口塞不进去要怎么裁剪裁剪之后语义还够不够。这些判断全依赖准确的 token 计算能力。tiktoken 就是目前最主流的离线计算方案之一它把分词逻辑搬到本地让你在发请求之前就能得到一个足够接近官方计费口径的数字不需要联网也不需要消耗额度试探。还有一个容易被忽略的点token 数不只是钱的问题它同时是上下文窗口的硬边界。窗口塞满了请求直接报错或者历史被静默截断导致模型失忆这两种结果在生产环境里都比多花点钱更难处理。所以把 token 计算做扎实等于同时解决了成本、容量、体验三件事投入产出比相当高。2. token 到底是什么从 BPE 分词讲起2.1 模型眼里的文本是整数序列不是文字要理解计费先得接受一个反直觉的事实模型从来没有读过你的文字。文本进入模型之前会经过一个分词器被转换成一串整数 ID。比如一段文本可能变成[1234, 56, 7890, 23, ...]这样的序列模型的所有计算都建立在这串整数上。输出的时候再反向解码回文字。所谓 token就是这串整数里的每一个数字对应的那一小块文本。这个设计不是偷懒而是效率上的必然。如果按字符切分那么每个字符都要一个编号词表会膨胀得极其夸张而且模型要处理的序列长度会变得很长注意力计算的成本随长度平方增长根本扛不住。如果按单词切分词表又会无限大——新词、拼写错误、专有名词、代码符号永远收录不完一旦遇到词表外的词就只能退化成未知标记信息直接丢失。所以业界普遍采用折中方案子词切分。常见的高频词整体保留成一个 token低频词拆成若干常见片段极端情况下退到字节级别。这样词表规模可控又能覆盖任意文本。2.2 BPE 的合并逻辑用一句话讲明白目前主流方案是 BPE字节对编码。它的训练过程非常朴素先把所有文本拆成单个字节然后统计相邻两个片段一起出现的频率把频率最高的一对合并成一个新片段加进词表重复这个过程直到词表达到预设大小。最终得到的就是一份从高频组合到低频组合的分层词表。这个机制解释了一个很多人困惑的现象同样长度的文本token 数差异巨大。原因是文本里的片段和词表的熟悉度不同。高频词、常见搭配、常用汉字组合往往能整体命中一个大 token一个 token 顶好几个字符生僻词、随机字符串、复杂代码表达式只能被拆成碎片一个字符可能要占一个甚至多个 token。你去看模型处理一串随机生成的十六进制字符串token 数经常会接近字符数甚至更多因为这种内容在训练语料里出现频率低词表里没有对应的组合。用生活类比可能更好理解假设你有一本常用语缩写词典看到中华人民共和国能直接翻到一个条目这就是 1 个 token看到魑魅魍魉没有对应条目只能一个字一个字查这就是 4 个 token。词典的收词范围决定了你的压缩率而不同模型用的词典大小和收词偏好都不一样这正是后面要强调编码器必须和模型匹配的根本原因。2.3 中文的 token 密度和你的直觉差多少英文场景下的经验值流传很广1 个 token 大约等于 4 个字符或者 0.75 个单词。这个数字在很多资料里被反复引用然后被直接套到中文上结果就是严重低估。中文的字符信息密度高一个汉字承载的语义远多于一个英文字母所以在词表设计上中文往往需要多个 token 才能表示一个汉字具体取决于该字在语料中的常见程度。我的实测经验是现代编码器下一段纯中文散文平均每个汉字大约消耗 1 到 1.5 个 token如果是常见成语、高频双字词压缩率会好一些接近 1 个汉字 1 个 token如果是古文、生僻字、专业术语密集的段落会往 1.5 甚至更高走。这意味着一篇 2000 字的中文文章token 数大概在 2200 到 3000 之间浮动而不是很多人以为的 1000 出头。如果这段文本还要作为多轮对话的历史反复回传这个低估会被放大好几倍。更麻烦的是混合内容。一份典型的技术文档里中文说明、英文术语、代码块、表格符号、URL 混在一起各段的 token 密度差异极大。你不能用整篇的平均值去推算某个片段必须逐段计算或者整体一次性算准。这就是为什么我一直建议不要用估值系数直接用分词器算。估值系数只适合做量级判断绝对不能用来做预算和截断决策。3. tiktoken 上手安装、编码选择与基础 API3.1 安装与第一段能跑的代码tiktoken 是一个纯 Python 实现的分词库安装很轻量不需要额外的模型权重下载词表文件会随包一起打包或者在首次使用时拉取。基础用法三行就能跑通pip install tiktokenimport tiktoken enc tiktoken.get_encoding(cl100k_base) tokens enc.encode(今天我们来聊聊 token 计费这件事。) print(len(tokens)) # token 数量 print(tokens) # 整数 ID 列表 print(enc.decode(tokens)) # 还原成文本这段代码打印出来的 token 数就是你该拿去和账单对齐的数字。注意encode返回的是一个整数列表len()得到的就是数量不要对字符串直接取长度那是字符数和 token 数完全是两码事。我在代码评审里见过不止一次把len(text)当成 token 数写进日志的排查了半天以为接口多扣费最后发现是自己统计口径错了。decode这个接口值得单独提一句。它不是完全可逆的某些 token 组合解码回来可能和原文有细微差别尤其是包含不规范空白字符、特殊控制符的文本。所以如果你要做截断到指定 token 数再还原成文本这类操作务必用decode的结果而不是自己按字符切片否则很容易切出半个汉字或者半个转义序列。3.2 编码器选错账就永远对不上tiktoken 内部维护了多套编码方案常见的有r50k_base、p50k_base、cl100k_base、o200k_base这几类。它们对应不同的词表规模和训练语料压缩率差异明显尤其是中文场景下新旧编码的 token 数能差出 20% 以上。用旧编码去估算新模型的实际消耗结果就是系统性偏差而且偏差方向固定你越算越觉得哪里不对。正确的做法是让编码器和模型对齐。tiktoken 提供了按模型标识获取编码器的接口import tiktoken # 传入你实际调用的模型标识 enc tiktoken.encoding_for_model(你的模型标识)如果这个接口不认识你用的模型标识新模型上线快库的更新往往滞后它会抛异常。这时候有两个选择一是查官方文档确认该模型对应哪套编码手动用get_encoding指定二是用一个已知的、词表规模接近的编码做近似估算同时把误差系数记录下来。第二种做法属于权宜之计只适合做趋势监控不适合做精确对账。我自己的习惯是在项目配置里显式写死编码名而不是每次动态推断。理由是动态推断依赖库版本某次升级之后行为可能变化导致历史数据和新数据不可比。写死之后至少在同一个统计口径下数据是连续可比较的。3.3 特殊 token 与允许列表encode有两个参数经常被忽略allowed_special和disallowed_special。默认情况下如果文本里出现了形如|endoftext|这种特殊标记encode会直接报错防止用户无意中注入控制符。这个默认行为在安全上是对的但在做统计的时候会带来麻烦——你的用户输入里如果恰好包含类似字符串计算就会中断。# 统计场景下通常希望把特殊标记当普通文本处理 n len(enc.encode(text, disallowed_special())) # 如果是构造对话模板需要显式允许 n len(enc.encode(text, allowed_special{|endoftext|}))我建议在纯统计路径上统一用disallowed_special()把所有特殊标记当普通字符处理这样统计逻辑永远不会因为输入内容而抛异常。而在真正拼接请求体的路径上则要严格按接口要求处理特殊标记两者不要混用。4. 对话场景下的真实 token 开销4.1 每条消息都有结构性包装开销很多人算 token 只算正文然后发现账单永远比预估高一截。差额主要来自消息包装。对话接口不是把裸文本直接喂进去的每条消息外面都包了一层结构标记用来区分角色、划分边界。这些标记本身也占 token通常每条消息固定开销在 3 到 5 个 token 左右具体数字取决于模型和模板。单条看不明显但在多轮对话里会累积。一轮对话两条消息用户一条、助手一条假设固定开销 4 token十轮就是 80 token。这个量级不算大但如果你在做大批量短消息处理比如一次请求塞进去 50 条历史消息做摘要那就是 200 token 的纯结构开销可能占到总输入的相当比例。我一般的处理方式是给每条消息额外加一个固定补偿值写成一个常量放在配置里比如MESSAGE_OVERHEAD 4统计时用正文 token MESSAGE_OVERHEAD。这个值不需要特别精确方向和量级对了就行因为它的目的在于让预估和账单落在同一个数量级上而不是做到分毫不差。4.2 中文对话的抽样测量为了让数字更具体我做了一组简单的抽样。取若干条典型的中文用户提问长度从 10 字到 200 字不等混合少量英文术语用现代编码器统计文本类型字符数token 数每字 token 比短问句口语化15181.20中等提问含术语80961.20长段描述技术向2002681.34纯英文句子60160.27代码片段1201451.21这组数据不追求普适性只是说明一个结论中文的 token 密度普遍高于 1长文本、术语密集的文本会更高英文的密度远低于 1代码介于两者之间符号多、缩进多的时候会显著上升。你可以在自己的业务语料上做同样的抽样得到属于你的系数然后写进估算函数里做兜底校验——分词器算出来的结果和系数估算结果差太多的时候打个警告能帮你发现意料之外的输入格式。4.3 图片、函数调用这些非纯文本开销只要你的应用涉及多模态或者工具调用token 计算就没法只靠文本分词搞定。图片通常按分辨率折算成一定数量的 token不同模型的分块策略不同同一张图在不同参数下消耗能差好几倍。函数调用的定义体名称、描述、参数 schema是实打实要计入输入的而且这些描述往往是自然语言写的长度不小。一段写得啰嗦的工具描述可能比你实际的用户提问还长。这部分开销我建议单独建一个估算模块不要和文本分词混在一起。文本走 tiktoken非文本走查表加规则最后汇总。这样某一块的逻辑变化时不会影响到另一块排查问题也容易定位。5. 计费公式拆解与成本建模5.1 输入和输出不是一个价几乎所有模型服务都对输入和输出采用不同单价输出通常更贵倍率一般在 2 到 4 倍之间。这个设计有其合理性输出是逐 token 生成的每一步都要跑一次前向计算而输入可以并行处理。但对使用者来说这意味着让模型多说几句的成本远高于多给模型看几段材料。这个特性直接影响了产品设计。比如摘要场景如果你让模型输出一份详细的结构化分析成本可能是让它输出三行结论的几倍反过来如果你想省钱把更多信息塞进输入让模型照着提炼通常比让它自己发挥更划算。我见过一些团队把输入裁得很狠、输出放得很开结果成本反而更高因为输出的单价摆在那里。用公式表达一次调用的成本更直观单次成本 输入token × 输入单价 输出token × 输出单价做预算的时候把输出 token 按最大长度估输入按实际长度估得到的是成本上界。这个上界在批量任务里非常有用可以直接回答这批数据跑完最多花多少这个问题。5.2 多轮对话的累积增长比你想的陡这是最容易翻车的地方。第一轮请求输入只有用户那句话第二轮请求输入是第一轮的用户话 助手回复 第二轮用户话第三轮继续累加。服务端不保存你的会话状态每一轮你都要把完整历史重新发一遍也就要重新计费一遍。做个具体的算术。假设每轮用户输入 200 token助手输出 300 token固定系统提示 500 token一共聊 10 轮。第 n 轮的输入 token 数 500系统 200本轮用户 前 n-1 轮的 (200 300)第 1 轮500 200 700 第 2 轮500 200 500 1200 第 3 轮500 200 1000 1700 …… 第 10 轮500 200 4500 5200总输入 700 1200 ... 5200等差数列10 项平均 2950合计 29500。 总输出 10 × 300 3000。如果按单轮视角粗算你可能以为总共只用了 2000 输入 3000 输出实际输入是 29500差了将近 15 倍。这个增长是二次的轮数越多越夸张。二十轮对话的输入总量会是十轮的三倍多而不是两倍。理解了这一点你就明白为什么限制历史轮数和压缩历史内容是必备的工程手段而不是可选项。我通常的做法是保留最近 N 轮原文更早的轮次做摘要摘要长度控制在原文的 20% 以内并且只在语义确实需要的时候才带上。5.3 缓存机制带来的折扣要用对才划算现在不少服务提供了前缀缓存如果本次请求的开头部分和之前某次请求完全一致这部分内容可以按折扣价计费折扣力度通常很大。这个机制对固定系统提示、固定知识库片段、固定工具定义的场景极其友好。关键在于完全一致这四个字。前缀必须逐 token 相同才能命中中间插一个动态的时间戳、一个随机的会话 ID整段前缀就作废了。我见过不少项目在系统提示里塞了当前时间本意是让模型知道日期结果是缓存一次都没命中白白多花了几倍的钱。正确的做法是把可变内容全部后置。固定的指令、固定的参考资料、固定的工具定义放在最前面逐字不变用户输入、时间、会话信息全部放到后面。这样每次请求的前缀都能命中缓存只有尾部变化的部分按原价计费。改造成本很低收益在长提示场景下非常可观。用数字说明系统提示 2000 token对话 10 轮。不缓存的话系统提示被计费 10 次共 20000 token缓存命中后首次按原价后续 9 次按折扣假设折扣后是原价的 20%等效消耗约 2000 9×400 5600 token省了七成以上。这个差距在规模化之后就是真金白银。5.4 一张能直接用的成本估算表把上面这些要素汇总成一张表方便照着套成本项计算方式常见误区系统提示token × 轮数 × 输入单价或缓存价忘了乘以轮数历史对话累积求和非单轮值按单轮估算低估十倍本轮用户输入分词后长度 消息包装直接用字符数模型输出预估长度 × 输出单价忽略输出溢价工具定义schema 序列化后分词完全没算多模态内容按分辨率/尺寸折算按文件大小折算这张表我建议直接做成配置文件或者代码里的常量结构让估算逻辑和实际请求构造逻辑共用同一份参数。两边分别维护是最容易出错的改了一边忘了另一边预估值就会慢慢漂移。6. 工程落地把 token 预算塞进代码里6.1 请求前的预估与硬截断最基础的一道防线是在发请求之前算一遍超了就拦下来。我通常写一个统一的入口函数所有请求都必须经过它import tiktoken ENC tiktoken.get_encoding(cl100k_base) MSG_OVERHEAD 4 def count_messages(messages): total 0 for m in messages: total len(ENC.encode(m[content], disallowed_special())) total MSG_OVERHEAD return total 3 # 结尾标记的固定开销 def guard(messages, max_input_tokens): n count_messages(messages) if n max_input_tokens: raise ValueError(finput too long: {n} {max_input_tokens}) return n这个函数看起来平淡但它把估算变成了一个不可绕过的关卡。所有请求都从同一个口径算日志里记录的数字才有意义对账的时候才能和账单做比对。我强烈建议把算出来的 token 数和请求 ID 一起写进日志后面做成本归因分析时会感谢自己。硬截断的策略要慎重。按字符截断会切坏语义按 token 截断再decode至少保证是完整的 token 序列但可能截在半句话上。更稳妥的是按段落或按句子切分逐段累加 token超了就停。多花几行代码换来的是不会出现标题被截掉一半这种尴尬情况。6.2 滑动窗口与摘要压缩的组合拳单纯限制轮数会有个问题用户问的早期信息被丢掉了模型回答开始跑偏。我的经验是组合使用两种策略。第一种是滑动窗口保留最近 N 轮原文这是主力保证当前对话的连贯性。N 的取值要看业务客服类场景 5 到 8 轮基本够用复杂任务规划类可能要到 15 轮以上。这个值不要拍脑袋拿真实会话数据跑一遍看回答质量随 N 变化的曲线找到拐点。第二种是摘要压缩把更早的历史压成一段短的背景描述。摘要本身也要花 token一次输出但只做一次之后每轮复用摊薄下来很划算。关键是摘要要保留事实性信息——用户说的关键参数、已经确认的结论、排除掉的方案而丢掉寒暄和过程性的追问。我一般用一段固定的提示词让模型做这件事输出限制在 150 字以内超过就再压一次。两者结合之后长期会话的输入 token 增长会从二次变成近似线性成本就可控了。6.3 监控、对账与异常告警算得再准也需要闭环验证。我的做法是每天拉一次账单数据和日志里记录的 token 统计做比对算偏差率。正常情况下偏差应该在个位数百分比如果某天突然跳到 20% 以上说明有新的输入格式进来了或者估算逻辑过时了。常见的原因有几个一是引入了新的内容类型比如开始传图片、开始用工具调用估算模块没覆盖二是提示词改版长度变了但常量没更新三是编码器和模型不匹配换了模型没换编码。这几种都能通过对账发现。告警阈值我一般设两级单次请求 token 超过阈值的告警用于发现异常长的输入日总量超过预算 80% 的告警用于提前干预。这两个阈值都不难实现但能避免很多月底看账单吓一跳的情况。7. 踩坑实录与排查速查表7.1 几个真实踩过的坑第一个坑是编码器和模型不匹配。项目早期用一套旧编码做估算后来换了模型没同步更新估算值系统性偏低约 18%导致截断逻辑一直没触发反而在服务端偶发超限报错。排查过程很折磨因为本地复现不了最后是打印模型返回的实际用量字段才发现差异。第二个坑是特殊字符导致统计中断。用户输入里带了形如特殊标记的字符串encode直接抛异常整个请求链路挂掉。修复方式就是把统计路径上的disallowed_special设为空元组把这类内容当普通文本处理。这个问题在开放输入的场景下必然会遇到早点处理。第三个坑是缓存不命中。前面提过系统提示里塞了动态时间戳导致前缀每次都不同。改法很简单把时间戳挪到用户消息里命中率立刻从 0 涨到 90% 以上。这个改动花了不到十分钟省下的钱是长期的。第四个坑是按字符数做截断。切出来的文本末尾有半个汉字序列化之后变成乱码模型理解偏差回答质量下降。改成按 token 截断再decode之后就正常了。这个坑的教训是任何涉及文本边界的操作都应该在 token 层面做不要在字符层面做。7.2 排查速查表现象可能原因排查动作账单比预估高 10% 到 20%消息包装、结尾标记未计入给每条消息加固定补偿值账单比预估高数倍多轮历史按单轮估算改成累积求和中文场景偏差特别大用了英文字符系数估算改用分词器实测估算低于实际且稳定偏低编码器与模型不匹配核对模型对应的编码缓存命中率为零前缀含动态内容把可变部分全部后置分词函数偶发抛异常输入含特殊标记统计路径放开特殊标记限制截断后文本出现乱码按字符而非 token 截断改为 encode 截断再 decode某天用量突增无对应流量重试风暴或循环调用检查重试策略与循环退出条件最后一行值得多说两句。重试逻辑写不好会造成 token 消耗的隐性放大请求超时重试原请求其实已经计费了重试又计一次如果重试没有指数退避和次数上限一个故障能在几分钟内烧掉一天的量。我的做法是重试次数上限设为 2 次且只对特定类型的错误重试同时对同一会话的重试做去重标记避免短时间内重复提交相同内容。还有一个细节流式输出的场景下如果客户端提前断开连接服务端可能已经生成了一部分内容并计费。这类消耗在日志里往往没有记录因为它没有正常返回。做对账时如果发现账单略高于日志统计且差额和断连次数正相关基本就是这个原因。处理办法是在客户端记录断连事件和服务端用量做联合分析而不是只盯着一侧的日志。我个人在实际项目里的体会是token 计费这件事的难点从来不在会不会调用分词库而在于有没有把统计口径统一到一个地方。只要所有请求都走同一个入口、同一份常量、同一套日志字段账就一定能对上反过来如果每个业务模块各算各的系数不同、补偿值不同、编码器也可能不同那账单永远是一笔糊涂账花再多时间排查也只是在补窟窿。所以真要做这件事第一优先级是把计算逻辑收敛成一个公共模块剩下的优化才有意义。
1. 先把账算明白token 计费这件事为什么值得单独拎出来聊 token 计费与计算绕不开一个工具tiktoken。很多团队做模型应用第一版跑通之后就开始被账单打脸——功能没问题日志也正常就是费用比预期高出一截而且高得毫无规律。追查下去十有八九是同一个原因对 token 的估算方式还停留在字数除以二这种拍脑袋阶段。这篇文章想做的事情很具体把 token 从一个模糊的计费单位变成一个你能在代码里精确算出、提前预估、事后对账的数值同时把 tiktoken 这个分词库的用法、坑点和工程化封装讲透。文章偏实操面向的是已经接过模型接口、手上有真实调用量、需要控制成本或者做预算评估的开发者以及准备把原型转成正式产品的团队。纯理论的部分我会点到为止重点放在怎么算准怎么算省怎么对得上账这三件事上。先说清楚 token 这个东西的定位。它是模型处理文本的最小切分单位既不是字符也不是单词更不是汉字。模型内部没有字的概念它看到的是一串整数编号每个编号对应词表里的一个条目。这个条目可能是一个完整的英文单词可能是单词的一部分可能是一个汉字也可能是两三个汉字凑成的一个组合甚至可能只是半个标点。计费系统统计的就是这些编号的个数所以我这段文本才 800 字怎么算了 1600 个 token这种事非常正常尤其是在中英混排、代码片段、emoji 混入的场景下偏差会大到让你怀疑接口在乱扣费。为什么要把计费单独拎出来说而不是直接看账单因为账单是滞后的。一次调用发出去了钱就花掉了你事后看到数字只能接受。真正的成本控制在请求发出之前就已经完成你要能预估这次请求大概多少 token能不能塞进上下文窗口塞不进去要怎么裁剪裁剪之后语义还够不够。这些判断全依赖准确的 token 计算能力。tiktoken 就是目前最主流的离线计算方案之一它把分词逻辑搬到本地让你在发请求之前就能得到一个足够接近官方计费口径的数字不需要联网也不需要消耗额度试探。还有一个容易被忽略的点token 数不只是钱的问题它同时是上下文窗口的硬边界。窗口塞满了请求直接报错或者历史被静默截断导致模型失忆这两种结果在生产环境里都比多花点钱更难处理。所以把 token 计算做扎实等于同时解决了成本、容量、体验三件事投入产出比相当高。2. token 到底是什么从 BPE 分词讲起2.1 模型眼里的文本是整数序列不是文字要理解计费先得接受一个反直觉的事实模型从来没有读过你的文字。文本进入模型之前会经过一个分词器被转换成一串整数 ID。比如一段文本可能变成[1234, 56, 7890, 23, ...]这样的序列模型的所有计算都建立在这串整数上。输出的时候再反向解码回文字。所谓 token就是这串整数里的每一个数字对应的那一小块文本。这个设计不是偷懒而是效率上的必然。如果按字符切分那么每个字符都要一个编号词表会膨胀得极其夸张而且模型要处理的序列长度会变得很长注意力计算的成本随长度平方增长根本扛不住。如果按单词切分词表又会无限大——新词、拼写错误、专有名词、代码符号永远收录不完一旦遇到词表外的词就只能退化成未知标记信息直接丢失。所以业界普遍采用折中方案子词切分。常见的高频词整体保留成一个 token低频词拆成若干常见片段极端情况下退到字节级别。这样词表规模可控又能覆盖任意文本。2.2 BPE 的合并逻辑用一句话讲明白目前主流方案是 BPE字节对编码。它的训练过程非常朴素先把所有文本拆成单个字节然后统计相邻两个片段一起出现的频率把频率最高的一对合并成一个新片段加进词表重复这个过程直到词表达到预设大小。最终得到的就是一份从高频组合到低频组合的分层词表。这个机制解释了一个很多人困惑的现象同样长度的文本token 数差异巨大。原因是文本里的片段和词表的熟悉度不同。高频词、常见搭配、常用汉字组合往往能整体命中一个大 token一个 token 顶好几个字符生僻词、随机字符串、复杂代码表达式只能被拆成碎片一个字符可能要占一个甚至多个 token。你去看模型处理一串随机生成的十六进制字符串token 数经常会接近字符数甚至更多因为这种内容在训练语料里出现频率低词表里没有对应的组合。用生活类比可能更好理解假设你有一本常用语缩写词典看到中华人民共和国能直接翻到一个条目这就是 1 个 token看到魑魅魍魉没有对应条目只能一个字一个字查这就是 4 个 token。词典的收词范围决定了你的压缩率而不同模型用的词典大小和收词偏好都不一样这正是后面要强调编码器必须和模型匹配的根本原因。2.3 中文的 token 密度和你的直觉差多少英文场景下的经验值流传很广1 个 token 大约等于 4 个字符或者 0.75 个单词。这个数字在很多资料里被反复引用然后被直接套到中文上结果就是严重低估。中文的字符信息密度高一个汉字承载的语义远多于一个英文字母所以在词表设计上中文往往需要多个 token 才能表示一个汉字具体取决于该字在语料中的常见程度。我的实测经验是现代编码器下一段纯中文散文平均每个汉字大约消耗 1 到 1.5 个 token如果是常见成语、高频双字词压缩率会好一些接近 1 个汉字 1 个 token如果是古文、生僻字、专业术语密集的段落会往 1.5 甚至更高走。这意味着一篇 2000 字的中文文章token 数大概在 2200 到 3000 之间浮动而不是很多人以为的 1000 出头。如果这段文本还要作为多轮对话的历史反复回传这个低估会被放大好几倍。更麻烦的是混合内容。一份典型的技术文档里中文说明、英文术语、代码块、表格符号、URL 混在一起各段的 token 密度差异极大。你不能用整篇的平均值去推算某个片段必须逐段计算或者整体一次性算准。这就是为什么我一直建议不要用估值系数直接用分词器算。估值系数只适合做量级判断绝对不能用来做预算和截断决策。3. tiktoken 上手安装、编码选择与基础 API3.1 安装与第一段能跑的代码tiktoken 是一个纯 Python 实现的分词库安装很轻量不需要额外的模型权重下载词表文件会随包一起打包或者在首次使用时拉取。基础用法三行就能跑通pip install tiktokenimport tiktoken enc tiktoken.get_encoding(cl100k_base) tokens enc.encode(今天我们来聊聊 token 计费这件事。) print(len(tokens)) # token 数量 print(tokens) # 整数 ID 列表 print(enc.decode(tokens)) # 还原成文本这段代码打印出来的 token 数就是你该拿去和账单对齐的数字。注意encode返回的是一个整数列表len()得到的就是数量不要对字符串直接取长度那是字符数和 token 数完全是两码事。我在代码评审里见过不止一次把len(text)当成 token 数写进日志的排查了半天以为接口多扣费最后发现是自己统计口径错了。decode这个接口值得单独提一句。它不是完全可逆的某些 token 组合解码回来可能和原文有细微差别尤其是包含不规范空白字符、特殊控制符的文本。所以如果你要做截断到指定 token 数再还原成文本这类操作务必用decode的结果而不是自己按字符切片否则很容易切出半个汉字或者半个转义序列。3.2 编码器选错账就永远对不上tiktoken 内部维护了多套编码方案常见的有r50k_base、p50k_base、cl100k_base、o200k_base这几类。它们对应不同的词表规模和训练语料压缩率差异明显尤其是中文场景下新旧编码的 token 数能差出 20% 以上。用旧编码去估算新模型的实际消耗结果就是系统性偏差而且偏差方向固定你越算越觉得哪里不对。正确的做法是让编码器和模型对齐。tiktoken 提供了按模型标识获取编码器的接口import tiktoken # 传入你实际调用的模型标识 enc tiktoken.encoding_for_model(你的模型标识)如果这个接口不认识你用的模型标识新模型上线快库的更新往往滞后它会抛异常。这时候有两个选择一是查官方文档确认该模型对应哪套编码手动用get_encoding指定二是用一个已知的、词表规模接近的编码做近似估算同时把误差系数记录下来。第二种做法属于权宜之计只适合做趋势监控不适合做精确对账。我自己的习惯是在项目配置里显式写死编码名而不是每次动态推断。理由是动态推断依赖库版本某次升级之后行为可能变化导致历史数据和新数据不可比。写死之后至少在同一个统计口径下数据是连续可比较的。3.3 特殊 token 与允许列表encode有两个参数经常被忽略allowed_special和disallowed_special。默认情况下如果文本里出现了形如|endoftext|这种特殊标记encode会直接报错防止用户无意中注入控制符。这个默认行为在安全上是对的但在做统计的时候会带来麻烦——你的用户输入里如果恰好包含类似字符串计算就会中断。# 统计场景下通常希望把特殊标记当普通文本处理 n len(enc.encode(text, disallowed_special())) # 如果是构造对话模板需要显式允许 n len(enc.encode(text, allowed_special{|endoftext|}))我建议在纯统计路径上统一用disallowed_special()把所有特殊标记当普通字符处理这样统计逻辑永远不会因为输入内容而抛异常。而在真正拼接请求体的路径上则要严格按接口要求处理特殊标记两者不要混用。4. 对话场景下的真实 token 开销4.1 每条消息都有结构性包装开销很多人算 token 只算正文然后发现账单永远比预估高一截。差额主要来自消息包装。对话接口不是把裸文本直接喂进去的每条消息外面都包了一层结构标记用来区分角色、划分边界。这些标记本身也占 token通常每条消息固定开销在 3 到 5 个 token 左右具体数字取决于模型和模板。单条看不明显但在多轮对话里会累积。一轮对话两条消息用户一条、助手一条假设固定开销 4 token十轮就是 80 token。这个量级不算大但如果你在做大批量短消息处理比如一次请求塞进去 50 条历史消息做摘要那就是 200 token 的纯结构开销可能占到总输入的相当比例。我一般的处理方式是给每条消息额外加一个固定补偿值写成一个常量放在配置里比如MESSAGE_OVERHEAD 4统计时用正文 token MESSAGE_OVERHEAD。这个值不需要特别精确方向和量级对了就行因为它的目的在于让预估和账单落在同一个数量级上而不是做到分毫不差。4.2 中文对话的抽样测量为了让数字更具体我做了一组简单的抽样。取若干条典型的中文用户提问长度从 10 字到 200 字不等混合少量英文术语用现代编码器统计文本类型字符数token 数每字 token 比短问句口语化15181.20中等提问含术语80961.20长段描述技术向2002681.34纯英文句子60160.27代码片段1201451.21这组数据不追求普适性只是说明一个结论中文的 token 密度普遍高于 1长文本、术语密集的文本会更高英文的密度远低于 1代码介于两者之间符号多、缩进多的时候会显著上升。你可以在自己的业务语料上做同样的抽样得到属于你的系数然后写进估算函数里做兜底校验——分词器算出来的结果和系数估算结果差太多的时候打个警告能帮你发现意料之外的输入格式。4.3 图片、函数调用这些非纯文本开销只要你的应用涉及多模态或者工具调用token 计算就没法只靠文本分词搞定。图片通常按分辨率折算成一定数量的 token不同模型的分块策略不同同一张图在不同参数下消耗能差好几倍。函数调用的定义体名称、描述、参数 schema是实打实要计入输入的而且这些描述往往是自然语言写的长度不小。一段写得啰嗦的工具描述可能比你实际的用户提问还长。这部分开销我建议单独建一个估算模块不要和文本分词混在一起。文本走 tiktoken非文本走查表加规则最后汇总。这样某一块的逻辑变化时不会影响到另一块排查问题也容易定位。5. 计费公式拆解与成本建模5.1 输入和输出不是一个价几乎所有模型服务都对输入和输出采用不同单价输出通常更贵倍率一般在 2 到 4 倍之间。这个设计有其合理性输出是逐 token 生成的每一步都要跑一次前向计算而输入可以并行处理。但对使用者来说这意味着让模型多说几句的成本远高于多给模型看几段材料。这个特性直接影响了产品设计。比如摘要场景如果你让模型输出一份详细的结构化分析成本可能是让它输出三行结论的几倍反过来如果你想省钱把更多信息塞进输入让模型照着提炼通常比让它自己发挥更划算。我见过一些团队把输入裁得很狠、输出放得很开结果成本反而更高因为输出的单价摆在那里。用公式表达一次调用的成本更直观单次成本 输入token × 输入单价 输出token × 输出单价做预算的时候把输出 token 按最大长度估输入按实际长度估得到的是成本上界。这个上界在批量任务里非常有用可以直接回答这批数据跑完最多花多少这个问题。5.2 多轮对话的累积增长比你想的陡这是最容易翻车的地方。第一轮请求输入只有用户那句话第二轮请求输入是第一轮的用户话 助手回复 第二轮用户话第三轮继续累加。服务端不保存你的会话状态每一轮你都要把完整历史重新发一遍也就要重新计费一遍。做个具体的算术。假设每轮用户输入 200 token助手输出 300 token固定系统提示 500 token一共聊 10 轮。第 n 轮的输入 token 数 500系统 200本轮用户 前 n-1 轮的 (200 300)第 1 轮500 200 700 第 2 轮500 200 500 1200 第 3 轮500 200 1000 1700 …… 第 10 轮500 200 4500 5200总输入 700 1200 ... 5200等差数列10 项平均 2950合计 29500。 总输出 10 × 300 3000。如果按单轮视角粗算你可能以为总共只用了 2000 输入 3000 输出实际输入是 29500差了将近 15 倍。这个增长是二次的轮数越多越夸张。二十轮对话的输入总量会是十轮的三倍多而不是两倍。理解了这一点你就明白为什么限制历史轮数和压缩历史内容是必备的工程手段而不是可选项。我通常的做法是保留最近 N 轮原文更早的轮次做摘要摘要长度控制在原文的 20% 以内并且只在语义确实需要的时候才带上。5.3 缓存机制带来的折扣要用对才划算现在不少服务提供了前缀缓存如果本次请求的开头部分和之前某次请求完全一致这部分内容可以按折扣价计费折扣力度通常很大。这个机制对固定系统提示、固定知识库片段、固定工具定义的场景极其友好。关键在于完全一致这四个字。前缀必须逐 token 相同才能命中中间插一个动态的时间戳、一个随机的会话 ID整段前缀就作废了。我见过不少项目在系统提示里塞了当前时间本意是让模型知道日期结果是缓存一次都没命中白白多花了几倍的钱。正确的做法是把可变内容全部后置。固定的指令、固定的参考资料、固定的工具定义放在最前面逐字不变用户输入、时间、会话信息全部放到后面。这样每次请求的前缀都能命中缓存只有尾部变化的部分按原价计费。改造成本很低收益在长提示场景下非常可观。用数字说明系统提示 2000 token对话 10 轮。不缓存的话系统提示被计费 10 次共 20000 token缓存命中后首次按原价后续 9 次按折扣假设折扣后是原价的 20%等效消耗约 2000 9×400 5600 token省了七成以上。这个差距在规模化之后就是真金白银。5.4 一张能直接用的成本估算表把上面这些要素汇总成一张表方便照着套成本项计算方式常见误区系统提示token × 轮数 × 输入单价或缓存价忘了乘以轮数历史对话累积求和非单轮值按单轮估算低估十倍本轮用户输入分词后长度 消息包装直接用字符数模型输出预估长度 × 输出单价忽略输出溢价工具定义schema 序列化后分词完全没算多模态内容按分辨率/尺寸折算按文件大小折算这张表我建议直接做成配置文件或者代码里的常量结构让估算逻辑和实际请求构造逻辑共用同一份参数。两边分别维护是最容易出错的改了一边忘了另一边预估值就会慢慢漂移。6. 工程落地把 token 预算塞进代码里6.1 请求前的预估与硬截断最基础的一道防线是在发请求之前算一遍超了就拦下来。我通常写一个统一的入口函数所有请求都必须经过它import tiktoken ENC tiktoken.get_encoding(cl100k_base) MSG_OVERHEAD 4 def count_messages(messages): total 0 for m in messages: total len(ENC.encode(m[content], disallowed_special())) total MSG_OVERHEAD return total 3 # 结尾标记的固定开销 def guard(messages, max_input_tokens): n count_messages(messages) if n max_input_tokens: raise ValueError(finput too long: {n} {max_input_tokens}) return n这个函数看起来平淡但它把估算变成了一个不可绕过的关卡。所有请求都从同一个口径算日志里记录的数字才有意义对账的时候才能和账单做比对。我强烈建议把算出来的 token 数和请求 ID 一起写进日志后面做成本归因分析时会感谢自己。硬截断的策略要慎重。按字符截断会切坏语义按 token 截断再decode至少保证是完整的 token 序列但可能截在半句话上。更稳妥的是按段落或按句子切分逐段累加 token超了就停。多花几行代码换来的是不会出现标题被截掉一半这种尴尬情况。6.2 滑动窗口与摘要压缩的组合拳单纯限制轮数会有个问题用户问的早期信息被丢掉了模型回答开始跑偏。我的经验是组合使用两种策略。第一种是滑动窗口保留最近 N 轮原文这是主力保证当前对话的连贯性。N 的取值要看业务客服类场景 5 到 8 轮基本够用复杂任务规划类可能要到 15 轮以上。这个值不要拍脑袋拿真实会话数据跑一遍看回答质量随 N 变化的曲线找到拐点。第二种是摘要压缩把更早的历史压成一段短的背景描述。摘要本身也要花 token一次输出但只做一次之后每轮复用摊薄下来很划算。关键是摘要要保留事实性信息——用户说的关键参数、已经确认的结论、排除掉的方案而丢掉寒暄和过程性的追问。我一般用一段固定的提示词让模型做这件事输出限制在 150 字以内超过就再压一次。两者结合之后长期会话的输入 token 增长会从二次变成近似线性成本就可控了。6.3 监控、对账与异常告警算得再准也需要闭环验证。我的做法是每天拉一次账单数据和日志里记录的 token 统计做比对算偏差率。正常情况下偏差应该在个位数百分比如果某天突然跳到 20% 以上说明有新的输入格式进来了或者估算逻辑过时了。常见的原因有几个一是引入了新的内容类型比如开始传图片、开始用工具调用估算模块没覆盖二是提示词改版长度变了但常量没更新三是编码器和模型不匹配换了模型没换编码。这几种都能通过对账发现。告警阈值我一般设两级单次请求 token 超过阈值的告警用于发现异常长的输入日总量超过预算 80% 的告警用于提前干预。这两个阈值都不难实现但能避免很多月底看账单吓一跳的情况。7. 踩坑实录与排查速查表7.1 几个真实踩过的坑第一个坑是编码器和模型不匹配。项目早期用一套旧编码做估算后来换了模型没同步更新估算值系统性偏低约 18%导致截断逻辑一直没触发反而在服务端偶发超限报错。排查过程很折磨因为本地复现不了最后是打印模型返回的实际用量字段才发现差异。第二个坑是特殊字符导致统计中断。用户输入里带了形如特殊标记的字符串encode直接抛异常整个请求链路挂掉。修复方式就是把统计路径上的disallowed_special设为空元组把这类内容当普通文本处理。这个问题在开放输入的场景下必然会遇到早点处理。第三个坑是缓存不命中。前面提过系统提示里塞了动态时间戳导致前缀每次都不同。改法很简单把时间戳挪到用户消息里命中率立刻从 0 涨到 90% 以上。这个改动花了不到十分钟省下的钱是长期的。第四个坑是按字符数做截断。切出来的文本末尾有半个汉字序列化之后变成乱码模型理解偏差回答质量下降。改成按 token 截断再decode之后就正常了。这个坑的教训是任何涉及文本边界的操作都应该在 token 层面做不要在字符层面做。7.2 排查速查表现象可能原因排查动作账单比预估高 10% 到 20%消息包装、结尾标记未计入给每条消息加固定补偿值账单比预估高数倍多轮历史按单轮估算改成累积求和中文场景偏差特别大用了英文字符系数估算改用分词器实测估算低于实际且稳定偏低编码器与模型不匹配核对模型对应的编码缓存命中率为零前缀含动态内容把可变部分全部后置分词函数偶发抛异常输入含特殊标记统计路径放开特殊标记限制截断后文本出现乱码按字符而非 token 截断改为 encode 截断再 decode某天用量突增无对应流量重试风暴或循环调用检查重试策略与循环退出条件最后一行值得多说两句。重试逻辑写不好会造成 token 消耗的隐性放大请求超时重试原请求其实已经计费了重试又计一次如果重试没有指数退避和次数上限一个故障能在几分钟内烧掉一天的量。我的做法是重试次数上限设为 2 次且只对特定类型的错误重试同时对同一会话的重试做去重标记避免短时间内重复提交相同内容。还有一个细节流式输出的场景下如果客户端提前断开连接服务端可能已经生成了一部分内容并计费。这类消耗在日志里往往没有记录因为它没有正常返回。做对账时如果发现账单略高于日志统计且差额和断连次数正相关基本就是这个原因。处理办法是在客户端记录断连事件和服务端用量做联合分析而不是只盯着一侧的日志。我个人在实际项目里的体会是token 计费这件事的难点从来不在会不会调用分词库而在于有没有把统计口径统一到一个地方。只要所有请求都走同一个入口、同一份常量、同一套日志字段账就一定能对上反过来如果每个业务模块各算各的系数不同、补偿值不同、编码器也可能不同那账单永远是一笔糊涂账花再多时间排查也只是在补窟窿。所以真要做这件事第一优先级是把计算逻辑收敛成一个公共模块剩下的优化才有意义。
