Token与上下文窗口：从token数量看懂模型的「记忆」边界
为什么这件事值得你花10分钟
刚开始用大模型时，我最困惑的一个现象是：聊得好好的，突然模型就「忘了」最开头说的话；写长文档写到一半，后面的内容质量明显下滑；还有的时候直接报错提示长度超限。
当时我以为是模型不稳定，后来才明白，这一切都跟一个东西有关——token数量和它背后的上下文窗口。
搞懂这两个概念，你就能提前预判很多坑，而不是等模型「翻车」了才一头雾水。这篇文章就把它讲透。
先搞清楚：token到底在数什么
我们上一篇已经讲过token是模型处理文字的最小单位，这里快速回忆一个关键点：模型的一切长度限制，都是按token算的，不是按字数算的。
所以同一个意思，换种说法可能占用的token完全不同。这直接带来三个影响：
- 你输入的内容（提示词、文档、代码）要算token
- 模型输出的内容也要算token，而且输出和输入共用同一个空间
- 中英文混排、代码、空格多的文本，token消耗速度不一样
一句话总结：token是模型世界里的「空间单位」，而上下文窗口就是这套房间的总面积。
上下文窗口：模型的「短期记忆」
上下文窗口（Context Window）指模型单次对话中能同时「看到」的最大token总量。你可以把它想象成一张固定大小的桌子：
| 概念 | 含义 | 类比 |
|---|---|---|
| 上下文窗口 | 单次能处理的最大token总量 | 桌子的总面积 |
| 输入token | 你发给模型的内容 | 你摆在桌上的资料 |
| 输出token | 模型生成的内容 | 模型在桌上写下的回复 |
| 剩余空间 | 窗口减去输入和输出 | 桌上还能放东西的地方 |
三个必须知道的推论
- 模型记不住窗口之外的内容。 超出窗口的部分，模型是真的看不见，不是「记性不好」。
- 窗口不是「无限记忆」，而是「滚动视野」。 很多模型会保留最近的对话，较早的内容可能被压缩或丢弃，这解释了为什么长对话后期模型会「忘事」。
- 不同模型的窗口大小差异很大，具体数值以各家官方文档为准。选模型时，窗口大小是一个和能力同等重要的指标。
动手估算：你的内容占多少token
在把长文档丢给模型之前，先估算一下token占用，是避免超限的最好习惯。
经验速算法（不需要工具）
| 内容类型 | 粗略估算 |
|---|---|
| 英文 | 约4个字符≈1个token |
| 中文 | 约1个汉字≈1到1.5个token |
| 代码 | 约3到4个字符≈1个token |
| 空白与标点 | 也会占用token |
比如一篇8000字的中文稿件，按保守估计大概在8000到12000 token之间，再算上你的提示词和模型的回复空间，很可能已经吃掉相当一部分窗口了。
精确计数：用官方分词器数一数
想得到准确数字，可以用模型官方提供的分词工具。以OpenAI的tiktoken为例，安装后这样用：
import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
text = "你好，这是我的大模型学习笔记。"
ids = enc.encode(text)
print("token数量：", len(ids))
print("前3个token：", ids[:3])
print("还原文本：", enc.decode(ids))
其他模型通常也提供类似的计数入口：
- 官方API后台或Playground会显示当前请求的token用量
- 部分模型的网页端会在长对话时提示占用比例
- 社区里有各种在线token计数器，使用前建议对照官方工具验证一次
窗口「装不下」会发生什么
不同情况下的表现不一样，对症处理才有效：
| 现象 | 原因 | 应对 |
|---|---|---|
| API直接报错，提示长度超限 | 输入+输出超过了窗口 | 删减内容或分段处理 |
| 回复中途戛然而止 | 输出token把剩余空间用完了 | 要求「继续」或减少输出要求 |
| 模型忘记开头的要求 | 早期内容被挤出有效视野 | 重述关键约束，或开新对话 |
| 长文后半段质量下降 | 上下文过载，注意力被稀释 | 分段提问，逐块处理 |
这里有个容易忽略的细节：输入和输出共用窗口。你把窗口塞得越满，留给模型输出的空间就越少。所以我一般会刻意留出余量，不把空间用到顶。
实战技巧：在有限窗口里塞下更多
第一步：先分类，再瘦身
把要处理的内容分成三类：
- 必须逐字保留的——比如合同条款、原始数据、代码逻辑
- 可以压缩的——比如背景介绍、次要说明，改成要点式表述
- 可以直接删掉的——客套话、重复内容、与任务无关的段落
删完之后你会发现，需要的token可能只有原来的三分之一。
第二步：长任务拆成分段流水线
处理长文档时，与其一次性全塞进去，不如分段处理：
- 把文档按主题或章节切成若干段
- 对每段用同一个提示模板提问或加工
- 汇总各段结果，再让模型做一次整合
这样每一步都在窗口的安全范围内，输出质量也更稳定。
第三步：让模型帮你做「前置整理」
如果你实在懒得手动瘦身，可以先让模型用一句话总结上一段结论，用这个精简结论作为后续对话的上下文，替代大段原文。这招在多轮改稿、长文档问答里特别好用。
一个可复制的日常检查流程
每次处理长内容前，我会快速过一遍这几个问题：
- 我的内容大概多少token？（用速算法估一下）
- 这个模型的窗口是多少？（查官方文档）
- 留给输出的空间够不够？（至少留出你期望的回复长度）
- 有没有可以删掉的冗余段落？
- 任务太长的话，要不要分段？
这五问花不了1分钟，但能避开绝大多数「模型失忆」和「内容被截断」的坑。
小结
把这一篇的核心浓缩成三句话：
- token是模型计量内容的空间单位，上下文窗口是这个空间的上限
- 输入和输出共用窗口，所以永远不要把空间用到顶
- 估算、瘦身、分段，是在有限窗口内稳定输出的三个基本功
理解了token和窗口的关系，你对大模型的所有「奇怪表现」基本都能找到解释。下一篇我们继续聊大模型的其他实用知识，欢迎回来。