AI Token 术语表

Token 是语言模型读取和生成的最小单位。现代 LLM 并不逐个处理字符或完整单词，而是将文本拆分为子词片段，并为每个片段分配一个整数 ID。模型此后完全基于这些 ID 进行运算。

在英语中，一个 token 大约相当于 4 个字符，或约四分之三个单词。诸如“the”“is”“in”这类简短的常用词通常各自就是一个 token；较长或较少见的单词则会被拆分成两个或更多片段。标点符号、空白字符和数字各自单独计数，而代码或非拉丁文字的分词成本往往高于英语散文。

API 提供商会同时对输入（你发送的内容）和输出（模型生成的内容）按 token 计费。这意味着文本越长，费用越高，占用的模型上下文窗口也越多。理解 token 是预测和控制 API 费用的第一步。

分词器是负责将原始文本转换为一系列 token（以及反向转换）的算法或程序。它在训练过程中构建一个固定的子词词表，并在推理时依据该词表拆分每一段新输入，将每个片段映射为唯一的整数 ID。

每个模型系列都自带专属的分词器和词表。这一点很重要，因为同一段文本在不同模型上可能产生不同的 token 计数。同一句话用 GPT-4o 分词可能得到 50 个 token，而用 Claude 或 Gemini 可能得到 47 或 55 个。差异来源于词表大小、训练过程中学到的合并规则，以及分词器对空白字符和特殊字符的处理方式。

对于英语文本，主流提供商之间的计数差异通常在 5% 到 15% 以内。对于代码、非拉丁文字和格式复杂的内容，这一差距会进一步扩大。这也是为什么面向非 OpenAI 模型的 token 计算器通常使用估算的换算系数，而非模型的精确分词器。

字节对编码（BPE）是一种受压缩算法启发的方法，它通过迭代合并最常出现的相邻单元对来构建子词词表。该过程从单个字节或字符开始，执行数千次合并操作，直到词表达到目标大小（例如 50,000 或 100,000 个条目）。

最终得到的词表中，英语常用单词和词语片段各自拥有专属的 token，而生僻单词则被拆分为仍然存在于词表中的更小片段。这在两个相互竞争的目标之间取得了平衡：小词表效率更高，但把每个单词都拆成字符会使序列变得又长又昂贵。BPE 恰好居中，既能保持序列可控，又能处理任何单词，即便是训练中从未出现过的单词。

OpenAI 的 GPT 模型通过其 tiktoken 库使用 BPE。许多其他模型也使用 BPE 的变体，包括部分 Llama 和 Mistral 模型。不同实现中的具体合并规则和词表各不相同，这也是为什么即便都使用 BPE，相同文本在不同模型上仍会产生不同计数的原因。

SentencePiece 是谷歌开发的一款分词库，采用了与 tiktoken 风格的 BPE 不同的方法。它不需要针对特定语言的预分词步骤（例如在应用合并规则前先按空格拆分），而是将整个输入视为包含空格在内的原始 Unicode 字符流。空格由一个类似下划线的特殊标记表示，你可能会在分词输出中看到它（通常显示为字符“_”或特殊的 Unicode 符号）。

这种设计使 SentencePiece 与语言无关。它处理日语、中文、阿拉伯语等不以空格作为词边界的文字时，与处理英语一样自然。它底层支持两种主要算法：BPE 和一元语言模型分词。

Gemini、Llama、T5 及许多多语言模型都使用 SentencePiece。由于其对空白字符的处理方式不同，即使词表规模相近，同一句英语句子用 SentencePiece 分词得到的计数也可能与 tiktoken 的 BPE 略有不同。这正是 token 计数在不同提供商之间不能互换的主要原因之一。

tiktoken 是 OpenAI 发布的快速开源 BPE 分词器库。它正是 OpenAI 自家 API 用于计费的分词计数工具，因此在计算器中使用 tiktoken 能为 OpenAI 模型提供精确计数，而非估算值。

tiktoken 提供多种对应不同模型代际的命名编码方案。其中最重要的两种是 cl100k_base（覆盖 GPT-3.5 Turbo 和 GPT-4 系列模型）和 o200k_base（覆盖 GPT-4o、GPT-5 以及 o 系列推理模型）。名称中的数字表示大致的词表规模：分别约为 100,000 和 200,000 个 token。更大的词表意味着更新的编码方案能用单个 token 表示更多内容，往往能让同一段文本得到略低的 token 计数。

本 Token 计算器通过 WebAssembly 构建，直接在你的浏览器中运行兼容 tiktoken 的编码方案，因此你的文本永远不会离开你的设备，且 OpenAI 模型的计数是精确的。

