ollama pull বনাম run: model কোথায় থাকে ও সরাবেন কীভাবে

ollama pull বনাম ollama run

ollama pull একটি model download করে এবং বন্ধ হয়ে যায়। ollama run model অনুপস্থিত থাকলেই শুধু সেটি download করে, তারপর memory-তে load করে এবং একটি interactive chat চালু করে। Download একইভাবে হয় এবং file একই জায়গায় সংরক্ষিত হয়। এরপর কেবল run চলতে থাকে।

এই একটি পার্থক্যই নির্ধারণ করে কোন command script-এ এবং কোনটি keyboard-এ ব্যবহার করা হবে।

ollama pull gemma4
ollama run gemma4
ollama run gemma4 "Reply with one word: ready"

প্রথম line-টি model fetch করে এবং exit করে, তাই provisioning ও systemd unit-এ এটি নিরাপদ। দ্বিতীয়টি একটি chat session চালু করে; বের হতে /bye type করুন অথবা Ctrl+D চাপুন। তৃতীয়টি একটি একক prompt পাঠায়, উত্তর print করে এবং exit করে। Session-এর পরিবর্তে উত্তর প্রয়োজন হলে script-এর জন্য এটিই উপযুক্ত form। এই তৃতীয় form-এও উত্তরের দৈর্ঘ্য সম্পূর্ণভাবে model-এর ওপর নির্ভর করে। তাই এক line-এর প্রশ্নের উত্তর 3টি paragraph-এ আসতে পারে। num_predict দিয়ে উত্তরের সর্বোচ্চ সীমা নির্ধারণ করলেই scripted run এমন আকারের মধ্যে থাকে, যা caller বাস্তবে ব্যবহার করতে পারে। Model name দ্রুত পরিবর্তিত হয়, তাই এখানে gemma4-কে একটি placeholder হিসেবে ধরুন: August 2026 অনুযায়ী এটি official Ollama documentation-এ ব্যবহৃত example, এবং library-এর যেকোনো tag একইভাবে কাজ করে। ইতিমধ্যে real server অনুযায়ী memory নির্ধারণ করা কোনো model ব্যবহার করতে চাইলে, VPS-এ Nemotron 3.5 Lightning চালানো অংশে pull করার exact tag এবং প্রয়োজনীয় memory দেওয়া আছে।

প্রথম ollama run কমান্ডটি কেন আটকে গেছে বলে মনে হয়

নতুন VPS-এ প্রথমবার run চালালে কয়েক মিনিট কোনো output ছাড়াই অপেক্ষা করতে পারে। কিছু নষ্ট হয়নি। Model disk-এ সংরক্ষিত এবং memory-তে loaded না হওয়া পর্যন্ত chat prompt দেখা যায় না। তাই run আপনাকে দেখানোর মতো কিছু পাওয়ার আগে কয়েক gigabyte data download করছে।

দুটি কারণে এই কাজটি চোখে পড়ে না। Ollama-এর progress bar শুধু তখনই দেখায়, যখন তার output একটি terminal-এ যাচ্ছে। তাই shell script, cron job, CI step বা সাধারণ ssh host ollama run ...-এর ভেতর চালানো run download চলাকালে কিছুই print করে না। এরপর data disk-এ লেখা হলেও প্রথম token তৈরি হওয়ার আগে file-টি disk থেকে RAM-এ পড়তে হয়। ছোট VPS-এ এই read ধীর হতে পারে। Model-এর জন্য পর্যাপ্ত memory না থাকলে kernel swapping শুরু করে এবং অপেক্ষার সময় অনেক বেড়ে যায়।

অনুমান না করে দ্বিতীয় session থেকে এটি monitor করুন:

df -h /
watch -n5 df -h /

Free space ধাপে ধাপে কমলে download এখনও চলছে। Command busy থাকা অবস্থায় free space কমা বন্ধ হলে download শেষ হয়েছে এবং memory-তে load শুরু হয়েছে।

এ কারণেই আগে থেকেই pull করা উচিত। যে ব্যক্তি ollama run টাইপ করেন, download-এর খরচ বহন করার দায়িত্ব তার হওয়া উচিত নয়।

অনুরোধ আসার আগেই মডেল pull করুন

ব্যক্তি নয়—এমন যেকোনো কিছুর ক্ষেত্রেও একই কথা প্রযোজ্য: আপনার Ollama endpoint-এ নির্দেশিত coding agent সাধারণত বহু-GB download শেষ হওয়ার জন্য অপেক্ষা না করে প্রথম অনুরোধেই ব্যর্থ হবে। নতুন box-এ server install করা একই script-এ model pull-ও যোগ করুন:

