Ollama num_predict: як обмежити довжину відповіді

Що робить num_predict в Ollama

num_predict — це параметр Ollama, який обмежує кількість токенів, що модель може згенерувати в одній відповіді. Він враховує лише вихідні токени, тому промпт не зараховується до цього обмеження. Коли модель досягає ліміту, генерація зупиняється на поточному місці, іноді посеред слова, а у відповіді done_reason має значення length.

На цьому функціональність завершується. Складність у тому, що Ollama дає змогу задати це значення в трьох окремих місцях, і пріоритет має параметр, найближчий до запиту. Майже кожне повідомлення про те, що «num_predict нічого не робить», пояснюється тим, що один рівень непомітно перевизначає інший.

num_predict — це не num_ctx

Ці два параметри в Ollama плутають частіше, ніж будь-яку іншу пару. Через це налагодження займає більше часу.

num_ctx визначає, скільки тексту модель може прочитати. Це розмір контекстного вікна, у якому зберігаються prompt і весь текст, згенерований на цей момент. Збільшення цього значення потребує більше пам’яті, оскільки key/value cache, який модель зберігає для цих токенів, зростає разом із розміром вікна. Визначення розміру num_ctx для вашого обладнання — це окреме завдання з власними причинами збоїв.

num_predict визначає, скільки тексту модель може записати. Це правило зупинки, а не виділення ресурсу. Збільшення цього значення потребує більше часу виконання, а не RAM, і заздалегідь нічого не резервується.

Ці параметри взаємодіють в одному місці. Згенеровані токени додаються до контекстного вікна в міру створення, тому відповідь може завершитися через заповнення вікна, а не через досягнення встановленого обмеження. 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

Кожна кінцева точка генерації приймає об’єкт 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 з тим самим значенням. Указане тут значення застосовується лише до цього виклику. Воно не впливає на інші виклики. Саме цей рівень використовують ваші інструменти: chat front end, скрипт, SDK wrapper або coding agent. Усі вони надсилають об’єкт options, незалежно від того, чи відображають вони окреме поле для нього.

Налаштуйте це для одного сеансу за допомогою параметра /set

У ollama run інтерактивний сеанс застосовує параметри до кінця цього сеансу:

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

/show parameters показує, що сеанс надішле з вашим наступним повідомленням. Це найшвидший спосіб перевірити, чи зміна набула чинності. Значення зберігається, доки ви не введете /bye. Щоб зберегти його, /save qwen3-capped записує поточний сеанс разом із параметрами як нову модель. Усе, що ви робите тут за допомогою /set, не передається жодному іншому клієнту.

Яке налаштування має перевагу і чому здається, що ваше ігнорується

Порядок простий. Параметри, передані разом із запитом, мають перевагу над усіма іншими. Рядок PARAMETER num_predict у Modelfile моделі використовується як резервне значення, якщо в запиті параметр не задано. Якщо не задано ні те, ні інше, застосовується вбудоване значення за замовчуванням Ollama.

/set parameter — це не третє правило. Інтерактивний сеанс є API-клієнтом, тому задане там значення надсилається як options цього запиту. Саме тому воно має перевагу над Modelfile протягом сеансу.

Тепер розглянемо проблему, яку це пояснює. Ви додаєте PARAMETER num_predict 512, перебудовуєте модель, але відповіді й далі містять тисячі токенів. Ваше налаштування присутнє, і 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 також приймає від’ємні значення, і вони є маркерами спеціальних станів, а не лічильниками. Одне від’ємне значення означає «не обмежувати це значення, продовжувати генерування». Інше означало «заповнити контекст, що залишився». Станом на August 2026 у довіднику Ollama Modelfile значенням за замовчуванням указано -1 — нескінченне генерування, а в попередніх версіях цієї самої таблиці також було вказано -2 для заповнення контексту.

