Ollama num_predict: giới hạn số token đầu ra

num_predict trong Ollama làm gì

num_predict là tùy chọn của Ollama dùng để giới hạn số token mà model được phép sinh trong một response. Giá trị này chỉ tính token đầu ra, nên prompt không bị tính vào giới hạn. Khi model đạt đến giới hạn, quá trình sinh dừng ngay tại vị trí đó, đôi khi dừng giữa một từ, và response trả về với done_reason được đặt thành length.

Đó là toàn bộ chức năng. Vấn đề là Ollama cho phép đặt giá trị này ở 3 vị trí riêng biệt, và thiết lập gần request nhất sẽ được ưu tiên. Hầu hết báo cáo kiểu "num_predict không có tác dụng" đều xảy ra vì một layer âm thầm ghi đè lên layer khác.

num_predict không phải là num_ctx

Hai tùy chọn này thường bị nhầm lẫn hơn bất kỳ cặp nào khác trong Ollama, và sự nhầm lẫn này làm mất nhiều thời gian debug.

num_ctx là lượng nội dung model có thể đọc. Đây là kích thước của context window, chứa prompt cùng toàn bộ nội dung đã được tạo cho đến thời điểm đó. Tăng giá trị này sẽ tốn thêm memory, vì key/value cache mà model giữ cho các token đó sẽ tăng theo kích thước window. Tính num_ctx phù hợp với phần cứng của bạn là một việc riêng, với các kiểu lỗi riêng.

num_predict là lượng nội dung model sẽ ghi. Đây là quy tắc dừng, không phải một khoản phân bổ tài nguyên. Tăng giá trị này tốn thời gian thực thi thay vì RAM, và không có dung lượng nào được cấp trước.

Hai tùy chọn này gặp nhau ở một điểm. Các token được tạo sẽ nằm trong context window ngay khi được tạo, vì vậy câu trả lời cũng có thể dừng do window đã đầy, thay vì do đã đạt giới hạn bạn đặt. Ollama báo cáo length trong cả hai trường hợp, nên giá trị giúp phân biệt chúng là eval_count, được trình bày ở phần dưới.

Đặt một lần bằng Modelfile

Modelfile nhúng giá trị vào model mà bạn tạo. Tạo file:

FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 512

Sau đó build model và đọc lại cấu hình đã tạo:

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

ollama show --parameters in một dòng cho mỗi parameter đã lưu, kèm theo giá trị của parameter đó. Nếu num_predict không xuất hiện trong output này, model không có giới hạn được nhúng sẵn và default của Ollama sẽ được áp dụng. ollama show --modelfile qwen3-capped in toàn bộ định nghĩa. Đây cũng là cách nhanh nhất để sao chép các parameter mà một model hiện có đã được phát hành kèm.

Đây là layer phù hợp cho giá trị mà bạn muốn mọi caller kế thừa. Đây không phải layer phù hợp nếu bạn cho rằng giá trị này là cố định cuối cùng, vì thực tế không phải vậy.

Đặt cho từng request trong object options

Mọi endpoint generation đều nhận một object options, và num_predict được đặt bên trong object đó:

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 sử dụng cùng key options với cùng ý nghĩa. Giá trị đặt ở đây chỉ áp dụng cho lần gọi đó, không áp dụng cho bất kỳ nơi nào khác. Đây là layer mà các công cụ của bạn sử dụng: giao diện chat, script, wrapper SDK hoặc coding agent. Tất cả đều gửi một object options, bất kể chúng có hiển thị ô nhập cho object đó hay không.

Đặt cho một phiên bằng /set parameter

Trong ollama run, phiên tương tác đặt các tùy chọn cho phần còn lại của phiên đó:

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

/show parameters hiển thị nội dung phiên sẽ gửi cùng tin nhắn tiếp theo của bạn. Đây là cách nhanh nhất để xác nhận thay đổi đã có hiệu lực. Giá trị này được giữ nguyên cho đến khi bạn nhập /bye. Để lưu lại, /save qwen3-capped ghi phiên hiện tại, bao gồm cả các parameter, thành một model mới. Không có nội dung nào bạn /set ở đây được gửi đến client khác.

