Model Verification

如何用模型指纹验证防止 AI 渠道掺水

2026年7月22日Cxj

如何用模型指纹验证防止 AI 渠道掺水：一次 `kimi-k3` 评测案例

如果你的团队正在采购大模型中转、AI 网关或聚合路由，不要只看“这个模型能不能回答问题”。

真正应该先问的是：

我请求的是这个模型，返回的到底是不是这个模型？

这就是模型指纹验证的价值。它不是 benchmark，也不是主观体验评分，而是用原始 request/response 证据确认：端点有没有把你选择的模型、协议、用量和响应元数据如实交付。

最近一次 TokenTest 评测中，我们请求的目标模型是 kimi-k3，但多个成功响应的顶层 model 字段返回了 kimi-k2.7-code。这个案例很适合说明：为什么渠道验真不能只依赖模型列表、UI 下拉框或供应商口头承诺。

TokenTest 模型指纹验证链路：请求 kimi-k3，运行时响应返回 kimi-k2.7-code

这张图就是这类问题的核心：应用请求、路由平台、运行时响应是三层不同证据。采购方不能只相信前两层的“声明”，必须把第三层的 raw response 也纳入验收。

核心规则

在正式接入任何 AI 渠道前，至少做一次黑盒模型指纹验证。

验证时不要只看答案文本，而要同时检查：

请求体里的 model
响应体里的 model
/v1/models 返回的模型列表
response id / request id
nonce 是否按本次请求返回
usage 字段是否可信
是否存在静默 fallback 或别名映射

如果 request.body.model 和 response.model 不一致，就应该进入复核，而不是直接认为“模型能回答就没问题”。

为什么模型列表不够

很多中转平台都会提供模型列表接口：

GET /v1/models

这个接口能证明“平台声称支持哪些模型”，但不能证明“运行时实际走了哪个模型”。

两类证据必须分开：

证据	能证明什么	不能证明什么
`/v1/models`	平台展示或声明支持某个模型	每次调用都实际走这个模型
`response.model`	本次响应自报的模型身份	这个身份是否与官方别名完全等价
nonce 回显	响应不是静态缓存或旧响应复用	模型一定没有被替换
usage 字段	计量是否看起来完整	账单后端一定真实无误
多 probe 一致性	异常是否重复出现	异常背后的商业原因

所以，模型列表只能作为一个入口证据。真正的模型身份验证，需要看每一次 completion 的原始响应。

这次 `kimi-k3` 案例发生了什么

这次评测的目标很简单：

Endpoint: 一个 OpenAI-compatible router
Model: kimi-k3
协议: /v1/chat/completions
目的: 验证这个路由是否按请求交付目标模型

TokenTest 先调用 /v1/models，模型列表中确实出现了 kimi-k3。这说明请求的模型名不是明显不存在。

但随后，多个 chat completion 响应返回了另一个模型 ID。

关键原始证据

下面是脱敏后的最小证据片段。它保留了判断指纹是否一致所必需的字段，但去掉了真实 endpoint、Authorization、request id、response id 和一次性 nonce。

如果用 curl 复核，形式大致如下。这里的域名、密钥和 nonce 都是示例值：

curl https://router.example.com/v1/chat/completions \
  -H "Authorization: Bearer sk-REDACTED" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {"role":"system","content":"You are being evaluated. Follow the user instruction exactly."},
      {"role":"user","content":"Return exactly this JSON: {\"probe\":\"ok\",\"answer\":42,\"nonce\":\"TT_SAMPLE_NONCE\"}"}
    ],
    "max_tokens": 80
  }'

对应的请求体核心字段如下：

{
  "method": "POST",
  "path": "/v1/chat/completions",
  "body": {
    "model": "kimi-k3",
    "messages": [
      {
        "role": "system",
        "content": "You are being evaluated. Follow the user instruction exactly."
      },
      {
        "role": "user",
        "content": "Return exactly this JSON: {\"probe\":\"ok\",\"answer\":42,\"nonce\":\"TT_SAMPLE_NONCE\"}"
      }
    ],
    "max_tokens": 80
  }
}

响应内容答对了这个简单任务，但响应顶层模型字段是：

{
  "id": "chatcmpl-REDACTED",
  "object": "chat.completion",
  "model": "kimi-k2.7-code",
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "{\"probe\":\"ok\",\"answer\":42,\"nonce\":\"TT_SAMPLE_NONCE\"}"
      },
      "finish_reason": "stop"
    }
  ]
}

TokenTest 因此记录：

requested=kimi-k3; returned=kimi-k2.7-code

这不是“模型不会做题”。它答对了。问题在于：请求的是 kimi-k3，响应自报的是 kimi-k2.7-code。

