LLM Token 计数器与提示词缓存成本计算器

英文、代码与中文在主流 Tokenizer 下的计费差异

现代大模型普遍采用字节级或子词级分词器（如 OpenAI 的 o200k_base 系列、Anthropic 的 Claude 5 分词器以及 Gemini 的 SentencePiece 词表），而不是简单按空格分词。纯英文自然语言通常约 4 个字符折合 1 个 Token；但 JSON Schema、缩进空白、错误堆栈与代码符号会产生大量独立切分点，往往每 2.5 至 3.2 个字符就会消耗 1 个 Token。

中文、日文与韩文字符的编码密度更高，通常每 1 个汉字约消耗 0.7 至 1.1 个 Token；此外，Claude 5 系列采用的新分词器在处理密集代码与多语言文本时，可能比旧版 Sonnet 4.6 多产生约 25%–30% 的 Token，迁移时务必重新基线测算。

长上下文跳档线与提示词缓存如何决定真实月账单

只看基础输入单价很容易算错大请求账单：GPT-6 Astra、GPT-6.1 Terra 与 GPT-5.6 系列在单次总输入超过 272,000 Token（包含命中的缓存读取部分）时，整次请求都会切换到更高的 >272K 档位；Grok 4.7 与 Gemini 2.5 Pro 的跳档阈值为 200,000 Token，Claude Haiku 5.5 则在超过 100,000 Token 时跳档。

与此同时，只要把系统指令、工具定义与固定参考文档放在消息最前面并保持字节级一致，后续请求就能触发缓存读取（通常比非缓存输入低 75%–90%）。调节上方的“提示词缓存命中率”即可直观看到固定前缀带来的月度降本幅度。

• 将静态指令、JSON Schema 与 Few-shot 示例固定在消息头部，把动态时间戳和用户上下文追加在末尾。
• 拼接 RAG 检索结果前先做去重与截断，避免多塞一段无关文档把 265K 请求推过 272K 计费跳档线。
• 对于前缀复用率低的离线批处理任务，预算时还应计入首次缓存写入与失败重试开销。