تفاوت دستورات ollama pull و ollama run چیست؟

تفاوت ollama pull و ollama run

ollama pull مدل را دانلود کرده و متوقف می‌شود. ollama run مدل را تنها در صورتی که موجود نباشد دانلود می‌کند، سپس آن را در حافظه بارگذاری کرده و یک چت تعاملی باز می‌کند. فرآیند دانلود یکسان است و فایل‌ها در مسیر مشابهی ذخیره می‌شوند. تنها run است که پس از آن به کار خود ادامه می‌دهد.

همین یک تفاوت تعیین می‌کند که کدام دستور برای اسکریپت مناسب است و کدام یک برای استفاده در محیط خط فرمان.

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

خط اول مدل را دریافت کرده و خارج می‌شود، بنابراین در فرآیندهای provisioning و در یک unit فایل systemd ایمن است. دستور دوم یک نشست چت باز می‌کند؛ برای خروج از آن /bye را تایپ کنید یا کلیدهای Ctrl+D را فشار دهید. دستور سوم یک پرامپت واحد ارسال کرده، پاسخ را چاپ می‌کند و خارج می‌شود؛ این همان قالبی است که اسکریپت‌ها برای دریافت پاسخ (به‌جای باز کردن یک نشست) به آن نیاز دارند. نام مدل‌ها به‌سرعت تغییر می‌کنند، بنابراین gemma4 را در اینجا به‌عنوان یک جای‌نگهدار (placeholder) در نظر بگیرید: این مثالی است که مستندات رسمی Ollama تا اوت 2026 استفاده کرده است و هر تگ دیگری از کتابخانه نیز به همین صورت عمل می‌کند.

چرا اولین اجرای ollama به نظر می‌رسد که متوقف شده است

اولین اجرای run روی یک VPS تازه، ممکن است چندین دقیقه بدون هیچ خروجی باقی بماند. هیچ مشکلی وجود ندارد. اعلان چت (chat prompt) تا زمانی که مدل روی دیسک ذخیره و در حافظه بارگذاری نشود ظاهر نمی‌شود، بنابراین run پیش از آنکه چیزی برای نمایش داشته باشد، در حال انجام یک دانلود چند گیگابایتی است.

دو عامل این فرآیند را پنهان می‌کنند. Ollama نوار پیشرفت خود را فقط زمانی ترسیم می‌کند که خروجی آن یک ترمینال باشد، بنابراین یک run در داخل یک اسکریپت shell، یک cron job، یک مرحله CI یا یک ssh host ollama run ... ساده، در حین دانلود هیچ چیزی چاپ نمی‌کند. سپس، پس از دریافت بایت‌ها، فایل باید از دیسک به RAM خوانده شود تا اولین توکن تولید گردد؛ در یک VPS کوچک، این خواندن کند است. اگر سرور حافظه کافی برای مدل نداشته باشد، هسته سیستم‌عامل شروع به استفاده از swap می‌کند و زمان انتظار بسیار طولانی‌تر می‌شود.

به‌جای حدس زدن، وضعیت را از یک نشست (session) دوم مشاهده کنید:

df -h /
watch -n5 df -h /

کاهش پله‌ای فضای آزاد به این معنی است که دانلود همچنان در حال انجام است. اگر فضای آزاد ثابت بماند در حالی که دستور همچنان مشغول است، یعنی دانلود تمام شده و بارگذاری در حافظه آغاز شده است.

این همان دلیلی است که باید مدل‌ها را از قبل pull کنید. کسی که دستور ollama run را تایپ می‌کند، نباید منتظر دانلود بماند.

پیش از درخواست کاربران، مدل را دریافت کنید

روی یک سرور جدید، همان اسکریپتی را دریافت کنید که سرور را نصب می‌کند:

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

اگر برای اولین بار سرور را راه‌اندازی می‌کنید، راهنمای کامل نصب Ollama روی VPS سرویس مربوطه و نحوه دسترسی به آن را پوشش می‌دهد. پس از آن، آنچه ارزش تنظیم دارد، فرآیند دریافت (pull) است که مستقل از ترمینال شما اجرا شود؛ چرا که قطع شدن دانلود در میانه راه، باعث ناقص ماندن مخزن مدل‌ها می‌شود.

این کار را داخل tmux اجرا کنید یا آن را به عنوان یک unit از نوع one-shot به 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

