Ollama model memory-তে loaded রাখার উপায়

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

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

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

keep_alive সেট করার দুটি জায়গা আছে: individual request-এ অথবা server default হিসেবে। Server default-কে restart-এর পরও কার্যকর রাখতে systemd drop-in ব্যবহার করতে হয়। এই 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 model unload করার স্বল্প সময়ের window-তে এটি Stopping... দেখায়।

release পরিবর্তনের কারণে column set বদলেছে। তাই script-এ field গোনার পরিবর্তে header পড়ুন। automation-এর জন্য 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-তে চলছে।

আসল reload-এর খরচ

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

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 অনেক বেশি থাকে। এটিকে seconds হিসেবে পড়তে 1000000000 দিয়ে ভাগ করুন। দ্বিতীয় call-টি model resident থাকা অবস্থায় চলে এবং অনেক কম সংখ্যা দেখায়। এই দুটি মানের পার্থক্যই timer শেষ হওয়ার পরে প্রতিটি user-কে একবার দিতে হয়। keep_alive পরিবর্তন করার মূল কারণ এটিই। ওই বিরতির আগে ও পরে generation speed জানতে নিজের box-এ প্রতি সেকেন্ডে token মাপার পদ্ধতি দেখুন।

একটি অনুরোধে Ollama model memory-তে loaded রাখুন

অনুরোধের সঙ্গে 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-এ কনফিগার করা যেকোনো মানের ওপর সেটিই কার্যকর হয়।

কোনো output তৈরি না করেও model load করতে পারেন। শুধু model name পাঠান। server model-টি load করে এবং "done": true সহ একটি empty response ফেরত দেয়।

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

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

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

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

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

মূল বিষয় হলো, variable-টি কোন environment-এ থাকতে হবে। আপনার SSH session-এ export OLLAMA_KEEP_ALIVE=30m চালালে কোনো ফল হবে না। কারণ packaged install নিজস্ব user ও নিজস্ব environment ব্যবহার করে systemd service হিসেবে সার্ভার চালায়। আপনার 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 নিয়ে চলবে, তা দেখায়। ওই লাইনে OLLAMA_KEEP_ALIVE=30m না থাকলে drop-in কার্যকর হয়নি। এর কারণ প্রায় সবসময় অনুপস্থিত [Service] header অথবা marker-এর নিচে লেখা line। restart করলে সব loaded model সরিয়ে ফেলা হয়। তাই পরের request-এ model cold load হবে। উপরের preload call ব্যবহার করে আগে model load করে নিন।

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

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

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

free -h

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

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

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

এখানে দুটি খরচ সহজেই চোখ এড়িয়ে যায়। বেশি context length একটি বড় KV cache সংরক্ষণ করে। KV cache হলো key value cache, অর্থাৎ model generate করার সময় প্রতি token-এর জন্য ধরে রাখা attention state। এই cache resident size-এর অংশ। OLLAMA_NUM_PARALLEL-এর মান 1-এর বেশি হলে প্রতিটি parallel slot-এর জন্য একবার করে ওই cache সংরক্ষিত হয়। একটি model থেকে একাধিক ব্যক্তিকে service দেওয়ার পরিকল্পনা থাকলে শুধু 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 load করা নেই, তার ক্ষেত্রে couldn't find model "qwen3:8b" to stop ফেরত আসে। API পদ্ধতিতে prompt ছাড়া একটি request পাঠাতে হয় এবং 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 বন্ধ করে দেয়।

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

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

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

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

sudo journalctl -u ollama -f

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

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

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

ollama --version
ollama serve --help

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

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

FAQ

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

পাঁচ মিনিট হলো ডিফল্ট 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 requested হলে এবং memory কম থাকলে scheduler জায়গা তৈরি করতে এই model-টিকেও unload করতে পারে।

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

কোথায় এটি সেট করেছেন তা পরীক্ষা করুন। systemctl show ollama --property=Environment চালান। output-এ variable না থাকলে server এটি পায়নি। কারণ আপনার shell-এ exported variable systemd service-এ পৌঁছায় না। sudo systemctl edit ollama.service দিয়ে এটি সেট করুন। এরপর 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 ছাড়া এবং "keep_alive": 0-সহ একটি request পাঠান। উত্তরে "done_reason": "unload" ফিরে আসবে। ollama ps দিয়ে নিশ্চিত করুন। এতে model-টি আর তালিকাভুক্ত থাকার কথা নয়।