如果你用过任何大模型 API，账单上一定有一个绕不开的单位：token。按 token 计费、按 token 算上下文长度、按 token 看模型能力——token 是理解大模型运行方式的第一个基础概念。但它到底是什么？和中文里的”字”、英文里的”词”有什么关系？这篇文章把它讲透。
Token 是什么：模型处理文本的最小单位
大模型并不能直接”读”汉字或英文字母。它处理的一切文本，都要先被切成一个个更小的片段，这些片段就是 token。你可以把 token 理解为”模型词汇表里的基本单位”，类似于人类语言里的”词”，但不完全等同。
举个直观的例子。英文里，一个常见的词往往就是一个 token，比如 “apple” 是一个 token，”the” 也是一个 token。但长词或生僻词会被进一步切分，比如 “tokenization” 可能被切成 “token” + “ization” 两个 token。中文里，一个字通常对应一个 token 左右，但具体取决于分词器的设计，有的分词器会把常用词合并成一个 token。
关键要记住的是：token 是”模型怎么切分文本”的结果，而不是一个固定大小的单位。同样一句话，用不同的分词器，切出来的 token 数量可能不一样。
分词是怎么做到的：BPE 算法
把文本切成 token 的过程，叫分词（tokenization）。大模型里最主流的分词算法是 BPE——Byte Pair Encoding，字节对编码。它的名字听起来复杂，思路其实很朴素。
BPE 的做法是：先从最基础的字符（甚至字节）出发，统计语料里”哪两个相邻的片段最常一起出现”，把它们合并成一个新片段，反复执行。比如英文里 “t” 和 “h” 经常连在一起，就合并成 “th”；”th” 又常和 “e” 连在一起，就合并成 “the”。这样一轮轮合并下去，最终得到一个由”常用词根、常用词、子词”组成的词表。
BPE 的好处在于：它能在”词表大小”和”切分粒度”之间取得平衡。词表里既有完整的常用词，也有能拼出任何生僻词的子词片段。这样既保证了常用词能被高效表示，又不会因为词表过大而爆炸，还能处理训练时没见过的生词——生词可以被拆成已知的子词来理解。BPE 最早由 Sennrich 等人在 2015 年提出，如今已经成为 GPT 等主流模型分词器的标准做法。
BPE 是怎么一步步合并的：一个具体例子
光看描述，BPE 可能还是有点抽象。下面用一个简化的英文例子，把它”合并”的过程走一遍。
假设我们的语料里反复出现这样几个词：low、lower、newest、widest。BPE 的第一步，是把每个词拆成字符，并统计相邻字符对的出现频率。比如 “low” 拆成 l-o-w，”lower” 拆成 l-o-w-e-r。统计会发现，”lo” 这个字符对出现了很多次，”ow” 也出现了很多次。
接着，BPE 选出出现频率最高的那一对，把它合并成一个新的符号。假设 “lo” 频率最高，就合并成 “lo”，于是 “low” 变成 lo-w，”lower” 变成 lo-w-e-r。下一步，再统计新的相邻对——这时 “lo” 和 “w” 又经常连在一起，就把 “low” 合并成一个符号。这样一轮轮迭代下去，最终词表里会积累出 “low”、”est”、”wid” 这类既非完整单词、也非单个字符的”子词”片段。
这个例子的关键启示是：BPE 合并出来的是”统计上高频、且能拼出任意词”的子词单元。它不依赖语言学知识，纯粹靠频率驱动，所以能自适应任何语言——这也是它被广泛采用的原因。理解了这一点，你就明白为什么分词器能把 “unbelievable” 拆成 “un” + “believe” + “able”，而不是非要把它当成一个整词。
从 GPT-2 到 GPT-4：分词器也在进化
分词器并不是一成不变的，它随着模型迭代也在更新。以 OpenAI 的 GPT 系列为例，能看出一条清晰的演进线。
GPT-2 时代用的 BPE 词表大约 5 万个 token，分词相对粗糙，长词和生僻词往往被拆得很碎。到了 GPT-3，词表进一步扩大。而 GPT-3.5 和 GPT-4 使用的分词器（内部代号 cl100k_base）词表规模达到了约 10 万个 token，分词质量明显提升——更少的 token 就能表示同样的文本，而且对多语言、代码、符号的处理更好。
词表大小是个权衡：词表越大，每个 token 平均覆盖的信息越多，同样的文本切出的 token 越少，计费上可能更划算；但词表越大，嵌入层的参数量也越大，模型本身会变重。所以设计者要在”分词效率”和”模型体积”之间找平衡。这也是为什么不同厂商、不同模型的分词器各不相同——同一个英文单词，在 OpenAI 的模型里和在大模型 A、B 里，切出来的 token 数可能都不一样。
怎么知道自己用了多少 token
既然按 token 计费，那就得知道”一段文本到底是多少 token”。主流模型厂商通常会提供官方的分词工具，最著名的是 OpenAI 的 tiktoken——一个 Python 库，可以直接把文本转成 token 并统计数量。类似地，各家平台也会在 API 返回里带上 token 用量信息，方便你核对账单。
一个实用的经验法则：英文文本，token 数大约是单词数的 1.3 倍左右；中文文本，token 数大约是字数的 1 到 1.5 倍。当然这只是粗估，精确数字还是得用官方工具算。另外要注意，同样的文本，用不同模型的分词器算出来的 token 数可能不同，计费时要以”你实际调用的那个模型”的分词结果为准。
中英文的 token 差异
一个经常被问的问题：为什么同样一句话，中文的 token 数和英文不一样？
这源于两种语言的结构差异。英文以空格分隔单词，天然就有”词”的边界，BPE 在这个基础上合并子词，效率很高。中文没有空格，字与字紧密相连，分词器往往先从”字”这个粒度出发，再把常用词（如”我们””模型””人工智能”）合并成词。
粗略地说，中文里一个汉字大约对应 1 到 2 个 token，英文里一个单词大约对应 1 到 3 个 token。这意味着，表达同样的意思，中文的 token 消耗通常比英文更省——这也是为什么有些按 token 计费的场景下，用中文写提示词反而”便宜”一点。当然，具体数字因分词器而异，不能一概而论。
为什么按 token 计费
理解了 token 是”模型处理文本的基本单位”，就理解了为什么 API 都按 token 计费——因为 token 直接对应着模型的计算量。
模型的每次推理，计算成本主要由”处理多少个 token”决定。输入（prompt）有多少 token，模型就要对它们做一次前向计算；输出（completion）每生成一个 token，也要做一次前向计算。所以”输入 token 数 + 输出 token 数”几乎就是计算量的代理指标。按 token 计费，本质上就是按”算力消耗”计费。
这也解释了为什么输入和输出通常分开计价，而且输出往往更贵——生成阶段的每一步都是串行、访存密集的，单位 token 成本更高。所以控制成本的两个关键，一是缩短提示词（减少输入 token），二是让模型回答简洁（减少输出 token）。
上下文窗口：模型一次能”看”多少 token
上下文窗口（context window）指的是模型一次能处理的 token 总量上限，通常用 token 数表示。比如”128K 上下文”就是大约 12.8 万个 token。
这个限制来自模型架构本身。主流的 Transformer 架构里，注意力机制的显存和计算量会随输入长度呈平方级增长，所以必须设一个上限。这个上限直接决定了模型”一次能读多少东西”：一篇短文几千 token，一本书可能几十万 token，一个大型代码仓库则可能上百万 token。
这也是为什么”长上下文”会成为模型竞争的重要维度——上下文越长，模型能一次性处理的文档、代码、对话历史就越多。从早期的 2K、4K，到现在的 128K、100 万甚至 1000 万 token，上下文窗口的增长，是衡量大模型能力演进的一条重要线索。
Token 和词嵌入、词表，别搞混
聊 token 时，几个相近的概念很容易混淆，这里一并理清。
- 词表（vocabulary）：分词器能够识别的所有 token 的集合。比如一个模型的词表可能有 5 万、10 万甚至 15 万个 token。词表越大，通常能更细粒度地表达，但也会增加模型的参数和计算。
- Token ID：分词器把每个 token 映射成一个整数编号。文本进入模型前，先被切成 token，再转成一串数字 ID。
- 词嵌入（embedding）：token ID 只是一个编号，模型会通过一个嵌入层，把每个 token 映射成一个高维向量——这个向量携带了该 token 的语义信息。后续的注意力、前馈等计算，都是在这些向量上进行的。
一条清晰的链路是：原始文本 → 分词成 token → 映射成 token ID → 通过嵌入层变成向量 → 进入模型计算。token 是这个链条最前端的入口，也是理解后续一切的基础。
上下文窗口的演进：一条能力增长的线索
如果只看 token，可能很难感受到大模型的进步有多快。但把”上下文窗口”这条线拉出来看，就会非常直观。
2018 年的 GPT-1，上下文窗口只有 512 个 token；GPT-2 提升到 1024；GPT-3 到了 2048。那时候，模型”读”一篇稍长的文章都费劲。到了 GPT-3.5 和 GPT-4，窗口一下子跳到 4096、8192，再到 12.8 万（128K），长文档问答才真正可用起来。
竞争的白热化发生在最近两年。Claude 一度把窗口做到 20 万 token，Gemini 系列更是一路推到 100 万甚至 200 万 token，而 Meta 的 Llama 4 Scout 则喊出了 1000 万 token 的业界纪录。窗口越大，模型能一次性处理的对话历史、文档、代码仓库就越大，能承接的任务就越复杂——从”总结一篇文章”到”通读整本书””分析整个代码库”，本质上是 token 上限在决定。
但要记住，上下文窗口大不等于”记得住”。研究表明，模型对长文本中间部分的信息，注意力往往会衰减。所以”能装下 100 万 token”和”能准确利用 100 万 token”是两回事，实际效果还要看模型在长程理解上的训练质量。
token 如何影响成本与效果
token 不只是账单上的数字，它还实实在在地影响着使用体验和效果，这里梳理几条容易忽视的关系。
输入与输出的成本结构：大多数平台对输入 token 和输出 token 分开计价，输出通常更贵。原因是输出是自回归逐个生成的，计算更密集。所以”让模型别啰嗦”不仅改善体验，还能直接省钱。
提示词的位置很重要：模型对开头和结尾的信息通常更敏感。把最关键的指令放对位置，用更少的 token 达到更好的效果，是提示词优化的重要思路。
截断的代价：如果输入超过了上下文窗口上限，模型（或平台）会截断一部分内容。被截掉的多半是中间或靠后的信息，可能导致模型”漏看”关键内容。所以喂长文档前，先估算 token 数、必要时做摘要或分块，能避免静默的信息丢失。
token 与模型”智力”的间接关系：一个模型在单位 token 上能”想”多深，取决于它的能力和推理机制。同样的问题，推理型模型可能消耗更多 token 来思考，但答案更可靠。所以”token 用得少”并不总是好事，有时是模型在偷懒，有时是模型能力强、表达精炼。
这个知识有什么用
理解 token 和分词，至少有这几个实实在在的用处：
- 看懂账单：知道输入和输出 token 怎么算，就能理解为什么有的对话贵、有的便宜，以及怎么省。
- 判断上下文够不够：把一个任务需要喂给模型的内容换算成大概的 token 数，判断当前模型的上下文窗口装不装得下，避免”超出上限被截断”。
- 优化提示词：减少无效 token、把关键信息放前面，既是成本优化，也是效果优化。
- 理解模型行为：为什么模型会把长词拆开？为什么它对某些字词”不认识”？很多现象都能从分词机制上找到解释。
词嵌入：token 背后的语义空间
token 只是”切分”的结果，真正让模型”理解”含义的，是切分之后的那一步——把 token 变成向量。这一步叫词嵌入（embedding），值得单独说说。
嵌入层会把每一个 token ID 映射成一个固定维度的高维向量，比如 1024 维、4096 维甚至更高。这个向量的妙处在于：它不是随机的，而是经过训练后”携带了语义信息”的。一个经典的现象是，语义相近的词，它们的向量在空间里也靠得很近——”猫”和”狗”的向量距离，比”猫”和”汽车”要近得多。
更进一步，向量之间的关系还编码了更复杂的语义规律。最著名的例子是类比：”国王”减去”男人”加上”女人”，得到的向量大约等于”女王”。这说明嵌入空间不仅记录了”词是什么意思”，还记录了”词与词之间是什么关系”。
现代大模型的做法更进一步——token 的向量不再是静态固定的，而是会随上下文动态变化。同一个词”苹果”，在”吃苹果”和”苹果公司”里，最终得到的上下文向量完全不同。这靠的是注意力机制根据上下文对向量做动态调整。所以准确的链路是：token → 静态向量 → 经过注意力等层动态调整 → 上下文相关的表示。理解了这一步，才算真正把”token 是什么”和”模型怎么理解语言”接上了。
一个实际案例：把一篇长文档喂给模型
光讲概念还不够，用一个具体的场景把 token 知识串起来。
假设你手里有一份 10 万字的合同，想用大模型帮你通读并总结要点。你的模型上下文窗口是 128K token。第一步是估算：10 万字的中文，按 1 字约 1.2 token 粗算，大约是 12 万 token——刚好在 128K 的临界线上，但加上你的提问和系统提示，很可能就超了。
这时你有几个选择：一是把合同切块，分段让模型总结，再把各段摘要合并；二是换一个上下文更大的模型；三是先做一轮摘要压缩，再喂给模型。无论选哪种，前提都是你”知道”这份文档大概多少 token、你的模型窗口多大——而这正是理解 token 带来的判断力。
反过来，如果文档只有 2 万字，约 2.4 万 token，离 128K 上限还很远，那你完全可以放心地整篇喂进去。成本上，输入 2.4 万 token，按某平台每百万 token 输入 2 元来算，一次也就几分钱。理解了 token，你对”这事能不能干、要花多少钱”就有了清晰的预期，而不是拍脑袋。
还需要留意的一点是，不同模型、不同平台的分词器并不通用。你用 A 平台的分词工具算出 1000 token，换到 B 平台的模型，实际可能变成 1100 甚至 1200 token。跨平台做成本估算时，最好用目标模型官方提供的分词工具，或者直接以 API 返回的 token 用量为准，避免估算偏差。这个小细节，在”多平台比价”和”预算控制”时尤其容易踩坑，也是不少团队第一次对账时才发现的问题。
小结
Token 是大模型世界里最基础也最实用的概念之一：它是模型处理文本的最小单位，由 BPE 等分词算法切分而来，直接决定了计费方式和上下文长度。搞懂了 token，你就能读懂 API 账单、判断上下文够不够、优化提示词成本——这些看似琐碎，却是用好大模型的基本功。