Ollama मध्ये num_ctx सेट करून prompt कापला जाणे थांबवा

num_ctx काय करते आणि तुमचा दीर्घ prompt का कापला गेला

Ollama context length म्हणजे एकाच वेळी memory मध्ये loaded model किती tokens ठेवू शकते, हे दर्शवणारी मर्यादा. num_ctx हा ती मर्यादा सेट करणारा option आहे. Ollama model ने जाहीर केलेल्या कमाल मर्यादेपेक्षा खूपच कमी default निवडते. त्यामुळे model तो prompt वाचण्यापूर्वीच मोठा prompt कापला जातो. असे झाल्याचे response मधून कळत नाही.

Ollama model library मध्ये Llama 3.1 8B साठी 128k context window दिली आहे. Stock server तुम्हाला ही पूर्ण मर्यादा देणार नाही. Ollama च्या स्वतःच्या documentation मधील वेगवेगळ्या पानांवर वेगवेगळे defaults दिले आहेत: FAQ मध्ये 4096 tokens, Modelfile reference मध्ये num_ctx चे default 2048, आणि context length page वर default उपलब्ध VRAM (video RAM) नुसार निवडला जातो असे म्हटले आहे: 24 GiB पेक्षा कमी VRAM असल्यास 4k, 24 ते 48 GiB असल्यास 32k आणि त्यापेक्षा जास्त असल्यास 256k. यापैकी प्रत्येक मूल्य एखाद्या build साठी बरोबर होते. या विसंगतीतून महत्त्वाचा धडा मिळतो: कोणत्याही page वर, या page वरसुद्धा, अवलंबून राहण्याऐवजी तुमच्या स्वतःच्या चालू server वरील मूल्य तपासा.

Truncation शांतपणे होते, कारण model तरीही उत्तर देते आणि ते उत्तर वाचायला चांगले वाटते. ते तुमच्या input च्या शेवटच्या भागावरून लिहिलेले असते. दस्तऐवजाच्या पहिल्या अर्ध्या भागाकडे दुर्लक्ष करणारा summary पाहिल्यावर model कमकुवत आहे असे वाटू शकते. प्रत्यक्षात कारण बहुतेक वेळा context window लहान असते.

तुमच्या सर्व्हरने प्रत्यक्षात लागू केलेली Ollama context length तपासा

कोणत्याही build वर चालणारी पडताळणी म्हणजे prompt_eval_count. ही सर्व्हरने प्रक्रिया केल्याचे नोंदवलेले prompt tokens ची संख्या आहे. उपलब्ध context पेक्षा मोठा prompt पाठवा. ही संख्या 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 वापरून पुन्हा चालवा. त्यानंतर ही संख्या वाढते. तुमच्या build मध्ये मजकूर truncated करण्याऐवजी error परत येत असेल, तरी तोच निष्कर्ष अधिक स्पष्टपणे दिसतो.

ollama ps

ज्या build मध्ये CONTEXT column दिसतो, त्यात सध्या loaded model कोणत्या context length सह चालत आहे हे या column मध्ये असते. त्याच्या शेजारील PROCESSOR column 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 असलेल्या line मध्ये दाखवतो. Releases नुसार अचूक मजकूर बदलतो. त्यामुळे ही line न दिसल्यास ते कोणत्याही निष्कर्षाचा पुरावा न मानता नाव बदलले असावे असे समजा.

num_ctx सेट करण्याची चार ठिकाणे

विनंतीमध्ये. "options": {"num_ctx": 16384} हे /api/generate किंवा /api/chat कडे पाठवा. इतर सर्व settings पेक्षा याला प्राधान्य मिळते आणि ते फक्त त्या call ला लागू होते. लोड केलेले model ज्या value ने चालू आहे त्यापेक्षा ही value वेगळी असल्यास, server आधी model पुन्हा load करतो. याचे चिन्ह response मधील load_duration मध्ये दिसते: ते जवळपास शून्यापासून पूर्ण seconds पर्यंत वाढते.

interactive session मध्ये. ollama run मध्ये /set parameter num_ctx 16384 टाइप करा. ही value त्या session पुरती लागू राहते.

Modelfile मध्ये. यामुळे ही value named model मध्ये समाविष्ट होते. त्यामुळे client-side बदल न करता प्रत्येक client ला ती value मिळते.

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 मध्ये debugging करताना precedence सर्वाधिक महत्त्वाचे ठरते. num_ctx असलेली request server default वर मात करते. त्यामुळे chat front end किंवा agent स्वतःची लहान value पाठवून तुमचा systemd बदल नकळत निष्प्रभ करू शकतो. जेव्हा तुम्ही coding agent ला तुमच्या Ollama server कडे निर्देशित करता, तेव्हा server ला दोष देण्यापूर्वी client काय पाठवत आहे ते तपासा.

