ollama

為什麼你的本地 LLM 回傳空白？一個參數就能修好

你的 Ollama API 回 200 OK、done: true，但 response 是空字串。模型沒壞——它把所有 token 都寫進了 thinking 欄位。一個參數就能修好。

江中喬

05 7月 2026 • 8 min read

你的 Ollama API 呼叫回傳 200 OK，JSON 裡 "done": true，看起來一切正常——但 response 欄位是空字串。

模型沒壞。它確實在產出內容，只是不在你的程式讀取的地方。

症狀

你透過 Ollama 的 /api/generate 端點送一段 prompt 給本地模型，回應長這樣：

{
  "response": "",
  "done": true,
  "done_reason": "length",
  "eval_count": 64
}

你的腳本讀 response，拿到空字串，然後拋出錯誤或靜默產出空檔案。模型跑了好幾秒、消耗了 64 個 token，但你的自動化流程看到的是零產出。

背景

這發生在透過 Ollama /api/generate 跑 qwen3.6:latest 的時候。請求是一個簡單的摘要任務——沒什麼特別的：

curl -s http://your-ollama-host:11434/api/generate \
  -d '{
    "model": "qwen3.6:latest",
    "prompt": "用一段話摘要以下內容：...",
    "stream": false,
    "options": { "num_predict": 256 }
  }'

模型載入了、處理了 prompt、回傳了完整的 JSON。沒有錯誤、沒有 timeout。就只是 response 欄位是空的。

到底發生了什麼

原始 API 回應裡有一個你的自動化程式沒有檢查的欄位：

{
  "response": "",
  "thinking": "Here's a thinking process:\n\n1. **Analyze User Input:**\n   - Command: ...",
  "done": true,
  "done_reason": "length",
  "eval_count": 64
}

模型把全部 64 個 token 都輸出到 thinking 欄位——一段推理過程——還沒來得及在 response 欄位寫任何東西。關鍵細節：num_predict 是對總生成 token 數的硬上限，包含 thinking token。 模型把整個預算燒在推理過程上（done_reason: "length"），根本沒機會寫出最終答案。

模型沒有失敗。它只是在自言自語地思考，花光了預算，然後來不及回答。

修法

在請求 payload 裡加上 "think": false。重要：think 是 top-level 欄位，不是放在 options 裡面。

curl -s http://your-ollama-host:11434/api/generate \
  -d '{
    "model": "qwen3.6:latest",
    "prompt": "用一段話摘要以下內容：...",
    "stream": false,
    "think": false,
    "options": { "num_predict": 1024 }
  }'

常見錯誤：把 "think": false 放進 "options": {} 裡面——會被靜默忽略。它必須在 request body 的最外層，跟 "model" 和 "prompt" 同級。

修改後的回應：

{
  "response": "The dispatch smoke test verified that a bounded local job...",
  "done": true,
  "done_reason": "stop",
  "eval_count": 107
}

response 有內容了（448 bytes）
thinking 變空了（長度 0）
done_reason 從 "length" 變成 "stop"——模型自然完成，而不是撞上限
eval_count 從 64 升到 107——更多 token 用在了實際輸出

最小範例

修改前（thinking 啟用，response 空白）：

import requests

resp = requests.post("http://your-ollama-host:11434/api/generate", json={
    "model": "qwen3.6:latest",
    "prompt": "用一句話回答：hello world。",
    "stream": False,
    "options": {"num_predict": 256}
})
data = resp.json()
print(data["response"])  # → ""（空字串）
print(len(data.get("thinking", "")))  # → 247（token 全跑去這裡）
print(data["done_reason"])  # → "length"

修改後（thinking 關閉，response 有內容）：

import requests

resp = requests.post("http://your-ollama-host:11434/api/generate", json={
    "model": "qwen3.6:latest",
    "prompt": "用一句話回答：hello world。",
    "stream": False,
    "think": False,
    "options": {"num_predict": 256}
})
data = resp.json()
print(data["response"])  # → "Hello world."（實際輸出）
print(len(data.get("thinking", "")))  # → 0
print(data["done_reason"])  # → "stop"

對自動化的影響

如果你正在把本地 LLM 接進腳本、pipeline 或批次任務，你大概是讀 response 然後當作模型的答案。對大部分模型來說這沒問題——直到你遇到一個預設啟用推理模式的「thinking model」。

這個故障是靜默的：沒有 HTTP 錯誤、沒有例外、沒有 timeout。只是你期望有內容的地方出現了空字串。如果你的程式沒有檢查這個狀況，它會在下游崩潰，或者更糟——靜默產出空白檔案然後繼續跑。

你可能正在踩到這個問題的跡象：

response 是空的，但 eval_count 不是零
done_reason 是 "length"，即使你的 prompt 很短
API 呼叫花了好幾秒（模型確實在生成 token，只是沒有寫進 response）

如果需要推理過程呢？

用 "think": false 關掉推理，適合簡單任務——摘要、萃取、格式化——只要最終答案的場景。

但如果你的使用場景需要 chain-of-thought 推理（複雜邏輯、多步驟數學、帶解釋的程式碼生成），關掉 thinking 可能會降低輸出品質。這時候可以：

