Ollama model মেমরিতে loaded রাখার উপায়

Ollama কয়েক মিনিট পর model unload করে কেন?

Ollama শেষ request-এর পর পাঁচ মিনিট model-টি memory-তে loaded রাখে, তারপর তা মুক্ত করে। পরবর্তী request-এ weights-কে disk থেকে পড়ে আবার RAM বা VRAM-এ map করতে হয়। তাই প্রথম token আসার আগে কিছুক্ষণ অপেক্ষা করতে হয়। এজন্য chat UI বা coding agent দ্রুত কাজ করে, কিছুক্ষণ নিষ্ক্রিয় থাকে, তারপর পরের message-এ আবার ধীর মনে হয়। কোনো কিছু নষ্ট হয়নি। Idle timer-এর সময়সীমা শেষ হয়েছে।

এই timer-এর নাম keep_alive। এটি প্রতি model-এর জন্য আলাদা এবং প্রতিটি request শেষ হলে আবার শুরু হয়। কোনো model বর্তমানে request-এর উত্তর দিলে সেটি কখনো unload হয় না, কারণ server কেবল active request না থাকা model-এর timer শেষ করে। August 2026 অনুযায়ী default হলো পাঁচ মিনিট। এই server যত model load করে, সবার ক্ষেত্রেই এটি প্রযোজ্য।

keep_alive সেট করার দুটি জায়গা আছে: individual request-এ অথবা server default হিসেবে। একটি systemd drop-in ব্যবহার করলে restart-এর পরও server default বজায় থাকে। এই guide ধরে নিচ্ছে যে Ollama ইতিমধ্যে একটি service হিসেবে চলছে। তা না চললে একটি VPS-এ Ollama install করা দিয়ে শুরু করুন এবং পরে এখানে ফিরে আসুন।

এই মুহূর্তে কোন মডেলগুলো মেমরিতে আছে এবং কখন সেগুলোর মেয়াদ শেষ হবে?

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

খালি output-এর অর্থ হলো কোনো মডেল লোড করা নেই। তাই পরবর্তী request-এ সম্পূর্ণ load সময় লাগবে। PROCESSOR দেখায় weights কোথায় রাখা হয়েছে। 100% GPU এবং 100% CPU হলো পরিষ্কার অবস্থা। 25%/75% CPU/GPU-এর মতো split-এর অর্থ হলো মডেলটি VRAM-এ সম্পূর্ণভাবে fit করেনি। তাই এর একটি অংশ processor-এ চলে এবং generation ধীর হয়।

UNTIL হলো countdown। এটি 4 minutes from now-এর মতো relative time দেখায়। মডেলটি negative keep_alive দিয়ে load করা হলে এটি Forever দেখায়। server মডেল unload করার অল্প সময়ের window-তে এটি Stopping... দেখায়।

release-গুলোর মধ্যে column set পরিবর্তিত হয়েছে। তাই script-এ field গুনে নেওয়ার পরিবর্তে header পড়ুন। স্বয়ংক্রিয় কাজের জন্য API-কে জিজ্ঞেস করুন:

curl -s http://localhost:11434/api/ps

প্রতিটি entry-তে expires_at, 2026-08-09T14:38:31.83753Z-এর মতো একটি absolute timestamp, এবং size_vram থাকে। size_vram হলো ওই মডেলের GPU memory-তে থাকা অংশ। size_vram-এর মান 0 হলে মডেলটি CPU-তে চলছে।

আবার লোড করার প্রকৃত খরচ

অনুমান করবেন না। Ollama প্রতিটি response-এ load time জানায়, যা load_duration হিসেবে nanosecond-এ দেওয়া থাকে।

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

প্রথম call-এ model load হয়, তাই এর load_duration বড় থাকে। এটিকে second হিসেবে পড়তে 1000000000 দিয়ে ভাগ করুন। দ্বিতীয় call-টি model resident থাকা অবস্থায় চলে এবং অনেক ছোট সংখ্যা দেখায়। এই দুই সংখ্যার ব্যবধানই timer শেষ হওয়ার পরে প্রতিটি user-এর দিতে হয়। keep_alive পরিবর্তনের মূল কারণও এটি। এই ব্যবধানের বেশির ভাগই disk read-এর কারণে হয়। তাই আপনি যদি model directory-টি দ্বিতীয় volume-এ সরিয়ে নিয়ে থাকেন, সেই volume-এর speed প্রতিটি cold load-এর সর্বনিম্ন সময় নির্ধারণ করে। ওই বিরতির আগে ও পরে generation speed মাপতে নিজের box-এ প্রতি second-এ কত token তৈরি হয় তা মাপার পদ্ধতি দেখুন।

একটি অনুরোধে Ollama model মেমরিতে লোড করে রাখুন

