Ollama में num_ctx सेट करके context length कैसे बढ़ाएं

num_ctx क्या करता है, और आपका लंबा प्रॉम्प्ट क्यों कट गया

Ollama context length उन टोकन्स की संख्या है जिन्हें एक लोड किया गया मॉडल एक बार में मेमोरी में रख सकता है, और num_ctx वह विकल्प है जो इसे सेट करता है। Ollama एक ऐसा डिफ़ॉल्ट चुनता है जो मॉडल द्वारा विज्ञापित अधिकतम सीमा से काफी कम होता है, इसलिए मॉडल के पढ़ने से पहले ही एक लंबा प्रॉम्प्ट कट जाता है। प्रतिक्रिया में ऐसी कोई जानकारी नहीं होती जो आपको बताए कि ऐसा हुआ है।

Llama 3.1 8B को Ollama मॉडल लाइब्रेरी पर 128k context window के साथ सूचीबद्ध किया गया है। एक स्टॉक सर्वर आपको वह क्षमता नहीं देगा। Ollama के अपने दस्तावेज़ों में अलग-अलग पृष्ठों पर अलग-अलग डिफ़ॉल्ट दिए गए हैं: FAQ कहता है 4096 टोकन्स, Modelfile संदर्भ कहता है कि num_ctx डिफ़ॉल्ट रूप से 2048 होता है, और context length page कहता है कि डिफ़ॉल्ट मान उपलब्ध VRAM (वीडियो RAM) से चुना जाता है, 24 GiB से नीचे 4k, 24 से 48 GiB के बीच 32k, और उससे ऊपर 256k। इनमें से प्रत्येक किसी न किसी बिल्ड के लिए सही था। यह असहमति ही यहाँ सीखने वाली महत्वपूर्ण बात है: किसी भी पृष्ठ पर भरोसा करने के बजाय, जिसमें यह पृष्ठ भी शामिल है, अपने चल रहे सर्वर से मान (value) को स्वयं पढ़ें।

Truncation चुपचाप होता है क्योंकि मॉडल अभी भी उत्तर देता है, और उत्तर पढ़ने में सही लगता है। इसे आपके इनपुट के अंतिम हिस्से से लिखा गया था। एक सारांश जो किसी दस्तावेज़ के पहले आधे हिस्से को छोड़ देता है, वह एक कमजोर मॉडल जैसा दिखता है। यह आमतौर पर एक छोटी context window के कारण होता है।

अपने सर्वर द्वारा लागू की गई Ollama कॉन्टेक्स्ट लेंथ की जाँच करें

किसी भी बिल्ड पर काम करने वाला चेक prompt_eval_count है, जो सर्वर द्वारा प्रोसेस किए गए प्रॉम्प्ट टोकन की संख्या बताता है। कॉन्टेक्स्ट क्षमता से अधिक टोकन भेजें और देखें कि वह संख्या सीमा पर रुक जाती है या नहीं।

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}'

वह प्रॉम्प्ट लगभग 18,000 शब्दों का है, जो 4096 टोकन से काफी अधिक है। prompt_eval_count वास्तविक टोकन संख्या के बजाय 4096 के करीब आता है, क्योंकि सर्वर ने बाकी हिस्से को हटा दिया है। इसे "num_ctx":16384 के साथ फिर से चलाएं और संख्या बढ़ जाएगी। यदि आपका बिल्ड ट्रंकेट करने के बजाय एरर देता है, तो यह भी उसी निष्कर्ष की पुष्टि करता है, बस अधिक स्पष्ट संकेत के साथ।

ollama ps

CONTEXT कॉलम, उन बिल्ड्स पर जो इसे प्रिंट करते हैं, उस कॉन्टेक्स्ट लेंथ को दर्शाता है जिस पर लोड किया गया मॉडल अभी चल रहा है। इसके बगल में PROCESSOR कॉलम दिखाता है कि मॉडल कहाँ स्थित है। बिना GPU वाले VPS पर 100% CPU सामान्य है। GPU बॉक्स पर 30%/70% CPU/GPU जैसा विभाजन यह दर्शाता है कि वेट्स (weights) और कैश अब VRAM में फिट नहीं हो रहे हैं, और इसका सामान्य कारण बढ़ा हुआ num_ctx है।

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

