很多人第一次听到token，是在用AI的时候。
比如你让AI总结一份很长的PDF，它可能提示“内容太长”。你让AI写一篇长文章，它有时候写到后面会忘记前面说过什么。你看一些AI工具的收费说明，又会发现它不是按“字数”收费，而是按token收费。
token到底是什么？
它是一个字吗？是一个词吗？还是一段话？
简单说，token可以理解成AI处理文字时使用的“基本颗粒”。
AI不是像人一样按一篇文章、一页纸、一个段落来理解文本，而是先把文字切成一个个token，再进行读取、理解和生成。
所以，token不是一个离我们现实生活很远的技术词，它会直接影响AI能读多长的内容、写多快、花多少钱，以及本地模型要占多少内存。
一、什么是token
第一：token不是固定等于一个字。
在中文里，一个token可能接近一个字，也可能是一段词的一部分。在英文里，一个token可能是一个单词，也可能只是单词的一部分。
举个例子，“今天天气不错”这句话，模型不一定是按“今天／天气／不错”这样符合我们语感的方式切分，它可能切成“今天”“天气”“不错”，也可能切成更细碎的片段，具体取决于模型用的分词方式。
同样，英文单词“tokenization”也常常会被切成“token”+“ization”两个片段，而不是当成一个完整单词处理。所以不能简单理解成：
1个token=1个字。
这个理解不准确。
第二：token是AI处理文本时的基本计量单位。
人看到的是一句话、一段话、一篇文章。
但AI看到的不是完整文章，而是一串被切分过的token，它先把文字拆开，再进行计算。
第三：输入和输出都会消耗token。
你发给AI的提示词、资料、PDF内容、历史对话，都是输入token，而对于AI，是以输出token的方式回应你的要求。
很多人只看AI最后写了多少字，却忽略了前面塞进去的资料、提示词和对话历史，这也都在占“token”。
第四：token越多，AI处理压力越大。
token越多，模型要读的信息越多，信息越多，就会影响速度、成本、上下文长度、内存占用。token不是一个纯技术词，而是理解AI使用成本和体验的入口。
二、token和字数是什么关系？
很多人最容易误解的地方，就是把token直接等同于字数，这不准确，因为不同语言、不同内容、不同符号，被切分成token的方式不一样。可以简单看这个表：
| 内容类型 | 我们看到的单位 | AI处理时的单位 |
|---|---|---|
| 中文文章 | 字、句子、段落 | token |
| 英文文章 | 单词、句子 | token |
| 代码 | 变量、符号、缩进 | token |
| 表格 | 行、列、字段 | token |
| PDF内容 | 页数、段落 | token |
| 对话记录 | 一轮一轮聊天 | token |
我们不需要精确记住每句话会被切成多少token，只要记住一个大方向：文字越多，结构越复杂，token通常就越多。 如果想有个粗略的量感，可以记一个大致的经验范围：中文大概1～2个字对应1个token，英文大概3～4个字母对应1个token，不需要精确，只是一个方便估算的尺子。
比如：
- 一段普通聊天，token很少。
- 一篇3000字公众号文章，token明显增加。
- 一份几十页PDF，再加上你让AI总结、改写、提炼标题，token就会继续增加。
如果你还让AI保留前面的所有对话，再继续修改，历史对话也会继续占token。
所以AI处理内容时，真正看的不是你主观感觉“这也没多少字”，而是模型内部实际要处理多少token。
三、为什么AI不按字数算，而按token算？
这个问题很重要，因为在我们的习惯里，文章是按字数算的，比如公众号文章3000字、作文800字、报告5000字，而AI模型真正处理的，是token序列。
你可以理解成：
字数是给人看的单位，token是给模型算的单位。
为什么不能直接按字数算？原因可能是以下三个方面：
1. 不同语言的切分方式不同
中文、英文、数字、标点、代码，被拆分的方式都不一样。
比如英文里，一个常见单词可能是一个token，也可能被拆成多个token。
代码里，一个函数名、一个括号、一个缩进，也可能都会影响token数量。
中文也不是永远一个字一个token。所以，用“字数”作为统一标准并不准确。
2. AI真正处理的是token序列
模型不是直接读一篇完整文章。
它先把文字转换成token，再把token转换成模型可以计算的表示，然后模型根据前面的token，预测后面最可能出现的token。这就是大语言模型生成文字的基本过程。
所以从模型角度看，它不是在写“字”，而是在一个token一个token地生成内容。
3. token更适合衡量成本
AI服务为什么按token计费？
因为token更接近模型真实的计算量，输入token越多，模型要读的内容越多；输出token越多，模型要生成的内容越多。这两部分都会消耗计算资源。
所以，按token计费，虽然一开始看起来不直观，但它比按“字数”“篇数”“页数”更接近AI的实际工作方式。
四、token对使用AI的我们有什么影响？
token不是一个只属于程序员的概念。
我们在使用AI时，很多体验问题都和token有关：
| 你遇到的问题 | 背后的token原因 |
|---|---|
| AI提示内容太长 | 输入token超过上下文限制 |
| 长文总结容易漏内容 | token太多，模型注意力被拉长 |
| AI写长文变慢 | 输出token越多，生成时间越长 |
| API调用变贵 | 输入和输出token都会计费 |
| 聊久了AI忘记前文 | 对话历史token太多，旧内容被截断或弱化 |
| 本地模型占内存变高 | 长上下文会带来额外内存压力 |
| 同一个问题换种问法成本不同 | 提示词长度不同，token消耗不同 |
举个简单例子：
- 你让AI写一句标题，消耗的token很少。
- 你让AI写一篇完整文章，消耗的token会明显增加。
- 你先丢给AI一万字资料，再让它总结、提炼、改写、生成标题、写朋友圈文案，消耗的token就不只是最后那篇文章，而是整个过程。
这也是为什么很多AI工具会限制单次输入长度、文件大小、对话轮数、上下文长度、输出长度——表面上看，是工具不给你用，本质上看，是token有上限，计算资源也有成本。这也是为什么一直以来免费的豆包也推出了付费版，现在的免费版豆包也会提示“今日额度已用完”。
这里有一个容易被忽略的点：AI消耗的不是最后那篇文章的字数，而是整个对话过程中输入和输出的token。
比如你最后只得到一篇3000字文章，但在生成这篇文章之前，你可能给了它：
- 一段选题说明
- 一份参考资料
- 一套写作要求
- 一份标题规则
- 几轮修改意见
- 一些历史对话背景
这些都会进入token消耗。
所以，当你发现AI写文章越来越慢、回答越来越短、或者开始忘记前面的要求时，不一定是模型突然变差了，也可能是上下文里的token太多了。
五、token和“上下文长度”是什么关系？
现在很多模型介绍里都会写 8K 上下文、32K 上下文、128K 上下文、1M 上下文，这里的K，通常就是指token数量级。
看到长上下文，我们一般会直接理解成——这个模型能读更多内容，所以一定更好，这个判断只对了一半。
长上下文确实有用，它能让模型一次读更多资料，保留更长对话，处理更复杂的任务，但长上下文也不是免费的。上下文越长，模型需要同时处理的信息越多，速度、成本和内存压力都会上升。
尤其在本地模型里，这一点更明显。你在云端用AI，成本主要体现在服务费用和响应速度上；你在Mac或本地电脑上跑模型，成本就会直接体现在内存、显存和运行速度上。
这也是为什么同一个模型，在 8K 上下文下可以跑得比较舒服，开到 32K 以后就可能明显变慢，甚至爆内存。
所以，我们理解上下文长度，不要只看“越长越好”，更准确的理解是：
上下文长度决定AI这次最多能同时记住多少token，但记得越多，处理压力也越大。
六、token和本地模型有什么关系？
如果你只用云端AI工具、不打算在本地跑模型，可以直接跳到“七、怎么用好token这个概念”。
如果你只是用云端AI，token主要影响费用、速度和上下文，但如果你开始在Mac上跑本地模型，token就会和内存直接挂钩。
很多人在选本地模型时，只看参数量，比如7B、14B、32B、70B，参数量当然重要，但它不是唯一因素。
本地模型能不能跑得舒服，还要看上下文长度、量化方式、KV Cache、内存带宽等因素。可以简单理解成下面这个表：
| 概念 | 普通理解 |
|---|---|
| 模型参数量 | 这颗“大脑”本身有多大 |
| 量化等级 | 这颗“大脑”被压缩到什么程度 |
| 上下文长度 | 这次最多要同时记住多少token |
| KV Cache | 为了记住上下文临时占用的工作空间 |
| 内存/显存 | 模型运行时可用的工作台 |
为什么同一个本地模型，有时候能跑，有时候卡？
一个重要原因就是上下文设置不同。如果你仅仅向AI问一句话，模型压力不大。但是你让它读一篇长文、保持几十轮对话、再写一篇完整分析，token数增加，KV Cache压力也会上来。这时候，内存占用就可能明显增加。
所以本地模型不是只看“我能不能加载这个模型”，更重要的是：在你真实使用场景下，它能不能稳定处理足够多的token。
这也是为什么 24GB 内存的 Mac 跑本地模型时，不能只看模型参数量，还要看上下文开多大、量化格式怎么选、任务到底有多长。
七、怎么用好token这个概念？
理解token，不是为了每天去计算token数，更需要的是用它改善AI使用方式。从实用性上来说：
1. 提示词不要无意义堆长
很多人写提示词，喜欢把所有背景一次性塞进去，但提示词绝不是越长越好。如果背景很长，却和任务没关系，只会增加token，增加模型负担。
在使用AI过程中更好的方式是：先说任务目标，再补充必要背景。
比如不要一上来就粘贴几千字资料，可以先告诉AI：
我接下来会给你一篇文章，请先只提炼结构，不要改写。
这样任务更清楚，也更省token。
2. 长文资料要分段处理
如果你要让AI总结一份很长的资料，不建议一次性全部丢进去，更稳的方式是：
- 第一步，分段总结。
- 第二步，合并要点。
- 第三步，再让AI形成完整文章。
这样比一次性让AI读完所有内容再输出，通常更稳定。
3. 多轮对话后要做阶段性摘要
如果一个对话聊了很久，历史内容会不断占用token，有时候你觉得AI开始“走偏”了。这时候可以主动让AI做一次阶段性摘要。
比如：
请把目前已经确定的要求整理成一份简短项目说明，后续回答只按这份说明执行。
这样可以减少历史对话负担，也能降低AI忘记重点的概率。
4. 本地模型不要盲目开超长上下文
很多本地模型工具里可以设置上下文长度，看到 32K、64K，不要本能地拉满。如果你只是日常问答、写短文、改标题，8K 或 16K 可能就够用；如果你要处理长文、PDF、代码项目，再考虑更长上下文。
上下文开得越长，不代表效果一定越好，更可能的是它也会带来速度和内存压力。
5. 用API时要同时看输入和输出
如果你用API做自动化，比如总结文章、生成日报、批量写文案，就不能只看输出。
输入的资料越长，成本也会上升，尤其是批量任务，token消耗会被放大。一篇文章多消耗一点看不出来，一百篇、一千篇之后，成本差异就明显了，token消耗量很快就会告急。
八、token不是越少越好，也不是越多越好
token不是越少越好——如果你给AI的背景太少，它可能理解不清任务，输出就会空泛。
token也不是越多越好——如果你把大量无关信息都塞进去，模型反而更容易抓不住重点，速度也会变慢，成本也会上升。token越多，只利好算力提供商。
更好的状态是：给AI足够完成任务的信息，但不要给它一堆无关负担。
这和人沟通其实很像。你请别人帮你写一篇文章，不能只说“帮我写一篇”，那信息太少；但你也没必要把所有聊天记录、所有参考链接、所有想法碎片都丢过去，那信息太乱。
最好的方式是：目标清楚，背景适量，要求明确，分步骤推进。
这就是我们日常使用token概念最实际的意义。
九、最后总结
token不是一个必须背定义的技术词：AI不是按字、按页、按篇处理内容，而是按token这种“文字颗粒”处理内容。
它影响AI能读多长、写多快、花多少钱，也影响本地模型占多少内存。
理解token，不是为了变成工程师，而是为了更清楚地使用AI。
当你知道AI是按token工作之后，会发现AI嫌内容太长、长文总结容易漏、API按token收费、本地模型开长上下文更吃内存、同一个模型有时快有时慢——这些看似不同的问题，背后都指向同一个原理：AI处理的从来不是“字”，而是token。