Ollama num_predict output அளவை எப்படிக் கட்டுப்படுத்தும்?

Ollama-ல் num_predict என்ன செய்கிறது

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

இந்த feature-ன் செயல்பாடு இதுவே. ஆனால் Ollama-ல் இந்த மதிப்பை அமைக்க மூன்று தனித்தனி இடங்கள் உள்ளன. Request-க்கு மிக அருகிலுள்ள setting முன்னுரிமை பெறும். “num_predict எதுவும் செய்யவில்லை” என்ற பெரும்பாலான reports-க்கு காரணம், ஒரு layer மற்றொரு layer-ன் setting-ஐ அமைதியாக override செய்வதாகும்.

num_predict என்பது num_ctx அல்ல

Ollama-வில் வேறு எந்த இரண்டு options-ஐ விடவும் இந்த இரண்டு options அதிகமாகக் குழப்பப்படுகின்றன. இந்தக் குழப்பம் உண்மையான debugging நேரத்தை வீணாக்குகிறது.

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

num_predict என்பது model எவ்வளவு எழுதும் என்பதைக் குறிக்கிறது. இது ஒரு stopping rule; memory allocation அல்ல. இதை அதிகரிப்பதால் RAM பயன்படுத்தப்படாது; wall-clock time மட்டும் அதிகரிக்கும். முன்கூட்டியே எந்த memory-யும் ஒதுக்கப்படாது.

இந்த இரண்டு options-ம் ஒரே இடத்தில் தொடர்பு கொள்கின்றன. Generated tokens உருவாகும் போதே context window-க்குள் சேர்க்கப்படுகின்றன. ஆகவே, உங்கள் cap எட்டப்படுவதற்கு முன்பே window நிரம்பியதாலும் reply நிறுத்தப்படலாம். இரண்டு நிலைகளிலும் Ollama length-ஐ report செய்கிறது. அவற்றை வேறுபடுத்தும் எண் eval_count ஆகும்; இது கீழே மேலும் விளக்கப்பட்டுள்ளது.

Modelfile மூலம் ஒருமுறை அமைக்கவும்

நீங்கள் உருவாக்கும் model-ல் Modelfile அந்த மதிப்பை உள்ளமைக்கிறது. இந்த file-ஐ எழுதவும்:

FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 512

பிறகு அதை build செய்து, உருவாக்கிய definition-ஐ மீண்டும் பார்க்கவும்:

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

ollama show --parameters சேமிக்கப்பட்ட ஒவ்வொரு parameter-க்கும் அதன் value-ஐ தனித்தனி வரியில் அச்சிடும். அந்த output-ல் num_predict இல்லையெனில், அந்த model-ல் உள்ளமைக்கப்பட்ட வரம்பு இல்லை; Ollama-வின் சொந்த default பயன்படுத்தப்படும். ollama show --modelfile qwen3-capped முழு definition-ஐ அச்சிடும். ஏற்கனவே உள்ள model-ல் ship செய்யப்பட்ட parameters-ஐ நகலெடுக்க இதுவே விரைவான வழியாகும்.

ஒவ்வொரு caller-மும் பெற வேண்டும் என்று நீங்கள் விரும்பும் மதிப்புக்கு இது சரியான layer ஆகும். ஆனால் இது இறுதி மதிப்பாக இருக்கும் என்று எதிர்பார்த்தால், இது சரியான layer அல்ல. ollama show --parameters கையேடு நடைமுறையில் பயன்படுத்தப்படும் command ஆக இருப்பதால், அதை மாற்றமின்றி வைத்துள்ளேன்.

ஒவ்வொரு request-க்கும் அதை 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

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

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

வரிசை சுருக்கமானது. Request உடன் அனுப்பப்படும் options அனைத்தையும் மிஞ்சும். Model-ன் Modelfile-ல் உள்ள PARAMETER num_predict line, request-ல் எந்த value-மும் இல்லாதபோது பயன்படுத்தப்படும் fallback ஆகும். இரண்டும் இல்லையெனில், Ollama-வின் built-in default அமலாகும்.

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

