Token：大模型世界的原子单位

Token 是大模型读写文本的最小单位——既不是字符，也不是单词，而是介于两者之间的「子词片段」。

当你把一句话发给 GPT 或 Claude，模型并不会看到字母和汉字。文本先经过一个叫 tokenizer（分词器）的组件，被切成一串 token，每个 token 对应词表里的一个整数编号；模型内部拿这个编号去查一张巨大的向量表（embedding），之后所有计算都发生在向量上。生成回答时方向相反：模型每一步输出一个 token 编号，再拼回文字。

一个 token 可能是一个完整的常用词（" are"）、一个词的片段（"Tok" + "ens"）、一个汉字或一个常用中文词、一个标点，甚至一个字节。高频的内容会被合成更长的 token，罕见的内容被拆得更碎——这是后面要讲的 BPE 算法决定的。

字符太碎，单词太多——subword token 是工程上的最优折中。

理论上模型可以直接处理字符或单词，为什么所有主流模型都选了中间路线？因为两个极端各有致命伤：

子词方案同时解决了三件事：开放词表（任何字符串都能表示）、序列效率（常用内容压得很短）、泛化（词缀、词根等结构暴露给模型，unhappiness 拆成 un + happiness 自带构词信息）。

几乎所有现代大模型都用 BPE（Byte-Pair Encoding）的变体：从字节出发，不断把语料里「最常相邻出现的一对」合并成新 token。

亲手看一遍 BPE 训练

假设训练语料里只有 5 个词（及出现次数）：hug ×10、pug ×5、pun ×12、bun ×4、hugs ×5。初始词表只有单个字符。每一步，找出出现频率最高的相邻字符对，合并成一个新 token 加入词表：

训练就这样迭代下去，直到词表达到目标大小（比如 20 万）。编码新文本时，按学到的合并规则依序应用即可。「高频 → 合并 → 变成一个 token」这一条规则，解释了 token 世界的绝大多数现象：为什么常用英文词是 1 个 token、为什么生僻字会被拆成多个字节、为什么中文比英文「贵」。

算法家族一览

主流模型的 tokenizer 与词表大小

英文经验值：1 token ≈ 4 个字符 ≈ 0.75 个单词。中文：1 个汉字 ≈ 1~1.5 个 token，取决于 tokenizer。

因为 BPE 按「语料里的出现频率」造词表，而训练语料以英文为主，所以英文的压缩率最高。常用换算（OpenAI 官方口径）：

• 100 token ≈ 75 个英文单词；一页 A4 英文约 500~700 token。
• 中文在 cl100k_base 下，常用汉字多为 1~2 个 token，生僻字 2~3 个；o200k_base 把中文 token 数压缩了约 1.4 倍，但同样语义下中文仍普遍比英文消耗更多 token——社区戏称「中文税」。
• 代码、JSON、Markdown 表格的 token 效率都不错（符号和缩进多有专属 token）；但 base64、随机字符串、生僻 emoji 非常费 token。

很多「大模型连小学题都不会」的笑话，根源不在智力，而在它看世界的方式——它看到的是 token 块，不是字符。

strawberry 里有几个 r？

模型经常答错成 2 个。原因：strawberry 在 cl100k 里被切成 str + aw + berry 三块，模型从头到尾没见过单个字母，要数 r 只能靠「记忆中这个词的拼写知识」间接推理。这类字符级任务（数字母、倒序拼写、藏头诗）天然是 token 化模型的盲区。

9.11 > 9.9？

数字被切分的方式和人类的数感不对齐：9.11 可能切成 9/./11，模型容易滑向「版本号比较」的模式（9.11 版确实新于 9.9 版）。研究表明这不全是 tokenizer 的锅——逐位分词的模型也会犯错——但 token 切分确实放大了它。

数字切分与算术

GPT 系把数字按 1~3 位一组从左往右切，而加法进位是从右往左的——两者错位。有研究发现：把数字用逗号强制三位分组（如 1,234,567）对齐 token 边界后，GPT-3.5 的多位数加法准确率从 75.6% 跳到 97.8%。

SolidGoldMagikarp：幽灵 token

GPT-2/3 的词表是从未过滤的网络数据上训练的，一些奇怪字符串（Reddit 用户名、电商后台残留）成了 token；但模型的训练语料过滤掉了这些内容——于是这些 token 有编号、没语义，embedding 几乎没被训练过。让早期 GPT 复述 "SolidGoldMagikarp"，它会答非所问，甚至说出 "distribute"。这类「glitch token」是词表训练与模型训练数据不一致的活化石。

空格和大小写敏感

在 BPE 词表里，hello、 hello（带前导空格）、Hello、HELLO 是四个不同的 token（序列）。前导空格通常归属后面的词，所以同一个词在句首和句中是不同 token。这就是为什么 prompt 末尾多一个空格，输出有时会明显变差。

API 按 token 双向计费：输入（prompt）一个价，输出（生成）一个价，输出通常贵 3~6 倍。

数 token 的三种姿势

① OpenAI 系：tiktoken 本地精确计数。开源、离线、和线上完全一致：

import tiktoken

enc = tiktoken.encoding_for_model("gpt-5.4")   # 自动选 o200k_base
tokens = enc.encode("Token 是大模型的原子单位")
print(len(tokens))          # token 数
print(enc.decode(tokens))   # 无损还原（BPE 可逆）

② Claude：count_tokens API。Claude 3 之后 tokenizer 不公开，没有本地库，但官方提供免费的计数端点（独立限额，不占消息额度），接受和正式请求完全相同的 body——system、tools、图片、PDF 都算进去：

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-sonnet-4-6",
    "system": "你是一个翻译助手",
    "messages": [{"role": "user", "content": "把这句话翻成英文…"}]
  }'
