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

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

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

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

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

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

August 2026 পর্যন্ত বর্তমান Ollama releases-এ এগুলো default value। এই সংখ্যাগুলো সরাসরি ধরে না নিয়ে আপনার সেটিং যাচাই করুন। নিচে দেখানো log line ব্যবহার করুন।

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

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

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

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

এটাই সম্পূর্ণ সীমাবদ্ধতা। এ কারণেই parallelism বিনামূল্যে নয়। প্রতি request-এর context একই রেখে এক slot থেকে চার slot-এ গেলে চার গুণ KV cache প্রয়োজন হয়। slot-গুলোর মধ্যে কিছু share হয় না। কোনো idle slot-এর বরাদ্দ 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 weight এবং ওই KV cache একসঙ্গে VRAM-এ না ধরলে Ollama কিছু layer system RAM-এ সরিয়ে দেয়। তখন ওই layer-গুলো CPU-তে চলে। CPU layer GPU layer-এর তুলনায় অনেক ধীর। ফলে শুরুতে চালানো একটিমাত্র request-সহ প্রতিটি request ধীর হয়ে যায়। তাই parallelism বাড়ালে throughput বাড়ার বদলে কমে যেতে পারে।

ollama ps

সবকিছু VRAM-এ 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 অনুমান নয়, পরিমাপ করে জানা যাবে।

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

রিবুটের পরও কার্যকর থাকে এমনভাবে এই ভেরিয়েবলগুলো কীভাবে সেট করবেন

Linux-এ Ollama একটি systemd service হিসেবে চলে। আপনার shell-এ export OLLAMA_NUM_PARALLEL=4 চালালে কোনো পরিবর্তন হয় না, কারণ systemd নিজস্ব environment নিয়ে service চালু করে এবং আপনার 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-কে কোন 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 চালু হওয়ার সময় যে slot count পেয়েছিল, সেটিই ধরে রাখে, কারণ value-টি runner process চালুর সময় নির্ধারিত হয়ে যায়। উপরের restart সবকিছু unload করে। তাই পরের request নতুন setting দিয়ে model reload করে এবং load time একবার ব্যয় করে। এরপর model কতক্ষণ resident থাকবে, সেটি আলাদা একটি control। এই বিষয়টি request-এর মধ্যে Ollama model loaded রাখা অংশে ব্যাখ্যা করা হয়েছে।

ক্লায়েন্টের দৃষ্টিতে পরিবেশিত, queue-তে অপেক্ষমাণ এবং প্রত্যাখ্যাত অনুরোধের চিত্র

একসঙ্গে কয়েকটি request পাঠিয়ে তাদের সময় মাপুন। এটি parallel-এ আটটি 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 পাওয়ার সময়। এটি প্রথম token পাওয়ার সময়ের (TTFT) কাছাকাছি, কারণ streamed প্রথম chunk-এ প্রথম token থাকে।

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

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

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

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

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

একটি সীমাবদ্ধতা মনে রাখুন: Ollama queue depth প্রকাশ করে না। ollama ps এবং /api/ps endpoint-এ loaded model-গুলোর তথ্য থাকে, অপেক্ষমাণ request-গুলোর নয়। তাই ক্লায়েন্ট-সাইড থেকেই queue মাপতে হবে—প্রথম byte পাওয়ার সময় পর্যবেক্ষণ করে। অথবা সামনের স্তরে যতগুলি 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 এটি গণনা করতে পারে, এবং মানুষও বার্তাটি পড়ে বুঝতে পারে। নিজের measurement থেকে সংখ্যাটি নির্ধারণ করুন। একটি generation সম্পন্ন হতে যদি প্রায় দশ সেকেন্ড লাগে এবং আপনার client ষাট সেকেন্ড অপেক্ষা করে, তাহলে ওই সময়সীমার মধ্যে প্রতি slot-এ প্রায় ছয়টি request সম্পন্ন করা সম্ভব। এর চেয়ে অনেক গভীর queue শুধু timeout তৈরি করবে।

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

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

• 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 একসঙ্গে চলা connection-এর সংখ্যা সীমিত করে এবং limit_req প্রতি client-এর request আসার হার সীমিত করে। ফলে অতিরিক্ত 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

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

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

নিজের throughput এবং প্রথম token পেতে সময় মাপুন

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

Ollama প্রতিটি response-এর শেষ 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 আশা করছেন, সেটি দিয়ে আবার চালান। তারপর ব্যবহারকারীর অভিজ্ঞতা নির্ধারণকারী দুটি সংখ্যা তুলনা করুন: প্রথম token পেতে সময় এবং প্রতি request-এ tokens per second। Slot যোগ করলে প্রতি request-এর throughput সবসময় কমে। প্রশ্ন হলো, এই হ্রাস ব্যবহারকারীরা যতটা গ্রহণ করতে পারবেন, তার চেয়ে বেশি কি না। স্থানীয় LLM-এ tokens per second মাপা পদ্ধতিটি আরও বিস্তারিতভাবে ব্যাখ্যা করে। এর মধ্যে run-গুলোর মধ্যে prompt অপরিবর্তিত রাখার পদ্ধতিও রয়েছে।

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

OLLAMA_HOST=0.0.0.0:11434 সেট করলে API প্রতিটি interface-এ bind হয়, এবং Ollama-তে built-in authentication নেই। ডিফল্ট queue-সহ একটি উন্মুক্ত endpoint যে কেউ খুঁজে পেলে তার কাছ থেকে 512টি অপেক্ষমাণ request গ্রহণ করবে। এই queue পূরণ করতে আক্রমণকারীর প্রায় কোনো খরচ নেই: দীর্ঘ 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-এর দিক থেকে এটি slow model-এর মতো দেখায়। সময়ের ধরনটি লক্ষ করুন: দীর্ঘ বিরতির পরে দ্রুত গতিতে text আসা queue-এর লক্ষণ। আর প্রথম token থেকেই ধীরে ধীরে text আসা slow 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-তে যোগ না করে reject করা হয়েছে। এটি memory error নয় এবং model error-ও নয়। Queue বাড়ালে একই rejection পাওয়ার আগে caller-কে শুধু আরও বেশি সময় অপেক্ষা করতে হবে। প্রকৃত সমাধান হলো VRAM পর্যাপ্ত থাকলে আরও slot ব্যবহার করা, incoming load কমানো, অথবা সামনে এমন queue রাখা যা retry ও prioritise করতে পারে।

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

না। এতে একই সময়ে আরও বেশি request চলতে পারে। তবে একটি GPU ভাগ করে নেওয়ায় প্রতিটি request একা চলার তুলনায় ধীর হয়। এটি 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 edit করুন। এরপর sudo systemctl daemon-reload এবং sudo systemctl restart ollama চালান। systemctl show ollama --property=Environment দিয়ে নিশ্চিত করুন। তারপর journalctl -u ollama-এর server config line পরীক্ষা করুন। এই line-এ server বাস্তবে যে environment load করেছে তা তালিকাভুক্ত থাকে।

কতগুলো parallel slot নির্ধারণ করা উচিত?

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 ব্যবহারকারীদের গ্রহণযোগ্য সীমার নিচে নেমে গেলে এক ধাপ কমিয়ে দিন।