Ollama میں num_predict سے output کی حد کیسے مقرر کریں

Ollama میں num_predict کیا کرتا ہے

num_predict Ollama کا وہ option ہے جو یہ حد مقرر کرتا ہے کہ ایک response میں model زیادہ سے زیادہ کتنے tokens generate کر سکتا ہے۔ اس میں صرف output tokens شمار ہوتے ہیں، اس لیے prompt اس حد میں شامل نہیں ہوتا۔ جب model اس حد تک پہنچ جاتا ہے تو generation اسی مقام پر رک جاتی ہے، جو کبھی کبھی لفظ کے درمیان بھی ہو سکتا ہے، اور response میں done_reason کی قدر length آتی ہے۔

یہی اس feature کا مکمل کام ہے۔ مشکل یہ ہے کہ Ollama میں یہ value مقرر کرنے کے لیے 3 الگ جگہیں موجود ہیں، اور request کے سب سے قریب موجود setting مؤثر ہوتی ہے۔ تقریباً ہر "num_predict کچھ نہیں کرتا" رپورٹ کی وجہ یہ ہوتی ہے کہ ایک layer خاموشی سے دوسری layer کی setting کو override کر رہی ہوتی ہے۔

num_predict، num_ctx نہیں

Ollama میں ان دونوں options کو کسی بھی دوسرے جوڑے سے زیادہ خلط ملط کیا جاتا ہے، اور اس الجھن سے debugging میں حقیقی وقت ضائع ہوتا ہے۔

num_ctx اس بات کا تعین کرتا ہے کہ model کتنا پڑھ سکتا ہے۔ یہ context window کا سائز ہے، جس میں prompt اور اب تک تیار کیا گیا تمام output شامل ہوتا ہے۔ اسے بڑھانے سے memory کی ضرورت بڑھتی ہے، کیونکہ model ان tokens کے لیے جو key/value cache برقرار رکھتا ہے، وہ window کے ساتھ بڑھتا ہے۔ اپنے hardware کے لیے num_ctx کا سائز مقرر کرنا ایک الگ کام ہے، جس میں failure کے اپنے مسائل ہوتے ہیں۔

num_predict اس بات کا تعین کرتا ہے کہ model کتنا لکھ سکتا ہے۔ یہ stopping rule ہے، allocation نہیں۔ اسے بڑھانے سے RAM کے بجائے wall-clock time زیادہ لگتا ہے، اور پہلے سے کوئی memory reserve نہیں کی جاتی۔

یہ دونوں ایک مقام پر باہم اثر انداز ہوتے ہیں۔ تیار کیے گئے tokens بنتے ہی context window میں شامل ہوتے جاتے ہیں، اس لیے reply اس وقت بھی رک سکتا ہے جب window بھر جائے، نہ کہ صرف اس وقت جب آپ کی cap پوری ہو۔ Ollama دونوں صورتوں میں length رپورٹ کرتا ہے، اس لیے ان دونوں میں فرق کرنے والی تعداد eval_count ہے، جس کی مزید وضاحت آگے کی گئی ہے۔

Modelfile کے ذریعے ایک بار قدر مقرر کریں

Modelfile میں یہ قدر اس model میں شامل ہو جاتی ہے جسے آپ بناتے ہیں۔ فائل لکھیں:

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 ہر محفوظ parameter کو اس کی قدر کے ساتھ ایک الگ سطر میں دکھاتا ہے۔ اگر اس output میں num_predict موجود نہ ہو تو model میں پہلے سے کوئی حد شامل نہیں ہے اور Ollama کی اپنی default قدر لاگو ہوتی ہے۔ ollama show --modelfile qwen3-capped مکمل definition دکھاتا ہے۔ موجودہ model میں پہلے سے شامل parameters نقل کرنے کا یہ سب سے تیز طریقہ بھی ہے۔

اگر آپ چاہتے ہیں کہ ہر caller یہی قدر حاصل کرے تو یہ درست layer ہے۔ اگر آپ سمجھتے ہیں کہ یہ آخری اور ناقابلِ تغیر قدر ہوگی تو یہ غلط layer ہے، کیونکہ ایسا نہیں ہے۔