Вважайте всі ці дані залежними від версії, оскільки вони змінювалися. У довіднику значенням за замовчуванням протягом тривалого часу було 128, доки запис не виправили наприкінці 2024 року, тому багато інструкцій досі містять старе число. Перегляньте довідник параметрів Modelfile для версії, яку ви фактично використовуєте, а потім перевірте поведінку за допомогою наведеної вище перевірки eval_count. Значення, яке ви перевірили на власному сервері, надійніше за значення, прочитане будь-де, зокрема в цій статті.

Чому довжина відповіді є основною витратою на VPS лише з CPU

Генерація має два етапи, які працюють із дуже різною швидкістю. Токени промпту обробляються пакетами, по багато за раз. Токени відповіді генеруються по одному, і для кожного потрібен повний прохід за вагами моделі. На VPS лише з CPU цей прохід обмежений пропускною здатністю пам’яті, тому один згенерований токен коштує значно дорожче за один токен промпту.

Запитайте відповідь без потокової передачі, і числа будуть безпосередньо перед вами:

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

Тривалості вказано в наносекундах. У цьому блоці, який є прикладом відповіді, опублікованим у документації Ollama API, а не вимірюванням на певному сервері, 26 токенів промпту оброблялися приблизно 0.1 секунди, тоді як 237 токенів відповіді — приблизно 4.3 секунди. Ваша власна швидкість генерації — це eval_count, поділене на eval_duration і переведене в секунди. Варто один раз виміряти кількість токенів за секунду на власному обладнанні, перш ніж налаштовувати щось інше. Ця швидкість залежить від моделі не менше, ніж від машини. Тому, якщо основна витрата припадає на довгі відповіді, модель, створена для швидкого декодування, наприклад Nemotron 3.5 Lightning на VPS, частково повертає час, який інакше захищав би низький ліміт.

Далі все визначає арифметика. За швидкості 8 токенів за секунду відповідь на 2,000 токенів утримує машину понад чотири хвилини, а модель не знає, що вам потрібен лише абзац. Деякі моделі також зациклюються й повторюють фразу, доки щось їх не зупинить. Без ліміту один такий запит займатиме ядро, доки не буде вичерпано контекстне вікно. num_predict — це параметр, який встановлює обмеження. Він особливо важливий на невеликому self-hosted Ollama VPS, де один довгий запит фактично займає всю машину.

Обрізаний вивід зазвичай означає досягнення ліміту, а не несправність моделі

Симптоми схожі на несправність моделі. Відповідь обривається посеред речення. JSON не розбирається, бо закривальна фігурна дужка так і не надійшла. Перша реакція — звинуватити модель або квантизацію. Спочатку прочитайте відповідь.

done_reason означає, що відповідь безпосередньо відповідає на запитання. stop означає, що модель завершила генерацію самостійно: видала токен кінця послідовності або знайшла один із рядків, указаних у параметрі stop. length означає, що генерацію перервано через нестачу доступного місця. Якщо бачите length, порівняйте eval_count з установленим лімітом: точний збіг означає, що генерацію зупинив num_predict, а менше значення — що спочатку заповнилося контекстне вікно.

Під час потокової передачі ці поля надходять в останньому фрагменті, який містить "done": true. Багато клієнтських бібліотек відкидають цей фрагмент і передають коду лише текст. Через це в застосунку таке саме обрізання виглядає незрозумілим, а в curl — очевидним. Якщо бібліотека приховує це поле, надішліть один запит із curl, щоб перевірити, що насправді повідомив сервер.

Є ще один момент, який допоможе не витрачати час даремно. Збільшення num_predict не змушує модель писати більше. Воно лише прибирає верхню межу. Якщо відповідь завершується на 200 токенах із done_reason, що має значення stop, модель вирішила, що завершила відповідь, і збільшення ліміту нічого не змінить. Короткі відповіді з stop означають проблему із запитом. Короткі відповіді з length означають проблему з лімітом.

Вибір значення