هر دو دستور عمداً از طریق /bin/sh -c اجرا می‌شوند. دستور خام ExecStart= به مسیر مطلق (absolute path) نیاز دارد و از آنجا که نصب‌کننده همیشه فایل اجرایی را در یک دایرکتوری ثابت قرار نمی‌دهد، استفاده از command -v ollama روی سرور خودتان تنها راه مطمئن است. استفاده از shell باعث می‌شود به جای مسیری که از یک راهنما کپی شده، از PATH تعریف‌شده برای سرویس استفاده شود. اولین ExecStart نیز اهمیت دارد: After=ollama.service به این معنی است که unit سرور استارت شده، اما لزوماً به معنای آماده بودن آن نیست؛ بنابراین حلقه تا زمانی که ollama list پاسخ دهد، منتظر می‌ماند و سپس عملیات pull آغاز می‌شود.

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

لاگ (journal) باید نشان دهد که عملیات دریافت بدون خطا به پایان رسیده است و سپس ollama list باید مدل را نمایش دهد. برای به‌روز نگه داشتن یک تگ متغیر، یک systemd timer یا یک ورودی cron هفتگی اضافه کنید که همان دستور pull را اجرا کند. دریافت مجدد تگی که تغییر کرده است، لایه‌های جدید را دانلود می‌کند و لایه‌های قدیمی را بدون ارجاع باقی می‌گذارد؛ این لایه‌های بلااستفاده در نوبت بعدی استارت سرور پاکسازی می‌شوند.

وقفه در عملیات pull چه پیامدی دارد

هر لایه از یک مدل تحت هش محتوای خود ذخیره می‌شود. بنابراین، یک عملیات pull که دچار وقفه شده، به معنای هدر رفتن کار انجام‌شده نیست: اگر همان ollama pull را دوباره اجرا کنید، لایه‌هایی که قبلاً تکمیل شده‌اند شناسایی و از آن‌ها صرف‌نظر می‌شود، بنابراین دانلود از همان لایه‌ای که قطع شده بود ادامه می‌یابد.

یک اقدام می‌تواند این پیشرفت را از بین ببرد. هنگامی که سرور Ollama شروع به کار می‌کند، لایه‌های ذخیره‌شده‌ای را که هیچ manifest مدلی به آن‌ها ارجاع نمی‌دهد حذف می‌کند؛ لایه ناقصی که از یک pull ناموفق باقی مانده، دقیقاً در همین دسته قرار می‌گیرد. بنابراین، راه‌اندازی مجدد سرویس پیش از تلاش دوباره، بخشی را که قبلاً دانلود کرده‌اید پاک می‌کند. ابتدا pull را دوباره امتحان کنید و سپس سرویس را restart کنید. اگر واقعاً نیاز دارید که یک دانلود ناقص پس از restart باقی بماند، OLLAMA_NOPRUNE=1 را در محیط سرویس تنظیم کنید و سپس آن را حذف کنید، زیرا آن پاک‌سازی هنگام شروع به کار، مانع از انباشته شدن لایه‌های یتیم روی دیسک می‌شود.

اگر عملیات pull با خطای no space left on device متوقف شد، پیش از تلاش مجدد، فضای دیسک را آزاد کنید. اگر df پر بودن دیسک را گزارش می‌دهد و du در دایرکتوری مدل دلیل آن را نشان نمی‌دهد، فضا جای دیگری اشغال شده است و مطالعه دلایل اختلاف بین df و du پیش از حذف هر فایلی توصیه می‌شود.

Ollama مدل‌ها را در کجا روی یک VPS ذخیره می‌کند؟

به جای اعتماد به مسیرهای ذکر شده در راهنماها، از جمله همین راهنما، از سیستم خودتان پرس‌وجو کنید. محل ذخیره‌سازی بین نصب بسته‌ای (package install) و کانتینر متفاوت است و اگر کسی متغیر OLLAMA_MODELS را تنظیم کرده باشد، باز هم تغییر می‌کند.

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

دستور systemctl cat فایل unit را به همراه تمام drop-inها نمایش می‌دهد، بنابراین هر خط OLLAMA_MODELS که توسط شما تنظیم شده یا در image شما گنجانده شده باشد، در آنجا ظاهر می‌شود. در صورت عدم وجود چنین خطی، محل ذخیره‌سازی در دایرکتوری home حسابی قرار دارد که سرویس با آن اجرا می‌شود و getent passwd آن دایرکتوری home را در ششمین فیلد جدا شده با دو نقطه چاپ می‌کند. دستور find یک فایل‌سیستم را برای یافتن دایرکتوری blobs جستجو می‌کند، که در واقع محل نوشتن لایه‌ها است. اگر مدل‌ها ممکن است از قبل روی یک mount جداگانه باشند، -xdev را حذف کنید.

