Ollama num_predict: வெளியீட்டு வரம்பை அமைப்பது எப்படி?

Ollama-வில் num_predict-ன் செயல்பாடு

num_predict என்பது Ollama-வின் ஒரு விருப்பத்தேர்வு (option) ஆகும். இது ஒரு பதிலில் ஒரு model அதிகபட்சமாக எத்தனை tokens-களை உருவாக்கலாம் என்பதை வரையறுக்கிறது. இது வெளியீட்டு tokens-களை மட்டுமே கணக்கிடும்; எனவே, prompt-க்கு இதில் கட்டணம் ஏதும் இல்லை. model இந்த வரம்பை எட்டும்போது, உருவாக்கம் (generation) அந்த இடத்திலேயே நின்றுவிடும். சில நேரங்களில் இது வார்த்தையின் பாதியிலேயே நின்றுவிடலாம். அப்போது வரும் பதிலில் done_reason என்பது length என அமைக்கப்பட்டிருக்கும்.

இதுவே இந்த அம்சத்தின் முழுமையான விளக்கம். இதில் உள்ள சிக்கல் என்னவென்றால், இந்த மதிப்பை அமைப்பதற்கு Ollama மூன்று வெவ்வேறு இடங்களை வழங்குகிறது. கோரிக்கைக்கு (request) மிக அருகில் உள்ள அமைப்பே செயல்பாட்டுக்கு வரும். "num_predict வேலை செய்யவில்லை" என்று வரும் பெரும்பாலான புகார்கள், ஒரு அடுக்கு மற்றொரு அடுக்கை அமைதியாக மீறிச் செயல்படுவதாலேயே ஏற்படுகின்றன.

num_predict மற்றும் num_ctx ஒன்றல்ல

Ollama-வில் இந்த இரண்டு விருப்பங்களும் மற்ற எதைவிடவும் அதிகமாகக் குழப்பத்தை ஏற்படுத்துகின்றன, மேலும் இந்தக் குழப்பம் பிழைதிருத்தத்திற்கு (debugging) அதிக நேரத்தை வீணாக்குகிறது.

num_ctx என்பது ஒரு model எவ்வளவு வாசிக்க முடியும் என்பதைக் குறிக்கிறது. இது context window-ன் அளவு; இது prompt மற்றும் இதுவரை உருவாக்கப்பட்ட அனைத்தையும் உள்ளடக்கியது. இதை அதிகரிப்பது memory-ஐப் பாதிக்கும், ஏனெனில் அந்த tokens-க்காக model வைத்திருக்கும் key/value cache, window-ன் அளவிற்கு ஏற்ப வளரும். உங்கள் hardware-க்கு ஏற்ப num_ctx-ஐ அமைத்தல் என்பது தனிப்பட்ட வேலை, அதற்குரிய தனித்துவமான தோல்வி நிலைகள் உள்ளன.

num_predict என்பது ஒரு model எவ்வளவு எழுத வேண்டும் என்பதைக் குறிக்கிறது. இது ஒரு நிறுத்த விதி (stopping rule), இது ஒதுக்கீடு (allocation) அல்ல. இதை அதிகரிப்பது RAM-ஐப் பாதிக்காது, மாறாக நேரத்தை (wall-clock time) எடுக்கும், மேலும் எதையும் முன்கூட்டியே ஒதுக்கீடு செய்யாது.

இவை இரண்டும் ஒரே இடத்தில் சந்திக்கின்றன. உருவாக்கப்பட்ட tokens, உருவாகும்போதே context window-க்குள் சேமிக்கப்படுகின்றன. எனவே, உங்கள் வரம்பை (cap) எட்டுவதற்கு முன்பே, window நிரம்பிவிட்டதாலும் ஒரு பதில் நின்றுவிடலாம். 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-ஐயும் அதன் மதிப்புடன் தனித்தனி வரியாகக் காட்டும். அந்த வெளியீட்டில் num_predict இல்லை என்றால், அந்த model-ல் எந்தக் கட்டுப்பாடும் (cap) இல்லை என்று அர்த்தம்; அப்போது Ollama-வின் இயல்புநிலை (default) மதிப்பே பொருந்தும். ollama show --modelfile qwen3-capped முழு வரையறையையும் காட்டும். ஏற்கனவே உள்ள ஒரு model-ல் உள்ள parameters-ஐ நகலெடுக்க இதுவே விரைவான வழியாகும். இந்த முறையில் ஒரு capped model-ஐ உருவாக்குவதால் கூடுதல் disk space செலவாகாது. ஏனெனில், புதிய entry-ஆனது base model ஏற்கனவே பதிவிறக்கம் செய்த weight blobs-ஐயே மீண்டும் பயன்படுத்துகிறது, அவற்றை நகலெடுப்பதில்லை. Ollama அந்த blobs-ஐ எங்கே சேமிக்கிறது என்பதைத் தெரிந்துகொள்வது, VPS root disk நிரம்புவதற்கு முன்பே அவசியமாகும்.

