用大模型算成本、估窗口，都绕不开 token。把它和字数画等号，是使用大模型时最常见的一笔糊涂账。
误区一：一个 token 就等于一个字
错在哪：token 是分词碎片，不是字。中文里「人工智能」可能是一个 token，也可能被切成两个字；英文里一个长单词就可能占三四个 token。切法完全由模型的分词器决定。
正确说法：token 与字数之间没有固定比例，只能用目标模型的计数器实测。粗估时，中文按一字一点几个 token、英文按一词一个 token 起步，再校正。
误区二：中英文的换算比例一样
错在哪：默认一套比例走天下。中文一字常占一到两个 token，英文单词平均不到一个 token，代码和数字的密度又不同。同一段内容中英混排时，简单乘系数必然跑偏。
正确说法：分开估再汇总。中文部分按字估，英文部分按词估，代码按行估，最后加一点余量，比一把倍数尺靠谱。分词器差异可以看分词器造成的 token 价差。
估错的代价在两端都会出现：估多了，白白按更贵的档位付费；估少了，上下文被截断，模型答非所问。写批处理脚本时，建议留 10% 左右的余量，并显式处理超长输入，别让截断静默发生。
实践中的估法可以更细：中文按每个字 1.5 个 token 起步，英文按每个词 0.75 个 token 起步，数字和标点单独加。先按这个粗框算一版，再拿真实文本校准误差，比拍脑袋准得多。
| 内容类型 | 粗估口径 | 注意 |
|---|---|---|
| 中文 | 每个字 1.5 个 token 起步 | 标点单独加 |
| 英文 | 每个词 0.75 个 token 起步 | 长单词可能占三四个 |
| 代码 | 按行估 | 缩进与标点同样占位 |
| 思考内容 | 单独列一行 | 推理模式下同样计费 |
长文本的切分方式也会影响 token 总量。同一份文档，按段落切和按固定长度切，重复填充的部分不一样，最后喂进去的 token 数可能差出一成。做批处理时把切分策略固定下来，成本才可预测。
还有一个隐蔽项是「思考 token」。开启推理模式后，模型内部的推敲过程同样计入用量，账单可能成倍上涨。评估预算时要把这部分单独列一行，别等账单出来才发现。
省钱的空间常常在输入端。系统提示里冗长的身份设定、每次重复粘贴的背景资料，都是白花的钱。把公共部分前置、利用缓存，把变动部分后置，是批处理场景的常规优化。省下的每一分，都是纯利润。
误区三：token 数直接等于花的钱
错在哪：忽略计费结构。输入和输出分开计价，两者的单价往往不同；部分平台还有阶梯价、缓存命中折扣、按量套餐。同样的 token 数，账单可能差不少。
正确说法：算账要按输入 token 数乘输入单价、加输出 token 数乘输出单价来，再叠加缓存和套餐折扣。想省钱，先砍输入冗余，再约束输出长度。推理模型的思考 token 同样计费，可以看推理模型的使用误区。
- 中文：一字约一到两个 token
- 英文：一词平均不到一个 token
- 代码：按行估，标点和缩进也占位
- 计费：输入输出分开，单价不同
窗口也按 token 算，塞多少材料直接受换算影响，可以看上下文 128K 的换算误区。文心一言、秘塔AI搜索的计费说明里都能看到 token 口径，对照着读更好理解。
换个问法再问token换算三句
- 怎么测自己的 token 数？：用平台自带的计算器或开源分词库，拿真实业务文本跑一遍，得出的数最可靠。
- 上下文窗口按 token 算，怎么规划？：先测文档的 token 占用，再留足回答空间，别按字数直接塞。
- 压缩提示词值得吗？：高频调用场景值得，删掉重复说明和客套，输入成本能降下一成到三成。
