إبقاء نموذج Ollama محمّلاً في الذاكرة

لماذا يفرغ Ollama النموذج بعد بضع دقائق؟

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

تُسمّى المهلة keep_alive. وهي تُطبَّق لكل نموذج، وتُعاد عند انتهاء كل طلب. لا يُفرغ النموذج الذي يجيب عن طلب حالياً، لأن الخادم لا يفرغ إلا نموذجاً لا يملك أي طلب نشط. اعتباراً من August 2026، تكون القيمة الافتراضية خمس دقائق، وتنطبق على كل نموذج يحمّله هذا الخادم.

يمكنك ضبط keep_alive في موضعين: ضمن الطلب الفردي، أو كقيمة افتراضية للخادم. يضمن ملف drop-in في systemd بقاء القيمة الافتراضية للخادم بعد إعادة التشغيل. يفترض هذا الدليل أن Ollama يعمل مسبقاً كخدمة. إذا لم يكن كذلك، فابدأ بـ تثبيت Ollama على VPS ثم عُد إلى هنا.

ما النماذج الموجودة في الذاكرة حالياً، ومتى تنتهي مدة بقائها؟

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

يعني الناتج الفارغ عدم تحميل أي نموذج، ولذلك سيدفع الطلب التالي كلفة تحميل كاملة. يوضح PROCESSOR مكان تحميل الأوزان. وتُعد 100% GPU و100% CPU حالتين واضحتين. أما قيمة مثل 25%/75% CPU/GPU فتعني أن النموذج لم يتسع في VRAM، لذلك يعمل جزء منه على المعالج وتصبح عملية التوليد أبطأ.

يمثل UNTIL العد التنازلي، ويطبع وقتاً نسبياً مثل 4 minutes from now. ويطبع Forever عندما يكون النموذج قد حُمِّل باستخدام keep_alive سالب. ويطبع Stopping... خلال الفترة القصيرة التي يفرّغ فيها الخادم النموذج.

تغيّرت مجموعة الأعمدة بين الإصدارات، لذلك اقرأ الترويسة بدلاً من عدّ الحقول في script. ولأي عملية مؤتمتة، استخدم API:

curl -s http://localhost:11434/api/ps

يتضمن كل إدخال expires_at، وهو طابع زمني مطلق مثل 2026-08-09T14:38:31.83753Z، وsize_vram، وهي نسبة ذلك النموذج الموجودة في ذاكرة GPU. وتعني قيمة size_vram تساوي 0 أن النموذج يعمل على CPU.

ما تكلّفه إعادة التحميل فعلياً

لا تعتمد على التخمين. يعرض Ollama مدة التحميل في كل استجابة، بوصفها load_duration، بوحدة النانوثانية.

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

يحمّل الاستدعاء الأول النموذج، لذلك تكون قيمة load_duration فيه كبيرة. اقسمها على 1000000000 لقراءتها بالثواني. يُنفَّذ الاستدعاء الثاني بينما يكون النموذج مقيماً في الذاكرة، ويعرض رقماً أصغر بكثير. الفرق بين هذين الرقمين هو الزمن الذي يدفعه كل مستخدم مرة واحدة بعد انتهاء المؤقت، وهو السبب الكامل لتغيير keep_alive. يعود معظم هذا الفرق إلى قراءة القرص، لذلك إذا كنت قد نقلت دليل النموذج إلى وحدة تخزين ثانية، فإن سرعة تلك الوحدة تحدد الحد الأدنى لزمن كل تحميل بارد. ولمعرفة سرعة التوليد قبل ذلك التوقف وبعده، راجع كيفية قياس عدد الرموز المولَّدة في الثانية على خادمك.

إبقاء نموذج Ollama محمّلاً في الذاكرة ضمن طلب واحد

أرسل keep_alive مع الطلب. ويُطبَّق ذلك على النموذج بدءاً من لحظة اكتمال الطلب.

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

تُقبل أربع صيغ للقيمة:

