Ollama मध्ये num_ctx कसे सेट करावे?

num_ctx काय करते आणि तुमचा लाँग प्रॉम्प्ट का कापला जातो

Ollama मधील context length म्हणजे लोड केलेल्या मॉडेलने एकाच वेळी मेमरीमध्ये साठवलेली टोकन्सची संख्या होय आणि num_ctx हा पर्याय ती संख्या निश्चित करतो. Ollama डीफॉल्ट म्हणून मॉडेलच्या जास्तीत जास्त क्षमतेपेक्षा खूप कमी संख्या निवडते, त्यामुळे मॉडेल वाचण्यापूर्वीच लांब प्रॉम्प्ट कापला जातो. असे घडल्याचे प्रतिसादात कुठेही कळत नाही.

Ollama मॉडेल लायब्ररीमध्ये Llama 3.1 8B साठी 128k context window नमूद केली आहे. एक सामान्य सर्व्हर तुम्हाला ती क्षमता देणार नाही. Ollama च्या स्वतःच्या दस्तऐवजीकरणामध्ये वेगवेगळ्या पानांवर वेगवेगळे डीफॉल्ट्स दिले आहेत: FAQ मध्ये 4096 टोकन्स, Modelfile संदर्भात num_ctx डीफॉल्ट 2048 असल्याचे म्हटले आहे आणि context length page वर असे म्हटले आहे की डीफॉल्ट संख्या उपलब्ध VRAM (व्हिडिओ रॅम) वरून निवडली जाते; 24 GiB पेक्षा कमी असल्यास 4k, 24 ते 48 GiB दरम्यान असल्यास 32k आणि त्यापेक्षा जास्त असल्यास 256k. यातील प्रत्येक माहिती काही बिल्ड्ससाठी सत्य होती. हा विसंगतीचा मुद्दा एक महत्त्वाचा धडा देतो: कोणत्याही पानावर विश्वास ठेवण्याऐवजी, स्वतःच्या चालू असलेल्या सर्व्हरवरून प्रत्यक्ष व्हॅल्यू तपासा.

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) आणि कॅशे (cache) आता 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 मध्ये. हे मूल्य एका विशिष्ट मॉडेलमध्ये समाविष्ट (bake) करते, त्यामुळे क्लायंट-साईडवर कोणताही बदल न करता प्रत्येक क्लायंटला ते मिळते.

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) यंत्रणेमुळे प्रत्येक टोकनला त्याआधीच्या प्रत्येक टोकनकडे पाहावे लागते. आधीच्या टोकन्ससाठी मोजलेल्या कीज (keys) आणि व्हॅल्यूज (values) साठवून ठेवल्या जातात, जेणेकरून प्रत्येक नवीन टोकनसाठी त्या पुन्हा मोजाव्या लागू नयेत; या साठवणुकीला KV cache (key/value cache) म्हणतात. मॉडेल लोड होतानाच संपूर्ण num_ctx साठी ही मेमरी आरक्षित केली जाते, संभाषणासोबत ती वाढत नाही. त्यामुळे, केवळ एका ओळीच्या प्रॉम्प्टसाठीही मोठ्या कॉन्टेक्स्टला तितकीच मेमरी लागते.

DigitalOcean चे इन्फरन्स कॉस्ट ट्युटोरियल एका ओळीत याचे गणित मांडते:

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

2 ही संख्या कीज आणि व्हॅल्यूज स्वतंत्रपणे मोजते. इतर आकडे तुमच्या स्वतःच्या मॉडेलच्या माहितीवरून घ्या.

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 लेयर्स आणि 8 की/व्हॅल्यू हेड्स असतात. हेड डायमेन्शन हे embed ला heads ने भागून मिळते, म्हणजेच इथे 4096 / 32 = 128, काही मॉडेल्स हे थेट llama.attention.key_length म्हणून प्रसिद्ध करतात. डीफॉल्ट कॅशे f16 व्हॅल्यूज साठवते, म्हणून bytes_per_value ची किंमत 2 असते, आणि 2 32 8 128 2 चे उत्तर 131,072 बाइट्स येते. याचा अर्थ प्रत्येक एका टोकनच्या कॉन्टेक्स्टसाठी 128 KiB कॅशे लागते. याला कॉन्टेक्स्ट लेंथने गुणले की हा खर्च केवळ तात्विक राहत नाही.

