Veridrop

Gemini API 中转站检测

Veridrop 通过 OpenAI 兼容协议(POST /chat/completions)探测 Gemini 中转站, 7 项检测覆盖协议规范、function calling、structured output、流式一致性和 usage 字段。 适配 Gemini 3 thinking-by-default 模型的特殊处理。免费、API key 不留存、代码开源。

协议级验证: 本检测验证 Gemini 中转站的 OpenAI 兼容协议实现是否完整,不提供加密级模型真伪证明。 Google 官方 OpenAI 兼容端点是 https://generativelanguage.googleapis.com/v1beta/openai; 第三方中转站通常在 /v1 暴露同样的协议。

填到 /chat/completions 的上一级。Google 官方填 /v1beta/openai;第三方中转站通常填 /v1。

仅用于本次检测,不写入报告、不持久化。会以 Authorization: Bearer 头发送。

OpenAI 兼容协议

统一通过 POST /chat/completions 探测,覆盖 Google 官方 /v1beta/openai 和绝大多数第三方中转站的 /v1 端点。

关键能力

探测 tool 调用、JSON schema strict 模式、流式与非流式响应一致性,识别能力缺失或参数没有透传的中转层。

用量字段

检查 usage.prompt_tokens / completion_tokens / total_tokens 自洽性以及流式 include_usage 是否被中转站如实透传。

常见问题(精选)

为什么 Gemini API 中转站经常 model_not_found?

三种可能:① 中转站只代理部分 Gemini 模型(很多中转站只有 3.x preview 系列,没有 2.5); ② 模型名拼写差异(gemini-2.5-flash vs models/gemini-2.5-flash); ③ 模型已下架。Veridrop 提交前会做 preflight,500ms 内识别死模型并给出可用列表替代。

Gemini 3.x preview 检测时 max_completion_tokens 应该填多少?

至少 64,推荐 128+。Gemini 3 默认开 thinking,会消耗 30-60 reasoning_tokens 才输出文本。 如果 max 太小(< 32),thinking 占满后没空间出文本,响应就是空字符串 + finish_reason=length。

为什么不支持 Gemini 原生 /v1beta/models/X:generateContent 路径?

99% 的第三方 Gemini 中转站只暴露 OpenAI 兼容协议,Google 官方也提供 OpenAI 兼容端点 /v1beta/openai。维护两套独立的检测逻辑成本高且容易引入翻译层导致结果失真, 所以集中在 OpenAI 兼容路径上做透。

Google 官方 Gemini API 也能用 Veridrop 测吗?

可以。base_url 填 https://generativelanguage.googleapis.com/v1beta/openai, api_key 用 Google AI Studio 申请的 AIza... key。Google 官方端点应该全 7 项 100 分, 可作为基线对比第三方中转站。

更多 Gemini 中转站问题 → /faq#gemini · 全部 常见问题