速查在线工具箱上下文窗口写着 128K，为什么装不下 128K 字？
窗口的单位是 token 不是字，而且输入和输出共用同一个额度。
两个原因。第一，窗口的单位是 token，不是字。token 是分词器切出来的片段，一个汉字可能占 0.6 个也可能占 1.5 个，跟模型训练用的语料有关，所以 131 072 个 token 换算成汉字是一个区间，而不是一个确切的数。
第二，也是更常被忽略的一点：输入和输出共用同一个窗口。你贴进去的长文档、模型生成的长回答、系统提示词、以及之前所有的对话历史，全都算在同一个额度里。所以「能装 128K」从来不等于「你能贴 128K 字」。
「上下文窗口 128K」这句话看着很明确，实际用起来总有落差：文档明明没到那个字数，还是提示超长；或者聊着聊着，模型忽然忘了前面说过什么。
落差来自两层换算。第一层是单位：窗口计的是 token，不是字，而 token 和汉字之间没有固定汇率。第二层是口径：窗口是所有内容共享的一个总预算，而不是「你能单独输入的额度」。把这两层分开看，很多现象就都对上了。
1token 是什么，为什么和字对不上
它既不是字也不是词，而是分词器切出的最小片段。
| 内容 | 大致换算 | 说明 |
|---|---|---|
| 英文单词 | 1 个约等于 1.3 个 token | 长词和生僻词会被拆成多个片段 |
| 英文文本 | 1 个 token 约等于 4 个字符 | 常用于估算纯英文长度 |
| 中文汉字 | 1 个字约等于 0.6 到 1.5 个 token | 取决于分词器与训练语料 |
| 标点与空白 | 通常各占若干 token | 代码和大段符号往往比正文更费额度 |
所以「128K 大约等于 16 万字」只是一个数量级的说法。真要估算成本或余量，用工具按实际文本数一遍才准。
2同一个窗口，装的不只是你的输入
列出到底有哪些内容在争同一份额度，就能理解为什么可用量比标称值小。
- 系统提示词与规则
- 每次请求都会带上，是一份固定的开销。
- 工具与函数定义
- 如果开启了工具调用，它们的描述也计入门限。
- 历史对话
- 多轮对话的每一轮都在累积，聊得越久占用越多。
- 本轮输入
- 你粘贴的文档、上传的文本内容。
- 模型输出
- 生成的回答同样占额度，而且是在生成过程中逐步占用。
- 多模态内容
- 图片、音频等会被换算成对应的 token 数量，往往比同等信息量的纯文本更贵。
「模型失忆」多半不是故障，而是窗口满了之后较早的内容被截断或压缩。理解了这一点，就知道该整理对话而不是重开一轮。
3怎么估、怎么省
两个动作就够用了：先估准，再按估出来的结果决定怎么切。
- 用工具把待处理的文本数一遍 token 数，不要用字数除以某个固定系数去猜。
- 把系统提示、工具定义、历史对话的占用也估算进去，得到真实的剩余额度。
- 为输出预留额度：希望模型给出较长回答时，输入部分就要留出空间，否则会提前触发截断。
- 长文档先做结构化再喂：分块之后只把与当前问题相关的块放进窗口。
- 长对话及时总结：把早期内容压缩成一段摘要替换掉原文，比让模型硬扛更稳定。
- 记录一次实测数据：同一段文本数出来的 token 数，可以作为后续估值的锚点。
顺着这个问题往下用
全部工具总览 →相关疑问
为什么同样一段中文，在不同模型上 token 数不同？
因为分词器不同。词表更大、中文语料更多的分词器，能把更多常用汉字组合合并成单个 token，中文效率就更高；以英文为主的词表，中文往往会被拆得更碎。
窗口越大，回答质量就越好吗？
不一定。窗口大意味着能一次性塞进更多材料，但注意力被摊薄、成本上升也是代价。对多数任务，精准检索出相关片段比把整本书塞进去效果更好。
超长文档必须切成小块吗？
多数情况下是。切块时要考虑每块自身是否语义完整，以及相邻块之间是否需要重叠，这两点直接影响后续检索能不能命中。
按 token 计费和窗口超限是同一个问题吗？
不是。计费关心总共用了多少 token，窗口关心一次请求能装多少。前者决定花多少钱，后者决定这次任务能不能完成。
继续看：相关问题与资料
全部问题解答 →内容说明：本页针对具体使用问题作答，方法步骤与数值由本站自行整理与复算，事实性内容以对应官方规范与文档为准。内容最后核对日期：2026-10-08。若发现错误，欢迎通过页脚反馈入口告知。