ہر درخواست کے لیے اسے 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 اسی مفہوم کے ساتھ استعمال ہوتی ہے۔ یہاں مقرر کی گئی value صرف اسی ایک call پر لاگو ہوتی ہے، کسی اور چیز پر نہیں۔ آپ کے tools اسی layer کو استعمال کرتے ہیں: chat front end، script، SDK wrapper یا coding agent۔ یہ سب ایک options object بھیجتے ہیں، چاہے وہ آپ کو اس کے لیے کوئی box دکھائیں یا نہ دکھائیں۔

ایک session کے لیے اسے /set parameter سے مقرر کریں

ollama run کے اندر interactive session، اس session کے باقی حصے کے لیے options مقرر کرتی ہے:

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

/show parameters دکھاتا ہے کہ اگلے message کے ساتھ session کیا بھیجے گا۔ اس سے یہ تصدیق کرنے کا تیز ترین طریقہ ملتا ہے کہ تبدیلی مؤثر ہو گئی ہے۔ یہ value اس وقت تک برقرار رہتی ہے جب تک آپ /bye نہ لکھیں۔ اسے محفوظ رکھنے کے لیے /save qwen3-capped موجودہ session کو، parameters سمیت، ایک نئے model کے طور پر لکھتا ہے۔ یہاں آپ جو کچھ بھی /set کرتے ہیں، وہ کسی دوسرے client تک نہیں پہنچتا۔

کون سی ترتیب غالب آتی ہے، اور آپ کی ترتیب نظر انداز کیوں ہوتی ہے

ترتیب مختصر ہے۔ درخواست کے ساتھ بھیجے گئے options باقی ہر چیز پر غالب آتے ہیں۔ model کے Modelfile میں موجود PARAMETER num_predict لائن اس وقت fallback کے طور پر استعمال ہوتی ہے جب درخواست میں کوئی value نہ ہو۔ اگر دونوں موجود نہ ہوں تو Ollama کی built-in default لاگو ہوتی ہے۔

/set parameter کوئی تیسرا rule نہیں ہے۔ interactive session ایک API client ہوتا ہے، اس لیے وہاں set کی گئی value اسی درخواست کے options کے طور پر بھیجی جاتی ہے۔ اسی وجہ سے یہ session کے لیے Modelfile کی value کو override کرتی ہے۔

اب وہ failure دیکھیں جس کی یہ وضاحت کرتی ہے۔ آپ PARAMETER num_predict 512 شامل کرتے ہیں، model دوبارہ build کرتے ہیں، لیکن replies پھر بھی ہزاروں tokens تک جاری رہتے ہیں۔ آپ کی setting موجود ہے، اور ollama show --parameters اس کی تصدیق کرتا ہے۔ ہر درخواست پر اسے override کیا جا رہا ہے، کیونکہ client اپنا options object بھیج رہا ہے جس میں اپنی number موجود ہے۔ اکثر یہ وہ number ہوتی ہے جو آپ نے کئی ماہ پہلے settings screen میں درج کی تھی اور بھول گئے تھے۔ ollama show stored model پڑھتا ہے۔ یہ نہیں دکھا سکتا کہ HTTP کے ذریعے اصل میں کیا موصول ہوتا ہے۔

ایک command سے server side ثابت کریں۔ ایسی 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 پرنٹ ہونے چاہییں۔ اگر jq موجود نہ ہو تو پہلے اسے sudo apt install -y jq کے ذریعے install کریں۔ "length" اور 32 کا response اس بات کی علامت ہے کہ server option کو قبول کر رہا ہے اور آپ کی application کچھ مختلف بھیج رہی ہے۔ کسی request کے بارے میں server کا اپنا record دیکھنے کے لیے اسے environment میں OLLAMA_DEBUG=1 کے ساتھ دوبارہ start کریں، اور اپنی application کی server سے بات چیت کے دوران journalctl -u ollama -f کو monitor کریں۔

