结论先说： “降智”不是一个可以通过单道题直接确认的技术状态。更可靠的做法是固定模型、参数和题集，在不同时段重复采样，并把协议字段、Token、动态能力题、流式输出、工具调用和真实业务结果放在一起比较。
最短判断路径是：先保存当前正常结果作为基线，再在相同模型 ID、参数和题集下复测。多项关键能力持续变差，并且排除了限流、上下文截断、客户端配置和网络波动时，可以升级为“疑似能力降级”。如果响应 model、服务商公告或路由元数据出现直接变化，即使质量暂时稳定，也值得单独排查路由变化；但网关可能改写字段，因此这些信号仍不能证明底层模型身份。
打开大模型 API 中转站检测工具，可以先生成一份分项报告，再按本文方法补充业务题集。
模型降智检测怎么做？
先固定模型 ID、提示词、参数和业务题集，保存一次正常结果作为基线；之后在相同条件下比较模型声明、Token、动态题、SSE、工具调用和任务完成情况。只有关键能力在多轮、跨时段持续变差，并且已经排除限流、上下文截断、网络和客户端差异，才适合记录为“疑似能力降级”。单次低分、回答风格变化或模型自述不能单独证明降智。
这类模型质量测试适合回答“当前接口是否按声明工作”，不适合单凭一次结果证明底层模型身份。若你需要比较多个入口，请使用相同模型、参数和题集，并保存每次报告的请求时间与脱敏请求 ID。
先定义什么叫“降智”
用户感受到的“变笨了”，可能来自多个环节：模型路由发生变化、网关追加系统提示、上下文被截断、工具调用不兼容、请求参数被过滤、高峰期限流，或者模型本身的随机输出波动。黑盒检测只能发现结果与声明不一致，不能仅凭现象确定内部原因。
因此建议把问题拆成三层：
| 层级 | 需要回答的问题 | 主要证据 |
|---|---|---|
| 协议层 | 接口有没有按声明返回标准结构 | 状态码、model、usage、流式事件 |
| 能力层 | 关键任务是否稳定完成 | 动态题、工具调用、结构化输出、业务题集 |
| 时间层 | 同一配置是否发生持续漂移 | 多时段报告、延迟、错误率、Token 与结果变化 |
可重复的检测步骤
1. 固定请求条件
记录 Base URL、模型 ID、temperature、最大输出长度、系统提示和测试时间。比较两个中转站时，除了 API Key 和地址，其余条件应保持一致。否则结果差异无法归因。
2. 先检查结构化信号
优先检查认证、HTTP 状态、响应 model、请求 ID、usage 和 Token 算术。结构化字段异常不等于模型一定被替换，但能较快暴露网关兼容、计费透明度或路由声明问题。
需要特别注意：/models 不开放或返回 401、403、429，可能只是权限与限流策略，不能单独当成造假证据。
3. 再验证关键能力
至少覆盖以下三类：
- 服务端随机生成的动态题，避免供应商针对固定题预设答案。
- SSE 流式输出，检查事件格式、增量内容和结束标记。
- 工具调用，检查工具名、JSON 参数和随机 nonce 是否原样返回。
如果业务依赖代码、长文本、检索或结构化 JSON，还应加入自己的脱敏样本。通用动态题只能检查部分能力，不能代替生产任务。
4. 在不同时间复测
建议低峰和高峰各运行一次，并在次日复测。一次失败可能来自网络、限流或上游波动；多项关键能力持续下降，且同一条件下能够重复，才值得升级为高风险信号。
哪些现象值得重点排查
先按故障现象分流，不把所有失败叫作降智
| 现象 | 优先核对 | 后续处理 |
|---|---|---|
| 请求返回 401 | 临时 Key、账号权限与认证头 | 密钥与认证排查 |
| 请求返回 429 | 余额、请求或 Token 限额、并发 | 额度与限流排查 |
| 普通回答正常，SSE 中途断开 | 流式事件、超时与代理缓冲 | 502 与断流排查 |
| 请求模型与响应 model 不同 | 服务商别名映射与路由说明 | 模型字段的证明边界 |
| 无 HTTP 错误，但业务任务持续变差 | 相同上下文、参数、题集与多轮基线 | 按同一记录模板复测 |
不要通过无限重试来提高检测通过率。认证问题应先修配置，限流问题应降低并发并按服务商规则退避；重复请求可能增加费用，也会污染可比性。
- 请求模型与响应
model长期不一致，且服务商无法解释别名映射。 usage持续缺失或 Token 算术明显不一致。- 原本可用的工具调用、流式输出或结构化结果持续失败。
- 同一业务题集的约束遵循率明显下降，而请求参数没有变化。
- 高峰期与低峰期的模型声明、能力结果或输出结构出现系统性差异。
这些信号说明“需要排查”，并不等于已经证明套壳或降智。网关升级、模型版本变更和客户端差异也可能产生类似现象。
不要只看总分
检测工具中的综合分衡量协议与关键能力的兼容程度，不是模型智力分，也不是厂商认证分。应先看失败项是否影响你的业务，再看多轮结果是否一致。
例如，工具调用失败对普通文本摘要影响有限，但对 Agent 任务可能是阻断问题；知识 cutoff 自述与输出风格属于弱信号，只适合长期对照，不应单独判定真假。
建议保存的对比记录
time, base_url, requested_model, response_model,
status, latency_ms, input_tokens, output_tokens,
dynamic_probe, sse, tool_call, business_suite, notes记录时不要保存完整 API Key、用户隐私或未脱敏提示词。出现异常后，使用同一题集复测并向服务商提供请求时间和脱敏请求 ID，比只说“模型变笨了”更容易定位。
下一步
先运行一次标准模型检测，再阅读检测报告判读方法。如果主要异常是请求模型与响应模型不一致，继续查看套壳与路由替换风险排查。