Ollama concurrency: NUM_PARALLEL ও MAX_QUEUE কীভাবে কাজ

প্রথম অনুরোধ তৈরি হওয়ার সময় দ্বিতীয় Ollama অনুরোধের কী হয়

Ollama-তে concurrency তিনটি environment variable দিয়ে নির্ধারিত হয়। ডিফল্টভাবে একটি loaded model একবারে একটি অনুরোধ পরিবেশন করে। দ্বিতীয় অনুরোধ প্রত্যাখ্যাত হয় না এবং আংশিক উত্তরও পায় না। একটি slot খালি হওয়া পর্যন্ত এটি queue-তে অপেক্ষা করে। এরপর স্বাভাবিক গতিতে চলে।

আসা একটি অনুরোধের তিনটি সম্ভাব্য পরিণতি আছে। কোনো slot খালি থাকলে এটি সঙ্গে সঙ্গে শুরু হয়। তা না হলে queue-তে অপেক্ষা করে। অথবা queue ইতিমধ্যে পূর্ণ থাকলে server HTTP 503 দিয়ে অনুরোধটি প্রত্যাখ্যান করে। কোনটি ঘটবে তা OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE এবং OLLAMA_MAX_LOADED_MODELS নির্ধারণ করে।

ডিফল্ট সেটিং নিরাপদ। তবে কোনো সমস্যা না থাকলেও দ্বিতীয় user-এর কাছে server "hung" মনে হওয়ার কারণ এটিই। slot যোগ করতে দুই লাইনের পরিবর্তন যথেষ্ট। সমস্যাটি memory-তে। প্রতিটি parallel slot-এর নিজস্ব key/value cache (KV cache) প্রয়োজন। এটি এমন একটি memory block, যেখানে model ইতিমধ্যে process করা token-গুলো ধরে রাখে। VRAM (GPU-র video memory) না বাড়িয়ে slot যোগ করলে ধীর উত্তর পাওয়ার বদলে model load ব্যর্থ হতে পারে।

OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE এবং OLLAMA_MAX_LOADED_MODELS কী নিয়ন্ত্রণ করে

এগুলো August 2026 পর্যন্ত বর্তমান Ollama release-গুলোর default। নিচে দেখানো log line ব্যবহার করে আপনার সেটিং পরীক্ষা করুন; এখানে দেওয়া সংখ্যার ওপর নির্ভর করবেন না।

• OLLAMA_NUM_PARALLEL নির্ধারণ করে, একটি loaded model একই সময়ে কতটি request পরিচালনা করবে। Default হলো 1, তাই request একটির পর একটি পরিবেশিত হয়।
• OLLAMA_MAX_LOADED_MODELS নির্ধারণ করে, একই সময়ে কতটি ভিন্ন model resident থাকবে। Default হলো 0। এর অর্থ Ollama নিজে সংখ্যা নির্বাচন করে: প্রতি GPU-তে তিনটি model এবং GPU ছাড়া machine-এ তিনটি model।
• OLLAMA_MAX_QUEUE নির্ধারণ করে, সর্বোচ্চ কতটি request অপেক্ষমাণ থাকতে পারবে। Default হলো 512। Queue পূর্ণ থাকা অবস্থায় আসা request সঙ্গে সঙ্গে প্রত্যাখ্যান করা হয়।

সর্বোচ্চ memory usage প্রথম দুটি মানের গুণফল। চারটি slot-সহ দুটি loaded model হলে KV cache-এর আটটি slot allocation একই সময়ে resident থাকে, এবং Ollama এই চাহিদা পূরণ করার চেষ্টা করবে। একটি single-GPU machine-এ সাধারণত একটি model ধরে রেখে সেটিকে একাধিক slot দেওয়াই ভালো, কারণ হিসাবটি সহজেই হাতে করা যায়।

প্রতিটি parallel slot-এর জন্য VRAM কেন লাগে

Ollama কোনো model load করলে একটি আলাদা runner process চালু করে। এটি যে argument-গুলো পাঠায়, তার মধ্যে দুটি এখানে গুরুত্বপূর্ণ: -c হলো runner যে মোট context-এর জন্য KV cache বরাদ্দ করে, আর -np হলো parallel sequence-এর সংখ্যা। Ollama -c-এর মান নির্ধারণ করে প্রতি request-এর context length-কে slot count দিয়ে গুণ করে। এরপর runner মোট মানটি slot-গুলোর মধ্যে সমানভাবে ভাগ করে। ফলে প্রতিটি request আপনার নির্ধারিত context length-ই পায়।

