Token 是大语言模型处理文字的最小单位。你可以把它理解成模型"阅读"和"写作"时的基本积木：一句话进入模型之前，会先被切成一串 Token，模型逐个理解这些 Token；回答时也是逐个吐出 Token，再拼成你看到的文字。看懂 Token，就看懂了 API 计费、上下文长度、生成速度这三个最常遇到的问题。
举个直观的例子。英文单词 "unbelievable"，模型不会把它当成一个整体吞下去，而可能切成 "un"、"believ"、"able" 三块；中文更直白，"人工智能"通常被切成"人""工""智""能"四个 Token。一句被切成多少块、从哪里下刀，由每个模型自带的分词器说了算，不同模型切法不一样。
Token 和字、词不是一回事
先划清边界，免得混用。字是书写单位，词是语言单位，Token 是模型的工程单位，三者经常对不上。
英文里，一个常用单词可能正好是一个 Token，也可能被拆成两三块；中文里，每个常用汉字通常对应一个 Token，生僻字、emoji 则可能被拆成多块。关键是：Token 的切法是每个模型私有的"度量衡"，同一句话在 GPT、Claude、DeepSeek 里算出的 Token 数都可能不同。所以"这段话多少字"和"这段话多少 Token"是两个问题，答题之前先看用的是哪个模型的尺子。
一句话是怎么被"切"成 Token 的
动手的叫分词器（tokenizer），它的切分规则是训练时学出来的。主流算法叫 BPE（字节对编码），思路很朴素：先从单个字符起步，统计训练语料里哪些字符对经常连在一起出现，就把它们合并成一个新块，反复合并，最后攒出几万到几十万个常用块，组成一张"词表"。新文本进来，就按这张词表从前往后切。
词表大小是有限的，这是理解很多现象的钥匙。罕见词、生造词、拼写错误不在词表里，只能被拆成小块硬拼——模型偶尔"读不懂"一个生僻词，根子往往在这里。而 Transformer 的注意力机制计算的，正是这些 Token 之间的关联强度：Token 是注意力真正操作的对象。
Token 为什么值得你关心：钱、长度和速度
概念讲完，看三件和你钱包、体验直接相关的实事。
第一，API 按 Token 计费。输入和输出分别按每百万 Token 定价，价格表上写的 "input / output tokens" 就是这个意思。估算有个经验法则：英文大约 1 个 Token 对应 4 个字符（约 0.75 个单词），中文大约 1 个汉字对应 1 个 Token。想预估一次调用花多少钱，先数 Token，不数汉字。
第二，上下文窗口按 Token 算。常听到的"128K 上下文"，指的是 12.8 万个 Token，不是 12.8 万字。对纯中文大约对应十万字量级的文本，混排英文、代码时还会再打折扣。提示词写太长被截断、RAG 系统给文档切块，都得按 Token 预算来规划——检索增强的切块逻辑里同样绕不开它。
第三，生成速度按 Token 计。模型一次只生成一个 Token，所以长回答天然就慢，你看到的"流式输出"逐字冒出来，正是它在逐个吐 Token。推理时的显存占用（KV 缓存）也随 Token 数量线性增长，上下文越长、回答越长，算得越慢、越贵。
关于 Token 的三个常见误解
误解一："Token 就是字数"。英文里 Token 数通常只有单词数的 1.3 倍左右，只在中文里才接近 1:1。拿字数直接当 Token 用，英文场景会错得离谱。
误解二："128K 上下文等于能读 12.8 万字"。是 12.8 万 Token。中文大约十万字量级，代码、表格、混排英文的实际"阅读量"还要再低一截，规划长文档任务时要留余量。
误解三："切分是多余的，直接按字处理不行吗"。按字处理词表虽小，序列却变得超长，而注意力机制的计算量随序列长度平方增长，太长根本算不动。Token 是在"语义完整"和"算得动"之间取的平衡，不是拍脑袋加的一道工序。
记住三句话就够了：Token 是模型眼里的文字单位，切法由各模型的分词器自定；API 的钱、上下文的长度、生成的速度，统统按 Token 算。下次看到价格表上的 "per 1M tokens"，你就知道它在说什么了。
