Ollamaలో num_predictతో output పొడవు పరిమితి

Ollamaలో num_predict చేసే పని

num_predict అనేది ఒక సమాధానంలో మోడల్ గరిష్ఠంగా రూపొందించగల tokens సంఖ్యను పరిమితం చేసే Ollama option. ఇది output tokens ను మాత్రమే లెక్కిస్తుంది. కాబట్టి prompt ఈ పరిమితిలోకి రాదు. మోడల్ ఈ పరిమితిని చేరుకున్నప్పుడు, ఆ స్థానంలోనే generation ఆగిపోతుంది. కొన్నిసార్లు పదం మధ్యలో కూడా ఆగవచ్చు. అప్పుడు response లో done_reason విలువ length గా ఉంటుంది.

ఈ feature మొత్తం ఇంతే. కానీ Ollamaలో ఈ విలువను సెట్ చేయడానికి మూడు వేర్వేరు స్థలాలు ఉన్నాయి. Requestకు అత్యంత సమీపంలో ఉన్న setting అమలవుతుంది. "num_predict does nothing" అనే దాదాపు ప్రతి నివేదికలో ఒక layer మరొక layer settingను నిశ్శబ్దంగా override చేస్తుంది.

num_predict అనేది num_ctx కాదు

Ollamaలో ఈ రెండు ఎంపికలను మరే ఇతర జంటకన్నా ఎక్కువగా గందరగోళపరుస్తారు. దీనివల్ల debugging కోసం వాస్తవ సమయం వృథా అవుతుంది.

num_ctx ద్వారా model ఎంత చదవగలదో నిర్ణయించబడుతుంది. ఇది context window పరిమాణం. ఇందులో prompt మరియు ఇప్పటివరకు ఉత్పత్తి చేసిన మొత్తం కంటెంట్ ఉంటాయి. దీన్ని పెంచితే memory వినియోగం పెరుగుతుంది, ఎందుకంటే ఆ tokens కోసం model నిర్వహించే key/value cache window పరిమాణంతో పాటు పెరుగుతుంది. మీ hardware కోసం num_ctx పరిమాణాన్ని నిర్ణయించడం అనేది ప్రత్యేకమైన పని. దీనికి సంబంధించిన failure modes కూడా వేర్వేరుగా ఉంటాయి.

num_predict ద్వారా model ఎంత వ్రాయగలదో నిర్ణయించబడుతుంది. ఇది allocation కాదు; ఇది ఆపే నియమం. దీన్ని పెంచితే RAM కంటే wall-clock time ఎక్కువగా అవసరమవుతుంది. ముందుగానే ఏదీ reserve చేయబడదు.

ఈ రెండు ఒకే చోట కలుస్తాయి. Generated tokens ఉత్పత్తి అవుతున్నప్పుడు context windowలో చేరుతాయి. అందువల్ల మీ cap చేరకముందే window నిండిపోయిన కారణంగా కూడా reply ఆగిపోవచ్చు. ఈ రెండు సందర్భాల్లోనూ Ollama length ను report చేస్తుంది. కాబట్టి ఈ రెండింటిని వేరు చేసే సంఖ్య eval_count. దీని గురించి దిగువన మరింత వివరించబడుతుంది.

Modelfile తో ఒకసారి సెట్ చేయండి

Modelfile మీరు సృష్టించే మోడల్‌లో ఆ విలువను శాశ్వతంగా పొందుపరుస్తుంది. ఫైల్‌ను రాయండి:

FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 512

తర్వాత దాన్ని build చేసి, మీరు build చేసిన నిర్వచనాన్ని తిరిగి చదవండి:

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

ollama show --parameters నిల్వ చేసిన ప్రతి parameter కు దాని value తో ఒక line ను ముద్రిస్తుంది. ఆ output లో num_predict లేకపోతే, మోడల్‌లో ముందుగానే పొందుపరిచిన పరిమితి లేదు; Ollama యొక్క స్వంత default వర్తిస్తుంది. ollama show --modelfile qwen3-capped మొత్తం definition ను ముద్రిస్తుంది. ఇప్పటికే ఉన్న మోడల్‌లో ship అయ్యే parameters ను copy చేయడానికి ఇదే వేగవంతమైన మార్గం.