इन्फरेंस रनर अपनी कॉन्टेक्स्ट साइज को उस लाइन में प्रिंट करता है जिसमें n_ctx शामिल होता है। सटीक शब्दावली रिलीज के साथ बदलती रहती है, इसलिए यदि यह लाइन न दिखे तो इसे किसी समस्या का प्रमाण मानने के बजाय नाम में बदलाव समझें।

num_ctx सेट करने के चार स्थान

रिक्वेस्ट में। "options": {"num_ctx": 16384} को /api/generate या /api/chat पर भेजें। यह अन्य सभी सेटिंग्स पर प्रभावी होता है और केवल उसी एक कॉल पर लागू होता है। यदि यह मान लोड किए गए मॉडल के वर्तमान मान से अलग है, तो सर्वर पहले मॉडल को पुनः लोड करता है, जिसे आप रिस्पॉन्स में load_duration में देख सकते हैं: यह शून्य के करीब से बढ़कर पूरे सेकंड में पहुँच जाता है। यही प्रतीक्षा समय तब भी दिखाई देता है जब मॉडल काफी देर तक निष्क्रिय रहने के कारण अनलोड हो गया हो, इसलिए एक बार जब आप कॉन्टेक्स्ट साइज तय कर लें, तो keep_alive के साथ मॉडल को मेमोरी में बनाए रखना फायदेमंद होता है।

इंटरएक्टिव सेशन में। ollama run के अंदर, /set parameter num_ctx 16384 टाइप करें। यह केवल उस सेशन के लिए प्रभावी रहता है।

Modelfile में। यह मान को एक नामित मॉडल में फिक्स कर देता है, जिससे प्रत्येक क्लाइंट को बिना किसी क्लाइंट-साइड बदलाव के यह मान मिल जाता है।

FROM llama3.1:8b
PARAMETER num_ctx 16384

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

सर्वर पर। OLLAMA_CONTEXT_LENGTH उन सभी रिक्वेस्ट के लिए डिफ़ॉल्ट सेट करता है जिनमें अपना num_ctx नहीं होता है। systemd के तहत, यूनिट फाइल को एडिट करने के बजाय एक ड्रॉप-इन फाइल जोड़ें।

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=16384"

sudo systemctl daemon-reload
sudo systemctl restart ollama
ollama ps

प्राथमिकता (precedence) तब सबसे महत्वपूर्ण होती है जब आप किसी और के क्लाइंट को डीबग कर रहे हों। एक रिक्वेस्ट जिसमें num_ctx शामिल है, वह सर्वर के डिफ़ॉल्ट मान को ओवरराइड कर देती है, इसलिए कोई चैट फ्रंट-एंड या एजेंट जो अपना छोटा मान भेजता है, वह चुपचाप आपके systemd बदलाव को निष्प्रभावी कर देता है। जब आप अपने Ollama सर्वर पर किसी कोडिंग एजेंट को पॉइंट करें, तो सर्वर को दोष देने से पहले यह जांच लें कि क्लाइंट क्या भेज रहा है।

आप num_ctx को सीधे मॉडल के अधिकतम मान पर क्यों सेट नहीं कर सकते

Attention mechanism हर टोकन को उससे पहले आने वाले हर टोकन को देखने के लिए मजबूर करता है। पहले के टोकन्स के लिए compute की गई keys और values को सुरक्षित रखा जाता है ताकि हर नए टोकन के लिए उन्हें दोबारा compute न करना पड़े; इस स्टोरेज को KV cache (key/value cache) कहते हैं। यह मॉडल लोड होते ही पूरे num_ctx के लिए allocate हो जाता है, न कि बातचीत बढ़ने के साथ, इसलिए एक छोटी सी प्रॉम्प्ट के लिए भी बड़ा context काफी मेमोरी खर्च करता है।

DigitalOcean का inference cost ट्यूटोरियल इस गणना को एक लाइन में स्पष्ट करता है:

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