Cài đặt nào được ưu tiên, và vì sao cài đặt của bạn có vẻ bị bỏ qua

Thứ tự rất ngắn gọn. Các option gửi kèm request được ưu tiên hơn mọi thứ khác. Một dòng PARAMETER num_predict trong Modelfile của model là giá trị fallback được dùng khi request không truyền giá trị. Nếu cả hai đều không có, Ollama sẽ dùng giá trị mặc định tích hợp sẵn.

/set parameter không phải là quy tắc thứ ba. Interactive session là một API client, nên giá trị bạn đặt ở đó được gửi trong options của request đó. Vì vậy, nó ghi đè Modelfile trong session.

Đây là lỗi mà cơ chế trên giải thích. Bạn thêm PARAMETER num_predict 512, rebuild model, nhưng các câu trả lời vẫn dài đến hàng nghìn token. Cài đặt của bạn có tồn tại, và ollama show --parameters xác nhận điều đó. Tuy nhiên, nó bị ghi đè trong từng request vì client gửi object options riêng với một giá trị riêng. Giá trị này thường là số bạn đã nhập trong màn hình cài đặt từ vài tháng trước rồi quên mất. ollama show đọc model đã lưu. Nó không thể cho bạn biết dữ liệu nào được gửi qua HTTP.

Bạn có thể kiểm tra phía server bằng một command. Gửi một request tạo câu trả lời dài, buộc giới hạn ở mức thấp, rồi đọc hai trường:

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'

Kết quả phải in ra "length" và 32. Nếu jq chưa được cài đặt, hãy cài trước bằng sudo apt install -y jq. Kết quả "length" và 32 có nghĩa là server tôn trọng option, còn application của bạn đang gửi một giá trị khác. Để xem server tự ghi nhận request như thế nào, hãy restart server với OLLAMA_DEBUG=1 trong environment rồi monitor journalctl -u ollama -f trong lúc application kết nối đến server.

Các giá trị âm và những con số bạn không nên sao chép

num_predict cũng chấp nhận các giá trị âm. Đây là các giá trị sentinel, không phải số lượng. Một giá trị âm có nghĩa là “không giới hạn giá trị này, tiếp tục sinh”. Một giá trị khác từng có nghĩa là “điền phần context còn lại”. Tính đến tháng 8 năm 2026, tài liệu tham khảo Ollama Modelfile ghi giá trị mặc định là -1, tức sinh vô hạn. Các phiên bản trước của cùng bảng cũng ghi -2 cho chế độ điền context.

Hãy coi tất cả các giá trị này là phụ thuộc phiên bản vì chúng đã thay đổi. Trong thời gian dài, tài liệu ghi giá trị mặc định là 128. Mục này chỉ được sửa vào cuối năm 2024, nên nhiều hướng dẫn vẫn lặp lại con số cũ. Đọc tài liệu tham khảo tham số Modelfile cho phiên bản bạn thực sự đang chạy, sau đó xác nhận hành vi bằng kiểm tra eval_count ở trên. Giá trị bạn tự xác minh trên máy của mình đáng tin hơn giá trị bạn đọc ở bất kỳ đâu, kể cả trong bài viết này.

Vì sao độ dài output là chi phí chính trên VPS chỉ dùng CPU

Quá trình sinh có 2 giai đoạn với tốc độ rất khác nhau. Model xử lý các token trong prompt theo từng batch, nhiều token cùng lúc. Output token được sinh từng token một, và mỗi token cần một lần quét đầy đủ qua các weight của model. Trên VPS chỉ dùng CPU, lần quét này bị giới hạn bởi băng thông bộ nhớ. Vì vậy, chi phí của 1 token được sinh ra cao hơn nhiều so với 1 token trong prompt.

