Ollama-তে num_predict দিয়ে output length সীমিত করুন

Ollama-তে num_predict কী করে

num_predict হলো Ollama-এর সেই option, যা একটি response-এ model সর্বোচ্চ কত token generate করতে পারবে তা সীমাবদ্ধ করে। এটি শুধু output token গণনা করে; তাই prompt-এর token এতে গণনা হয় না। model এই সীমায় পৌঁছালে সেখানেই generation বন্ধ হয়। কখনও শব্দের মাঝখানেও এটি ঘটতে পারে। তখন response-এ done_reason-এর মান length সেট করা থাকে।

এটাই এই feature-এর সম্পূর্ণ কাজ। সমস্যা হলো, Ollama-তে এই value সেট করার জন্য তিনটি আলাদা জায়গা আছে। request-এর সবচেয়ে কাছের setting কার্যকর হয়। প্রায় সব "num_predict does nothing" report-এর কারণ হলো, একটি layer নীরবে অন্য layer-এর setting override করছে।

num_predict এবং num_ctx এক নয়

Ollama-এ এই দুটি option-এর মধ্যে অন্য যেকোনো জোড়ার তুলনায় বেশি বিভ্রান্তি হয়, এবং এতে debugging-এর প্রকৃত সময় নষ্ট হয়।

num_ctx নির্ধারণ করে model কতটুকু পড়তে পারবে। এটি context window-এর আকার, যেখানে prompt এবং এখন পর্যন্ত তৈরি হওয়া সবকিছু থাকে। এর মান বাড়ালে memory ব্যবহার বাড়ে, কারণ model ওই token-গুলোর জন্য যে key/value cache সংরক্ষণ করে, window বড় হওয়ার সঙ্গে সেটিও বড় হয়। আপনার hardware-এর জন্য num_ctx নির্ধারণ একটি আলাদা কাজ, যার নিজস্ব failure mode আছে।

num_predict নির্ধারণ করে model কতটুকু লিখবে। এটি একটি stopping rule, allocation নয়। এর মান বাড়ালে RAM-এর পরিবর্তে wall-clock time বেশি লাগে, এবং আগে থেকে কোনো memory reserve করা হয় না।

এই দুই option এক জায়গায় এসে সম্পর্কিত হয়। Generated token তৈরি হওয়ার সঙ্গে সঙ্গে context window-এর মধ্যে জমা হয়। তাই আপনার cap-এ পৌঁছানোর আগেই window পূর্ণ হয়ে যাওয়ার কারণে reply থেমে যেতে পারে। উভয় ক্ষেত্রেই Ollama length report করে। তাই যে সংখ্যাটি এই দুই কারণের পার্থক্য দেখায়, সেটি হলো eval_count, যা নিচে আরও ব্যাখ্যা করা হয়েছে।

Modelfile দিয়ে একবার সেট করুন

আপনি যে মডেল তৈরি করবেন, একটি Modelfile সেই মডেলের মধ্যে মানটি স্থায়ীভাবে সংরক্ষণ করে। ফাইলটি লিখুন:

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 না থাকলে মডেলটিতে স্থায়ী cap নেই এবং Ollama-এর নিজস্ব default প্রযোজ্য হবে। ollama show --modelfile qwen3-capped সম্পূর্ণ definition দেখায়। বিদ্যমান কোনো মডেল যে parameter-গুলো নিয়ে আসে, সেগুলো কপি করার এটিই দ্রুততম উপায়। এভাবে cap-যুক্ত মডেল তৈরি করতে প্রায় কোনো অতিরিক্ত disk space লাগে না। নতুন entry-টি base model আগে download করা weight blob পুনরায় ব্যবহার করে; সেগুলোর কপি তৈরি করে না। VPS-এর root disk পূর্ণ হওয়ার আগে Ollama এই blob-গুলো কোথায় রাখে তা জানা উপযোগী।

প্রতিটি 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 একই অর্থে ব্যবহার করে। এখানে নির্ধারিত value শুধু ওই একটি call-এর ক্ষেত্রে প্রযোজ্য; অন্য কোনো কিছুর ক্ষেত্রে নয়। আপনার tools এই স্তরটি ব্যবহার করে: একটি chat front end, একটি script, একটি SDK wrapper বা একটি coding agent। এগুলো সবই একটি options object পাঠায়, সেখানে সেটির জন্য কোনো input box দেখানো হোক বা না হোক।

