Ollamaలో num_ctx సెట్ చేసి prompt truncation ఆపడం

num_ctx ఏమి చేస్తుంది, మీ పొడవైన prompt ఎందుకు కత్తిరించబడింది

Ollama context length అంటే ఒకేసారి memoryలో ఉంచగల loaded model tokens సంఖ్య. num_ctx దాన్ని నిర్ణయించే option. Model ప్రకటించే గరిష్ఠ పరిమితికంటే చాలా తక్కువ default ను Ollama ఎంచుకుంటుంది. అందువల్ల model prompt ను చదివేలోపే పొడవైన prompt కత్తిరించబడుతుంది. ఇది జరిగినట్లు response లో ఎలాంటి సమాచారం కనిపించదు.

Ollama model libraryలో Llama 3.1 8B కు 128k context window ఉన్నట్లు చూపిస్తుంది. అయితే సాధారణ server అంత పరిమితిని ఇవ్వదు. Ollama documentationలోని వేర్వేరు పేజీల్లో వేర్వేరు defaults ఉన్నాయి: FAQలో 4096 tokens అని, Modelfile referenceలో num_ctx default 2048 అని, context length pageలో అందుబాటులో ఉన్న VRAM (video RAM) ఆధారంగా default ఎంచుకోబడుతుందని చెబుతుంది: 24 GiB కంటే తక్కువైతే 4k, 24 నుంచి 48 GiB వరకు 32k, అంతకంటే ఎక్కువైతే 256k. వేర్వేరు buildsలో ఇవన్నీ ఏదో ఒక సమయంలో నిజమే. అందువల్ల ఇక్కడి ఉపయోగకరమైన పాఠం ఇదే: ఏ documentation పేజీని, ఈ పేజీని కూడా, నమ్మడం కంటే మీ స్వంత running server నుంచి value ను చదవండి.

Truncation నిశ్శబ్దంగా జరుగుతుంది, ఎందుకంటే model సమాధానం ఇస్తూనే ఉంటుంది మరియు ఆ సమాధానం చదవడానికి సరైనదిగానే కనిపిస్తుంది. అయితే అది మీ input లోని చివరి భాగాన్ని ఆధారంగా చేసుకుని రాయబడుతుంది. ఒక documentలోని మొదటి సగాన్ని పరిగణనలోకి తీసుకోని summary బలహీనమైన model కారణంగా వచ్చినట్లు కనిపించవచ్చు. సాధారణంగా కారణం చిన్న context window.

మీ సర్వర్ వాస్తవంగా అమలు చేసిన Ollama context length ను తనిఖీ చేయండి

ఏ build లోనైనా పనిచేసే తనిఖీ `prompt_eval_count`. ఇది సర్వర్ process చేసిన prompt tokens సంఖ్యను చూపుతుంది. Context లో సరిపడే పరిమాణం కంటే ఎక్కువ data పంపితే, ఆ సంఖ్య limit వద్ద ఆగిపోతుంది.

sudo apt update && sudo apt install -y jq
LONG=$(python3 -c "print('the quick brown fox jumps over the lazy dog. ' * 2000)")
jq -n --arg p "$LONG" '{model:"llama3.1:8b", prompt:$p, stream:false, options:{num_ctx:4096}}' |
  curl -s http://localhost:11434/api/generate -d @- |
  jq '{prompt_eval_count, prompt_eval_duration}'

ఆ prompt లో సుమారు 18,000 పదాలు ఉన్నాయి. అందువల్ల అది 4096 tokens కంటే చాలా ఎక్కువ. `prompt_eval_count వాస్తవ token count కు దగ్గరగా కాకుండా 4096 కు దగ్గరగా వస్తుంది. కారణం, సర్వర్ మిగిలిన భాగాన్ని తొలగించింది. ఇప్పుడు "num_ctx":16384` తో మళ్లీ అమలు చేయండి. అప్పుడు count పెరుగుతుంది. మీ build truncate చేయడానికి బదులుగా error చూపిస్తే, అదే విషయం మరింత స్పష్టమైన సంకేతంతో తెలుస్తుంది.