ప్రతి caller స్వయంచాలకంగా పొందాలని మీరు కోరుకునే value కు ఇది సరైన layer. అయితే ఈ value తుది విలువగా ఉంటుందని మీరు భావిస్తే, ఇది సరైన 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. ఇవన్నీ మీకు దాని కోసం ప్రత్యేక box కనిపించకపోయినా, ఒక options object ను పంపుతాయి.

/set parameter తో ఒక session కోసం దీన్ని సెట్ చేయండి

ollama run లో interactive session, మిగిలిన session కోసం options ను సెట్ చేస్తుంది:

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

/show parameters మీరు పంపే తదుపరి message తో session ఏమి పంపుతుందో చూపిస్తుంది. అందువల్ల మార్పు అమలైందో లేదో నిర్ధారించడానికి ఇది వేగవంతమైన మార్గం. మీరు /bye టైప్ చేసే వరకు 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. కాబట్టి అక్కడ మీరు set చేసినది ఆ request యొక్క optionsగా పంపబడుతుంది. అందుకే అది ఆ session కోసం Modelfile setting ను override చేస్తుంది.

ఇప్పుడు దీనివల్ల అర్థమయ్యే సమస్యను చూద్దాం. మీరు PARAMETER num_predict 512 జోడించి model ను మళ్లీ build చేసినా, replies వేలాది tokens వరకు కొనసాగుతాయి. మీ setting ఉంది; ollama show --parameters కూడా దాన్ని నిర్ధారిస్తుంది. అయితే ప్రతి request లో అది override అవుతోంది. కారణం client తన స్వంత సంఖ్యతో కూడిన options object ను పంపుతోంది. చాలాసార్లు ఆ సంఖ్యను మీరు నెలల క్రితం settings screen లో నమోదు చేసి, తరువాత మర్చిపోయి ఉంటారు. ollama show stored model ను చదువుతుంది. HTTP ద్వారా వాస్తవంగా వచ్చినదాన్ని అది చూపించదు.

ఒకే command తో server వైపు దీనిని నిర్ధారించండి. Long answer ఉత్పత్తి చేసే request పంపండి, cap ను తక్కువగా force చేయండి, తరువాత రెండు 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 ఫలితాలు వస్తే, server ఆ option ను గౌరవిస్తోంది; మీ application వేరే value పంపుతోంది. ఒక request గురించి server స్వయంగా నమోదు చేసిన వివరాలు చూడాలంటే, environment లో OLLAMA_DEBUG=1 తో దాన్ని restart చేసి, మీ application దానితో మాట్లాడుతున్నప్పుడు journalctl -u ollama -f ను monitor చేయండి.

ప్రతికూల విలువలు, కాపీ చేయకూడని సంఖ్యలు

num_predict ప్రతికూల విలువలను కూడా అంగీకరిస్తుంది. అవి countలుగా కాకుండా sentinelలుగా పంపబడతాయి. ఒక ప్రతికూల విలువ అంటే “దీనికి పరిమితి విధించవద్దు, generation కొనసాగించండి” అని అర్థం. మరొక విలువకు “మిగిలిన contextను పూరించండి” అనే అర్థం ఉంది. August 2026 నాటికి Ollama Modelfile reference లో defaultగా -1, అంటే infinite generation, చూపిస్తోంది. అదే పట్టికలోని పాత versionలు contextను పూరించడానికి -2 ను కూడా చూపించాయి.

ఇవన్నీ versionపై ఆధారపడినవిగా పరిగణించండి, ఎందుకంటే ఈ ప్రవర్తనలో మార్పులు వచ్చాయి. 2024 చివర్లో entry సరిచేసే వరకు reference చాలా కాలం defaultను 128గా నమోదు చేసింది. అందువల్ల అనేక guides ఇప్పటికీ పాత సంఖ్యను పునరావృతం చేస్తున్నాయి. మీరు వాస్తవంగా నడుపుతున్న versionకు సంబంధించిన Modelfile parameter referenceను చదవండి. తరువాత పై eval_count checkతో ప్రవర్తనను నిర్ధారించండి. మీరు స్వయంగా మీ boxపై verify చేసిన విలువ, ఈ 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 కంటే చాలా ఎక్కువగా ఉంటుంది.

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గా మార్చిన విలువ. ఏ ఇతర tuning చేయకముందు మీ స్వంత hardwareపై tokens per secondను కొలవడం ఉపయోగకరంగా ఉంటుంది. ఆ rate machineపై మాత్రమే కాకుండా modelపై కూడా ఆధారపడుతుంది. కాబట్టి పొడవైన answersే అసలు వ్యయం అయితే, వేగవంతమైన decoding కోసం రూపొందించిన VPSపై Nemotron 3.5 Lightning వంటి model, తక్కువ cap రక్షిస్తున్న సమయాన్ని కొంత తిరిగి ఇస్తుంది.

