如何验证 API 中转是否偷换模型：可落地的技术校验方案

团队统一采购第三方 API 中转时，最容易被忽略的一点是：你买到的不是一个模型，而是一个承诺。请求发出去，中间隔着网关、路由和一堆你看不见的上游账号，返回的 model 字段写什么，完全由对方决定。价格比官方低一截的时候，这个承诺的可信度就成了核心风险。

真正要解决的问题不是「能不能测出一次」，而是「能不能持续确认」。单次盲测很容易被针对性绕过：前期给你真模型，等你把业务迁上来，高峰期再悄悄降级。下面把判断逻辑和可落地的校验手段拆开讲。

问题本质：中转层让模型身份变成不可验证的标签

一次请求的链路大致是：你的客户端 → 中转网关 → 上游（官方直连、云厂商转售、账号池或混合）。网关能做的不只是转发，它可以改写模型名、按并发或时段切换上游、对长请求做降级、把流式响应重新拼装。所以在这个链路上，模型身份不是技术事实，而是商业承诺加抽样验证。

这也意味着：不存在一次性「实锤」的银弹，只有把多个弱信号叠加成高置信度判断，再用合同和兜底机制把剩余风险兜住。

第一步：先看成本结构，再看技术

技术检测成本高、周期长，而成本结构异常是最便宜的预警信号。长期显著低于官方按量价格的报价，一定有别的来源支撑，常见有三类：

采购时可以直接问三个问题，并要求书面回答：上游是官方密钥、云厂商转售，还是账号池？断供时如何赔付？数据是否留存、是否用于训练？口头保证「纯官转」没有意义，能写进合同才有意义。凡是回避上游来源、只谈价格和并发的中转，先降一档信任等级。

第二步：建立官方参照基线

所有对比检测都依赖一个可信参照系。可行做法：

1. 用官方 API（不要用网页版或 App，它们自带系统提示词，行为不可比）跑一组固定请求。
2. 固定 system、temperature、max_tokens 和模型版本，请求体逐字节保持一致。
3. 每个用例采样多次（建议 5–10 次），记录完整响应而非只看第一条。
4. 用同一组请求打中转，逐条比对差异。

关键在采样次数。单条输出不同不能说明任何问题，模型本身有随机性；要看的是分布层面的偏移。

第三步：结构化能力指纹

单一 prompt 陷阱很容易被针对性规避，更稳的做法是设计一组覆盖不同能力的测试集，观察整体分布：

• 结构化输出遵循度：给一个带嵌套和枚举约束的 JSON Schema，统计合法率与字段顺序稳定性。
• 长上下文召回：在长文本的不同位置埋入标记，看模型能召回哪些位置。不同模型的注意力分布差异明显。
• 多约束冲突处理：同时给出互相冲突的指令，观察它优先服从哪一条。
• 拒答边界与措辞：用一组边界请求对比两边的拒答位置和措辞模板，这是区分不同厂商模型的有效维度之一，但仅用于内部供应商评估，不要拿去做别的用途。
• 语言与用词偏好：某些模型在中文创作类任务上有稳定的默认倾向（比如让引用名人名言时倾向于选某类人物）。这类特征可以用，但会随模型版本迭代漂移，必须定期重新校准，只能作为弱信号。

把这些维度做成打分表，对官方跑一遍得到基线分，再对中转跑一遍。若某几项系统性偏离，而不是随机波动，就值得追问。

第四步：核对响应字段与用量数据

这一层最容易被忽略，但成本很低：

• model 字段：必须与请求一致。这是最低要求，能被随意改写，但连这个都对不上就不用往下测了。
• usage token 数：用官方 tokenizer 对同一段文本单独计数，与中转返回的 usage 比对。持续、系统性偏大，说明底层 tokenizer 或模型可能不是同一个。
• stop_reason 与流式结构：分块方式、字段顺序、结束原因是否符合官方形态。
• 思考块与签名：部分官方渠道会返回带签名的思考内容，签名与请求上下文绑定、无法伪造。如果对方声称走官方链路却始终给不出可校验的签名，可以作为追问点；但要注意，中转完全可以整体透传，所以「有签名」是加分项，「没签名」不足以直接定罪。

第五步：看异常信号与时序变化

真模型和廉价模型的差异，往往在压力下才暴露：

• 延迟分布：首 token 延迟、吞吐的均值与方差，两边差异通常比内容差异更早出现。
• 错误与限流形态：官方 429 的错误结构和提示文案有自己的模板，被替换后会变形。
• 忙闲时差异：同一请求在高峰期和低谷期结果明显不同，说明后端可能在多个池子之间路由。
• 版本漂移：模型行为在某天突然整体改变，可能是上游换了模型或降级。

验证必须持续，不能只做一次

把上面的手段固化成一套流程，才有实际价值：

1. 维护一组 20–50 条固定用例，覆盖结构化输出、长上下文、拒答边界、语言偏好。
2. 每周或每月自动跑一次，与历史基线对比，输出偏离度。
3. 测试内容对供应商保密，避免被针对性适配。
4. 保存原始响应日志，作为后续追责依据。
5. 线上业务侧再加一层兜底：关键输出做规则校验与人工抽检，同时准备第二家供应商，可随时切换。

如果复测脚本需要长期不间断运行，注意采样环境的稳定性：本地机器休眠、网络抖动、出口 IP 频繁变化，都会让延迟和限流数据失真。一个可选做法是把复测脚本放到长期在线的远程环境里跑，例如整台 Mac mini 放在新加坡机房、按月租用、远程连接使用的独享远程 Mac，网络出口固定、可以一直在线，也能顺带长期运行 Claude Code 之类的工具。这只是环境层面的取舍，与模型真伪判定本身无关。

自建还是继续采购

有人会考虑自己搭中转。需要先算清楚代价：支付渠道、账号合规、运维值班、故障处理，缺一不可。通过账号池、共享账号、批量注册等方式压低成本的做法风险很高——随时失效、违反上游服务条款、请求内容可能被第三方看到，不适合承载生产流量，这里也不展开具体做法。

更稳妥的路径是：官方企业接入、云厂商托管的模型服务，或者愿意签约、能提供用量对账和 SLA 的代理商。价格不会最低，但责任边界清晰。

小结

• 没有单点「100% 实锤」的方法，可靠结论来自多个弱信号的叠加和持续抽样。
• 价格异常是成本最低的第一预警，其次是上游来源是否愿意书面说明。
• 官方 API 基线 + 结构化能力指纹 + usage 与响应字段核对，是性价比最高的一组组合拳。
• 单次检测必然被绕过，把复测做成周期性流程，并在合同里写明模型版本与替换通知义务。
• 关键业务永远准备备用通道，验证的最终目的是控制损失，不是追求绝对确定。

各家的模型版本、接口字段和计费规则变化较快，具体以官方最新文档为准；采购前建议自行复测一遍再签合同。