இது விளக்கும் failure இப்போது பார்க்கலாம். நீங்கள் PARAMETER num_predict 512 சேர்த்து model-ஐ rebuild செய்கிறீர்கள். ஆனால் replies இன்னும் ஆயிரக்கணக்கான tokens வரை செல்கின்றன. உங்கள் setting உள்ளது என்பதை ollama show --parameters உறுதிப்படுத்துகிறது. ஆனால் ஒவ்வொரு request-லும் அது override செய்யப்படுகிறது. காரணம், client தனக்கென ஒரு options object-ஐவும் அதில் தனக்கென ஒரு எண்ணையும் அனுப்புகிறது. அந்த எண், பல மாதங்களுக்கு முன் settings screen-ல் நீங்கள் உள்ளிட்டதும் பின்னர் மறந்துவிட்டதுமாக இருக்கலாம். ollama show stored model-ஐப் படிக்கிறது. HTTP மூலம் உண்மையில் வரும் value-ஐ அது காட்ட முடியாது.

ஒரே command மூலம் server பக்கத்தை உறுதிப்படுத்தலாம். நீண்ட பதிலை உருவாக்கும் request-ஐ அனுப்புங்கள். cap-ஐ குறைந்த value-ஆக கட்டாயப்படுத்துங்கள். பின்னர் இரண்டு 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 செய்ய வேண்டும். jq இல்லை என்றால், முதலில் sudo apt install -y jq மூலம் அதை install செய்யுங்கள். "length" மற்றும் 32 என்ற response கிடைத்தால், server அந்த option-ஐ ஏற்றுக்கொள்கிறது என்றும் உங்கள் application வேறு value-ஐ அனுப்புகிறது என்றும் பொருள். ஒரு request குறித்து server-ன் சொந்த பதிவைப் பார்க்க, environment-ல் OLLAMA_DEBUG=1 உடன் அதை restart செய்யுங்கள். உங்கள் application அதனுடன் தொடர்புகொள்ளும் போது journalctl -u ollama -f-ஐ monitor செய்யுங்கள்.

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

num_predict எதிர்மறை மதிப்புகளையும் ஏற்கிறது. அவை count-களாக அல்லாமல் sentinel-களாக அனுப்பப்படுகின்றன. ஒரு எதிர்மறை மதிப்பு, இதற்கு cap விதிக்க வேண்டாம், generation-ஐ தொடர்ந்து செய்ய வேண்டும் என்பதைக் குறிக்கிறது. மற்றொரு மதிப்பு, மீதமுள்ள context-ஐ நிரப்ப வேண்டும் என்பதைக் குறித்துள்ளது. August 2026 நிலவரப்படி, Ollama Modelfile reference-ல் default மதிப்பு -1, அதாவது infinite generation எனக் குறிப்பிடப்பட்டுள்ளது. இதே அட்டவணையின் முந்தைய versions-ல் context-ஐ நிரப்புவதற்கான மதிப்பாக -2-மும் குறிப்பிடப்பட்டிருந்தது.

இவை அனைத்தும் version-dependent எனக் கருதுங்கள்; காரணம், இந்த விவரம் மாறியுள்ளது. 2024-ன் இறுதி வரை reference நீண்ட காலமாக default மதிப்பை 128 எனக் குறிப்பிட்டிருந்தது. அந்த entry பின்னர் திருத்தப்பட்டதால், பல guides இன்னும் பழைய எண்ணையே மீண்டும் குறிப்பிடுகின்றன. நீங்கள் உண்மையில் இயக்கும் version-க்கான Modelfile parameter reference-ஐப் படிக்கவும். பின்னர் மேலே உள்ள eval_count check மூலம் behavior-ஐ உறுதிப்படுத்தவும். உங்கள் சொந்த box-ல் சரிபார்த்த மதிப்பு, இந்த post உட்பட வேறு எங்கும் படித்த மதிப்பைவிட நம்பகமானது.

CPU-only VPS-ல் output length ஏன் முக்கிய செலவாகிறது

