破坏生产级 LLM 系统的分词器盲点

大多数构建 LLM 的工程师最终都会学到一个粗略的换算比例：1 个 Token 大约等于 0.75 个英文单词，因此 4,000 个 Token 的上下文窗口大约可以容纳 3,000 个单词。当你的输入是日常英文文本时，这个数字用于粗略估算还可以。但在其他任何地方，它都是悄无声息地错误——而事实证明，“其他任何地方”涵盖了大多数有趣的生产环境负载。

Token 计算错误不会大声报错。它们表现为与任何账单项目都不匹配的成本超支、上下文窗口悄悄截断了文档的最后几段，或者是多语言流水线在英文测试中表现良好，但在遇到真实流量的第一周就超出了 4 倍预算。当你追溯到 Tokenizer 分词问题时，损失已经造成。

这篇文章将探讨那些会坑害生产系统的特定故障模式——不是为了研究 Tokenizer 内部原理本身，而是为了揭示将 Tokenizer 视为黑盒会让你在金钱、可靠性或两者上付出代价的地方。

“每 1000 个 Token 换算 750 个单词”的迷思及其破灭

0.75 的比例是使用 OpenAI 的 cl100k_base Tokenizer 针对英文散文进行校准的。对于干净的英文新闻文章和博客文章，它保持得相当好。但在以下四种常见情况下，它会失效。

不同模型的分词方式不同。 句子 "Artificial intelligence is transforming industries" 在 GPT-4 中产生 6 个 Token，在 Claude 3 中产生 7 个，在 Llama 2 中产生 8 个。如果你针对一个模型估算 Token 数量并在另一个模型上运行，你已经错了。当模型更新发布新的 Tokenizer 时，相同的工作负载每字符成本可能会在一夜之间增加 2 倍以上——这是一个让工程团队措手不及的真实案例。

代码的 Token 密度比散文高 1.5–2.5 倍。 语法字符（括号、分号、方括号）每个都会消耗 Token。驼峰式 (CamelCase) 和蛇形 (snake_case) 标识符不像重复的自然语言模式那样可以高效压缩。在许多 Tokenizer 中，缩进也被计为 Token。一个提取 20 个代码片段的 RAG 系统平均比等量的文档散文多消耗大约 40% 的 Token——这足以让调优良好的上下文预算超出限制。

JSON 和结构化格式带来了沉重的开销。 每个大括号、引号、冒号和逗号都是一个 Token 或其一部分。与相同表格数据的 CSV 编码相比，JSON 使用的 Token 多 30–60%。如果你的流水线检索结构化数据并在注入上下文之前将其格式化为 JSON，那么你在为每次请求支付高额溢价。数字的碎片化也很严重："3.14159" 经常被拆分为多个 Token，使得数值密集型格式的成本高得不成比例。

输出 Token 的成本高于输入 Token。 大多数供应商对输出 Token 的收费是输入 Token 的 2–3 倍。生成 1,000 个输出 Token 的成本不是 1,000 个输入 Token 的 2 倍——通常是 3 倍或更多。基于单一 Token 费率建立的成本模型，其低估程度会随着输出字数的增加而扩大。

多语言 Token 膨胀不容忽视

英语与非拉丁语系语言在 Token 效率上的巨大差异，已经大到足以成为产品层面的关注点，而不仅仅是一个奇闻。

以下是主要语系相对于英语的近似 Token 倍数：

语言	近似倍数
西班牙语、法语	1.0–1.2x
俄语、希伯来语	~1.5x
简体中文	~1.8x
日语	~2.1x
韩语	~2.4x
阿拉伯语	~2.5x
印地语	~4.7x
泰米尔语	~7.2x

这些数字来自于主要针对英文文本（在网络爬虫数据集中占主导地位）训练的 Tokenizer。像“猫”这样的汉字在 cl100k_base 中需要 2–3 个 Token，因为 BPE 词汇表是基于一个中日韩（CJK）字符代表性不足的语料库构建的。英语受益于高效的子词压缩；而非拉丁语系通常按字符或以小的字节级分块进行分词。

生产环境的影响是巨大的。一家为全球用户构建 AI 功能的 SaaS 公司，其英文流量的经济效益可能尚可，但在泰米尔语的同等交互中成本会激增 7 倍。由于这种成本并不对应于可见的功能或服务，它往往表现为基础设施支出中的异常账单，而不是产品漏洞——这意味着它通常会被忽视数月之久。

对于多语言工作负载，唯一可靠的方法是在发布前测量真实流量样本中每种语言的 Token 数量。根据你的语言组合，0.75 规则会导致你的容量规划出现 2–7 倍的偏差。

加载中…