ollama ps

Context length ను print చేసే builds లో `CONTEXT column, ప్రస్తుతం loaded model ఉపయోగిస్తున్న context length ను చూపిస్తుంది. దాని పక్కన ఉన్న PROCESSOR column, model ఎక్కడ అమలవుతుందో చూపిస్తుంది. GPU లేని VPS లో 100% CPU సాధారణ స్థితి. GPU ఉన్న system లో 30%/70% CPU/GPU వంటి split కనిపిస్తే, weights మరియు cache VRAM లో ఇక పూర్తిగా సరిపోవడం లేదని అర్థం. సాధారణంగా దీనికి కారణం పెంచిన num_ctx`.

journalctl -u ollama --no-pager | grep -i n_ctx | tail -n 5

Inference runner తన context size ను `n_ctx` ఉన్న line లో print చేస్తుంది. Releases మధ్య ఖచ్చితమైన wording మారుతుంది. అందువల్ల ఆ line కనిపించకపోతే, దాన్ని ఏదో rename చేసినట్లు పరిగణించండి; దాని ఆధారంగా ఏదైనా నిర్ధారణకు రావద్దు.

num_ctx ను సెట్ చేయడానికి నాలుగు ప్రదేశాలు

అభ్యర్థనలో. "options": {"num_ctx": 16384} ను /api/generate లేదా /api/chat కు పంపండి. ఇది ఇతర అన్ని settings కంటే ప్రాధాన్యత కలిగి ఉంటుంది మరియు ఆ ఒక్క call కు మాత్రమే వర్తిస్తుంది. లోడ్ చేసిన model ప్రస్తుతం ఉపయోగిస్తున్న విలువతో ఈ విలువ భిన్నంగా ఉంటే, server ముందుగా model ను reload చేస్తుంది. దీనిని response లోని load_duration లో చూడవచ్చు: విలువ దాదాపు సున్నా నుంచి పూర్తి seconds కు పెరుగుతుంది.

ఇంటరాక్టివ్ session లో. ollama run లో /set parameter num_ctx 16384 టైప్ చేయండి. ఇది ఆ session వరకు మాత్రమే ఉంటుంది.

Modelfile లో. ఇది విలువను ఒక named model లో స్థిరపరుస్తుంది. అందువల్ల client-side మార్పు లేకుండానే ప్రతి client ఆ విలువను పొందుతుంది.

FROM llama3.1:8b
PARAMETER num_ctx 16384

ollama create llama3.1-16k -f ./Modelfile
ollama run llama3.1-16k

Server పై. స్వంత num_ctx లేని ప్రతి request కు OLLAMA_CONTEXT_LENGTH default ను సెట్ చేస్తుంది. systemd కింద unit file ను సవరించకుండా drop-in ను జోడించండి.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=16384"

sudo systemctl daemon-reload
sudo systemctl restart ollama
ollama ps

మీరు మరొకరి client ను debug చేస్తున్నప్పుడు precedence అత్యంత ముఖ్యమైనది. num_ctx కలిగిన request server default పై ప్రాధాన్యత పొందుతుంది. అందువల్ల చిన్న విలువను స్వయంగా పంపే chat front end లేదా agent, మీ systemd మార్పును నిశ్శబ్దంగా రద్దు చేయవచ్చు. మీరు coding agent ను మీ Ollama server కు చూపించినప్పుడు, server ను తప్పుపట్టే ముందు client ఏమి పంపుతుందో తనిఖీ చేయండి.

మీరు num_ctx ను మోడల్ గరిష్ఠానికి ఎందుకు సెట్ చేయకూడదు

Attention ప్రతి token కు ముందు వచ్చిన ప్రతి token ను పరిశీలిస్తుంది. ముందున్న tokens కోసం లెక్కించిన keys మరియు values ను మళ్లీ ప్రతి కొత్త token కు లెక్కించకుండా నిల్వ చేస్తారు. ఆ నిల్వను KV cache (key/value cache) అంటారు. మోడల్ load అయినప్పుడు మొత్తం num_ctx కోసం ఇది కేటాయించబడుతుంది. Conversation పెరుగుతున్న కొద్దీ ఇది కేటాయించబడదు. అందువల్ల ఒకే వరుస prompt అయినా పెద్ద context దాని memory ను వినియోగిస్తుంది.