curl -fsSL https://ollama.com/install.sh | sh
ollama pull gemma4

আপনি যদি প্রথমবার server চালু করেন, VPS-এ সম্পূর্ণ Ollama install-এ service এবং কারা এতে পৌঁছাতে পারবে—দুটিই ব্যাখ্যা করা আছে। এরপর যে কাজটি করা উচিত, তা হলো terminal বন্ধ হলেও চলতে থাকে এমন একটি pull setup করা। কারণ download মাঝপথে বন্ধ হয়ে গেলে model store আংশিকভাবে পূর্ণ হয়ে যায়।

এটি tmux-এর ভেতরে চালান, অথবা boot-এর সময় চলা one-shot unit হিসেবে systemd-কে দিন। /etc/systemd/system/ollama-pull.service লিখুন:

[Unit]
Description=Pre-pull Ollama models
Wants=ollama.service network-online.target
After=ollama.service network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'until ollama list >/dev/null 2>&1; do sleep 2; done'
ExecStart=/bin/sh -c 'ollama pull gemma4'

[Install]
WantedBy=multi-user.target

দুটি command-ই ইচ্ছাকৃতভাবে /bin/sh -c-এর মাধ্যমে চলে। সরাসরি ExecStart= ব্যবহার করলে absolute path প্রয়োজন হয়। Installer সব সময় binary একই directory-তে রাখে না। তাই নিজের box-এ command -v ollama-এর ফলাফলই একমাত্র নির্ভরযোগ্য উত্তর। shell-এর মাধ্যমে চালালে guide থেকে কপি করা path-এর বদলে service PATH ব্যবহৃত হয়। প্রথম ExecStart-ও গুরুত্বপূর্ণ: After=ollama.service মানে server unit শুরু হয়েছে, server ready—এমন নয়। তাই pull শুরু করার আগে loop অপেক্ষা করে, যতক্ষণ না ollama list উত্তর দেয়।

sudo systemctl daemon-reload
sudo systemctl enable --now ollama-pull.service
journalctl -u ollama-pull.service

Journal-এ কোনো error ছাড়া pull শেষ হওয়ার বার্তা দেখা উচিত। এরপর ollama list-এ model দেখা যাবে। পরিবর্তনশীল tag সর্বশেষ রাখতে systemd timer বা weekly cron entry যোগ করুন, যা একই pull চালাবে। পরিবর্তিত tag পুনরায় pull করলে নতুন layer download হয়। পুরোনো layer-গুলোর দিকে আর কোনো reference থাকে না। Server পরেরবার শুরু হলে সেগুলো পরিষ্কার হয়।

Pull বাধাগ্রস্ত হলে কী ঘটে

একটি model-এর প্রতিটি layer তার নিজস্ব content-এর hash-এর অধীনে সংরক্ষিত হয়। তাই বাধাগ্রস্ত pull করা কাজ নষ্ট করে না: একই ollama pull আবার চালান। ইতিমধ্যে সম্পন্ন layer-গুলো শনাক্ত করে বাদ দেওয়া হবে। ফলে download যে layer-এ থেমেছিল, সেখান থেকেই আবার চলবে।

একটি কাজ এই অগ্রগতি নষ্ট করে। Ollama server চালু হলে এমন stored layer সরিয়ে দেয়, যেগুলো কোনো model manifest-এ উল্লেখ নেই। বন্ধ হয়ে যাওয়া pull-এর ফেলে যাওয়া partial layer ঠিক এমনই একটি layer। তাই retry করার আগে service restart করলে ইতিমধ্যে download করা অংশটি মুছে যাবে। আগে pull retry করুন, পরে restart করুন। কোনো partial download-কে সত্যিই restart-এর পরেও রাখতে হলে service environment-এ OLLAMA_NOPRUNE=1 সেট করুন। পরে এটি সরিয়ে দিন, কারণ startup cleanup-ই orphaned layer disk-এ জমতে বাধা দেয়।

pull no space left on device নিয়ে বন্ধ হয়ে গেলে retry করার আগে disk space খালি করুন। df যদি full disk দেখায়, কিন্তু model directory-তে du সেই ব্যবহারের ব্যাখ্যা না দেয়, তাহলে space অন্য কোথাও ব্যবহৃত হয়েছে। কিছু delete করার আগে df এবং du-এর ফল কেন মেলে না পড়ে নিন।

Ollama VPS-এ মডেল কোথায় সংরক্ষণ করে?

