Ollama में concurrency कैसे काम करती है: NUM_PARALLEL गाइड

जब पहली request generate हो रही हो, तब दूसरी Ollama request का क्या होता है

Ollama की concurrency तीन environment variables द्वारा निर्धारित होती है, और डिफ़ॉल्ट रूप से एक loaded model एक समय में केवल एक ही request को process करता है। दूसरी request को न तो अस्वीकार किया जाता है और न ही उसे अधूरा उत्तर मिलता है। वह queue में तब तक प्रतीक्षा करती है जब तक कि कोई slot खाली न हो जाए, और उसके बाद वह सामान्य गति से चलती है।

आने वाली request के तीन संभावित परिणाम हो सकते हैं। यह तुरंत एक खाली slot में शुरू हो जाती है। यह queue में प्रतीक्षा करती है। या फिर queue पहले से ही भरी हुई है और सर्वर इसे HTTP 503 के साथ अस्वीकार कर देता है। आपको क्या परिणाम मिलेगा, यह OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE और OLLAMA_MAX_LOADED_MODELS द्वारा तय किया जाता है।

डिफ़ॉल्ट सेटिंग सुरक्षित है, और यही कारण है कि दूसरा उपयोगकर्ता रिपोर्ट करता है कि सर्वर "hang" हो गया है, जबकि वास्तव में कुछ भी खराब नहीं होता है। Slots बढ़ाना केवल दो लाइन का बदलाव है। जो हिस्सा समस्या पैदा करता है वह memory है। प्रत्येक parallel slot को अपने स्वयं के key/value cache (KV cache) की आवश्यकता होती है, जो memory का वह हिस्सा है जिसे model उन tokens के लिए रखता है जिन्हें वह पहले ही process कर चुका है। यदि आप VRAM (GPU पर video memory) बढ़ाए बिना slots बढ़ाते हैं, तो आप एक धीमे उत्तर को failed load में बदल देते हैं।

OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE और OLLAMA_MAX_LOADED_MODELS क्या नियंत्रित करते हैं

ये अगस्त 2026 तक Ollama के वर्तमान releases में डिफ़ॉल्ट मान हैं। यहाँ दिए गए नंबरों पर भरोसा करने के बजाय, नीचे दिखाए गए log line का उपयोग करके अपने मानों की जाँच करें।

• OLLAMA_NUM_PARALLEL यह नियंत्रित करता है कि एक loaded model एक ही समय में कितने requests को संभाल सकता है। इसका डिफ़ॉल्ट मान 1 है, जिसका अर्थ है कि requests को एक के बाद एक पूरा किया जाता है।
• OLLAMA_MAX_LOADED_MODELS यह नियंत्रित करता है कि एक साथ कितनी अलग-अलग models memory में resident रह सकती हैं। इसका डिफ़ॉल्ट मान 0 है, जिसका अर्थ है कि Ollama स्वयं चुनाव करता है: प्रति GPU तीन models, और बिना GPU वाली मशीन पर भी तीन models।
• OLLAMA_MAX_QUEUE यह नियंत्रित करता है कि कितनी requests प्रतीक्षा सूची (queue) में रह सकती हैं। इसका डिफ़ॉल्ट मान 512 है। जब queue भर जाती है, तो आने वाली नई request को तुरंत अस्वीकार (reject) कर दिया जाता है।

सबसे खराब स्थिति में memory का उपयोग पहले दो मानों का गुणनफल होता है। यदि चार-चार slots वाली दो models loaded हैं, तो KV cache के कुल आठ slot allocations एक साथ memory में रहेंगे, और Ollama उन्हें पूरा करने का प्रयास करेगा। एक सिंगल GPU वाले सिस्टम पर आमतौर पर एक ही model को रखना और उसे अधिक slots देना बेहतर होता है, क्योंकि इससे गणना सरल बनी रहती है।

हर parallel slot के लिए VRAM की आवश्यकता क्यों होती है

जब Ollama किसी model को load करता है, तो यह एक अलग runner process शुरू करता है। इसमें भेजे जाने वाले दो arguments महत्वपूर्ण हैं: -c वह कुल context है जिसके लिए runner एक KV cache allocate करता है, और -np parallel sequences की संख्या है। Ollama -c को आपकी प्रति-request context length और slot count के गुणनफल पर set करता है। इसके बाद runner उस कुल context को slots के बीच समान रूप से विभाजित कर देता है, ताकि प्रत्येक request को आपके द्वारा मांगी गई context length मिल सके।

