Ollama 出現 model not found 怎麼辦？從 API、模型名稱到執行中程序排查

先保留完整錯誤與連線位置#

先把錯誤中的三項資料記下來：

• 實際呼叫的 host 和 port，例如 127.0.0.1:11434 或 gpu-box.local:11434。
• 請求裡的 model 字串，例如 qwen3.5:9b 或 kimi-k2.5:cloud。
• 使用的 API 路徑，是原生 /api/chat、/api/generate，還是某個 OpenAI-compatible /v1 代理。

如果程式在 Docker、遠端 server 或另一個 systemd service 裡執行，終端機上可用的 localhost 不一定是程式看到的 localhost。先確認連線位置，再判斷模型。

第一關：確認 Ollama API 可達#

在出錯的同一個執行環境中執行：

1
curl -i http://127.0.0.1:11434/api/tags

你要先看到 HTTP 200 和 JSON，而不是直接得到 connection refused、timeout 或 HTML 錯誤頁。若 host 不在本機，替換成程式實際使用的主機：

1
curl -i http://gpu-box.local:11434/api/tags

Ollama 官方文件的 /api/tags 回應會列出每個模型的 name、digest、大小與 details。後面的測試要以這個回應中的 name 為準，不要自己猜 tag。

也可以用 CLI 對照本機 daemon：

1
ollama list
2
ollama ps

ollama list 表示已安裝的模型；ollama ps 表示目前載入記憶體的模型。模型沒有出現在 ollama ps 不代表不存在，第一次呼叫時仍可能才載入；真正判斷「能不能被 API 找到」要看 /api/tags。

第二關：精確比對模型名稱#

假設 /api/tags 回傳的名稱是 qwen3.5:9b，以下幾個字串就不應視為相同：

原生 API 的 body 使用模型名稱本身：

1
{
2
  "model": "qwen3.5:9b",
3
  "messages": [
4
    { "role": "user", "content": "Reply with exactly: ok" }
5
  ],
6
  "stream": false
7
}

如果你是從 OpenClaw、LangChain 或其他 provider abstraction 複製設定，先把 ollama/ 這類路由前綴和原生 API 的 model 欄位分開。這是「上層找得到、下層卻 404」的常見來源。

第三關：用 /api/show 檢查模型詳情#

從 /api/tags 取得完整名稱後，傳給官方的 model details endpoint：

1
curl http://127.0.0.1:11434/api/show \
2
  -H 'Content-Type: application/json' \
3
  -d '{"model":"qwen3.5:9b"}'

若 /api/show 成功，代表這個 host 至少能解析該模型的 manifest 與設定。若這裡回 404，問題仍在模型名稱、host 或模型尚未安裝，不需要先調整 prompt、temperature 或 context。

需要安裝時，使用同一個 Ollama host 執行：

1
ollama pull qwen3.5:9b
2
ollama list

如果模型來自自訂 Modelfile，先檢查 ollama create 使用的名稱與實際 API 呼叫的名稱；自訂名稱可以和來源模型名稱不同。

第四關：用最小 /api/chat 重現#

模型存在後，用最小請求測試對話，不要一開始帶入工具、長上下文或多輪 history：

1
curl http://127.0.0.1:11434/api/chat \
2
  -H 'Content-Type: application/json' \
3
  -d '{
4
    "model": "qwen3.5:9b",
5
    "messages": [
6
      {"role": "user", "content": "Reply with exactly: ok"}
7
    ],
8
    "stream": false
9
  }'

官方的 Chat API 要求 model 和 messages，並支援 stream、tools 與 options 等欄位。先讓最小文字請求成功，再逐項加回工具或其他設定，才能知道是哪一層引入錯誤。

如果 /api/chat 回傳成功，但整合工具仍顯示 model not found，請把整合程式的實際 request URL、provider name 和 model 值記錄下來。很多時候，命令列測的是本機 127.0.0.1，服務實際卻連到容器內的另一個 host。

Cloud model 不要當成 local model#

Ollama 現在也支援 cloud model。這會讓模型名稱看起來像已安裝，但實際路由與登入狀態不同。先確認你要的是哪一種：

1
ollama pull gemma4
2
curl http://127.0.0.1:11434/api/chat \
3
  -d '{"model":"gemma4","messages":[{"role":"user","content":"ok"}],"stream":false}'

1
ollama signin
2
ollama pull kimi-k2.5:cloud
3
ollama list

常見整合錯誤分流#

如果最後一列才是你的問題，站內已有 Ollama CORS 環境變數設定可作為背景；CORS 和模型不存在是兩個不同的失敗層。

最小排查清單#

1
# 1. 確認 daemon 與 host
2
curl -fsS http://127.0.0.1:11434/api/tags
3

4
# 2. 確認安裝與執行中模型
5
ollama list
6
ollama ps
7

8
# 3. 對某個確實存在的完整名稱查詳情
9
curl http://127.0.0.1:11434/api/show \
10
  -H 'Content-Type: application/json' \
11
  -d '{"model":"你的完整模型名稱"}'
12

13
# 4. 做最小 chat smoke test
14
curl http://127.0.0.1:11434/api/chat \
15
  -H 'Content-Type: application/json' \
16
  -d '{"model":"你的完整模型名稱","messages":[{"role":"user","content":"ok"}],"stream":false}'

這套順序的重點，是每一關只回答一個問題：服務在哪裡、模型是否存在、模型詳情能否讀取、最小推論能否完成。等這四關都通過，再回頭處理整合工具的 provider、工具呼叫或長上下文設定。

常見問題#