Ollama num_predict 如何限制輸出長度？

Ollama 中的 num_predict 功能

num_predict 是 Ollama 中限制模型單次回應最多可產生多少 token 的選項。它只計算輸出 token，因此不會將提示內容計入限制。模型達到上限後，會立即停止產生內容，有時甚至會在單字中間停止；此時回應會將 done_reason 設為 length。

這就是此功能的全部內容。問題在於，Ollama 提供 3 個可設定此值的位置，而且距離請求最近的設定會優先套用。幾乎所有「num_predict 沒有作用」的問題，都是某一層設定在不知情的情況下覆寫了另一層設定。

num_predict 不是 num_ctx

這兩個選項在 Ollama 中比任何其他選項更常被混淆，並且會實際增加除錯時間。

num_ctx 是模型可以讀取的內容量。它代表 context window 的大小，其中包含提示內容，以及目前為止產生的所有內容。提高這個值會增加記憶體用量，因為模型為這些 token 保留的 key/value cache 會隨視窗大小增加。為硬體設定 num_ctx 大小 是另一項工作，也有其自身的失敗情況。

num_predict 是模型會寫入的內容量。它是停止規則，不是配置大小。提高這個值增加的是實際執行時間，而不是 RAM 用量；系統也不會預先保留這些資源。

兩者會在同一處產生關聯。模型產生內容時，產生的 token 會放入 context window，因此回覆可能不是因為達到上限而停止，而是因為視窗已填滿。Ollama 在這兩種情況下都會回報 length，因此用來區分兩者的數值是 eval_count，下文會進一步說明。

使用 Modelfile 設定一次

Modelfile 會將值寫入你建立的模型。建立檔案：

FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 512

接著建立模型，並讀回剛才建立的內容：

ollama create qwen3-capped -f Modelfile
ollama show --parameters qwen3-capped

ollama show --parameters 會針對每個已儲存的參數輸出一行及其值。如果該輸出中缺少 num_predict，表示模型沒有內建上限，會套用 Ollama 自身的預設值。ollama show --modelfile qwen3-capped 會輸出完整定義，也是複製現有模型已內建參數最快的方法。以這種方式建立設有限制的模型，幾乎不會增加額外磁碟空間，因為新項目會重複使用基礎模型已下載的權重 blob，而不是複製這些 blob；在 VPS 的 root 磁碟空間耗盡前，先了解 Ollama 儲存這些 blob 的位置 很有幫助。

如果你希望每個呼叫端都繼承某個值，這就是正確的設定層級。但如果你以為它會是最後生效的值，就不應該使用這一層，因為它不是。

在 options 物件中針對每個請求設定

每個 generation endpoint 都接受 options 物件，而 num_predict 放在該物件中：

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "prompt": "Explain what a reverse proxy does.",
  "stream": false,
  "options": { "num_predict": 128 }
}'

/api/chat 使用相同的 options 金鑰，意義也相同。這裡的值只套用於該次呼叫，不會影響其他內容。您的工具會使用這一層：聊天前端、指令碼、SDK wrapper 或 coding agent。無論介面是否顯示可供您填寫的欄位，它們都會傳送 options 物件。

使用 /set parameter 在單一工作階段中設定

在 ollama run 中，互動式工作階段會為該工作階段的其餘時間設定選項：

>>> /set parameter num_predict 256
>>> /show parameters

/show parameters 會顯示工作階段將隨下一則訊息傳送的內容，因此是確認變更是否生效最快的方法。此值會持續存在，直到您輸入 /bye 為止。若要保留此設定，/save qwen3-capped 會將包含目前工作階段參數的內容寫入為新模型。在此處使用 /set 所做的任何變更，都不會影響其他用戶端。

哪個設定會生效，以及為什麼看起來像被忽略

套用順序很簡單。隨請求傳送的選項優先於其他設定。模型 Modelfile 中的 PARAMETER num_predict 行，會在請求未提供值時作為後備設定。兩者都未設定時，才會套用 Ollama 的內建預設值。

/set parameter 不是第三條規則。互動工作階段是 API 用戶端，因此你在其中設定的值會以該請求的 options 傳送。這正是它會在該工作階段覆寫 Modelfile 的原因。

現在說明這項設定能解釋的問題。你加入 PARAMETER num_predict 512、重新建置模型，但回覆仍然產生數千個 token。你的設定確實存在，ollama show --parameters 也證明了這一點。每個請求都會覆寫該設定，因為用戶端會傳送自己的 options 物件，其中包含另一個數值。這通常是你幾個月前在設定畫面輸入、之後忘記的數值。ollama show 讀取的是已儲存的模型，無法顯示透過 HTTP 收到的內容。

