model not found 是什么原因？配置 AI 工具时先检查模型名

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

model not found 是什么原因？配置 AI 工具时先检查模型名

配置 Codex、ChatBox、Cherry Studio 或其他 AI 工具时，有一个报错很常见：

model not found

很多人看到这个提示，会先怀疑是不是 API Key 填错了，或者接口地址不能用。其实不一定。

如果已经能正常连接接口，但一发消息就提示 model not found，大概率是“模型名”和“当前接口支持的模型”没有对上。

这篇按实际排查顺序整理一下。遇到这个问题，不建议一上来就反复换 Key，可以先看下面几个地方。

1. model 不是随便填的，要复制平台支持的模型名

很多 AI 工具都会让你填三个核心配置：

base_url
api_key
model

其中 model 指的是这次请求要调用哪个模型。

它不是一个随便起的名称，也不是“我想用哪个模型就写哪个模型”。客户端最终会把这个模型名发给接口，如果接口那边没有这个模型，就会返回类似 model not found 的提示。

常见错误有几种：

• 模型名手打时多了空格
• 横线、点号、版本号写错
• 把展示名称当成了接口模型名
• 复制了别的平台的模型名
• 客户端默认模型和当前平台不匹配

我的建议是：不要手打模型名，直接去平台后台或文档里复制。

尤其是模型名里带版本号的时候，手打很容易少一个字符。看起来只是一个小差别，接口侧会把它当成另一个完全不存在的模型。

2. 客户端默认模型不一定能直接用

有些工具安装后，会默认填一个模型名。

这个默认值不一定适合你当前配置的接口。比如工具默认按官方接口的模型名来填，但你现在接的是 OpenAI 兼容接口，模型列表可能并不完全一样。

这种情况下，base_url 是对的，api_key 也是对的，但只要 model 不在当前接口支持范围内，还是会报错。

可以按这个顺序处理：

如果工具支持“测试连接”，可以先用最基础的模型测试。先跑通，再换更复杂的模型，这样排查会轻松很多。

3. 当前 Key 可能没有这个模型权限

还有一种情况也很容易被忽略：模型确实存在，但当前 API Key 没有权限调用。

这时客户端也可能提示 model not found、permission denied，或者只给一个很简单的失败提示。

可以重点看这几个地方：

• 当前 Key 是否启用
• 当前分组是否允许调用该模型
• 后台是否给这个 Key 绑定了模型权限
• 账号额度是否正常
• 调用日志里有没有更具体的错误

如果后台有调用日志，建议优先看日志。客户端弹窗有时候只展示一句话，日志里通常能看到更准确的原因。

一个简单判断方法是：

后台没有请求记录：优先查 base_url、网络、客户端配置
后台有请求记录：优先查模型名、权限、额度、分组配置

这个判断很实用。因为请求有没有到后台，决定了你应该先查客户端，还是先查账号侧配置。

4. base_url 和 model 要来自同一个平台

还有一个高频问题：base_url 用的是 A 平台，model 复制的是 B 平台。

OpenAI 兼容 API 的配置方式看起来很像，但不同平台的模型名称、权限、分组规则不一定完全一样。

比如你在工具里这样配置：

base_url = https://yunshuapi.cn/v1
api_key = 你的 API Key
model = 从当前平台模型列表复制的模型名

这三个信息最好来自同一个后台。不要接口地址用一个平台，模型名又从另一个平台复制。

如果你用的是统一入口，建议把常用配置整理成一份固定模板：

接口地址：平台提供的 /v1 地址
API Key：当前平台生成的 Key
模型名：当前平台模型列表里的接口名称

以后换工具时，就按这三项复制过去。这样比每次临时找配置稳很多。

5. 保存配置后，记得重启或重新加载

有些桌面客户端保存配置后，不一定马上生效。

如果你已经改了模型名，但还是报同样的错误，可以试试：

• 关闭当前会话，重新新建会话
• 重启客户端
• 重新选择一次模型提供方
• 清掉旧的默认模型配置
• 确认当前会话没有继续使用旧模型

这个问题听起来很小，但实际排查时经常遇到。尤其是客户端里同时配置了多个提供方时，界面上看着改了，实际请求可能还在走旧配置。

配置时可以记住这张表

如果只看一句话，那就是：

model not found 优先查 model，其次查权限，再看 base_url 是否和 model 对应。

一个建议的排查顺序

遇到 model not found，可以按下面这个顺序来：

这样排查下来，大部分问题都能定位到。

小结

model not found 不是一个复杂问题，但它很容易让人误判。

很多时候 Key 没坏，接口地址也没错，只是客户端里的模型名和当前平台支持的模型列表没有对上。

配置 OpenAI 兼容 API 时，建议把三项信息放在一起看：

base_url -> api_key -> model

这三项要来自同一个平台，并且当前 Key 要有对应模型权限。

如果你经常在 Codex、ChatBox、Cherry Studio 这类工具之间切换，可以提前整理一份自己的配置模板。后面换工具时，只需要复制接口地址、Key 和模型名，排查成本会低很多。

像云舒 API 这类统一入口，更适合用来集中管理接口地址、模型列表和调用记录。个人使用时不用一开始配置得很复杂，先用一个基础模型跑通，再逐步切换到自己常用的模型，会更稳。