同一个插件，86.1%还是8.5%省Token？测准是前提

「这个插件能省多少 Token？」 是一个很容易答错的问题。同一个插件、同一份 400 个用例的工作负载，在一个阈值下能省下 86.1% 的计费 Token，在另一个阈值下只剩 8.5%。两个数字都是真的，但脱离条件就都没有意义。

dsh-phocinae 是面向 DeepSeek^广告 Harness（dsh）Agent 的本地决策插件，提供 phocinae_ask 和 phocinae_gate 两个工具，背后是一个小模型，一次前向传播就能回答结构化决策问题。本次测量的工作负载是公开的 typed-decisions 行集：400 个用例、2000 个决策，本地模型为 Phocinae-Largha-150M-v1（CPU、fp32），对照的托管模型是 flash 档的 deepseek-flash（temperature 0）。本文要拆的是这些数字背后到底怎么测出来的。

为什么「省 Token」很难测

托管模型侧有 API 自己的 usage 计数器；本地决策本身不计费，但不等于零成本——它的工具定义会随每个请求一起发送，每次调用的参数和渲染结果都会进入 transcript，在下一个请求里被照常计费。所谓「省下」永远等于「没有发送」，你必须先说明自己到底在数什么。

更麻烦的是升单位不是「决策」。一旦触发升，托管模型收到的是一整个案例——一个状态加它的五个结构化问题。只要其中一个决策没把握，整个案例会被重新回答一遍。所以「留在本地的决策数」和「从不碰 API 的案例数」是两种不同的统计口径，会给出两个不同的百分比。

阈值本身则是产品决策。插件输出的是 escalate 信号，不是省钱保证。τ（低于该置信度即标记为不确定）由调用方选择，正是 86.1% 那一行和 8.5% 那一行之间的分歧所在。

置信度阈值（τ）与升级信号

插件输出的不是一个二元对的"答/不答"，而是一个校准过的置信度分数。τ 是一条分界线：分数低于 τ 的决策被标记为 escalate，交给托管模型重答；高于 τ 的留在本地。这个机制把"要不要花 Token"变成了一个可以由调用方调节的旋钮。问题的微妙之处在于，τ 并不是插件的内部参数，而是产品层面的取舍——调高 τ 等于"宁可多花钱也别答错"，调低 τ 等于"宁可冒点质量风险也要省"。文章里 86.1% 和 8.5% 的差别，本质上是同一个模型在不同风险偏好下给出的两个答案，而不是两次互相矛盾的测量。理解这一点，才能读懂后面所有数字为什么都带着 τ 的脚注。

Pre-execute 钩子与消息计费的区别

文中提到审批门"作为 pre-execute 钩子运行，不是消息，因此对会话 Token 的增量为零"。这背后是一个容易被忽略的计费边界：托管 API 通常只对进入消息序列（system、user、assistant、tool 等 role）的内容计费，而钩子是在工具真正执行之前由客户端本地触发的一段逻辑，它既不产生输出 Token，也不进入下一轮的上下文。所以 phocinae_gate 的 212 tokens 工具定义会被计入每请求固定开销，但它每次拦截命令的决策过程本身对账单零影响。混淆这两者，会把审批门的成本算高一截。

测量设计：三个计数器

每请求——固定部分。 插件加载期间，两个工具定义会出现在每个请求的工具列表里：phocinae_ask 473 tokens 加 phocinae_gate 212 tokens，即每请求 685 tokens。这是用供应商自己的 tokenizer 数出来的，不是估算。审批门是例外：它作为 pre-execute 钩子运行，不是消息，因此对会话 Token 的增量为零。

每决策——往返开销。 一次本地调用的参数 99 tokens、渲染结果 135 tokens，稳态下每决策 234 tokens；若这是会话中的第一个决策，还要额外带上固定的 685。

每案例——托管模型实际被调用的粒度。 400 个案例的托管侧 usage 合计为 1,222,211 tokens（输入 290,606、输出 931,605，约 76% 的账单花在模型自己写答案上），即每案例 3,055.5 tokens。本地侧则按构造零计费——决策是一次前向传播，不是生成。

为什么用供应商自己的 tokenizer 计数

