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

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

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

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

num_predict हे num_ctx नाही

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

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

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

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

Modelfile द्वारे ते एकदाच सेट करा

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

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 करण्याचा हा सर्वात जलद मार्ग आहे.

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

विनंतीनुसार options object मध्ये ते सेट करा

प्रत्येक generation endpoint options object स्वीकारतो आणि त्यामध्ये 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 पाठवतो, जरी त्यामध्ये त्यासाठीचे box दिसत नसले तरी.

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

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

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

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

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

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

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

यामुळे स्पष्ट होणारे failure आता पाहू. तुम्ही 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 द्वारे प्रत्यक्ष येणारी value ती दाखवू शकत नाही.

Server-side वर्तन एका command ने सिद्ध करा. दीर्घ answer निर्माण होईल अशी request पाठवा, cap कमी value वर force करा आणि दोन 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 स्वतः काय नोंदवतो हे पाहण्यासाठी environment मध्ये OLLAMA_DEBUG=1 देऊन तो पुन्हा सुरू करा आणि application त्याच्याशी संवाद साधत असताना journalctl -u ollama -f monitor करा.

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

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

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

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

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

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

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

कालावधी nanoseconds मध्ये आहेत. या block मध्ये Ollama API documentation मध्ये प्रकाशित केलेला sample response आहे; तो कोणत्याही विशिष्ट server वरील measurement नाही. त्यात 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 वरही अवलंबून असतो. त्यामुळे मोठी उत्तरे हाच खरा खर्च असेल, तर fast decoding साठी तयार केलेला VPS वरील Nemotron 3.5 Lightning low cap मुळे वाचणारा काही वेळ परत मिळवून देऊ शकतो.

उरलेली गणना सरळ आहे. 8 tokens per second या वेगाने 2,000 tokens चे उत्तर machine चार मिनिटांपेक्षा जास्त काळ व्यस्त ठेवते. Model ला तुम्हाला फक्त एक paragraph हवा होता याची माहिती नसते. काही models एखादी phrase थांबवणारी गोष्ट येईपर्यंत ती पुन्हा पुन्हा लिहितात. कोणताही cap नसल्यास context window संपेपर्यंत ती एकच request core व्यस्त ठेवते. num_predict ही मर्यादा ठरवणारी setting आहे. एका छोट्या self-hosted Ollama VPS वर एक लांब request संपूर्ण machine चा वापर करू शकत असल्यामुळे ही setting विशेष महत्त्वाची ठरते.

छाटलेले आउटपुट सहसा मर्यादा संपल्यामुळे येते; मॉडेल बिघडलेले नसते

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

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

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

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

मूल्य निवडणे

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

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

FAQ

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

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

माझी num_predict setting दुर्लक्षित होत असल्यासारखी का दिसते?

कारण request सोबत पाठवलेली value model मध्ये साठवलेल्या value वर override करते. Modelfile मध्ये PARAMETER num_predict 512 ठेवा. त्यानंतर त्या model ला 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 असल्यास model स्वतःहून पूर्ण झाले आहे. length ची value असल्यास उपलब्ध मर्यादा संपली आहे. त्यानंतर eval_count ची तुलना तुमच्या cap सोबत करा. दोन्ही अगदी समान असल्यास num_predict मुळे output थांबले. eval_count लहान असल्यास context window आधी भरली. Streaming करताना दोन्ही fields अंतिम chunk मध्ये "done": true सोबत येतात. तुमच्या code पर्यंत पोहोचण्यापूर्वी अनेक client libraries हा भाग काढून टाकतात.

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

Article वर अवलंबून राहण्याऐवजी ती तुमच्या स्वतःच्या 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 वाढवल्याने model अधिक लांब answers लिहितो का?

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