Veridrop

supxh.xin Gemini 中转站检测报告

70/100 · 基本通过 · 模型 gemini-3.5-flash · 模式 standard · 中转站 https://api.supxh.xin · 品牌:supxh.xin · 实际 endpoint:api.supxh.xin

下载 JPG
协议级验证: 本检测通过 OpenAI 兼容协议 (POST /chat/completions) 探测 Gemini 中转站,验证响应字段、tool 调用、结构化输出、流式一致性和 usage 字段是否符合 OpenAI 规范。它不提供加密级模型真伪证明。
70%
基本通过

由 https://veridrop.org 生成

  • 基础请求 未通过
  • 模型响应形状 通过
  • 函数调用 通过
  • 结构化输出 通过
  • 协议规范性 通过
  • 流式一致性 通过
  • Token 用量 异常

划重点:这份报告在说什么

返回的用量数字不太可信

这家中转站报的用量(花了多少 token)不完整,或者前后对不上 —— 别直接拿它报的数字来算钱。

首 TOKEN
1,553ms
总耗时
13,034ms
吞吐 (T/S)
54.2
输入 TOKENS
2,055
输出 TOKENS
707
Gemini 检测项各自检查什么?
基础请求
发送最小 generateContent 请求,确认接口可用且能提取 Gemini 文本响应。
模型响应形状
检查 modelVersion、responseId、finishReason、candidate 和 safety 字段是否完整。
函数调用
强制 Gemini 返回 functionCall,检查函数名和 args 是否是结构化对象。
结构化输出
使用 responseMimeType=application/json 和 responseSchema,检查返回内容能否按 schema 解析。
协议规范性
被动检查 candidates、content.parts、safetyRatings、usageMetadata 等 Gemini 原生字段。
流式一致性
比较同一 prompt 的 generateContent 与 streamGenerateContent 文本、结束原因和用量字段是否一致。
Token 用量
检查 usageMetadata 是否存在、Token 统计是否自洽,以及长短文本带来的 Token 增量是否合理。
这份报告帮你避坑了吗?

如果 Veridrop 的字段级证据对你有用,欢迎顺手给 GitHub 点个 Star,支持公开、可复核的中转站测评继续维护。

GitHub 加星支持 →