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

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

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

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

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

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

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

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

ये दोनों एक जगह मिलते हैं। उत्पन्न टोकन जैसे-जैसे बनते हैं, वे कॉन्टेक्स्ट विंडो के अंदर आते जाते हैं, इसलिए उत्तर विंडो भर जाने के कारण भी रुक सकता है, न कि केवल आपकी सीमा तक पहुँचने के कारण। Ollama दोनों ही स्थितियों में length की रिपोर्ट करता है, इसलिए जो संख्या उन्हें अलग करती है वह eval_count है, जिसे आगे विस्तार से समझाया गया है।

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

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

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 मौजूद नहीं है, तो मॉडल में कोई पूर्व-निर्धारित सीमा (cap) नहीं है और Ollama का अपना डिफ़ॉल्ट मान लागू होता है। ollama show --modelfile qwen3-capped संपूर्ण परिभाषा को प्रिंट करता है, जो किसी मौजूदा मॉडल के पैरामीटर्स को कॉपी करने का सबसे तेज़ तरीका भी है। इस तरह से सीमित मॉडल बनाने में डिस्क स्पेस लगभग खर्च नहीं होता, क्योंकि नई प्रविष्टि बेस मॉडल द्वारा पहले से डाउनलोड की गई weight blobs का पुन: उपयोग करती है, उन्हें कॉपी नहीं करती। Ollama इन blobs को कहाँ रखता है यह जानना तब उपयोगी होता है जब VPS की root disk भरने वाली हो।

यह उस मान के लिए सही स्तर है जिसे आप चाहते हैं कि हर caller इनहेरिट करे। यदि आप इसे अंतिम (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 पैरामीटर के साथ इसे एक सेशन के लिए सेट करें

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

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

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

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

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

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

CPU-only VPS पर output length मुख्य लागत क्यों है

Generation के दो चरण होते हैं और दोनों की गति बहुत अलग होती है। Prompt tokens को batches में, एक साथ कई tokens के रूप में evaluate किया जाता है। Output tokens एक-एक करके generate होते हैं और प्रत्येक token के लिए model weights पर एक पूर्ण pass की आवश्यकता होती है। CPU-only VPS पर वह pass memory bandwidth द्वारा सीमित होता है, इसलिए एक generated token की लागत एक prompt token की तुलना में कहीं अधिक होती है। चूंकि उस pass को हर weight को पढ़ना पड़ता है, इसलिए प्रत्येक weight द्वारा घेरे गए bytes की संख्या आपकी token rate की अधिकतम सीमा तय करती है। यही कारण है कि q4 build, q8 या fp16 वाले उसी model की तुलना में तेजी से decode करता है।

यदि आप बिना streaming के response मांगते हैं, तो आंकड़े स्पष्ट दिखाई देते हैं:

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

अवधियाँ nanoseconds में हैं। उस block में, जो कि किसी विशेष सर्वर का मापन न होकर Ollama API documentation में प्रकाशित sample response है, 26 prompt tokens को process करने में लगभग 0.1 seconds लगे, जबकि 237 output tokens के लिए लगभग 4.3 seconds लगे। आपकी अपनी generation rate eval_count को eval_duration से विभाजित करके और उसे seconds में बदलकर निकाली जाती है, और अपने hardware पर tokens per second मापना किसी भी अन्य चीज़ को tune करने से पहले एक बार जरूर कर लेना चाहिए। वह दर machine के साथ-साथ model पर भी निर्भर करती है, इसलिए यदि लंबे उत्तर ही वास्तविक लागत हैं, तो VPS पर Nemotron 3.5 Lightning जैसे तेज decoding के लिए बनाए गए models उस समय की कुछ भरपाई कर देते हैं जिसे low cap अन्यथा सुरक्षित रखता है।

बाकी काम गणित करता है। 8 tokens per second की दर से, 2,000 tokens का उत्तर machine को चार मिनट से अधिक समय तक व्यस्त रखता है, और model को यह पता नहीं होता कि आप केवल एक paragraph चाहते थे। एक reasoning model आपके द्वारा मांगे गए शब्दों को लिखने से पहले उस budget का कुछ हिस्सा सोचने में खर्च करता है, और वह सोच भी बाकी सब की तरह एक-एक token करके generate होती है, इसलिए आपके द्वारा मांगा गया reasoning effort उसी बिल पर एक और कारक है। कुछ models loop में भी फंस जाते हैं और किसी रुकावट के आने तक एक ही phrase को दोहराते रहते हैं। बिना किसी cap के, वह एक request तब तक core को व्यस्त रखती है जब तक context window समाप्त न हो जाए। num_predict वह setting है जो इसे सीमित करती है, जो एक छोटे self-hosted Ollama VPS पर सबसे अधिक मायने रखती है, जहाँ एक लंबी request पूरी machine को व्यस्त कर सकती है।

Truncated output का कारण आमतौर पर cap है, न कि कोई खराब model

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

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

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

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

मान (value) का चयन

• इंटरैक्टिव चैट के लिए, इसे uncapped छोड़ें और runaway reply को रोकने के लिए Ctrl+C दबाएं। आप वैसे भी स्क्रीन देख रहे होते हैं।
• स्क्रिप्टेड कार्यों के लिए, इसे सेट करें। लूप के अंदर uncapped generation के कारण ही वह batch job जो दस मिनट में पूरी होनी चाहिए थी, अगली सुबह तक चलती रहती है।
• स्ट्रक्चर्ड आउटपुट के लिए, कैप को अपने द्वारा अपेक्षित सबसे बड़े वैध दस्तावेज़ से ऊपर सेट करें, फिर done_reason of length को एक hard error मानें और जो वापस आया उसे पार्स करने के बजाय पुनः प्रयास करें।
• कोडिंग एजेंट के लिए, यह मान एजेंट के अपने कॉन्फ़िगरेशन में होना चाहिए, क्योंकि एजेंट हर अनुरोध पर अपने विकल्प स्वयं भेजता है। 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 के रूप में वापस आए।