ollama list 有模型，API 为什么仍报 model not found

终端里 ollama list 能看到模型，应用调用却返回类似下面的 JSON：

{"error":"model 'llama3:8b' not found"}

要核对的是这个 API 地址对应的实例。一个机器上可以同时有系统服务、手动启动的服务和容器；它们的端口、账号和模型目录可能不同。下面使用 Ollama 0.5.2 的本地模型 API，不讨论云端模型。

在应用使用的地址列出模型

不要先在另一个终端重新 pull。把请求地址与应用完全对齐，查询 /api/tags。以下是通过既有本地转发访问服务的只读示例，11435 替换为应用实际端口：

curl --fail --show-error http://127.0.0.1:11435/api/tags

响应中的 models[].name 才是这个服务列出的名称。保留完整的 namespace 和 tag，复制到请求的 model 字段。下面只是请求示例，会加载模型并生成内容，执行前应确认服务有可用资源：

curl --fail --show-error http://127.0.0.1:11435/api/generate   -H 'Content-Type: application/json'   -d '{"model":"llama3:8b","prompt":"回复一个词","stream":false}'

示例假定该实例已经列出 llama3:8b。model:tag 中省略 tag 会按 latest 解析，不能认为 8b、70b 和 latest 必然是同一份模型。是否需要 stream:false 属于响应读取方式，这个字段不会修复模型缺失。

CLI 也需要指向同一个实例

OLLAMA_HOST 会影响 Ollama CLI 的目标。在服务器本机的默认终端列出模型，与在应用指向的其他端口列出模型，可能是两个结果。已确认应用使用本地 11435 时，可以在单次命令中明确目标：

OLLAMA_HOST=127.0.0.1:11435 ollama list

它只影响这次命令的目标，不修改服务端监听。远程入口仍须沿已有安全通道使用；不能将这里的客户端配置当成需要重新启动服务器的理由。

同机不同账号，模型目录也可能不同

标准 Linux 安装的服务通常由 ollama 用户运行，模型目录与普通用户手动运行时不同；容器又可能使用独立的数据卷。检查实际服务账号、启动环境中的 OLLAMA_MODELS 和持久化目录挂载。

文件夹里有几个 blob 不等于模型已经注册可用：服务还需要对应的 manifest，以及它引用的完整对象。不要为了让目录可读而对所有文件开放权限，也不要删除目录后让程序重新下载来掩盖实例错位。

若只是应用连错了端口，修正客户端地址通常就足够。若确实要统一模型目录，先保存服务配置与数据，核对目录完整性和服务账号权限，安排重启；保留原目录，在同一个 API 地址确认模型可列出并生成后再处理迁移。

目标实例确实没有模型，再在该实例下载

确认模型名称和权限后，下面的修复片段把 CLI 明确指向同一入口：

OLLAMA_HOST=127.0.0.1:11435 ollama pull llama3:8b

下载会占用目标服务器的网络、磁盘和后续加载资源。先确认允许获取该模型，并核对空间与原服务配置；不要只为排错下载另一个大型模型。完成后重新请求同一地址的 /api/tags，再发起原应用请求。

如果响应是普通 404 page not found，而没有模型错误 JSON，还需核对反向代理路径、请求方法和服务版本。浏览器直接用 GET 打开只接受 POST 的生成接口，不能作为模型是否存在的验证。若连 TCP 都失败，先核对服务监听与客户端目标地址，模型下载不能修复拒绝连接。