Ollama मध्ये num_predict ने output लांबी कशी मर्यादित

Ollama मध्ये num_predict काय करते

num_predict हा Ollama पर्याय आहे. तो एका प्रतिसादात मॉडेल किती tokens तयार करू शकते याची कमाल मर्यादा ठरवतो. यात फक्त output tokens मोजले जातात. त्यामुळे prompt या मर्यादेत मोजला जात नाही. मॉडेल ही मर्यादा गाठल्यावर जिथे असेल तिथे generation थांबते. कधीकधी हे एखाद्या शब्दाच्या मध्यावरही घडते. त्यानंतर प्रतिसादात done_reason ची किंमत length अशी सेट केलेली असते.

या वैशिष्ट्याचे स्वरूप इतकेच आहे. अडचण अशी आहे की Ollama मध्ये ही किंमत सेट करण्यासाठी तीन स्वतंत्र ठिकाणे आहेत. विनंतीच्या सर्वात जवळची setting लागू होते. जवळपास प्रत्येक "num_predict does nothing" अहवालामागे एक layer दुसरी setting शांतपणे override करत असते.

num_predict हे num_ctx नाही

Ollama मधील इतर कोणत्याही पर्यायांपेक्षा या दोन पर्यायांमध्ये अधिक गोंधळ होतो आणि त्यामुळे debugging साठी लागणारा वास्तविक वेळ वाढतो.

num_ctx हे मॉडेल किती मजकूर वाचू शकते ते ठरवते. ही context window ची क्षमता आहे. त्यात prompt आणि आतापर्यंत तयार झालेला सर्व मजकूर असतो. ही क्षमता वाढवल्यास memory जास्त लागते, कारण त्या tokens साठी मॉडेल ठेवत असलेला key/value cache window सोबत वाढतो. तुमच्या hardware साठी num_ctx चे sizing हे स्वतंत्र काम आहे आणि त्याचे failure modes देखील स्वतंत्र आहेत.

num_predict हे मॉडेल किती मजकूर लिहील ते ठरवते. हा allocation नसून थांबण्याचा नियम आहे. ही मर्यादा वाढवल्यास RAM पेक्षा wall-clock time अधिक लागतो आणि आधीपासून कोणतेही memory reserve केले जात नाही.

हे दोन्ही एका ठिकाणी एकत्र येतात. Generated tokens तयार होताना context window मध्ये समाविष्ट होतात. त्यामुळे तुमची cap गाठल्यामुळे नव्हे, तर window भरल्यामुळेही reply थांबू शकतो. दोन्ही परिस्थितींमध्ये Ollama length नोंदवते. त्यामुळे या दोन परिस्थितींमधील फरक दाखवणारी संख्या eval_count आहे; तिचे पुढे अधिक स्पष्टीकरण दिले आहे.

Modelfile वापरून ते एकदाच सेट करा

Modelfile तुम्ही तयार करत असलेल्या model मध्ये हे मूल्य कायमचे समाविष्ट करते. फाइल लिहा:

FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 512

त्यानंतर model तयार करा आणि तयार केलेली व्याख्या पुन्हा वाचा:

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

ollama show --parameters साठवलेल्या प्रत्येक parameter साठी त्याचे मूल्य असलेली एक ओळ दाखवते. त्या output मध्ये num_predict नसल्यास, model मध्ये पूर्वनिश्चित कमाल मर्यादा नाही आणि Ollama चे स्वतःचे default लागू होते. ollama show --modelfile qwen3-capped संपूर्ण definition दाखवते. विद्यमान model सोबत आधीपासून आलेले parameters copy करण्याचा हा सर्वात जलद मार्ग आहे. अशा प्रकारे मर्यादित model तयार केल्याने जवळजवळ अतिरिक्त disk space लागत नाही, कारण नवीन entry base model ने आधीच download केलेले weight blobs पुन्हा वापरते; त्यांची प्रत बनवत नाही. VPS चा root disk भरून जाण्यापूर्वी Ollama हे blobs कुठे ठेवते हे जाणून घेणे उपयुक्त ठरते.

