这个工具解决什么问题

做大模型应用，最容易失控的一项成本就是 token。它不像服务器按月包干，而是随每一次调用、每一个字往上累加， 等月底看到账单的时候，钱已经花出去了。麻烦的是 token 这个单位对人来说很不直观—— 你盯着一段提示词，很难一眼看出它到底是「几十」还是「几百」的量级，也就无从判断 「把这段说明加进系统提示词，一天调十万次要多花多少」。

这个工具就是把那层直觉补上。粘一段文本进去，立刻给出估算的 token 数和字符数两个数。 它不替你决策，只是把一个抽象单位换算成你能比较的数字：这版提示词比那版多用多少、 一份合同大概占多少上下文、批量处理一万条这样的记录大致是什么数量级。有了量级， 后面的预算和选型才有得谈。

它实际是怎么算的

规则很朴素，也故意做得透明：逐字符扫一遍输入，CJK 字符（中日韩汉字以及全角标点）每个记 1 个 token； 其余字符——英文字母、数字、半角标点、空格、换行——按每 4 个字符折算 1 个 token，除不尽的向上取整。 两部分相加就是你看到的估算值。字符数则是文本的原始长度，中英文都按 1 个算，放在旁边供你对照。

需要特别强调一件事：上面这套规则是本工具的近似假设，不是通用换算公式。 真实模型用的分词器是训练出来的，各家词表不同、切法不同，同一段中文在不同分词器下可能被切成 差别不小的片段数；有的会把常见词组并成一个 token，有的遇到生僻字反而拆成好几片。 所以「几个汉字等于几个 token」这种记法在换一个模型之后就不成立了，本页刻意不提供这类固定比值。 你要的是量级，不是精确数——这一点想清楚，工具才用得对。

另外，所有计算都在你的浏览器里跑完，输入的文本不会被上传，粘贴内部资料也不必担心。

怎么用，结果怎么读

最直接的用法是做横向比较。写提示词的时候准备两版，分别粘进来看数差多少， 省下的那部分乘以你的日调用量，就是这次优化的实际价值。这种比较是相对的，即使绝对值有偏差， 谁更省的结论通常仍然成立，这也是估算工具最可靠的用法。

第二个用法是体量预判。手上有一批要送进模型的文档，抽几份典型的粘进来， 看看单份大概什么量级，再乘以份数，就能提前知道会不会撞上上下文窗口的上限， 是该直接整篇送、还是得先做切分和摘要。这一步在动手开发之前做，比跑一半发现超限再返工省事得多。

第三个用法是反推预算。拿到 token 量级之后，配合你实际拿到的单价，就能把月度成本估出来。 这里有个特别容易漏的坑：真正发出去的请求里，除了你粘的这段正文，还有系统提示词、 历史对话、工具定义、结构化输出的 schema——这些每一轮都要重新计入输入 token。 很多人第一次算预算严重偏低，就是因为只算了「用户说的那句话」。

局限在哪，什么时候必须以账单为准

说三条硬限制。第一，分词器差异无法消除。本工具不内置任何厂商的词表， 给的是一个中性的近似值，跟你实际用的模型之间必然有系统性偏差，方向和幅度取决于你用的是谁。 第二，它只算输入，不算输出。模型生成的回复同样计费，而且输出单价往往和输入不是一个价， 输出长度还受你的指令和参数影响，这部分本工具完全没有覆盖。 第三，它不知道你的调用结构。多轮对话的历史累积、失败重试、Agent 内部的多次往返， 都会让真实用量远超单次文本的估算，这些必须结合你的调用链路自己叠加。

所以正确的姿势是：用估算做量级判断和方案比较，用真实 usage 做对账和承诺。 真跑几次请求，把 API 返回的 usage 字段和本工具的估算值做个比值， 之后拿这个系数去修正批量预算，准确度立刻上一个台阶。凡是要写进合同、 要卡硬阈值的数字，一律以你自己的账单为准。

延伸阅读

想把中文场景的 token 估算讲得更细，包括为什么中英文差距那么大、怎么建立自己的经验系数， 可以看 中文 token 估算方法； 如果你发现账单大头在输出侧， 输出长度控制与成本 这篇讲了怎么用指令和参数把回复长度压下来，通常比换模型见效更快。