• سلسلة مدة: "30m" و"24h" و"90s"
• رقم عادي يُفسَّر بالثواني: 3600
• قيمة سالبة، -1 أو "-1m"، وتعني عدم تطبيق مهلة خمول مطلقاً
• 0، وتعني إلغاء تحميل النموذج فور اكتمال هذا الطلب

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

يمكنك أيضاً تحميل نموذج من دون توليد أي شيء. أرسل اسم النموذج فقط. يحمّله الخادم ويعيد استجابة فارغة مع "done": true.

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

هذا هو الأمر الذي تشغّله بعد إعادة التشغيل أو بعد سحب نموذج جديد، حتى لا يدفع أول طلب فعلي من المستخدم تكلفة التحميل. وتنفّذ CLI المهمة نفسها باستخدام flag:

ollama run --keepalive 30m qwen3:8b "hello"

اجعل القيمة محمّلة افتراضياً باستخدام OLLAMA_KEEP_ALIVE

يقرأ الخادم OLLAMA_KEEP_ALIVE عند بدء التشغيل ويستخدمه لكل نموذج لا يحمل قيمة خاصة به. وتقبل هذه القيمة الصيغ نفسها التي يقبلها حقل الطلب، لذلك تعمل 30m و3600 و-1 جميعاً.

المشكلة هي البيئة التي يجب أن تُضاف إليها القيمة. لا يفعل تشغيل export OLLAMA_KEEP_ALIVE=30m في جلسة SSH شيئاً، لأن التثبيت المضمّن يشغّل الخادم كخدمة systemd تحت حساب مستخدم خاص بها وبيئة خاصة بها. لا تتصل صدفة تسجيل الدخول بهذه الخدمة. وهذا هو السبب الأكثر شيوعاً لظهور الإعداد وكأنه مُهمَل.

اجعل الإعداد يستمر بعد إعادة التشغيل باستخدام drop-in في systemd

sudo systemctl edit ollama.service

يفتح المحرر مع علامتي تعليق. اكتب بينهما: يتجاهل systemd أي شيء تكتبه أسفل العلامة الثانية.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

تكتب عملية الحفظ /etc/systemd/system/ollama.service.d/override.conf. هذا drop-in وليس تعديلاً على الوحدة التي تشحنها الحزمة، لذلك يترك ترقية حزمة Ollama التي تستبدل ollama.service إعدادك دون تغيير. إذا كانت drop-ins وملفات الوحدات جديدة عليك، فراجع دليل خدمات systemd والمؤقتات لفهم آلية عملها.

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

يعرض الأمر الأخير البيئة التي ستشغّل الخدمة بها فعلياً. إذا كان OLLAMA_KEEP_ALIVE=30m مفقوداً من ذلك السطر، فهذا يعني أن drop-in لم يُطبَّق. ويكون السبب في معظم الحالات غياب ترويسة [Service] أو كتابة الأسطر أسفل العلامة. تؤدي إعادة التشغيل نفسها إلى إسقاط كل نموذج محمّل، لذلك يكون الطلب التالي عملية تحميل باردة. ابدأ تحميله مسبقاً باستخدام استدعاء preload أعلاه.

ما الذي يكلّفك إبقاء نموذج محمّلاً في الذاكرة

عمود SIZE في ollama ps هو الذاكرة المحجوزة طوال فترة الخمول، وليس أثناء الطلب فقط. يحتاج نموذج بحجم 8B مع تكميم 4-bit إلى نحو 5 إلى 6 GB. أما نموذج بحجم 27B فيتطلب حساباً مختلفاً، ومن المفيد مراجعة حساب الذاكرة اللازمة لتشغيله على VPS يعتمد على CPU فقط قبل أن تقرر إبقاءه محمّلاً. عند ضبط keep_alive على -1، فأنت تقرر أن النموذج له الأولوية الدائمة على كل شيء آخر في الخادم. في VPS صغير، يأتي ذلك مباشرة على حساب قاعدة البيانات وتطبيق الويب ومهام البناء.