# → {"input_tokens": 31}

③ 在线工具。OpenAI 的 platform.openai.com/tokenizer 可以可视化任意文本的切分，适合直觉训练。

哪些东西在烧你的 token

账单上的 input token 远不止「用户那句话」。每次请求，下面这些全部按输入计费：

• system prompt + 全部对话历史（多轮对话每轮都要重发完整历史！）
• 工具定义：tools 里的名称、描述、JSON Schema，每次请求都算
• 工具调用与结果：tool_use / tool_result 块
• 图片和 PDF（折算规则见下）

而 thinking / reasoning token 按输出计费——推理模型「想」得越久越贵，即使思考过程不展示给你。用量都写在响应的 usage 字段里：

{
  "usage": {
    "input_tokens": 412,                  // 未命中缓存的输入
    "cache_creation_input_tokens": 8214,   // 本次写入缓存（1.25x 计价）
    "cache_read_input_tokens": 11037,      // 从缓存读出（0.1x 计价）
    "output_tokens": 1582                  // 输出（含 thinking）
  }
}

图片怎么折算成 token

为什么输出比输入贵 3~6 倍

这不是定价策略的任性，而是 GPU 的物理现实。处理输入（prefill）时，整个 prompt 可以一次前向传播并行算完，GPU 算力打满；生成输出（decode）是自回归的，每个 token 都要完整跑一遍模型，每步都要搬运全部权重和不断增长的 KV cache——瓶颈在显存带宽，GPU 大部分时间在等数据：

2026 年 6 月主流模型价目（每百万 token，USD）

Context window = 一次请求里模型能「看见」的 token 总量上限，输入、已生成的输出、thinking 共享同一个窗口。

窗口之内是模型的全部世界：装不下的内容它不知道，超了就报错或被截断。max output tokens 是窗口内的子限制——单次响应最多能生成多少。2026 年中，1M（约 75 万英文词，一整套《指环王》）已是旗舰标配：

但「窗口大」不等于「随便塞」：

• 成本随窗口线性涨：每轮对话都重发全部历史，第 50 轮的一句"嗯"可能背着几十万 token 的历史。OpenAI 对超 272K 的请求还要整单加价。
• 注意力会稀释：长上下文的中段信息容易被忽略（lost in the middle），关键指令放开头和结尾。
• 窗口是共享的：开了 extended thinking，思考也占窗口；要留够输出空间。

缓存的不是文本，而是模型处理前缀后的内部计算状态（KV cache）。前缀相同的请求可以「从断点续算」——跳过的部分按 1/10 价格计费，首 token 延迟最多降 80%。

回忆第 06 节：输入是 prefill 一次算完的。模型处理 prompt 时，每个 token 都会产生注意力的 Key/Value 张量。如果这次请求的前缀和上次完全一致，这些张量根本不用重算——服务商把它们留在显存/磁盘里，下次直接接上。这就是 prompt caching。

Claude：显式断点，控制最精细

在内容块上加 cache_control 标记断点，断点之前的全部前缀进入缓存：

{
  "model": "claude-sonnet-4-6",
  "system": [{
    "type": "text",
    "text": "你是法务助手。以下是 10 万 token 的合同全文……",
    "cache_control": {"type": "ephemeral"}          // ← 断点：到这里为止全部缓存
  }],
  "messages": [{"role": "user", "content": "第 12 条违约金怎么算？"}]
}
// 想缓存活 1 小时："cache_control": {"type": "ephemeral", "ttl": "1h"}

关键规则：

• 定价：缓存写入 = 输入价 ×1.25（5 分钟 TTL）或 ×2（1 小时 TTL）；缓存读取 = 输入价 ×0.1。
• TTL 是滑动窗口：5 分钟内再次命中，免费续命 5 分钟。活跃对话可以一直只付增量。
• 最多 4 个断点；按变化频率分层打（tools 永不变 → 长文档每天变 → 对话每轮变），一段失效不殃及前面的段。
• 最小可缓存长度因模型而异（512~4096 token），太短的前缀打了断点也不缓存。
• 命中要求前缀逐字一致。缓存按层级构建：tools → system → messages，改了上游，下游全部失效——改一个工具定义，整个缓存重写；改 temperature 等采样参数则不影响缓存。
• 缓存按组织/workspace 隔离，不会被其他用户「蹭」到。

四家机制对比

缓存为什么是 agent 的成本命门

Agent 每一步工具调用，都要把「system + 全部工具定义 + 越滚越长的完整历史」重发一遍。一个任务几十次请求，输入 token 是输出的几十倍——全部命中时输入按 0.1x 计，全不命中按 1x~1.25x 计，相差 10 倍以上。亲手感受一下：

最佳实践与常见误区

• 稳定的放前面，易变的放后面——所有家的缓存都是前缀匹配。一个时间戳放在 system 开头，全军覆没。
• 断点打在「跨请求不变的最后一个块」上，不要打在每次都变的用户问题上。
• 调用间隔可能超 5 分钟的任务用 1h TTL（写入 2x 但避免反复全量重写）；OpenAI 侧 GPT-5 系可延长保留到 24h。
• 并发冷启动会重复写入：缓存条目要等第一个响应开始后才可用，N 个并发首请求会各付一次写入费。先串行发一个预热请求再放并发（Claude 可用 max_tokens: 0 纯预热）。
• 「改一个字全失效」只对单断点成立：多断点时，失效的只是改动点之后的段，之前的断点照常命中。
• OpenAI 高并发场景用 prompt_cache_key 给请求分桶，避免缓存路由被冲散。

把前面八节压缩成一张决策表。

技术事实与价格均核实于 2026 年 6 月 11 日；价格可能变动，以官方价目页为准。