一、Token 不是字，也不是词
模型不直接处理字符，而是先把文本切成 token（子词单元），再映射成数字。常见的切分算法是 BPE（Byte Pair Encoding）：从字符开始，反复合并出现频率最高的相邻对，最终形成一个平衡「词表大小」与「表达能力」的子词表。
结果就是：
- 常见英文单词往往是 1 个 token（
the、data）。 - 生僻词、长词会被拆成多个（
tokenization→token+ization）。 - 中文常见词可能 1–2 个 token，生僻字可能 2–3 个。
- 数字、符号、空格也占 token。
二、中英文的差异
粗略估算（不同模型差异较大）：
| 内容 | 大致 token 数 |
|---|---|
| 1 个英文单词 | 1.3 token |
| 1000 个英文字符 | 约 250 token |
| 1 个汉字 | 1–2 token |
| 1000 个汉字 | 约 1000–1500 token |
所以同样信息量，中文消耗的 token 通常比英文多。这也是很多模型按「每千 token」计费时，中文用户感觉更贵的原因之一。
准确数字要用对应模型的分词器算，估算只能用于粗算预算。
三、上下文窗口是什么
上下文窗口 = 一次请求里「输入 + 输出」能容纳的最大 token 数。常见规格有 8K、32K、128K、200K 等。
关键理解：
- 窗口是总容量，输入占得多，输出就少。
- 超出窗口会报错或被截断（不同 API 行为不同）。
- 「支持 128K」不意味着效果在 128K 时一样好——长上下文中部信息容易被忽略（俗称「lost in the middle」）。
所以不是「能塞多少塞多少」，而是「塞对内容」。
四、计费方式
主流 API 按 token 计费，且输入与输出价格不同（输出通常贵 2–4 倍）：
费用 = 输入 token × 输入单价 + 输出 token × 输出单价影响因素：
- 多轮对话：每轮都要把历史消息重新发一遍，token 数随轮次线性增长。长对话成本上升很快。
- 系统提示：每次都计入输入，长系统提示是隐性成本。
- 流式输出：不减少 token，但改善体验。
- 缓存机制：部分厂商对重复的前缀（如固定系统提示）提供缓存折扣。
五、超长文本怎么处理
| 策略 | 适用 | 代价 |
|---|---|---|
| 直接截断 | 只要开头/结尾的信息 | 丢失中间内容 |
| 分段总结再汇总 | 长文档、会议记录 | 多次调用，成本增加，细节损失 |
| 检索增强（RAG） | 知识库问答 | 需要向量库与切分策略 |
| 结构化抽取 | 表单、合同字段 | 需要设计字段与校验 |
「分段总结再汇总」的常见坑是：每段总结会丢掉细节，最终汇总可能答不出具体数字。需要精确信息时，应该先检索定位到具体段落，再把原文片段喂给模型。
六、降低成本的实际做法
- 精简系统提示：去掉冗余说明，用结构化格式代替长段落。
- 控制历史轮次：只保留最近 N 轮 + 一条摘要，而不是全量历史。
- 限制输出长度：明确「不超过 100 字」，避免模型长篇发挥。
- 用小模型做预处理：分类、抽取、改写用便宜模型，复杂推理再用大模型。
- 缓存重复请求：相同输入直接命中缓存。
- 批量合并：把多个小任务合并成一次请求（注意别超过窗口）。
七、估算与监控
- 上线前用真实样本估算平均 token 与调用量，算月度成本。
- 上线后记录每次调用的 token 数（多数 API 的响应里带 usage 字段），按功能维度拆分。
- 设置预算告警，防止异常流量（如循环调用、爬虫刷接口）导致账单暴涨。
八、常见误解
- 「字数 = token 数」：不等，中文尤其不等。
- 「上下文越大越好」：成本更高，且长上下文效果不一定更好。
- 「输出不计费」：输出通常更贵。
- 「流式输出更便宜」：只是体验不同，计费一样。
小结
Token 是子词单元，中文通常比英文更耗 token；上下文窗口是输入加输出的总容量；输出比输入贵；长对话成本随轮次增长；省钱的顺序是精简提示、控制历史、限制输出、小模型预处理。