منفی قدریں، اور وہ اعداد جنہیں آپ کو نقل نہیں کرنا چاہیے

num_predict منفی قدریں بھی قبول کرتا ہے، اور یہ قدریں count کے بجائے sentinel کے طور پر استعمال ہوتی ہیں۔ ایک منفی قدر کا مطلب ہے: "اس کی حد مقرر نہ کریں، generation جاری رکھیں"۔ دوسری قدر کا مطلب "باقی ماندہ context مکمل کریں" رہا ہے۔ August 2026 تک Ollama Modelfile reference میں default کے طور پر -1 درج ہے، جس کا مطلب infinite generation ہے، جبکہ اسی table کے پہلے versions میں context مکمل کرنے کے لیے -2 بھی درج تھا۔

ان تمام قدروں کو version-dependent سمجھیں، کیونکہ یہ تبدیل ہوتی رہی ہیں۔ Reference میں طویل عرصے تک default کے طور پر 128 درج تھا، یہاں تک کہ end of 2024 میں اس entry کو درست کیا گیا۔ اسی لیے بہت سی guides اب بھی پرانی value دہراتی ہیں۔ آپ جو version چلا رہے ہیں، اس کے لیے Modelfile parameter reference پڑھیں، پھر اوپر دیے گئے eval_count check سے behavior کی تصدیق کریں۔ اپنے box پر خود verify کی ہوئی value، اس post میں دی گئی value سمیت، ہر دوسری جگہ پڑھی ہوئی value سے زیادہ قابلِ اعتماد ہے۔

CPU-only VPS پر output length سب سے بڑا خرچ کیوں ہے

Generation دو phases میں ہوتی ہے، اور دونوں کی رفتار میں بہت فرق ہوتا ہے۔ Prompt tokens کو batches میں، ایک وقت میں کئی tokens کے ساتھ evaluate کیا جاتا ہے۔ Output tokens ایک وقت میں ایک token کے حساب سے تیار ہوتے ہیں، اور ہر token کے لیے model weights پر مکمل pass درکار ہوتا ہے۔ CPU-only VPS پر یہ pass memory bandwidth سے محدود ہوتا ہے، اس لیے ایک generated token کی لاگت ایک prompt token کے مقابلے میں کہیں زیادہ ہوتی ہے۔

Streaming کے بغیر response طلب کریں تو اعداد سامنے آ جاتے ہیں:

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

Durations 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 میں convert کرکے معلوم ہوتی ہے، اور اپنے hardware پر tokens per second کی پیمائش کسی بھی دوسری tuning سے پہلے ایک بار کرنا مفید ہے۔ یہ rate machine کے ساتھ ساتھ model پر بھی منحصر ہوتی ہے۔ اس لیے اگر اصل خرچ طویل answers ہیں تو fast decoding کے لیے بنایا گیا model، جیسے VPS پر Nemotron 3.5 Lightning، اس وقت کا کچھ حصہ واپس حاصل کر سکتا ہے جسے کم cap بصورت دیگر بچا رہی ہوتی ہے۔

باقی حساب خود واضح ہے۔ 8 tokens per second کی رفتار پر 2,000 tokens کا answer machine کو چار منٹ سے زیادہ مصروف رکھتا ہے، اور model کو یہ معلوم نہیں ہوتا کہ آپ صرف ایک paragraph چاہتے تھے۔ کچھ models loop بھی کر سکتے ہیں اور کسی phrase کو اس وقت تک دہراتے رہتے ہیں جب تک کوئی چیز انہیں روک نہ دے۔ Cap کے بغیر یہ single request context window ختم ہونے تک ایک core کو مصروف رکھتی ہے۔ num_predict وہ setting ہے جو اس کی حد مقرر کرتی ہے۔ یہ خاص طور پر چھوٹے self-hosted Ollama VPS پر اہم ہے، جہاں ایک طویل request پوری machine کے وسائل استعمال کر سکتی ہے۔