ஒவ்வொரு caller-க்கும் கிடைக்க வேண்டிய ஒரு மதிப்பிற்கு இதுவே சரியான அடுக்கு (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-ஐ அதே பொருளுடன் பயன்படுத்துகிறது. இங்கே கொடுக்கப்படும் மதிப்பு அந்த ஒரு குறிப்பிட்ட அழைப்பிற்கு மட்டுமே பொருந்தும், மற்றவற்றிற்குப் பொருந்தாது. உங்கள் கருவிகள் பயன்படுத்தும் அடுக்கு இதுவே: ஒரு chat front end, ஒரு script, ஒரு SDK wrapper, அல்லது ஒரு coding agent. இவை அனைத்தும் ஒரு options object-ஐ அனுப்புகின்றன; இதற்காக உங்களுக்கு ஒரு பெட்டியை (box) காட்டினாலும் சரி, காட்டாவிட்டாலும் சரி.

/set parameter மூலம் ஒரு session-க்கு மட்டும் அமைத்தல்

ollama run-க்குள், interactive session அந்த session-ன் மீதமுள்ள பகுதிக்கு விருப்பங்களை அமைக்கிறது:

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

/show parameters உங்கள் அடுத்த செய்தியுடன் session எதை அனுப்பும் என்பதைக் காட்டுகிறது, மாற்றங்கள் நடைமுறைக்கு வந்துவிட்டதை உறுதிப்படுத்த இதுவே வேகமான வழியாகும். நீங்கள் /bye என்று தட்டச்சு செய்யும் வரை இந்த மதிப்பு இருக்கும். இதைத் தக்கவைக்க, /save qwen3-capped தற்போதைய session-ஐ, அதன் parameters உட்பட, புதிய model-ஆக எழுதும். நீங்கள் இங்கே /set செய்யும் எதுவும் வேறு எந்த client-க்கும் செல்லாது.

எந்த அமைப்பு முன்னுரிமை பெறுகிறது மற்றும் உங்கள் அமைப்பு ஏன் புறக்கணிக்கப்பட்டதாகத் தெரிகிறது

இதற்கான வரிசைமுறை சுருக்கமானது. கோரிக்கையுடன் (request) அனுப்பப்படும் விருப்பங்களே மற்ற அனைத்தையும் விட முன்னுரிமை பெறும். கோரிக்கையில் எந்த மதிப்பும் இல்லாதபோது, Modelfile-ல் உள்ள ஒரு PARAMETER num_predict வரிசை மாற்று வழியாக (fallback) பயன்படுத்தப்படும். இவை இரண்டுமே இல்லையெனில், Ollama-வின் உள்ளமைக்கப்பட்ட இயல்புநிலை (default) பொருந்தும்.

/set parameter என்பது மூன்றாவது விதி அல்ல. ஊடாடும் அமர்வு (interactive session) ஒரு API client ஆகச் செயல்படுகிறது, எனவே நீங்கள் அங்கு அமைப்பது அந்த கோரிக்கையின் options ஆக அனுப்பப்படுகிறது. இதனால்தான் அது அந்த அமர்விற்கான Modelfile-ஐ மீறுகிறது (override).

இப்போது இது விளக்கும் தோல்வி இதோ. நீங்கள் PARAMETER num_predict 512-ஐச் சேர்த்து, மாதிரியை (model) மீண்டும் உருவாக்குகிறீர்கள், ஆனால் பதில்கள் இன்னும் ஆயிரக்கணக்கான tokens-க்கு நீள்கின்றன. உங்கள் அமைப்பு அங்கேயே உள்ளது, மேலும் ollama show --parameters அதை உறுதிப்படுத்துகிறது. ஒவ்வொரு கோரிக்கையிலும் அது மீறப்படுகிறது, ஏனெனில் client தனது சொந்த options பொருளை அதன் சொந்த எண்ணுடன் அனுப்புகிறது. இது பெரும்பாலும் மாதங்களுக்கு முன்பு அமைப்புகள் திரையில் நீங்கள் தட்டச்சு செய்து மறந்த எண்ணாக இருக்கலாம். ollama show சேமிக்கப்பட்ட மாதிரியை மட்டுமே வாசிக்கும். HTTP வழியாக என்ன வருகிறது என்பதை அதனால் உங்களுக்குக் காட்ட முடியாது.

சர்வர் பக்கத்தை ஒரே கட்டளையில் நிரூபியுங்கள். நீண்ட பதிலைத் தரும் ஒரு கோரிக்கையை அனுப்பி, வரம்பைக் (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 மூலம் முதலில் அதை நிறுவவும். "length" மற்றும் 32 என்ற பதில் கிடைத்தால், சர்வர் அந்த விருப்பத்தை மதிக்கிறது என்றும், உங்கள் application வேறு எதையோ அனுப்புகிறது என்றும் அர்த்தம். ஒரு கோரிக்கை குறித்த சர்வரின் சொந்த பதிவைக் காண, சூழலில் OLLAMA_DEBUG=1 உடன் அதை மறுதொடக்கம் செய்து, உங்கள் application அதனுடன் தொடர்பு கொள்ளும்போது journalctl -u ollama -f-ஐக் கவனிக்கவும்.

எதிர்மறை மதிப்புகள் மற்றும் நீங்கள் நகலெடுக்கக் கூடாத எண்கள்

num_predict எதிர்மறை மதிப்புகளையும் ஏற்கும், ஆனால் அவை எண்ணிக்கையைக் குறிக்காமல், ஒரு குறியீடாக (sentinel) செயல்படுகின்றன. ஒரு எதிர்மறை மதிப்பு "இதை கட்டுப்படுத்த வேண்டாம், தொடர்ந்து உருவாக்கு" என்று பொருள்படும். மற்றொன்று "மீதமுள்ள context-ஐ நிரப்பு" என்பதைக் குறிக்கும். ஆகஸ்ட் 2026 நிலவரப்படி, Ollama Modelfile குறிப்பு, இயல்புநிலை மதிப்பை -1 என்று குறிப்பிடுகிறது, இது முடிவில்லாத உருவாக்கத்தைக் குறிக்கும். அதே அட்டவணையின் முந்தைய பதிப்புகள், context-ஐ நிரப்புவதற்கு -2 மதிப்பைப் பயன்படுத்தின.

இவை பதிப்பைப் பொறுத்து மாறுபடும் என்பதால், கவனமாக இருக்கவும். 2024-ன் இறுதியில் திருத்தம் செய்யப்படும் வரை, நீண்ட காலமாக 128 என்பதே இயல்புநிலை என்று ஆவணப்படுத்தப்பட்டிருந்தது. எனவே, பல வழிகாட்டிகளில் இன்னும் அந்த பழைய எண்ணே குறிப்பிடப்பட்டிருக்கும். நீங்கள் பயன்படுத்தும் பதிப்பிற்கான Modelfile parameter reference-ஐப் படித்துவிட்டு, மேலே உள்ள eval_count சோதனையின் மூலம் அதன் செயல்பாட்டை உறுதிப்படுத்தவும். இந்த இடுகை உட்பட, எங்கு படித்தாலும், உங்கள் சொந்த server-ல் நீங்கள் சரிபார்த்த மதிப்பே இறுதியானது.

CPU-மட்டும் கொண்ட VPS-ல் வெளியீட்டு நீளம் ஏன் முதன்மைச் செலவாகிறது

உருவாக்கம் (generation) இரண்டு நிலைகளைக் கொண்டது, இவை இரண்டும் வெவ்வேறு வேகத்தில் இயங்குகின்றன. Prompt tokens தொகுதிகளாக, ஒரே நேரத்தில் பலவாக மதிப்பீடு செய்யப்படுகின்றன. Output tokens ஒவ்வொன்றாக உருவாக்கப்படுகின்றன, ஒவ்வொன்றிற்கும் model weights முழுவதையும் ஒருமுறை கடந்து செல்ல வேண்டியது அவசியம். CPU-மட்டும் கொண்ட VPS-ல், அந்தச் செயல்முறை memory bandwidth-ஆல் கட்டுப்படுத்தப்படுகிறது, எனவே ஒரு prompt token-ஐ விட ஒரு generated token அதிகச் செலவை ஏற்படுத்துகிறது. ஒவ்வொரு weight-ஐயும் அந்தச் செயல்முறை படிக்க வேண்டியிருப்பதால், ஒவ்வொரு weight-ம் எடுத்துக்கொள்ளும் bytes அளவு உங்கள் token வேகத்திற்கான உச்சவரம்பை நிர்ணயிக்கிறது, இதனால்தான் q4 build, q8 அல்லது fp16-ல் உள்ள அதே model-ஐ விட வேகமாக decode செய்கிறது.

Streaming இல்லாமல் பதிலை வேண்டினால், எண்கள் தெளிவாகத் தெரியும்:

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

கால அளவுகள் nanoseconds-ல் உள்ளன. அந்தத் தொகுதியில், எந்தவொரு குறிப்பிட்ட server-ன் அளவீட்டிற்குப் பதிலாக Ollama API ஆவணத்தில் வெளியிடப்பட்ட மாதிரிப் பதில் உள்ளது; அதில் 26 prompt tokens சுமார் 0.1 வினாடிகளையும், 237 output tokens சுமார் 4.3 வினாடிகளையும் எடுத்துக்கொண்டன. உங்கள் சொந்த உருவாக்க விகிதம் என்பது eval_count-ஐ eval_duration-ஆல் வகுத்து வினாடிகளாக மாற்றப்படுவதாகும், மேலும் உங்கள் சொந்த hardware-ல் tokens per second-ஐ அளவிடுவது மற்ற எதையும் மாற்றியமைக்கும் முன் ஒருமுறை செய்ய வேண்டியது அவசியம். அந்த விகிதம் இயந்திரத்தைப் போலவே model-ஐயும் சார்ந்துள்ளது, எனவே நீண்ட பதில்கள் உண்மையான செலவாக இருந்தால், VPS-ல் Nemotron 3.5 Lightning போன்ற வேகமான decoding-க்காக உருவாக்கப்பட்ட model, குறைந்த வரம்பு (cap) பாதுகாக்கும் நேரத்தை மீண்டும் பெற்றுத் தரும்.

மீதமுள்ளவற்றை எண்கணிதம் தீர்மானிக்கிறது. வினாடிக்கு 8 tokens என்ற விகிதத்தில், 2,000 tokens கொண்ட பதில் இயந்திரத்தை நான்கு நிமிடங்களுக்கு மேல் பிடித்து வைத்திருக்கும், மேலும் நீங்கள் ஒரு பத்தியைத்தான் எதிர்பார்த்தீர்கள் என்பது model-க்குத் தெரியாது. ஒரு reasoning model, நீங்கள் கேட்ட வார்த்தையை எழுதுவதற்கு முன்பு அதன் பட்ஜெட்டில் ஒரு பகுதியைச் சிந்திக்கச் செலவிடுகிறது, அந்தச் சிந்தனையும் மற்ற அனைத்தையும் போலவே ஒரு நேரத்தில் ஒரு token-ஆக உருவாக்கப்படுகிறது, எனவே நீங்கள் கோரும் reasoning முயற்சி அதே கட்டணத்தில் மற்றொரு காரணியாகும். சில models loop ஆகி, ஏதேனும் ஒன்று அவற்றை நிறுத்தும் வரை ஒரு சொற்றொடரைத் திரும்பத் திரும்பக் கூறலாம். வரம்பு (cap) இல்லையென்றால், அந்த ஒற்றைக் கோரிக்கை context window தீரும் வரை ஒரு core-ஐ பிஸியாக வைத்திருக்கும். num_predict என்பது அதை வரம்பிற்குள் வைக்கும் அமைப்பாகும், இது ஒரு சிறிய self-hosted Ollama VPS-ல் மிக முக்கியமானது, ஏனெனில் அங்கு ஒரு நீண்ட கோரிக்கை முழு இயந்திரத்தையும் ஆக்கிரமித்துவிடும்.

வெளியீடு பாதியில் துண்டிக்கப்படுவது பெரும்பாலும் வரம்பினால் ஏற்படுவது, மாதிரியின் பிழை அல்ல

அறிகுறிகள் மாதிரி தோல்வியடைந்தது போலத் தோன்றும். வாக்கியத்தின் பாதியில் நின்றுவிடும் பதில். இறுதி அடைப்புக்குறி (closing brace) வராததால் parse ஆகாத JSON. மாதிரியையோ அல்லது அதன் quantisation-ஐயோ குறை கூறுவது இயல்பான எதிர்வினை. முதலில் பதிலை முழுமையாகப் படியுங்கள்.

done_reason கேள்விக்கு நேரடியாகப் பதிலளிக்கிறது. stop என்பது மாதிரி தானாகவே முடிந்துவிட்டது என்று பொருள்; அது தனது end-of-sequence token-ஐ வெளியிட்டிருக்கலாம் அல்லது உங்கள் stop விருப்பத்தில் உள்ள ஏதேனும் ஒரு string-உடன் பொருந்தியிருக்கலாம். length என்பது இடவசதி தீர்ந்துவிட்டதால் உருவாக்கம் (generation) துண்டிக்கப்பட்டது என்று பொருள். length-ஐக் காணும்போது, eval_count-ஐ உங்கள் வரம்புடன் (cap) ஒப்பிட்டுப் பாருங்கள்: இரண்டும் சரியாகப் பொருந்தினால் num_predict அதை நிறுத்தியுள்ளது என்று அர்த்தம், சிறிய எண் என்றால் context window முதலில் நிரம்பிவிட்டது என்று பொருள்.

நீங்கள் stream செய்யும்போது, அந்தத் தகவல்கள் "done": true-ஐக் கொண்ட இறுதித் துண்டில் (chunk) வரும். பல client libraries அந்தத் துண்டைத் தவிர்த்துவிட்டு, உரைப்பகுதியை மட்டுமே உங்கள் code-க்கு வழங்கும். இதனால்தான் ஒரு application-க்குள் இந்தத் துண்டிப்பு விவரிக்க முடியாததாகத் தெரிகிறது, ஆனால் curl-ன் கீழ் பார்க்கும்போது தெளிவாகத் தெரிகிறது. ஒரு library இதை மறைக்கிறது என்றால், சர்வர் உண்மையில் என்ன சொன்னது என்பதைக் கண்டறிய curl-ஐப் பயன்படுத்தி ஒரு கோரிக்கையை (request) அனுப்புங்கள்.

இன்னொரு விஷயம் உங்கள் நேரத்தை மிச்சப்படுத்தும். num_predict-ஐ அதிகரிப்பது மாதிரி அதிகமாக எழுதச் செய்யாது. அது ஒரு உச்சவரம்பை மட்டுமே நீக்குகிறது. ஒரு பதில் 200 tokens-ல் done_reason மற்றும் stop உடன் முடிந்தால், மாதிரி முடிந்துவிட்டதாகத் தீர்மானித்துவிட்டது என்று பொருள்; வரம்பை அதிகரிப்பதால் எந்த மாற்றமும் இருக்காது. stop உடன் வரும் குறுகிய பதில்கள் ஒரு prompting சிக்கல். length உடன் வரும் குறுகிய பதில்கள் ஒரு வரம்புச் சிக்கல்.

மதிப்பைத் தேர்ந்தெடுத்தல்

• ஊடாடும் உரையாடல்களுக்கு (interactive chat), வரம்பை நிர்ணயிக்காமல் விட்டுவிட்டு, தேவையற்ற நீண்ட பதில்களை நிறுத்த Ctrl+C விசையைப் பயன்படுத்தவும். நீங்கள் திரையை நேரடியாகக் கண்காணித்துக் கொண்டிருக்கிறீர்கள்.
• ஸ்கிரிப்ட் மூலம் இயங்கும் பணிகளுக்கு, வரம்பை நிர்ணயிக்கவும். ஒரு லூப்பிற்குள் வரம்பற்ற generation-ஐ அனுமதித்தால், பத்து நிமிடங்களில் முடிய வேண்டிய batch job அடுத்த நாள் காலை வரை இயங்கிக் கொண்டிருக்கும்.
• கட்டமைக்கப்பட்ட வெளியீடுகளுக்கு (structured output), நீங்கள் எதிர்பார்க்கும் மிகப்பெரிய ஆவணத்தை விட சற்று அதிகமான வரம்பை அமைக்கவும். பிறகு, done_reason-ஐ length-ன் ஒரு பிழையாகக் கருதி, வந்த தரவை parse செய்வதற்குப் பதிலாக மீண்டும் முயற்சிக்கவும்.
• ஒரு coding agent-க்கு, இந்த மதிப்பு அந்த agent-ன் சொந்த configuration-ல் இருக்க வேண்டும். ஏனெனில், ஒவ்வொரு கோரிக்கையின் போதும் அந்த agent தனது சொந்த விருப்பத்தேர்வுகளை அனுப்புகிறது. Ollama-வை ஒரு coding agent-க்கு சுட்டிக்காட்டுதல் பகுதியில் இந்த அமைப்புகள் எங்கு உள்ளன என்பது விளக்கப்பட்டுள்ளது.

இந்த வரம்பு வார்த்தைகளையோ அல்லது எழுத்துக்களையோ கணக்கிடாது, tokens-ஐ மட்டுமே கணக்கிடும். எனவே, இதை உத்தேசமாக கணிக்க வேண்டாம். வரம்பு இல்லாமல் ஒரு மாதிரிப் பதிலை உருவாக்கி, eval_count-ஐப் படித்து, அந்த வரம்பை அதைவிடச் சற்று அதிகமாக அமைக்கவும். ஒவ்வொரு model குடும்பமும் tokens-ஐ வெவ்வேறு விதமாகக் கையாளும். எனவே, ஒரு Llama model-க்கு ஏற்ற மதிப்பு, அதே VPS-ல் உள்ள ஒரு Qwen 3 model-ன் பதிலை வெட்டிவிடக்கூடும்.

FAQ

Ollama-வில் num_ctx மற்றும் num_predict ஆகியவற்றுக்கு இடையே உள்ள வேறுபாடு என்ன?

num_ctx என்பது context window-ன் அளவு ஆகும்; இது மாடல் எவ்வளவு தகவலை வாசிக்க முடியும் என்பதைத் தீர்மானிக்கிறது (prompt மற்றும் இதுவரை உருவாக்கப்பட்ட அனைத்தும்). இது நினைவகத்தை (memory) அதிகம் பயன்படுத்தும், ஏனெனில் key/value cache இதற்கேற்ப வளரும். num_predict என்பது ஒரு பதிலில் மாடல் எத்தனை tokens-களை எழுதலாம் என்பதைத் தீர்மானிக்கிறது. இது நினைவகத்தை விட நேரத்தை அதிகம் எடுத்துக்கொள்ளும், மேலும் இதற்கு முன்கூட்டியே எந்த இடமும் ஒதுக்கப்படுவதில்லை. உருவாக்கப்பட்ட tokens இரண்டிற்கும் பொதுவானவை என்பதால், ஏதேனும் ஒன்றின் வரம்பை எட்டினாலும் பதில் பாதியிலேயே நின்றுவிடலாம்.

எனது num_predict அமைப்பு ஏன் புறக்கணிக்கப்படுகிறது?

ஏனெனில், கோரிக்கையுடன் (request) அனுப்பப்படும் மதிப்பு, மாடலில் சேமிக்கப்பட்ட மதிப்பை விட முன்னுரிமை பெறும். ஒரு Modelfile-ல் PARAMETER num_predict 512-ஐ அமைத்துவிட்டு, அந்த மாடலை ஒரு chat front end அல்லது coding agent மூலம் இயக்கினால், client தனது சொந்த options object-ஐ அனுப்பும், அதுவே வெற்றி பெறும். ollama show --parameters உங்கள் மதிப்பைத்தான் காட்டும், ஏனெனில் அது சேமிக்கப்பட்ட மாடலை மட்டுமே வாசிக்கும்; HTTP வழியாக என்ன வருகிறது என்பதை அதனால் பார்க்க முடியாது. "options": {"num_predict": 32}-ஐப் பயன்படுத்தி curl உடன் ஒரு கோரிக்கையை அனுப்பி, eval_count என்பது 32 என வருகிறதா என்று சரிபார்க்கவும். இது server சரியாகச் செயல்படுவதை உறுதிப்படுத்தும், அதன் பிறகு உங்கள் application-ல் சிக்கலைத் தேடலாம்.

எனது வெளியீடு num_predict-ஆல் நிறுத்தப்பட்டதா என்பதை எப்படி அறிவது?

"stream": false உடன் கோரிக்கையை அனுப்பி, done_reason-ஐ வாசிக்கவும். stop என்ற மதிப்பு இருந்தால், மாடல் தானாகவே முடித்துவிட்டது என்று அர்த்தம். length என்ற மதிப்பு இருந்தால், அதற்கு இடம் போதவில்லை என்று அர்த்தம். பிறகு eval_count-ஐ உங்கள் வரம்புடன் ஒப்பிடவும்: இரண்டும் சரியாகப் பொருந்தினால், num_predict அதை நிறுத்தியுள்ளது என்று பொருள். eval_count சிறியதாக இருந்தால், context window முதலில் நிரம்பிவிட்டது என்று பொருள். Streaming செய்யும்போது, இந்த இரண்டு புலங்களும் இறுதி chunk-ல் "done": true உடன் வரும்; பல client libraries உங்கள் code-க்குக் கிடைப்பதற்கு முன்பே இதை நீக்கிவிடும்.

num_predict-ன் இயல்புநிலை (default) மதிப்பு என்ன?

கட்டுரைகளை நம்புவதை விட, உங்கள் சொந்த நிறுவலிலிருந்து (install) இதைப் படிக்கவும். ஆகஸ்ட் 2026 நிலவரப்படி, Ollama Modelfile குறிப்பு இயல்புநிலை மதிப்பை -1 எனக் குறிப்பிடுகிறது; அதாவது generation-க்கு வரம்பு இல்லை. 128 என்று பல ஆண்டுகளாக ஆவணப்படுத்தப்பட்ட பிறகு, 2024 இறுதியில் இந்தத் தகவல் திருத்தப்பட்டது. எதிர்மறை மதிப்புகள் (negative values) எண்ணிக்கையைக் குறிக்காமல், ஒரு குறியீடாகச் செயல்படுகின்றன. அதே அட்டவணையின் பழைய பதிப்புகள், மீதமுள்ள context-ஐ நிரப்ப -2-ஐக் குறிப்பிட்டிருந்தன. உங்கள் பதிப்பிற்கான Modelfile parameter reference-ஐச் சரிபார்த்து, அதை ollama show --parameters மற்றும் ஒரு curl கோரிக்கை மூலம் உறுதிப்படுத்தவும்.

num_predict-ஐ அதிகரித்தால் மாடல் நீண்ட பதில்களை எழுதுமா?

இல்லை. இது ஒரு உச்சவரம்பை (ceiling) மட்டுமே நீக்குகிறது. ஒரு பதில் stop-ல் done_reason என முடிந்தால், மாடல் தானாகவே முடிவெடுத்துவிட்டது என்று அர்த்தம்; வரம்பை அதிகரிப்பதால் எந்த மாற்றமும் இருக்காது. அத்தகைய சூழலில் பதிலின் நீளம் என்பது prompting சார்ந்த விஷயம்: ஒரு குறிப்பிட்ட அமைப்பு, பிரிவுகளின் எண்ணிக்கை அல்லது விரிவான விளக்கத்தைக் கேட்கவும். done_reason என்பது length என வரும்போது மட்டுமே num_predict-ஐ அதிகரிக்கவும்.