1 个 token ≈ 多少字：LLM 计费里的隐形单位

如果你算过 AI API 的账单，会发现计量单位不是"字"也不是"词"，而是 token。工程师常见的第一个问题：一个 token 是不是等于一个字？不完全是。

token 是怎么切出来的

现在的大模型几乎都用 BPE 一类的分词器，思路是：从字符甚至字节出发，看训练语料里哪些相邻片段出现得最频繁，就把它们合并成一个新符号，重复这个过程，直到词表达到预定大小。高频词整块保留，低频组合被拆开，词表里没有的（生僻字、emoji、特殊符号）落到字节级编码。

后果是不同语言差别很大：

- 英文：一个 token 约 4 个字符，折合 0.75 个单词

- 中文：一个常用字约 1~2 个 token，生僻词、地名、人名经常一字一切

- 日文、韩文和 emoji 同样偏贵

所以同样 1000 字的正文，中文比英文贵 2~3 倍。这不是定价歧视，是词表覆盖率的直接结果。

代码也比自然语言"贵"。标识符、下划线、camelCase、特殊符号在语料里出现频率低，往往两三字符一切；一笔和中文一样长的提交信息，token 数可能是日常对话的两倍。

别用肉眼数。两个做法：

1. 用 API 响应里的 usage 字段。prompt_tokens 和 completion_tokens 就是结算值，系统提示词、few-shot 示例、之前所有轮次都算在内。

2. 请求前想离线估算，就用对应模型族的分词器（如 OpenAI 系对应 tiktoken 的编码）。注意不同模型族词表不同，同一段文本的 token 数不一样，别把 GPT 系的数直接套到 Qwen 或 Claude 上。

量级估算够用就行：英文 1 token ≈ 4 个 ASCII 字符；中文 1 字 ≈ 1.5 个 token，上下浮动 30%。

1. **系统提示词每次都算钱。** 2000 token 的系统提示词调用 1 万次，就是 2000 万 token 的固定开销。支持 prompt caching 的平台，把静态内容放最前面，命中缓存后单价大幅下降。

2. **输出 token 单价通常是输入的 2~4 倍。** 影响成本最大的参数是模型话多话少。把回答限制在 500 token 内，往往比塞 2000 token 背景更省钱。

3. **调试与循环。** 复算、重试、多轮 function calling 的中间产物都是隐形 token。开发期把 usage 和回复一起打印，别只看文字。

假设一个客服问答系统：系统提示词 3000 token，用户提问平均 200 token，回答限制 600 token，每天调用 1 万次。单价按输入 3 元、输出 15 元每百万 token 算（数字仅作示例，套你实际用的价格）。

单次开销：输入 3200 token 约 0.0096 元，输出 600 token 约 0.009 元，合计约 0.0186 元；放大到每天 1 万次就是 186 元。

优化方向有两个，效率差别很大：把系统提示词砍半，每次省 1500 个输入 token，一天省 45 元，账单降四分之一；把回答平均长度从 600 压到 400 个 token，一天只省 1 元，毛毛雨。先动最大项，再用监控验证效果，比凭感觉改提示词靠谱。

标称上下文窗口是输入加输出的总预算。处理长文本时，可用输入 = 窗口上限 − 你还要生成的输出。计划"塞几篇文档进去"，要按扣除输出后的剩余额度算，不然会撞上截断或报错。

token 同时是三件事的单位：模型理解的最小颗粒、上下文预算的刻度、账单的计价单位。把 usage 字段打出来记下来，成本核算就从猜测变成四则运算：先量，再算，然后按金额从大到小一项项压。