तुम्ही num_ctx मॉडेलच्या कमाल मर्यादेइतकेच का सेट करू शकत नाही

Attention प्रक्रियेत प्रत्येक token त्याच्या आधीच्या प्रत्येक token कडे पाहतो. आधीच्या tokens साठी मोजलेली keys आणि values पुन्हा प्रत्येक नवीन token साठी मोजावी लागू नयेत म्हणून साठवली जातात. या संचयाला KV cache (key/value cache) म्हणतात. मॉडेल load होताना संपूर्ण num_ctx साठी हा cache allocate केला जातो. Conversation वाढत गेल्यावर तो हळूहळू वाढत नाही. त्यामुळे one line prompt असला तरी मोठ्या context साठी त्याची memory लागते.

DigitalOcean's 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 म्हणून प्रकाशित करतात. Default cache मध्ये f16 values ठेवली जातात, त्यामुळे bytes_per_value हे 2 आहे. म्हणून 2 32 8 128 2 = 131,072 bytes होते. म्हणजे context मधील प्रत्येक token साठी cache ला 128 KiB memory लागते. 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 वरील सूत्रावर आधारित गणित आहे; ती measurements नाहीत. Total column मध्ये Ollama library ने August 2026 मध्ये llama3.1:8b साठी दाखवलेला 4.9 GB download समाविष्ट आहे. तो 4.6 GiB आहे. Compute buffers आणि server process यामध्ये समाविष्ट केलेले नाहीत. त्यामुळे हे किमान आवश्यकतेचे अनुमान समजा.

या गणिताचा आकार महत्त्वाचा आहे. 8k context वर cache साठी 1 GiB लागतात. Weights च्या तुलनेत ही रक्कम नगण्य आहे. मॉडेलच्या पूर्ण 128k context वर cache साठी 16 GiB लागतात. हे weights पेक्षा तीनपट अधिक आहे आणि एकूण memory गरज जवळपास 20.6 GiB होते. त्यामुळे 4 GB VPS वर हे मॉडेल उपयुक्त context सह load करता येत नाही. 8 GB VPS वर 8k context आरामात चालतो. 16 GB VPS वर उर्वरित server साठी memory राखून 32k context वापरता येतो. Weights वाढल्यास या सर्व मर्यादा वाढतात. त्यामुळे या 8B मॉडेलऐवजी मोठे मॉडेल वापरण्याचा विचार करत असल्यास, 8 ते 64 GB दरम्यान context साठी किती कमी memory उरते हे CPU-only VPS वरील Qwen चा 27B tag साठी केलेले तेच गणित दाखवते.

KV cache मध्ये बसत नसल्यास काय होते

CPU-only VPS वर process चा memory वापर वाढत जातो. Model load होत असताना आणि long request चालू असताना त्याचे निरीक्षण करा.

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

RSS (resident set size) kilobytes मध्ये दाखवला जातो. free -m मधील used swap वाढू लागल्यास context size कमी करा. Swap मध्ये असलेला KV cache generation ला प्रत्येक token साठी काही seconds पर्यंत थांबवतो, कारण प्रत्येक नवीन token वाचताना संपूर्ण cache वाचावा लागतो.

Server ची memory पूर्णपणे संपल्यास kernel सर्वात मोठा process निवडून बंद करतो.

sudo dmesg | grep -i "killed process"

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

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

हे आधी short prompt सह आणि नंतर long prompt सह चालवा. त्यानंतर प्रत्येक प्रकरणात tokens ला seconds ने भागा. CPU-only VPS वर long-context request मध्ये prefill हा सहसा सर्वात धीमा भाग असतो. त्यामुळे short prompt वरून मिळालेला tokens per second आकडा long-context request च्या कामगिरीचा अंदाज देत नाही.

Concurrency मुळे ही समस्या सर्वाधिक वाढते. Serve केलेल्या प्रत्येक request साठी स्वतंत्र cache आवश्यक असतो. त्यामुळे वरील chart मधील memory ही server साठी नव्हे, तर प्रत्येक request साठी असते. एक long request पूर्ण box व्यापून ठेवू शकतो आणि short request त्याच्या मागे queue मध्ये थांबू शकतात. OLLAMA_NUM_PARALLEL जाणीवपूर्वक सेट करा. दोन्ही संख्या एकाच वेळी वाढवण्यापूर्वी एक self-hosted LLM किती concurrent users ना सेवा देऊ शकतो हे पहा.

लहान cache वापरून संदर्भक्षमता परत मिळवा