Generation இரண்டு phases-ஆக நடைபெறும்; அவற்றின் வேகம் மிகவும் வேறுபடும். Prompt tokens batch-களாக, ஒரே நேரத்தில் பல tokens கணக்கிடப்பட்டு evaluate செய்யப்படும். Output tokens ஒவ்வொன்றாக உருவாக்கப்படும்; ஒவ்வொரு 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-ஆக மாற்றிய மதிப்பு. மேலும், எதையும் tune செய்வதற்கு முன் உங்கள் சொந்த hardware-ல் tokens per second-ஐ அளவிடுவது பயனுள்ளதாகும். இந்த rate, machine-ஐப் போலவே model-ஐயும் சார்ந்தது. எனவே நீண்ட பதில்களே உண்மையான செலவாக இருந்தால், VPS-ல் Nemotron 3.5 Lightning போன்ற fast decoding-க்காக உருவாக்கப்பட்ட model, குறைந்த cap பாதுகாக்கும் நேரத்தின் ஒரு பகுதியை மீட்டுத் தரும்.

மீதமுள்ளதை arithmetic தெளிவுபடுத்துகிறது. ஒரு second-க்கு 8 tokens என்ற வேகத்தில், 2,000 tokens கொண்ட பதில் machine-ஐ நான்கு minutes-க்கும் மேலாக busy-ஆக வைத்திருக்கும். நீங்கள் ஒரு paragraph மட்டுமே கேட்டீர்கள் என்பது model-க்கு தெரியாது. சில models loop செய்து, ஏதாவது ஒன்று நிறுத்தும் வரை ஒரே phrase-ஐ மீண்டும் மீண்டும் உருவாக்கும். Cap இல்லையெனில், context window நிரம்பும் வரை அந்த ஒரு request ஒரு CPU core-ஐ busy-ஆக வைத்திருக்கும். num_predict என்பது இதற்கு எல்லை நிர்ணயிக்கும் setting ஆகும். ஒரு நீண்ட request முழு machine-ஐயே பயன்படுத்தக்கூடிய சிறிய self-hosted Ollama VPS-ல் இது மிகவும் முக்கியமானது.

Truncated output பொதுவாக cap காரணமாக ஏற்படும்; model பழுதடைந்ததால் அல்ல

இதன் அறிகுறிகள் model failure போலத் தோன்றும். ஒரு பதில் வாக்கியத்தின் நடுவில் நின்றுவிடும். Closing brace வராததால் JSON parse ஆகாது. உடனடி எதிர்வினையாக model அல்லது quantisation-ஐ குறை கூறுவார்கள். முதலில் response-ஐப் படிக்கவும்.

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

நீங்கள் stream செய்யும்போது, இந்த fields இறுதி chunk-ல் வரும்; அந்த chunk-ல் "done": true இருக்கும். பல client libraries அந்த chunk-ஐ discard செய்து, text-ஐ மட்டும் உங்கள் code-க்கு வழங்குகின்றன. அதனால் application-க்குள் அதே truncation காரணம் தெரியாததாகத் தோன்றும்; curl-ல் அது தெளிவாகத் தெரியும். Library அதை மறைத்தால், curl உடன் ஒரு request அனுப்பி server உண்மையில் என்ன தெரிவித்தது என்பதை அறியவும்.

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

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

• Interactive chat-க்கு வரம்பு அமைக்காமல் விட்டுவிட்டு, கட்டுப்பாடின்றி நீளும் reply-ஐ நிறுத்த Ctrl+C அழுத்தவும். நீங்கள் திரையைப் பார்த்துக்கொண்டே இருப்பீர்கள்.
• Script மூலம் இயக்கப்படும் எதற்கும் வரம்பை அமைக்கவும். Loop-க்குள் வரம்பில்லாத generation இருப்பதால், பத்து நிமிடங்களில் முடிக்க வேண்டிய batch job அடுத்த நாள் காலையிலும் இயங்கிக்கொண்டிருக்கும்.
• Structured output-க்கு, எதிர்பார்க்கும் மிகப்பெரிய valid document-ஐ விட cap-ஐ அதிகமாக அமைக்கவும். பின்னர் done_reason of length ஏற்பட்டால் அதை hard error-ஆகக் கருதி, கிடைத்த output-ஐ parse செய்வதற்குப் பதிலாக retry செய்யவும்.
• Coding agent-க்கு இந்த மதிப்பு agent-ன் சொந்த configuration-ல் இருக்க வேண்டும். ஒவ்வொரு request-லும் agent தன் சொந்த options-ஐ அனுப்பும். Coding agent-ஐ Ollama-க்கு சுட்டிக்காட்டுதல் என்ற பகுதியில் இந்த settings எங்கு உள்ளன என்பது விளக்கப்பட்டுள்ளது.

