Token——AI 产品的'石油'

为什么这个稀缺资源约束了一切 AI 产品的设计

如果你用 AI 工具的次数足够多——可能见过这种报错：

"context length exceeded" "messages too long" "rate limit: tokens exceeded"

一开始你不在意——再开个新 session 就行。慢慢你会发现——几乎所有 AI 产品的核心约束都跟这个东西有关。它叫 token。

理解 token 不是技术细节——是理解 AI 产品的"经济学基础"。所有上层的产品判断——为什么 AI 总是漏看内容、为什么长对话突然变贵、为什么有些 AI 工具很慢——都源于 token 这个稀缺资源。

一、Token 不是字、不是单词、不是字符

最容易混淆的是——token 是什么。

直觉上你可能以为 token = 字 = 字符。错。

LLM 处理文字前要做一道叫 tokenization 的工序——把文本切成一个个 token。怎么切？每家厂商有自己的算法。

最常用的算法叫 BPE（Byte Pair Encoding）。它的思路是——常见的词作为一个 token，不常见的词被拆成几个 token。

具体说——"the" 是一个 token（极常见）。"hello" 是一个 token（常见）。"tokenization" 在 OpenAI 的 tokenizer 里可能是 3 个 token：token + iz + ation（拆开了）。"xerxes" 这种生僻词可能被拆成 4-5 个 token。

中文的情况更复杂——每个中文字通常是 1-2 个 token。"你好"在 GPT 里大概是 2 个 token（一个字一个 token）；在 Claude 里大概是 3 个 token（中文字符在 Claude 的 tokenizer 里更碎）。

这就是为什么中文比英文更费 token——同样信息量的中文，token 数大约是英文的 1.5-2 倍。如果你的 AI 产品主要面向中文用户——token 成本会比英文产品高 50-100%。

不同厂商的 tokenizer 也不一样：

• OpenAI 的 tokenizer（叫 tiktoken）
• Anthropic 的 tokenizer
• Google Gemini 的 tokenizer

同样一段文字在三家的 token 数可能差 10-20%。这意味着——你不能用 OpenAI 的 token 数估算 Claude 的成本。每家要分别算。

一个粗略的换算：

• 英文：1 token ≈ 4 字符 ≈ 0.75 单词
• 中文：1 token ≈ 1.5 字符

这只是估算——不准确但够用。

二、Context window 是什么——LLM 的"工作桌面"

LLM 有个固定的限制——一次能处理多少 token。这个限制叫 context window。

主流 LLM 的 context window：

• GPT-3.5：4K tokens
• GPT-4：8K → 32K → 128K（多版本演进）
• Claude 2：100K
• Claude 3 / 3.5 / 4：200K
• Gemini 1.5：1M
• Gemini 2：2M（实验性）

听起来很大？让我们做个换算。Claude 3 的 200K context window——按英文 4 字符/token 算——能塞下 80 万字符——大约 100 页打印纸。

听起来够用？

实际上完全不够用。

为什么？因为 AI Agent 的 context 消耗远比你想象的快。我们看一个具体场景。

用户跟 opencode 说"修一下 src/auth/login.ts 的 bug"。opencode 在 LLM 调用里的 context 包含：

• system prompt（5 张脸之一 + AGENTS.md + 工具描述）：约 10K tokens
• 用户的请求：~30 tokens
• LLM 调用 read 读了 login.ts（200 行代码）：约 3K tokens 占用
• LLM 调用 grep 找相关函数（10 个结果）：约 500 tokens
• LLM 调用 read 读了相关的 token.ts（150 行）：约 2K tokens
• LLM 几次思考的文字输出：约 1K tokens
• 几次 tool_call 的 metadata：约 500 tokens

到这里已经 17K tokens——任务还没开始改代码。

如果继续：

• LLM 调用 edit 修复 bug（要重复完整 messages 历史，包含前面所有内容）
• LLM 调用 bash 跑测试（测试输出可能 2-5K tokens）
• LLM 调用 read 重新看修复后的代码确认（再 3K）
• 多次思考和决策

一次任务下来——30-50K tokens 是常态。

继续聊几个任务——很快就 100K。

到 200K——Claude 的 max context 满了。你必须做 compaction（压缩历史）或者开新 session。