এই নির্দেশিকাসহ যেকোনো গাইডে দেওয়া path সরাসরি বিশ্বাস না করে নিজের server-কে জিজ্ঞেস করুন। Package install এবং container-এর ক্ষেত্রে location ভিন্ন হয়। কেউ OLLAMA_MODELS সেট করলে location আবার পরিবর্তিত হয়।

systemctl cat ollama.service
getent passwd ollama
sudo find / -xdev -type d -name blobs 2>/dev/null

systemctl cat প্রতিটি drop-in-সহ সম্পূর্ণ unit file দেখায়। তাই আপনি সেট করা বা image-এর মধ্যে আগে থেকেই থাকা OLLAMA_MODELS line সেখানে দেখা যাবে। এমন কোনো line না থাকলে store যে account-এর অধীনে service চলে, তার home directory-র মধ্যে থাকে। getent passwd colon দিয়ে আলাদা করা ষষ্ঠ field-এ সেই home directory দেখায়। find একটি filesystem-এ blobs directory খোঁজে। Layer-গুলো বাস্তবে এই directory-তেই লেখা হয়। Model অন্য mount-এ আগে থেকেই থাকতে পারে মনে হলে -xdev বাদ দিন।

এখন মাপ নিন এবং নিজের ফলাফল দেখুন:

ollama list
df -h /
sudo du -sh /the/directory/you/found
sudo du -h -d1 /the/directory/you/found

Store-এর দুটি অংশ রয়েছে। manifests-এ প্রতিটি model tag-এর জন্য একটি ছোট file থাকে। সেই file-এ tag-টি কোন layer দিয়ে তৈরি, তা তালিকাভুক্ত থাকে। blobs-এ layer-গুলো থাকে। প্রতিটি layer-এর নাম তার content-এর hash অনুযায়ী নির্ধারিত হয়, এবং মোট size-এর প্রায় পুরোটাই এখানে থাকে। একাধিক tag-এর মধ্যে layer share করা হয়। তাই একই weights-এর ওপর তৈরি দুটি model ollama list-এ আলাদা আলাদা size দেখাতে পারে, যদিও disk-এ ওই space একবারই ব্যবহৃত হয়। ফলে তালিকাভুক্ত size যোগ করলে directory-র জন্য du যে size দেখায়, তার চেয়ে বেশি হতে পারে।

আপনি সম্ভবত যে অন্য যেকোনো software install করবেন, তার তুলনায় model file একটি ছোট VPS-এর root filesystem অনেক দ্রুত পূর্ণ করে। Model-এর size নিয়ন্ত্রণে সবচেয়ে বড় প্রভাব ফেলে weight format। q4, q8 এবং fp16-এর মধ্যে নির্বাচন করলে প্রতি model-এ কয়েক gigabyte সাশ্রয় হতে পারে।

OLLAMA_MODELS ব্যবহার করে মডেলগুলো একটি data volume-এ সরান

পরিকল্পনায় যদি দ্বিতীয় disk বা বড় data volume থাকে, root filesystem পূর্ণ হওয়ার আগে model store সরিয়ে নিন। প্রথমে server বন্ধ করুন, যাতে তখনও লেখা হচ্ছে এমন কোনো file কপি না হয়।

sudo systemctl stop ollama
sudo mkdir -p /mnt/data/ollama-models
sudo rsync -a /the/directory/you/found/ /mnt/data/ollama-models/
sudo chown -R ollama:ollama /mnt/data/ollama-models
sudo systemctl edit ollama.service

systemctl edit একটি drop-in file-এর জন্য editor খোলে। এতে packaged unit অপরিবর্তিত থাকে এবং package upgrade আপনার পরিবর্তন overwrite করতে পারে না। এই দুটি line যোগ করুন:

[Service]
Environment="OLLAMA_MODELS=/mnt/data/ollama-models"

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

systemctl show-এ আপনার নতুন path দেখানো উচিত, এবং ollama list-এ move করার আগের মতো একই model দেখানো উচিত। তালিকা খালি হলে server নতুন directory পড়তে পারছে না। Service-টি ollama user হিসেবে চলে। তাই ওই user-এর destination-এ read এবং write access প্রয়োজন। উপরের chown line-এর কাজ এটিই। নতুন path-সংক্রান্ত permission error আছে কি না দেখতে journalctl -e -u ollama পরীক্ষা করুন। তালিকা সঠিক হওয়ার পরেই পুরোনো copy মুছুন। কারণ move ব্যর্থ হওয়ার পর source মুছে ফেললে সবকিছু আবার download করতে হবে।

অন্য বিকল্পে original path অপরিবর্তিত থাকে এবং data volume-টি সেই path-এর ওপর mount করা হয়:

echo '/mnt/data/ollama-models /the/directory/you/found none bind 0 0' | sudo tee -a /etc/fstab
sudo mount -a
findmnt /the/directory/you/found
df -h /

findmnt-এ mount দেখালে বোঝা যায় bind সক্রিয় আছে। Server-এ অন্য কোনো কিছু default location প্রত্যাশা করলে bind mount উপকারী। তবে এখানে একটি সমস্যা আছে: কপি করে সরিয়ে নেওয়া file-গুলো root disk-এর mount point-এর নিচে থেকেই যায়, কিন্তু mount সেগুলো আড়াল করে রাখে। তাই unmount করে file-গুলো মুছে না ফেলা পর্যন্ত disk space ফেরত পাওয়া যায় না। পরেরবার যে ব্যক্তি লগ ইন করবেন, তাঁকে বোঝানোর জন্য environment variable-ই সহজ বিকল্প।

এগুলোর পরিবর্তে container-এ অবস্থান

Official image মডেলগুলো কোনো ollama user-এর মালিকানাধীন host directory-তে নয়, আপনি যে location mount করেন সেখানে সংরক্ষণ করে। নথিভুক্ত run command হলো:

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Colon-এর আগের ollama একটি named Docker volume, আর /root/.ollama হলো container-এর ভেতরের সেই location যেখানে server লিখে। তাই আগের section-এর path-গুলোর বিরুদ্ধে du চালালে কিছু পাওয়া যায় না, কারণ সেখানে কোনো ফাইল নেই। প্রকৃত location এবং size দেখুন:

docker volume inspect ollama
docker system df -v
docker exec -it ollama ollama list

docker volume inspect থেকে Mountpoint field পড়ুন, তারপর সেটির বিরুদ্ধে sudo du -sh চালান। মডেলগুলো data volume-এ রাখতে named volume-এর বদলে একটি host directory (-v /mnt/data/ollama:/root/.ollama) ব্যবহার করে container পুনরায় তৈরি করুন। Container root হিসেবে লেখে, তাই host directory-টির মালিকানা root-এর হয়। Rootless Podman-এ ID-গুলো আপনার user-এর subuid range-এ map হয়। তাই host-এ মালিকানা আবার ভিন্ন দেখায়: rootless Podman-এর অধীনে Ollama চালানো-তে এই mapping ব্যাখ্যা করা হয়েছে।

Cleanup সম্পর্কে একটি সতর্কতা আছে। docker volume prune এমন সব volume সরিয়ে দেয়, যেগুলো কোনো container ব্যবহার করছে না। Volume ছাড়া ollama container সরিয়ে ফেললে বা পুনরায় তৈরি করলে, পরবর্তী prune আপনার download করা সব মডেল মুছে দিতে পারে। সেগুলো আবার download করা ছাড়া ফেরত পাওয়ার কোনো উপায় থাকবে না। Models থাকা কোনো box-এ prune চালানোর আগে VPS-এ Docker disk usage কীভাবে prune করবেন পড়ুন।

ollama rm ব্যবহার করে model সরান, rm ব্যবহার করে নয়

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm ওই tag-এর manifest মুছে দেয়, তারপর যেসব layer আর কোনো অবশিষ্ট manifest উল্লেখ করে না, সেগুলো মুছে দেয়। ওই file-গুলো unlink হওয়ার সঙ্গে সঙ্গে disk space ফিরে আসে, তাই df সঙ্গে সঙ্গেই কার্যকর হয়। Layer শেয়ার করা হয় বলে, কাছাকাছি সম্পর্কিত দুটি tag-এর মধ্যে একটি সরালে ollama list-এর পাশে দেখানো size-এর তুলনায় অনেক কম space খালি হতে পারে। এটি সঠিক আচরণ; delete ব্যর্থ হয়নি।

হাতে file মুছে ফেললে এই সম্পর্ক নষ্ট হয়। rm দিয়ে blob সরালে manifest-এ সেটি থেকে যায়। ফলে ollama list model-টি দেখাতেই থাকে, কিন্তু missing layer পড়ার সময় সেটি ব্যবহার করার প্রতিটি চেষ্টা ব্যর্থ হয়। হাতে manifest সরালে তার layer-গুলো disk-এ থেকে যায়, কিন্তু সেগুলোর দিকে নির্দেশ করার মতো কিছু থাকে না। এতে space আটকে থাকে, যা কোনো Ollama command আপনাকে জানাবে না। আপনি যদি ইতিমধ্যে এমন করে থাকেন, tag-এ ollama rm চালালে অবশিষ্ট entry সরে যাবে। এরপর server restart করলে কোনো কিছুর দ্বারা উল্লেখ না করা layer-গুলো সরে যাবে।