অনুরোধের সঙ্গে keep_alive পাঠান। অনুরোধ সম্পন্ন হওয়ার মুহূর্ত থেকে এটি ওই model-এর ক্ষেত্রে প্রযোজ্য হবে।

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

চার ধরনের value গ্রহণ করা হয়:

• duration string: "30m", "24h", "90s"
• সাধারণ number, যা seconds হিসেবে পড়া হয়: 3600
• negative value, -1 বা "-1m", যার অর্থ idle timeout একেবারেই থাকবে না
• 0, যার অর্থ এই অনুরোধ শেষ হওয়ার সঙ্গে সঙ্গে model unload করা হবে

অনুরোধে দেওয়া value server default-কে উভয় ক্ষেত্রেই override করে। এর গুরুত্ব প্রত্যাশার চেয়ে বেশি: কোনো client নিজের keep_alive পাঠালে server-এ কনফিগার করা যেকোনো value-এর ওপর সেটিই কার্যকর হবে।

কোনো output generate না করেও model লোড করতে পারেন। শুধু model-এর নাম পাঠান। server এটি লোড করবে এবং "done": true-সহ একটি খালি response ফেরত দেবে।

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

Reboot-এর পরে বা নতুন model pull করার পরে চালানোর জন্য এটিই command। এতে প্রথম প্রকৃত user request-কে model লোড হওয়ার সময় অপেক্ষা করতে হয় না। CLI-তেও একটি flag দিয়ে একই কাজ করা যায়:

ollama run --keepalive 30m qwen3:8b "hello"

OLLAMA_KEEP_ALIVE দিয়ে ডিফল্টভাবে লোড করে রাখুন

সার্ভারটি startup-এর সময় OLLAMA_KEEP_ALIVE পড়ে এবং যেসব model-এর নিজস্ব মান নেই, সেগুলোর জন্য এই মান ব্যবহার করে। এটি request field-এর মতো একই format গ্রহণ করে। তাই 30m, 3600 এবং -1—সবই কাজ করে।

মূল বিষয় হলো, variable-টি কোন environment-এ থাকতে হবে। আপনার SSH session-এ export OLLAMA_KEEP_ALIVE=30m চালালে কোনো ফল হবে না, কারণ packaged install server-টিকে systemd service হিসেবে নিজস্ব user এবং নিজস্ব environment-এর অধীনে চালায়। আপনার login shell এবং ওই service-এর environment কখনো এক হয় না। Setting-টি উপেক্ষিত হচ্ছে বলে মনে হওয়ার সবচেয়ে সাধারণ কারণ এটি।

systemd drop-in ব্যবহার করে restart-এর পরেও এটি চালু রাখুন

sudo systemctl edit ollama.service

editor-এ দুটি comment marker দেখা যায়। এই দুটির মধ্যে লিখুন: দ্বিতীয় marker-এর নিচে আপনি যা লিখবেন, systemd তা বাতিল করে।

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

সংরক্ষণ করলে /etc/systemd/system/ollama.service.d/override.conf লেখা হয়। এটি shipped unit সম্পাদনা না করে একটি drop-in তৈরি করে। তাই Ollama package upgrade-এর সময় ollama.service প্রতিস্থাপিত হলেও আপনার setting অপরিবর্তিত থাকে। drop-in এবং unit file আপনার কাছে নতুন হলে, systemd service ও timer guide-এ এই প্রক্রিয়ার বিস্তারিত ব্যাখ্যা রয়েছে।

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

শেষ command-টি service বাস্তবে যে environment নিয়ে চলবে, তা দেখায়। ওই line-এ OLLAMA_KEEP_ALIVE=30m না থাকলে drop-in কার্যকর হয়নি। এর কারণ প্রায় সব সময় অনুপস্থিত [Service] header অথবা marker-এর নিচে লেখা line। restart করলে loaded model-গুলো সরিয়ে ফেলা হয়, তাই পরের request-এ model নতুন করে load হবে। উপরের preload call ব্যবহার করে আগে থেকেই model load করে নিন।

একটি model resident রাখার খরচ

ollama ps-এর SIZE column-এ পুরো idle window জুড়ে ধরে রাখা memory দেখানো হয়, শুধু request চলাকালীন নয়। 4-bit quantisation-এ 8B model সাধারণত 5 থেকে 6 GB memory নেয়। 27B model-এর ক্ষেত্রে হিসাবটি সম্পূর্ণ ভিন্ন, এবং CPU-only VPS-এ একটি model চালানোর memory হিসাব resident রাখার সিদ্ধান্ত নেওয়ার আগে করে দেখা উচিত। keep_alive-কে -1 সেট করলে আপনি স্থায়ীভাবে সিদ্ধান্ত নিচ্ছেন যে ওই box-এর অন্য সব কিছুর চেয়ে model-এর অগ্রাধিকার বেশি। ছোট VPS-এ এটি সরাসরি আপনার database, web app এবং build job-এর সঙ্গে memory ভাগাভাগির বিষয়।

