openai兼容接口怎么获取模型列表

拿到一个中转站或自建服务的 Key，第一件事往往不是发对话请求，而是先问一句「你这儿到底有哪些模型」。很多人直接调 /v1/models 拿到一坨 JSON 就懵了：字段哪些能信、列表里有但调用 404 是怎么回事。这篇按调用、读字段、核对三步走，把模型列表这个端点讲成能直接照做的动作。

拿到一个中转站或自建服务的 Key，很多人第一反应是直接发对话请求，结果报错也说不清是模型名写错、渠道没通还是额度问题。更稳的顺序是先问一句「你这儿到底有哪些模型」：调一次模型列表端点，把返回的 id 拿全，再拿其中一个去跑对话。这样出问题时能立刻分清是「名字不对」还是「服务不对」。

但列表拿到手也别全信。兼容接口只是个约定俗成的外壳，不同中转站、不同自建网关对字段的填充程度差别很大，有的只保证 id 可用，其余字段是占位。这篇按调用、读字段、核对三步走，把它讲成能照做的动作。

先把这个端点调通

路径的拼法是 Base URL 后面直接接 /models，中间不要再补一次 /v1。最常见的 404 就是路径重复：配置里写的 Base URL 已经带了 /v1，代码里又拼了一遍。调之前先把你实际用的 Base URL 打出来看一眼，确认它停在版本号那一层为止。

curl -s -H "Authorization: Bearer $API_KEY" \
  "$BASE_URL/models" | head -c 800

curl 通了再换 SDK 的 client.models.list()，两种方式的结果应该一致；不一致说明你的 SDK 在 Base URL 上又做了自己的拼接，去看 SDK 的初始化参数。用同一套 Key 和同一个 Base URL 对比最干净。

状态码只是第一步，别看到 401 就反复改代码。先按换站验证的路子走一遍：同一个 Key 换路径、换服务商、换网络环境各试一次，能快速定位问题出在你这边还是服务那边。具体流程可参考站内的中转站检测入口 /sites。

返回字段哪些能信、哪些只是摆设

拿到 JSON 后，真正要盯的只有 id。这个字符串就是后面填进对话请求 model 参数的原文，原样复制，别自己改大小写、加厂商前缀或去掉后缀。很多「模型不存在」的报错，根源就是手抄时改了写法。

id

唯一必须用的字段，直接填进 model 参数，原样复制不改写

object

多半固定为 list 或 model，用于结构识别，不承载业务信息

owned_by

中转场景下常是占位字符串，不能拿来判断模型归属哪个厂商

created

只是登记时间，不代表模型新旧，更不代表能力强弱

有些实现会额外返回 permission、context_length 之类的扩展字段，看到就参考，缺了也别当故障——兼容接口并不要求这些字段齐全，缺字段不影响正常调用。想看某个模型真实的能力、上下文和版本差异，到站内模型资料库对照，比从列表字段里猜靠谱。

列表里有的不等于能调：做一次可用性核对

列表端点只说明服务愿意把这份清单返回给你，不保证每个模型背后都有可用渠道。所以从列表里挑出你要用的那一个之后，必须单独发一次真实请求验证，最好再分别测一次普通请求和流式请求，因为有的网关只在流式路径上出问题。

1. 挑目标模型发最短请求从列表里复制 id，发一条一两句话的对话请求，确认返回 200 且内容完整，不截断。
2. 故意发一个不存在的模型名用它反向验证错误处理：返回 404 或 400 说明服务会如实报错；一律吞成 500 的话，后续排障会非常吃力。
3. 分开记录两次结果把「拉列表成功」和「对话成功」当成两个独立指标记录，很多问题恰恰出在第二步，混在一起看会误判。
4. 定期拉列表做快照隔一段时间拉一次并保存，模型被下架、改名或悄悄换了后端时，能第一时间发现而不是等用户报错。

这套流程有个不适用的情况：如果你只是想快速试探某家中转站能不能用，不必每次都做完整核对，发一条对话请求就行，能回就基本可用。反过来，接入生产或多人共用的项目时，模型列表快照和可用性核对建议固化成定时任务，别靠人记。

顺便说一句，列表里的模型名并不等于定价档位，同一个 id 在不同中转站可能对应不同上游。想比较花钱效率，到站内价格追踪页面 /price-watch 核对当时的数字，别拿列表顺序当参考。