Hãy yêu cầu response không streaming để xem các con số ngay:

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

Thời lượng được tính bằng nanosecond. Trong block này, đây là response mẫu được công bố trong tài liệu Ollama API chứ không phải phép đo trên một server cụ thể nào: 26 prompt token mất khoảng 0.1 giây, trong khi 237 output token mất khoảng 4.3 giây. Tốc độ sinh của bạn là eval_count chia cho eval_duration rồi quy đổi sang giây. Bạn nên đo số token mỗi giây trên phần cứng của mình một lần trước khi tối ưu các yếu tố khác. Tốc độ này phụ thuộc vào model không kém gì máy chủ. Vì vậy, nếu response dài mới là chi phí chính, một model được thiết kế để decode nhanh như Nemotron 3.5 Lightning trên VPS có thể giảm một phần thời gian mà giới hạn thấp đang bảo vệ.

Phần tính toán còn lại rất đơn giản. Ở tốc độ 8 token mỗi giây, một response dài 2,000 token sẽ giữ máy bận hơn 4 phút, trong khi model không biết bạn chỉ muốn một đoạn văn. Một số model cũng có thể lặp vô hạn, lặp lại một cụm từ cho đến khi có thứ gì đó dừng chúng. Nếu không có giới hạn, một request duy nhất có thể giữ 1 core bận cho đến khi context window đầy. num_predict là setting dùng để giới hạn độ dài này. Setting này đặc biệt quan trọng trên một VPS Ollama tự host nhỏ, nơi một request dài có thể chiếm toàn bộ máy.

Output bị cắt thường là do giới hạn, không phải model bị lỗi

Các triệu chứng này trông giống lỗi của model. Câu trả lời dừng giữa chừng. JSON không parse được vì dấu ngoặc đóng chưa xuất hiện. Phản xạ đầu tiên thường là đổ lỗi cho model hoặc quantisation. Hãy đọc response trước.

done_reason có nghĩa là model trả lời trực tiếp câu hỏi. stop có nghĩa là model tự kết thúc, bằng cách phát end-of-sequence token hoặc khớp một trong các chuỗi trong tùy chọn stop của bạn. length có nghĩa là quá trình sinh bị dừng vì hết chỗ. Khi thấy length, hãy so sánh eval_count với giới hạn của bạn: hai giá trị khớp chính xác nghĩa là num_predict đã dừng quá trình, còn số nhỏ hơn nghĩa là context window đã đầy trước.

Khi stream, các trường này xuất hiện trong chunk cuối cùng, tức chunk chứa "done": true. Nhiều client library loại bỏ chunk này và chỉ chuyển phần text cho code của bạn. Vì vậy, cùng một lần bị cắt trông khó giải thích bên trong ứng dụng nhưng lại rõ ràng khi dùng curl. Nếu library ẩn thông tin này, hãy gửi một request với curl để biết chính xác server đã trả về gì.

Có một điểm nữa giúp tránh mất cả buổi chiều. Tăng num_predict không khiến model viết nhiều hơn. Nó chỉ gỡ bỏ một giới hạn trên. Nếu reply kết thúc ở 200 token với done_reason của stop, model đã quyết định hoàn tất và tăng giới hạn cũng không thay đổi gì. Câu trả lời ngắn kèm stop là vấn đề về prompt. Câu trả lời ngắn kèm length là vấn đề về giới hạn.

Chọn giá trị

• Với chat tương tác, hãy để không giới hạn và nhấn Ctrl+C để dừng câu trả lời chạy quá lâu. Bạn vẫn đang theo dõi màn hình.
• Với mọi thứ chạy bằng script, hãy đặt giới hạn. Generation không giới hạn bên trong loop có thể khiến một batch job lẽ ra chỉ mất mười phút vẫn chạy đến sáng hôm sau.
• Với output có cấu trúc, hãy đặt giới hạn cao hơn tài liệu hợp lệ lớn nhất mà bạn dự kiến, sau đó coi done_reason của length là lỗi nghiêm trọng và retry thay vì parse phần output đã nhận.
• Với coding agent, giá trị này nằm trong cấu hình riêng của agent, vì agent tự gửi các option của nó trong mỗi request. Trỏ coding agent đến Ollama giải thích vị trí của các setting đó.