प्रत्येक caller ने वारशाने वापरावे असे मूल्य सेट करण्यासाठी हा योग्य स्तर आहे. मात्र हे अंतिम मूल्य असेल अशी अपेक्षा असल्यास हा चुकीचा स्तर आहे, कारण ते अंतिम नसते.

प्रत्येक विनंतीसाठी 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 वापरला जातो. येथे दिलेले मूल्य केवळ त्या एका call ला लागू होते; इतर कोणत्याही call ला लागू होत नाही. तुमची tools हीच layer वापरतात: chat front end, script, SDK wrapper किंवा coding agent. ते सर्व options object पाठवतात, त्या object साठी तुम्हाला स्वतंत्र box दिसत असो वा नसो.

एका सत्रासाठी /set parameter ने ते सेट करा

ollama run मध्ये interactive session त्या सत्राच्या उर्वरित कालावधीसाठी options सेट करते:

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

/show parameters तुमच्या पुढील message सोबत session काय पाठवेल ते दाखवते. त्यामुळे बदल लागू झाला आहे का हे तपासण्याचा हा सर्वात जलद मार्ग आहे. तुम्ही /bye टाइप करेपर्यंत ही value कायम राहते. ती जतन करण्यासाठी /save qwen3-capped सध्याचे session आणि त्यातील parameters यांचा नवीन model म्हणून लिखाण करते. तुम्ही येथे /set केलेली कोणतीही गोष्ट इतर client पर्यंत पोहोचत नाही.

कोणती setting लागू होते आणि तुमची setting दुर्लक्षित का दिसते

क्रम सोपा आहे. Request सोबत पाठवलेले options इतर सर्व settings वर प्राधान्य मिळवतात. Model च्या Modelfile मधील PARAMETER num_predict line ही request मध्ये value नसल्यास वापरली जाणारी fallback setting आहे. दोन्ही नसल्यास Ollama ची built-in default setting लागू होते.

/set parameter हा तिसरा नियम नाही. Interactive session हा API client असतो. त्यामुळे तेथे सेट केलेली value त्या request च्या options म्हणून पाठवली जाते. म्हणूनच ती session साठी Modelfile मधील setting override करते.

यामुळे स्पष्ट होणारी समस्या आता पाहू. तुम्ही PARAMETER num_predict 512 जोडता, model पुन्हा build करता, तरी replies हजारो tokens पर्यंत चालू राहतात. तुमची setting उपस्थित आहे, हे ollama show --parameters सिद्ध करते. मात्र प्रत्येक request वर ती override होत आहे, कारण client स्वतःचा options object पाठवतो. त्यात स्वतःची number असते. अनेकदा ही number तुम्ही काही महिन्यांपूर्वी settings screen मध्ये टाइप केलेली असते आणि नंतर विसरलेले असता. ollama show stored model वाचते. HTTP वरून प्रत्यक्षात काय आले, हे ती दाखवू शकत नाही.

एका command मध्ये server-side स्थिती सिद्ध करा. दीर्घ answer निर्माण होईल अशी request पाठवा, cap कमी ठेवा आणि दोन fields वाचा:

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 print झाले पाहिजेत. jq उपलब्ध नसल्यास प्रथम sudo apt install -y jq वापरून ते install करा. "length" आणि 32 असा response मिळाल्यास server ने option स्वीकारले आहे आणि तुमचे application वेगळी value पाठवत आहे. Request च्या server-side नोंदी पाहण्यासाठी environment मध्ये OLLAMA_DEBUG=1 सेट करून server restart करा आणि application त्याच्याशी संवाद साधत असताना journalctl -u ollama -f monitor करा.

नकारात्मक मूल्ये आणि कॉपी करू नयेत असे अंक

num_predict नकारात्मक मूल्येही स्वीकारतो. ही मूल्ये संख्या नसून sentinel म्हणून वापरली जातात. एका नकारात्मक मूल्याचा अर्थ “यावर मर्यादा घालू नका; निर्मिती सुरू ठेवू द्या” असा आहे. दुसऱ्या मूल्याचा अर्थ “उर्वरित context भरा” असा होता. August 2026 पर्यंत Ollama Modelfile reference मध्ये default म्हणून -1, म्हणजेच infinite generation, दिले आहे. याच तक्त्याच्या जुन्या आवृत्त्यांमध्ये context भरण्यासाठी -2 देखील दिले होते.