这就是为什么 ChatGPT、Cursor、opencode 在长对话上"很贵且突然就要重启"——不是 bug——是 context window 的物理限制。

三、Token 是延迟——长 context 慢得反直觉

Token 不止是钱——还是等待时间。

LLM 处理 context 的成本随长度平方增长（4.1 章详讲）。这意味着——

• 1K context：首 token 延迟 0.3-0.5 秒
• 10K context：1-2 秒
• 50K context：3-5 秒
• 100K context：5-10 秒
• 200K context：可能 15-30 秒

如果你的 AI 产品塞了大量 context 给 LLM——用户会等很久才看到第一个字。这对体验是致命的——人能容忍 1-2 秒——5 秒就会觉得"卡了"。

这是为什么很多 AI 产品看似可以"塞大量内容"但实际产品里不这么做——长 context 让产品慢得不可接受。

工程上的应对是——把大 context 任务拆成多个小 context 任务。比如让 AI 总结 50 个文档——不是塞 50 个文档一次性总结——是先并行总结每个文档（每个 5K context、很快）、再用每个的摘要做最终总结（5K × 50 个摘要 = 250K，仍然小）。

这种"分块"策略比"塞大 context"快 5-10 倍——而且效果通常更好（因为避免 lost in the middle）。

四、Token 是钱——直接对应账单

最直接的——token 就是钱。

LLM 厂商按 token 收费。每家定价不同——大致几个量级：

• 便宜模型（Claude 3 Haiku、Gemini Flash、GPT-4o mini）：input ~$0.10-0.25 每百万 token，output ~$0.50-1 每百万 token
• 中等模型（Claude 3.5 Sonnet、GPT-4o）：input ~$2.50-3 每百万 token，output ~$10-15 每百万 token
• 贵模型（Claude 3 Opus、GPT-4、o1）：input ~$15-30 每百万 token，output ~$60-120 每百万 token

注意——output 通常是 input 的 3-5 倍价。

为什么？因为 LLM 生成 output 需要逐 token 推理——每个 output token 都是一次完整推理——比读 input 慢且贵。

实际成本的累积：

• ChatGPT 普通用户一天 100 turn——10K-50K token——大约 $0.05-0.30 / 天
• Cursor 重度用户一天写代码——可能 500K-1M token——$5-15 / 天
• 自动化 Agent 跑一个复杂任务——50K-200K token——$1-5 / 任务

为什么 ChatGPT 每月只收 $20——而你看到的"成本"远超这个？因为 OpenAI 按"批量平均"算——很多用户其实只用一点——少数重度用户被 $20 上限保护——OpenAI 自己吃亏。这种"压力测试"让 OpenAI 烧了大量钱——是它必须不断融资的原因。

如果你做 AI 产品——你没有 OpenAI 的资金缓冲。用户每用一次 token——你都要付钱给 LLM 厂商。如果你定价 $10/月——一个重度用户消耗 $50/月的 token——你亏 $40/月。

这是 AI 产品定价的真实挑战——怎么让定价覆盖 token 成本。要么限用量（"每天最多 100 message"）、要么限模型（"普通用户只能用 GPT-4o mini"）、要么按使用量收费（"$10/月 含 100K token，超出按 $0.01/K token"）。

每种策略都有代价——理解 token 经济学，你才能做出合理的产品决策。

五、为什么 Anthropic 的 prompt caching 是革命性的

如果说 token 成本是个固定约束——那 prompt caching 是个改变游戏规则的优化。

我们已经在 6.8 章详细讲过 prompt caching——这里从产品角度再看一次。

每次 LLM 调用都要把完整 messages 历史发过去——里面 system prompt + 工具描述这些不变的部分占大头（在 opencode 里大概 10K-15K tokens）。

如果你的 session 跑 50 个 turn——这 10-15K 被发送了 50 次——你付了 50 次钱。这是巨大的浪费——同样内容为什么要重复付钱？

Anthropic 在 2024 年推出 prompt caching——LLM 服务端识别出"重复的 prompt 前缀"——给你只收 10% 的钱。

具体说——

• 第一次请求：你的 prompt 包含 10K 不变 + 1K 变化——按全价付 11K input cost
• 同时 Anthropic 服务端把 10K 不变部分做哈希、缓存住
• 第二次请求（5 分钟内）：同样的 10K 不变 + 不同 1K——Anthropic 识别缓存命中——10K 部分只付 1K 的钱（10% 折扣）+ 1K 变化部分付全价

