模型明明已经下载，接口却返回空数组。显存仍在占用时，也可能找不到没有释放的模型。排查前先分清两种状态：Ollama 的 /api/tags 列出已经保存到本机的模型，/api/ps 列出当前仍加载在内存中的模型。

这套检查方法适用于 Windows、macOS 和 Linux。前提是 Ollama 已安装，本地服务正在运行，并且终端能访问 localhost:11434。所有操作都是只读查询，不会拉取、删除或改名模型；示例返回里的模型名、体积、时间和显存数值会随本机环境变化。

Windows 建议在 PowerShell 或 Windows Terminal 中使用 curl.exe，避免旧版 PowerShell 把 curl 解释成其他命令。macOS 和 Linux 可直接使用 curl。如果 Ollama 配置了不同端口，应把命令中的 11434 换成实际监听端口。

先查本机保存了哪些模型

1. 先从系统终端开始。入口位置：Windows 打开 PowerShell 或 Windows Terminal。macOS 打开“终端”，Linux 打开当前桌面环境使用的终端。确认 Ollama 应用或服务已经启动。

   第一次请求只读取清单。主要动作：Windows 执行 curl.exe localhost:11434/api/tags。macOS 或 Linux 执行 curl localhost:11434/api/tags。请求方法是 GET，不需要 JSON 请求体。

   返回内容决定通路是否建立。成功标志：终端得到一个 JSON 对象，顶层包含 models 数组。数组里有对象，表示本地已有模型。返回 {"models":[]}，表示接口可用，但当前模型目录没有可列出的模型。

   错误信息要按类型处理。失败处理：连接失败时先启动 Ollama，再核对端口。出现 404 时检查路径是否完整写成 /api/tags。Windows 出现参数或别名提示时，确认执行的是 curl.exe。

Ollama API Reference 的 List models 页面同时给出了 GET 路径和本机请求示例。截图里左侧的 /api/tags 是接口入口，右侧命令是可以在终端复现的请求。

读懂模型列表里的关键字段

2. 清单留在刚才的终端里。入口位置：从 models 数组的第一个对象开始查看。有多个对象时，逐个按相同字段核对。

   字段要按身份和规格分开读。主要动作：先记下 name 或 model，再查看 modified_at、size 和 digest。判断规格时，继续看 details 内的 format、family、parameter_size 与 quantization_level。

   一条对象应能说明一个模型。成功标志：能够确定完整名称、修改时间、字节体积和内容摘要。还能读出格式、模型家族、参数规模与量化级别。后续运行或删除时，使用这里返回的完整名称。

   缺项不能靠猜测补齐。失败处理：字段缺失时先保留原始 JSON。不同模型或 Ollama 版本可能返回不同细节。终端输出挤成一行时，可用本机已有的 JSON 格式化工具查看，但不要改动字段名。

官方返回示例把模型身份和模型细节分成两层。排查“是否下载过”主要看 models、name 和 digest；判断模型规格再进入 details，不要把参数规模误当成文件体积。

再查哪些模型仍在运行

3. 运行状态仍从终端读取。入口位置：继续使用同一个查询窗口。若要观察明确状态，可在另一个终端执行 ollama run 模型完整名称 并保持会话，再回到查询窗口。

   第二次请求只查看加载情况。主要动作：Windows 执行 curl.exe localhost:11434/api/ps。macOS 或 Linux 执行 curl localhost:11434/api/ps。这个 GET 请求不会启动或停止模型。

   数组内容就是当前快照。成功标志：终端返回带有 models 数组的 JSON。出现模型对象，说明它仍被 Ollama 加载。空数组表示查询成功，但此刻没有模型处于加载状态。

   接口错误与空结果要分开。失败处理：连接失败时按第一步检查服务和端口。404 时确认路径是 /api/ps。刚结束会话就得到空数组并不一定异常，模型可能已经到达卸载条件。

List running models 页面把接口定义为 /api/ps，用途是读取当前运行中的模型。它和操作系统的 ps 命令不是一回事，也不会列出 Ollama 之外的进程。

用运行字段判断内存与卸载时间

4. 先锁定目标对象。入口位置：在 /api/ps 的 models 数组中找到目标模型。用 name 和 digest 与 /api/tags 的结果对应。

   资源判断只看三个新增字段。主要动作：读取 expires_at、size_vram 和 context_length。它们分别表示加载状态的到期时间、显存使用量和当前上下文长度。

   目标状态应能被单独描述。成功标志：能够确认模型是否在内存中，以及显存、上下文长度与到期时间。多个模型同时出现时逐个记录，不能把第一项当成全部状态。

   两个接口不一致往往不是故障。失败处理：/api/tags 有模型而 /api/ps 没有，通常表示模型已下载但未加载。刚启动仍查不到时，确认运行与查询指向同一台机器、同一端口和同一个服务。

运行状态响应除了重复模型身份与规格字段，还增加了到期时间、显存和上下文长度。截图中的这些字段用于判断资源占用；磁盘里是否存在模型，仍应以 /api/tags 为准。

把两次查询合成一个状态判断

5. 比较前先固定查询范围。入口位置：并排保留同一时间取得的 /api/tags 与 /api/ps 输出。按完整模型名核对，名称相近时再比较 digest。

   状态归类只需要三种结果。主要动作：两个数组都有目标，记为“已下载且当前加载”。只在 /api/tags 中出现，记为“已下载但当前空闲”。两个数组都没有时，先检查名称与模型目录。

   每个模型只能落入一种状态。成功标志：磁盘存在性与内存加载情况没有混写。需要持续监控时，定时保存两次 GET 的原始 JSON，并附上查询时间。

   环境不一致时不能硬比。失败处理：两次结果来自不同端口或机器时停止比较。查询间隔过长时重新连续执行两条命令。只凭 name 无法确认时，再核对 digest，不要按数组顺序配对。

最常见的误判是看到 /api/ps 空数组就认为模型被删除。空数组只说明当前没有模型加载到内存；只要 /api/tags 仍能列出目标，它就还在本地模型清单中。

完成检查清单

1. 服务可达：两条请求都能返回 JSON，而不是连接失败或 404。

2. 本地清单明确：/api/tags 中每个目标模型的完整名称、摘要和体积已经记录。

3. 运行状态明确：/api/ps 中是否存在目标模型已经确认，空数组没有被误判成删除。

4. 资源字段可读：运行模型的到期时间、显存使用量和上下文长度已经分别核对。

5. 环境一致：两次查询指向同一台机器、同一端口和同一个 Ollama 服务。

6. 图片可访问：4 张接口入口与返回字段截图均能打开，并且每张只承担一个检查点。