为什么这属于渠道掺水风险

所谓“渠道掺水”，不一定表现为答案质量明显下降。更常见的是这些灰区：

用较便宜或较旧的模型承接高价模型请求。
高峰期静默 fallback 到另一个模型。
把内部模型别名返回给客户，但没有公开等价关系。
/models 列表展示的是销售名，运行时返回的是另一个 serving name。
usage、模型 ID、错误格式等元数据经过二次包装，导致买方无法审计。

如果平台能清楚证明 kimi-k2.7-code 是 kimi-k3 的官方或等价内部别名，并且能在 Kimi 官方开放平台或 Moonshot AI 官网找到可复核依据，这个问题可以通过白名单解决。但在没有明确 alias mapping 前，TokenTest 默认把它视为 P0 指纹风险是合理的。

因为采购方买的不是“某个能回答的模型”，而是“指定模型的访问权”。

TokenTest 采购证据矩阵：模型列表、请求模型、响应模型、nonce、usage、request id

在 TokenTest 里应该怎么跑

可以在 TokenTest 首页按这个流程做一次渠道验真：

1. 先跑模型发现

点击自动发现模型，或者直接调用：

GET /v1/models

确认目标模型是否出现在列表中。

2. 跑 quick 或 truth 评测

输入：

Endpoint: https://your-router.example.com
Model: kimi-k3
Protocol: OpenAI /v1/chat/completions

重点看 D1 身份与协议完整性，而不是只看总分。

3. 展开原始证据

检查每个成功 probe：

request.body.model
response.model
response.id
finish_reason
usage
content_preview

如果多个 probe 都出现同样的模型字段不一致，就不是单次异常。

4. 向供应商索要解释

把 request id 和原始片段发给供应商，要求说明：

是否存在 alias
是否存在 fallback
这个 returned model 是否与 requested model 等价
是否能在文档或后台配置中证明

一个采购可用的检查表

检查项	通过标准	风险信号
模型列表	`/models` 包含目标模型	目标模型不存在或 owner 异常
指纹一致性	`response.model` 与请求模型一致或有明确 alias	返回另一个模型 ID
nonce 回显	每次返回本次 nonce	旧 nonce、缺失 nonce、静态响应
usage 完整性	input/output/total 可解释	output 为 0、total 不一致、字段混乱
截断行为	finish_reason 与 max_tokens 自洽	大量空输出或不可见答案
错误格式	返回协议正确的 4xx/5xx	暴露内部栈、渠道 ID 或敏感信息

这张表比单纯看 benchmark 分数更适合采购审核，因为它关注的是“渠道是否可信”。

TokenTest 为什么要把验真和生产可用性分开

这次评测也暴露了另一个问题：大量任务因为 length 或空可见输出没有返回完整答案。

这类问题应该被记录，但不能和模型指纹混为一谈。

TokenTest 现在把结果拆成两层：

验真判定：模型身份、协议、nonce、鉴权、header 和 usage 是否支持“这是目标模型”。
生产可用性：结构化输出、推理、长输出、工具、延迟和截断表现是否适合生产。

这样可以避免两个误判：

不会因为模型答对了几道题，就忽略指纹不一致。
也不会因为同一个空输出问题重复扣分，把生产兼容性问题误判成多个独立能力失败。

这对 AI 中间层尤其重要。买方需要知道的是：这个渠道到底是“模型身份不可信”，还是“模型身份可信但生产表现需要调参”。

常见错误

只看 /models，不看每次响应里的 model
只看答案对错，不看原始 response
把 router 的内部别名当作天然可信
允许静默 fallback，但没有在报告里标记
用一个总分判断真假，不区分验真和生产可用性
发现空输出后重复扣分，却没有识别同一根因
没有保留 request id，导致无法和供应商对账

最终结论

模型指纹验证的价值很简单：

防止你以为自己买到了指定模型，实际却在使用另一个渠道、别名或 fallback。

对于 AI 采购和中转运营来说，response.model 不是一个可有可无的字段。它是运行时模型身份的第一层证据。

这次 kimi-k3 案例说明了一个关键事实：一个端点可以在 /models 里列出目标模型，也可以正确回答简单问题，但仍然在 raw response 中暴露模型指纹不一致。

上线前，用 TokenTest 跑一次黑盒评测，把 request、response、nonce、usage 和 request id 留下来。这样供应商如果真的没有掺水，可以用证据自证；如果存在别名、降级或静默 fallback，你也能在生产事故发生前看见。

如何用模型指纹验证防止 AI 渠道掺水：一次 kimi-k3 评测案例