2 का अंक keys और values को अलग-अलग गिनता है। अन्य संख्याएँ आप अपने मॉडल के विनिर्देशों से देख सकते हैं।

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 है, और कुछ मॉडल इसे सीधे llama.attention.key_length के रूप में प्रकाशित करते हैं। डिफ़ॉल्ट cache f16 values को होल्ड करता है, इसलिए bytes_per_value का मान 2 है, और 2 32 8 128 2 का परिणाम 131,072 bytes होता है। यह context के हर एक टोकन के लिए 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 पंक्तियाँ ऊपर दिए गए फॉर्मूले की गणना हैं, न कि मापन। 'Total' कॉलम में 4.9 GB का डाउनलोड शामिल है जिसे Ollama लाइब्रेरी ने अगस्त 2026 में llama3.1:8b के लिए सूचीबद्ध किया था, जो कि 4.6 GiB है, और इसमें compute buffers तथा स्वयं सर्वर प्रोसेस को शामिल नहीं किया गया है। इसे न्यूनतम सीमा (floor) मानें।

मुख्य बात इसका आकार है। 8k पर cache की लागत 1 GiB है, जो weights की तुलना में नगण्य है। मॉडल के पूर्ण 128k पर इसकी लागत 16 GiB हो जाती है, जो weights से तीन गुना अधिक है, और कुल योग 20.6 GiB के करीब पहुँच जाता है। इसलिए, 4 GB का VPS इस मॉडल को किसी भी उपयोगी context के साथ लोड नहीं कर सकता। 8 GB का VPS 8k पर ठीक काम करता है। 16 GB का VPS 32k तक पहुँच जाता है और सिस्टम के अन्य कार्यों के लिए जगह भी बचती है। ये सभी सीमाएँ weights के साथ बदलती रहती हैं, इसलिए यदि आप इस 8B मॉडल की तुलना किसी बड़े मॉडल से कर रहे हैं, तो CPU-only VPS पर Qwen के 27B टैग के लिए की गई गणनाएँ दिखाती हैं कि 8 GB और 64 GB के बीच context के लिए weights कितनी कम जगह छोड़ते हैं।

जब KV cache फिट नहीं होता है तो क्या होता है

केवल CPU वाले VPS पर process का आकार बढ़ जाता है। model load होते समय और लंबे request के चलने के दौरान इसे monitor करें।

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

RSS (resident set size) को kilobytes में print किया जाता है। यदि free -m में swap का उपयोग बढ़ना शुरू हो जाए, तो context को कम करें। swap में मौजूद KV cache के कारण generation में हर token के लिए कई seconds की देरी होती है, क्योंकि प्रत्येक नया token पूरे cache को read करता है।

यदि box की memory पूरी तरह समाप्त हो जाती है, तो kernel सबसे बड़ी process को चुनता है और उसे kill कर देता है।

sudo dmesg | grep -i "killed process"

Out of memory: Killed process 1234 (ollama) वाली line का अर्थ है कि आपके द्वारा मांगा गया context फिट नहीं हुआ। Ollama अक्सर उस स्थिति तक पहुँचने से पहले ही मना कर देता है, और request एक error message के साथ fail हो जाती है जिसमें उपलब्ध memory के मुकाबले आवश्यक memory का उल्लेख होता है।

GPU box पर failure का पता कम चलता है। layers system RAM में spill हो जाती हैं, ollama ps CPU और GPU के विभाजन को दिखाता है, और throughput में भारी गिरावट आती है। यह गिरावट आपके hardware पर निर्भर करती है, इसलिए किसी और की machine के आंकड़ों पर भरोसा करने के बजाय अपने box पर tokens per second को मापें और हर context setting पर इसकी जाँच करें।

Prefill का समय prompt की तुलना में तेजी से बढ़ता है

Prefill वह कार्य है जो पहला output token दिखाई देने से पहले आपके input पर किया जाता है। प्रत्येक prompt token अपने से पहले के हर token पर ध्यान (attend) देता है, इसलिए कुल कार्य input की लंबाई के वर्ग (square) के अनुपात में बढ़ता है। prompt को दोगुना करने पर पहले token के लिए प्रतीक्षा का समय दोगुने से भी अधिक हो जाता है।