用一個命令即可驗證伺服器端。傳送一個會產生長篇回覆的請求，將上限強制設為較低的值，然後讀取兩個欄位：

curl -s http://localhost:11434/api/generate -d '{
  "model": "qwen3-capped",
  "prompt": "Describe the Linux boot process in detail.",
  "stream": false,
  "options": { "num_predict": 32 }
}' | jq '.done_reason, .eval_count'

這應會列印 "length" 和 32。如果尚未安裝，先使用 sudo apt install -y jq 安裝 jq。若回應為 "length" 和 32，表示伺服器有遵循該選項，而你的應用程式傳送了不同的設定。若要查看伺服器對請求的記錄，請在環境中加入 OLLAMA_DEBUG=1 後重新啟動伺服器，並在應用程式與伺服器通訊時監看 journalctl -u ollama -f。

負值，以及不應照抄的數字

num_predict 也接受負值，但這些值代表特殊標記，而不是計數。某個負值表示「不要限制，持續產生內容」。另一個負值則曾表示「填滿剩餘的 context」。截至 August 2026，Ollama Modelfile 參考文件將預設值列為 -1，代表無限產生內容；同一表格的早期版本也曾列出 -2，表示填滿 context。

這些內容都應視為依版本而異，因為相關設定曾經變更。很長一段時間內，參考文件都將預設值記載為 128，直到 2024 年底才修正，因此許多指南仍會重複舊數字。請閱讀實際執行版本的 Modelfile 參數參考，再使用上方的 eval_count 檢查確認行為。你在自己的主機上驗證過的值，比從任何地方讀到的值都可靠，包括本文。

為什麼輸出長度是僅使用 CPU 的 VPS 主要成本

生成分為兩個速度差異很大的階段。提示詞 token 會以批次方式評估，一次處理許多 token。輸出 token 則一次產生一個，而且每個 token 都需要完整掃描一次模型權重。在僅使用 CPU 的 VPS 上，這個掃描速度受記憶體頻寬限制，因此產生一個 token 的成本遠高於評估一個提示詞 token。由於每次掃描都必須讀取所有權重，每個權重所占用的位元組數就決定了 token 速率的上限。這也是為什麼 q4 build 的解碼速度比相同模型的 q8 或 fp16 更快。

要求回應不要串流傳送，就能直接看到這些數字：

"prompt_eval_count": 26,
"prompt_eval_duration": 107345000,
"eval_count": 237,
"eval_duration": 4289432000

持續時間以奈秒表示。在該區塊中，這是 Ollama API 文件發布的範例回應，不是任何特定伺服器的測量結果：26 個提示詞 token 約花費 0.1 秒，而 237 個輸出 token 約花費 4.3 秒。你自己的生成速率是將 eval_count 除以 eval_duration，再換算為秒；在調整其他設定前，先測量自己硬體上的每秒 token 數值得一做。這個速率與模型本身同樣有關。因此，如果真正的成本是過長的回應，選用專為快速解碼設計的模型，例如 VPS 上的 Nemotron 3.5 Lightning，就能取回低上限原本用來節省的部分時間。

接下來只需計算即可。在每秒 8 個 token 的速度下，2,000 個 token 的回應會讓機器忙碌超過 4 分鐘，而模型不知道你只想要一個段落。推理模型會先花費部分預算進行思考，再寫出你要求的文字；這些思考內容同樣會一次產生一個 token。因此，你要求的推理強度也是影響相同成本的另一個調整項。有些模型還會反覆執行，持續重複某個片語，直到有條件停止它們。未設定上限時，這個單一請求會持續占用一個 CPU 核心，直到內容視窗用盡。num_predict 是限制其範圍的設定；在小型的自架 Ollama VPS 上，單一長請求可能占用整台機器，因此這項設定尤其重要。

截斷輸出通常是達到上限，而不是模型故障

這些症狀看起來像模型故障。回答在句子中途停止。JSON 無法剖析，因為結尾的大括號始終沒有出現。直覺上，人們會責怪模型或量化設定。請先讀取回應。

done_reason 表示回答直接解決了問題。stop 表示模型自行完成輸出，可能是發出 end-of-sequence token，也可能是符合 stop 選項中的其中一個字串。length 表示生成因為沒有剩餘空間而中止。看到 length 時，請將 eval_count 與上限比較：兩者完全相同表示是 num_predict 使輸出停止；若數值較小，表示 context window 先填滿。