একটি সেশনের জন্য /set parameter দিয়ে এটি নির্ধারণ করুন

ollama run-এর মধ্যে interactive session সেই session-এর বাকি সময়ের জন্য options নির্ধারণ করে:

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

/show parameters আপনার পরবর্তী message-এর সঙ্গে session কী পাঠাবে তা দেখায়। তাই কোনো পরিবর্তন কার্যকর হয়েছে কি না নিশ্চিত করার এটি সবচেয়ে দ্রুত উপায়। আপনি /bye টাইপ করা পর্যন্ত value-টি থাকে। এটি সংরক্ষণ করতে /save qwen3-capped বর্তমান session-কে, parameters-সহ, একটি নতুন model হিসেবে লেখে। আপনি এখানে /set-এ যা করেন, তা অন্য কোনো client-এ প্রযোজ্য হয় না।

কোন সেটিং কার্যকর হয়, এবং আপনার সেটিং উপেক্ষিত মনে হয় কেন

ক্রমটি সংক্ষিপ্ত। অনুরোধের সঙ্গে পাঠানো option অন্য সবকিছুর ওপর অগ্রাধিকার পায়। মডেলের Modelfile-এ থাকা PARAMETER num_predict লাইনটি তখন fallback হিসেবে ব্যবহৃত হয়, যখন অনুরোধে কোনো value থাকে না। দুটিই না থাকলে Ollama-এর built-in default কার্যকর হয়।

/set parameter তৃতীয় কোনো rule নয়। Interactive session একটি API client। তাই সেখানে সেট করা value ওই অনুরোধের options হিসেবে পাঠানো হয়। এই কারণেই session চলাকালে এটি Modelfile-এর সেটিং override করে।

এখন এই আচরণ যে সমস্যাটি ব্যাখ্যা করে, সেটি দেখুন। আপনি PARAMETER num_predict 512 যোগ করে model rebuild করেন, কিন্তু reply এখনও হাজার হাজার token পর্যন্ত চলে। আপনার setting উপস্থিত আছে, এবং ollama show --parameters সেটি প্রমাণ করে। তবে প্রতিটি অনুরোধে এটি override হচ্ছে, কারণ client নিজস্ব options object পাঠাচ্ছে, যার মধ্যে নিজস্ব number রয়েছে। অনেক সময় এই number কয়েক মাস আগে settings screen-এ লিখে রাখা হয়েছিল এবং পরে ভুলে যাওয়া হয়েছে। ollama show stored model পড়ে। HTTP-এর মাধ্যমে আসা value এটি দেখাতে পারে না।

একটি command-এ server side যাচাই করুন। এমন একটি request পাঠান, যা দীর্ঘ answer তৈরি করবে, cap কম মানে বাধ্যতামূলক করুন, এবং দুটি field পড়ুন:

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 ভিন্ন কিছু পাঠাচ্ছে। কোনো request সম্পর্কে server-এর নিজস্ব তথ্য দেখতে, environment-এ OLLAMA_DEBUG=1 সেট করে server restart করুন এবং application কথা বলার সময় journalctl -u ollama -f monitor করুন।

ঋণাত্মক মান এবং যে সংখ্যাগুলো আপনার কপি করা উচিত নয়

num_predict ঋণাত্মক মানও গ্রহণ করে। এগুলো count নয়, sentinel। একটি ঋণাত্মক মানের অর্থ হলো “এটির সীমা নির্ধারণ করবেন না, generation চালিয়ে যান।” আরেকটির অর্থ ছিল “অবশিষ্ট context পূরণ করুন।” August 2026 অনুযায়ী Ollama Modelfile reference-এ default হিসেবে -1, অর্থাৎ infinite generation, দেওয়া আছে। একই table-এর আগের version-গুলোতে context পূরণের জন্য -2-ও দেওয়া ছিল।