文中反复强调 685、234、3,055.5 这些数字是"用供应商自己的 tokenizer 数出来的，不是估算"。这一点在跨模型对比时尤其关键：不同模型家族的分词规则差异很大，同一段英文在 GPT 系、Claude 系和 DeepSeek 系下可能相差 10% 到 30% 的 token 数。如果本地用一套估算器数插件开销、托管侧却读 API 返回的 usage，两边口径就对不上，"省幅"会凭空多出一截或凭空少一截。把两个计数器统一到托管模型的分词器上，才能保证"省下的 token"和"账单上的 token"是同一把尺子。

按决策计费 vs 按案例计费的差异来源

文章区分了"留在本地的决策数"和"从不碰 API 的案例数"两种口径，根源在于托管模型的调用粒度不是决策而是案例。一个案例包含一个状态加五个结构化问题，只要其中任何一个决策被升，整个案例就要重新送进托管模型回答一遍——这意味着即使 95% 的决策留在本地，如果它们分散在 95% 的案例里，实际上几乎所有案例都会被升。所以决策级省幅（比如 92%）和案例级省幅（比如 86%）之间并非简单换算，而是取决于升的分布是聚集还是发散。τ=0.6 之所以效果差，正是因为置信度分布集中在中位数 0.6294 附近，升的决策散落在大量案例中，触发了"一个拖全案"的连锁效应。

结果：每个数字都带着条件

纯本地路径。 所有决策都在本地完成、零升。相比全部交给托管模型，1 个决策省 69.9%，10 个决策省 90.1%，1000 个决策省 92.3%。它在约 92% 处饱和而不是 100%，缺口正是那个固定计数器：工具定义和往返开销始终留在调用方上下文里。

τ=0.4 的混合模式，是本文在这个工作负载上更愿意推荐的一行。400 个案例中 27 个被升（6.8%），计费 Token 从 1,222,211 降到 82,499。若把插件自身开销（每请求 685 + 每个留本地决策 234）算进去，省幅为 86.1%。准确率 0.7305，托管单跑 0.7085、本地单跑 0.7320——在这个负载上，升几乎是一次平手。

τ=0.6 的混合模式则是「诚实的一行」，也是插件默认出厂值。400 个案例中有 363 个被升（90.8%），仅看模型侧省 9.2%，把插件开销算进来只有 8.5%。准确率也降到 0.7115，低于纯本地的 0.7320——因为被升的案例整案重答，而托管模型在该负载的选择型问题上更弱（0.6793 对本地模型的 0.7529）。

为什么 0.6 会升这么多？置信度分布集中在中间，中位数决策落在 0.6294，而一个决策不确定就足以拖上整个案例。2000 个决策里有 851 个（42.6%）低于 0.6，按案例统计就是 90.8%。一个听起来保守的阈值，在这个分布上几乎等于整体退出。

按配对的公开单价（每百万输入 $0.28、每百万输出 $1.10）计算，400 案例单跑托管为 $1.1061，τ=0.4 为 $0.0747，纯本地则没有计费 Token。

没有测到的部分

400 个机器可读案例是 bench，不是会话 trace。真实会话有更长的历史、更多工具和更多轮次；下一步该做的是同一份 30+ 任务清单在插件开/关下聚合 API usage，同时统计升、误拦和任务成功率。在那之前，上面的数字只能当校准过的 bench，不是承诺。

延迟数据全部来自 CPU、fp32、单机：本地决策 HTTP 往返 42.6 ms，审批门筛命令均值约 21 ms，白名单命令 0.02 ms。流传中的 GPU 数据（fp16、RTX 5090 上 p50 21.0 ms）是模型发布方的数字，不是本次测量，尚未复现。τ=0.4 也不是普适常数，只是这份负载置信度分布的产物。

在自己的流量上复现

仓库 bench/ 下留有全部脚本与原始结果，一条命令即可重跑：先 python -m phocinae.main 起本地模型，再 node bench/token-savings.mjs 指向你自己的 rows 和模型对，然后用 context-cost.mjs 数插件自身开销、economics.mjs 算分期与混合行、gate-by-mode.mjs 单独测审批门。把 τ 扫过 {0.3, 0.4, 0.5, 0.6} 并把准确率和省幅并排读：在这个负载上，把 τ 往上推，省得更少、准确率还更差。

一个省钱声明是否可信，就看你能不能重跑它。这里给出的是：τ=0.4、400 案例、含插件开销 86.1%——以及因为「不报告的旋钮等于不理解的旋钮」而一并给出的 τ=0.6 下的 8.5%。把 bench 指向你自己的日志，然后相信你自己的那一行。