拼写错误的隐藏成本：人类打字习惯如何推高 Token 数量

与大语言模型 (LLM) 交互时，大多数用户都专注于提示词工程 (prompt engineering) 的质量，以获得最佳结果。然而，在模型处理文本含义之前，存在一个隐藏的效率层：分词 (tokenization)。

分词器根据其训练数据中发现的常见模式将文本拆分为块。由于服务商按 token 计费，我们自然的打字方式——包含拼写错误、缩写和对话填充词——在不改变消息意图的情况下，会直接影响 API 调用的成本。对于任何正在优化自动化流水线或高吞吐量 LLM 使用场景的人来说，理解人类打字习惯与分词器逻辑之间的差距至关重要。

拼写错误带来的 Token 税

人类为了速度和语气而打字，这往往会导致字母交换、字符缺失或按错相邻按键。虽然人类读者（通常 LLM 本身也可以）可以轻松推断出预期的单词，但分词器看到的却是一个它无法识别的模式。

常用的单词通常会被压缩成单个 token。而较罕见的拼写，例如拼写错误，则会碎裂成多个 token。例如：

  • template $\rightarrow$ 1 token
  • tempalte $\rightarrow$ 3 tokens
  • assistant $\rightarrow$ 1 token
  • assitant $\rightarrow$ 2-3 tokens

在编程语境下，这种效应会成倍增加。一个出现在声明、引用、日志和 diff 中的拼写错误的变量或函数名，会显著推高输入到提示词中的代码库的 token 数量。

词形与后缀

单词末尾的微小变化会导致 token 数量不成比例的跳跃。对人类来说看似无害的微小后缀，可能会导致分词器将一个单词拆分为几个部分。

考虑以下示例：

  • describe $\rightarrow$ 1 token
  • describer $\rightarrow$ 2 tokens
  • describers $\rightarrow$ 3 tokens

这表明分词器对单词的具体“形状”高度敏感，即使只增加几个字母，也可能将一个单词从常见模式转变为碎片化的模式。

对话噪声的成本

人类的聊天自然充满了低信号的填充内容。虽然这些元素增加了语气和礼貌感，但它们很少对当前任务有所贡献，且总是会增加账单金额。

低信号填充

  • 填充词 (Fillers): 像 just, basically, actually, 和 really 这样的词。
  • 套话 (Hedges): 像 maybe, I think, kind of, 或 sort of 这样的短语。
  • 包装词 (Wrappers): 礼貌的开头和结尾，如 hey, please, thanks, 和 sorry。
  • 尾缀 (Tails): 悬挂短语，如 etc., or so, 和 and all that。
  • 聊天噪声 (Chat Noise): 表达性的标点符号和俚语，例如 lol, haha, ..., !!, 和 ??。

表达习惯

即使是我们强调单词的方式也会增加成本。虽然 Good 是 1 token，但 Good... 变成了 2 个。同样，yes 是 1 token，但 yesss 可能跳到 3 个 token。

缩写的悖论

人类经常为了减少按键次数而进行优化，认为较短的文本等于较低的成本。然而，分词器是针对常见文本进行优化的，而不是针对短文本。标准字典单词更有可能成为单个 token，因为它们在训练数据中频繁出现。

使用缩写通常会导致比全称更多的 token：

  • please $\rightarrow$ 1 token / pls $\rightarrow$ 2 tokens
  • thanks $\rightarrow$ 1 token / thx $\rightarrow$ 2 tokens
  • without $\rightarrow$ 1 token / w/o $\rightarrow$ 2-3 tokens

静默 Token 泄漏

除了对话习惯，技术数据通常会产生“token 泄漏”——即本质上很长且碎片化的字符串。

  • 标识符 (Identifiers): UUIDs, hashes, 和 request IDs 是出了名的昂贵。单个 UUID 可能耗费 24-26 个 token。
  • 时间戳 (Timestamps): 一个 RFC 3339 时间戳（例如 2026-05-08T21:00:00+05:30）可能耗费 16-17 个 token。
  • 基础设施 (Infrastructure): 长 URL 和文件路径，以及不规则的前导或尾随空格，也会进一步推高计数。

结论：效率 vs. 理智

这里的根本矛盾在于，虽然模型可以从混乱的人类输入中恢复含义，但计费系统却不能。

正如社区讨论中所提到的，关于这种程度的优化对于手动提示词是否实际，存在争议。一位评论者指出，在实时聊天会话中纠正每一个拼写错误以节省几分钱可能是在“让自己发疯”。然而，对于构建自动化流水线、摄取大量文档或管理高吞吐量 agentic workflows 的开发者来说，这些“泄漏”不再是微不足道的。它们代表了一种系统性的低效，可以通过在数据到达分词器之前进行清洗来解决。

Sources