অনুমানের ওপর নির্ভর না করে প্রকৃত সংখ্যা দেখুন। একটি model loaded থাকা অবস্থায় এটি চালান, তারপর ollama stop-এর পর আবার চালান:

free -h

available column-এ kernel নতুন process-কে এখনও দিতে পারে এমন memory দেখানো হয়। NVIDIA GPU box-এ nvidia-smi একই বিষয় VRAM-এর ক্ষেত্রে দেখায়। Box-এর memory শেষ হয়ে গেলে kernel recovery করার জন্য একটি process বন্ধ করে দেয়:

sudo dmesg -T | grep -i "out of memory"

ollama-এর নাম থাকা line-এর অর্থ হলো model server-টি বন্ধ হওয়া process। আপনার database-এর নাম থাকা line-এর অর্থ হলো model জিতেছে এবং আপনার গুরুত্বপূর্ণ কোনো service ক্ষতিগ্রস্ত হয়েছে। উভয় ফলাফলের কারণ একই: headroom না থাকা box-এ দীর্ঘ keep-alive window।

এখানে দুটি খরচ সহজে চোখ এড়িয়ে যায়। বেশি context length বড় KV cache সংরক্ষণ করে। KV cache হলো key value cache, অর্থাৎ model generate করার সময় প্রতি token-এর জন্য ধরে রাখা attention state। এই cache resident size-এর অংশ। এর আকার num_ctx-এর ওপর নির্ভর করে। তাই context window বাড়ালে model উত্তর দেওয়ার সময় নয়, পুরো idle period জুড়েই বেশি memory ধরে রাখে। 1-এর বেশি OLLAMA_NUM_PARALLEL থাকলে প্রতি parallel slot-এর জন্য ওই cache একবার করে সংরক্ষণ করা হয়। একটি model থেকে একাধিক ব্যক্তিকে serve করার পরিকল্পনা থাকলে শুধু weights-এর জন্য নয়, slot-গুলোর জন্যও memory নির্ধারণ করুন।

একটি যুক্তিসঙ্গত default হলো: headroom থাকা box-এ একটি model -1 ব্যবহার করতে পারে। Shared box-এ এমন window ব্যবহার করা উচিত যা আপনার request-গুলোর মধ্যবর্তী বিরতি পর্যন্ত কার্যকর থাকে, যেমন 30m। এতে আপনি কাজ থামালে memory আবার মুক্ত হয়।

একটি model তাৎক্ষণিকভাবে unload করুন

ollama stop qwen3:8b

কোনো output ছাড়াই এটি ফিরে আসে এবং model-টি ollama ps থেকে সরে যায়। যে name loaded নয়, তার ক্ষেত্রে couldn't find model "qwen3:8b" to stop ফেরত আসে। API form-এ কোনো prompt থাকে না এবং keep_alive-এর মান 0 সেট করা থাকে:

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

উত্তরে "done_reason": "unload" থাকে। service restart করার পরিবর্তে এটি ব্যবহার করুন। systemctl restart ollama memory-ও মুক্ত করে, তবে এটি অন্য সব loaded model সরিয়ে দেয় এবং চলমান যেকোনো request বন্ধ করে দেয়।

একটি সার্ভারে একাধিক model চালানো

OLLAMA_MAX_LOADED_MODELS একসঙ্গে কতগুলো model loaded থাকবে তা সীমাবদ্ধ করে। August 2026 অনুযায়ী, প্রতিটি GPU-তে default হিসেবে তিনটি model, অথবা CPU-only সার্ভারে তিনটি model রাখা যায়। এই সীমা model-এর সংখ্যা গণনা করে, কিন্তু প্রকৃত সীমা হলো memory। তাই তিনটিতে পৌঁছানোর অনেক আগেই দ্বিতীয় বড় model-এর জন্য পর্যাপ্ত memory না থাকায় সেটি প্রত্যাখ্যাত হতে পারে।

নতুন কোনো model-এর request এলে এবং তার জন্য পর্যাপ্ত memory না থাকলে scheduler জায়গা তৈরি করতে resident model-গুলোর একটি unload করে। এটি active request না থাকা model-কে অগ্রাধিকার দেয়। Timer শেষ না হলেও কোনো model evict করতে পারে, -1 দিয়ে loaded model-ও এর অন্তর্ভুক্ত। তাই ঋণাত্মক keep_alive মানে idle timeout নেই। এটি অন্য model-এর request থেকে weights-কে স্থায়ীভাবে সংরক্ষণ করে না।