response में माप (measurement) शामिल होती है, इसलिए आपको इसे केवल विश्वास के आधार पर लेने की आवश्यकता नहीं है।

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 के लिए सही अनुमान नहीं देता। यदि prefill के सामने लगा कोई timeout समाप्त हो जाए, तो लंबा prompt अक्सर उत्तर के बजाय context deadline exceeded लौटाता है। इसलिए context छोटा करने से पहले पता लगाएँ कि किस layer ने request छोड़ दी।

Concurrency के मामले में यह सबसे अधिक प्रभावित करता है। सेवा दी जा रही प्रत्येक request को अपने स्वयं के cache की आवश्यकता होती है, इसलिए ऊपर दिए गए चार्ट में memory प्रति request है, न कि प्रति सर्वर। एक लंबी request सर्वर को व्यस्त रख सकती है, जबकि छोटी requests उसके पीछे कतार में खड़ी रहती हैं। OLLAMA_NUM_PARALLEL को सोच-समझकर सेट करें, और दोनों संख्याओं को एक साथ बढ़ाने से पहले एक self-hosted LLM कितने concurrent users को सेवा दे सकता है पढ़ें।

छोटे cache के साथ context वापस प्राप्त करें

सूत्र में bytes_per_value एक ऐसी सेटिंग है जिसे आप नियंत्रित करते हैं। Ollama का FAQ OLLAMA_KV_CACHE_TYPE का दस्तावेजीकरण करता है, जिसमें f16 डिफ़ॉल्ट रूप से 2 bytes पर है, इसके साथ q8_0 1 byte पर और q4_0 उससे नीचे है। q8_0 पर जाने से cache आधा हो जाता है, इसलिए 32k row की लागत 4 GiB के बजाय 2 GiB होती है। Weights को quantise करने से उसी बजट के दूसरी तरफ मेमोरी खाली हो जाती है, और वह GLM tag जो वास्तव में एक VPS में फिट बैठता है उसे quantisation दर quantisation के माध्यम से पूरा किया जाता है यदि आप वह समझौता करना पसंद करते हैं। वही FAQ OLLAMA_FLASH_ATTENTION=1 का दस्तावेजीकरण करता है, जिसकी कुछ builds को quantised cache प्रभावी होने से पहले आवश्यकता होती है।

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

अनुमान लगाने के बजाय पुष्टि करें: service को restart करें, model को पहले की तरह ही num_ctx पर load करें, और RSS की तुलना करें। समर्थन model और backend पर निर्भर करता है, इसलिए यदि कोई सेटिंग कुछ भी नहीं बदलती है, तो इसका मतलब है कि आपका संयोजन समर्थित नहीं है। दस्तावेज़ इन विकल्पों को सूचीबद्ध करते हैं लेकिन गुणवत्तापूर्ण परिणाम का वादा नहीं करते हैं, इसलिए उन पर भरोसा करने से पहले अपने स्वयं के prompts के विरुद्ध q4_0 का परीक्षण करें। यदि ये knobs ही वह कारण हैं कि आप यहाँ हैं, तो Ollama और llama.cpp इन्हें अलग-अलग तरीके से expose करते हैं।

num_ctx चुनने के लिए एक विधि

1. /api/show से मॉडल की अधिकतम context, उसकी layer count और key/value head count को पढ़ें।
2. सूत्र का उपयोग करके प्रति token bytes की गणना करें, फिर उसे अपनी इच्छित context से गुणा करें।
3. इसमें weight size जोड़ें, उपलब्ध RAM से तुलना करें, और सिस्टम के अन्य कार्यों के लिए कम से कम 1 GiB RAM सुरक्षित रखें।
4. मान सेट करें, मॉडल लोड करें, और फिर ollama ps तथा prompt_eval_count के साथ पुष्टि करें कि क्या लागू हुआ है।
5. free -m पर नजर रखते हुए अपना वास्तविक वर्कलोड चलाएं, और यदि swap का उपयोग शुरू हो जाए तो context को आधा कर दें।

