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 লিখুন অথবা Ctrl+D চাপুন। তৃতীয়টি একটি single prompt পাঠায়, উত্তর print করে এবং exit করে। কোনো session নয়, শুধু একটি উত্তর দরকার হলে script-এ এটাই ব্যবহার করতে হয়। Model name দ্রুত পরিবর্তিত হয়। তাই এখানে gemma4-কে একটি placeholder হিসেবে ধরুন। August 2026 অনুযায়ী এটি official Ollama documentation-এ ব্যবহৃত example। Library-এর যেকোনো tag একইভাবে কাজ করে।

প্রথম ollama run হ্যাং হয়ে গেছে বলে কেন মনে হয়

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

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

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

df -h /
watch -n5 df -h /

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

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

যে কেউ অনুরোধ করার আগেই model pull করুন

নতুন box-এ server install করার একই script দিয়ে model pull করুন:

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

আপনি যদি প্রথমবার server চালু করেন, VPS-এ Ollama install করার সম্পূর্ণ নির্দেশনা service এবং কারা এতে access করতে পারবে—দুটিই ব্যাখ্যা করে। এরপর terminal বন্ধ হলেও চলতে থাকবে এমন pull সেটআপ করা গুরুত্বপূর্ণ। কারণ 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 চালিয়েই নির্ভরযোগ্য path পাওয়া যায়। 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 বর্তমান রাখতে একই pull চালানোর জন্য একটি systemd timer বা weekly cron entry যোগ করুন। পরিবর্তিত tag আবার pull করলে নতুন layer download হয়। যেসব পুরোনো layer আর কোনো কিছুর দ্বারা ব্যবহৃত হয় না, সেগুলো রেখে দেওয়া হয় এবং server পরেরবার start হলে পরিষ্কার করা হয়।

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 করার আগে space খালি করুন। df যদি full disk দেখায়, কিন্তু model directory-তে du সেই ব্যবহারের হিসাব না মেলায়, তাহলে space অন্য কোথাও ব্যবহৃত হয়েছে। কিছু মুছে ফেলার আগে df এবং du-এর হিসাব কেন মেলে না তা পড়ে নিন।

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

এই গাইডের কোনো path-সহ অন্য কোনো গাইডের path অন্ধভাবে অনুসরণ না করে নিজের box-এ যাচাই করুন। 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-টি service যে account হিসেবে চলে, সেই account-এর home directory-এর অধীনে থাকে। getent passwd colon দিয়ে আলাদা করা field-এর মধ্যে ষষ্ঠ field-এ সেই home directory দেখায়। find একটি filesystem-এ blobs directory খোঁজে। Layer বাস্তবে এখানেই লেখা হয়। 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 থাকে। প্রতিটির নাম তার content-এর hash অনুযায়ী হয়। মোট আকারের প্রায় পুরোটাই এখানে থাকে। একাধিক tag-এর মধ্যে layer ভাগ করা যায়। তাই একই weights-এর ওপর তৈরি দুটি model ollama list-এ নিজ নিজ আকার দেখালেও disk-এ সেই স্থান একবারই ব্যবহৃত হয়। ফলে তালিকাভুক্ত আকারগুলোর যোগফল directory-এর জন্য du যে আকার দেখায়, তার চেয়ে বেশি হতে পারে।

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

OLLAMA_MODELS ব্যবহার করে models-কে data volume-এ সরান

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

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 করার আগের মতো একই models দেখানোর কথা। তালিকা খালি হলে 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 সক্রিয় আছে। সার্ভারে অন্য কোনো কিছু যদি ইতিমধ্যে default location প্রত্যাশা করে, bind mount তখন কার্যকর। তবে এখানে একটি সমস্যা আছে: copy করা file-গুলো root disk-এর mount point-এর নিচে এখনও থেকে যায়। mount সেগুলোকে আড়াল করে রাখে। তাই unmount করে file-গুলো সরানো না পর্যন্ত disk space ফেরত পাওয়া যায় না। পরবর্তী লগইনকারীকে বোঝানোর দিক থেকে environment variable ব্যবহার করাই সহজ।

কনটেইনারে মডেলগুলো আসলে যেখানে থাকে

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-এর ভেতরে server যে location-এ লেখে। তাই আগের section-এর path-গুলোতে du চালালে কিছু পাওয়া যায় না, কারণ সেখানে কিছুই নেই। প্রকৃত location এবং size দেখুন:

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

docker volume inspect থেকে Mountpoint field পড়ুন, তারপর ওই location-এর বিরুদ্ধে 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-এ ownership আবার ভিন্ন দেখায়: rootless Podman-এ Ollama চালানো-এ এই mapping ব্যাখ্যা করা হয়েছে।

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

ollama rm ব্যবহার করে মডেল সরান, rm দিয়ে নয়

ollama list
ollama rm gemma4
ollama list
df -h /

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

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

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

FAQ

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

ollama pull একটি model disk-এ download করে তারপর বন্ধ হয়। ollama run model-টি disk-এ আগে থেকেই আছে কি না পরীক্ষা করে, না থাকলে download করে, memory-তে load করে এবং interactive chat session শুরু করে। উভয় command একই 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 হতে পারে। Ollama শুধু terminal-এ output পাঠালে 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 সেট করা আছে কি না দেখতে systemctl cat ollama.service চালান। সেট করা না থাকলে store সেই account-এর home directory-এর অধীনে থাকে, যে account দিয়ে service চলে; getent passwd ollama সেটি print করে। sudo find / -xdev -type d -name blobs 2>/dev/null সরাসরি layer directory-এর অবস্থান দেখায়। 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-টির মালিকানা 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 মুছে ফেললে কি disk space মুক্ত হয়?

হাতে file মুছে ফেললে byte মুক্ত হয়, কিন্তু store-এর consistency নষ্ট হয়। একটি 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 করে না, সেগুলো মুছে যাবে।