一句话解释

Token 是大语言模型处理文本的最小单位，可以理解为模型眼里的“字词碎片”。模型读进来的是 Token，吐出去的也是 Token；而模型每处理一个 Token 都要消耗算力，所以服务商按 Token 数量收费。

模型为什么不直接读“字”

计算机只认识数字。要让模型处理文字，首先得把文本切成一个个单元，再把每个单元映射成编号，这一步叫“分词”（Tokenization）。

切分的粒度有几种选择：

  • 按字符切：词表很小，但序列会非常长，模型要花更多步骤才能“读完”一句话。
  • 按完整单词切：序列短，但词表会大到难以承受，而且遇到新词、拼写错误就无能为力。
  • 按子词切：介于两者之间，也是目前主流大模型的做法。常见词保留为一个整体，少见词拆成几个更小的片段。

子词分词的典型算法包括 BPE（字节对编码）及其变体。它的大致思路是：从单个字符或字节开始，统计训练语料里最常相邻出现的组合，不断把它们合并成新的词表单元，直到词表达到预定大小。于是“the”“ing”这种高频片段会成为单独的 Token，而一个罕见的专业词汇可能被拆成三四块。

一个 Token 大概是多少字

这没有固定答案，取决于具体模型的分词器和文本内容。一般规律是：

  • 英文：常见单词通常是一个 Token，长词或罕见词会被拆开，空格和标点也会占用 Token。
  • 中文：不同分词器差别较大。早期的一些分词器对中文支持较弱，一个汉字可能占不止一个 Token；较新的模型普遍扩充了中文词表，常用词可以合并成一个 Token。
  • 代码、数字、表情符号：往往比普通文本更“费” Token。

所以同一段话，在不同模型里计出的 Token 数可能不一样。想知道准确数字，最可靠的方法是使用服务商提供的分词工具或接口返回的用量统计。

Token 和上下文窗口

模型能“同时看到”的内容是有上限的，这个上限叫上下文窗口，单位同样是 Token。它包括：系统提示词、历史对话、你上传的文档、工具返回的结果，以及模型正在生成的回答。

超出窗口的内容，模型就看不到了。这也是为什么长对话聊久了，模型可能“忘记”最开始说过的话：应用为了腾出空间，往往会截断或压缩早期内容。

为什么按 Token 计费

大模型的计算成本与处理的 Token 数直接相关：

输入要计算。 模型需要把你发来的每个 Token 都“读”一遍，计算它们之间的关系。输入越长，计算量越大。

输出更贵。 模型生成回答是一个 Token 接一个 Token 地进行的，每生成一个都要完整地跑一次推理。因此多数服务商对输出 Token 的单价高于输入 Token。

按量计费更公平。 有人只问一句“你好”，有人上传整本书让模型总结，按次收费很难兼顾。按 Token 计费让成本与实际使用量对应起来。

很多服务商还提供“提示缓存”之类的机制：如果多次请求的开头部分完全相同（比如同一段很长的系统提示词），重复的部分可以按更低价格计费。具体规则以各家文档为准。

怎么估算和节省 Token

  • 精简提示词：去掉重复的说明和无关的背景材料。
  • 控制历史长度：多轮对话时，只保留必要的上下文，或把早期内容总结成摘要。
  • 限制输出长度：明确要求“用三句话回答”，或通过参数设置最大输出 Token 数。
  • 按需检索：与其把整份文档贴进去，不如先检索出相关段落再交给模型。
  • 选择合适的模型：简单任务用更小、更便宜的模型就够了。
  • 看用量统计：API 返回结果中通常会附带本次输入、输出各用了多少 Token，以此为准做预算。

常见误区

误区一：一个 Token 就是一个字或一个单词。 Token 是分词器切出来的片段，可能是一个字、半个单词，也可能是一个常用词组。

误区二：所有模型的 Token 数都一样。 不同模型使用不同的分词器，同一段文本的计数可能明显不同，比较价格时要考虑这一点。

误区三：只有我输入的内容才算钱。 系统提示词、对话历史、工具调用结果和模型的输出都会计入；对于会进行内部推理的模型，推理过程产生的 Token 通常也会计费。

误区四：上下文窗口越大越好，可以随便塞。 窗口大意味着能装更多，但塞得越多费用越高、响应越慢，模型在海量信息里抓重点的能力也可能下降。

延伸阅读