এটাই সম্পূর্ণ সীমাবদ্ধতা। তাই parallelism বিনামূল্যে নয়। প্রতি request-এর context একই রেখে এক slot থেকে চার slot-এ গেলে চার গুণ KV cache প্রয়োজন হয়। slot-গুলোর মধ্যে কিছু share করা হয় না। কোনো slot idle থাকলেও তার বরাদ্দ busy slot-কে দেওয়া হয় না, কারণ runner চালু হওয়ার সময় এই বিভাজন স্থির হয়ে যায়।

আপনি যে মান সেট করতে চেয়েছিলেন তার বদলে বাস্তবে ব্যবহৃত মান দেখতে পারেন:

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

এই লাইনে -c এবং -np-সহ সম্পূর্ণ runner command line থাকে। আপনি variable সেট করার পরে যদি -np-এর মান 1 হয়, তাহলে setting server-এ পৌঁছাচ্ছে না। পরের section-এ এর কারণ ব্যাখ্যা করা হয়েছে।

Model weights এবং ওই KV cache একসঙ্গে VRAM-এ না ধরলে Ollama কিছু layer system RAM-এ সরিয়ে দেয়। সেই layer-গুলো CPU-তে চলে। CPU layer, GPU layer-এর তুলনায় অনেক ধীর। তাই শুরুতে একটি মাত্র request থাকলেও প্রতিটি request ধীর হয়ে যায়। ফলে parallelism বাড়ালে throughput বাড়ার বদলে কমে যেতে পারে। Model যথেষ্ট বড় হলে slot-এর হিসাব শুরু হওয়ার আগেই weights একাই বিষয়টি নির্ধারণ করে। তাই Kimi K3-এর মতো বড় কিছু self-hosting করা মূলত আপনার কাছে কতগুলো card আছে সেই আলোচনা, কতগুলো slot সেট করেছেন সেই আলোচনা নয়।

ollama ps

পুরো model fit করলে PROCESSOR column-এ 100% GPU দেখা যায়। 35%/65% CPU/GPU-এর মতো split-এর অর্থ model-এর একটি অংশ CPU-তে চলছে। SIZE column-এ KV cache-ও অন্তর্ভুক্ত থাকে। তাই slot count বাড়িয়ে model reload করলে এই মান বাড়ে। OLLAMA_NUM_PARALLEL বাড়ান, restart করুন, একটি request পাঠান, তারপর আবার ollama ps চালান। এতে আপনার পরিবর্তনের memory cost অনুমান নয়, মেপে জানা যাবে। এই measurement-এ যদি model আর fit না করে, মনে রাখুন weights একই budget-এর অন্য অর্ধেক। আপনি যে অতিরিক্ত slot যোগ করতে চেয়েছিলেন, তার খরচের তুলনায় fp16 থেকে q8 বা q4 build-এ পরিবর্তন করা প্রায়ই বেশি VRAM খালি করে।

Context length এবং slot count পরস্পর গুণ হয়। তাই দুটিকে একসঙ্গে নির্বাচন করতে হবে। চারটি slot-সহ বড় context মানে চারটি বড় context। আপনি যদি আপনার model-এর num_ctx context window-ও tuning করেন, তাহলে একবারে দুটির মধ্যে একটিই পরিবর্তন করুন। তা না হলে কোনটি card-এর VRAM পূর্ণ করেছে তা বোঝা যাবে না।

রিবুটের পরেও এই variable-গুলো কীভাবে কার্যকর রাখবেন

Linux-এ Ollama একটি systemd service হিসেবে চলে। আপনার shell-এ export OLLAMA_NUM_PARALLEL=4 চালালেও কোনো পরিবর্তন হয় না, কারণ systemd নিজস্ব environment দিয়ে service শুরু করে এবং আপনার shell-এর environment দেখতে পায় না। এর জন্য একটি 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-কে যে environment দেবে, তা দেখায়। সেখানে আপনার variable না থাকলে drop-in সংরক্ষণ করা হয়নি অথবা daemon-reload চালানো হয়নি। সার্ভারের নিজস্ব দিক থেকেও নিশ্চিত করুন:

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

