Ollamaలో num_predictతో output పొడవు పరిమితం చేయడం

Ollamaలో num_predict చేసే పని

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

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

num_predict అనేది num_ctx కాదు

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

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

num_predict మోడల్ ఎంత వరకు వ్రాయగలదో నిర్దేశిస్తుంది. ఇది stopping rule, allocation కాదు. దీన్ని పెంచితే RAM కంటే wall-clock time ఎక్కువగా ఖర్చవుతుంది. ముందుగానే ఏదీ reserve చేయబడదు.

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

Modelfile తో ఒకసారి అమర్చండి

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

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 లేకపోతే, model లో ముందే నిర్ణయించిన పరిమితి లేదు. అప్పుడు Ollama యొక్క స్వంత default వర్తిస్తుంది. ollama show --modelfile qwen3-capped మొత్తం definition ను చూపుతుంది. ఇప్పటికే ఉన్న model లో చేర్చబడిన parameters ను copy చేయడానికి ఇదే వేగవంతమైన మార్గం. ఈ విధంగా పరిమితి ఉన్న model ను సృష్టించడానికి దాదాపు అదనపు disk space అవసరం లేదు. కొత్త entry, base model ఇప్పటికే download చేసిన weight blobs ను copy చేయకుండా వాటినే మళ్లీ ఉపయోగిస్తుంది. VPS root disk నిండిపోకముందే Ollama ఆ blobs ను ఎక్కడ ఉంచుతుందో తెలుసుకోవడం ఉపయోగకరం.

ప్రతి 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 ను అదే అర్థంతో ఉపయోగిస్తుంది. ఇక్కడ ఇచ్చిన విలువ ఆ ఒక్క call కు మాత్రమే వర్తిస్తుంది; మరేదానికీ వర్తించదు. మీ tools ఉపయోగించే layer ఇదే: chat front end, script, SDK wrapper లేదా coding agent. అవి మీకు దాని కోసం ప్రత్యేక box చూపించినా, చూపించకపోయినా, అన్నీ ఒక options object ను పంపుతాయి.

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

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

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

/show parameters మీ తదుపరి message తో session ఏమి పంపుతుందో చూపిస్తుంది. అందువల్ల మార్పు అమలైందో లేదో నిర్ధారించడానికి ఇది వేగవంతమైన మార్గం. మీరు /bye టైప్ చేసే వరకు ఈ value కొనసాగుతుంది. దీన్ని నిలుపుకోవడానికి /save qwen3-capped ప్రస్తుత session ను, parameters సహా, కొత్త model గా వ్రాస్తుంది. ఇక్కడ మీరు /set చేసే ఏదీ ఇతర client కు చేరదు.

ఏ setting అమల్లోకి వస్తుంది, మీ setting ఎందుకు పట్టించుకోనట్టుగా కనిపిస్తుంది

క్రమం సంక్షిప్తంగా ఉంటుంది. Request తో పంపిన options అన్నిటికంటే ముందుగా అమల్లోకి వస్తాయి. Request లో value లేకపోతే, model యొక్క Modelfile లోని PARAMETER num_predict line fallbackగా ఉపయోగించబడుతుంది. రెండూ లేకపోతే, Ollama యొక్క built-in default అమల్లోకి వస్తుంది.

/set parameter మూడవ నియమం కాదు. Interactive session ఒక API client కాబట్టి, అక్కడ మీరు set చేసిన value ఆ request యొక్క options గా పంపబడుతుంది. అందువల్ల ఆ session కోసం అది Modelfile setting ను override చేస్తుంది.

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

ఒక command తో server side ను నిర్ధారించండి. పొడవైన 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'

దీని output లో "length" మరియు 32 కనిపించాలి. 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లుగా పనిచేస్తాయి. ఒక ప్రతికూల విలువ అంటే “దీనికి పరిమితి విధించవద్దు, generation కొనసాగించండి” అని అర్థం. మరొకటి “మిగిలిన contextను నింపండి” అనే అర్థాన్ని కలిగి ఉంది. August 2026 నాటికి Ollama Modelfile reference defaultగా -1, అంటే infinite generation, చూపిస్తోంది. ఇదే పట్టికలోని పాత versionsలో contextను నింపడానికి -2 అని కూడా చూపించారు.

