NNNNzs

Gemini 3.7 Flash 模型调用失败排查记录

2026年09月04日0 次阅读0 人喜欢
Geminicli-proxy-apiNew-API踩坑记录API网关
所属合集
小破站建设

起因

今天 Hermes 调用 Gemini 3.7 Flash 突然挂了，之前用得好好的，莫名其妙就报错。记录一下整个排查过程。

我的 AI 网关架构是这样的：Hermes → New-API（ai-gateway.nnnnzs.cn）→ cli-proxy-api（CPA）→ Google API。CPA 跑在 VPS 上，负责把 Antigravity 的 OAuth 订阅转成 OpenAI 兼容接口。

Hermes 配置的 provider 是 custom:new-api-codex，模型写的是 gemini-3.7-flash-high。之前一直正常，今天突然不行了。

排查流程图

第一反应：查 Hermes 配置

先看了眼 Hermes 的 config，发现一个可疑的地方：

yaml 复制代码 
reasoning_effort: medium

reasoning_effort: medium 和模型名后缀 -high 冲突了。心想这可能是问题？但改了之后还是一样报错。不是这个原因。

直接 curl 测试

绕过 Hermes，直接 curl 网关：

bash 复制代码 
curl -X POST https://ai-gateway.nnnnzs.cn/v1/chat/completions \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{"model": "gemini-3.7-flash-high", "messages": [{"role": "user", "content": "hello"}]}'

返回：

json 复制代码 
{"error": {"message": "unknown provider for model gemini-3.7-flash", "code": 400}}

注意看，请求发的是 gemini-3.7-flash-high，但错误信息里是 gemini-3.7-flash。后缀被吃了。

检查 New-API 渠道

登录 New-API 后台看了下，cpa-gemini 渠道（ID 21）的模型列表里明确有 gemini-3.7-flash-high。

然后试了 /v1/models 接口，返回的列表里 gemini-3.7-flash-high 好好地在那儿。但这个接口只能说明模型在白名单里，不代表能用。

之前就踩过这个坑，/v1/models 只是 New-API 的渠道配置展示，不代表下游真的能处理这个模型。

上 VPS 看 CPA

SSH 到 VPS，一开始用了 root@192.168.80.100，连不上。对了，应该用 nnnnzs@vpc.nnnnzs.cn。

进去之后先看 CPA 容器状态，跑着呢，状态 healthy。再看认证文件，有两个：

  • gemini-n709934831@gmail.com-gen-lang-client-0528170259.json（gemini 类型）
  • antigravity-n709934831@gmail.com.json（antigravity 类型）

都在，没问题。

看 CPA 日志找到关键线索

翻 CPA 日志，看到请求到达 CPA 了，但 request body 里的 model 是 gemini-3.7-flash——-high 后缀没了！

这就奇怪了，New-API 收到的是 gemini-3.7-flash-high，传到 CPA 怎么就变成 gemini-3.7-flash 了？

查 CPA 的模型注册表

去 GitHub 看了 CPA 用的模型注册表：

bash 复制代码 
curl https://raw.githubusercontent.com/router-for-me/models/refs/heads/main/models.json

里面有两个 provider 的模型映射：

json 复制代码 
{
  "gemini": ["gemini-3.7-flash", ...],
  "antigravity": ["gemini-3.7-flash-high", ...]
}

看到了吧。gemini-3.7-flash-high 只在 antigravity provider 下注册了，gemini provider 下的是 gemini-3.7-flash（不带后缀）。

根因

CPA 有个逻辑：收到请求时会把模型名的 -high/-medium/-low 后缀去掉，然后去匹配 provider。所以 gemini-3.7-flash-high 变成了 gemini-3.7-flash，匹配到了 gemini provider（用的是 CLI OAuth 的 gen-lang-client 项目）。但这个项目根本没有 gemini-3.7-flash 的访问权限，于是 400 了。

那 antigravity provider 呢？它注册的是 gemini-3.7-flash-high，但 CPA 的后缀剥离逻辑让它永远匹配不到 antigravity。

为什么之前能用

翻了下 CPA 的更新日志，v7.2.139 把 Gemini 3.7 Flash 加进了模型注册表。在那之前，gemini-3.7-flash-high 不在任何 provider 的注册表里，CPA 可能走了 fallback 路由到 antigravity。更新之后，模型被错误地注册到了 gemini provider 下。

另外 Google 这边也改了命名规则，3.7 Flash 的 -high/-medium/-low 后缀变成了独立的模型 ID，不是随便加的修饰词。

修复

在 CPA 配置里加了 oauth-model-alias，强制把去掉后缀的模型名指向 antigravity：

yaml 复制代码 
oauth-model-alias:
  antigravity:
    - name: gemini-3.7-flash-high
      alias: gemini-3.7-flash
    - name: gemini-3.6-flash-high
      alias: gemini-3.6-flash

重启容器，再测，HTTP 200，两个模型都正常了。

复盘

这次排查走了不少弯路。一开始盯着 Hermes 配置的 reasoning_effort 冲突看，改了没用。然后看 /v1/models 接口以为模型没问题（其实只是白名单展示）。真正的问题藏在 CPA 的后缀剥离逻辑和模型注册表的错位里。

教训就是：/v1/models 列出模型 ≠ 模型能用。要确认能不能用，得直接 curl 发请求看返回。还有，CPA 更新版本后最好检查下模型注册表有没有变化，尤其是命名规则改了的时候。

加载评论中...