Ollama में num_predict का उपयोग कैसे करें

Ollama में num_predict क्या करता है

num_predict वह Ollama विकल्प है जो यह सीमित करता है कि एक response में model अधिकतम कितने tokens generate कर सकता है। यह केवल output tokens की गणना करता है, इसलिए prompt को इसमें शामिल नहीं किया जाता है। जब model इस सीमा तक पहुँच जाता है, तो generation वहीं रुक जाता है, कभी-कभी शब्द के बीच में ही, और response में done_reason का मान length सेट होकर आता है।

यह पूरी सुविधा बस इतनी ही है। कठिनाई यह है कि Ollama आपको यह मान सेट करने के लिए तीन अलग-अलग स्थान देता है, और request के सबसे करीब वाली सेटिंग प्रभावी होती है। लगभग हर "num_predict काम नहीं कर रहा है" वाली रिपोर्ट का कारण यही होता है कि एक लेयर चुपचाप दूसरी को override कर रही होती है।

num_predict और num_ctx एक समान नहीं हैं

Ollama में इन दो विकल्पों के बीच सबसे अधिक भ्रम होता है, और यह भ्रम वास्तविक डिबगिंग में समय की बर्बादी का कारण बनता है।

num_ctx यह निर्धारित करता है कि मॉडल कितना पढ़ सकता है। यह context window का आकार है, जिसमें prompt और अब तक उत्पन्न की गई सभी सामग्री शामिल होती है। इसे बढ़ाने से memory की खपत बढ़ती है, क्योंकि उन tokens के लिए मॉडल द्वारा रखा गया key/value cache विंडो के साथ बढ़ता जाता है। अपने हार्डवेयर के लिए num_ctx का आकार निर्धारित करना एक अलग कार्य है जिसके अपने विफलता के कारण (failure modes) हैं।

num_predict यह निर्धारित करता है कि मॉडल कितना लिखेगा। यह एक stopping rule है, न कि कोई allocation। इसे बढ़ाने से RAM के बजाय wall-clock time की खपत होती है, और पहले से कुछ भी आरक्षित (reserve) नहीं किया जाता है।

ये दोनों एक बिंदु पर मिलते हैं। उत्पन्न किए गए tokens जैसे-जैसे बनते हैं, वे context window के अंदर आते जाते हैं, इसलिए कोई उत्तर इसलिए भी रुक सकता है क्योंकि विंडो भर गई है, न कि इसलिए कि आपकी सीमा (cap) पूरी हो गई है। Ollama दोनों ही स्थितियों में length की रिपोर्ट करता है, इसलिए वह संख्या जो उन्हें अलग करती है वह eval_count है, जिसे आगे विस्तार से समझाया गया है।

Modelfile के साथ इसे एक बार सेट करें

Modelfile इस मान को आपके द्वारा बनाए गए मॉडल में समाहित (bake) कर देता है। फाइल लिखें:

FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 512

फिर इसे build करें और जो आपने बनाया है उसे पढ़ें:

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

ollama show --parameters प्रत्येक संग्रहीत पैरामीटर को उसके मान के साथ एक पंक्ति में प्रिंट करता है। यदि उस आउटपुट में num_predict मौजूद नहीं है, तो मॉडल में कोई भी मान पहले से सेट नहीं है और Ollama का अपना डिफ़ॉल्ट मान लागू होता है। ollama show --modelfile qwen3-capped पूरी परिभाषा को प्रिंट करता है, जो किसी मौजूदा मॉडल के साथ आने वाले पैरामीटर्स को कॉपी करने का सबसे तेज़ तरीका भी है।

यह उस मान के लिए सही स्तर है जिसे आप चाहते हैं कि हर caller inherit करे। यदि आप अपेक्षा करते हैं कि यह अंतिम (final) मान होगा, तो यह गलत स्तर है, क्योंकि ऐसा नहीं है।

इसे 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 पर लागू होता है और किसी अन्य पर नहीं। यह वह layer है जिसका उपयोग आपके tools करते हैं: एक chat front end, एक script, एक SDK wrapper, या एक coding agent। वे सभी एक options object भेजते हैं, चाहे वे आपको इसके लिए कोई box दिखाएं या न दिखाएं।

/set पैरामीटर के साथ इसे एक session के लिए सेट करें

ollama run के अंदर, interactive session उस session के बाकी हिस्से के लिए विकल्प सेट करता है:

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

