ollama pull مقابل run: أين تُحفظ النماذج؟

ollama pull مقابل ollama run

ينزّل ollama pull نموذجاً ثم يتوقف. ينزّل ollama run النموذج فقط إذا لم يكن موجوداً، ثم يحمّله إلى الذاكرة ويفتح جلسة محادثة تفاعلية. عملية التنزيل متطابقة، وتُحفظ الملفات في المكان نفسه. وحده run يتابع التنفيذ بعد ذلك.

هذا الفرق وحده يحدد الأمر المناسب لاستخدامه في script، والأمر المناسب لتنفيذه من سطر الأوامر.

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

يجلب السطر الأول النموذج ثم يخرج، لذلك فهو آمن للاستخدام أثناء التجهيز وفي وحدة systemd. يفتح السطر الثاني جلسة محادثة؛ اكتب /bye أو اضغط Ctrl+D للخروج منها. يرسل السطر الثالث prompt واحداً، ويطبع الإجابة ثم يخرج. هذه هي الصيغة المناسبة للـscript عندما يحتاج إلى إجابة بدلاً من جلسة. تترك هذه الصيغة الثالثة طول الإجابة بالكامل للنموذج، لذلك قد يتحول سؤال من سطر واحد إلى 3 فقرات. ويضمن تحديد الإجابة باستخدام num_predict بقاء run الذي ينشئه الـscript ضمن حجم يستطيع المستدعي استخدامه فعلياً. تتغير أسماء النماذج بسرعة، لذلك تعامل مع gemma4 هنا باعتباره عنصراً نائباً: فهذا هو المثال الذي تستخدمه وثائق Ollama الرسمية حتى August 2026، وأي tag من المكتبة يعمل بالطريقة نفسها. إذا كنت تفضّل استخدام نموذج سبق تحديد متطلباته على خادم فعلي، فتعرض طريقة تشغيل Nemotron 3.5 Lightning على VPS الـtag الدقيق المطلوب تنزيله والذاكرة التي يتوقع توفرها.

لماذا يبدو أن أول تشغيل لـ ollama قد تجمّد

قد يتوقف أول run على VPS جديد من دون أي مخرجات لعدة دقائق. لا يوجد عطل. لا يظهر موجّه المحادثة حتى يُنزَّل النموذج إلى القرص ويُحمَّل في الذاكرة، لذلك ينفّذ run عملية تنزيل بحجم عدة غيغابايت قبل أن يعرض أي شيء لك.

هناك عاملان يخفيان هذه العملية. يعرض Ollama شريط التقدم فقط عندما يكون إخراجه موجهاً إلى طرفية، لذلك لا يطبع run الموجود داخل shell script أو cron job أو خطوة CI أو ssh host ollama run ... عادي أي شيء أثناء التنزيل. بعد وصول البيانات، يجب أيضاً قراءة الملف من القرص إلى RAM قبل ظهور أول token. وعلى VPS صغير، تكون هذه القراءة بطيئة. وإذا لم تكن ذاكرة الخادم تكفي للنموذج، تبدأ النواة باستخدام swap، فتطول مدة الانتظار كثيراً.

راقب العملية من جلسة ثانية بدلاً من التخمين:

df -h /
watch -n5 df -h /

انخفاض المساحة الحرة على مراحل يعني أن التنزيل ما زال قيد التنفيذ. أما توقف انخفاض المساحة الحرة مع بقاء الأمر مشغولاً، فيعني أن التنزيل اكتمل وبدأ تحميل النموذج إلى الذاكرة.

لهذا يُفضَّل تنزيل النموذج مسبقاً. يجب ألا يكون الشخص الذي يكتب ollama run هو نفسه من يدفع كلفة التنزيل.

اسحب النموذج قبل أن يطلبه أي مستخدم

وينطبق الأمر نفسه على كل ما ليس شخصاً: وكيل برمجي موجّه إلى نقطة نهاية Ollama لديك سيتخلى عادةً عن الطلب الأول بدلاً من انتظار اكتمال تنزيل حجمه عدة غيغابايت. على خادم جديد، نفّذ السحب ضمن النص البرمجي نفسه الذي يثبّت الخادم:

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

إذا كنت تجهّز الخادم للمرة الأولى، يغطي دليل تثبيت Ollama الكامل على VPS الخدمة نفسها والجهات المسموح لها بالوصول إليها. بعد ذلك، ما يستحق الإعداد هو سحب يستمر بعد إغلاق الطرفية، لأن توقف التنزيل في منتصفه هو ما يؤدي إلى وجود مخزن نماذج غير مكتمل.

