低价模型接口为何多算输入词元

便宜的 LLM API，单价低，输入账单却未必低。UplinkSwitch 用同一段约 90 tokens 的提示词测试不同路由，有的返回约 4,469 个输入 tokens，两条甚至报出 14,111。作者怀疑，中间服务商可能给请求加了用户看不见的系统提示词。

这组测试值得程序员关注，因为它提供了一种成本很低的排查办法。但要分清：输入计数异常是观测结果，隐藏提示词是解释，实际如何计费还需要核对账单。

同一段提示词，为什么能差出上百倍？

UplinkSwitch 每天向所列模型的各条路由发送固定提示词，再读取响应里的 usage.prompt_tokens。这里的路由，可以理解为访问同一模型的不同转发渠道。

2026-10-12 的检查覆盖 4 个服务商、107 条路由，每条路由采样一次。原文用 Host A 到 Host D 匿名标记服务商，结果如下：

服务商	路由数	同一段约 90 tokens 提示词的输入计数
Host A	66	GPT 约 4,469；Gemini 为 352，其中一条为 2,213
Host B	32	GPT 为 4,280 至 4,469；Claude 为 380、540；Grok 为 289；一条 Grok 4.7 为 1,325；两条 GLM 均为 14,111
Host C	8	一条 GPT 为 8,938
Host D	1	唯一路由为 1,171

作为参照，作者认为计数正常的路由通常返回 76 至 127，差别来自 tokenizer，即模型把文本切成 token 的规则。同样的模型，在其他路由上也有返回 89 的情况。

这些数字不是各家全部路由的完整明细，不能据此计算异常比例。另外，两条报出 14,111 的 GLM 路由提供的是第三方修改版本，并非模型开发者自己的权重，比较时必须带上这个前提。

作者给出的解释是：服务商可能在请求前面拼接了一段固定 system prompt。它参与输入计数，如果服务商按这个计数收费，用户就会反复为它付钱。

例如，业务请求只有 300 tokens，却额外带上 4,400 tokens 的前缀，那么前缀约占输入账单的 93%。这还可能改变模型接收到的指令环境：你的 system prompt 前面，已经存在另一组指令。

便宜的 token 单价，不能单独代表一次请求的真实成本。

不过，原文也承认，计数异常可能有其他原因。仅凭返回数字，尚不能确认额外内容是什么、由谁加入，更不能确认指令具体如何排列。

用一条 curl，先检查自己的 API

作者建议发送极短提示词，把 max_tokens 设为 1，再读取输入计数。这样可以压低测试的输出成本，把注意力集中到输入侧：

curl https://YOUR_PROVIDER/v1/chat/completions \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "MODEL_ID", "max_tokens": 1,
       "messages": [{"role": "user", "content": "Reply with one word."}]}' \
  | jq .usage.prompt_tokens

要看的是最后一行的 .usage.prompt_tokens。max_tokens: 1 限制的是输出，不会把输入计数限制为 1。

同一请求还应发送到模型开发者的官方端点，建立基线。聊天接口通常有消息模板开销，不能简单要求返回值等于自己估算的文本 token 数；但如果官方端点只有几十，转发渠道却有几千，就有了继续排查的理由。

作者建议每天执行一次并保留记录。计数突然变化，可以作为路由发生变化的线索。

UplinkSwitch 也介绍了自己的处理方式：声称输入计费不超过请求可能包含的 token 数；从文中所说的「今天」起，当请求比路由自身附带的提示词还短时，优先发送到计数更正常的路由。这个「今天」没有单独明确日期。

它还在 /proof 发布每日检查结果，通过 GET https://api.uplinkswitch.com/v1/proof 提供探针文本和判定，方便重复检查。原文没有充分展开计费上限的具体算法。

我的判断

我赞同把输入计数作为 API 接入检查的一部分。它便宜、容易复现，也能帮助团队识别短请求被额外开销吞掉的问题。

但「计数异常」到「隐藏提示词导致多收费」，中间仍然缺少证据。原文没有公开服务商名称，也没有提供完整请求链路、实际账单和足以排除其他原因的对照材料。固定前缀是合理猜测，还不能当成定论。

它也不是模型验真工具。路由可以任意填写 usage；同系列小模型替代、量化权重，都可能返回看起来正常的计数。每天一次采样，还会漏掉两次检查之间的变化。

正常计数只能说明这次响应没有暴露计数异常，不能证明模型身份。

相比只按价格选渠道，这种测试多提供了一个可量化维度；相比完整的质量评测和账单核验，它又只能覆盖很窄的一面。UplinkSwitch 同时在介绍自己的产品方案，其保护措施属于厂商自述，原文没有给出独立对照数据。

能拿来做什么

• 为 Node 服务接入第三方 LLM API 时，先用固定短提示词测试，并与同模型官方端点比较，保存日期、模型名、路由和 usage.prompt_tokens。
• 对分类、短文本处理等输入较短的任务，同时核算每次请求的实际费用，检查低单价是否被固定输入开销抵消。
• 把固定探针放进每日检查，计数出现明显变化时，再结合账单和输出质量定位原因。
• 为日常 AI 编程选择模型渠道时，把计数检查与任务效果评测一起做，不要凭一次正常的 usage 返回就认定模型可靠。