字节、Token 与上下文窗口换算
大模型 API 与产品文档中的 上下文窗口（如 100K、128K）以 Token 数 计量，与文件系统里的 字节（Byte） 是两套独立单位，不能直接等同。
本文说明两者的区别、换算关系，以及估算文档能否放入给定上下文窗口的方法。
一、两种度量单位
| 维度 | 存储大小（Byte/KB/MB） | 上下文大小（Token） |
|---|---|---|
| 衡量对象 | 磁盘/内存中的文件体积 | 模型推理时的输入计数单位 |
| 计算依据 | 字符编码（UTF-8、GBK 等） | 分词器（Tokenizer）切分结果 |
| 典型场景 | 文件大小、带宽、存储成本 | API 计费、上下文上限、生成速度（TPS） |
结论：宣称「100K 上下文」表示最多约 100,000 个 Token，而非 100 KB 数据。
二、字节 → Token 换算
1. 基本假设
以下估算以 UTF-8 编码 为准（现代 Web、API 的默认编码）：
| 字符类型 | 存储占用 |
|---|---|
| 英文字母、数字、常见标点 | 1 Byte/字符 |
| 常用汉字 | 3 Byte/字符 |
分词器在切分前会将输入统一解码为 Unicode，不依赖底层字节编码（GBK 与 UTF-8 的字节差异不影响 Token 计数逻辑）。
2. 经验换算系数
| 文本类型 | Token/字符（经验值） | 说明 |
|---|---|---|
| 英文 | ≈ 1 Token / 4 字符 | 含空格与标点；约 0.75 个英文单词 |
| 中文 | ≈ 1 ~ 1.5 Token / 字 | 常见字多为 1 Token；生僻组合可能为 2 |
3. 100 KB 文件示例
纯英文（100 KB ≈ 102,400 字符）
102,400 字符 ÷ 4 ≈ 25,600 Token
纯中文（100 KB ≈ 34,133 汉字，按 3 Byte/字）
34,133 字 × 1.2 ≈ 40,960 Token
三、编码与 Token 的关系
存储层面的编码换算（如 100 KB = 51,200 汉字 在 GBK 下成立）不能直接用于 Token 估算，原因如下：
- 分词器按字符切分：API 接收文本后先转为 Unicode 再 Tokenize，与文件在磁盘上的字节编码无关。
- 中文信息密度高：汉字占 3 字节，但分词后常接近 1 Token/字，Token 数通常 小于 字节数 ÷ 3。
- 英文 Token 密度低：1 字节 ≈ 1 字符，但约 4 字符才对应 1 Token，Token 数约为 字节数 ÷ 4。
四、上下文窗口容量速查
以 100K Token 上下文窗口为例（UTF-8、纯文本）：
| 文本类型 | 文件大小 | 约等于 Token | 占 100K 窗口比例 |
|---|---|---|---|
| 纯英文 | 100 KB | ~2.5 万 | ~25% |
| 纯中文 | 100 KB | ~4 万 | ~40% |
| 纯英文 | 400 KB | ~10 万 | ~100%（接近上限） |
| 纯中文 | 250 KB | ~10 万 | ~100%（接近上限） |
粗略上限（100K Token 窗口）：
- 纯英文文档：约 400 KB
- 纯中文文档：约 250 KB
实际占用还受 Markdown 标记、代码块、JSON 结构、混合语种等因素影响，上述值为工程估算，非精确值。
五、精确计算方式
经验公式适用于快速估算；精确计数应使用对应模型的 Tokenizer：
- OpenAI：Tokenizer 工具
- 其他厂商：查阅各 API 文档提供的 Token 计数接口或 SDK 方法
输入 Token 数 = 系统提示词 + 历史对话 + 当前用户消息 + 检索/工具返回内容；任一环节超限都会导致截断或报错。
六、与相关概念的关系
| 概念 | 关系 |
|---|---|
| Token | 上下文窗口的上限单位；计费与 TPS 均按 Token 计 |
| 上下文窗口 | 单次请求可处理的 Token 总量（输入 + 输出，具体以 API 文档为准） |
| 文件大小 | 仅反映存储体积；需经 Tokenize 后才能与窗口上限比较 |
要点：评估文档能否放入模型上下文，应计算 Token 数，而非文件 KB 数。