Giới hạn này tính theo token, không phải từ hoặc ký tự, vì vậy đừng ước lượng. Hãy generate một câu trả lời đại diện khi không đặt giới hạn, đọc eval_count, rồi đặt giới hạn cao hơn giá trị đó một khoảng an toàn. Các họ model tokenise khác nhau, nên một giá trị đủ cho model Llama có thể làm truncate cùng câu trả lời khi dùng model Qwen 3 trên cùng VPS.

FAQ

Sự khác nhau giữa num_ctx và num_predict trong Ollama là gì?

num_ctx là kích thước context window, nên nó quyết định lượng nội dung model có thể đọc: prompt cộng với mọi nội dung đã tạo cho đến thời điểm đó. Tham số này tốn memory vì key/value cache tăng theo kích thước đó. num_predict quyết định số token tối đa mà model có thể ghi trong một response. Tham số này chủ yếu tốn thời gian thay vì memory, và không reserve trước. Các token đã tạo được tính vào cả hai giới hạn, nên response có thể bị cắt bởi một trong hai.

Vì sao thiết lập num_predict của tôi có vẻ bị bỏ qua?

Vì giá trị gửi cùng request sẽ override giá trị được lưu trong model. Đặt PARAMETER num_predict 512 trong Modelfile, sau đó dùng model đó từ chat front end hoặc coding agent, thì client sẽ gửi object options riêng và giá trị trong đó sẽ được ưu tiên. ollama show --parameters vẫn in ra giá trị của bạn vì nó đọc model đã lưu và không biết nội dung nào được gửi qua HTTP. Gửi một request với curl bằng "options": {"num_predict": 32} rồi kiểm tra xem eval_count có trả về 32 hay không. Điều này xác nhận server đang hoạt động đúng và chuyển hướng kiểm tra sang application của bạn.

Làm thế nào để biết output bị cắt bởi num_predict?

Gửi request với "stream": false và đọc done_reason. Giá trị stop nghĩa là model tự kết thúc. Giá trị length nghĩa là model đã hết giới hạn. Sau đó so sánh eval_count với giới hạn của bạn: nếu hai giá trị khớp chính xác, num_predict đã dừng model; nếu eval_count nhỏ hơn, context window đã đầy trước. Khi streaming, cả hai field xuất hiện trong chunk cuối cùng cùng với "done": true, nhưng nhiều client library loại bỏ chúng trước khi code của bạn nhận được.

Giá trị mặc định của num_predict là gì?

Hãy đọc từ bản cài đặt của bạn thay vì dựa vào một bài viết. Tính đến tháng 8 năm 2026, tài liệu tham khảo Ollama Modelfile ghi giá trị mặc định là -1, nghĩa là generation không bị giới hạn, và mục này đã được sửa vào cuối năm 2024 sau nhiều năm ghi là 128. Các giá trị âm là sentinel chứ không phải số lượng token, và các phiên bản cũ hơn của cùng bảng cũng từng ghi -2 để lấp đầy phần context còn lại. Hãy kiểm tra tài liệu tham khảo tham số Modelfile cho phiên bản của bạn, sau đó xác nhận bằng ollama show --parameters và một request curl.

Tăng num_predict có làm model viết câu trả lời dài hơn không?

Không. Tham số này chỉ bỏ giới hạn trên. Nếu response kết thúc với done_reason của stop, model đã tự quyết định hoàn tất và tăng giới hạn cũng không thay đổi gì. Trong trường hợp đó, độ dài phụ thuộc vào prompt: hãy yêu cầu cấu trúc cụ thể, số lượng section hoặc mức độ chi tiết rõ ràng. Chỉ tăng num_predict khi done_reason trả về length.