LLM Token 计数器 + 成本估算
Claude / GPT / Gemini / Llama / Mistral 的 token 数 + 成本估算
完全免费
无需注册
浏览器内完成
5 种语言
深色模式
字符
0
词
0
CJK
0
行
0
📐 估算方法
- • ASCII: ~4 chars / token (GPT BPE 平均值)
- • CJK: ~1.5 tokens / char (GPT 与 Claude 均是)
- • 精确值 ±10-20%
| 模型 | 输入 | 输出 | 输入价 | 输出价 | 总成本 | 上下文 | 使用率 |
|---|
📖 常见的坑
粘贴文本后，本工具会估算在主流 LLM 上的 token 数与大致成本。处理全部在浏览器内完成。这里给出的是估算值——各家的分词器各不相同，同一句话在不同模型上可能相差一成左右。需要精确数值时，请使用各家官方的 token 计数 API。本页面的用途是确认你没有搞错数量级。
| 情形 | 会发生什么 | 怎么处理 |
|---|---|---|
| 用英文的直觉估算中日文成本 | 英文大约每 4 个字符 1 个 token，而中文、日文、韩文则是每个字 1~2 个 token。也就是说，同样的字数，token 数会多出 5~8 倍。按英文提示词做的预算直接换成中文，账单往往是预期的数倍。 | 请用你实际会使用的语言的真实文本来测量。先测出单次请求的输入与输出 token 数，再乘以每月请求数后再做判断。若想降低成本，把数据翻成英文通常不如只把提示词（指令部分）写成英文、输入数据保持原文——指令每次都相同，缩短它会对所有请求都生效。 |
| 只按输入 token 估算 | 输出 token 的单价通常是输入的 3~5 倍。摘要长文档很便宜，因为输入大、输出小；而由简短指令生成长文本的任务，即便输入只有几十个 token，账单的绝大部分也落在输出侧。在多轮对话场景中，更容易被忽略的是：整个历史记录每一轮都会作为输入再发送一次。 | 请分别估算输入与输出，各自乘以单价后再相加。若输出长度难以预测，可用 max_tokens 设上限，并按该上限计算以留出安全余量。在对话场景中，不要发送完整历史，改为只发最近 N 轮或一份滚动摘要，token 数就不会随轮次线性增长。 |
| 以为塞得进上下文窗口就没问题 | 「装得下」与「被正确使用」是两回事。在长输入中，反复观察到中段信息比开头与结尾更不受重视（lost in the middle）。此外，把上下文塞满还会同时抬高单次请求的成本与响应时间。 | 请把重要指令放在输入的末尾。先粘贴资料、再写「基于以上……」的顺序，比把指令放在开头更稳定。若文档很大，这就是应当停止全量传入、改为只检索相关部分再传入（RAG）的时点。切分方法整理在 RAG 文本分块器。 |
若每次都发送相同内容，请确认是否可以使用提示词缓存。把系统提示词、参考文档这类在请求之间不变的前置部分缓存起来，该部分的输入单价会大幅下降。要用上它，需要把不变的部分集中放在开头，因此在设计阶段就考虑好，之后就不必回头改写。各模型的单价与适用条件不同，请查阅各家的价格页面。
📖 使用方法
-
1
粘贴文本粘贴到左侧
-
2
预期输出 + 选项输出 + 选项
-
3
比较决策成本 + 上下文
❓ 常见问题
准确？
近似 ±10-20%
价格何时？
2026-04
Batch / 缓存？
Batch 50% / 缓存 10%
🐛 此工具出现问题了吗？
免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。
✅
感谢您的反馈！
已送达运营者,将用于改进工具。