Ollama startup-এর সময় তার সম্পূর্ণ environment এমন একটি line-এ log করে, যার message হলো server config। ওই map-ই নির্ভরযোগ্য তথ্য। কোনো variable কার্যকর হয়েছে কি না, তা দ্রুত নিশ্চিত করার সবচেয়ে সহজ উপায় এটি।

ইতিমধ্যে loaded থাকা model-টি startup-এর সময় নির্ধারিত slot count-ই ধরে রাখে, কারণ value-টি launch-এর সময় runner process-এ স্থির হয়ে যায়। উপরের restart সবকিছু unload করে। তাই পরের request নতুন setting দিয়ে model reload করে এবং load time একবার ব্যয় হয়। এরপর model কতক্ষণ resident থাকবে, তা আলাদা একটি control। এ বিষয়ে request-এর মধ্যে Ollama model loaded রাখা অংশে বলা হয়েছে।

ক্লায়েন্টের দিক থেকে served, queued এবং refused অবস্থার চেহারা

একসঙ্গে কয়েকটি অনুরোধ পাঠিয়ে সেগুলোর সময় মাপুন। এটি সমান্তরালে আটটি streaming request চালায় এবং প্রতিটির status ও timing দেখায়:

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 হলো stream-এর প্রথম byte পাওয়া পর্যন্ত সময়। এটি first token time (TTFT)-এর কাছাকাছি, কারণ stream-এর প্রথম chunk-এ প্রথম token থাকে।

সমান্তরালে served। প্রতিটি অনুরোধে একই রকম ttfb দেখা যায় এবং সবার total একসঙ্গে বাড়ে। চলমান slot-গুলোর মধ্যে GPU ভাগ হয়ে যায়। তাই প্রতিটি উত্তর একা চলার তুলনায় ধীর হয়, তবে প্রতি মিনিটে বেশি উত্তর সম্পন্ন হয়। OLLAMA_NUM_PARALLEL বাড়ালে আপনি এই কার্যপদ্ধতিই নির্বাচন করছেন।

Queued। প্রথম অনুরোধগুলো দ্রুত উত্তর পায়। পরের অনুরোধগুলোতে বড় ttfb দেখা যায়, তারপর স্বাভাবিক generation হয়। এই অপেক্ষাটিই queue; model ধীর নয়। chat window দেখা একজন ব্যবহারকারী দীর্ঘ সময় খালি পর্দা দেখেন, তারপর পূর্ণ গতিতে text পেতে শুরু করেন। শুরুতে ধীর এবং পরে দ্রুত—এই ধরনটি overloaded GPU-এর নয়, queue-এর লক্ষণ।

Refused। ক্লায়েন্ট প্রায় সঙ্গে সঙ্গেই http=503 পায় এবং body হলো:

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

এই message-এর অর্থ হলো, অনুরোধটি আসার মুহূর্তে queue পূর্ণ ছিল। এটি VRAM সম্পর্কে কিছু জানায় না এবং model সম্পর্কেও কিছু জানায় না।

একটি সীমাবদ্ধতা মনে রাখুন: Ollama queue depth প্রকাশ করে না। ollama ps এবং /api/ps endpoint loaded model-গুলোর তথ্য দেয়, অপেক্ষমাণ অনুরোধগুলোর নয়। তাই client side থেকে queue মাপতে হবে—প্রথম byte পাওয়ার সময় পর্যবেক্ষণ করে—অথবা সামনে থাকা component-এ কতটি 503 response এসেছে তা গুনতে হবে।

একটি ছোট MAX_QUEUE কেন প্রায়ই ভালো সেটিং

512-এর queue যথেষ্ট বড় মনে হতে পারে, কিন্তু একটি মাত্র slot থাকলে এটি প্রায় অকার্যকর। Request 300 সম্পূর্ণ হতে থাকা 299টি generation-এর পেছনে অপেক্ষা করে। সর্বোত্তম অবস্থাতেও এতে কয়েক মিনিট লাগবে। সব HTTP client তার অনেক আগেই অপেক্ষা বন্ধ করে দেয়। ফলে caller client-side timeout দেখতে পায়। এতে কারণ বোঝা যায় না এবং আপনার monitoring-এ alert দেওয়ার মতো তথ্যও থাকে না।