/show parameters यह print करता है कि session आपके अगले message के साथ क्या भेजेगा, जो यह पुष्टि करने का सबसे तेज़ तरीका है कि बदलाव प्रभावी हो गया है। यह value तब तक रहती है जब तक आप /bye टाइप नहीं करते। इसे सुरक्षित रखने के लिए, /save qwen3-capped वर्तमान session को, parameters सहित, एक नए model के रूप में लिखता है। यहाँ आपके द्वारा /set की गई कोई भी चीज़ किसी अन्य client तक नहीं पहुँचती है।

कौन सी सेटिंग प्रभावी होती है, और आपकी सेटिंग अनदेखी क्यों लगती है

क्रम छोटा है। अनुरोध (request) के साथ भेजी गई सेटिंग्स सबसे ऊपर होती हैं। Modelfile में मौजूद PARAMETER num_predict लाइन का उपयोग तब किया जाता है जब अनुरोध में कोई मान (value) न हो। यदि दोनों न हों, तो 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 ऋणात्मक मानों को भी स्वीकार करता है, और ये गणना के बजाय संकेत (sentinels) होते हैं। एक ऋणात्मक मान का अर्थ है "इसे सीमित न करें, जनरेट करना जारी रखें"। एक अन्य का अर्थ "शेष संदर्भ (context) को भरना" रहा है। अगस्त 2026 तक, Ollama Modelfile संदर्भ डिफ़ॉल्ट को -1 बताता है, जिसका अर्थ है अनंत जनरेशन, और उसी तालिका के पुराने संस्करणों में संदर्भ भरने के लिए -2 भी सूचीबद्ध था।

इन सभी को संस्करण-निर्भर मानें, क्योंकि इनमें बदलाव होते रहे हैं। संदर्भ में लंबे समय तक डिफ़ॉल्ट को 128 प्रलेखित किया गया था, इससे पहले कि 2024 के अंत में प्रविष्टि को सुधारा गया, इसलिए कई गाइड अभी भी पुरानी संख्या को दोहराते हैं। जिस संस्करण को आप वास्तव में चला रहे हैं, उसके लिए Modelfile parameter reference पढ़ें, फिर ऊपर दिए गए eval_count चेक के साथ व्यवहार की पुष्टि करें। आपके द्वारा अपने सिस्टम पर सत्यापित किया गया मान, कहीं भी पढ़े गए मान से बेहतर है, जिसमें यह पोस्ट भी शामिल है।

CPU-only VPS पर आउटपुट की लंबाई मुख्य लागत क्यों है

जेनरेशन दो चरणों में होती है और दोनों की गति बहुत अलग होती है। प्रॉम्प्ट टोकन्स का मूल्यांकन बैच में, एक साथ कई टोकन्स के रूप में किया जाता है। आउटपुट टोकन्स एक-एक करके तैयार किए जाते हैं, और प्रत्येक टोकन के लिए मॉडल वेट्स (model weights) पर एक पूर्ण पास की आवश्यकता होती है। CPU-only VPS पर वह पास मेमोरी बैंडविड्थ द्वारा सीमित होता है, इसलिए एक जनरेट किए गए टोकन की लागत एक प्रॉम्प्ट टोकन की तुलना में कहीं अधिक होती है।

यदि आप बिना स्ट्रीमिंग के रिस्पॉन्स मांगते हैं, तो आंकड़े स्पष्ट हो जाते हैं:

"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 से विभाजित करके और उसे सेकंड में बदलकर प्राप्त की जाती है, और किसी भी अन्य चीज़ को ट्यून करने से पहले अपने हार्डवेयर पर टोकन्स प्रति सेकंड मापना एक बार जरूर कर लेना चाहिए। वह दर मशीन के साथ-साथ मॉडल पर भी निर्भर करती है, इसलिए यदि लंबे उत्तर वास्तविक लागत हैं, तो VPS पर Nemotron 3.5 Lightning जैसे तेज़ डिकोडिंग के लिए बनाए गए मॉडल उस समय को वापस पा सकते हैं जिसे कम कैप (low cap) अन्यथा सुरक्षित रखता है।

