上周三晚上十点多产品老哥拿着报表来找我咱们这个 AI 摘要功能上线一个月账单是预估的两倍多是不是模型又偷偷涨价了我第一反应也是去查价格页翻了一圈没发现调价记录。后来把调用日志导出来一条条对才发现问题出在我自己身上——我当时预估成本是拿一条摘要大概两百个字去乘单价算的心里默认一个汉字就是一个 token词元大模型处理文本的最小单位。天真了。得先说清楚一件事大模型从头到尾就没见过你打的那个字。你发出去的文本会先被 tokenizer分词器切成一块块 token每个 token 对应词表里的一个编号模型啃的是这些编号。主流模型用的 BPEbyte pair encoding字节对编码一种按使用频率合并字符的压缩式分词算法是从海量语料里统计出来的——高频搭配合成一块低频的就被拆得七零八落。所以 token 既不是字也不是词它的边界完全由统计频率决定跟你我的语感没有半毛钱关系。这对成本意味着什么我后来在项目里实测过同一段中文一个汉字大约吃 1 到 1.5 个 token英文那边themodel这种高频词一个抵 1 个 token但tokenization这种生僻词会被切成三四块。更坑的是代码和混合文本——缩进空格、标点、大小写来回切都会让 token 数往上蹿。我当时按字数≈token 数做的预算实测比例是 1.6 倍账单自然对不上。后来我把日志全量回放了一遍用各家的官方计数工具重新数才把新预算定准。写到这儿插一句产品老哥听完这个结论沉默了几秒来了句那你当时拍着胸脯说预算够用的时候怎么不再多拍两下。行吧这锅我背。token 这东西不光掏你的钱包还直接影响模型的智商。你可能刷到过那个名场面让大模型数strawberry里有几个 r它张口就是 2 个正确答案是 3 个。我一开始也当乐子看后来自己琢磨明白才笑不出来——模型看到的根本不是 s-t-r-a-w 这些字母而是一整个strawberry对应的编号。让它数字母就像让你隔着没拆封的罐头数里面有几颗草莓只能凭印象猜。顺着这个思路我复盘出了另一个以前一直归因为模型数学不行的坑大数运算翻车。我们有个内部小工具让模型算单据金额合计几千块以内基本对一到六七位数出错率就开始飙升。排查后发现原因之一长数字经常被 tokenizer 从中间切开比如1234567可能被切成123和4567两块模型是对块做运算的每一位的进位关系早就模糊了。后来我们在提示词里要求先把金额按千分位拆开、逐段相加或者干脆把算术扔给计算器工具错误率才压下来。还有一个更隐蔽的坑藏在 max_tokens最大输出 token 数这个参数里。我有次让模型输出 JSON看返回内容差不多写完了就把输出上限设了个自以为很宽裕的值。结果线上偶发解析失败排查了一晚上才发现被截断的那几条都是输出里夹着英文药名和长数字的记录——同样的字数token 数比别人多出一截正好顶到上限JSON 被拦腰截断。教训很实在设 max_tokens 不能按感觉内容长度来得按 token 算而且要给非纯中文的内容留更大余量。你以为这就完了还有更麻烦的每家的分词器都不一样。同样一千字的中文在 A 家模型上是 1200 个 token换到 B 家可能变成 1500 个。也就是说你换模型供应商不光接口要改成本模型、max_tokens 配置、上下文长度的预估全部要重算一遍。我们上次从一家模型切到另一家我就把这茬忘了监控里的成本曲线直接抬走我还以为对方计费口径有猫腻差点找人家客服对线对完才发现是我自己预估的 token 比例过时了。说实话tokenizer 这一层是整个大模型技术栈里用户最没得选的部分。你不喜欢它的切法没有任何配置项能改各家标准不统一连上下文 128K这句话的含金量都因此变得可疑——同样 128K 的窗口中文能实际塞进去的内容量各家能差出 20% 以上。对中文用户来说这笔隐形的语言税短期内看不到头。现在我做新项目的成本预估第一步不再是查价格表而是先拿真实样本去数 token。这个习惯起码救了我两次预算事故。你呢有没有被 token 数坑过——账单超了、输出被拦腰截断、还是眼睁睁看模型数错字母评论区聊聊让我看看还有多少人跟我一样曾经以为一个字就是一个 token。