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

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

দুটির প্রভাব একটি জায়গায় মিলিত হয়। তৈরি হওয়া token-গুলো উৎপন্ন হওয়ার সঙ্গে সঙ্গে context window-এর মধ্যে জমা হয়। তাই আপনার নির্ধারিত cap-এ পৌঁছানোর আগেই window পূর্ণ হয়ে গেলে reply থেমে যেতে পারে। উভয় ক্ষেত্রেই Ollama length রিপোর্ট করে। তাই এই দুটি পরিস্থিতিকে আলাদা করে এমন সংখ্যা হলো 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-এর মানসহ একটি করে line দেখায়। ওই output-এ num_predict না থাকলে মডেলটিতে স্থায়ী কোনো cap নেই এবং Ollama-এর নিজস্ব default প্রযোজ্য হবে। ollama show --modelfile qwen3-capped সম্পূর্ণ definition দেখায়। বিদ্যমান মডেলের সঙ্গে থাকা parameter কপি করার এটিই সবচেয়ে দ্রুত উপায়।

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

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

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

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

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

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

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

/set parameter তৃতীয় কোনো rule নয়। Interactive session একটি API client। তাই সেখানে সেট করা value ওই অনুরোধের options হিসেবে পাঠানো হয়। এই কারণেই session চলাকালে এটি Modelfile-এর setting-কে 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-এর মাধ্যমে আসা request-এ কী আছে, এটি তা দেখাতে পারে না।

একটি command-এ server side যাচাই করুন। এমন একটি request পাঠান, যা দীর্ঘ উত্তর তৈরি করবে, 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 server-এর সঙ্গে যোগাযোগ করার সময় journalctl -u ollama -f monitor করুন।

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

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

এগুলোকে version-dependent হিসেবে বিবেচনা করুন, কারণ মানগুলো পরিবর্তিত হয়েছে। দীর্ঘ সময় reference-এ default হিসেবে 128 লেখা ছিল। 2024-এর শেষ দিকে entry-টি সংশোধন করা হয়। তাই অনেক guide-এ এখনও পুরোনো সংখ্যাটি পুনরাবৃত্তি করা হয়। আপনি যে version চালাচ্ছেন, তার জন্য Modelfile parameter reference পড়ুন। এরপর উপরের eval_count check দিয়ে আচরণটি নিশ্চিত করুন। নিজের system-এ যাচাই করা মান যেকোনো জায়গা থেকে পড়া মানের চেয়ে নির্ভরযোগ্য, এই 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-এর তুলনায় অনেক বেশি।

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 seconds লেগেছে, আর 237টি output token নিতে প্রায় 4.3 seconds লেগেছে। আপনার নিজের generation rate হলো eval_count-কে eval_duration দিয়ে ভাগ করে seconds-এ রূপান্তর করার ফল। অন্য কোনো tuning করার আগে নিজের hardware-এ প্রতি সেকেন্ডে token মাপা একবার করা উপকারী। এই rate machine-এর মতো model-এর ওপরও নির্ভর করে। তাই দীর্ঘ উত্তরই যদি মূল খরচ হয়, তাহলে VPS-এ Nemotron 3.5 Lightning-এর মতো দ্রুত decoding-এর জন্য তৈরি model ব্যবহার করলে কম cap যে সময় সুরক্ষিত রাখে, তার কিছুটা ফেরত পাওয়া যায়।

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

কাটা আউটপুট সাধারণত সীমা পূর্ণ হওয়ার ফল, মডেল নষ্ট হওয়ার নয়

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

done_reason মানে উত্তরটি সরাসরি প্রশ্নের উত্তর দিয়েছে। stop মানে মডেল নিজে থেকে শেষ করেছে; হয় 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 বাড়ালে মডেল বেশি লিখবে না। এতে শুধু সর্বোচ্চ সীমাটি সরানো হয়। কোনো reply 200 token-এ done_reason-সহ stop অবস্থায় শেষ হলে, মডেল নিজেই সিদ্ধান্ত নিয়েছে যে তার উত্তর শেষ। বড় cap দিলেও কিছু পরিবর্তন হবে না। stop-সহ সংক্ষিপ্ত উত্তর prompting-এর সমস্যা। length-সহ সংক্ষিপ্ত উত্তর cap-এর সমস্যা।

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

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

এই cap শব্দ বা character নয়, token গণনা করে। তাই এটি অনুমান করে নির্ধারণ করবেন না। কোনো cap ছাড়া একটি প্রতিনিধিত্বমূলক উত্তর generate করুন, eval_count পড়ুন এবং তার চেয়ে যথেষ্ট বেশি limit নির্ধারণ করুন। Model family-গুলো token আলাদাভাবে ভাগ করে, তাই কোনো Llama model-এ যে মানে উত্তরটি সম্পূর্ণ হয়, একই 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 নিজে থেকে generation শেষ করেছে। length value-এর অর্থ হলো available room শেষ হয়ে গেছে। এরপর eval_count-এর সঙ্গে আপনার cap তুলনা করুন। দুটির value ঠিক মিলে গেলে num_predict generation থামিয়েছে। আর eval_count ছোট হলে context window আগে পূর্ণ হয়েছে। Streaming-এর সময় উভয় field-ই final chunk-এ "done": true-এর সঙ্গে আসে। অনেক client library আপনার code এটি দেখার আগেই তা বাদ দেয়।

num_predict-এর default value কী?

কোনো article-এর পরিবর্তে আপনার নিজের install থেকে এটি পড়ুন। 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 দিয়ে এটি নিশ্চিত করুন।

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

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