बाकी काम गणित करता है। 8 टोकन्स प्रति सेकंड की दर से, 2,000 टोकन का उत्तर मशीन को चार मिनट से अधिक समय तक व्यस्त रखता है, और मॉडल को यह पता नहीं होता कि आप केवल एक पैराग्राफ चाहते थे। कुछ मॉडल लूप भी करते हैं, और किसी चीज़ के रुकने तक एक ही वाक्यांश को दोहराते रहते हैं। बिना किसी कैप के, वह एक अनुरोध तब तक कोर को व्यस्त रखता है जब तक कि कॉन्टेक्स्ट विंडो समाप्त न हो जाए। num_predict वह सेटिंग है जो इसे सीमित करती है, जो एक छोटे self-hosted Ollama VPS पर सबसे अधिक मायने रखती है जहाँ एक लंबा अनुरोध पूरी मशीन को घेर लेता है।

Truncated output आमतौर पर cap के कारण होता है, न कि broken model के कारण

लक्षण model failure जैसे दिखते हैं। एक उत्तर जो वाक्य के बीच में रुक जाता है। JSON जो parse नहीं होगा, क्योंकि closing brace कभी नहीं आया। स्वाभाविक प्रतिक्रिया model या quantisation को दोष देने की होती है। पहले response को पढ़ें।

done_reason सीधे प्रश्न का उत्तर देता है। stop का अर्थ है कि model ने अपने आप काम पूरा कर लिया है, या तो अपना end-of-sequence token emit करके या आपके stop option में दी गई strings में से किसी एक से मेल खाकर। length का अर्थ है कि generation को काट दिया गया क्योंकि जगह खत्म हो गई थी। जब आप length देखते हैं, तो eval_count की तुलना अपने cap से करें: सटीक मेल का अर्थ है कि num_predict ने इसे रोक दिया, और छोटी संख्या का अर्थ है कि context window पहले भर गई थी।

जब आप stream करते हैं, तो वे fields अंतिम chunk में आते हैं, जो "done": true को ले जाता है। कई client libraries उस chunk को discard कर देती हैं और आपके code को केवल text देती हैं, यही कारण है कि वही truncation एक application के अंदर अस्पष्ट दिखता है और curl के तहत स्पष्ट। यदि कोई library इसे छिपा रही है, तो यह जानने के लिए कि server ने वास्तव में क्या कहा, curl के साथ एक request भेजें।

एक और बिंदु एक बर्बाद दोपहर को बचा सकता है। num_predict को बढ़ाने से model ज्यादा नहीं लिखता। यह केवल एक ceiling को हटाता है। यदि कोई reply stop के done_reason के साथ 200 tokens पर समाप्त होता है, तो model ने तय किया कि वह पूरा हो गया है, और एक बड़ा cap कुछ भी नहीं बदलेगा। stop के साथ छोटे उत्तर एक prompting समस्या हैं। length के साथ छोटे उत्तर एक cap समस्या हैं।

मान चुनना

• इंटरैक्टिव चैट के लिए, इसे अनकैप्ड (uncapped) छोड़ दें और अनियंत्रित उत्तर को रोकने के लिए Ctrl+C दबाएं। आप वैसे भी स्क्रीन देख रहे होते हैं।
• स्क्रिप्टेड कार्यों के लिए, इसे सेट करें। लूप के अंदर अनकैप्ड जनरेशन का मतलब है कि एक बैच जॉब जिसे दस मिनट में पूरा होना चाहिए था, वह अगली सुबह भी चल रहा है।
• स्ट्रक्चर्ड आउटपुट के लिए, कैप को अपने द्वारा अपेक्षित सबसे बड़े वैध दस्तावेज़ से ऊपर सेट करें, फिर done_reason के length को एक हार्ड एरर मानें और वापस आए डेटा को पार्स करने के बजाय पुनः प्रयास करें।
• कोडिंग एजेंट के लिए, यह मान एजेंट के अपने कॉन्फ़िगरेशन में होना चाहिए, क्योंकि एजेंट हर अनुरोध पर अपने स्वयं के विकल्प भेजता है। Ollama पर कोडिंग एजेंट को पॉइंट करना बताता है कि ये सेटिंग्स कहाँ रहती हैं।

कैप टोकन की गिनती करता है, न कि शब्दों या वर्णों की, इसलिए इसका अनुमान न लगाएं। बिना किसी कैप के एक प्रतिनिधि उत्तर जनरेट करें, eval_count पढ़ें, और सीमा को उससे थोड़ा ऊपर सेट करें। मॉडल परिवार अलग-अलग तरह से टोकनाइज़ करते हैं, इसलिए जो मान Llama मॉडल के लिए उपयुक्त है, वह उसी VPS पर Qwen 3 मॉडल के समान उत्तर को काट (truncate) सकता है।

FAQ

Ollama में num_ctx और num_predict के बीच क्या अंतर है?