మిగిలినదాన్ని arithmetic స్పష్టం చేస్తుంది. 8 tokens per second వేగంతో 2,000 token answerకు నాలుగు నిమిషాలకంటే ఎక్కువ సమయం పడుతుంది. మీరు ఒక paragraph మాత్రమే కోరుకున్నారని modelకు తెలియదు. కొన్ని models loopలోకి వెళ్లి, ఏదైనా వాటిని ఆపే వరకు ఒక phraseను మళ్లీ మళ్లీ repeat చేస్తాయి. Cap లేకపోతే context window పూర్తయ్యే వరకు ఆ ఒక్క request ఒక coreను busyగా ఉంచుతుంది. దాన్ని పరిమితం చేసే setting num_predict. ఒక పొడవైన request మొత్తం machineను ఆక్రమించగల చిన్న self-hosted Ollama VPSలో ఇది ముఖ్యంగా అవసరం.

Truncated output సాధారణంగా broken model కాదు; cap కారణంగానే వస్తుంది

లక్షణాలు model failure లాగా కనిపిస్తాయి. సమాధానం వాక్యం మధ్యలోనే ఆగిపోవచ్చు. Closing brace రాకపోవడంతో JSON parse కాకపోవచ్చు. వెంటనే model లేదా quantisation ను నిందించాలనిపిస్తుంది. ముందుగా response ను పరిశీలించండి.

done_reason అంటే సమాధానం ప్రశ్నకు నేరుగా ఇచ్చిందని అర్థం. stop అంటే model స్వయంగా పూర్తయిందని అర్థం. ఇది end-of-sequence token ను emit చేయడం వల్ల కావచ్చు లేదా మీ stop option లోని strings లో ఒకదానితో సరిపోవడం వల్ల కావచ్చు. length అంటే generation కు అందుబాటులో ఉన్న స్థలం పూర్తవడంతో అది మధ్యలోనే నిలిచిందని అర్థం. length కనిపించినప్పుడు, eval_count ను మీ cap తో పోల్చండి: రెండు ఒకేలా ఉంటే num_predict generation ను ఆపింది. చిన్న సంఖ్య ఉంటే context window ముందుగా పూర్తయింది.

మీరు stream ఉపయోగించినప్పుడు, ఈ fields final chunk లో వస్తాయి. ఆ chunk లో "done": true ఉంటుంది. అనేక client libraries ఆ chunk ను discard చేసి, మీ code కు text ను మాత్రమే అందిస్తాయి. అందుకే application లో అదే truncation కారణం తెలియనట్టుగా కనిపిస్తుంది, కానీ curl కింద స్పష్టంగా కనిపిస్తుంది. Library ఆ సమాచారాన్ని దాచిపెడితే, server నిజంగా ఏమి చెప్పిందో తెలుసుకోవడానికి curl తో ఒక request పంపండి.

ఇంకొక విషయం గుర్తుంచుకుంటే సమయం వృథా కాదు. num_predict పెంచడం వల్ల model మరింత రాయదు. అది కేవలం పరిమితిని తొలగిస్తుంది. Reply 200 tokens వద్ద done_reason తో ముగిసి, stop గా ఉంటే, model తన సమాధానం పూర్తయిందని నిర్ణయించింది. పెద్ద cap పెట్టినా మార్పు ఉండదు. stop ఉన్న చిన్న సమాధానాలు prompting సమస్యను సూచిస్తాయి. length ఉన్న చిన్న సమాధానాలు cap సమస్యను సూచిస్తాయి.

విలువను ఎంచుకోవడం