এসবকে version-dependent হিসেবে বিবেচনা করুন, কারণ মানগুলো পরিবর্তিত হয়েছে। Entry-টি 2024-এর শেষ দিকে সংশোধন করার আগে reference-এ দীর্ঘ সময় default হিসেবে 128 দেওয়া ছিল। তাই অনেক guide-এ এখনও পুরোনো সংখ্যাটি দেখা যায়। আপনি যে version চালাচ্ছেন, তার জন্য Modelfile parameter reference পড়ুন। এরপর উপরের eval_count check দিয়ে behaviour নিশ্চিত করুন। নিজের box-এ যাচাই করা মান যেকোনো জায়গায় পড়া মানের চেয়ে বেশি নির্ভরযোগ্য, এই post-এ দেওয়া মানের চেয়েও।

CPU-only VPS-এ output length কেন প্রধান খরচ

Generation-এর দুটি phase আছে এবং দুটির গতি একেবারেই ভিন্ন। Prompt token batch-এ, একসঙ্গে অনেকগুলো, evaluate করা হয়। Output token একবারে একটি করে তৈরি হয়, এবং প্রতিটির জন্য model weight-এর ওপর সম্পূর্ণ pass চালাতে হয়। CPU-only VPS-এ এই pass memory bandwidth দ্বারা সীমাবদ্ধ থাকে। তাই একটি generated token-এর খরচ একটি prompt token-এর তুলনায় অনেক বেশি। এই pass-এ প্রতিটি weight পড়তে হয়। ফলে প্রতিটি weight কত byte দখল করে, সেটিই আপনার token rate-এর সর্বোচ্চ সীমা নির্ধারণ করে। এই কারণেই একই model-এর q8 বা fp16 build-এর তুলনায় q4 build দ্রুত decode হয়।

Streaming ছাড়া response চাইলে সংখ্যাগুলো সরাসরি দেখা যায়:

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

সময় nanosecond-এ দেওয়া হয়েছে। ওই block-টি কোনো নির্দিষ্ট server-এর measurement নয়; এটি Ollama API documentation-এ প্রকাশিত একটি sample response। সেখানে 26টি prompt token তৈরি হতে প্রায় 0.1 second লেগেছে, আর 237টি output token তৈরি হতে প্রায় 4.3 second লেগেছে। আপনার নিজের generation rate হলো eval_count-কে eval_duration দিয়ে ভাগ করে second-এ রূপান্তর করার ফল। অন্য কিছু tune করার আগে একবার নিজের hardware-এ tokens per second মাপা উপকারী। এই rate machine-এর মতো model-এর ওপরও নির্ভর করে। তাই দীর্ঘ উত্তরই যদি প্রকৃত খরচ হয়, তাহলে VPS-এ Nemotron 3.5 Lightning-এর মতো দ্রুত decoding-এর জন্য তৈরি model ব্যবহার করলে কম cap যে সময় সাশ্রয় করে, তার কিছুটা ফিরে পাওয়া যায়।

এর পরের হিসাব সহজ। প্রতি second-এ 8টি token তৈরি হলে, 2,000 token-এর একটি উত্তর machine-কে চার মিনিটের বেশি ব্যস্ত রাখে। Model জানে না যে আপনি শুধু একটি paragraph চেয়েছিলেন। Reasoning model আপনার অনুরোধের একটি শব্দ লেখার আগেই বরাদ্দ budget-এর কিছু অংশ চিন্তা করতে ব্যয় করে। এই চিন্তাও অন্য সবকিছুর মতো একবারে একটি token করে তৈরি হয়। তাই আপনি যে reasoning effort চান সেটিও একই খরচ নিয়ন্ত্রণের আরেকটি উপায়। কিছু model আবার loop-এ পড়ে কোনো কিছু তাদের থামানো পর্যন্ত একটি phrase পুনরাবৃত্তি করে। কোনো cap না থাকলে context window পূর্ণ হওয়া পর্যন্ত ওই একটিমাত্র request একটি CPU core ব্যস্ত রাখে। num_predict হলো যে setting এই সীমা নির্ধারণ করে। ছোট self-hosted Ollama VPS-এ এটি সবচেয়ে গুরুত্বপূর্ণ, কারণ সেখানে একটি দীর্ঘ request-ই পুরো machine-এর resource ব্যবহার করতে পারে।

সাধারণত output truncate হওয়ার কারণ সীমা, মডেলের ত্রুটি নয়