راقب الأرقام الفعلية بدلاً من الاعتماد على تقدير. شغّل الأمر التالي أثناء تحميل نموذج، ثم شغّله مرة أخرى بعد ollama stop:

free -h

يعرض عمود available مقدار الذاكرة التي ما زال kernel قادراً على تخصيصها لعملية جديدة. وعلى خادم مزود بوحدة NVIDIA GPU، يعرض nvidia-smi الوضع نفسه في VRAM. إذا نفدت موارد الخادم، يقتل kernel إحدى العمليات لاستعادة الموارد:

sudo dmesg -T | grep -i "out of memory"

يعني السطر الذي يذكر ollama أن خادم النموذج كان العملية التي أُنهيت. أما السطر الذي يذكر قاعدة بياناتك، فيعني أن النموذج انتصر وأن شيئاً مهماً لديك خسر الموارد. كلا الاحتمالين ناتج عن القرار نفسه: ضبط فترة keep-alive طويلة على خادم لا يملك سعة احتياطية.

هناك تكلفتان يسهل تجاهلهما. يحجز طول السياق الأكبر KV cache، أي ذاكرة التخزين المؤقت للقيم والمفاتيح، وهي حالة الانتباه لكل token التي يحتفظ بها النموذج أثناء التوليد. وتُحتسب هذه الذاكرة ضمن الحجم المحمّل. يعتمد حجمها على num_ctx، لذلك يؤدي رفع نافذة السياق إلى زيادة الذاكرة التي يحتفظ بها النموذج المحمّل طوال فترة الخمول، وليس أثناء الإجابة فقط. تحجز قيم OLLAMA_NUM_PARALLEL التي تتجاوز 1 ذاكرة التخزين المؤقت هذه مرة لكل خانة متوازية. إذا كنت تخطط إلى خدمة عدة أشخاص من نموذج واحد، فاحسب الذاكرة اللازمة للخانات، لا للأوزان وحدها.

الإعداد الافتراضي المعقول هو أن يستخدم نموذج واحد على خادم ذي سعة احتياطية -1. أما الخادم المشترك، فاستخدم فترة تغطي الفواصل بين طلباتك، مثل 30m، لكي تتحرر الذاكرة عندما تتوقف عن العمل.

إلغاء تحميل نموذج فوراً

ollama stop qwen3:8b

يعود الأمر من دون مخرجات، ويختفي النموذج من ollama ps. إذا لم يكن الاسم محمّلاً، فستحصل على couldn't find model "qwen3:8b" to stop. صيغة API هي طلب من دون مطالبة، مع ضبط keep_alive على 0:

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

تتضمن الاستجابة "done_reason": "unload". استخدم هذه الطريقة بدلاً من إعادة تشغيل الخدمة. يحرر systemctl restart ollama الذاكرة أيضاً، لكنه يزيل تحميل كل نموذج آخر ويُنهي أي طلب قيد التنفيذ.

تشغيل أكثر من نموذج على خادم واحد

يحدّد OLLAMA_MAX_LOADED_MODELS عدد النماذج التي تبقى محمّلة في الوقت نفسه. واعتباراً من August 2026، تكون القيمة الافتراضية ثلاثة نماذج لكل GPU، أو ثلاثة نماذج على خادم يعمل بالـCPU فقط. يحسب هذا الحد عدد النماذج، بينما تمثّل الذاكرة القيد الفعلي. لذلك قد يُرفض تحميل نموذج كبير ثانٍ بسبب عدم توفر مساحة، قبل وقت طويل من الوصول إلى ثلاثة نماذج.

عند طلب نموذج جديد وعدم توفر ذاكرة كافية له، يفرغ المجدول أحد النماذج المقيمة لتوفير المساحة. ويفضّل نموذجاً لا يملك أي طلب نشط، كما يمكنه إخلاء نموذج لم تنتهِ مهلته، بما في ذلك نموذج حُمّل باستخدام -1. لذلك تعني قيمة keep_alive السالبة عدم وجود مهلة لعدم النشاط. ولا تمنع هذه القيمة تثبيت الأوزان عند وصول طلب لنموذج آخر.

