如何识别大模型API中转站的Token注水

很多团队发现大模型 API 成本异常时，第一反应是把模型的回答复制出来数字数，再换算成 token 对账。这个动作几乎注定徒劳——原因很简单：你能读到的文本，只是被计费内容的一个子集。真正要对账的对象是服务端的计量链路，而不是你屏幕上的那段文字。

一、先纠正一个直觉：注水不在你看到的文字里

一个形象的类比：去餐厅吃饭，账单上除了你点的菜，还可能包含餐位费、服务费和后厨损耗。只盯着端上来的盘子，永远对不平账。中转站（API 转售、聚合网关类服务）如果想虚报用量，最不可能动手脚的恰恰是可见回答——那是用户最容易直接验证的部分；真正的操作空间，全部集中在你看不见、也难以复现的计量环节里。所以核验思路必须从“看文本”切换到“看链路”。

二、拆开账本：一次调用到底计量了哪些内容

要把账对清，先要理解账本的结构。按业界通行的计量口径，一次对话式调用通常被拆成以下几类：

1. 输入 token：包括系统提示词、多轮对话的历史上下文、当前这轮的问题，以及 RAG 场景注入的检索片段、启用工具调用时下发的函数与工具定义。这部分随会话变长而快速膨胀，往往是账单的大头。
2. 输出 token：既包括返回给你的可见回答，也包括部分推理模型在生成前输出的“思考过程”——后者通常不下发给调用方，但照常计费。
3. 缓存命中的输入：不少服务对前缀相同的输入提供缓存，命中部分单价显著低于普通输入，用于降低重复上下文的成本。
4. 多模态折算 token：请求携带图像、音频等内容时，会被按规则折算成等价 token 计入账单。
5. 工具调用往返：模型发起函数调用、拿到工具结果、再继续生成的整个往返过程，每一环都会产生计量。

理解这个结构后，一个关键推论自然浮现：长上下文场景下，可见回答在总账单中的占比可能被压得很低——输入侧动辄数千 token，回答可能只有几百。即使中转站把不可见部分虚报一倍，你从“回答字数”上也看不出任何异常。

三、五类常见注水手法

把计量结构摊开后，常见的操纵手法就变得清晰，它们全部瞄准不可见环节：

• 静默重发长上下文：转发请求时“顺手”把历史上下文重复拼接，或注入一段用户不知情的额外提示，输入 token 直接翻倍；
• 缓存命中记全价：上游明明命中缓存（应计低价），中转却按全价输入上报，差价被吃掉；
• 重试计入本次：网络抖动、上游限流导致的自动重试，每次都完整计费并计入你的账单，且不告知；
• 隐藏推理重复计数：推理模型的思考 token 被多计一次，甚至给所有响应虚挂一层“推理开销”；
• usage 字段乘系数：最粗暴也最难防的一种——在返回的用量统计上直接乘一个大于 1 的系数。

这五种手法的共性是：全部发生在你看不见的环节，且全部无法通过肉眼阅读回答来发现。

四、第一道核验：基准探针（输入侧）

输入侧是你唯一能完全控制的变量——提示词是你写的，理论上可以精确算出它的 token 数。基准探针的设计要点：

1. 准备一段固定的短提示，内容精确到一字不改，作为探针；
2. 为请求设置明确的输出上限（如 16 个 token），排除输出侧干扰；
3. 连续发送若干次（如 10 次），记录每次返回的用量明细；
4. 在本地用目标模型对应的官方分词器（tokenizer）离线计算这段提示的 token 数，作为基准值；
5. 将账单中的输入 token 与基准值比对，同时观察多次请求之间数值的一致性。

示意性代码：

PROBE_PROMPT = "请只回复一个词：收到。"
def run_probe(client, n=10):
    records = []
    for _ in range(n):
        resp = client.chat(
            messages=[{"role": "user", "content": PROBE_PROMPT}],
            max_output_tokens=16,   # 锁死输出上限
            temperature=0,          # 降低随机性，便于比对
        )
        records.append({
            "request_id":        resp.id,
            "timestamp":         resp.created_at,
            "prompt_tokens":     resp.usage.prompt_tokens,
            "completion_tokens": resp.usage.completion_tokens,
            "total_tokens":      resp.usage.total_tokens,
        })
    return records
# 与本地基准值比对
expected = local_tokenizer_count(PROBE_PROMPT)
for r in records:
    dev = (r["prompt_tokens"] - expected) / expected
    print(r["request_id"], f"输入偏差 {dev:.1%}")