இந்த cap tokens-ஐ எண்ணுகிறது; words அல்லது characters-ஐ அல்ல. எனவே இதை ஊகித்து அமைக்க வேண்டாம். முதலில் cap இல்லாமல் ஒரு பிரதிநிதித்துவமான answer-ஐ generate செய்து, eval_count-ஐப் படிக்கவும். பின்னர் அதைவிட போதுமான அளவு அதிகமாக limit-ஐ அமைக்கவும். Model families வேறுபட்ட முறையில் tokenise செய்யும். ஆகவே, ஒரு Llama model-ல் பொருந்தும் value, அதே VPS-ல் இயங்கும் Qwen 3 model-இலிருந்து வரும் அதே answer-ஐ truncate செய்யக்கூடும்.

FAQ

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

num_ctx என்பது context window-ன் அளவு. எனவே model எவ்வளவு உள்ளீட்டைப் படிக்க முடியும் என்பதை இது நிர்ணயிக்கிறது: prompt மற்றும் இதுவரை உருவாக்கப்பட்ட அனைத்தும் இதில் அடங்கும். இதற்கு memory தேவைப்படும், ஏனெனில் key/value cache இதனுடன் சேர்ந்து பெரிதாகும். num_predict என்பது ஒரு response-ல் model எழுதக்கூடிய token-களின் அதிகபட்ச எண்ணிக்கையை நிர்ணயிக்கிறது. இதற்கு memory-யைவிட time அதிகமாக தேவைப்படும்; முன்கூட்டியே எதுவும் reserve செய்யப்படாது. உருவாக்கப்பட்ட token-கள் இரண்டிற்கும் எதிராகக் கணக்கிடப்படும். எனவே இரண்டில் ஏதேனும் ஒன்றால் reply முன்கூட்டியே நிறுத்தப்படலாம்.

எனது num_predict அமைப்பு புறக்கணிக்கப்படுவது போலத் தெரிகிறது. ஏன்?

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-ஐ அதனால் பார்க்க முடியாது. "options": {"num_predict": 32}-ஐப் பயன்படுத்தி curl உடன் ஒரு request அனுப்பவும். பின்னர் eval_count 32 ஆகத் திரும்புகிறதா என்பதைச் சரிபார்க்கவும். இது server சரியாக இயங்குகிறது என்பதை உறுதிப்படுத்தும்; அடுத்ததாக உங்கள் application-ல் காரணத்தைத் தேடலாம்.

num_predict காரணமாக எனது output துண்டிக்கப்பட்டதா என்பதை எப்படித் தெரிந்துகொள்வது?

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

num_predict-ன் default value என்ன?

ஒரு article-ஐ நம்பாமல், உங்கள் சொந்த install-லிருந்து இதைப் படிக்கவும். August 2026 நிலவரப்படி, Ollama Modelfile reference default-ஐ -1 எனக் குறிப்பிடுகிறது. இதன் பொருள் generation-க்கு cap இல்லை. பல ஆண்டுகளாக 128 என ஆவணப்படுத்தப்பட்டிருந்த இந்த entry, 2024-ன் இறுதியில் திருத்தப்பட்டது. Negative values counts அல்ல; அவை sentinel values. இதே table-ன் பழைய versions, மீதமுள்ள context-ஐ நிரப்புவதற்கான -2 value-ஐயும் குறிப்பிட்டிருந்தன. உங்கள் version-க்கான Modelfile parameter reference-ஐப் பார்க்கவும். பின்னர் ollama show --parameters மற்றும் ஒரு curl request மூலம் அதை உறுதிப்படுத்தவும்.

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

இல்லை. இது ஒரு ceiling-ஐ மட்டும் நீக்குகிறது. done_reason மற்றும் stop உடன் reply முடிந்தால், model முடித்துவிட்டதாகத் தீர்மானித்துள்ளது; பெரிய cap எந்த மாற்றத்தையும் ஏற்படுத்தாது. அந்தச் சூழலில் length என்பது prompting தொடர்பான கேள்வி. குறிப்பிட்ட structure, section count, அல்லது தேவையான detail level-ஐக் கேட்கவும். done_reason length ஆகத் திரும்பும்போது மட்டும் num_predict-ஐ அதிகரிக்கவும்.