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

Що робить num_predict в Ollama

num_predict — це параметр Ollama, який обмежує кількість токенів, що модель може згенерувати в одній відповіді. Він враховує лише вихідні токени, тому prompt не враховується в цьому обмеженні. Коли модель досягає ліміту, генерація зупиняється на поточному місці, іноді посеред слова, а відповідь повертається зі значенням 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 виводить повне визначення моделі. Це також найшвидший спосіб скопіювати параметри, з якими вже постачається наявна модель. Створення моделі з обмеженням у такий спосіб майже не потребує додаткового дискового простору, оскільки новий запис повторно використовує блоби вагових даних, які базова модель уже завантажила, замість їх копіювання. Перед заповненням root-диска VPS варто знати де Ollama зберігає ці блоби.

Це правильний рівень для значення, яке мають успадковувати всі виклики. Але це неправильний рівень, якщо ви очікуєте, що значення буде остаточним, оскільки це не так.

Установлюйте це для кожного запиту в об’єкті параметрів

Кожна кінцева точка генерації приймає об’єкт 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 або 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

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

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

"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 токенів займає машину більш ніж на 4 хвилини, а модель не знає, що вам був потрібен лише абзац. Модель із міркуваннями витрачає частину цього бюджету на обдумування, перш ніж записати запитане слово. Це міркування також генерується по одному токену, як і все інше. Тому рівень міркувань, який ви запитуєте, є ще одним параметром, що впливає на ту саму витрату. Деякі моделі також зациклюються та повторюють фразу, доки щось їх не зупинить. Без ліміту один такий запит утримує ядро зайнятим, доки не буде вичерпано контекстне вікно. num_predict — це параметр, який встановлює таку межу. Він особливо важливий на невеликому self-hosted Ollama VPS, де один довгий запит може зайняти всю машину.

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

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

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

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

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

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

• Для інтерактивного чату залиште ліміт необмеженим і натискайте Ctrl+C, щоб зупинити відповідь, яка вийшла з-під контролю. Ви все одно стежите за екраном.
• Для всього, що виконується у скриптах, установіть ліміт. Необмежена генерація всередині циклу може призвести до того, що пакетне завдання, яке мало тривати десять хвилин, працюватиме й наступного ранку.
• Для структурованого виводу встановіть ліміт вище за найбільший очікуваний коректний документ. Потім вважайте done_reason із length критичною помилкою та повторюйте запит замість того, щоб аналізувати отриманий результат.
• Для coding agent значення має бути в його власній конфігурації, оскільки 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 менше, спочатку було заповнено контекстне вікно. Під час потокової передачі обидва поля надходять в останньому фрагменті з "done": true. Багато клієнтських бібліотек відкидають цей фрагмент до того, як його отримує ваш код.

Яке значення 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.