يُسجّل هذا القرار على مستوى debug. أضف سطراً ثانياً من Environment="OLLAMA_DEBUG=1" إلى ملف drop-in نفسه، ثم أعد التشغيل وراقب:

sudo journalctl -u ollama -f

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

إرشادات تظل صالحة بعد الإصدار التالي

تُصدر Ollama إصدارات جديدة كثيراً، وتتغير إعداداتها الافتراضية؛ لذلك تحقّق من الإصدار الموجود أمامك بدلاً من حفظ الأرقام عن ظهر قلب:

ollama --version
ollama serve --help

يعرض ollama serve --help متغيرات البيئة التي يقرأها ذلك الإصدار فعلياً، ومن بينها OLLAMA_KEEP_ALIVE. هناك قاعدتان ظلّتا ساريتين عبر الإصدارات، ويمكنك الاعتماد عليهما بأمان. تتغلب القيمة المحددة في الطلب على الإعداد الافتراضي للخادم. كما أن ollama ps يوضح فعلياً ما تم تحميله، بغض النظر عما يحدده ملف الإعدادات.

إذا كان محرر أو agent يتحكم في خادمك، فتحقّق مما يرسله ذلك العميل قبل إلقاء اللوم على الخادم. يوضح توجيه coding agent إلى خادم Ollama الخاص بك مكان وجود إعدادات الطلب هذه.

FAQ

لماذا يفرغ Ollama نموذجي بعد 5 دقائق؟

خمس دقائق هي القيمة الافتراضية لـ keep_alive، وهو مؤقت الخمول الذي يبدأه Ollama عند انتهاء الطلب. عند انتهاء المؤقت، يحرر الخادم أوزان النموذج، لذلك يعيد الطلب التالي تحميلها من القرص. وهذا التحميل هو سبب فترة التوقف التي تلاحظها. ارفع القيمة لطلب واحد بإرسال "keep_alive": "30m" في نص JSON، أو طبّقها على الخادم بالكامل باستخدام متغير البيئة OLLAMA_KEEP_ALIVE.

كيف أبقي نموذج Ollama محمّلاً في الذاكرة بشكل دائم؟

استخدم قيمة سالبة: "keep_alive": -1 في الطلب، أو OLLAMA_KEEP_ALIVE=-1 للخادم. يعرض ollama ps عندئذٍ Forever في العمود UNTIL. يؤدي ذلك إلى إلغاء مؤقت الخمول فقط، ولا يغيّر أي شيء آخر. إذا طُلب نموذج آخر وكانت الذاكرة غير كافية، فسيظل المجدول يفرغ هذا النموذج لتوفير مساحة.

لماذا يتم تجاهل OLLAMA_KEEP_ALIVE؟

تحقق من المكان الذي عيّنت فيه المتغير. شغّل systemctl show ollama --property=Environment. إذا لم يظهر المتغير في الناتج، فهذا يعني أن الخادم لم يستلمه، لأن المتغير الذي تصدّره في shell لا يصل إلى خدمة systemd. عيّنه باستخدام sudo systemctl edit ollama.service، ثم شغّل sudo systemctl daemon-reload وsudo systemctl restart ollama. والسبب الآخر هو أن العميل قد يرسل قيمة keep_alive خاصة به في الطلب، فتتجاوز القيمة الافتراضية للخادم.

كيف أحرر الذاكرة من دون إعادة تشغيل Ollama؟

يفرغ ollama stop qwen3:8b ذلك النموذج فوراً، ويترك الخادم وكل نموذج آخر محمّلاً قيد التشغيل. عبر API، أرسل طلباً من دون prompt مع "keep_alive": 0، وستتضمن الاستجابة "done_reason": "unload". أكّد ذلك باستخدام ollama ps، الذي يجب ألا يعرض النموذج بعد ذلك.