分词器与 token 估算
模型按 token 计量与限长，而 token 不是字符也不是词：中英文、数字、代码、罕见符号的切分密度差别很大。估算的可靠做法是用目标模型自带的分词器实测，再留出余量；用固定系数硬估在长数字、代码与多语言混排场景下误差会很明显。
基本信息
| 术语 | tokenizer、BPE、词表大小、上下文窗口 |
|---|---|
| 差异来源 | 不同模型分词规则不同，同一段文本 token 数不同 |
| 中文 | 常见一字约 0.6 到 1 个 token，随分词器与文本变化 |
| 数字与代码 | 切分更碎，长数字串与符号组合消耗更多 token |
| 预算 | 估算值乘以 1.1 到 1.3 作为上限，别贴着窗口边界设计 |
典型使用场景
- 设计提示长度：按目标分词器实测系统提示与示例占多少
- 控制成本：估算单次输入输出 token，再推算单位任务成本
- 上下文裁剪：判断保留几轮原文时，用实测数字而不是字数
- 选择模型：同一任务在两种分词器下的 token 数可能差出可观比例
- 评测对比：固定输入下统计 token 消耗，发现提示膨胀的版本
估算与留余量
估算与留余量
实测路径:
tokens = len(tokenizer.encode(text)) # 用目标模型的分词器
粗略参考:
中文正文 约 0.6 到 1 token 每字
英文单词 约 1 到 1.3 token 每词
数字与代码 切分更碎，长数字串尤其明显
预算: 估算值 × 1.1 到 1.3，给输出与格式留空间内容类型与 token 密度
| 内容类型 | 密度特点 | 估算建议 |
|---|---|---|
| 中英混排正文 | 介于两者之间 | 以实测为准，别取平均系数 |
| 长数字与编号 | 切分碎，消耗偏高 | 单独测算，容易被低估 |
| 代码与符号 | 符号与缩进都占 token | 按实测，不要按字符数折算 |
| 表格与 JSON | 键名重复出现，累积可观 | 结构越扁平越省 |
不同模型之间不能互推 token 数：按一个模型的分词估算另一个模型的费用，误差可能超过三成，成本预算会直接失真。