हे सर्व version-dependent समजा, कारण ही मूल्ये बदलली आहेत. Entry दुरुस्त होऊन 2024 च्या अखेरीस बदलण्यापूर्वी reference मध्ये default बराच काळ 128 असे दिले होते. त्यामुळे अनेक guides अजूनही जुना अंक वापरतात. तुम्ही प्रत्यक्ष चालवत असलेल्या version साठी Modelfile parameter reference वाचा. त्यानंतर वरील eval_count check वापरून वर्तनाची खात्री करा. स्वतःच्या box वर पडताळलेले मूल्य, या post मध्ये वाचलेल्या मूल्यासह इतर कुठेही वाचलेल्या मूल्यापेक्षा अधिक विश्वसनीय असते.

CPU-only VPS वर आउटपुटची लांबी हा मुख्य खर्च का आहे

Generation दोन टप्प्यांत होते आणि या दोन्ही टप्प्यांचा वेग लक्षणीयरीत्या वेगळा असतो. Prompt tokens चे मूल्यमापन batches मध्ये, एकावेळी अनेक tokens चे, केले जाते. Output tokens एकावेळी एक तयार केले जातात आणि प्रत्येक token साठी model weights वरून पूर्ण pass आवश्यक असतो. CPU-only VPS वर हा pass memory bandwidth मुळे मर्यादित असतो. त्यामुळे एका prompt token पेक्षा प्रत्येक generated token ची किंमत खूप जास्त असते. या pass मध्ये प्रत्येक weight वाचावा लागतो. त्यामुळे प्रत्येक weight ने व्यापलेल्या bytes ची संख्या तुमच्या token rate ची कमाल मर्यादा ठरवते. म्हणूनच त्याच model च्या q8 किंवा fp16 आवृत्तीपेक्षा q4 build जलद decode होते.

Streaming शिवाय response मागितल्यास आकडे थेट दिसतात:

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

कालावधी nanoseconds मध्ये आहेत. त्या block मध्ये, जो कोणत्याही विशिष्ट server वरील measurement नसून Ollama API documentation मध्ये प्रकाशित केलेला sample response आहे, 26 prompt tokens साठी सुमारे 0.1 seconds लागले, तर 237 output tokens साठी सुमारे 4.3 seconds लागले. तुमचा स्वतःचा generation rate म्हणजे eval_count ला eval_duration ने भागून seconds मध्ये रूपांतरित केलेले मूल्य. तुमच्या स्वतःच्या hardware वर tokens per second मोजणे इतर कोणतेही tuning करण्यापूर्वी एकदा करणे उपयुक्त ठरते. हा rate machine इतकाच model वरही अवलंबून असतो. त्यामुळे मोठी उत्तरे हा खरा खर्च असेल, तर VPS वर Nemotron 3.5 Lightning सारखा fast decoding साठी तयार केलेला model, कमी cap मुळे वाचणारा काही वेळ परत मिळवून देतो.

उरलेली गणना सोपी आहे. 8 tokens per second या वेगाने 2,000 tokens चे उत्तर machine ला चार minutes पेक्षा जास्त वेळ व्यस्त ठेवते. तुम्हाला फक्त एक paragraph हवा होता याची model ला कल्पना नसते. Reasoning model तुम्ही मागितलेला शब्द लिहिण्यापूर्वी त्याच्या budget मधील काही भाग विचार करण्यासाठी वापरतो. हे thinking देखील इतर सर्व गोष्टींप्रमाणे एकावेळी एक token तयार करूनच होते. त्यामुळे तुम्ही मागितलेला reasoning effort हा त्याच bill वर परिणाम करणारा आणखी एक घटक आहे. काही models एखादी गोष्ट त्यांना थांबवणारे कारण मिळेपर्यंत पुन्हा पुन्हा लिहितात. Cap नसल्यास context window संपेपर्यंत ती एक request एक CPU core व्यस्त ठेवते. num_predict ही त्याची मर्यादा ठरवणारी setting आहे. एका छोट्या self-hosted Ollama VPS वर एकच लांब request संपूर्ण machine व्यस्त ठेवू शकते, त्यामुळे ही setting विशेष महत्त्वाची आहे.