ఇవన్నీ versionపై ఆధారపడే విషయాలుగా పరిగణించండి, ఎందుకంటే ఈ వివరాలు మారాయి. Entryను 2024 చివర్లో సరిచేసే వరకు reference చాలా కాలం defaultను 128గా నమోదు చేసింది. అందువల్ల అనేక guides ఇప్పటికీ పాత సంఖ్యను పునరావృతం చేస్తున్నాయి. మీరు వాస్తవంగా నడుపుతున్న versionకు సంబంధించిన Modelfile parameter reference చదవండి. తరువాత పై eval_count checkతో ప్రవర్తనను నిర్ధారించండి. మీ స్వంత boxలో మీరు ధృవీకరించిన విలువ, ఈ postలో చదివిన విలువతో సహా ఎక్కడైనా చదివిన విలువ కంటే విశ్వసనీయమైనది.

CPU-only VPSలో output length ప్రధాన ఖర్చు ఎందుకు

Generation కు రెండు దశలు ఉంటాయి. వాటి వేగాలు చాలా భిన్నంగా ఉంటాయి. Prompt tokens ను batches లో, ఒకేసారి అనేక tokens చొప్పున evaluate చేస్తారు. Output tokens ను ఒక్కొక్కటిగా produce చేస్తారు. ప్రతి token కోసం model weights పై పూర్తి pass అవసరం. CPU-only VPSలో ఆ pass ను memory bandwidth పరిమితం చేస్తుంది. అందువల్ల ఒక generated token కు అయ్యే ఖర్చు, ఒక prompt token కంటే చాలా ఎక్కువ. ప్రతి weight ను చదవాల్సి ఉంటుంది కాబట్టి, ఒక్కో weight ఆక్రమించే bytes సంఖ్య మీ token rate కు గరిష్ఠ పరిమితిని నిర్ణయిస్తుంది. అందుకే అదే model ను q8 లేదా fp16లో decode చేయడం కంటే q4 build వేగంగా decode అవుతుంది.

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

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

Truncated output సాధారణంగా పరిమితి వల్ల వస్తుంది, మోడల్ విఫలమైనందువల్ల కాదు

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

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

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

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

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

• Interactive chat కోసం దీనికి పరిమితి పెట్టకుండా ఉంచండి. అనియంత్రితంగా పొడిగే సమాధానాన్ని ఆపడానికి Ctrl+C నొక్కండి. మీరు స్క్రీన్‌ను గమనిస్తూనే ఉంటారు.
• 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 లేకుండా ఒక ప్రతినిధి సమాధానాన్ని generate చేసి, eval_count ను పరిశీలించండి. ఆ విలువ కంటే సౌకర్యవంతంగా ఎక్కువగా limit ను సెట్ చేయండి. Model families tokens ను వేర్వేరు విధాలుగా tokenise చేస్తాయి. అందువల్ల ఒక Llama model కు సరిపోయే విలువ, అదే VPS పై Qwen 3 model నుంచి వచ్చిన అదే సమాధానాన్ని truncate చేయవచ్చు.

FAQ

num_ctx మరియు num_predict మధ్య తేడా ఏమిటి?

num_ctx అనేది context window పరిమాణం. అంటే prompt తో పాటు ఇప్పటివరకు రూపొందిన మొత్తం విషయాన్ని model ఎంతవరకు చదవగలదో అది నిర్ణయిస్తుంది. ఇది memory వినియోగాన్ని పెంచుతుంది, ఎందుకంటే key/value cache దాని పరిమాణంతో పెరుగుతుంది. num_predict ఒక response లో model గరిష్ఠంగా ఎన్ని tokens రాయవచ్చో నిర్ణయిస్తుంది. దీనికి ముందుగానే memory reserve చేయబడదు; ఇది memory కంటే సమయంపై ఎక్కువ ప్రభావం చూపుతుంది. రూపొందిన tokens రెండింటి పరిమితికీ లెక్కలోకి వస్తాయి. అందువల్ల వీటిలో ఏదైనా ఒకటి కారణంగా reply మధ్యలోనే ఆగిపోవచ్చు.

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

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 ను చూడలేదు. curl తో ఒక request ను "options": {"num_predict": 32} ఉపయోగించి పంపండి. తిరిగి వచ్చిన eval_count విలువ 32 గా ఉందో తనిఖీ చేయండి. ఇది server సరిగ్గా పనిచేస్తోందని నిర్ధారిస్తుంది. తదుపరి పరిశీలనను మీ application వైపు కొనసాగించవచ్చు.

నా output num_predict కారణంగా మధ్యలో ఆగిందో ఎలా తెలుసుకోవాలి?

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

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

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

num_predict పెంచితే model మరింత పొడవైన సమాధానాలు రాస్తుందా?

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