مختصر output عموماً cap کی وجہ سے ہوتا ہے، model خراب نہیں ہوتا

ظاہری علامات model کی failure جیسی لگتی ہیں۔ جواب جملہ مکمل ہونے سے پہلے رک جاتا ہے۔ JSON parse نہیں ہوتا کیونکہ closing brace کبھی موصول ہی نہیں ہوئی۔ فوری ردعمل میں model یا quantisation کو قصوروار ٹھہرایا جاتا ہے۔ پہلے response پڑھیں۔

done_reason کا مطلب ہے کہ جواب نے سوال کا براہِ راست جواب دیا۔ stop کا مطلب ہے کہ model خود مکمل ہو گیا، یا تو اس نے اپنا end-of-sequence token جاری کیا یا آپ کے stop option میں موجود strings میں سے کسی ایک سے match کیا۔ length کا مطلب ہے کہ generation اس لیے رک گئی کیونکہ دستیاب گنجائش ختم ہو گئی۔ جب length نظر آئے تو eval_count کا اپنے cap سے موازنہ کریں: دونوں کا بالکل برابر ہونا ظاہر کرتا ہے کہ num_predict نے generation روکی، جبکہ اس سے کم number کا مطلب ہے کہ context window پہلے بھر گئی۔

جب آپ stream کرتے ہیں تو یہ fields آخری chunk میں آتی ہیں، یعنی اس chunk میں جس میں "done": true شامل ہوتا ہے۔ بہت سی client libraries یہ chunk discard کر دیتی ہیں اور آپ کے code کو صرف text دیتی ہیں۔ اسی لیے application کے اندر یہی truncation غیر واضح دکھائی دیتی ہے، جبکہ curl کے تحت واضح ہوتی ہے۔ اگر کوئی library اسے چھپا رہی ہو تو curl کے ساتھ ایک request بھیجیں تاکہ معلوم ہو سکے کہ server نے حقیقت میں کیا کہا۔

ایک اور نکتہ ضائع ہونے والی کئی گھنٹوں کی محنت سے بچاتا ہے۔ num_predict بڑھانے سے model زیادہ نہیں لکھتا۔ اس سے صرف ایک ceiling ختم ہوتی ہے۔ اگر reply 200 tokens پر done_reason کے ساتھ ختم ہو اور stop موجود ہو، تو model نے فیصلہ کیا کہ جواب مکمل ہے، اور بڑا cap کچھ تبدیل نہیں کرے گا۔ stop کے ساتھ مختصر answers prompting کا مسئلہ ہیں۔ length کے ساتھ مختصر answers cap کا مسئلہ ہیں۔

قدر کا انتخاب

• Interactive chat کے لیے اسے غیر محدود رہنے دیں اور بے قابو جواب روکنے کے لیے Ctrl+C دبائیں۔ آپ اسکرین کی نگرانی کر رہے ہوتے ہیں۔
• Script کے ذریعے چلنے والے کام کے لیے قدر مقرر کریں۔ Loop کے اندر غیر محدود generation کی وجہ سے دس منٹ میں مکمل ہونے والا batch job اگلی صبح بھی چل رہا ہوتا ہے۔
• Structured output کے لیے cap کو متوقع سب سے بڑی درست document سے زیادہ مقرر کریں۔ اس کے بعد done_reason کو length میں hard error سمجھیں اور واپس آنے والے نامکمل output کو parse کرنے کے بجائے دوبارہ کوشش کریں۔
• Coding agent کے لیے یہ قدر agent کی اپنی configuration میں مقرر کریں، کیونکہ agent ہر request پر اپنے options خود بھیجتا ہے۔ Coding agent کو Ollama سے منسلک کرنا میں بتایا گیا ہے کہ یہ settings کہاں موجود ہوتی ہیں۔

