03 · Token：它眼里的世界，也是你的账单
Token（令牌）是大模型处理文本的最小单位。它眼里没有"字"也没有"词"，只有 Token。你的费用、上下文上限、速率限制，全部按 Token 算。
一个 Token 大概是多少
没有精确换算，只有经验值。不同模型的切分方式还不一样，所以下面这张表是用来"估"的，不是用来"算"的：
| 内容 | 大概几个 Token |
|---|---|
| 一个汉字 | 1 ～ 2 个 |
| 一个常见英文单词 | 1 个左右 |
| 一个生僻英文单词 | 2 ～ 3 个 |
| 一个标点、一个空格 | 通常算 1 个 |
| 一页 A4 中文文档（约 800 字） | 1000 ～ 1600 个 |
| 一份 30 页的 PDF | 三四万个 |
粗略记法：中文按字数 × 1.5，英文按单词数 × 1.3，估个数量级够用了。
为什么英文更"便宜"
主流模型的切词表是以英文为主训练出来的，常见英文单词往往一个词就是一个 Token，而中文经常一个字就要一到两个。同样一段意思，中文版通常比英文版贵一截。真要压成本的场景（比如要塞很长的资料），有人会把提示词写成英文——但可读性和团队协作的代价你自己权衡。
为什么你必须知道这个词
一、你的钱按这个收
按 API 计费的话，账单长这样：输入 Token 一个价，输出 Token 另一个价（输出通常贵好几倍）。所以：
- 你把一份 50 页的合同整个贴进去问一句话——贵的是那 50 页，不是你那句话。
- 让它"把这份文档重写一遍"比"把这份文档总结成五条"贵得多，因为输出长。
- 多轮对话越聊越贵：每一轮都要把前面所有内容重新发一遍（见 04 · 上下文窗口）。
包月订阅的聊天产品不直接按 Token 收你钱，但背后的额度限制还是这个逻辑。
二、它一次能装多少，按这个算
模型的「上下文窗口」大小是用 Token 数说的。"20 万 Token 的窗口"意思是：System Prompt + 全部对话历史 + 你贴进去的资料 + 它这次的输出，加起来不能超过 20 万。装不下会怎么样，下一章讲。
三、它数不清字数，也是因为这个
让它"写一段 500 字的介绍"，你多半会拿到 430 字或者 620 字。不是它偷懒，是它眼里根本没有"字"这个单位——它在按 Token 往下预测，中途没有一个准确的计数器。
别用字数当硬指标。要控制长度，改成它能感知的结构约束：
- ❌ "写 500 字" → ✅ "写三段，每段三到四句话"
- ❌ "简短一点" → ✅ "总共不超过五个要点，每点一行"
- ❌ "详细展开" → ✅ "每个要点下面各给一个具体例子"
字数只能当"大概的松散提示"用，当硬性验收标准一定翻车。
顺带说清楚三个连带的概念
| 词 | 意思 | 你什么时候会撞上 |
|---|---|---|
| 速率限制（Rate limit） | 每分钟 / 每天最多能用多少 Token 或请求数 | 批量处理时突然被限流 |
| max_tokens | 你给这次输出设的上限，到了就硬截断 | 输出到一半戛然而止，通常是这个设小了 |
| Temperature | 挑下一个 Token 时的随机程度，低=稳定保守，高=发散 | 要稳定格式调低，要创意发散调高 |
这三个在聊天框里通常看不见，一旦你开始用 API 或者带参数的工具就会遇上。详细解释在术语表。
一个能立刻用上的估算习惯
派活之前先扫一眼你要贴进去的东西有多长：
- 几百字 — 随便贴，不用想。
- 几千字（一份纪要、一篇文章） — 没问题，常规操作。
- 几万字（一份长报告、几十页 PDF） — 能塞进大窗口模型，但注意两件事：贵，而且中间的内容它容易读漏。
- 十几万字以上（一整个知识库、几百份文档） — 别硬塞。这是 RAG 要解决的问题：只把相关的那几段挑出来给它。
下一步
04 · 上下文窗口：它为什么会忘 —— 知道了单位，接下来看这个容器有多大、装满了会怎样。