这意味着——你的成本从 11K input 降到 2K input —— 5.5 倍降本。

长 session 累积下来——一个 50 turn 的 session 你能省 90% input cost。

Anthropic 推 caching 之后——AI 产品的 token 成本结构彻底改变。原来"长 session 越用越贵"——现在"长 session 越用越省（相对）"。

但这有几个关键约束——

约束 1：你必须标记 cache_control。Anthropic 不会自动缓存——你的 API 调用必须显式说"这部分缓存"。OpenAI 的 caching 是自动的（不需要标记）——但折扣只有 50%（不如 Anthropic 90%）。

约束 2：5 分钟 TTL。缓存只活 5 分钟——超过这个时间，缓存失效——下次又要付全价。

约束 3：稳定结构。你 cache 的部分必须完全不变——一个字符都不能改。否则缓存不命中——白付了 cache 创建的钱（cache_write 比正常贵 1.25 倍）。

理解 caching 是设计 AI 产品的核心技能。不会用 caching——你的产品成本是别人的 10 倍。

六、opencode 的"token 算账三件套"

opencode 在 token 管理上有几个具体设计——反映对 token 经济学的理解。

设计 1：粗估算 + 精确报销。

opencode 内部用一个简化的估算——4 字符等于 1 token（对英文准、对中文差一倍）。它不调 provider 的精确 tokenizer——避免性能开销。

但报销时用真实值——每次 LLM 响应里都带 usage.input_tokens / usage.output_tokens 准确值——opencode 用真实值算 cost 累加。

估算用于"决策"（要不要触发 compaction），报销用于"账单"（用户看到的成本）。两者性质不同——分别用合适的方法。

设计 2：三个魔法数字驱动 compaction。

opencode 在 compaction.ts 定义了：

PRUNE_MINIMUM = 20_000
PRUNE_PROTECT = 40_000
DEFAULT_TAIL_TURNS = 2

不到 20K 不压（压缩本身有成本、压少了不值）。最近 40K 范围保护（保留工作记忆）。最近 2 个 turn 不压（保护对话流）。

这三个数字是 opencode 团队大量实验调出来的"经验值"——反映 LLM 在 effective context 大约 60K-80K 时质量明显衰减——所以在 60K-80K 之间触发 compaction 是合理的。

设计 3：cost 透明显示。

opencode UI 上展示每次对话的 token 消耗和 cost：

Input: 1,234 tokens × $3/M = $0.0037
Cache read: 12,000 tokens × $0.3/M = $0.0036
Output: 567 tokens × $15/M = $0.0085
Total this turn: $0.0158
Session total: $0.42

让用户感知自己花了多少钱。

这是个开发者工具的姿态——开发者想知道成本——透明让他们能做决策（"这个 model 太贵了我换一个"）。普通用户工具可能不这样——但对 opencode 的目标用户合适。

七、token 是 AI 产品的"石油"

让我们退一步看整张图。

token 在 AI 产品里的地位——类似石油在工业经济里的地位。

它是最底层的资源——所有上层产品都依赖它。

它是有限且稀缺的——LLM 厂商的 GPU 产能、网络带宽、context window 都限制了 token 的"产量"。

它是有价格的——token 价格反映了"LLM 计算的实际成本"——LLM 厂商靠卖 token 赚钱。

它是有质量差的——便宜模型的 token 不等于贵模型的 token——同样数量但能力不同。

它是有损耗的——长 context 上 effective token 远少于 input token——你付了钱但模型没真用上。

它驱动了所有上层创新——RAG、Agent、multimodal、reasoning——本质都是怎么更有效地用 token。

理解了这件事——你看 AI 产品的视角就变了。每次设计判断都问：

• 这个 feature 需要多少 token？
• 用便宜模型够吗？
• 能 cache 吗？
• 长 context 是真用得上还是 marketing？
• 用户会愿意付这个 token cost 吗？

把这些问题想清楚——你才能做出真正能 scale 的 AI 产品。

下一章 0.4 我们看 token 的"另一面"——system prompt 和 context 怎么构成 LLM 的"工作语境"。