LLM 按 token 计费,但 token 数和字符数并不成正比。一个 UUID(通用唯一标识符,就是一串带连字符的十六进制随机字符串)看起来不长,在 GPT-4o 的分词器里却要吃掉 18 个 token;换成短 id 只要 3 个。一段 pretty-printed(带缩进和换行的美化格式)JSON 要 16 token,minified(压缩成一行)只要 9。这些差距不是玄学,而是分词器(tokenizer,把文本切成模型能处理的最小单元的算法)的 BPE(字节对编码,一种通过合并高频字符对来切词的子词算法)机制决定的:随机字符串找不到可复用的模式,几乎一个字符一个 token。
Tokensift 就是干这个的:一个开源的 token 效率 linter(静态检查工具),专门扫描 LLM prompt 和 payload(请求体),指出哪些地方在浪费 token。它像 ESLint 检查未使用变量一样,检查的是文本里那些花了钱却不给模型提供信息的片段。核心引擎、20 条内置规则、CLI、以及 vitest/jest 的 matcher(测试断言工具)都已经可用。OpenAI 模型用官方 BPE 词表,计数精确;Claude 没有公开 tokenizer,所以用校准过的估计值,每条 finding 上会标注 confidence 是 estimate 还是 exact。
用法有两种:作为库集成进自己的代码或测试,或者作为 CLI 指向 prompt 文件并接入 CI(持续集成,让检查自动跑在每次提交上)。项目文档里有一个支持工单分类的 prompt 例子:里面有两个 few-shot(给模型几个示例再让它回答)示例、一个 ticket id、一个输出 schema。analyze() 跑完发现三个问题:UUID 浪费 15 token;缩进 JSON 浪费 7 token;一段 12 token 的指令重复了 3 次,浪费 24 token。整个 prompt 150 token,46 个是浪费的,每次调用成本 $0.000115,一千次 $0.115——一旦有真实流量,这就是实打实的钱。
最巧妙的设计是 dyn() 动态占位符。真实场景里 prompt 会插入 ticket body、用户历史等每次请求都变的内容。如果不标记,分析器会把动态内容当成静态文本,误判成本。用 dyn() 包起来后,analyze() 能区分静态成本和动态预算,离线或 CI 里传一个代表性值就能估算。
自定义规则也很简单:defineRule 暴露了和内置规则一样的接口,读 AnalysisContext(包含分词后的文本、JSON 区域、槽位等),返回 Finding[]。比如你可以写一条 no-all-caps 规则,检查全大写喊话浪费 token。
CLI 部分考虑得很工程化。tokensift init 会生成配置文件和三段参考片段(GitHub Action、pre-commit、测试 matcher)。--format 支持 json、github(输出 GitHub Actions workflow command,直接显示在 PR diff 上)、markdown(PR 评论表格)、sarif(给 GitHub Code Scanning 用的静态分析结果格式)。--fix --write 能自动修复安全的部分(unicode-punct、whitespace-run、pretty-json)。还有 baseline 和 budget 机制:先记录当前 token 数,之后如果增长超过 10% 就报 baseline-regression;budget init 设置硬性上限,check 作为 CI 的确定性闸门,exit 0 或 2,没有中间状态。
成本计算是另一个亮点。每条 finding 都带真实美元成本,来自 LiteLLM 定价表的快照。你可以在配置里设置 volume(比如每天 25000 请求),然后每条 finding 还会给出 atVolume,即放任不管的月度成本。Claude 模型支持校准:内置估计编码器对 claude-opus-4-5、claude-sonnet-4-5、claude-haiku-4-5 的平均绝对误差约 7.6%,你也可以用自己的 Anthropic key 和真实 prompt 跑 calibrate 命令,得到更准的本地校准文件。
这个工具不评判 prompt 质量,只告诉你“这个写法比等价结构更贵”。它也不做 LLM 重写、不代理请求、没有遥测,唯一网络调用是主动的定价刷新和校准。目前不支持 Gemini,gpt-oss 模型也还没实现,Claude 是估计值。但作为确定性、离线的静态分析工具,它非常适合接进 CI 和测试套件,防止 prompt 库在无人注意时悄悄变贵。任何维护大量 prompt 的团队,都可以用同样的思路:把 token 成本当成一种可回归的指标,像对待性能基准一样对待它。
内容与图片版权归原作者所有 · 原文: https://github.com/ritenv/tokensift