यही एकमात्र बाधा है, और इसीलिए parallelism मुफ्त नहीं है। एक slot से चार slots पर जाने का मतलब है कि समान प्रति-request context पर चार गुना KV cache की आवश्यकता। slots के बीच कुछ भी साझा नहीं होता है, और एक idle slot का हिस्सा किसी busy slot को नहीं दिया जा सकता, क्योंकि runner शुरू होते ही यह विभाजन तय हो जाता है।

आप उन वास्तविक numbers को देख सकते हैं जिन्हें आपने set करने का प्रयास किया था:

journalctl -u ollama --no-pager -n 500 | grep "starting llama-server"

उस line में पूरा runner command line होता है, जिसमें -c और -np शामिल हैं। यदि variable set करने के बाद भी -np का मान 1 है, तो इसका मतलब है कि setting server तक नहीं पहुँच रही है, और अगला section इसका कारण बताता है।

यदि model weights और वह KV cache, VRAM में नहीं समाते हैं, तो Ollama कुछ layers को system RAM में स्थानांतरित कर देता है और वे layers CPU पर चलती हैं। CPU layers, GPU layers की तुलना में बहुत धीमी होती हैं, इसलिए इससे हर request धीमी हो जाती है, जिसमें वह single request भी शामिल है जिससे आपने शुरुआत की थी। इसलिए, parallelism बढ़ाने से throughput बढ़ने के बजाय घट सकता है। यदि model काफी बड़ा हो, तो weights ही यह तय कर देते हैं कि model fit होगा या नहीं, इससे पहले कि कोई slot calculation शुरू हो। यही कारण है कि Kimi K3 जैसे model को self-host करना इस बात की चर्चा है कि आपके पास कितने cards हैं, न कि इस बात की कि आपने कितने slots set किए हैं।

ollama ps

जब सब कुछ fit हो जाता है, तो PROCESSOR column में 100% GPU दिखाई देता है। 35%/65% CPU/GPU जैसा विभाजन यह दर्शाता है कि model का कुछ हिस्सा CPU पर चल रहा है। SIZE column में KV cache शामिल होता है, इसलिए जब आप slot count बढ़ाते हैं और model को reload करते हैं, तो यह बढ़ जाता है। OLLAMA_NUM_PARALLEL को बढ़ाएं, restart करें, एक request भेजें, और फिर से ollama ps चलाएं: यह आपके बदलाव की memory लागत है, जिसे अनुमान लगाने के बजाय मापा गया है। यदि वह माप यह बताती है कि model अब fit नहीं हो रहा है, तो याद रखें कि weights उसी budget का दूसरा हिस्सा हैं, और fp16 से q8 या q4 build पर जाना अक्सर उस slot से अधिक VRAM खाली कर देता है जिसे आप जोड़ने का प्रयास कर रहे थे।

Context length और slot count आपस में गुणा होते हैं, इसलिए उन्हें एक साथ चुना जाना चाहिए। चार slots के साथ एक बड़ा context, चार बड़े contexts के बराबर होता है। यदि आप अपने model के लिए num_ctx context window को भी tune कर रहे हैं, तो एक बार में केवल एक ही बदलाव करें, अन्यथा आपको पता नहीं चलेगा कि किस कारण से card भर गया।

इन variables को reboot के बाद भी बनाए रखने का तरीका

Linux पर, Ollama एक systemd service के रूप में चलता है। अपने shell में export OLLAMA_NUM_PARALLEL=4 चलाने से कुछ नहीं बदलता, क्योंकि systemd service को अपने स्वयं के environment के साथ शुरू करता है और आपके shell को कभी नहीं देखता। इसके लिए एक drop-in file का उपयोग करें।

sudo systemctl edit ollama.service

खुलने वाले editor में इसे जोड़ें:

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_MAX_QUEUE=32"

फिर reload और restart करें:

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

systemctl show वह जानकारी दिखाता है जो systemd process को देगा। यदि आपकी variable वहां नहीं है, तो drop-in save नहीं हुआ या daemon-reload को छोड़ दिया गया था। सर्वर की तरफ से भी इसकी पुष्टि करें:

journalctl -u ollama --no-pager | grep "server config" | tail -1

