HopBase
先说答案:验证一个 API 渠道有没有偷换模型、有没有降智,靠三类可复现的检查——成本结构类(prompt cache 的命中行为伪造不了)、行为边界类(模型族的硬边界在伪装时会露馅)、质量盲测类(固定任务集、足够样本量的对照)。任何供应商如果不欢迎你跑这些检查,这本身就是答案。
企业选 AI 中转/聚合渠道最大的焦虑是三件事:模型是不是真的、有没有被降智、数据去了哪。市面上的回应几乎全是口头承诺——「不路由不降智不偷换」。承诺不可验证,方法才可验证。我们做上游供应链审计两年,把内部用的检测思路整理成这篇公开方法,你可以拿它验证任何渠道,包括我们。
第 0 步:忘掉「你是什么模型」
最常见的验证方式是问模型「你是谁」,这毫无意义:一条系统提示就能让任何模型自称任何名字。反过来,官方模型也常常报不准自己的版本号。身份要用行为验证,不能用自我声明验证。
检查一:prompt cache 的成本结构(最难伪造)
Claude、GPT 系的 prompt cache 有官方定义的计费结构:缓存写入有溢价、缓存读取是折扣价,且 usage 字段里 cache_read_input_tokens 可见。这构成一个天然的测谎仪:
- 用同一个长系统提示连续请求,第二次起应出现稳定的 cache 命中(读 token 占比高、首字更快);
- 拼池、随机路由的渠道,命中率会显著低甚至为 0——因为你的请求落到了不同账号/机器上;
- 命中率背后是真金白银的成本差,长期伪造等于渠道自己赔钱,经济上不成立。
这是我们内部审计上游时权重最高的指标:缓存行为反映的是通道的真实拓扑,嘴上说不了谎。
检查二:模型族的硬边界
每个模型族有改不掉的行为边界,伪装者会在边界处露馅:上下文窗口的真实上限(塞接近上限的输入,看截断行为)、tokenizer 差异(同一段文本的 token 计数在不同模型族有系统性差异,对照 usage 数字)、参数支持面(不支持的参数是报错还是静默忽略,行为应与官方一致)、停止序列与流式分块的细节习惯。单项不构成证据,多项组合的指纹很难全部伪造。
检查三:注入痕迹
部分渠道会在你的系统提示前后注入自己的指令(改身份、加广告、加约束)。检测思路是行为对照:同一组请求分别打到官方直连与被测渠道,比较模型对系统提示的服从细节——被注入的通道在「复述指令」「角色扮演边界」类任务上会出现系统性偏移。我们审计中见过从单行伪装到 4KB 大段注入的各种形态,它们在对照测试下都会显形。
检查四:降智盲测(样本量是关键)
「感觉变笨了」不是证据——同一模型同一提示,输出方差本来就大。可信的做法:固定 20-50 个有标准答案的任务(代码补全、多步推理、指令遵循),官方与渠道各跑一遍,比通过率;温度设 0 降低方差;隔周复测,防止「高峰期换便宜模型」的时段性把戏。通过率差距持续超过噪声区间,才能下结论。
检查五:工程质量面
模型是真的,通道也可能是坏的:看首字延迟的分布而不是均值(P95 抖动大=链路不稳)、长输出的断流率(流式中途静默截断是最恶劣的故障形态)、上游错误码是否透传(把 429/529 吞掉改成超时的渠道,会毁掉你的重试逻辑)。
为什么我们敢公开这套方法
因为 HopBase 自己就是这么选上游的——每个通道接入前都过这套审计,不合格的直接否决。也因为我们的定价页把每条通道的属性写得明明白白:Claude Max、AWS Bedrock、Kiro,各是什么渠道、什么倍率,全部公开;AWS Bedrock 这类平台直连通道,连「个人账号」都不存在。透明的通道属性 + 可复现的验证方法,比一百句「绝不偷换」有说服力。欢迎拿这篇文章里的每一项检查来测我们。