模型列表可访问，不代表推理接口可用
作者用模型目录与实际聊天请求双重探测，区分限流、余额耗尽及模型下线等失败原因。文章指出，仅检查 /v1/models 无法验证推理服务是否真正可用。
AI 深度解读
免费模型接口不出结果，未必是免费层没了，也可能是探测脚本把不同问题混在了一起。作者曾用模型列表接口判断服务健康，又靠模型名里的 :free 寻找免费额度，结果把能用的服务漏掉，把不能聊天的服务标绿。
这篇最值得程序员拿走的，是一套更准确的排查顺序：真正发一次聊天请求，再结合状态码、响应体和具体 Key 判断失败原因。它能帮助你检查 AI 接口监控是否真的测到了业务可用性。
模型列表能返回，不代表模型能回答
作者维护了一个探测脚本，遍历多个兼容 OpenAI 的端点，检查两件事：能否获取模型列表，以及能否立即完成聊天。但几个月里，作者只看了第一项。
在标记为 09.10.2026 的那次记录中，结果出现明显分化：
| 服务 | 模型列表与聊天结果 |
|---|---|
| Groq | openai/gpt-oss-20b、qwen/qwen3.8-27b 的列表和聊天检查均返回 200 |
| Google Gemini | 列出 62 个模型，聊天返回 429 |
| Mistral | 列出 46 个模型，聊天返回 429 |
| NVIDIA NIM | 列出 80 个模型，作者尝试的模型 ID 返回 410 Gone |
| SambaNova | 返回 402，响应体包含 balance_units: 0 |
这些结果如果只压成一个红绿灯，就很容易误导后续排查。
下面的命令只能查看模型目录接口的 HTTP 状态码：
curl -sS -o /dev/null -w '%{http_code}\n' \
-H "Authorization: Bearer $KEY" \
https://api.example.com/v1/models
注意 -o /dev/null：它会丢弃响应体，只留下状态码。用来快速检查接口有无响应很方便，用来解释失败原因就不够了。
作者把 /v1/models 理解为附带列表的身份检查：请求头被接受，Key 能关联到账户，账户可能拥有查看目录的权限。但这些都不能证明某个模型仍在提供推理服务，也不能证明账户还有聊天额度。
模型目录适合提供上下文，聊天请求才直接检验你需要的能力。
免费额度不能靠模型名字猜
作者原先用下面这段代码筛选免费模型：
free = [m["id"] for m in models if m["id"].endswith(":free")]
问题就出在 endswith(":free")。它把特定平台的命名习惯当成了所有服务的共同规则。
原文指出，:free 常见于聚合路由端点。聚合服务把多个上游放在同一个命名空间里，需要用后缀区分零价格的模型变体。第一方端点则可能把免费资格放在账户层面，模型 ID 根本不带这个后缀。
例如，Groq 使用普通模型 ID；Gemini 的目录使用 models/gemini-… 这样的名称，并列出支持的方法，也没有 :free 后缀。作者的筛选器因此把实际能返回 200 的服务排除在外，还连续数周将一类可用服务归为「没有免费模型」。
同样不能盲信的，还有目录中的旧 ID。NVIDIA NIM 虽然列出了 80 个模型，但作者硬编码的部分 ID 已返回 410 Gone。后来能用的是目录中标记为当前可用的条目。
这里要区分两个对象：服务仍在响应，某个模型却可能已经退役。删除整个服务配置，会把问题处理得过大。
同样是失败，429、402、410 需要不同处理
410 Gone 首先指向具体模型 ID。作者的处理是检查当前模型条目，替换几个月前写死的旧 ID，而不是据此认定 NVIDIA NIM 整体不可用。
429 指向限流或配额约束，但单看数字还不能确定怎么恢复。作者此前丢弃了响应体，导致「稍后重试」和「套餐不符合要求」被压成同一种故障。响应体可能提供套餐或配额桶信息，Retry-After 和限流相关响应头也可能给出等待线索。
402 则要结合账户信息看。SambaNova 返回的 balance_units: 0 明确指向余额。作者强调，同一个服务的两个 Key，可能一个返回 402，另一个仍能返回 200，因此服务商级别的健康状态太粗了。
作者最终为每次尝试保存三项信息：状态码、响应体、时间戳，并按 Key 分别记录。模型目录仍保留在日志里，但不再承担判定可用性的任务。
这套做法的价值是让失败能够指导下一步：换模型、检查额度、等待重试，各自有依据。
我的判断
我认同作者对监控粒度的修正。接入 AI 服务时，目录发现、模型可调用、账户有额度是不同条件。只测 /v1/models，确实不足以支撑「聊天功能正常」的结论。相比仅检查服务商是否在线，按 Key 保留实际调用证据更方便定位问题。
但作者把 Gemini 和 Mistral 的 429 归因于共享免费池繁忙，这个解释不能仅凭状态码成立。原文没有展示完整响应体，也没有给出多账户、跨时段的对照记录。具体原因仍应由当次错误信息确认。
同样，单次聊天返回 200 只能证明当时那次调用成功，不能证明长期稳定。原文没有延迟、成功率或持续观测数据，也没有给出聊天探针的具体请求参数。因此，这是一份有用的排障经验，不能据此给几家服务的免费层排可靠性名次。
能拿来做什么
- 如果你在 Node 服务里接入多个模型端点，可以同时记录目录查询与聊天探测结果，让健康检查覆盖真正使用的聊天能力。
- 如果现有脚本依赖
:free筛选模型，应检查服务商的免费资格究竟绑定模型名称还是账户，分别处理这两种情况。 - 如果 AI 编程调用失败，可以先保留状态码、错误响应体和时间戳，再区分
429的配额约束、402的余额问题与410的模型退役。 - 如果团队共用一个服务商的多个 Key，应分别记录调用状态，避免一个 Key 的额度耗尽触发整个服务商的停用。