লক্ষণগুলো দেখে মডেল ব্যর্থ হয়েছে বলে মনে হয়। উত্তরটি বাক্যের মাঝখানে থেমে যায়। শেষের closing brace না আসায় JSON parse হয় না। স্বাভাবিক প্রতিক্রিয়া হলো মডেল বা quantisation-কে দোষ দেওয়া। আগে response পড়ুন।

done_reason মানে উত্তরটি সরাসরি প্রশ্নের উত্তর দিয়েছে। stop মানে মডেল নিজে generation শেষ করেছে; হয় end-of-sequence token পাঠিয়েছে, নয়তো আপনার stop option-এ থাকা কোনো string-এর সঙ্গে মিলেছে। length মানে পর্যাপ্ত জায়গা না থাকায় generation কেটে গেছে। length দেখলে eval_count-কে আপনার cap-এর সঙ্গে তুলনা করুন: দুটি মান এক হলে num_predict generation থামিয়েছে, আর ছোট কোনো সংখ্যা হলে context window আগে পূর্ণ হয়েছে।

আপনি stream ব্যবহার করলে এই field-গুলো final chunk-এ আসে, যে chunk-এ "done": true থাকে। অনেক client library এই chunk বাদ দিয়ে আপনার code-কে শুধু text দেয়। তাই application-এর ভেতরে একই truncation-এর কারণ অস্পষ্ট মনে হয়, কিন্তু curl-এ তা স্পষ্ট দেখা যায়। কোনো library এটি আড়াল করলে curl দিয়ে একটি request পাঠান, যাতে server আসলে কী জানিয়েছে তা জানা যায়।

আরেকটি বিষয় মনে রাখলে অপ্রয়োজনীয় সময় নষ্ট হবে না। num_predict বাড়ালে মডেল বেশি লিখবে না। এটি শুধু একটি সর্বোচ্চ সীমা সরায়। কোনো উত্তর 200 tokens-এ done_reason of stop সহ শেষ হলে মডেল নিজেই ধরে নিয়েছে যে উত্তর শেষ হয়েছে, এবং বড় cap-এও কিছু পরিবর্তন হবে না। stop-সহ ছোট উত্তর prompting-এর সমস্যা। length-সহ ছোট উত্তর cap-এর সমস্যা।

একটি মান নির্বাচন করা

• ইন্টার‌্যাক্টিভ chat-এর জন্য কোনো সীমা নির্ধারণ না করে রাখুন এবং নিয়ন্ত্রণের বাইরে চলে যাওয়া উত্তরের প্রক্রিয়া থামাতে Ctrl+C চাপুন। আপনি এমনিতেই স্ক্রিন পর্যবেক্ষণ করছেন।
• স্ক্রিপ্টে ব্যবহারের ক্ষেত্রে সীমা নির্ধারণ করুন। loop-এর মধ্যে সীমাহীন generation রাখলে যে batch job দশ মিনিটে শেষ হওয়ার কথা, সেটি পরদিন সকালেও চলতে পারে।
• structured output-এর ক্ষেত্রে প্রত্যাশিত বৃহত্তম বৈধ document-এর চেয়ে বেশি সীমা নির্ধারণ করুন। এরপর done_reason of length-কে গুরুতর error হিসেবে বিবেচনা করে পুনরায় চেষ্টা করুন; প্রাপ্ত output parse করার চেষ্টা করবেন না।
• coding agent-এর ক্ষেত্রে মানটি agent-এর নিজস্ব configuration-এ রাখতে হবে, কারণ প্রতিটি request-এ agent নিজস্ব options পাঠায়। coding agent-কে Ollama-তে নির্দেশ করা অংশে এই settings কোথায় থাকে তা ব্যাখ্যা করা হয়েছে।

এই সীমা tokens গণনা করে, words বা characters নয়। তাই এটি অনুমান করে নির্ধারণ করবেন না। প্রথমে কোনো cap ছাড়া একটি প্রতিনিধিত্বমূলক answer generate করুন, eval_count পড়ুন, তারপর তার চেয়ে যথেষ্ট বেশি limit নির্ধারণ করুন। বিভিন্ন model family ভিন্নভাবে tokenise করে। তাই একটি Llama model-এর জন্য উপযুক্ত মান একই answer-কে একই VPS-এ চলা একটি Qwen 3 model-এ truncate করতে পারে।

