Token 估算器

大模型把文本切成 Token 计费与限长。英文约 4 字符 1 Token; 中文通常更省或更费; 取决于分词器。

本工具用启发式公式; 与官方 tiktoken 可能差几个 Token; 但足够做预算与裁剪。

在编写 LLM 提示词时，先在此工具粘贴文本，实时观察 Token 变化。当接近模型限制（如 GPT-4 的 8k）时，工具会高亮提醒。此时可删减冗余内容或拆分 Prompt，确保完整信息能送入模型。

对于技术文档翻译等长文本，用「段落模式」逐段检查。先处理标题和关键段落，保留 20% Token 余量给模型回复。中英混排时，注意中文 1 字≈1.5 Token 的消耗特点。

OpenAI、Anthropic 等按 input/output token 计费。发送前用本工具估算 prompt 长度，避免意外账单或截断。不同模型 tokenizer 可能略有差异——本工具给出近似值，临界场景留 5–10% 余量。

RAG 管道中，chunk + system prompt + user question 总和必须低于 context window。配合 json-formatter 查看 retrieved docs 体积，structured-output-validator 约束输出长度。

中文通常每字 1–2 token，高于英文词均 token 数。代码块（JSON、SQL）因符号密集 token 密度高。粘贴前删除无关 log 行可显著降本。

llm-json-extractor 提取 JSON 后再计数，避免 Markdown 包装占用 token。pii-scanner 在发送前脱敏，减少无效字符同时降泄露风险。

建立 prompt 模板最大 token 预算；PR review 大 prompt 变更时附 token 估算截图。text-analyzer 统计字符，token-counter 估算模型 token——两者互补。

微调数据集准备时，统计样本分布避免极端长例主导 loss。

先为 system、检索片段、用户问题、工具 schema 分配预算，再用本工具分别计数后求和。超限时优先截断检索片段而非删除安全相关 system 规则。structured-output-validator 约束输出 schema，避免模型用超长散文烧掉输出配额。

把预算表写进团队 Prompt 规范；大变更 PR 附上计数结果。临界窗口留 5–10% 余量，因各厂商 tokenizer 存在细微差别。

日志与工单进模型前：pii-scanner → 人工替换 → token-counter。先计数再脱敏会低估安全流程耗时，也容易把密钥计进「必要上下文」。jwt-decoder 仅用于确认 token 类型后删除原文，不要把完整 JWT 留在 prompt。

本地计数不上传文本，但你粘贴到聊天产品时仍会离开浏览器。Towalles 只解决估算步骤的本地化。

同一段中文在不同厂商 tokenizer 下计数可能差 10–20%。做法：固定一段「黄金样本」（含中英、代码、标点），在本工具与目标 API usage 各记一笔，算出系数后再做预算。不要假设「字符/4」通用于所有模型。

更换模型家族时重测黄金样本；把系数表放进内部 wiki。RAG 场景分别统计 query、top-k 片段与 system，避免只看总数。

Function/tool schema、JSON Schema 枚举值、长 system 安全策略都会占输入 token。先把 schema 单独计数，再决定是否内联巨大 enum。输出端若强制长 JSON，预留输出预算，否则会在末尾截断导致解析失败。

用 structured-output-validator 验证最小成功响应，再反推「最小必要 schema」。配合 pii-scanner，避免把真实客户字段名写进示例 schema。

同一段 prompt 在不同模型上的 token 数与单价都不同。用本工具得到稳定输入长度后，再乘各厂商价目做「成本上限」表：简单分类走小模型，长文档摘要走大模型。把阈值写进路由配置，而不是每次靠感觉。

变更 system prompt 时重新计数并更新预算表。隐藏的工具 schema / function calling 定义也会占配额——把它们单独计数后再求和。

切片重叠能提高召回，但会线性推高检索拼进 prompt 的 token。先对单片、重叠区、最终拼装结果分别计数，再决定 overlap。用 structured-output-validator 限制答案结构，避免模型用冗长复述吃掉输出预算。

把「最大检索片段 token」写成服务配置；超限时截断并记录指标，而不是静默超账单。