شغّله داخل tmux، أو سلّمه إلى 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= المجرد إلى مسار مطلق، ولا يضع المثبّت الملف التنفيذي دائماً في الدليل نفسه، لذلك فإن command -v ollama على خادمك هو الإجابة الموثوقة الوحيدة. يؤدي المرور عبر shell إلى استخدام PATH الخاص بالخدمة بدلاً من استخدام مسار منسوخ من دليل. كما أن ExecStart الأول مهم: يعني After=ollama.service أن وحدة الخادم بدأت، وهذا لا يعني أنها أصبحت جاهزة، لذلك تنتظر الحلقة حتى يستجيب ollama list قبل بدء السحب.

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

يجب أن يوضح السجل اكتمال السحب من دون أخطاء، ثم يجب أن يعرض ollama list النموذج. للحفاظ على تحديث tag متحرك، أضف مؤقت systemd أو إدخالاً أسبوعياً في cron يشغّل عملية السحب نفسها. يؤدي سحب tag انتقل إلى إصدار أحدث إلى تنزيل الطبقات الجديدة، ويترك الطبقات القديمة من دون مراجع إليها، وتُنظَّف هذه الطبقات في المرة التالية التي يبدأ فيها الخادم.

ما الذي يحدث عند مقاطعة عملية السحب

تُخزَّن كل طبقة من النموذج ضمن تجزئة تعتمد على محتواها وحده. لذلك لا يضيع العمل عند مقاطعة عملية السحب: شغّل الأمر ollama pull نفسه مرة أخرى، وستتعرّف الأداة على الطبقات التي اكتمل تنزيلها وتتجاوزها، ثم تتابع التنزيل من الطبقة التي انقطع عندها.

هناك إجراء واحد يتسبب في فقدان هذا التقدم. عند بدء تشغيل خادم Ollama، يزيل الطبقات المخزنة التي لا يشير إليها أي بيان نموذج. والطبقة الجزئية التي خلّفتها عملية سحب توقفت هي بالضبط من هذا النوع. لذلك، إذا أعدت تشغيل الخدمة قبل إعادة المحاولة، فستفقد الجزء الذي نزّلته بالفعل. أعد محاولة السحب أولاً، ثم أعد التشغيل لاحقاً. إذا كان يجب أن تبقى عملية التنزيل الجزئية بعد إعادة التشغيل، فعيّن OLLAMA_NOPRUNE=1 في بيئة الخدمة، ثم أزله لاحقاً، لأن عملية التنظيف عند بدء التشغيل هي التي تمنع تراكم الطبقات اليتيمة على القرص.

إذا توقفت عملية السحب مع no space left on device، فحرّر مساحة قبل إعادة المحاولة. إذا أبلغ df عن امتلاء القرص، ولم يفسّر du في مجلد النموذج سبب ذلك، فقد استُخدمت المساحة في مكان آخر. عندها يجدر بك قراءة أسباب اختلاف نتائج df وdu قبل حذف أي شيء.

أين يخزّن Ollama النماذج على VPS؟

اسأل خادمك بنفسك بدلاً من الوثوق بمسار وارد في أي دليل، بما في ذلك هذا الدليل. يختلف الموقع بين التثبيت من حزمة والتشغيل داخل حاوية، ويتغير مجدداً إذا ضبط أحدهم OLLAMA_MODELS.

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

يطبع systemctl cat ملف الوحدة مع كل ملفات drop-in، لذلك يظهر فيه أي سطر OLLAMA_MODELS ضبطته بنفسك أو أُدرج في صورتك. إذا لم يوجد هذا السطر، فسيكون مخزن النماذج ضمن الدليل الرئيسي للحساب الذي تعمل الخدمة باسمه، ويطبع getent passwd ذلك الدليل الرئيسي في الحقل السادس المفصول بنقطتين. يبحث find في نظام ملفات واحد عن دليل blobs، وهو الدليل الذي تُكتب فيه الطبقات فعلياً. احذف -xdev إذا كانت النماذج قد تكون موجودة مسبقاً على mount منفصل.

قِس الآن، واقرأ الأرقام التي حصلت عليها بنفسك:

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

يتكون المخزن من جزأين. يحتوي manifests على ملف صغير واحد لكل وسم نموذج، ويسرد هذا الملف الطبقات التي بُني منها الوسم. ويحتوي blobs على الطبقات نفسها، وتُسمّى كل طبقة وفق hash محتوياتها، ويتركز فيه تقريباً كامل الحجم. وبما أن الطبقات مشتركة بين الوسوم، فإن نموذجين مبنيين على الأوزان نفسها يبلّغ كل منهما عن حجمه الخاص في ollama list، مع شغل تلك المساحة مرة واحدة فقط على القرص؛ لذلك قد يتجاوز مجموع الأحجام المذكورة ما يبلّغه du للدليل.