Ollama startup पर अपने पूरे environment को एक line में log करता है जिसका message server config होता है। वह map ही अंतिम सत्य है। यह इस बात पर बहस खत्म करने का सबसे तेज़ तरीका है कि कोई variable प्रभावी हुई या नहीं।

जो model पहले से loaded है, वह उसी slot count को बनाए रखता है जिसके साथ उसे शुरू किया गया था, क्योंकि यह value launch के समय runner process में fix हो जाती है। ऊपर दिया गया restart सब कुछ unload कर देता है, इसलिए अगली request नई setting के साथ model को reload करती है और load time का भुगतान एक बार करती है। उसके बाद model कितनी देर तक resident रहता है, यह एक अलग control है, जिसे requests के बीच Ollama model को loaded रखने में कवर किया गया है।

Client के नजरिए से served, queued और refused का अर्थ

एक साथ कई requests भेजें और उनका समय मापें। यह कमांड समानांतर (parallel) रूप से आठ streaming requests चलाती है और प्रत्येक के लिए status और timings प्रिंट करती है:

for i in $(seq 1 8); do
  curl -s -o /dev/null \
    -w "req$i http=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n" \
    http://127.0.0.1:11434/api/generate \
    -d '{"model":"llama3.2:3b","prompt":"Explain what a KV cache is.","stream":true}' &
done
wait

ttfb स्ट्रीम के पहले बाइट तक का समय है। यह time to first token (TTFT) के करीब है क्योंकि स्ट्रीम किया गया पहला हिस्सा ही पहला टोकन लेकर आता है।

समानांतर में served (Served in parallel)। प्रत्येक request एक समान ttfb रिपोर्ट करती है, और सभी के लिए total एक साथ बढ़ता है। GPU को चल रहे slots के बीच साझा किया जाता है, इसलिए प्रत्येक उत्तर अकेले चलने की तुलना में धीमा होता है, जबकि प्रति मिनट अधिक उत्तर पूरे होते हैं। जब आप OLLAMA_NUM_PARALLEL बढ़ाते हैं, तो आप इसी मोड का उपयोग कर रहे होते हैं।

Queued (कतार में)। पहली requests जल्दी उत्तर देती हैं और बाद वाली requests में पहले एक लंबा ttfb दिखाई देता है, जिसके बाद सामान्य generation होती है। यह प्रतीक्षा कतार (queue) के कारण है, न कि मॉडल के कारण। चैट विंडो देख रहे उपयोगकर्ता को पहले एक लंबा खाली अंतराल दिखाई देता है और फिर पूरी गति से टेक्स्ट आता है। यह आकार—शुरू होने में धीमा और फिर तेज—ओवरलोडेड GPU के बजाय कतार की पहचान है।

Refused (अस्वीकृत)। क्लाइंट को लगभग तुरंत http=503 प्राप्त होता है, और body इस प्रकार होती है:

{"error":"server busy, please try again.  maximum pending requests exceeded"}

इस संदेश का अर्थ है कि जिस क्षण request पहुंची, उस समय कतार भरी हुई थी। यह VRAM या मॉडल के बारे में कुछ नहीं बताता है।

एक स्पष्ट सीमा: Ollama कतार की गहराई (queue depth) प्रकाशित नहीं करता है। ollama ps और /api/ps endpoint उन मॉडल्स की रिपोर्ट करते हैं जो लोड किए गए हैं, न कि उन requests की जो प्रतीक्षा कर रही हैं। इसलिए आप क्लाइंट साइड से time to first byte को देखकर कतार को मापते हैं, या फिर जो भी आपके सामने (proxy/load balancer) स्थित है, वहां 503 responses की गिनती करते हैं।

MAX_QUEUE को कम रखना अक्सर बेहतर सेटिंग क्यों है

512 की queue सुनने में काफी बड़ी लगती है, लेकिन एक single slot पर यह लगभग बेकार है। Request 300 को 299 पूर्ण generations के पीछे इंतज़ार करना पड़ता है। यह कम से कम कुछ मिनटों का समय है। हर HTTP client इससे बहुत पहले ही हार मान लेता है, इसलिए caller को client side timeout दिखाई देता है, जो उन्हें कारण के बारे में कुछ नहीं बताता और आपकी monitoring को alert करने के लिए कुछ नहीं देता।