এই সিদ্ধান্ত debug level-এ log করা হয়। একই drop-in-এ দ্বিতীয় Environment="OLLAMA_DEBUG=1" line যোগ করুন, service restart করুন, তারপর log monitor করুন:

sudo journalctl -u ollama -f

যে request-এর কারণে unload হয়েছে, তার পাশে runner-এর জায়গা খালি করতে সেটি unload করার বিষয়ে একটি line থাকলে বুঝবেন, এই সার্ভারে দুটি model একসঙ্গে রাখা সম্ভব নয়। সমাধান হলো এই সার্ভারে কম model রাখা, অথবা যে model-কে দ্রুত উত্তর দিতে হবে তার জন্য দীর্ঘ window রাখা এবং যেটি খুব কম ব্যবহার করেন তার জন্য 0 ব্যবহার করা।

পরবর্তী release-এর পরেও কার্যকর নির্দেশনা

Ollama ঘন ঘন release প্রকাশ করে এবং এর default পরিবর্তিত হয়। তাই সংখ্যা মুখস্থ না করে আপনার সামনে থাকা build পরীক্ষা করুন:

ollama --version
ollama serve --help

ollama serve --help-এ ওই build আসলে যে environment variable পড়ে, সেগুলোর তালিকা আছে। এর মধ্যে OLLAMA_KEEP_ALIVE-ও রয়েছে। সব release-এ দুটি নিয়ম কার্যকর থেকেছে এবং এগুলোর ওপর নির্ভর করে configuration তৈরি করা নিরাপদ। Request-এ দেওয়া value server default-এর ওপর অগ্রাধিকার পায়। আর configuration file-এ যা নির্ধারিত থাকুক না কেন, কী loaded হয়েছে তার প্রকৃত তথ্য হলো ollama ps।

কোনো editor বা agent আপনার server পরিচালনা করলে server-কে দোষ দেওয়ার আগে client কী পাঠাচ্ছে তা পরীক্ষা করুন। নিজের Ollama server-এ coding agent নির্দেশ করা-এ request setting-গুলো কোথায় থাকে তা ব্যাখ্যা করা হয়েছে।

FAQ

Ollama 5 মিনিট পরে আমার model unload করে কেন?

5 মিনিট হলো default keep_alive, অর্থাৎ request শেষ হলে Ollama যে idle timer চালু করে। এই timer শেষ হলে server weights মুক্ত করে। তাই পরের request disk থেকে সেগুলো আবার load করে। আপনি যে বিরতি অনুভব করেন, সেটিই এই reload-এর সময়। একটি request-এর জন্য এটি বাড়াতে JSON body-তে "keep_alive": "30m" পাঠান। পুরো server-এর জন্য OLLAMA_KEEP_ALIVE environment variable ব্যবহার করুন।

Ollama model-কে স্থায়ীভাবে memory-তে loaded রাখব কীভাবে?

Negative value ব্যবহার করুন: request-এর ক্ষেত্রে "keep_alive": -1 অথবা server-এর ক্ষেত্রে OLLAMA_KEEP_ALIVE=-1। এরপর ollama ps-এ UNTIL column-এ Forever দেখা যাবে। এতে idle timer বন্ধ হয়, অন্য কোনো পরিবর্তন হয় না। অন্য একটি model-এর request এলে এবং memory কম থাকলে scheduler জায়গা তৈরি করতে এই model-টিও unload করতে পারে।

OLLAMA_KEEP_ALIVE উপেক্ষা করা হচ্ছে কেন?

আপনি variable-টি কোথায় set করেছেন তা পরীক্ষা করুন। systemctl show ollama --property=Environment চালান। Output-এ variable-টি না থাকলে server এটি পায়নি। কারণ আপনার shell-এ export করা variable systemd service-এ পৌঁছায় না। sudo systemctl edit ollama.service দিয়ে এটি set করুন। এরপর sudo systemctl daemon-reload এবং sudo systemctl restart ollama চালান। অন্য কারণ হতে পারে এমন কোনো client, যা request-এ নিজস্ব keep_alive পাঠায়। এটি server default-কে override করে।

Ollama restart না করে memory মুক্ত করব কীভাবে?

ollama stop qwen3:8b শুধু ওই model-টি সঙ্গে সঙ্গে unload করে। Server এবং অন্য সব loaded model চালু থাকে। API-এর মাধ্যমে prompt ছাড়া একটি request পাঠান এবং "keep_alive": 0 ব্যবহার করুন। Reply-তে "done_reason": "unload" ফিরে আসবে। ollama ps দিয়ে নিশ্চিত করুন। সেখানে model-টি আর তালিকাভুক্ত থাকার কথা নয়।