Truncated output बहुतेक वेळा मर्यादा असते, बिघडलेले model नाही

ही लक्षणे model मध्ये बिघाड झाल्यासारखी दिसतात. उत्तर वाक्याच्या मध्यावर थांबते. शेवटचा brace न आल्यामुळे JSON parse होत नाही. लगेच model किंवा quantisation ला दोष दिला जातो. आधी response वाचा.

done_reason म्हणजे उत्तराने प्रश्नाला थेट उत्तर दिले. stop म्हणजे model ने स्वतःहून पूर्ण केले; त्याने end-of-sequence token दिला किंवा तुमच्या stop option मधील एखाद्या string शी जुळले. length म्हणजे जागा संपल्यामुळे generation मध्येच थांबले. length दिसल्यास eval_count ची तुलना तुमच्या cap शी करा: दोन्ही तंतोतंत समान असतील, तर num_predict मुळे ते थांबले; त्यापेक्षा छोटी संख्या असेल, तर context window आधी भरली.

तुम्ही stream वापरत असल्यास, हे fields अंतिम chunk मध्ये येतात; त्यात "done": true असते. अनेक client libraries हा chunk discard करतात आणि तुमच्या code ला फक्त text देतात. त्यामुळे application मध्ये तेच truncation कारण नसल्यासारखे दिसते, तर curl अंतर्गत ते स्पष्ट दिसते. एखादी library हे लपवत असल्यास, server ने प्रत्यक्षात काय सांगितले हे पाहण्यासाठी curl सह एक request पाठवा.

आणखी एक मुद्दा लक्षात ठेवल्यास वेळ वाया जाणे टाळता येते. num_predict वाढवल्याने model अधिक लिहित नाही. त्यामुळे फक्त कमाल मर्यादा काढली जाते. done_reason च्या stop सह reply 200 tokens वर संपत असेल, तर model ने ते पूर्ण झाले असे ठरवले आहे आणि मोठी cap केल्याने काहीही बदलणार नाही. stop असलेली लहान उत्तरे ही prompting ची समस्या आहे. length असलेली लहान उत्तरे ही cap ची समस्या आहे.

मूल्य निवडणे

• परस्परसंवादी चॅटसाठी कमाल मर्यादा ठेवू नका आणि अनियंत्रित उत्तर थांबवण्यासाठी Ctrl+C दाबा. तुम्ही स्क्रीनवर लक्ष ठेवत असता.
• स्क्रिप्टद्वारे चालणाऱ्या कोणत्याही प्रक्रियेसाठी ही मर्यादा सेट करा. कमाल मर्यादा नसलेली generation loop मध्ये चालवल्यास दहा मिनिटांत पूर्ण होणारे batch job दुसऱ्या दिवशी सकाळीही सुरू राहू शकते.
• संरचित output साठी, अपेक्षित सर्वात मोठ्या वैध document पेक्षा ही मर्यादा जास्त ठेवा. त्यानंतर done_reason पैकी length आल्यास ते hard error समजा आणि परत आलेले output parse करण्याऐवजी पुन्हा प्रयत्न करा.
• coding agent साठी हे मूल्य agent च्याच configuration मध्ये ठेवा, कारण प्रत्येक request वेळी agent स्वतःचे options पाठवतो. coding agent ला Ollama कडे निर्देशित करणे येथे ही settings कुठे असतात ते स्पष्ट केले आहे.

