Token 计数器与上下文预算
粘一段文本进去,看它大概是多少 token、在各模型的上下文窗口里占多大比例、单次调用多少钱, 以及照这个长度还能放几轮。文本不会离开你的浏览器。
上下文预算
| 模型 | 上下文 | 这段占比 | 还能放几轮 | 单次调用 |
|---|---|---|---|---|
| Claude Opus 5 Anthropic | 1000k | | — | — |
| Claude Sonnet 5 Anthropic | 1000k | | — | — |
| Claude Haiku 4.5 Anthropic | 200k | | — | — |
| DeepSeek V4 Pro DeepSeek | 1000k | | — | — |
| DeepSeek V4 Flash DeepSeek | 1000k | | — | — |
| Gemini 3.7 Flash Google | 1049k | | — | — |
| Gemini 3.5 Flash Lite Google | 1049k | | — | — |
| GPT-5.6 Sol OpenAI | 1050k | | — | — |
「还能放几轮」= 剩余上下文 ÷ 这段长度,并留出 4k token 给回答。
单次调用成本按「这段作为输入 + 800 token 输出」估算,用的是未命中缓存的价格。
要精确值请用厂商的 tokenizer 接口;这里给的是区间,用来做预算而不是对账。
为什么不直接跑一个真的分词器
真正的 BPE 分词器每个模型家族要带 1–2 MB 的词表,而且必须先下载完才能显示第一个数字 —— 换来的精度提升只有几个百分点。所以这里按文字种类估算, 因为误差的主要来源本来就在这儿:
- 拉丁文本:BPE 会把常见英文合并到大约 4 个字符 1 个 token。
- 中日韩文本:没有空格可合并,常用汉字通常 1 个 token,生僻字按 UTF-8 字节回退到 2–3 个。这里取 1.3 token / 字,区间 1.0–1.7。
- 空格和标点大多会跟着相邻词一起被合并,不单独计。
所以上面给的是一个区间而不是一个精确值。 做预算、判断会不会超上下文,这个精度足够;要对账或者卡在硬性上下文上限边缘时, 请用厂商自己的 tokenizer 接口拿准确数。一个坦白说明误差范围的估计,比一个看起来很精确但是错的数字有用。
上下文占比一列里,「还能放几轮」预留了 4k token 给模型的回答 —— 把上下文填到 100% 是最常见的一类线上事故:请求本身不报错,模型只是开始丢掉最早的内容。