• Для інтерактивного чату залиште обмеження вимкненим і натисніть Ctrl+C, щоб зупинити відповідь, яка не завершується. Ви все одно стежите за екраном.
• Для будь-яких скриптів установлюйте обмеження. Генерація без обмеження всередині циклу може призвести до того, що пакетне завдання, яке мало виконуватися десять хвилин, працюватиме й наступного ранку.
• Для структурованого виводу встановіть обмеження вище за розмір найбільшого допустимого документа, який ви очікуєте. Потім вважайте done_reason зі length критичною помилкою та повторіть запит замість того, щоб аналізувати отриманий результат.
• Для coding agent значення має зберігатися у власній конфігурації агента, оскільки агент надсилає власні параметри в кожному запиті. У розділі Підключення coding agent до Ollama описано, де зберігаються ці налаштування.

Обмеження рахує токени, а не слова й не символи, тому не оцінюйте його приблизно. Згенеруйте одну репрезентативну відповідь без обмеження, перегляньте eval_count і встановіть ліміт із достатнім запасом. Різні сімейства моделей виконують токенізацію по-різному, тому значення, якого достатньо для моделі Llama, може обрізати ту саму відповідь від моделі Qwen 3 на тому самому VPS.

FAQ

У чому різниця між num_ctx і num_predict в Ollama?

num_ctx — це розмір контекстного вікна. Він визначає, скільки може прочитати модель: prompt і все, що вже було згенеровано. Це потребує пам’яті, оскільки key/value cache збільшується разом із ним. num_predict визначає, скільки токенів модель може записати в одній відповіді. Це потребує часу, а не додаткової пам’яті, і наперед нічого не резервується. Згенеровані токени враховуються в обох параметрах, тому відповідь може бути передчасно завершена через будь-який із них.

Чому здається, що моє значення num_predict ігнорується?

Тому що значення, надіслане в запиті, має вищий пріоритет за значення, збережене в моделі. Додайте PARAMETER num_predict 512 у Modelfile, потім використовуйте цю модель через chat front end або coding agent, і клієнт надішле власний об’єкт options, число в якому матиме пріоритет. ollama show --parameters все одно виведе ваше значення, оскільки читає збережену модель і не бачить, що надходить через HTTP. Надішліть один запит із curl, використовуючи "options": {"num_predict": 32}, і перевірте, що у відповіді eval_count має значення 32. Це підтвердить, що сам сервер працює правильно, і перенесе пошук причини до вашого застосунку.

Як визначити, що виведення було обрізане через num_predict?

Надішліть запит із "stream": false і прочитайте done_reason. Значення stop означає, що модель завершила роботу самостійно. Значення length означає, що доступне місце закінчилося. Потім порівняйте eval_count з установленим обмеженням: якщо значення точно збігаються, num_predict зупинив генерацію; якщо eval_count менше, спочатку заповнилося контекстне вікно. Під час streaming обидва поля надходять в останньому фрагменті разом із "done": true, який багато client library відкидають до того, як його побачить ваш код.

Яке значення num_predict використовується за замовчуванням?

Перевірте його у власній інсталяції, а не в сторонній статті. Станом на August 2026 у довіднику Ollama Modelfile значення за замовчуванням указано як -1, тобто генерація не має обмеження, а цей запис було виправлено наприкінці 2024 року після багатьох років документування 128. Від’ємні значення є sentinel-значеннями, а не лічильниками; у старіших версіях тієї самої таблиці також було вказано -2 для заповнення залишку контексту. Перевірте довідник параметрів Modelfile для своєї версії, а потім підтвердьте значення за допомогою ollama show --parameters і одного запиту curl.

Чи змусить збільшення num_predict модель генерувати довші відповіді?

Ні. Воно лише знімає верхнє обмеження. Якщо відповідь завершується з done_reason у stop, модель вирішила, що завершила роботу, і збільшення обмеження нічого не змінить. У такому разі довжина залежить від prompt: попросіть конкретну структуру, визначену кількість розділів або вказаний рівень деталізації. Збільшуйте num_predict лише тоді, коли done_reason повертає length.