同時解析兩個欄位。 讀 thinking 和 response（或在 /api/chat 上讀 message.thinking 和 message.content）。把 thinking 用於除錯或 log，response 用於最終答案。
設 num_predict: -1（無限）。 這會移除 token 上限，讓模型想多久就多久，然後還有空間產出回應。用 num_ctx 來控制總 context 大小。
把 num_predict 設高。 如果無限制讓你不安，試試 "num_predict": 8192 或更高——給模型足夠空間同時思考和回答。
用 /api/chat 取代 /api/generate。 chat 端點對某些模型處理 think: false 更可靠（#14793）。
Modelfile 模板 hack。 社群流行的解法：在 system prompt 或 Modelfile 模板開頭注入空的 <think></think> 區塊，強制跳過推理階段。適用於 Qwen 3、DeepSeek R1、QwQ 等推理模型。
CLI 選項。 互動式使用時，ollama run <model> --hidethinking 可以隱藏推理過程但不關閉推理功能，或在互動式 session 中用 /set nothink。

關鍵認知："think": false 是請求層級的參數，不是永久的模型設定。你可以根據任務逐次切換。

注意事項

這是有文件記載的行為。 Ollama 從 v0.9.0（2025 年 5 月 29 日）起正式支援 think 參數，/api/generate 和 /api/chat 都支援。Qwen 3、DeepSeek R1、DeepSeek-v3.1、GPT-OSS 等模型預設啟用 thinking。參見 Ollama thinking 文件和公告部落格。
這是被廣泛回報的問題。 多個 GitHub issue（#10976、#14793、#14716、#15288）和社群貼文確認，空 response/content 搭配有內容的 thinking 是 Qwen 3、DeepSeek R1、Gemma 4 等推理模型的常見痛點。LiteLLM、LangChain、OpenWebUI、Zammad 等第三方整合都遇過。
/api/generate 的已知 bug：#14793 回報 think: false 在 /api/generate 上可能被靜默忽略（qwen3.5:9b，Ollama 0.17.7），而 /api/chat 正常處理。如果 think: false 在 /api/generate 上沒用，請改用 /api/chat。
GPT-OSS 模型要用字串值：GPT-OSS 要傳 "think": "low" / "medium" / "high"，不能用布林值——布林值會被靜默忽略。
升級 Ollama 後要重新 pull 模型：如果你升級到 v0.9.0+ 但 think 參數行為異常，重新跑 ollama pull <model>。chat template 在 thinking 功能發布時有更新。
Prompt 層級的 workaround 沒用：在 prompt 文字裡加 /no_think 經測試無法關閉 thinking 模式。只有 API 層級的 "think": false 參數有效。
Tools + thinking 的交互：#10976 回報 think: true 搭配 tool definitions 會產出空白。Vision 輸入（#14716、#16184）也會觸發同樣問題。如果你在用 function calling 或多模態輸入，請仔細測試。
num_predict 包含 thinking token：這是根本原因。num_predict 限制的是總生成 token 數——thinking 和 response 加起來。一個需要 500 token 思考、200 token 回答的模型，num_predict 至少要 700，否則預算會在推理階段耗盡，response 留空。
安全提醒：Ollama 在 port 11434 監聽且沒有內建認證。如果你把 Ollama 暴露到網路上（即使是家用網路），請用反向代理加認證。絕對不要直接把 port 11434 開放到網際網路。

Debug 排查清單

如果你的 Ollama 自動化產出空白結果，按順序檢查：

response 真的是空的嗎？還是你的解析有問題？
JSON 回應裡有沒有 thinking 欄位且有內容？
done_reason 是不是 "length"？（推理階段吃完了生成預算）
eval_count 是不是非零？（模型確實有生成 token，只是不在你預期的地方）
你的 Ollama 版本 ≥ v0.9.0 嗎？不是的話，升級並重新 pull 模型。
試試在請求的 top-level 加 "think": false（不是放在 options 裡）。
如果 think: false 在 /api/generate 上被忽略，改用 /api/chat。
如果需要保留 thinking，試試 "num_predict": -1（無限）或高數值如 8192。
GPT-OSS 模型要用 "think": "low"，不能用 false。
確認你的模型是在 Ollama v0.9.0 升級後重新 pull 的——不確定就重新 pull。

結語

這是一個參數就能修好的問題，但它造成的挫折感不成比例。模型沒壞——API 的回應結構比你預期的多了一個欄位，而你的程式假設 response 是唯一的輸出位置。

更大的啟示：把本地 LLM 接進自動化時，不要只檢查 HTTP 錯誤和 timeout。檢查回來的東西長什麼樣。一個 200 OK 搭配空白 response，可能是你的模型最有生產力的一次失敗——它只是把所有東西寫錯了欄位。

本文基於 2026 年 7 月的本地自動化專案實際觀察，已對照 Ollama 官方 thinking 文件驗證。think 參數自 2025 年 5 月起為正式支援功能。請以你自己的模型和 Ollama 版本測試後再套用。

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。

症狀

背景