अधिकांश कार्यों के लिए लोगों द्वारा दी जाने वाली context से कम की आवश्यकता होती है। एक लंबी रिपोर्ट का सारांश 16k में आ जाता है। एक retrieval front end जो पांच दस्तावेज़ के टुकड़ों को पेस्ट करता है, वह शायद ही कभी 8k से ऊपर जाता है। एक कोडिंग एजेंट जो पूरी फाइलें पढ़ता है, उसे वास्तव में 64k या उससे अधिक की आवश्यकता होती है, और यही वह स्थिति है जहाँ आपको context के आधार पर मशीन का आकार तय करना चाहिए, न कि इसके विपरीत। यदि सर्वर अभी नया है, तो VPS पर Ollama का कार्यशील इंस्टॉलेशन से शुरुआत करें और मॉडल के सफलतापूर्वक लोड होने के बाद context को ट्यून करें।

FAQ

Ollama में default context length क्या है?

यह build और hardware पर निर्भर करता है, इसलिए अनुमान लगाने के बजाय इसकी जाँच करें। Ollama का FAQ 4096 tokens का उल्लेख करता है, Modelfile reference में num_ctx default 2048 बताया गया है, और context length पेज के अनुसार default उपलब्ध VRAM से तय होता है: 24 GiB से कम पर 4k, 24 से 48 GiB के बीच 32k, और उससे अधिक पर 256k। केवल CPU वाले VPS पर यह कम रहता है। ollama ps उन builds पर लागू context दिखाता है जिनमें यह column मौजूद है, और हर build पर API response में prompt_eval_count इसकी पुष्टि करता है।

Ollama मेरे लंबे prompt की शुरुआत को ignore क्यों करता है?

क्योंकि prompt context window से लंबा था, इसलिए server ने model तक पहुँचने से पहले ही उसे काट दिया, और कोई error नहीं मिला। उसी prompt को बड़े num_ctx के साथ फिर से भेजें और response में prompt_eval_count को बढ़ते हुए देखें। यदि वह संख्या नहीं बदलती है, तो आपके और server के बीच कोई चीज़ खुद num_ctx सेट कर रही है, जो chat front ends और agent frameworks में आम है।

बड़े num_ctx के लिए कितनी अतिरिक्त RAM चाहिए?

Context length को प्रति token cache cost से गुणा करें, जो 2 * layers * kv_heads * head_dim * bytes_per_value है। Llama 3.1 8B (f16) के लिए यह 128 KiB प्रति token है, इसलिए 32k tokens की लागत 4 GiB है और पूरे 128k की लागत weights के अलावा 16 GiB है। Cache तब allocate होती है जब model load होता है, इसलिए एक बड़े num_ctx के लिए वह memory खर्च होती है, भले ही आपके prompts छोटे हों।

क्या बड़ी context window Ollama को धीमा कर देती है?

हाँ, दो तरीकों से। Prefill का काम prompt की लंबाई के वर्ग (square) के साथ बढ़ता है, इसलिए लंबा input पहले token में उसकी लंबाई से कहीं अधिक देरी करता है। बड़ी cache memory के लिए प्रतिस्पर्धा भी करती है: GPU box पर यह layers को system RAM में धकेल देती है, और CPU box पर यह machine को swap की ओर ले जाती है। एक बड़ा num_ctx जिसे आप कभी पूरा नहीं भरते, वह भी memory खर्च करता है, हालाँकि इसमें prefill का समय नहीं लगता।

क्या मैं किसी एक model के लिए num_ctx को स्थायी रूप से सेट कर सकता हूँ?

हाँ। एक Modelfile लिखें जिसमें FROM llama3.1:8b और PARAMETER num_ctx 16384 शामिल हों, फिर ollama create llama3.1-16k -f ./Modelfile चलाएँ। जो भी client llama3.1-16k के लिए request करेगा, उसे बिना कोई option भेजे वह context मिल जाएगा। यदि कोई request अपना खुद का num_ctx भेजती है, तो वह प्रभावी होगा, इसलिए यह एक ceiling के बजाय default सेट करता है।