Cap tokens گنتا ہے، words یا characters نہیں، اس لیے اس کا اندازہ نہ لگائیں۔ پہلے cap کے بغیر ایک نمائندہ جواب generate کریں، eval_count پڑھیں، اور limit کو اس قدر سے مناسب حد تک زیادہ مقرر کریں۔ مختلف model families tokens کو مختلف طریقے سے tokenise کرتی ہیں، اس لیے جو قدر Llama model کے لیے کافی ہو، ممکن ہے وہ اسی VPS پر موجود Qwen 3 model کے اسی جواب کو truncate کر دے۔

FAQ

num_ctx اور num_predict میں کیا فرق ہے؟

num_ctx context window کا سائز ہے، اس لیے یہ طے کرتا ہے کہ model کتنا پڑھ سکتا ہے: prompt اور اب تک تیار کیا گیا تمام متن۔ اس کے لیے memory درکار ہوتی ہے، کیونکہ key/value cache اس کے ساتھ بڑھتا ہے۔ num_predict یہ طے کرتا ہے کہ model ایک response میں زیادہ سے زیادہ کتنے tokens لکھ سکتا ہے۔ اس کے لیے memory کے بجائے وقت درکار ہوتا ہے، اور پہلے سے کوئی جگہ مختص نہیں کی جاتی۔ تیار ہونے والے tokens دونوں حدود میں شمار ہوتے ہیں، اس لیے reply ان میں سے کسی ایک کی وجہ سے مختصر ہو سکتا ہے۔

میری 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 دیکھ نہیں سکتا۔ curl کے ساتھ "options": {"num_predict": 32} استعمال کرتے ہوئے ایک request بھیجیں اور تصدیق کریں کہ eval_count کی value 32 واپس آتی ہے۔ اس سے ثابت ہو جائے گا کہ server خود درست کام کر رہا ہے اور تلاش آپ کی application تک محدود ہو جائے گی۔

میں کیسے معلوم کر سکتا ہوں کہ output num_predict کی وجہ سے رک گیا؟

request کو "stream": false کے ساتھ بھیجیں اور done_reason پڑھیں۔ stop کی value کا مطلب ہے کہ model خود مکمل ہو گیا۔ length کی value کا مطلب ہے کہ دستیاب حد ختم ہو گئی۔ پھر eval_count کا اپنی cap سے موازنہ کریں: اگر دونوں بالکل برابر ہوں تو num_predict نے اسے روکا، اور اگر eval_count چھوٹی ہو تو context window پہلے بھر گئی۔ Streaming کے دوران دونوں fields آخری chunk میں "done": true کے ساتھ آتی ہیں، لیکن بہت سی client libraries آپ کے code تک پہنچنے سے پہلے انہیں ضائع کر دیتی ہیں۔

num_predict کی default value کیا ہے؟

کسی article کے بجائے اپنی install سے value پڑھیں۔ August 2026 تک Ollama Modelfile reference میں default کو -1 بتایا گیا ہے، یعنی generation پر کوئی cap نہیں، اور یہ entry 2024 کے آخر میں درست کی گئی تھی؛ اس سے پہلے کئی سال تک 128 دستاویز کیا جاتا رہا۔ Negative values counts کے بجائے sentinels ہوتی ہیں، اور اسی table کے پرانے versions میں باقی context بھرنے کے لیے -2 بھی درج تھا۔ اپنے version کے لیے Modelfile parameter reference دیکھیں، پھر ollama show --parameters اور ایک curl request کے ذریعے اس کی تصدیق کریں۔

کیا num_predict بڑھانے سے model زیادہ طویل answers لکھتا ہے؟

نہیں۔ یہ صرف ایک upper limit ختم کرتا ہے۔ اگر reply done_reason of stop کے ساتھ ختم ہو جائے تو model نے فیصلہ کیا کہ وہ مکمل ہو چکا ہے، اور بڑی cap سے کچھ نہیں بدلے گا۔ اس صورت میں length کا تعلق prompting سے ہے: مخصوص structure، sections کی تعداد، یا مطلوبہ detail level مانگیں۔ num_predict صرف اس وقت بڑھائیں جب done_reason کے طور پر length واپس آئے۔