queue को लगभग उस संख्या पर सेट करें जिसे आपका सर्वर आपके client के timeout के भीतर पूरा कर सके, और overflow तुरंत 503 error में बदल जाएगा। एक 503 उपयोगी है: एक reverse proxy इसे retry कर सकता है, एक client back off कर सकता है, एक dashboard इसे count कर सकता है, और एक व्यक्ति इसे पढ़ सकता है। इस संख्या का निर्धारण अपने स्वयं के measurements से करें। यदि एक generation में लगभग दस सेकंड लगते हैं और आपका client साठ सेकंड इंतज़ार करता है, तो प्रति slot लगभग छह requests उस window के भीतर पूरी हो सकती हैं, और उससे अधिक गहरी queue केवल timeouts ही पैदा करती है।

Ollama के सामने queue कब रखें

Ollama की इन-बिल्ट queue 'first in, first out' (FIFO) है और यह नहीं जानती कि कॉल कौन कर रहा है। एक सर्वर से बात करने वाले एक एप्लिकेशन के लिए यह पर्याप्त है, और अतिरिक्त इंफ्रास्ट्रक्चर केवल विफलता के नए कारण पैदा करेगा। यदि निम्नलिखित में से कोई भी स्थिति हो, तो सामने कुछ लगाने पर विचार करें।

• आपको प्राथमिकता (priority) की आवश्यकता है। एक इंटरैक्टिव चैट को बैच समराइजेशन जॉब के पीछे इंतजार नहीं करना चाहिए। Ollama की queue में कोई प्राथमिकता नहीं होती, इसलिए बैच वर्क को बाहर रोककर धीरे-धीरे फीड करना पड़ता है।
• आपको निष्पक्षता (fairness) की आवश्यकता है। एक क्लाइंट अकेले ही पूरी queue भर सकता है, जिसके बाद बाकी सभी को 503 एरर मिलने लगता है।
• आपको यह सुनिश्चित करना है कि रीस्टार्ट के बाद भी काम सुरक्षित रहे। queue सर्वर की मेमोरी में रहती है। Ollama को रीस्टार्ट करते ही सभी प्रतीक्षारत (waiting) रिक्वेस्ट खत्म हो जाती हैं।
• आपको बैकऑफ (backoff) के साथ वास्तविक रिट्राय (retries) की आवश्यकता है, जिसे कहीं रिकॉर्ड किया गया हो ताकि आप बाद में जांच सकें।

हल्का विकल्प एक reverse proxy है। Nginx में, limit_conn एक साथ होने वाले कनेक्शनों को सीमित करता है और limit_req प्रति क्लाइंट आने वाली रिक्वेस्ट की दर को सीमित करता है, जिससे ओवरफ्लो को प्रॉक्सी पर ही अस्वीकार कर दिया जाता है और वह Ollama की queue तक कभी नहीं पहुँचता। भारी विकल्प एक जॉब queue है जिसमें डेटाबेस के साथ एक वर्कर होता है जो Ollama को कॉल करता है। यदि आप चाहते हैं कि रिक्वेस्ट प्रोसेस रीस्टार्ट होने के बाद भी बनी रहे, तो यही सही तरीका है। वास्तविक ट्रैफिक के लिए इसका आकार निर्धारित करना अपने आप में एक कार्य है: concurrent users के लिए self-hosted LLM की योजना बनाना में इसकी गणना समझाई गई है, और VPS पर Ollama चलाना में उस बुनियादी इंस्टॉलेशन को कवर किया गया है जिस पर ये वेरिएबल आधारित हैं।

जब सही समाधान एक अलग सर्वर हो

एक सीमा ऐसी है जिसे आप किसी भी ट्यूनिंग से पार नहीं कर सकते। जब मॉडल लोड होता है, तो Ollama KV cache को समान, निश्चित स्लॉट्स में विभाजित कर देता है। एक खाली स्लॉट की मेमोरी का उपयोग किसी व्यस्त स्लॉट द्वारा नहीं किया जा सकता है, और मॉडल को अनलोड किए बिना स्लॉट्स की संख्या बदली नहीं जा सकती। यह डिज़ाइन एक व्यक्ति, एक छोटी टीम या कोडिंग एजेंट के लिए उपयुक्त है।

