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 context length की जाँच करें

किसी भी build पर काम करने वाला तरीका prompt_eval_count है, जो उन prompt tokens की संख्या है जिन्हें सर्वर ने प्रोसेस किया है। context की क्षमता से अधिक डेटा भेजें और देखें कि वह संख्या सीमा पर रुक जाती है या नहीं।

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 के साथ दोबारा चलाएं और संख्या बढ़ जाएगी। यदि आपका build truncation के बजाय error देता है, तो इसका अर्थ भी वही है, बस संकेत अधिक स्पष्ट है।

ollama ps

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

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

Inference runner अपनी context size को उस लाइन में प्रिंट करता है जिसमें n_ctx शामिल होता है। सटीक शब्दावली releases के बीच बदलती रहती है, इसलिए यदि लाइन न दिखे तो उसे किसी समस्या का प्रमाण मानने के बजाय नाम में बदलाव समझें।

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

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

इंटरएक्टिव सेशन में। 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 में हर token, अपने से पहले के हर token को देखता है। पहले के tokens के लिए compute किए गए keys और values को सुरक्षित रखा जाता है ताकि हर नए token के लिए उन्हें दोबारा compute न करना पड़े; इस स्टोरेज को KV cache (key/value cache) कहते हैं। यह मॉडल लोड होते ही पूरे num_ctx के लिए allocate हो जाता है, न कि बातचीत बढ़ने के साथ-साथ। इसलिए, एक छोटी सी prompt के लिए भी बड़ा context काफी memory खर्च करता है।

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

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 के हर एक 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 पंक्तियाँ ऊपर दिए गए सूत्र की गणना हैं, न कि मापन। 'Total' कॉलम में 4.9 GB का वह download शामिल है जिसे Ollama library ने अगस्त 2026 में llama3.1:8b के लिए सूचीबद्ध किया था, जो कि 4.6 GiB है, और इसमें compute buffers तथा स्वयं server process को शामिल नहीं किया गया है। इसे न्यूनतम सीमा (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 तक पहुँच जाता है और बाकी system के लिए भी जगह बची रहती है। ये सभी सीमाएँ weights के साथ बदलती रहती हैं, इसलिए यदि आप इस 8B मॉडल की तुलना किसी बड़े मॉडल से कर रहे हैं, तो Qwen's 27B tag on a CPU-only VPS के लिए की गई गणनाएँ दिखाती हैं कि 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 को कम कर दें। जो KV cache swap में रहता है, वह 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 के आंकड़ों पर भरोसा करने के बजाय हर context setting पर अपने box पर tokens per second मापें।

Prefill का समय प्रॉम्प्ट की तुलना में तेजी से बढ़ता है

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

रिस्पॉन्स में माप (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)}'

इसे एक छोटे प्रॉम्प्ट के साथ चलाएं और फिर एक लंबे प्रॉम्प्ट के साथ, उसके बाद प्रत्येक स्थिति में टोकन को सेकंड से विभाजित करें। केवल CPU वाले VPS पर, prefill आमतौर पर लंबे-संदर्भ (long-context) वाले अनुरोध का सबसे धीमा हिस्सा होता है, और छोटे प्रॉम्प्ट से लिया गया टोकन प्रति सेकंड का आंकड़ा इसका सटीक अनुमान नहीं देगा।

Concurrency (समवर्तीता) वह जगह है जहाँ यह सबसे अधिक नुकसान पहुँचाती है। सेवा दिए जा रहे प्रत्येक अनुरोध को अपने स्वयं के कैश की आवश्यकता होती है, इसलिए ऊपर दिए गए चार्ट में मेमोरी प्रति सर्वर के बजाय प्रति अनुरोध है, और एक लंबा अनुरोध सर्वर को व्यस्त रख सकता है जबकि छोटे अनुरोध उसके पीछे कतार में लगे रहते हैं। 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 होती है। वही 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. सूत्र का उपयोग करके प्रति टोकन बाइट्स (bytes per token) निकालें, फिर उसे अपनी इच्छित 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 से कम VRAM पर 4k, 24 से 48 GiB के बीच 32k, और उससे अधिक पर 256k। केवल CPU वाले VPS पर यह मान कम रहता है। जिन builds में यह कॉलम उपलब्ध है, उनमें ollama ps लागू context को प्रिंट करता है, और हर build में API response के अंदर prompt_eval_count इसे प्रमाणित करता है।

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

क्योंकि prompt context window से लंबा था, इसलिए सर्वर ने model तक पहुँचने से पहले ही उसे काट दिया, और कोई error वापस नहीं आया। उसी prompt को एक बड़े num_ctx के साथ दोबारा भेजें और response में prompt_eval_count को बढ़ते हुए देखें। यदि वह संख्या नहीं बदलती है, तो आपके और सर्वर के बीच कोई अन्य चीज़ 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 को model load होते समय ही allocate कर दिया जाता है, इसलिए एक बड़ा 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 के लिए अनुरोध करेगा, उसे बिना कोई option भेजे वह context मिल जाएगा। यदि कोई request अपना खुद का num_ctx लेकर आती है, तो वही मान्य होगा, इसलिए यह एक ceiling के बजाय एक default सेट करता है।