DigitalOcean inference cost tutorial ఈ లెక్కను ఒకే వరుసలో చూపిస్తుంది:

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

ఇక్కడ 2 అనేది keys మరియు values ను విడిగా లెక్కించడాన్ని సూచిస్తుంది. మిగతా సంఖ్యలను మీ స్వంత model నుంచి తీసుకోండి.

curl -s http://localhost:11434/api/show -d '{"model":"llama3.1:8b"}' |
  jq '.model_info | {ctx: ."llama.context_length", layers: ."llama.block_count", heads: ."llama.attention.head_count", kv_heads: ."llama.attention.head_count_kv", embed: ."llama.embedding_length"}'

Llama 3.1 8B లో 32 layers మరియు 8 key/value heads ఉన్నాయి. Head dimension అనేది embed ను heads తో భాగించిన ఫలితం. కాబట్టి ఇక్కడ 4096 / 32 = 128. కొన్ని models దీనిని నేరుగా llama.attention.key_length గా ప్రచురిస్తాయి. Default cache లో f16 values ఉంటాయి. అందువల్ల bytes_per_value విలువ 2. 2 32 8 128 2 లెక్కిస్తే 131,072 bytes వస్తుంది. అంటే context లోని ప్రతి ఒక్క token కు 128 KiB cache అవసరం. దీన్ని context length తో గుణిస్తే ఖర్చు స్పష్టంగా తెలుస్తుంది.

[
  {
    "label": "4k",
    "kv_cache_gib": 0.5,
    "total_ram_gib": 5.1
  },
  {
    "label": "8k",
    "kv_cache_gib": 1,
    "total_ram_gib": 5.6
  },
  {
    "label": "16k",
    "kv_cache_gib": 2,
    "total_ram_gib": 6.6
  },
  {
    "label": "32k",
    "kv_cache_gib": 4,
    "total_ram_gib": 8.6
  },
  {
    "label": "64k",
    "kv_cache_gib": 8,
    "total_ram_gib": 12.6
  },
  {
    "label": "128k",
    "kv_cache_gib": 16,
    "total_ram_gib": 20.6
  }
]

ఆ 6 rows పై formula ద్వారా చేసిన లెక్కలు మాత్రమే; అవి measurements కావు. Total column లో Ollama library August 2026లో llama3.1:8b కోసం చూపించిన 4.9 GB download కూడా కలిపి ఉంది. అది 4.6 GiB కు సమానం. Compute buffers మరియు server process ను ఇందులో చేర్చలేదు. కాబట్టి దీన్ని కనీస అవసరంగా పరిగణించండి.

ఇక్కడ ముఖ్యమైనది cache పెరుగుదల విధానం. 8k వద్ద cache ఖర్చు 1 GiB మాత్రమే. Weights తో పోలిస్తే ఇది చాలా తక్కువ. Model యొక్క పూర్తి 128k వద్ద cache ఖర్చు 16 GiB అవుతుంది. ఇది weights కంటే మూడు రెట్లకుపైగా ఉంటుంది. మొత్తం అవసరం సుమారు 20.6 GiB అవుతుంది. అందువల్ల 4 GB VPS ఈ model ను ఉపయోగకరమైన context తో load చేయలదు. 8 GB VPS లో 8k context సౌకర్యంగా నడుస్తుంది. 16 GB VPS లో మిగతా system కోసం memory మిగిలి ఉండగానే 32k context ను ఉపయోగించవచ్చు. Weights పెరిగే కొద్దీ ఈ పరిమితులన్నీ కూడా పెరుగుతాయి. కాబట్టి ఈ 8B model కు బదులుగా పెద్ద model ను పరిశీలిస్తే, 8 మరియు 64 GB మధ్య context కోసం weights ఎంత తక్కువ memory వదిలిపెడతాయో CPU-only VPS పై Qwen 27B tag కోసం చేసిన అదే లెక్కలు చూపిస్తాయి.