শেষে একটি পার্থক্য মনে রাখুন, কারণ দুটি বিষয় প্রায়ই গুলিয়ে ফেলা হয়। ollama rm disk space নিয়ে কাজ করে। ollama stop gemma4 memory থেকে model unload করে, কিন্তু disk space একটুও খালি করে না। Download শেষ হওয়ার পরে model কতক্ষণ RAM-এ resident থাকবে, সেটি আলাদা setting। প্রতিটি request-এ পুনরায় load না করে model loaded রাখা বিষয়টি সেখানে ব্যাখ্যা করা হয়েছে।

FAQ

ollama pull এবং ollama run-এর মধ্যে পার্থক্য কী?

ollama pull একটি model disk-এ download করে এবং বন্ধ হয়ে যায়। ollama run modelটি disk-এ আগে থেকেই আছে কি না পরীক্ষা করে; না থাকলে download করে, memory-তে load করে এবং interactive chat session খোলে। দুটিই একই directory-তে একই file লেখে। Provisioning ও script-এ pull ব্যবহার করুন, আর কেউ keyboard-এ কাজ করার সময় run ব্যবহার করুন। ollama run <model> "your prompt" একটি prompt পাঠিয়ে বন্ধ হয়ে যায়; এটি run-এর script-এ ব্যবহারের উপযোগী রূপ।

আমার প্রথম ollama run কেন আটকে আছে বলে মনে হয়?

এটি download করছে। Model disk-এ থাকা এবং memory-তে load হওয়ার আগে chat prompt দেখা যায় না, আর একটি model-এর আকার কয়েক gigabyte হতে পারে। Output terminal-এ গেলে তবেই Ollama progress bar দেখায়। তাই কোনো script, cron job বা ssh host ollama run ...-এর ভিতরে run চললে কাজ চলাকালে কিছুই দেখা যায় না। দ্বিতীয় session খুলে watch -n5 df -h / চালান। Free space ধাপে ধাপে কমলে বুঝবেন download চলছে। আগে থেকেই model pull করলে এই অপেক্ষা থাকবে না।

Ollama তার model কোথায় সংরক্ষণ করে?

Location installation-এর ওপর নির্ভর করে। তাই অনুমান না করে location print করুন। Unit বা drop-in-এ OLLAMA_MODELS set আছে কি না দেখতে systemctl cat ollama.service চালান। এটি set না থাকলে store থাকে service যে account হিসেবে চলে তার home directory-র নিচে। getent passwd ollama সেই directory print করে। Layer directory সরাসরি খুঁজে পেতে sudo find / -xdev -type d -name blobs 2>/dev/null ব্যবহার করুন। Container image-এর ক্ষেত্রে store mounted volume-এর ভিতরে থাকে, আর docker volume inspect ollama তার host Mountpoint print করে।

Ollama model অন্য disk-এ কীভাবে সরাব?

Service বন্ধ করুন। rsync -a ব্যবহার করে store নতুন location-এ copy করুন। sudo chown -R ollama:ollama <directory> দিয়ে directory-টির ownership service account-কে দিন। এরপর sudo systemctl edit ollama.service চালিয়ে একটি [Service] line-এর নিচে Environment="OLLAMA_MODELS=<directory>" যোগ করুন। sudo systemctl daemon-reload দিয়ে reload করে service restart করুন। systemctl show ollama --property=Environment এবং ollama list দিয়ে নিশ্চিত করুন। List খালি থাকলে প্রায় সবসময় এর অর্থ ollama user নতুন directory পড়তে পারছে না। journalctl -e -u ollama pathটি দেখাবে।

Model file মুছে দিলে কি space খালি হয়?

হাতে file মুছে দিলে byte খালি হয়, কিন্তু store অসামঞ্জস্যপূর্ণ থেকে যায়। কোনো blob মুছে ফেললে manifest-এ modelটির তালিকা থেকেই যায়। ফলে এটি ollama list-এ দেখা যায় এবং ব্যবহার করার সময় ব্যর্থ হয়। কোনো manifest মুছে ফেললে তার layer disk-এ থেকে যায়, কিন্তু সেগুলোর দিকে আর কোনো reference থাকে না। ollama rm <model> ব্যবহার করুন। এটি manifest মুছে দেয় এবং অন্য কোনো model-এর প্রয়োজন নেই এমন layer-ও মুছে দেয়। ইতিমধ্যে হাতে file মুছে ফেলা হয়ে থাকলে tag-এ ollama rm চালিয়ে entry সরান। এরপর server restart করুন। এতে কোনো manifest যে layer reference করে না, সেগুলো মুছে যাবে।