تفاوت دستورات 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 را فشار دهید. دستور سوم یک پرامپت واحد ارسال کرده، پاسخ را چاپ می‌کند و خارج می‌شود؛ این همان قالبی است که اسکریپت در زمان نیاز به پاسخ (به‌جای نشست تعاملی) به آن احتیاج دارد. این فرم سوم همچنان طول پاسخ را کاملاً به مدل واگذار می‌کند، بنابراین یک پرسش تک‌خطی ممکن است به صورت سه پاراگراف بازگردد؛ از این رو محدود کردن پاسخ با num_predict همان چیزی است که باعث می‌شود یک run اسکریپت‌شده، در اندازه‌ای باقی بماند که فراخواننده بتواند از آن استفاده کند. نام مدل‌ها به‌سرعت تغییر می‌کنند، بنابراین gemma4 را در اینجا به عنوان یک جای‌نگهدار در نظر بگیرید: این مثالی است که مستندات رسمی Ollama تا اوت 2026 استفاده می‌کند و هر تگی از کتابخانه به همین صورت عمل می‌کند. اگر ترجیح می‌دهید مدلی را جایگزین کنید که قبلاً توسط شخصی برای یک سرور واقعی اندازه‌گیری شده است، اجرای Nemotron 3.5 Lightning روی یک VPS تگ دقیق برای pull کردن و میزان حافظه مورد نیاز آن را ارائه می‌دهد.

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

یک run اولیه روی یک VPS تازه، ممکن است چندین دقیقه بدون هیچ خروجی باقی بماند. هیچ مشکلی وجود ندارد. اعلان چت (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 را تایپ می‌کند، نباید منتظر دانلود بماند.

پیش از آنکه کسی درخواستی ارسال کند، مدل را Pull کنید

همین قاعده برای هر چیزی که یک کاربر انسانی نیست صدق می‌کند: یک عامل برنامه‌نویسی که به endpoint مدل Ollama شما متصل شده است، معمولاً به‌جای انتظار برای دانلود چندین گیگابایتی، در همان اولین درخواست منصرف می‌شود. روی یک سرور جدید، همان اسکریپتی را اجرا کنید که سرور را نصب می‌کند:

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

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

این عملیات را درون tmux اجرا کنید یا آن را به عنوان یک unit از نوع one-shot که در زمان boot اجرا می‌شود، به 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= خام به مسیر مطلق نیاز دارد و از آنجا که نصب‌کننده همیشه فایل binary را در یک دایرکتوری ثابت قرار نمی‌دهد، 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

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

وقفه در عملیات 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 کوچک را سریع‌تر از هر چیز دیگری که احتمالاً نصب می‌کنید پر می‌کنند و بزرگترین عامل تأثیرگذار بر حجم آن‌ها، فرمت وزن‌ها است. انتخاب بین 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 کرده باشید ذخیره می‌کند، نه در هیچ دایرکتوری میزبان که متعلق به کاربر 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، شناسه‌ها به محدوده 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 به آن‌ها ارجاع نمی‌دهد، حذف شوند.