FAQ

num_ctx এবং num_predict-এর মধ্যে পার্থক্য কী?

num_ctx হলো context window-এর আকার। তাই এটি নির্ধারণ করে মডেল কতটুকু পড়তে পারবে: prompt এবং এখন পর্যন্ত তৈরি হওয়া সবকিছু। এতে memory খরচ হয়, কারণ এর সঙ্গে key/value cache বড় হয়। num_predict একটি response-এ মডেল সর্বোচ্চ কত token লিখতে পারবে তা নির্ধারণ করে। এতে memory-এর বদলে time খরচ হয়, এবং আগে থেকে কিছু reserve করা হয় না। তৈরি হওয়া token উভয় সীমার হিসাবেই ধরা হয়। তাই যেকোনো একটি সীমার কারণে reply অসম্পূর্ণ হতে পারে।

আমার num_predict setting উপেক্ষা করা হচ্ছে বলে মনে হচ্ছে কেন?

কারণ request-এর সঙ্গে পাঠানো value model-এ সংরক্ষিত value-কে override করে। একটি Modelfile-এ PARAMETER num_predict 512 রাখুন। এরপর chat front end বা coding agent থেকে সেই model চালালে client নিজস্ব options object পাঠায়, এবং তার number কার্যকর হয়। ollama show --parameters তবু আপনার value দেখায়, কারণ এটি stored model পড়ে এবং HTTP দিয়ে কী এসেছে তা দেখতে পারে না। curl ব্যবহার করে "options": {"num_predict": 32}-এর সঙ্গে একটি request পাঠান এবং দেখুন eval_count 32 হিসেবে ফেরত আসে কি না। এতে নিশ্চিত হবে যে server নিজে সঠিকভাবে কাজ করছে, এবং অনুসন্ধান আপনার application-এর দিকে সরানো যাবে।

num_predict-এর কারণে output কেটে গেছে কি না কীভাবে বুঝব?

"stream": false সহ request পাঠান এবং done_reason পড়ুন। stop value-এর অর্থ হলো model নিজে থেকে শেষ করেছে। length value-এর অর্থ হলো model-এর আর জায়গা ছিল না। এরপর eval_count-কে আপনার cap-এর সঙ্গে তুলনা করুন। দুটির মান হুবহু একই হলে num_predict output থামিয়েছে। আর eval_count ছোট হলে context window আগে পূর্ণ হয়েছে। Streaming-এর সময় উভয় field-ই "done": true-সহ final chunk-এ আসে। অনেক client library আপনার code সেগুলো দেখার আগেই বাদ দেয়।

num_predict-এর default value কী?

কোনো article-এর বদলে নিজের install থেকে value পড়ুন। August 2026 অনুযায়ী Ollama Modelfile reference-এ default হিসেবে -1 দেওয়া আছে। এর অর্থ generation-এর কোনো cap নেই। 2024-এর শেষ দিকে এই entry সংশোধন করা হয়; এর আগে বহু বছর ধরে 128 নথিভুক্ত ছিল। Negative value-গুলো count নয়, sentinel হিসেবে পাঠানো হয়। একই table-এর পুরোনো version-গুলোতে অবশিষ্ট context পূরণের জন্য -2-ও দেওয়া ছিল। আপনার version-এর জন্য Modelfile parameter reference দেখুন। এরপর ollama show --parameters এবং একটি curl request দিয়ে value নিশ্চিত করুন।

num_predict বাড়ালে কি model আরও দীর্ঘ answer লিখবে?

না। এটি শুধু একটি ceiling সরিয়ে দেয়। যদি reply done_reason of stop দিয়ে শেষ হয়, তাহলে model নিজেই সিদ্ধান্ত নিয়েছে যে তার কাজ শেষ। বড় cap করলে কিছু পরিবর্তন হবে না। এই ক্ষেত্রে length একটি prompting-এর বিষয়। নির্দিষ্ট structure, section count বা বিস্তারিতের নির্ধারিত স্তর চাইতে prompt লিখুন। done_reason যদি length হিসেবে ফেরত আসে, তখনই num_predict বাড়ান।