判读方式：固定输入下，每次请求的输入 token 数应当完全一致；与本地基准的偏差应当为零或某个可解释的常数（见第七节）。如果数值逐次跳动、或偏差明显大于常数，输入侧就有虚报嫌疑——而这恰恰是整条链路中最容易精确定位异常的一段。

五、第二道核验：输出侧强约束

输出侧没有“官方基准值”可算，但可以把可见输出压到极小，让异常无处遁形：使用“请只回复一个词”这类强约束任务，把可见回答控制在一两个 token。此时若账单上的输出 token 仍然显著偏大，多出来的部分只可能来自两类：隐藏的思考过程，或被计入本次的重试。

需要强调的是：推理模型的思考 token 计费，本身是合理的计量口径——上游确实消耗了这部分算力。问题不在“计了”，而在“是否事先说清”。合规的服务应当在文档中明示推理 token 的计量规则；把它悄悄藏进输出总数里，让用户误以为计费只覆盖可见回答，在信息透明度上就是不合格的。

六、第三道核验：字段对齐与明细留存

核验中最常见的错误是“拿总数对总数”。正确做法是对齐到字段级：

• 规范的响应会分别给出输入 token、输出 token、总 token，业界常见的兼容格式里通常对应 prompt_tokens、completion_tokens、total_tokens 三个字段；部分服务还会细分出缓存读取部分、推理部分的单项计量；
• 如果一个中转服务只返回一个合并后的数字，不提供请求 ID（request id），也不给任何明细拆分——这本身就应当扣减信任分。无法对齐的账，等于放弃了被审计的可能性。

比字段对齐更重要的是留存习惯：把每次调用返回的原始 usage 结构连同时间戳、模型名、请求 ID 一起落库（接入常规的日志服务或时序数据库均可），再按日聚合。这套数据是事后核验、争议申诉、成本归因的唯一可靠依据，远比事后翻聊天记录、凭记忆估数可靠。

七、区分合理偏差与真实注水，避免误伤

把所有偏差都当成注水同样不专业。以下几类差异是正常的，通常只带来几个百分点级别的出入：

• 分词器版本差异：服务端与本地使用的 tokenizer 版本不一致，切分结果略有不同；
• 平台自动注入：部分服务会在你的提示之前附加平台级系统提示，并计入输入；
• 多轮历史重发：对话式接口的机制决定了历史上下文会随每轮请求重新发送，会话越长越多；
• 失败自动重试：调用失败后的重试若最终成功，上游可能按实际消耗计费；
• 中英混排的 BPE 切分差异：中文与代码混排时，不同实现的处理方式会带来小比例出入。

判定注水的关键不是“有没有偏差”，而是偏差的结构。推荐一组对照实验：把同一个请求分别发给官方直连通道和中转通道，同时记录两边 usage，计算相对偏差，然后观察：

偏差形态	判断
稳定在某个小比例（如 3%～5%）	大概率是计量口径差异，可接受
随上下文长度线性放大	高度可疑——像是重复计入历史上下文
随时间越漂越大	高度可疑——像是系数被动态调整

一句话总结：口径差异是“常数”，注水往往呈现“结构性的放大”。

八、把核验沉淀为制度

技术核验之外，几条商业层面的常识值得写进流程：

1. 单价极低 + 口径模糊 = 实际成本未必低。报价远低于市场水平、同时不给字段明细、不给请求 ID、不说明计量口径的服务，低价只是“把水分藏在了你看不见的地方”，而且一旦发生争议，你没有任何可申诉的依据。
2. 把“可审计”写进选型要求。在意成本的团队，应当将“提供按请求 ID 可追溯的 usage 明细”作为硬性选型条件，写进供应商评估表甚至合同条款。
3. 定期抽样复核。上线前做一次全面探针，之后按周或按月抽样复核，并把 token 用量接入常规的监控告警体系，设定偏差阈值自动报警，而不是等账单爆炸才回头排查。
4. 对透明度要求高的场景，优先官方直连。如果业务对计量准确性要求很高，可直接选择官方直连通道或大型云厂商的标准服务（例如百度智能云），从源头减少中间环节带来的计量风险。

九、结语

识别 Token 注水的本质，是一场围绕“不可见计量环节”的审计，而不是对回答文本的阅读理解。方法可以收敛为一条完整流程：先拆账本，理解计量结构；再用基准探针锁死输入侧；用强约束任务压扁输出侧；用字段级明细替代总数对账；用对照实验观察偏差的结构；最后把可审计性写进采购要求。做到这几步，绝大多数注水手法都会在数据面前现形——而一个经得起这套核验的中转服务，也才值得长期合作。