আপনার client-এর timeout-এর মধ্যে server যতগুলো request সম্পন্ন করতে পারে, queue প্রায় সেই আকারে সেট করুন। তাহলে অতিরিক্ত request সঙ্গে সঙ্গে 503 পাবে। 503 কার্যকর: reverse proxy এটি retry করতে পারে, client back off করতে পারে, dashboard এটি গণনা করতে পারে এবং একজন administrator বার্তাটি পড়তে পারেন। আপনার নিজস্ব measurement থেকে সংখ্যাটি নির্ধারণ করুন। একটি generation সম্পন্ন হতে প্রায় দশ সেকেন্ড লাগে এবং client 60 সেকেন্ড অপেক্ষা করলে, সেই সময়ের মধ্যে প্রতিটি slot প্রায় ছয়টি request সম্পন্ন করতে পারে। এর চেয়ে অনেক গভীর queue শুধু timeout তৈরি করবে।

Ollama-এর সামনে কখন queue বসাবেন

Built-in queue প্রথমে আসা কাজ আগে প্রক্রিয়া করে (FIFO), এবং কে অনুরোধ পাঠাচ্ছে তা এটি জানে না। একটি application একটি server-এর সঙ্গে যোগাযোগ করলে এটুকুই যথেষ্ট। অতিরিক্ত infrastructure যোগ করলে শুধু failure mode বাড়বে। নিচের যেকোনো একটি প্রয়োজন হলে সামনে একটি ব্যবস্থা ব্যবহার করুন।

• Priority দরকার। Interactive chat যেন batch summarisation job-এর পেছনে অপেক্ষা না করে। Ollama-এর queue-তে priority নেই। তাই batch কাজ বাইরে ধরে রেখে ধীরে ধীরে পাঠাতে হবে।
• Fairness দরকার। একটি client একাই queue পূর্ণ করে ফেলতে পারে। তখন অন্য সবাই 503 পাবে।
• Restart-এর পরেও কাজ টিকে থাকা দরকার। Queue server-এর memory-তে থাকে। Ollama restart করলে অপেক্ষমাণ প্রতিটি request হারিয়ে যাবে।
• Backoff-সহ প্রকৃত retry দরকার, এবং পরে পরিদর্শনের জন্য সেগুলো কোথাও record করা দরকার।

সহজ সমাধান হলো একটি reverse proxy। nginx-এ limit_conn simultaneous connection-এর সংখ্যা সীমিত করে এবং limit_req প্রতি client-এর arrival rate সীমিত করে। ফলে অতিরিক্ত request proxy-তেই প্রত্যাখ্যাত হয় এবং Ollama-এর queue-তে পৌঁছায় না। ভারী সমাধান হলো database-সহ একটি job queue, যার সামনে এমন একটি worker থাকে যে Ollama-কে call করে। Request-গুলোকে process restart-এর পরেও টিকিয়ে রাখতে হলে এটাই প্রয়োজন। প্রকৃত traffic অনুযায়ী এর আকার নির্ধারণ করা আলাদা কাজ: concurrent user-এর জন্য self-hosted LLM পরিকল্পনা করা-এ প্রয়োজনীয় হিসাব দেখানো হয়েছে, এবং VPS-এ Ollama চালানো-এ এই variable-গুলো যে base install ধরে নেয় তা ব্যাখ্যা করা হয়েছে।

সৎ উত্তর যখন অন্য একটি server

একটি সীমা আছে, যা configuration পরিবর্তন করে অতিক্রম করা যায় না। Model load হওয়ার সময় Ollama KV cache-কে সমান আকারের fixed slot-এ ভাগ করে। Idle slot-এর memory busy slot ব্যবহার করতে পারে না। Model unload না করা পর্যন্ত slot-এর সংখ্যা পরিবর্তন করা যায় না। এই design একজন ব্যক্তি, ছোট team বা coding agent-এর জন্য উপযোগী।