कई उपयोगकर्ताओं के लिए बनाए गए सर्वर अलग तरह से काम करते हैं। वे मांग के अनुसार KV cache को छोटे पेजों में आवंटित करते हैं और आने वाले अनुरोधों को पहले से चल रहे बैच में जोड़ देते हैं, जिससे मेमोरी का उपयोग निश्चित विभाजन के बजाय वास्तविक मांग के अनुसार होता है। यदि आपका लक्ष्य एक GPU पर बड़ी संख्या में समवर्ती उपयोगकर्ताओं को संभालना है, तो यह आर्किटेक्चरल अंतर OLLAMA_NUM_PARALLEL के किसी भी मान से अधिक महत्वपूर्ण है। Ollama और vLLM के बीच तुलना वह स्थान है जहाँ आप यह निर्णय ले सकते हैं। हालांकि, केवल सिद्धांत के आधार पर न बदलें: एक अलग सर्वर को संचालित करना अधिक जटिल है, और यदि आपका ट्रैफ़िक कुछ ही लोगों का है, तो इन-बिल्ट व्यवहार ही सही समाधान है।

अपने थ्रूपुट और 'टाइम टू फर्स्ट टोकन' को मापें

टोकन प्रति सेकंड (tokens per second) के प्रकाशित आंकड़े किसी और के GPU, मॉडल, क्वांटाइजेशन, कॉन्टेक्स्ट लेंथ और प्रॉम्प्ट पर आधारित होते हैं। इनमें से कोई भी आपके सेटअप से मेल नहीं खाता, इसलिए किसी भी आंकड़े को केवल एक अनुमान मानें और अपने सामने मौजूद मशीन पर स्वयं मापें।

Ollama हर रिस्पॉन्स के अंतिम JSON ऑब्जेक्ट में टाइमिंग की जानकारी देता है। eval_count उत्पन्न किए गए टोकन की संख्या है और eval_duration उन्हें उत्पन्न करने में लगा समय है, जो नैनोसेकंड में होता है।

sudo apt install -y jq
curl -s http://127.0.0.1:11434/api/generate \
  -d '{"model":"llama3.2:3b","prompt":"Explain what a KV cache is.","stream":false}' \
  | jq '{prompt_eval_count, eval_count, eval_duration, tokens_per_second: (.eval_count / (.eval_duration / 1000000000))}'

इसे एक स्लॉट के साथ चलाएं, फिर उस कॉन्करेंसी (concurrency) पर दोबारा चलाएं जिसकी आप वास्तव में अपेक्षा करते हैं। इसके बाद उन दो आंकड़ों की तुलना करें जो यह तय करते हैं कि उपयोगकर्ता संतुष्ट हैं या नहीं: 'टाइम टू फर्स्ट टोकन' और प्रति रिक्वेस्ट 'टोकन प्रति सेकंड'। जैसे-जैसे स्लॉट बढ़ाए जाते हैं, प्रति रिक्वेस्ट थ्रूपुट हमेशा गिरता है। मुख्य प्रश्न यह है कि क्या यह गिरावट उस स्तर से अधिक है जिसे आपके उपयोगकर्ता स्वीकार करेंगे। लोकल LLM पर टोकन प्रति सेकंड मापना इस विधि को अधिक विस्तार से कवर करता है, जिसमें यह भी शामिल है कि रन के बीच प्रॉम्प्ट को स्थिर कैसे रखा जाए।

एक public endpoint जिसमें बड़ी queue हो, वह denial of service का लक्ष्य बन सकता है

OLLAMA_HOST=0.0.0.0:11434 सेट करने से API हर interface पर उपलब्ध हो जाता है, और Ollama में कोई built-in authentication नहीं है। default queue वाला एक open endpoint किसी भी व्यक्ति से 512 waiting requests स्वीकार कर लेगा। उस queue को भरने में हमलावर का लगभग कुछ भी खर्च नहीं होता: लंबे prompts, कोई login नहीं, कोई rate limit नहीं, और कोई शुल्क नहीं। इसके बाद आपके अपने users को 503 responses मिलते हैं या उन्हें लंबा इंतज़ार करना पड़ता है, और machine हर समय व्यस्त रहती है।

Listener को loopback पर रखें और उस तक SSH tunnel या private network के माध्यम से पहुँचें, या इसके आगे authentication और rate limiting लगाएँ। Ollama API endpoint को सुरक्षित करना इन दोनों को कवर करता है। इसके बाद ही queue को tune करें, क्योंकि queue की लंबाई एक capacity setting है, और यह किसी चीज़ की सुरक्षा नहीं करती है।

FAQ

मेरी दूसरी Ollama request पहली के पूरा होने तक इंतज़ार क्यों करती है?