ही मर्यादा words किंवा characters नव्हे, तर tokens मोजते. त्यामुळे तिचा अंदाज लावू नका. कमाल मर्यादा न ठेवता एक प्रतिनिधिक answer generate करा, eval_count वाचा आणि limit त्यापेक्षा पुरेशी जास्त ठेवा. वेगवेगळ्या model families मध्ये tokenisation वेगळी असते. त्यामुळे Llama model साठी योग्य असलेले मूल्य त्याच VPS वरील Qwen 3 model कडून मिळणारे तेच answer truncate करू शकते.

FAQ

num_ctx आणि num_predict यांच्यात Ollama मध्ये काय फरक आहे?

num_ctx ही context window ची लांबी आहे. त्यामुळे मॉडेल किती मजकूर वाचू शकते हे ती ठरवते: prompt आणि आतापर्यंत तयार झालेला सर्व मजकूर. यासाठी memory लागते, कारण key/value cache तिच्यासोबत वाढतो. num_predict एका response मध्ये मॉडेल किती tokens लिहू शकते हे ठरवते. यासाठी memory पेक्षा time लागतो आणि काहीही आधीच आरक्षित केले जात नाही. Generated tokens ची गणना दोन्ही मर्यादांमध्ये होते. त्यामुळे कोणत्याही एका मर्यादेमुळे reply मध्येच थांबू शकतो.

माझी num_predict setting दुर्लक्षित केली जात आहे असे का वाटते?

कारण request सोबत पाठवलेली value मॉडेलमध्ये साठवलेल्या value वर override करते. Modelfile मध्ये PARAMETER num_predict 512 ठेवा. त्यानंतर त्या मॉडेलचा वापर chat front end किंवा coding agent मधून करा. अशा वेळी client स्वतःचा options object पाठवतो आणि त्यातील number लागू होतो. ollama show --parameters तरीही तुमची value दाखवते, कारण ते stored model वाचते आणि HTTP वरून आलेली value पाहू शकत नाही. "options": {"num_predict": 32} वापरून curl असलेली एक request पाठवा आणि eval_count ची value 32 परत येते का ते तपासा. यामुळे server स्वतः योग्य प्रकारे कार्य करत असल्याची खात्री होते आणि तपास application कडे वळवता येतो.

माझे output num_predict मुळे मध्येच थांबले आहे का हे कसे ओळखावे?

"stream": false सह request पाठवा आणि done_reason वाचा. stop ची value म्हणजे मॉडेल स्वतःहून पूर्ण झाले. length ची value म्हणजे उपलब्ध जागा संपली. त्यानंतर eval_count ची तुलना तुमच्या cap सोबत करा. दोन्ही अगदी समान असल्यास num_predict मुळे output थांबले. eval_count लहान असल्यास context window आधी भरली. Streaming दरम्यान दोन्ही fields अंतिम chunk मध्ये "done": true सह येतात. अनेक client libraries तुमच्या code पर्यंत पोहोचण्यापूर्वी हा भाग काढून टाकतात.

num_predict ची default value काय आहे?

एखाद्या लेखाऐवजी ती तुमच्या स्वतःच्या install मधून वाचा. August 2026 पर्यंत Ollama Modelfile reference मध्ये default म्हणून -1 दिले आहे. याचा अर्थ generation वर मर्यादा नाही. अनेक वर्षे 128 दस्तऐवजीकरण केल्यानंतर 2024 च्या अखेरीस ती entry दुरुस्त करण्यात आली. Negative values या counts नसून sentinels आहेत. याच table च्या जुन्या versions मध्ये उरलेली context भरण्यासाठी -2 देखील दिले होते. तुमच्या version साठी Modelfile parameter reference तपासा. त्यानंतर ollama show --parameters आणि एक curl request वापरून ते निश्चित करा.

num_predict वाढवल्याने मॉडेल अधिक लांब answers लिहिते का?

नाही. यामुळे फक्त कमाल मर्यादा दूर होते. reply done_reason of stop सह संपत असेल, तर मॉडेलने ते पूर्ण झाले असे ठरवले आहे आणि मोठी cap बदल घडवून आणत नाही. अशा वेळी लांबी हा prompting चा प्रश्न आहे. विशिष्ट structure, section count किंवा अपेक्षित detail level मागा. done_reason ची value length परत येते तेव्हाच num_predict वाढवा.