অনেক simultaneous user-এর জন্য তৈরি server ভিন্নভাবে কাজ করে। তারা প্রয়োজন অনুযায়ী ছোট page-এ KV cache বরাদ্দ করে এবং চলমান batch-এ আসা request যোগ করে। ফলে memory fixed ভাগের বদলে প্রকৃত চাহিদা অনুসরণ করে। একটি GPU-তে অনেক concurrent user চালানো আপনার লক্ষ্য হলে, এই architectural পার্থক্য OLLAMA_NUM_PARALLEL-এর যেকোনো value-এর চেয়ে বেশি গুরুত্বপূর্ণ। Ollama ও vLLM-এর তুলনা-এ এই সিদ্ধান্ত নেওয়ার উপযুক্ত আলোচনা আছে। তবে নীতিগত কারণে switch করবেন না। অন্য server পরিচালনা করা বেশি জটিল। আপনার traffic যদি কয়েকজন user-এর মধ্যে সীমাবদ্ধ থাকে, তাহলে built-in behaviour-ই সঠিক পছন্দ।

নিজের throughput এবং time to first token পরিমাপ করুন

প্রকাশিত tokens per second-এর পরিসংখ্যান অন্য কারও GPU, model, quantisation, context length এবং prompt থেকে পাওয়া। এগুলোর কোনোটিই আপনার ব্যবস্থার সঙ্গে মেলে না। তাই পড়া যেকোনো সংখ্যাকে আনুমানিক নির্দেশনা হিসেবে নিন এবং আপনার সামনে থাকা machine-এর কর্মক্ষমতা নিজেই পরিমাপ করুন।

Ollama প্রতিটি response-এর final JSON object-এ timing ফেরত দেয়। eval_count হলো তৈরি হওয়া token-এর সংখ্যা এবং eval_duration হলো সেগুলো তৈরি করতে ব্যয় হওয়া সময়, nanosecond-এ।

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

প্রথমে এটি একটি slot নিয়ে চালান। এরপর আপনি বাস্তবে যে concurrency আশা করছেন, সেটি ব্যবহার করে আবার চালান। তারপর ব্যবহারকারীরা সন্তুষ্ট কি না নির্ধারণ করে এমন দুটি সংখ্যা তুলনা করুন: time to first token এবং প্রতি request-এ tokens per second। slot যোগ করলে প্রতি request-এর throughput সবসময় কমে। প্রশ্ন হলো, এটি আপনার ব্যবহারকারীরা যতটা গ্রহণ করতে পারবেন তার চেয়ে বেশি কমে কি না। স্থানীয় LLM-এ প্রতি সেকেন্ডে token পরিমাপ করা পদ্ধতিটি আরও বিস্তারিতভাবে ব্যাখ্যা করে। এর মধ্যে প্রতিটি run-এর সময় prompt অপরিবর্তিত রাখার পদ্ধতিও রয়েছে।

উদার queue-সহ একটি public endpoint denial-of-service আক্রমণের লক্ষ্য হতে পারে

OLLAMA_HOST=0.0.0.0:11434 সেট করলে API প্রতিটি interface-এ bind হয়, এবং Ollama-তে built-in authentication নেই। Default queue-সহ একটি open endpoint যে কেউ খুঁজে পেলে তার কাছ থেকে 512টি অপেক্ষমাণ request গ্রহণ করবে। এই queue পূরণ করতে attacker-এর প্রায় কোনো খরচ হয় না: দীর্ঘ prompt, login নেই, rate limit নেই, bill নেই। তখন আপনার নিজস্ব user-রা 503 response বা দীর্ঘ অপেক্ষার সম্মুখীন হবে, এবং মেশিনটি পুরো সময় ব্যস্ত থাকবে।

Listener-টি loopback-এ রাখুন এবং SSH tunnel বা private network-এর মাধ্যমে এতে পৌঁছান, অথবা এর সামনে authentication ও rate limiting যুক্ত করুন। Ollama API endpoint সুরক্ষিত করা—এ দুটিরই ব্যাখ্যা দেয়। এরপর queue সমন্বয় করুন, কারণ queue length একটি capacity setting; এটি কোনো সুরক্ষা দেয় না।

FAQ

আমার দ্বিতীয় Ollama request কেন প্রথমটি শেষ হওয়া পর্যন্ত অপেক্ষা করে?