KV cache సరిపోకపోతే ఏమి జరుగుతుంది

CPU-only VPSలో process పరిమాణం పెరుగుతూనే ఉంటుంది. Model load అవుతున్నప్పుడు, అలాగే దీర్ఘమైన request నడుస్తున్నప్పుడు దాన్ని monitor చేయండి.

free -m
ps -eo rss,comm --sort=-rss | head -n 5

RSS (resident set size) kilobytesలో చూపబడుతుంది. free -m లో ఉపయోగించిన swap పెరగడం ప్రారంభిస్తే, context పరిమాణాన్ని తగ్గించండి. Swapలో ఉన్న KV cache కారణంగా generationలో ప్రతి tokenకు కొన్ని seconds ఆలస్యం అవుతుంది. దీనికి కారణం ప్రతి కొత్త token మొత్తం cacheను చదవాల్సి రావడమే.

Boxలో memory పూర్తిగా అయిపోతే, kernel పెద్ద processను ఎంచుకుని kill చేస్తుంది.

sudo dmesg | grep -i "killed process"

Out of memory: Killed process 1234 (ollama) అని ఉన్న line, మీరు అడిగిన context సరిపోలేదని అర్థం. Ollama సాధారణంగా ఆ స్థితి రాకముందే నిరాకరిస్తుంది. అప్పుడు request విఫలమవుతుంది. Error messageలో అవసరమైన memory మరియు ఖాళీగా ఉన్న memory వివరాలు ఉంటాయి.

GPU boxలో failure అంత స్పష్టంగా కనిపించదు. కొన్ని layers system RAMలోకి spill అవుతాయి. ollama ps CPU మరియు GPU మధ్య విభజనను చూపుతుంది. Throughput గణనీయంగా తగ్గుతుంది. తగ్గుదల మీ hardwareపై ఆధారపడి ఉంటుంది. అందువల్ల ఇతరుల machineలోని గణాంకాన్ని నమ్మకుండా, ప్రతి context setting వద్ద మీ స్వంత boxలో ప్రతి secondకు ఎన్ని tokens ఉత్పత్తి అవుతున్నాయో కొలవండి.

Prefill సమయం prompt కంటే వేగంగా పెరుగుతుంది

మొదటి output token కనిపించే ముందు మీ inputపై జరిగే పనినే prefill అంటారు. ప్రతి prompt token తనకు ముందు ఉన్న ప్రతి tokenను పరిశీలిస్తుంది. అందువల్ల మొత్తం పని input పొడవు వర్గానికి అనుగుణంగా పెరుగుతుంది. Promptను రెండింతలు చేస్తే, మొదటి token కోసం వేచి ఉండే సమయం రెండింతలకంటే ఎక్కువగా పెరుగుతుంది.

కొలత responseలోనే ఉంటుంది. కాబట్టి మీరు దాన్ని కేవలం నమ్మాల్సిన అవసరం లేదు.

jq -n --arg p "$LONG" '{model:"llama3.1:8b", prompt:$p, stream:false, options:{num_ctx:16384}}' |
  curl -s http://localhost:11434/api/generate -d @- |
  jq '{tokens: .prompt_eval_count, prefill_seconds: (.prompt_eval_duration/1000000000)}'

దీన్ని ఒక చిన్న promptతో ఒకసారి, పొడవైన promptతో మరోసారి అమలు చేయండి. ప్రతి సందర్భంలో tokensను secondsతో భాగించండి. CPU-only VPSలో, దీర్ఘమైన context ఉన్న requestలో prefill సాధారణంగా అత్యంత నెమ్మదైన భాగం. చిన్న promptతో పొందిన tokens per second విలువ దీర్ఘమైన prompt పనితీరును అంచనా వేయదు.