[
  {
    "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 ओळी वरील सूत्रावरून काढलेले गणित आहे, मोजमाप नाही. एकूण रकान्यात ऑगस्ट 2026 मध्ये Ollama लायब्ररीने llama3.1:8b साठी नमूद केलेले 4.9 GB डाउनलोड (जे 4.6 GiB आहे) मिळवले आहे, आणि यात कॉम्प्युट बफर्स व सर्व्हर प्रोसेसचा समावेश नाही. याला किमान मर्यादा (floor) समजा.

याचा आकार महत्त्वाचा आहे. 8k वर कॅशेचा खर्च 1 GiB इतका होतो, जो मॉडेलच्या वेट्सच्या (weights) तुलनेत नगण्य आहे. मॉडेलच्या पूर्ण 128k क्षमतेवर तो 16 GiB होतो, जो वेट्सच्या तिप्पट आहे आणि एकूण मेमरी 20.6 GiB च्या जवळ जाते. त्यामुळे 4 GB च्या VPS वर हे मॉडेल कोणत्याही उपयुक्त कॉन्टेक्स्टसह लोड होऊ शकत नाही. 8 GB चा VPS 8k कॉन्टेक्स्टसाठी सोयीस्कर आहे. 16 GB चा VPS 32k पर्यंत पोहोचतो आणि इतर कामांसाठी मेमरी शिल्लक राहते. यातील प्रत्येक मर्यादा वेट्सच्या आकारानुसार बदलत जाते. त्यामुळे जर तुम्ही मोठ्या मॉडेलची तुलना या 8B मॉडेलशी करत असाल, तर Qwen's 27B tag on a CPU-only VPS साठी केलेली गणिते हे दर्शवतात की 8 GB ते 64 GB च्या दरम्यान वेट्स कॉन्टेक्स्टसाठी किती कमी जागा शिल्लक ठेवतात.

KV cache मावणार नाही तेव्हा काय होते

केवळ CPU असलेल्या VPS वर ही प्रक्रिया केवळ वाढत जाते. मॉडेल लोड होत असताना आणि एखादी मोठी विनंती (request) सुरू असताना त्यावर लक्ष ठेवा.

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

RSS (resident set size) किलोबाइट्समध्ये दर्शविला जातो. जर free -m मधील swap चा वापर वाढू लागला, तर context कमी करा. जर KV cache swap मध्ये असेल, तर प्रत्येक नवीन टोकनसाठी संपूर्ण cache वाचावा लागत असल्याने जनरेशन प्रक्रियेत प्रति टोकन काही सेकंदांचा विलंब होतो.

जर सर्व्हरची मेमरी पूर्णपणे संपली, तर कर्नल सर्वात मोठी प्रक्रिया निवडते आणि ती बंद (kill) करते.

sudo dmesg | grep -i "killed process"

Out of memory: Killed process 1234 (ollama) अशी ओळ दिसण्याचा अर्थ असा की तुम्ही मागितलेला context मावला नाही. Ollama अनेकदा त्या स्थितीपर्यंत पोहोचण्यापूर्वीच नकार देते आणि विनंती अयशस्वी होते, ज्यामध्ये उपलब्ध मेमरीच्या तुलनेत आवश्यक मेमरीचा उल्लेख असलेला संदेश मिळतो.

GPU असलेल्या सर्व्हरवर हे अपयश अधिक शांतपणे घडते. लेयर्स सिस्टम RAM मध्ये पसरतात, ollama ps मध्ये CPU आणि GPU मधील विभागणी दिसते आणि थ्रूपुटमध्ये मोठी घट होते. ही घट किती असेल हे तुमच्या हार्डवेअरवर अवलंबून असते, म्हणून इतरांच्या मशीनवरील आकडेवारीवर विश्वास ठेवण्याऐवजी तुमच्या स्वतःच्या मशीनवर प्रति सेकंद टोकन्स मोजा आणि त्यानुसार प्रत्येक context सेटिंग तपासा.

Prefill साठी लागणारा वेळ प्रॉम्प्टच्या तुलनेत वेगाने वाढतो

Prefill म्हणजे पहिला आउटपुट टोकन दिसण्यापूर्वी इनपुटवर केलेले काम. प्रत्येक प्रॉम्प्ट टोकन त्याच्या आधीच्या प्रत्येक टोकनवर लक्ष केंद्रित करते (attend), त्यामुळे एकूण काम इनपुटच्या लांबीच्या वर्गाच्या (square) प्रमाणात वाढते. प्रॉम्प्ट दुप्पट केल्यास पहिल्या टोकनसाठी लागणारा प्रतीक्षा वेळ दुप्पटीपेक्षा जास्त वाढतो.

प्रतिसादामध्ये मोजमाप दिलेले असते, त्यामुळे तुम्हाला त्यावर आंधळा विश्वास ठेवण्याची गरज नाही.

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

हे short prompt आणि long prompt या दोन्हींसह चालवा. प्रत्येक प्रकरणात tokens ला seconds ने भागा. CPU-only VPS वर long-context request मध्ये prefill हा सहसा सर्वात धीमा टप्पा असतो. त्यामुळे short prompt वरून मिळवलेला tokens per second आकडा long prompt साठी अचूक अंदाज देत नाही. समोर असलेला कोणताही timeout संपेपर्यंत prefill सुरू राहिल्यास, long prompt ला उत्तराऐवजी context deadline exceeded मिळण्याचे हेच सामान्य कारण असते. त्यामुळे context कमी करण्यापूर्वी कोणत्या layer ने प्रक्रिया थांबवली ते शोधा.

Concurrency (एकाच वेळी अनेक विनंत्या) मध्ये याचा सर्वाधिक फटका बसतो. सर्व्ह केल्या जाणाऱ्या प्रत्येक विनंतीला स्वतःच्या कॅशेची आवश्यकता असते, त्यामुळे वरील चार्टमधील मेमरी ही प्रति सर्व्हर नसून प्रति विनंती आहे. एक लांब विनंती सर्व्हरला गुंतवून ठेवू शकते, ज्यामुळे लहान विनंत्या रांगेत थांबतात. OLLAMA_NUM_PARALLEL मुद्दाम सेट करा आणि दोन्ही संख्या एकत्र वाढवण्यापूर्वी एक self-hosted LLM एकाच वेळी किती वापरकर्त्यांना सर्व्ह करू शकते हे वाचा.

लहान कॅशे वापरून मेमरीची उपलब्धता वाढवणे

सूत्रातील bytes_per_value हे तुमच्या नियंत्रणातील एक सेटिंग आहे. Ollama चे FAQ OLLAMA_KV_CACHE_TYPE बद्दल माहिती देते, ज्यामध्ये f16 हे 2 बाइट्सवर डीफॉल्ट असते, तसेच q8_0 हे 1 बाइटवर आणि q4_0 हे त्यापेक्षा कमी मूल्यांवर असते. q8_0 वर बदल केल्यास कॅशे अर्धी होते, त्यामुळे 32k ची ओळ 4 GiB ऐवजी 2 GiB जागा घेते. वेट्सचे (weights) प्रमाणीकरण (quantisation) केल्यास त्याच बजेटच्या दुसऱ्या बाजूला मेमरी मोकळी होते, आणि VPS वर बसणारा GLM टॅग हा प्रमाणीकरणानुसार कसा कार्य करतो, हे तुम्ही तुमच्या गरजेनुसार ठरवू शकता. त्याच FAQ मध्ये OLLAMA_FLASH_ATTENTION=1 बद्दल माहिती दिली आहे, ज्याची काही बिल्ड्सना प्रमाणीकृत कॅशे प्रभावी होण्यापूर्वी आवश्यकता असते.

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

गृहीत धरण्याऐवजी खात्री करा: सर्व्हिस रीस्टार्ट करा, मॉडेल पूर्वीप्रमाणेच त्याच num_ctx वर लोड करा आणि RSS ची तुलना करा. सपोर्ट हा मॉडेल आणि बॅकएंडवर अवलंबून असतो, त्यामुळे जर एखादे सेटिंग बदलूनही काही फरक पडत नसेल, तर याचा अर्थ तुमचे कॉम्बिनेशन याला सपोर्ट करत नाही. डॉक्युमेंटेशनमध्ये हे पर्याय दिले आहेत, परंतु ते उत्तम रिझल्ट देतीलच याची खात्री नाही, त्यामुळे त्यावर अवलंबून राहण्यापूर्वी q4_0 ची तुमच्या स्वतःच्या प्रॉम्प्ट्सवर चाचणी करा. जर हे पर्यायच तुमच्या मुख्य गरजा असतील, तर Ollama आणि llama.cpp हे पर्याय वेगवेगळ्या प्रकारे हाताळतात.

num_ctx निवडण्यासाठीची कृती

1. /api/show मधून मॉडेलची कमाल context, त्यातील लेयर्सची संख्या आणि key/value head ची संख्या तपासा.
2. सूत्राचा वापर करून प्रति टोकन किती bytes लागतात ते काढा आणि तुम्हाला हव्या असलेल्या context ने गुणा.
3. यामध्ये मॉडेलच्या वजनाचा (weight size) आकार मिळवा, उपलब्ध RAM शी तुलना करा आणि सिस्टमच्या इतर कामांसाठी किमान 1 GiB RAM शिल्लक ठेवा.
4. मूल्य सेट करा, मॉडेल लोड करा आणि त्यानंतर ollama ps व prompt_eval_count वापरून नेमके किती context लागू झाले आहे याची खात्री करा.
5. तुमचा प्रत्यक्ष वर्कलोड चालवताना free -m वर लक्ष ठेवा; जर swap मेमरी वापरली जाऊ लागली, तर context अर्धी करा.

बहुतेक कामांसाठी लोकांना वाटते त्यापेक्षा कमी context पुरेशी असते. एखादा मोठा अहवाल सारांशित करण्यासाठी 16k पुरेशी असते. पाच दस्तऐवजांचे भाग पेस्ट करणारे retrieval front end क्वचितच 8k च्या पुढे जाते. कोडिंग एजंट जेव्हा संपूर्ण फाइल्स वाचतो, तेव्हाच खऱ्या अर्थाने 64k किंवा त्यापेक्षा जास्त context ची गरज भासते. अशा वेळी, उपलब्ध हार्डवेअरनुसार context ठरवण्याऐवजी, context च्या गरजेनुसार मशीनची क्षमता ठरवणे योग्य ठरते. जर सर्व्हर नवीन असेल, तर Ollama चे VPS वरील कार्यरत इंस्टॉलेशन पासून सुरुवात करा आणि मॉडेल्स व्यवस्थित लोड होऊ लागल्यावर context ट्यून करा.

FAQ

Ollama मध्ये डीफॉल्ट कॉन्टेक्स्ट लेन्थ (context length) किती असते?

हे बिल्ड आणि हार्डवेअरवर अवलंबून असते, त्यामुळे गृहीत धरण्याऐवजी तपासा. Ollama च्या FAQ मध्ये 4096 टोकन्सचा उल्लेख आहे, Modelfile संदर्भात num_ctx डीफॉल्ट 2048 दिलेले आहे, आणि कॉन्टेक्स्ट लेन्थ पेजवर उपलब्ध VRAM नुसार डीफॉल्ट ठरवले जाते: 24 GiB पेक्षा कमी असल्यास 4k, 24 ते 48 GiB दरम्यान असल्यास 32k, आणि त्यापेक्षा जास्त असल्यास 256k. फक्त CPU असलेल्या VPS वर ही मर्यादा कमी असते. ज्या बिल्ड्समध्ये कॉलम उपलब्ध आहे तिथे ollama ps वापरून लागू केलेली कॉन्टेक्स्ट पाहता येते, आणि प्रत्येक बिल्डमध्ये API रिस्पॉन्स मधील prompt_eval_count हे सिद्ध करते.

Ollama माझ्या लांब प्रॉम्प्टची सुरुवात का दुर्लक्षित करते?

कारण प्रॉम्प्ट कॉन्टेक्स्ट विंडोपेक्षा मोठा होता, त्यामुळे मॉडेलपर्यंत पोहोचण्यापूर्वीच सर्व्हरने तो कापला आणि कोणतीही त्रुटी (error) परत आली नाही. तोच प्रॉम्प्ट मोठ्या num_ctx सह पुन्हा पाठवा आणि रिस्पॉन्स मधील prompt_eval_count वाढत असल्याचे तपासा. जर तो आकडा बदलत नसेल, तर तुमच्या आणि सर्व्हरच्या दरम्यान काहीतरी स्वतःहून num_ctx सेट करत आहे, जे चॅट फ्रंट-एंड आणि एजंट फ्रेमवर्क्समध्ये सामान्य आहे.

मोठ्या num_ctx साठी किती अतिरिक्त RAM लागते?

कॉन्टेक्स्ट लेन्थला प्रति टोकन कॅशे कॉस्टने गुणा, जी 2 * layers * kv_heads * head_dim * bytes_per_value आहे. Llama 3.1 8B (f16) साठी हे प्रति टोकन 128 KiB आहे, त्यामुळे 32k टोकन्ससाठी 4 GiB आणि पूर्ण 128k साठी 16 GiB मेमरी मॉडेलच्या वजनाव्यतिरिक्त लागते. मॉडेल लोड होतानाच कॅशे अलोकेट (allocate) केला जातो, त्यामुळे तुमचे प्रॉम्प्ट्स लहान असले तरीही मोठ्या num_ctx साठी तेवढी मेमरी खर्च होते.

मोठी कॉन्टेक्स्ट विंडो Ollama ला धीमे करते का?

हो, दोन प्रकारे. प्रीफिल (prefill) काम प्रॉम्प्टच्या लांबीच्या वर्गाच्या प्रमाणात वाढते, त्यामुळे लांब इनपुटमुळे पहिल्या टोकनला लागणारा वेळ त्याच्या लांबीपेक्षा जास्त वाढतो. मोठा कॅशे मेमरीसाठी स्पर्धा करतो: GPU सर्व्हरवर तो लेयर्सना सिस्टम RAM मध्ये ढकलतो, आणि CPU सर्व्हरवर तो मशीनला स्वॅप (swap) कडे नेतो. तुम्ही न वापरलेला मोठा num_ctx सुद्धा मेमरी खर्च करतो, जरी तो प्रीफिल वेळेत भर टाकत नसला तरीही.

मी एका मॉडेलसाठी num_ctx कायमस्वरूपी सेट करू शकतो का?

हो. FROM llama3.1:8b आणि PARAMETER num_ctx 16384 असलेला एक Modelfile लिहा, आणि नंतर ollama create llama3.1-16k -f ./Modelfile चालवा. जो क्लायंट llama3.1-16k ची विनंती करेल, त्याला कोणतेही ऑप्शन्स न पाठवता ती कॉन्टेक्स्ट मिळेल. स्वतःचा num_ctx असलेली विनंती अजूनही प्रभावी ठरते, त्यामुळे हे एक डीफॉल्ट मूल्य सेट करते, कमाल मर्यादा (ceiling) नाही.