num_ctx कॉन्टेक्स्ट विंडो का आकार है, जो यह निर्धारित करता है कि मॉडल कितना पढ़ सकता है: इसमें प्रॉम्प्ट और अब तक उत्पन्न की गई सभी सामग्री शामिल है। यह मेमोरी का उपयोग करता है, क्योंकि इसके साथ key/value cache बढ़ता है। num_predict यह निर्धारित करता है कि मॉडल एक प्रतिक्रिया में कितने टोकन लिख सकता है। यह मेमोरी के बजाय समय का उपयोग करता है, और इसके लिए पहले से कुछ भी आरक्षित नहीं किया जाता है। उत्पन्न टोकन दोनों सीमाओं में गिने जाते हैं, इसलिए किसी भी एक सीमा के कारण उत्तर बीच में कट सकता है।

मेरी num_predict सेटिंग को अनदेखा क्यों किया जा रहा है?

क्योंकि अनुरोध के साथ भेजा गया मान मॉडल में संग्रहीत मान को ओवरराइड कर देता है। Modelfile में PARAMETER num_predict 512 सेट करें, फिर उस मॉडल को चैट फ्रंट-एंड या कोडिंग एजेंट से चलाएं, तो क्लाइंट अपना स्वयं का options ऑब्जेक्ट भेजता है जिसका मान प्रभावी होता है। ollama show --parameters अभी भी आपके मान को प्रिंट करता है, क्योंकि यह संग्रहीत मॉडल को पढ़ता है और यह नहीं देख सकता कि HTTP के माध्यम से क्या आ रहा है। "options": {"num_predict": 32} का उपयोग करके curl के साथ एक अनुरोध भेजें और जांचें कि क्या eval_count 32 के रूप में वापस आता है, जो यह पुष्टि करता है कि सर्वर सही ढंग से काम कर रहा है और समस्या आपके एप्लिकेशन में है।

मैं यह कैसे पता लगाऊं कि मेरा आउटपुट num_predict द्वारा काटा गया है?

अनुरोध को "stream": false के साथ भेजें और done_reason को पढ़ें। stop का मान यह दर्शाता है कि मॉडल ने स्वयं अपना कार्य पूरा कर लिया है। length का मान यह दर्शाता है कि मॉडल के पास जगह समाप्त हो गई है। फिर eval_count की तुलना अपनी सीमा से करें: यदि वे बिल्कुल मेल खाते हैं, तो num_predict ने इसे रोक दिया है, और यदि eval_count छोटा है, तो कॉन्टेक्स्ट विंडो पहले भर गई थी। स्ट्रीमिंग के दौरान, दोनों फ़ील्ड अंतिम चंक में "done": true के साथ आते हैं, जिसे कई क्लाइंट लाइब्रेरी आपके कोड तक पहुँचने से पहले ही हटा देती हैं।

num_predict का डिफ़ॉल्ट मान क्या है?

इसे किसी लेख के बजाय अपने स्वयं के इंस्टॉलेशन से पढ़ें। अगस्त 2026 तक, Ollama Modelfile संदर्भ डिफ़ॉल्ट मान को -1 बताता है, जिसका अर्थ है कि जनरेशन पर कोई सीमा नहीं है, और इस प्रविष्टि को 2024 के अंत में वर्षों तक 128 के दस्तावेजीकरण के बाद सुधारा गया था। ऋणात्मक मान गणना के बजाय संकेत (sentinels) होते हैं, और उसी तालिका के पुराने संस्करणों में शेष कॉन्टेक्स्ट को भरने के लिए -2 भी सूचीबद्ध था। अपने संस्करण के लिए Modelfile parameter reference देखें, फिर ollama show --parameters और एक curl अनुरोध के साथ इसकी पुष्टि करें।

क्या num_predict बढ़ाने से मॉडल लंबे उत्तर लिखता है?

नहीं। यह केवल एक ऊपरी सीमा को हटाता है। यदि कोई उत्तर stop में से done_reason पर समाप्त होता है, तो मॉडल ने निर्णय लिया है कि वह पूरा हो गया है, और बड़ी सीमा से कुछ नहीं बदलेगा। उस स्थिति में लंबाई एक प्रॉम्प्टिंग का प्रश्न है: एक विशिष्ट संरचना, अनुभागों की संख्या, या विवरण के एक निर्धारित स्तर के लिए कहें। num_predict को केवल तभी बढ़ाएं जब done_reason का मान length के रूप में वापस आए।