ఈ సమస్య concurrencyలో అత్యంత స్పష్టంగా కనిపిస్తుంది. అందిస్తున్న ప్రతి requestకు ప్రత్యేక cache అవసరం. అందువల్ల పై chartలో చూపిన memory server మొత్తానికి కాకుండా ప్రతి requestకు వర్తిస్తుంది. ఒక పొడవైన request మొత్తం box వనరులను ఆక్రమించవచ్చు. దాని వెనుక చిన్న requests queueలో వేచి ఉండవచ్చు. OLLAMA_NUM_PARALLEL ను ఉద్దేశపూర్వకంగా సెట్ చేయండి. రెండు సంఖ్యలను ఒకేసారి పెంచే ముందు ఒక self-hosted LLM ఎన్ని concurrent usersకు సేవలు అందించగలదో చదవండి.

చిన్న cache తో context ను తిరిగి పొందండి

సూత్రంలోని bytes_per_value మీరు నియంత్రించే setting. Ollama FAQ లో OLLAMA_KV_CACHE_TYPE గురించి వివరించబడింది. 2 bytes default గా f16 ఉంటుంది. 1 byte కోసం q8_0, దానికంటే తక్కువ కోసం q4_0 ఉన్నాయి. q8_0 కు మార్చితే cache సగానికి తగ్గుతుంది. అందువల్ల 32k row ధర 2 GiB అవుతుంది; 4 GiB కాదు. Quantised cache అమలులోకి రావడానికి కొన్ని builds ముందు OLLAMA_FLASH_ATTENTION=1 అవసరమని కూడా అదే FAQ పేర్కొంటుంది.

[Service]
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

ఊహించకుండా నిర్ధారించండి. Service ను restart చేసి, ముందులాగే అదే num_ctx తో model ను load చేయండి. తరువాత RSS ను పోల్చండి. Support model మరియు backend పై ఆధారపడి ఉంటుంది. Setting ఏ మార్పూ చేయకపోతే, మీ కలయికకు అది వర్తించదు. Documentation ఈ options ను పేర్కొంటుంది. అయితే quality result కు హామీ ఇవ్వదు. కాబట్టి దానిపై ఆధారపడే ముందు మీ prompts తో q4_0 ను పరీక్షించండి. మీరు ఇక్కడికి రావడానికి కారణం ఈ knobs అయితే, Ollama మరియు llama.cpp వాటిని వేర్వేరు విధాలుగా అందిస్తాయి.

num_ctx ఎంచుకునే విధానం

1. /api/show నుంచి model గరిష్ఠ context, layer count, అలాగే key/value head count ను చదవండి.
2. ఇచ్చిన formula తో ప్రతి token కు అవసరమైన bytes ను లెక్కించి, ఆ విలువను మీకు కావలసిన context తో గుణించండి.
3. weight size ను దీనికి జోడించి, free RAM తో పోల్చండి. మిగతా server పనుల కోసం కనీసం 1 GiB RAM ఖాళీగా ఉంచండి.
4. విలువను సెట్ చేసి model ను load చేయండి. తరువాత ollama ps మరియు prompt_eval_count ద్వారా అమలులోకి వచ్చిన విలువను నిర్ధారించండి.
5. free -m ను monitor చేస్తూ మీ అసలు workload ను నడపండి. swap వినియోగం ప్రారంభమైతే context ను సగానికి తగ్గించండి.

చాలా jobs కు వినియోగదారులు కేటాయించేంత context అవసరం ఉండదు. పొడవైన report ను summarise చేయడానికి 16k సరిపోతుంది. ఐదు document chunks ను జోడించే retrieval front end సాధారణంగా 8k దాటదు. పూర్తి files ను చదివే coding agent కు మాత్రమే 64k లేదా అంతకంటే ఎక్కువ context నిజంగా అవసరం కావచ్చు. ఈ సందర్భంలో context కు అనుగుణంగా machine ను పరిమాణీకరించాలి; machine పరిమితులకు అనుగుణంగా context ను తగ్గించకూడదు. Server ఇంకా కొత్తగా ఉంటే, ముందుగా VPSలో పనిచేసే Ollama installation నుంచి ప్రారంభించండి. Models సక్రమంగా load అయిన తరువాత context ను tune చేయండి.