• ఇంటరాక్టివ్ chat కోసం గరిష్ఠ పరిమితి విధించకుండా వదిలేయండి. అదుపు తప్పిన reply ను ఆపడానికి Ctrl+C నొక్కండి. మీరు screen ను ఎలాగూ గమనిస్తూనే ఉంటారు.
• Script ద్వారా నడిచే పనులకు పరిమితిని సెట్ చేయండి. loop లో గరిష్ఠ పరిమితి లేని generation ఉంటే, పది నిమిషాల్లో పూర్తవ్వాల్సిన batch job మరుసటి ఉదయం కూడా నడుస్తూనే ఉంటుంది.
• Structured output కోసం, మీరు ఊహించే అతిపెద్ద చెల్లుబాటు అయ్యే 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 tokens ను వేర్వేరు విధాలుగా 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 లో మోడల్ గరిష్ఠంగా ఎన్ని tokens రాయవచ్చో నిర్ణయిస్తుంది. దీనికి memory కంటే time ఎక్కువగా అవసరం; ముందుగానే ఏదీ reserve చేయబడదు. Generated tokens రెండింటి పరిమితికీ లెక్కలోకి వస్తాయి. అందువల్ల reply ఏ పరిమితి వల్లనైనా ముందుగానే ఆగిపోవచ్చు.

నా num_predict setting పట్టించుకోనట్టుగా ఎందుకు కనిపిస్తోంది?

Request తో పంపిన value, model లో నిల్వ చేసిన value ను override చేస్తుంది. Modelfile లో PARAMETER num_predict 512 ఉంచి, ఆ model ను chat front end లేదా coding agent ద్వారా నడిపితే, client తన స్వంత options object ను పంపుతుంది. అందులోని సంఖ్యకే ప్రాధాన్యం ఉంటుంది. ollama show --parameters మాత్రం మీ value ను చూపిస్తూనే ఉంటుంది, ఎందుకంటే అది నిల్వ చేసిన model ను మాత్రమే చదువుతుంది; HTTP ద్వారా వచ్చిన value దానికి కనిపించదు. "options": {"num_predict": 32} ఉపయోగించి curl తో ఒక request పంపి, eval_count విలువ 32గా తిరిగి వచ్చిందో చూడండి. దీనివల్ల server సరిగ్గా పనిచేస్తోందని నిర్ధారించవచ్చు. తరువాత సమస్యను మీ application లో వెతకవచ్చు.

నా output num_predict వల్ల కత్తిరించబడిందో ఎలా తెలుసుకోవచ్చు?

"stream": false తో request పంపి, done_reason ను చదవండి. stop విలువ అంటే model స్వయంగా పూర్తిచేసిందని అర్థం. length విలువ అంటే దానికి అందుబాటులో ఉన్న స్థలం అయిపోయిందని అర్థం. తరువాత eval_count ను మీ cap తో పోల్చండి. రెండూ ఖచ్చితంగా సమానంగా ఉంటే num_predict దాన్ని ఆపింది. eval_count విలువ దాని కంటే తక్కువగా ఉంటే context window ముందుగా నిండిపోయింది. Streaming సమయంలో రెండు fields కూడా "done": true ఉన్న final chunk లో వస్తాయి. మీ code చూడకముందే అనేక client libraries ఆ chunk ను discard చేస్తాయి.

num_predict యొక్క default value ఏమిటి?

ఒక article పై ఆధారపడకుండా మీ స్వంత install నుంచి value ను చదవండి. August 2026 నాటికి Ollama Modelfile reference default ను -1గా చూపిస్తోంది. అంటే generation కు cap లేదు. 2024 చివర్లో ఆ entry సరిచేయబడింది. అంతకు ముందు ఎన్నో సంవత్సరాలు 128 అని documentation లో చూపించారు. Negative values counts కాదు; అవి sentinels. అదే table యొక్క పాత versions మిగిలిన context ను నింపడానికి -2 ను కూడా చూపించేవి. మీ version కోసం Modelfile parameter reference చూడండి. తరువాత ollama show --parameters తో నిర్ధారించి, curl request పంపండి.

num_predict పెంచితే model ఎక్కువ పొడవైన answers రాస్తుందా?

లేదు. అది కేవలం ఒక ceiling ను తొలగిస్తుంది. Reply done_reason of stop తో ముగిస్తే, model తాను పూర్తయ్యిందని నిర్ణయించిందని అర్థం. పెద్ద cap పెట్టినా ఫలితం మారదు. ఈ సందర్భంలో length అనేది prompting కు సంబంధించిన విషయం. నిర్దిష్ట structure, section count లేదా వివరాల స్థాయిని అడగండి. done_reason, length గా తిరిగి వచ్చినప్పుడు మాత్రమే num_predict ను పెంచండి.