bytes_per_value हे formula मधील तुम्ही नियंत्रित करू शकता असे setting आहे. Ollama च्या FAQ मध्ये OLLAMA_KV_CACHE_TYPE याचे दस्तऐवजीकरण आहे. त्यामध्ये default म्हणून 2 bytes असलेले f16, तसेच 1 byte असलेले q8_0 आणि त्यापेक्षा कमी असलेले q4_0 दिले आहेत. q8_0 वर गेल्यास cache चे आकारमान निम्मे होते. त्यामुळे 32k row साठी 4 GiB ऐवजी 2 GiB लागतात. त्याच FAQ मध्ये OLLAMA_FLASH_ATTENTION=1 याचेही दस्तऐवजीकरण आहे. Quantised cache लागू होण्यापूर्वी काही builds मध्ये हे आवश्यक असते.

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

अंदाज न बांधता पडताळणी करा: service restart करा, आधीच्या समान num_ctx वर model load करा आणि RSS ची तुलना करा. Support model आणि backend वर अवलंबून असतो. त्यामुळे setting बदलूनही काही फरक पडत नसेल, तर तुमचे combination समर्थित नसू शकते. Documentation मध्ये हे options दिले आहेत; मात्र quality result ची हमी दिलेली नाही. त्यामुळे त्यावर अवलंबून राहण्यापूर्वी q4_0 तुमच्या स्वतःच्या prompts विरुद्ध तपासा. तुम्ही येथे आला असाल त्याचे कारण हीच settings असतील, तर Ollama आणि llama.cpp ही settings वेगवेगळ्या प्रकारे उपलब्ध करतात.

num_ctx निवडण्याची पद्धत

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

बहुतेक कामांसाठी लोक देतात त्यापेक्षा कमी context पुरेसा असतो. मोठ्या अहवालाचा सारांश तयार करण्यासाठी 16k पुरेसे असते. पाच document chunks जोडणारा retrieval front end क्वचितच 8k पेक्षा जास्त context पाठवतो. पूर्ण files वाचणाऱ्या coding agent साठी 64k किंवा त्याहून अधिक context खरोखर आवश्यक असतो. अशा वेळी उलट पद्धतीने न जाता context लक्षात घेऊन मशीनचे आकारमान ठरवा. सर्व्हर अजून नवीन असल्यास, VPS वर कार्यरत Ollama install पासून सुरुवात करा. मॉडेल्स सुरळीतपणे load झाल्यानंतर context समायोजित करा.

FAQ

Ollama मधील default context length किती असते?

ते build आणि hardware वर अवलंबून असते. त्यामुळे अंदाज न धरता तपासा. Ollama च्या FAQ मध्ये 4096 tokens दिले आहेत, Modelfile reference मध्ये num_ctx default 2048 दिले आहे, तर context length page उपलब्ध VRAM नुसार default सांगते: 24 GiB पेक्षा कमी असल्यास 4k, 24 ते 48 GiB असल्यास 32k आणि त्यापेक्षा जास्त असल्यास 256k. CPU-only VPS लहान श्रेणीत येतो. ज्या builds मध्ये हा column उपलब्ध आहे, त्यांमध्ये ollama ps लागू केलेला context दाखवते. API response मधील prompt_eval_count प्रत्येक build मध्ये तो context प्रत्यक्ष लागू झाल्याचे सिद्ध करते.

Ollama माझ्या मोठ्या prompt ची सुरुवात का दुर्लक्षित करते?

कारण prompt ची लांबी context window पेक्षा जास्त होती. त्यामुळे model ला prompt दिसण्यापूर्वी server ने तो कापला आणि कोणतीही error परत आली नाही. तोच prompt मोठ्या num_ctx सह पुन्हा पाठवा आणि response मधील prompt_eval_count वाढते का ते monitor करा. ही संख्या बदलत नसेल, तर तुमच्या आणि 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 मध्ये तो प्रति token 128 KiB आहे. त्यामुळे 32k tokens साठी 4 GiB आणि पूर्ण 128k साठी 16 GiB weights व्यतिरिक्त लागतात. Model load होताना cache allocate केला जातो. त्यामुळे prompts लहान असले तरी मोठ्या num_ctx साठी तेवढी memory लागते.

मोठी context window Ollama ला धीमे करते का?

होय, दोन कारणांनी. Prefill work prompt length च्या square नुसार वाढते. त्यामुळे मोठ्या input मुळे first token मिळण्यास input च्या लांबीवरून वाटेल त्यापेक्षा अधिक वेळ लागतो. मोठा cache memory साठीही स्पर्धा करतो. GPU box वर यामुळे काही layers system RAM मध्ये जातात. CPU box वर machine swap वापरण्याच्या स्थितीकडे जाते. मोठा num_ctx कधीही पूर्ण वापरला नाही तरी त्यासाठी memory लागते. मात्र त्यामुळे prefill time वाढत नाही.

एका 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 मात्र त्यावर प्राधान्य मिळवते. त्यामुळे ही setting default ठरते, ceiling नाही.