تملأ ملفات النماذج نظام ملفات root صغيراً على VPS أسرع من أي شيء آخر يُرجّح أن تثبّته، وأكبر عامل منفرد يؤثر في حجمها هو تنسيق الأوزان. يستحق الاختيار بين q4 وq8 وfp16 عدة غيغابايت لكل نموذج.

نقل النماذج إلى وحدة تخزين بيانات باستخدام OLLAMA_MODELS

إذا كانت الخطة تتضمن قرصاً ثانياً أو وحدة تخزين بيانات أكبر، فانقل مخزن النماذج قبل امتلاء نظام الملفات الجذري. أوقف الخادم أولاً حتى لا تنسخ ملفاً ما يزال قيد الكتابة.

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، لذلك تبقى الوحدة المثبتة من الحزمة دون تعديل، ولا يمكن لترقية الحزمة الكتابية أن تستبدل تغييرك. أضف السطرين التاليين:

[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 بحثاً عن أخطاء صلاحيات تذكر المسار الجديد. احذف النسخة القديمة فقط بعد التأكد من صحة القائمة، لأن فشل النقل ثم حذف المصدر يعني تنزيل كل شيء مرة أخرى.

الخيار الآخر يُبقي المسار الأصلي ويربط وحدة تخزين البيانات به:

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 لنقطة الربط أن الربط يعمل. يفيد bind mount عندما يتوقع شيء آخر على الخادم موقع التخزين الافتراضي. لكن له مشكلة واحدة: تبقى الملفات التي نسختها تحت نقطة الربط على القرص الجذري، ويخفيها الربط، لذلك لا تُستعاد المساحة إلا بعد فك الربط وحذفها. يسهل شرح متغير البيئة أكثر من الخيار الآخر للشخص الذي سيسجّل الدخول بعد ذلك.

حيث يحتفظ بها الحاوي بدلاً من ذلك

تخزّن الصورة الرسمية النماذج في المسار الذي تربطه، وليس في أي دليل على المضيف يملكه مستخدم ollama. أمر التشغيل الموثّق هو:

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

يمثّل ollama قبل النقطتين وحدة تخزين مسماة في Docker، بينما يمثّل /root/.ollama المسار الذي يكتب فيه الخادم داخل الحاوي. لذلك لا يعثر du على شيء في المسارات من القسم السابق، لأن النماذج ليست موجودة فيها. اطبع الموقع والحجم الفعليين:

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

اقرأ حقل Mountpoint من docker volume inspect، ثم شغّل sudo du -sh عليه. لوضع النماذج في وحدة تخزين على المضيف، استبدل وحدة التخزين المسماة بدليل على المضيف (-v /mnt/data/ollama:/root/.ollama)، ثم أعد إنشاء الحاوي. يكتب الحاوي بصفة root، لذلك يصبح ذلك الدليل على المضيف مملوكاً لـ root. أما مع Podman دون root، فتُربط المعرّفات بنطاق subuid الخاص بمستخدمك، ولذلك تظهر الملكية على المضيف بشكل مختلف مرة أخرى: يشرح تشغيل Ollama مع Podman دون root هذا الربط.

تحذير بشأن التنظيف. يحذف docker volume prune كل وحدة تخزين لا يشير إليها أي حاوي. إذا حذفت حاوي ollama أو أعدت إنشاءه من دون وحدة التخزين الخاصة به، فسيحذف أمر prune لاحقاً كل نموذج نزّلته، ولن تتمكن من استعادته إلا بإعادة تنزيله. اقرأ كيفية تنظيف استخدام Docker للقرص على VPS قبل تشغيل prune على خادم يستضيف نماذج.

إزالة نموذج باستخدام ollama rm، وليس باستخدام rm

ollama list
ollama rm gemma4
ollama list
df -h /

يؤدي ollama rm إلى حذف manifest الخاص بذلك الوسم، ثم يحذف الطبقات التي لا يشير إليها أي manifest متبقٍّ. تعود المساحة فور إلغاء ربط هذه الملفات، لذلك يتحرك df مباشرة. وبما أن الطبقات مشتركة، فقد تؤدي إزالة أحد وسمين متقاربين إلى تحرير مساحة أقل بكثير من الحجم الذي طبعه ollama list بجانبه. هذا سلوك صحيح، وليس فشلًا في الحذف.

يؤدي حذف الملفات يدوياً إلى كسر هذا الترابط. أزل blob باستخدام rm، وسيظل manifest يسرده، لذلك يواصل ollama list عرض النموذج، ويفشل أيّ استخدام له عند قراءة الطبقة المفقودة. أزل manifest يدوياً، وستبقى طبقاته على القرص من دون أي مرجع إليها، فتشغل مساحة لا يعرضها لك أي أمر من أوامر Ollama. إذا فعلت ذلك بالفعل، فإن ollama rm على الوسم يزيل الإدخال المتبقي، كما تؤدي إعادة تشغيل الخادم إلى إزالة الطبقات التي لا يشير إليها أي شيء.

هناك تمييز أخير، لأن الخلط بين الأمرين شائع جداً. يتعلق ollama rm بالقرص. أما ollama stop gemma4 فيزيل تحميل النموذج من الذاكرة ولا يحرر أي مساحة على القرص. وتُعد المدة التي يبقى فيها النموذج مقيماً في RAM بعد اكتمال التنزيل إعداداً منفصلاً، ويتناولها إبقاء النموذج محمّلاً بدلاً من إعادة تحميله مع كل طلب.

FAQ

ما الفرق بين ollama pull وollama run؟

ينزّل ollama pull نموذجاً إلى القرص ثم ينتهي. يتحقق ollama run مما إذا كان النموذج موجوداً على القرص، وينزّله إذا لم يكن موجوداً، ويحمّله إلى الذاكرة، ثم يفتح جلسة محادثة تفاعلية. يكتب كلا الأمرين الملفات نفسها في الدليل نفسه. استخدم pull أثناء التجهيز وفي البرامج النصية، واستخدم run عندما تكون أمام لوحة المفاتيح. يرسل ollama run <model> "your prompt" مطالبة واحدة ثم ينتهي، وهو الشكل القابل للبرمجة من run.

لماذا يبدو أن أول تشغيل لـollama run يتوقف؟

إنه ينزّل النموذج. لا تظهر مطالبة المحادثة قبل حفظ النموذج على القرص وتحميله إلى الذاكرة، وحجم النموذج عدة غيغابايت. يعرض Ollama شريط التقدم فقط عندما يكون الإخراج موجهاً إلى طرفية، لذلك لا يعرض run داخل برنامج نصي أو مهمة cron أو ssh host ollama run ... أي شيء أثناء عمله. افتح جلسة ثانية وشغّل watch -n5 df -h /؛ يعني تناقص المساحة الحرة على مراحل أن التنزيل جارٍ. نزّل النموذج مسبقاً، فتختفي فترة الانتظار.

أين يخزّن Ollama نماذجه؟

يعتمد الموقع على طريقة التثبيت، لذلك اطبعه بدلاً من افتراضه. شغّل systemctl cat ollama.service لمعرفة ما إذا كان OLLAMA_MODELS مضبوطاً في الوحدة أو في drop-in. إذا لم يكن مضبوطاً، فسيكون مخزن النماذج داخل الدليل الرئيسي للحساب الذي تعمل الخدمة باسمه، ويطبعه getent passwd ollama. يحدّد sudo find / -xdev -type d -name blobs 2>/dev/null دليل الطبقات مباشرة. بالنسبة إلى صورة الحاوية، يوجد المخزن داخل وحدة التخزين المركّبة، ويطبع 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 ثم أعد التشغيل. تحقّق باستخدام systemctl show ollama --property=Environment وollama list. تعني القائمة الفارغة في معظم الحالات أن مستخدم ollama لا يستطيع قراءة الدليل الجديد؛ وسيعرض journalctl -e -u ollama المسار.

هل يؤدي حذف ملفات النموذج إلى تحرير المساحة؟

يحرّر حذف الملفات يدوياً المساحة، لكنه يترك المخزن في حالة غير متسقة. إذا حذفت blob، فسيظل manifest يسرد ذلك النموذج، لذلك سيستمر ظهوره في ollama list وسيفشل عند استخدامه. وإذا حذفت manifest، فستبقى طبقاته على القرص من دون أي مرجع إليها. استخدم ollama rm <model>، إذ يحذف manifest ثم الطبقات التي لا يحتاج إليها أي نموذج آخر. إذا حُذفت الملفات يدوياً مسبقاً، فشغّل ollama rm على الوسم لمسح الإدخال، ثم أعد تشغيل الخادم، الذي يزيل الطبقات التي لا يشير إليها أي manifest.