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 的大小，會容納 prompt 以及目前為止產生的所有內容。提高此值會增加記憶體用量，因為模型為這些 token 保留的 key/value cache 會隨 context window 擴大。依硬體規模設定 num_ctx 是另一項工作，也有其自身的失敗情況。

num_predict決定模型會寫入多少內容。它是停止規則，不是配置大小。提高此值增加的是實際執行時間，而非 RAM 用量，且不會預先保留任何資源。

兩者會在同一處產生關聯。模型產生 token 時，這些 token 會被放入 context window，因此回覆可能是因為 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 會輸出完整定義，也是複製現有模型已內建參數最快的方法。

如果您希望每個呼叫端都繼承某個值，這是正確的設定層級。但如果您預期該值會是最終值，這就不是正確的層級，因為它不會是最終值。

在 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 key，含義也相同。這裡設定的值只套用至該次呼叫，不會影響其他內容。這是工具使用的層級，包括聊天前端、script、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。如果系統缺少 jq，請先使用 sudo apt install -y 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。

要求不使用串流的回應後，數據會直接顯示：

"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 分鐘，而模型並不知道你只想要一個段落。有些模型也會進入迴圈，不斷重複某個片語，直到受到停止條件限制。沒有上限時，單一請求會持續占用一個 CPU 核心，直到用盡 context window。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 視為嚴重錯誤，重新嘗試，而不是解析已取得的內容。
• 對 coding agent，應在 agent 自身的設定中指定此值，因為 agent 會在每次請求中傳送自己的選項。將 coding agent 指向 Ollama 說明這些設定的位置。

此上限計算的是 tokens，不是單字或字元，因此不要自行估算。先在不設上限的情況下生成一則具代表性的回覆，查看 eval_count，再將限制設在高於該值且保留充足餘裕的位置。不同 model family 的 tokenization 方式不同，因此適用於 Llama model 的數值，可能會截斷來自同一台 VPS 上的 Qwen 3 model的相同回覆。

FAQ

num_ctx 與 num_predict 在 Ollama 中有何差異？

num_ctx 是 context window 的大小，決定模型能讀取多少內容：prompt 加上目前為止產生的所有內容。這會耗用記憶體，因為 key/value cache 會隨之增長。num_predict 決定模型在單次回應中最多可寫入多少 tokens。它主要耗用時間，而不是額外保留記憶體。產生的 tokens 會同時計入兩者，因此回應可能因任一設定而提前結束。

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

因為隨請求傳送的值會覆寫模型中儲存的值。在 Modelfile 中設定 PARAMETER num_predict 512，接著從聊天前端或 coding agent 使用該模型時，client 會自行傳送 options 物件，其中的數值會優先採用。ollama show --parameters 仍會顯示你設定的值，因為它讀取的是模型中儲存的設定，無法查看透過 HTTP 收到的內容。使用 "options": {"num_predict": 32} 傳送一個包含 curl 的請求，並確認回應中的 eval_count 為 32。這可確認伺服器本身運作正常，接著應將問題範圍縮小到你的應用程式。

如何判斷輸出是否因 num_predict 而提前截斷？

使用 "stream": false 傳送請求，並讀取 done_reason。stop 表示模型自行完成輸出。length 表示模型已用完可用空間。接著將 eval_count 與你的上限比較：若兩者完全相同，表示 num_predict 使輸出停止；若 eval_count 較小，則表示 context window 先填滿。使用串流時，這兩個欄位會隨最後一個區塊中的 "done": true 一起傳送，但許多 client library 會在你的程式取得資料前將其捨棄。

num_predict 的預設值是多少？

請以你自行安裝的版本為準，不要直接採用文章中的說法。截至 August 2026，Ollama Modelfile reference 將預設值列為 -1，表示不限制 generation；該項目在 2024 年底經過修正，此前多年一直記載為 128。負值是 sentinel，不是計數值；較舊版本的同一份表格也曾列出 -2，表示填滿剩餘的 context。請查閱 Modelfile 參數參考 確認你的版本，再使用 ollama show --parameters 和一個 curl 請求進行驗證。

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

不會。它只會移除上限。如果回應以 done_reason 結束，且 stop，表示模型判斷自己已完成輸出，提高上限也不會改變結果。此時長度取決於提示內容：要求特定結構、段落數量或明確的詳細程度。只有在 done_reason 回傳 length 時，才應提高 num_predict。