اکنون اندازه‌گیری کنید و اعداد مربوط به سیستم خود را بخوانید:

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

این محل ذخیره‌سازی دو بخش دارد. manifests به ازای هر تگ مدل، یک فایل کوچک نگه می‌دارد که لایه‌های تشکیل‌دهنده آن تگ را فهرست می‌کند. blobs خود لایه‌ها را نگه می‌دارد که هر کدام با هش محتویاتشان نام‌گذاری شده‌اند و تقریباً تمام حجم اشغال شده مربوط به این بخش است. از آنجا که لایه‌ها بین تگ‌ها به اشتراک گذاشته می‌شوند، دو مدل که بر اساس وزن‌های یکسانی ساخته شده‌اند، هر کدام حجم خود را در ollama list گزارش می‌دهند، در حالی که تنها یک بار آن فضا را روی دیسک اشغال می‌کنند؛ بنابراین مجموع اندازه‌های فهرست‌شده می‌تواند بیشتر از مقداری باشد که du برای آن دایرکتوری گزارش می‌دهد.

فایل‌های مدل، فایل‌سیستم root یک VPS کوچک را سریع‌تر از هر چیز دیگری که احتمالاً نصب می‌کنید پر می‌کنند و بزرگترین عامل تأثیرگذار بر حجم آن‌ها، فرمت وزن‌ها (weight format) است. انتخاب بین q4، q8 و fp16 به ازای هر مدل، صرفه‌جویی در حد گیگابایت به همراه دارد.

انتقال مدل‌ها به یک volume داده با استفاده از OLLAMA_MODELS

اگر برنامه دارای دیسک دوم یا volume داده بزرگ‌تری است، پیش از پر شدن فایل‌سیستم root، محل ذخیره‌سازی را منتقل کنید. ابتدا سرور را متوقف کنید تا فایلی که در حال نوشتن است، کپی نشود.

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 باز می‌کند تا unit بسته‌بندی‌شده دست‌نخورده باقی بماند و ارتقای بسته، تغییرات شما را بازنویسی نکند. این دو خط را اضافه کنید:

[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 باید مسیر جدید شما را چاپ کند و ollama list باید همان مدل‌هایی را نشان دهد که پیش از انتقال نمایش می‌داد. لیست خالی به این معنی است که سرور نمی‌تواند دایرکتوری جدید را بخواند. سرویس با کاربر ollama اجرا می‌شود، بنابراین آن کاربر به دسترسی خواندن و نوشتن در مقصد نیاز دارد که این وظیفه خط chown در بالا است. برای مشاهده خطاهای مجوز که مسیر جدید را نام می‌برند، journalctl -e -u ollama را بررسی کنید. تنها پس از اطمینان از صحت لیست، کپی قدیمی را حذف کنید، زیرا انتقال ناموفق به همراه حذف منبع به معنای دانلود مجدد همه موارد است.

گزینه دیگر، حفظ مسیر اصلی و mount کردن volume داده روی آن است:

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 فعال است. یک bind mount زمانی مفید است که سرویس دیگری روی سیستم از قبل انتظار محل پیش‌فرض را داشته باشد. این روش یک نکته منفی دارد: فایل‌هایی که کپی کرده‌اید همچنان زیر نقطه mount روی دیسک root باقی می‌مانند و توسط mount پنهان می‌شوند، بنابراین تا زمانی که unmount و حذف نشوند، فضا آزاد نمی‌شود. متغیر محیطی (environment variable) برای توضیح به شخصی که در آینده وارد سیستم می‌شود، گزینه ساده‌تری است.

محل نگهداری مدل‌ها در کانتینر

ایمیج رسمی، مدل‌ها را در هر مسیری که mount کرده باشید ذخیره می‌کند، نه در هیچ دایرکتوری میزبان (host) که متعلق به کاربر ollama باشد. دستور اجرای مستندشده به شرح زیر است:

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

عبارت ollama پیش از علامت دونقطه، یک Docker volume نام‌گذاری‌شده است و /root/.ollama مسیری است که سرور داخل کانتینر در آن می‌نویسد. بنابراین، اجرای du روی مسیرهای بخش قبل نتیجه‌ای در بر ندارد، زیرا فایلی در آنجا وجود ندارد. برای مشاهده مکان واقعی و حجم، دستور زیر را اجرا کنید:

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

فیلد Mountpoint را از docker volume inspect بخوانید و سپس دستور sudo du -sh را روی آن اجرا کنید. برای قرار دادن مدل‌ها روی یک volume داده، volume نام‌گذاری‌شده را با یک دایرکتوری میزبان (-v /mnt/data/ollama:/root/.ollama) جایگزین کرده و کانتینر را دوباره ایجاد کنید. کانتینر با دسترسی root می‌نویسد، بنابراین مالکیت آن دایرکتوری میزبان در نهایت به root می‌رسد. در حالت rootless Podman، شناسه‌ها (ids) به محدوده subuid کاربر شما نگاشت می‌شوند و مالکیت در میزبان متفاوت به نظر می‌رسد: اجرای Ollama تحت rootless Podman این نگاشت را پوشش می‌دهد.

یک هشدار در مورد پاک‌سازی: دستور docker volume prune تمام volumeهایی که هیچ کانتینری به آن‌ها ارجاع نمی‌دهد را حذف می‌کند. اگر کانتینر ollama را بدون volume آن حذف یا دوباره ایجاد کنید، دستور prune در آینده تمام مدل‌هایی که دانلود کرده‌اید را پاک می‌کند و راهی جز دانلود مجدد آن‌ها وجود نخواهد داشت. پیش از اجرای prune روی سروری که میزبان مدل‌هاست، نحوه پاک‌سازی فضای دیسک Docker در یک VPS را مطالعه کنید.

حذف یک مدل با ollama rm، نه با rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm مانیفست مربوط به آن تگ را حذف می‌کند و سپس لایه‌هایی که هیچ مانیفست دیگری به آن‌ها ارجاع نمی‌دهد را پاکسازی می‌کند. فضای دیسک بلافاصله پس از unlinked شدن فایل‌ها آزاد می‌شود، بنابراین df بلافاصله اعمال می‌شود. از آنجا که لایه‌ها به صورت اشتراکی استفاده می‌شوند، حذف یکی از دو تگ بسیار مشابه ممکن است فضای بسیار کمتری نسبت به حجمی که ollama list در کنار آن نمایش می‌دهد، آزاد کند. این رفتار صحیح است و به معنای شکست در عملیات حذف نیست.

حذف دستی فایل‌ها باعث ایجاد اختلال در این جفت‌سازی می‌شود. اگر یک blob را با rm حذف کنید، مانیفست همچنان آن را فهرست می‌کند، بنابراین ollama list همچنان مدل را نمایش می‌دهد و هرگونه تلاش برای استفاده از آن هنگام خواندن لایهٔ مفقودشده با خطا مواجه می‌شود. اگر مانیفستی را به صورت دستی حذف کنید، لایه‌های آن روی دیسک باقی می‌مانند بدون اینکه چیزی به آن‌ها اشاره کند؛ این یعنی فضایی اشغال شده که هیچ دستور Ollama آن را به شما گزارش نخواهد داد. اگر قبلاً این کار را انجام داده‌اید، اجرای ollama rm روی آن تگ، ورودی باقی‌مانده را پاک می‌کند و راه‌اندازی مجدد سرور، لایه‌هایی که به آن‌ها ارجاعی وجود ندارد را پاکسازی خواهد کرد.

یک تفاوت نهایی که باید به آن توجه کرد، زیرا این دو مورد دائماً با هم اشتباه گرفته می‌شوند: ollama rm مربوط به فضای دیسک است. ollama stop gemma4 مدل را از حافظه (RAM) تخلیه می‌کند و هیچ فضایی از دیسک را آزاد نمی‌کند. اینکه یک مدل پس از اتمام دانلود چه مدت در RAM باقی می‌ماند، یک تنظیم جداگانه است و نگه داشتن مدل در حافظه به جای بارگذاری مجدد آن در هر درخواست به آن می‌پردازد.

FAQ

تفاوت بین ollama pull و ollama run چیست؟

ollama pull مدل را روی دیسک دانلود کرده و خارج می‌شود. ollama run بررسی می‌کند که آیا مدل از قبل روی دیسک موجود است یا خیر؛ اگر موجود نباشد آن را دانلود کرده، در حافظه بارگذاری می‌کند و سپس یک نشست چت تعاملی باز می‌کند. هر دو دستور فایل‌های یکسانی را در دایرکتوری یکسانی می‌نویسند. از pull در فرآیندهای آماده‌سازی (provisioning) و اسکریپت‌ها استفاده کنید و از run زمانی که کاربر پشت کیبورد است استفاده نمایید. ollama run <model> "your prompt" یک پرامپت ارسال کرده و خارج می‌شود که در واقع فرم قابل اسکریپت‌نویسی run است.

چرا اولین اجرای ollama run به نظر می‌رسد که متوقف (hang) شده است؟

در حال دانلود است. پرامپت چت تا زمانی که مدل روی دیسک نباشد و در حافظه بارگذاری نشود ظاهر نمی‌شود، و حجم مدل چندین گیگابایت است. Ollama نوار پیشرفت خود را فقط زمانی رسم می‌کند که خروجی یک ترمینال باشد، بنابراین run در داخل یک اسکریپت، یک cron job یا یک ssh host ollama run ... در حین کار هیچ چیزی نشان نمی‌دهد. یک نشست دوم باز کنید و watch -n5 df -h / را اجرا کنید: کاهش فضای آزاد به صورت مرحله‌ای به این معنی است که دانلود در حال انجام است. مدل را از قبل pull کنید تا زمان انتظار از بین برود.

Ollama مدل‌ها را کجا ذخیره می‌کند؟

محل ذخیره‌سازی به نوع نصب بستگی دارد، بنابراین به جای فرض کردن، آن را چاپ کنید. systemctl cat ollama.service را اجرا کنید تا ببینید آیا OLLAMA_MODELS در unit یا یک drop-in تنظیم شده است یا خیر. اگر تنظیم نشده باشد، محل ذخیره در دایرکتوری home حسابی است که سرویس با آن اجرا می‌شود، که getent passwd ollama آن را چاپ می‌کند. sudo find / -xdev -type d -name blobs 2>/dev/null دایرکتوری لایه‌ها را مستقیماً پیدا می‌کند. برای image کانتینر، محل ذخیره در داخل volume متصل‌شده (mounted) است و docker volume inspect ollama مسیر Mountpoint میزبان آن را چاپ می‌کند.

چگونه مدل‌های Ollama را به دیسک دیگری منتقل کنم؟

سرویس را متوقف کنید، محل ذخیره را با rsync -a به مکان جدید کپی کنید، دسترسی دایرکتوری را با sudo chown -R ollama:ollama <directory> به حساب کاربری سرویس بدهید، سپس sudo systemctl edit ollama.service را اجرا کرده و Environment="OLLAMA_MODELS=<directory>" را زیر یک خط [Service] اضافه کنید. با sudo systemctl daemon-reload تنظیمات را بارگذاری مجدد کرده و سرویس را restart کنید. با systemctl show ollama --property=Environment و ollama list تأیید کنید. لیست خالی تقریباً همیشه به این معنی است که کاربر ollama نمی‌تواند دایرکتوری جدید را بخواند؛ journalctl -e -u ollama مسیر را مشخص خواهد کرد.

آیا حذف دستی فایل‌های مدل، فضا را آزاد می‌کند؟

حذف دستی فایل‌ها بایت‌ها را آزاد می‌کند اما باعث ناسازگاری در محل ذخیره می‌شود. اگر یک blob را حذف کنید، manifest همچنان آن مدل را لیست می‌کند، بنابراین در ollama list ظاهر می‌شود و هنگام استفاده با خطا مواجه می‌گردد. اگر یک manifest را حذف کنید، لایه‌های آن روی دیسک باقی می‌مانند در حالی که هیچ چیزی به آن‌ها ارجاع نمی‌دهد. از ollama rm <model> استفاده کنید که manifest و سپس لایه‌هایی که هیچ مدل دیگری به آن‌ها نیاز ندارد را حذف می‌کند. اگر فایل‌ها قبلاً به صورت دستی حذف شده‌اند، ollama rm را روی تگ اجرا کنید تا ورودی پاک شود، سپس سرور را restart کنید تا لایه‌هایی که هیچ manifest به آن‌ها ارجاع نمی‌دهد، حذف شوند.