Token 估算与成本测算

📖 Token 估算与成本测算使用说明

大模型不按字数计费，按 token 计费。token 是模型分词器切出来的最小单位，一个英文单词可能是一个 token，一个汉字可能是一个也可能是两个，具体取决于用的是哪个分词器。这款工具按字符类型分别折算，给出一个量级参考，同时算出它占各种上下文窗口的比例和大致的调用成本。

它解决的是几个很实际的问题：这份提示词会不会撑爆窗口？这批内容跑一遍要花多少钱？把提示词精简三成能省多少？内容全部在浏览器里处理，商业提示词也可以放心估。

一、估算是怎么算的？

精确的 token 数只有跑一遍对应模型的分词器才知道。纯前端做不到加载各家的词表——那些文件动辄几兆——所以这里用的是按字符类型分档的折算：

• 汉字与中日韩字符：按每字符 1 到 1.5 个 token 折算。新一代分词器对中文更友好，同样一段中文，用较新的词表切出来的 token 数比早期词表少三成左右。
• 英文字母：按每 4 个字符约 1 个 token 折算。这是英文文本的经验值，常见词往往整词一个 token，生僻词和长词会被切成好几段。
• 数字：按每 2 到 3 位一个 token 折算。多数分词器把长数字切成小段，所以数字密集的内容 token 消耗比看起来高。
• 空白与标点：单独计入，空格常常与相邻单词合并成一个 token。
• 代码：符号密度高，实际 token 数通常比同长度的自然语言多两到三成，工具会在检测到明显代码特征时给出提示。

三档估算里，中间那档最接近实际。低档和高档给的是不同分词器口径下的上下界，把这个区间当作规划的余量比盯着某个具体数字更稳妥。

二、上下文窗口该怎么规划？

窗口大小是输入加输出的总额度，不是只算输入。规划时留三成余量是比较稳的做法：模型的回复、多轮对话的历史、系统提示词、工具定义，都要挤在同一个窗口里。

还有一点常被忽略：窗口大不等于效果好。把几十万 token 的资料一股脑塞进去，模型对中间部分的注意力会明显下降，这个现象在长上下文的评测里反复出现。与其把整本手册丢进去，不如先做检索再把最相关的几段送进去，这也是 RAG 存在的理由。

三、成本怎么估才不失真？

工具没有内置价目表，单价要你自己填。这是有意的：各家的价格调整很频繁，任何写死在页面里的数字过几个月就会误导人。填单价的时候注意三件事。

输入和输出的价格通常不一样，输出往往是输入的三到五倍。所以让模型少说废话，比压缩提示词更省钱——一个"请简明回答"的约束，效果可能超过精简一半的输入。

缓存能大幅降低重复调用的成本。如果每次请求都带同一段很长的系统提示词，各家的提示词缓存机制能把这部分的价格降到很低的水平。批量任务里这一项的影响往往比模型选型还大。

批量接口通常有折扣。不要求实时返回的任务走批量提交，价格一般是标准接口的一半左右。做内容批处理、离线分析这类活儿，这是最容易被忽略的省钱手段。

四、内容运营的人为什么要关心 token？

做内容和 SEO 的人现在绕不开这件事，有几个具体场景。

批量生成或改写的预算测算。一篇文章的提示词加输出大概多少 token，乘以篇数，就是这个项目的模型成本。先算清楚再决定用哪个档位的模型。

提示词的性价比优化。把提示词从三千 token 压到一千五，在一万次调用的规模上是实打实的成本差异。压缩的重点是删掉重复的说明和冗余示例，而不是删掉约束条件。

喂给模型的资料要不要精简。把一整篇长文塞进去让模型总结，和先切块检索再送最相关的部分，成本可能差十倍，效果还未必更差。

估算长文的处理可行性。一份几万字的报告是不是超出了某个模型的窗口，用这个工具先量一下，比调用失败再回头排查省事。

五、这款工具做不到什么？

• 它不是精确分词。这是按字符类型的折算估计，与真实分词器的差距通常在一成到一成五之间，混杂大量代码、表情或生僻字符时误差会更大。要精确数字，得用官方的分词库跑一遍。
• 它不区分具体模型。给的是新旧两类分词口径的区间，而不是某个具体模型的精确值。
• 它不算图片和音频。多模态输入有各自的计量方式，图片按尺寸折算成 token 的规则各家不同，这里只处理文本。
• 它不内置价格。单价由你填，工具只做乘法。这是特意的设计，避免过时的价格误导决策。
• 它不预测输出长度。输出 token 需要你自己估，可以先跑几次真实调用取平均。