使用串流時，這些欄位會出現在最後一個 chunk，也就是攜帶 "done": true 的 chunk。許多 client library 會丟棄這個 chunk，只將文字交給程式，因此相同的截斷在應用程式內看似無法解釋，在 curl 下卻很明顯。如果 library 隱藏了這項資訊，請使用 curl 傳送一次請求，以確認伺服器實際回傳的內容。

還有一點可以避免浪費一個下午。提高 num_predict 不會讓模型寫出更多內容，只會移除上限。如果回應在 200 tokens 處以 done_reason 結束，且 stop，表示模型判定自己已完成；提高上限也不會改變結果。帶有 stop 的簡短回答是 prompting 問題。帶有 length 的簡短回答是上限問題。

選擇值

• 互動式聊天可不設上限，並按下 Ctrl+C 停止失控的回覆。因為你會持續查看畫面。
• 任何腳本化工作都應設定上限。在迴圈中不設上限地生成內容，可能導致原本只需執行十分鐘的批次工作持續到隔天早上。
• 對結構化輸出，請將上限設在預期最大有效文件的大小之上，然後將 done_reason of length 視為嚴重錯誤，重新嘗試，而不是解析已取得的內容。
• 對程式碼代理程式，應在代理程式本身的設定中指定此值，因為代理程式會在每次請求中自行傳送選項。將程式碼代理程式指向 Ollama 說明這些設定的位置。

此上限計算的是 tokens，不是單字或字元，因此不要自行估算。先在不設上限的情況下產生一個具代表性的回答，讀取 eval_count，再將限制設得比該值寬裕一些。不同模型系列的 tokenization 方式不同，因此某個適用於 Llama 模型的值，可能會截斷同一 VPS 上 Qwen 3 模型的相同回答。

FAQ

num_ctx 和 num_predict 有什麼差異？

num_ctx 是 context window 的大小，用來設定模型可讀取的內容量，包括 prompt 以及目前為止產生的所有內容。這會消耗記憶體，因為 key/value cache 會隨之增長。num_predict 設定模型在單次回應中最多可寫入的 token 數量。它主要消耗時間，而不是記憶體，且不會預先保留空間。產生的 token 會同時計入兩者，因此回應可能因任一設定而提前結束。

為什麼我的 num_predict 設定似乎沒有生效？

因為隨 request 傳送的值會覆寫模型中儲存的值。將 PARAMETER num_predict 512 放入 Modelfile，然後從 chat front end 或 coding agent 使用該模型時，client 會自行傳送 options 物件，其中的數值會優先採用。ollama show --parameters 仍會顯示你的值，因為它讀取的是儲存於模型中的設定，無法看見透過 HTTP 傳入的內容。使用 "options": {"num_predict": 32} 傳送一個包含 curl 的 request，並確認回傳的 eval_count 為 32。這可確認 server 本身運作正常，接著應將問題範圍縮小至你的 application。

如何判斷 output 是否因 num_predict 而提前結束？

使用 "stream": false 傳送 request，然後讀取 done_reason。stop 表示模型自行完成回應。length 表示模型已用完可用空間。接著將 eval_count 與你的上限比較：如果兩者完全相同，表示 num_predict 使回應停止；如果 eval_count 較小，表示 context window 先填滿。使用 streaming 時，這兩個欄位會在最後一個 chunk 中與 "done": true 一起傳送，但許多 client library 會在程式碼讀取前將其捨棄。

num_predict 的預設值是多少？

請從你自己的 install 讀取設定，不要依賴文章。截至 August 2026，Ollama Modelfile reference 將預設值列為 -1，表示 generation 不設上限；該項目在 2024 年底修正，此前多年一直記載為 128。負值是 sentinel，不是數量；同一表格的舊版也曾列出 -2，用於填滿剩餘的 context。請查看你所用版本的 Modelfile parameter reference，再使用 ollama show --parameters 和一個 curl request 進行確認。

提高 num_predict 會讓模型產生更長的回應嗎？

不會。它只會移除上限。如果回應以 done_reason 結束，且 stop，表示模型判定自己已完成；提高上限不會改變結果。在這種情況下，長度取決於 prompting：要求特定結構、section 數量或明確的詳細程度。只有在 done_reason 回傳 length 時，才提高 num_predict。