কারণ OLLAMA_NUM_PARALLEL-এর default মান 1। তাই loaded model একবারে একটি request চালায় এবং বাকি request-গুলো ক্রমানুসারে অপেক্ষা করে। অপেক্ষমাণ request তার HTTP connection খোলা রাখে, কিন্তু কোনো slot খালি না হওয়া পর্যন্ত byte পাঠায় না। Client-এর দিক থেকে এটি ধীর model-এর মতোই দেখায়। সময়ের ধরন দেখে পার্থক্য বোঝা যায়: দীর্ঘ বিরতির পরে পূর্ণ গতিতে text আসা queue নির্দেশ করে, আর প্রথম token থেকেই ধীরে ধীরে text আসা ধীর model নির্দেশ করে। systemd drop-in ব্যবহার করে slot count বাড়ান এবং service restart করুন।

"server busy, please try again. maximum pending requests exceeded" বলতে কী বোঝায়?

এটি Ollama-এর queue overflow error, যা HTTP status 503 সহ ফেরত আসে। ইতিমধ্যে অপেক্ষমাণ request-এর সংখ্যা OLLAMA_MAX_QUEUE-এ পৌঁছেছে। এর default মান 512। তাই নতুন request-টি queue-তে যোগ না করে প্রত্যাখ্যান করা হয়েছে। এটি memory error নয় এবং model error-ও নয়। Queue বড় করলে একই প্রত্যাখ্যানের আগে caller-দের আরও বেশি সময় অপেক্ষা করতে হবে। তাই প্রকৃত সমাধান হলো, পর্যাপ্ত VRAM থাকলে আরও slot ব্যবহার করা, incoming load কমানো, অথবা সামনে এমন একটি queue ব্যবহার করা যা retry ও prioritise করতে পারে।

OLLAMA_NUM_PARALLEL বাড়ালে কি Ollama দ্রুত হয়?

না। এতে একই সময়ে আরও বেশি request চলতে পারে। তবে প্রতিটি request একা চলার তুলনায় ধীর হয়, কারণ তারা একই GPU ভাগ করে ব্যবহার করে। এটি KV cache-ও বাড়ায়, কারণ Ollama runner চালু করার সময় context length-কে slot count দিয়ে গুণ করে মোট context নির্ধারণ করে। ফলাফল VRAM-এ আর না ধরলে Ollama কিছু layer CPU-তে সরিয়ে দেয়। তখন প্রতিটি request ধীর হয়, এমনকি কোনো প্রতিযোগিতা ছাড়া একটি request-ও। পরিবর্তনের পরে ollama ps পরীক্ষা করুন এবং নিশ্চিত করুন যে PROCESSOR column-এ এখনও 100% GPU লেখা আছে।

এই variable-গুলো পরিবর্তন করার পরে কি Ollama restart করতে হবে?

হ্যাঁ। Server startup-এর সময় এগুলো পড়ে। Running model তার runner process চালু হওয়ার সময় নির্ধারিত slot count ব্যবহার করে। sudo systemctl edit ollama.service দিয়ে drop-in সম্পাদনা করুন। এরপর sudo systemctl daemon-reload এবং sudo systemctl restart ollama চালান। systemctl show ollama --property=Environment দিয়ে নিশ্চিত করুন। তারপর journalctl -u ollama-এর server config line পরীক্ষা করুন। সেখানে server বাস্তবে যে environment load করেছে তা তালিকাভুক্ত থাকে।

কতগুলো parallel slot সেট করা উচিত?

1 দিয়ে শুরু করুন এবং একবারে 1 ধাপ করে বাড়ান। প্রতিটি ধাপের পরে Ollama restart করুন, model load করার জন্য একটি request পাঠান এবং ollama ps চালান। যে সর্বশেষ মানে PROCESSOR-এ এখনও 100% GPU লেখা থাকে এবং SIZE column-এ আপনার পরিবেশিত দীর্ঘতম context-এর জন্য পর্যাপ্ত headroom থাকে, সেখানে থামুন। এরপর বাস্তব concurrency-তে ওই setting ব্যবহার করে time to first token এবং tokens per second মাপুন। Per-request speed ব্যবহারকারীদের গ্রহণযোগ্য সীমার নিচে নেমে গেলে 1 ধাপ পিছিয়ে যান।