FAQ

Ollamaలో డిఫాల్ట్ context length ఎంత?

ఇది build మరియు hardware పై ఆధారపడి ఉంటుంది. కాబట్టి ఊహించకుండా పరిశీలించాలి. Ollama FAQలో 4096 tokens అని, Modelfile referenceలో num_ctx default 2048 అని, context length పేజీలో అందుబాటులో ఉన్న VRAM ఆధారంగా default ఎంచుకోబడుతుందని పేర్కొన్నారు: 24 GiB కంటే తక్కువైతే 4k, 24 నుంచి 48 GiB వరకు ఉంటే 32k, అంతకంటే ఎక్కువైతే 256k. CPU-only VPS సాధారణంగా ఈ పరిధిలోని చిన్న విలువను ఉపయోగిస్తుంది. ఆ column ఉన్న buildsలో ollama ps అమలైన context ను చూపిస్తుంది. API responseలోని prompt_eval_count ప్రతి buildలో అది అమలైందని నిర్ధారిస్తుంది.

నా పొడవైన prompt ప్రారంభాన్ని Ollama ఎందుకు పట్టించుకోదు?

Prompt context window కంటే పొడవుగా ఉండటం వల్ల. Model దాన్ని చూడకముందే server promptను కత్తిరించింది, కానీ ఎలాంటి error తిరిగి రాలేదు. అదే promptను పెద్ద num_ctx తో మళ్లీ పంపి, responseలో prompt_eval_count పెరుగుతుందో monitor చేయాలి. ఆ సంఖ్య మారకపోతే, మీకు మరియు serverకు మధ్య ఉన్న ఏదో భాగం స్వయంగా num_ctx ను సెట్ చేస్తోంది. Chat front ends మరియు agent frameworksలో ఇది సాధారణం.

పెద్ద num_ctx కు అదనంగా ఎంత RAM అవసరం?

Context lengthను ప్రతి tokenకు అయ్యే cache ఖర్చుతో గుణించాలి. ఆ ఖర్చు 2 * layers * kv_heads * head_dim * bytes_per_value. Llama 3.1 8Bను f16లో ఉపయోగించినప్పుడు ప్రతి tokenకు 128 KiB అవసరం. అందువల్ల 32k tokensకు weightsకు అదనంగా 4 GiB, పూర్తి 128kకు 16 GiB అవసరం. Model load అయినప్పుడు cache allocate అవుతుంది. కాబట్టి prompts చిన్నగా ఉన్నప్పటికీ పెద్ద num_ctx కు ఆ memory అవసరం అవుతుంది.

పెద్ద context window Ollamaను నెమ్మదిగా చేస్తుందా?

అవును, రెండు విధాలుగా. Prompt length యొక్క squareకు అనుగుణంగా prefill పని పెరుగుతుంది. అందువల్ల input పొడవు సూచించే దానికంటే ఎక్కువ సమయం తర్వాత మొదటి token వస్తుంది. పెద్ద cache కూడా memory కోసం పోటీ పడుతుంది. GPU boxలో layers system RAMలోకి తరలించబడతాయి. CPU boxలో machine swap వైపు నెట్టబడుతుంది. మీరు ఎప్పుడూ పూర్తిగా ఉపయోగించని పెద్ద num_ctx అయినా memoryని వినియోగిస్తుంది. అయితే prefill సమయం మాత్రం వినియోగించదు.

ఒక model కోసం num_ctxను శాశ్వతంగా సెట్ చేయవచ్చా?

అవును. FROM llama3.1:8b మరియు PARAMETER num_ctx 16384 కలిగిన Modelfileను రాసి, తరువాత ollama create llama3.1-16k -f ./Modelfile అమలు చేయాలి. llama3.1-16k ను అభ్యర్థించే ప్రతి client ఎలాంటి options పంపకుండానే ఆ contextను పొందుతుంది. తన స్వంత num_ctx ను కలిగిన requestకు ప్రాధాన్యం ఉంటుంది. కాబట్టి ఇది ceiling కాకుండా defaultను సెట్ చేస్తుంది.