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

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

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

یہی اس feature کا مکمل کام ہے۔ پیچیدگی یہ ہے کہ Ollama میں value set کرنے کے لیے تین الگ مقامات موجود ہیں، اور request کے سب سے قریب موجود setting نافذ ہوتی ہے۔ تقریباً ہر "num_predict does nothing" رپورٹ کی وجہ یہ ہوتی ہے کہ ایک layer خاموشی سے دوسری layer کی setting override کر رہی ہوتی ہے۔

num_predict، num_ctx نہیں

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

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

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

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

Modelfile کے ساتھ اسے ایک بار مقرر کریں

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

FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 512

پھر اسے build کریں اور build کی گئی configuration دوبارہ دیکھیں:

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

ollama show --parameters ذخیرہ شدہ ہر parameter اور اس کی value کے لیے ایک الگ سطر دکھاتا ہے۔ اگر اس output میں num_predict موجود نہ ہو تو model میں پہلے سے مقرر کردہ cap نہیں ہے، اور Ollama کا اپنا default لاگو ہوگا۔ ollama show --modelfile qwen3-capped پوری definition دکھاتا ہے۔ یہ ان parameters کو copy کرنے کا تیز ترین طریقہ بھی ہے جن کے ساتھ موجودہ model پہلے ہی آتا ہے۔ اس طریقے سے capped model بنانے کے لیے تقریباً اضافی disk space درکار نہیں ہوتی، کیونکہ نئی entry base model کے پہلے سے download کیے گئے weight blobs کو copy کرنے کے بجائے دوبارہ استعمال کرتی ہے۔ یہ جاننا بھی مفید ہے کہ Ollama یہ blobs کہاں رکھتا ہے، اس سے پہلے کہ VPS کی root disk بھر جائے۔

یہ اس value کے لیے درست layer ہے جسے آپ چاہتے ہیں کہ ہر caller inherit کرے۔ اگر آپ توقع رکھتے ہیں کہ یہ آخری فیصلہ ہوگا تو یہ غلط 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 دکھائیں یا نہ دکھائیں۔

اسے ایک سیشن کے لیے /set parameter کے ذریعے مقرر کریں

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

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

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

کون سی setting مؤثر ہوتی ہے، اور آپ کی setting نظر انداز کیوں ہوتی ہے

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

/set parameter تیسرا rule نہیں ہے۔ interactive session ایک API client ہے، اس لیے وہاں set کی گئی 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 کے ذریعے کیا پہنچ رہا ہے۔

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

منفی values، اور وہ numbers جنہیں آپ کو copy نہیں کرنا چاہیے

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

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

CPU-only VPS پر output length بنیادی لاگت کیوں ہے

Generation دو مراحل میں ہوتی ہے، اور دونوں کی رفتار میں نمایاں فرق ہوتا ہے۔ Prompt tokens کو batches میں، یعنی ایک وقت میں کئی tokens کو evaluate کیا جاتا ہے۔ Output tokens ایک ایک کر کے تیار ہوتے ہیں، اور ہر token کے لیے model weights پر مکمل pass درکار ہوتا ہے۔ CPU-only VPS پر یہ pass memory bandwidth سے محدود ہوتا ہے، اس لیے ایک generated token کی لاگت ایک prompt token سے کہیں زیادہ ہوتی ہے۔ چونکہ اس pass میں ہر weight کو پڑھنا ضروری ہے، اس لیے ہر weight کے زیرِ استعمال bytes کی تعداد آپ کی token rate کی بالائی حد مقرر کرتی ہے۔ اسی وجہ سے q4 build اسی model کے q8 یا fp16 ورژن سے زیادہ تیزی سے decode ہوتا ہے۔

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

"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 پر بھی منحصر ہوتی ہے۔ اگر اصل لاگت طویل answers ہیں تو fast decoding کے لیے بنایا گیا model، جیسے VPS پر Nemotron 3.5 Lightning، وہ وقت واپس دلا سکتا ہے جسے کم cap بصورتِ دیگر بچا رہا ہوتا ہے۔

باقی حساب خود واضح ہے۔ 8 tokens per second کی رفتار پر 2,000 tokens کا answer machine کو 4 minutes سے زیادہ مصروف رکھتا ہے، اور model کو یہ معلوم نہیں ہوتا کہ آپ صرف ایک paragraph چاہتے تھے۔ Reasoning model آپ کے کہنے پر ایک لفظ لکھنے سے پہلے اپنے budget کا کچھ حصہ سوچنے میں صرف کرتا ہے۔ یہ سوچ بھی ہر دوسری چیز کی طرح ایک ایک token کر کے generate ہوتی ہے، اس لیے آپ جس reasoning effort کی درخواست کرتے ہیں وہ بھی اسی bill کو متاثر کرنے والا ایک lever ہے۔ کچھ models loop بھی کرتے ہیں اور کسی phrase کو اس وقت تک دہراتے رہتے ہیں جب تک کوئی چیز انہیں روک نہ دے۔ cap کے بغیر یہ واحد request context window ختم ہونے تک ایک core کو مصروف رکھ سکتی ہے۔ num_predict وہ setting ہے جو اس کی حد مقرر کرتی ہے۔ یہ ایک چھوٹے self-hosted Ollama VPS پر خاص طور پر اہم ہے، جہاں ایک طویل request پوری machine کو مصروف کر دیتی ہے۔

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

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

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

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

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

قدر منتخب کرنا

• تعاملی چیٹ کے لیے اسے غیر محدود رہنے دیں اور بے قابو جواب روکنے کے لیے Ctrl+C دبائیں۔ آپ اسکرین کی نگرانی کر ہی رہے ہیں۔
• اسکرپٹ کے ذریعے چلنے والے کام کے لیے قدر مقرر کریں۔ loop کے اندر غیر محدود generation کی وجہ سے 10 منٹ میں مکمل ہونے والا batch job اگلی صبح بھی چل رہا ہوتا ہے۔
• structured output کے لیے cap کو متوقع سب سے بڑی درست document سے زیادہ رکھیں۔ پھر done_reason کو length کا hard error سمجھیں اور واپس موصول ہونے والے مواد کو 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

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

num_ctx context window کا سائز ہے، اس لیے یہ طے کرتا ہے کہ model کتنا متن پڑھ سکتا ہے: prompt اور اب تک تیار کیا گیا تمام متن۔ اس کے لیے memory درکار ہوتی ہے، کیونکہ key/value cache اس کے ساتھ بڑھتا ہے۔ num_predict یہ طے کرتا ہے کہ model ایک response میں زیادہ سے زیادہ کتنے tokens لکھ سکتا ہے۔ اس کے لیے memory کے بجائے وقت درکار ہوتا ہے، اور پہلے سے کچھ reserve نہیں کیا جاتا۔ تیار کیے گئے 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 میں منتقل ہو جائے گی۔

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

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 تک پہنچنے سے پہلے انہیں discard کر دیتی ہیں۔

num_predict کی default value کیا ہے؟

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

کیا num_predict بڑھانے سے model طویل answers لکھے گا؟

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