क्योंकि OLLAMA_NUM_PARALLEL का डिफ़ॉल्ट मान 1 है, इसलिए एक लोड किया गया मॉडल एक बार में केवल एक ही request प्रोसेस करता है और बाकी कतार में इंतज़ार करती हैं। इंतज़ार करने वाली request अपना HTTP connection खुला रखती है और जब तक कोई स्लॉट खाली नहीं होता, तब तक कोई डेटा नहीं भेजती। client-side से यह बिल्कुल धीमे मॉडल जैसा दिखता है। इसे पहचानने का तरीका timing है: यदि लंबा pause है और फिर टेक्स्ट पूरी गति से आता है, तो यह कतार (queue) है, जबकि यदि पहला टोकन मिलने के बाद टेक्स्ट धीरे-धीरे आता है, तो मॉडल धीमा है। systemd drop-in के साथ स्लॉट की संख्या बढ़ाएं और सर्विस को restart करें।

"server busy, please try again. maximum pending requests exceeded" का क्या अर्थ है?

यह Ollama का queue overflow error है, जो HTTP status 503 के साथ आता है। कतार में इंतज़ार कर रही requests की संख्या OLLAMA_MAX_QUEUE तक पहुँच गई है (जिसका डिफ़ॉल्ट मान 512 है), इसलिए नई request को कतार में जोड़ने के बजाय अस्वीकार कर दिया गया। यह memory error या model error नहीं है। कतार की सीमा बढ़ाने से callers को अस्वीकृति मिलने से पहले केवल अधिक इंतज़ार करना पड़ेगा। इसका वास्तविक समाधान यह है कि यदि आपके पास VRAM उपलब्ध है तो स्लॉट बढ़ाएं, आने वाले load को कम करें, या सामने एक ऐसी queue लगाएं जो retry और prioritization कर सके।

क्या OLLAMA_NUM_PARALLEL बढ़ाने से Ollama तेज़ हो जाता है?

नहीं। यह एक साथ अधिक requests को चलने की अनुमति देता है, और इनमें से प्रत्येक request अकेले चलने की तुलना में धीमी होती है क्योंकि वे एक ही GPU साझा करती हैं। यह KV cache को भी गुणा कर देता है, क्योंकि Ollama आपके context length और स्लॉट संख्या के गुणनफल के बराबर कुल context के साथ runner शुरू करता है। यदि परिणाम VRAM में फिट नहीं होता है, तो Ollama layers को CPU पर धकेल देता है और हर request धीमी हो जाती है, यहाँ तक कि बिना किसी प्रतिस्पर्धा वाली अकेली request भी। बदलाव के बाद ollama ps की जाँच करें और सुनिश्चित करें कि PROCESSOR कॉलम अभी भी 100% GPU दिखा रहा है।

क्या इन variables को बदलने के बाद मुझे Ollama को restart करने की आवश्यकता है?

हाँ। सर्वर इन्हें स्टार्टअप पर पढ़ता है, और एक चल रहा मॉडल उसी स्लॉट संख्या को बनाए रखता है जो लॉन्च के समय उसके runner process में तय की गई थी। sudo systemctl edit ollama.service के साथ drop-in को edit करें, फिर sudo systemctl daemon-reload और sudo systemctl restart ollama चलाएं। systemctl show ollama --property=Environment के साथ पुष्टि करें, और फिर journalctl -u ollama में server config लाइन की जाँच करें, जो उस environment को सूचीबद्ध करती है जिसे सर्वर ने वास्तव में लोड किया है।

मुझे कितने parallel स्लॉट सेट करने चाहिए?

1 से शुरू करें और एक बार में एक कदम बढ़ाएं। हर कदम के बाद, Ollama को restart करें, मॉडल लोड करने के लिए एक request भेजें, और ollama ps चलाएं। उस अंतिम मान पर रुकें जहाँ PROCESSOR अभी भी 100% GPU दिखाता है और SIZE कॉलम आपके द्वारा सर्व किए जाने वाले सबसे लंबे context के लिए जगह (headroom) छोड़ता है। फिर अपने वास्तविक concurrency के तहत उस सेटिंग पर 'time to first token' और 'tokens per second' मापें, और यदि प्रति request गति आपके उपयोगकर्ताओं की सहनशीलता से कम हो गई है, तो एक कदम पीछे हट जाएं।