上下文窗口是模型在同一时间能够保留在其“工作记忆”中的最大 token 数量，涵盖单次请求中的所有内容：系统提示词、对话历史、你附加的任何文档、用户消息以及模型的输出。如果总量超过该窗口，你必须缩短输入内容，否则 API 会返回错误。

上下文窗口的规模在各代模型之间迅速增长。早期的 GPT-3 只有 4,096 个 token 的窗口。当前的前沿模型支持的窗口规模可达数十万甚至数百万个 token，使得将整个代码库或整本书传入单次请求成为可能。

更大的上下文窗口让你能够传入更多文档、维持更长的对话，并为模型提供更多示例进行参考。代价是费用：更多的输入 token 意味着更高的账单。也有证据表明，超长的上下文可能降低模型对提示词中间信息的关注质量，这种现象有时被称为“中间遗失”问题。将提示词保持在必要的简洁程度，通常对费用和输出质量都有好处。

API 提供商将 token 计费分为两类。输入 token（也称提示词 token）是你在一次请求中发送给模型的所有内容：系统提示词、完整的对话历史、你附加的任何文档或上下文，以及用户最近的一条消息。输出 token（也称补全 token）是模型在其响应中生成的 token。

两者分别定价，是因为生成 token 在计算上比读取 token 更昂贵。输出 token 每百万个的价格通常是输入 token 的数倍，具体比例因提供商和模型而异。

一次请求费用的计算公式很简单：

总费用 = （输入 token 数 / 1,000,000）x 每百万输入价格 + （输出 token 数 / 1,000,000）x 每百万输出价格

在估算应用费用时，你需要同时考虑输入和输出两方面。对于系统提示词较长或检索上下文较大的应用，输入费用占主导；对于生成冗长响应的任务（如文档撰写或代码生成），输出费用占主导。Token 计算器允许你分别设置预期的输入和输出长度，以便对两者分别建模。

提示词缓存是多家提供商（包括 Anthropic 和 OpenAI）提供的一项功能，允许你将提示词的一部分标记为可缓存。当 API 在后续请求中再次遇到相同的缓存前缀时，会对这些 token 收取显著降低的费用，而不是按全价处理。缓存命中的费用通常只是标准输入价格的一小部分，视提供商而定，通常约为标准费率的 10% 到 25%。

部分提供商会对写入缓存的新条目收取少量额外费用（因为存储键值状态本身也有成本），但只要你将该前缀重复使用一两次以上，这笔写入成本通常很快就能收回。

当一个庞大且静态的前缀出现在大量请求中时，提示词缓存的价值最为显著：例如较长的系统提示词、参考文档、代码文件或一组少样本示例。如果你的应用每次用户提问前都会附加一份 10,000 个 token 的文档，缓存该文档可以大幅降低每次请求的输入费用。

对于提示词每次都不相同，或可缓存前缀频繁变化的工作负载，缓存的作用则较为有限。缓存也会在一段时间不活跃后过期（具体的存活时间因提供商而异），因此非常低频的请求可能无法从中受益。

批量 API 是一种异步处理模式，你可以一次性提交大量请求（通常以 JSONL 文件形式），并在稍后一个承诺的时间窗口内（通常最长 24 小时）收到结果。由于提供商可以在低峰算力期间安排你的请求，因此会提供可观的折扣，相较于同步实时 API 通常约为半价。

批量处理非常适合不需要即时响应的工作负载，例如评估大规模数据集、为产品目录生成描述、对成千上万张支持工单进行分类、针对新模型运行回归测试套件，或在夜间处理大批量文档。

对于需要实时回复的面向用户的场景，或每个步骤都依赖上一步输出的流水线（因为各步骤之间可能需要等待数小时），批量 API 并不适合。

在为批量工作负载做预算时，将单 token 价格减半可以在规模化场景下带来显著差异。如果你每天要处理数百万个非紧急任务的 token，将其改用批量 API 而非同步端点，是降低基础设施成本最简单的方法之一。

Token 预算是对某项任务、请求或应用允许使用的 token 数量所设定的计划上限。设定预算有两个目的：一是让费用保持可预测，二是防止请求无意中超出模型的上下文窗口。

实用的 token 预算通常涵盖三个方面：系统提示词和静态上下文（每次部署固定不变）、每次请求增加的动态上下文（检索到的文档、对话历史、用户输入），以及最大输出长度（通过 max_tokens 参数控制）。将三者相加并与模型的上下文限制进行比对，即可判断你的设计是否可行。

保持在预算内的常见方法包括缩短系统提示词、限制 RAG 流程中检索片段的数量、截断或概括旧的对话轮次，以及通过限制 max_tokens 参数来防止输出失控。

在开发前估算预算，比在生产环境中排查超支问题要容易得多。使用Token 计算器来测量你的提示词，在确定模型或定价层级之前，准确了解你的 token 数处于什么水平。