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

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

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

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

يمكنك ضبط keep_alive في موضعين: ضمن الطلب نفسه، أو كقيمة افتراضية للخادم. يجعل systemd drop-in القيمة الافتراضية للخادم تستمر بعد إعادة التشغيل. يفترض هذا الدليل أن 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، بينما يعمل الجزء المتبقي على المعالج، فتكون عملية التوليد أبطأ. يحدث ذلك عادةً لأن النموذج لم يتسع، لكن إعداد num_gpu الذي يحدد عدد الطبقات التي تُرسل إلى GPU ينتج التقسيم نفسه.

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

تغيّرت مجموعة الأعمدة بين الإصدارات، لذلك اقرأ الترويسة بدلاً من عدّ الحقول في script. يطبع Ollama v0.40.2، وهو الإصدار الحالي عند إجراء هذا الفحص في 2026-10-10، أيضاً عمود RUNNER بين CONTEXT وUNTIL. ويسمي هذا العمود الـrunner الذي يقدّم النموذج، لذلك قد تكون ترويسة الإخراج لديك أعرض بعمود واحد من المثال أعلاه. بالنسبة إلى أي إجراء آلي، استخدم 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. بعد إلغاء التحميل، تظل ذاكرة الصفحات في النواة غالباً محتفظة بملف النموذج. لذلك يمكن أن تكون إعادة التحميل أسرع من أول تحميل بعد الإقلاع على خادم تتوفر فيه ذاكرة RAM احتياطية. عندما تُستعاد مساحة ذاكرة التخزين المؤقت، تُقرأ الأوزان من القرص. لذلك، إذا كنت قد نقلت دليل النموذج إلى وحدة تخزين ثانية، فإن سرعة تلك الوحدة تحدد الحد الأدنى لزمن كل تحميل بارد. لمعرفة سرعة التوليد قبل ذلك التوقف وبعده، راجع كيفية قياس عدد الرموز المولدة في الثانية على خادمك.

إبقاء نموذج 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] أو كتابة الأسطر أسفل العلامة. تؤدي إعادة التشغيل نفسها إلى إلغاء تحميل كل النماذج المحمّلة، لذلك يكون الطلب التالي تحميلًا بارداً. نفّذ استدعاء التحميل المسبق أعلاه لتسخينها. يحافظ drop-in على الإعداد بعد إعادة التشغيل، لكنه لا يحافظ على النموذج: تبدأ الخدمة ollama serve من دون تحميل أي نموذج، لذلك نفّذ استدعاء التحميل المسبق نفسه بعد كل إقلاع.

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

يمثل العمود SIZE في ollama ps الذاكرة المحجوزة طوال فترة الخمول، وليس أثناء الطلب فقط. يستهلك نموذج بحجم 8B مع quantisation بمقدار 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 طويلة على خادم لا يملك هامشاً احتياطياً.

هناك تكلفتان يسهل إغفالهما. يحجز context length أكبر ذاكرة KV cache أكبر، وهي key value cache، أي حالة الانتباه لكل token التي يحتفظ بها النموذج أثناء التوليد. وتُعد هذه الذاكرة جزءاً من الحجم المقيم في الذاكرة. يعتمد حجمها على num_ctx، لذلك يؤدي رفع نافذة السياق إلى زيادة الذاكرة التي يحتفظ بها النموذج طوال فترة الخمول، وليس أثناء الرد فقط. يحجز OLLAMA_NUM_PARALLEL الأكبر من 1 ذاكرة التخزين المؤقت هذه مرة لكل parallel slot. إذا كنت تخطط إلى خدمة عدة مستخدمين من نموذج واحد، فاحسب حجم الذاكرة وفق عدد الفتحات، وليس وفق الأوزان وحدها.

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

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

ollama stop qwen3:8b

يُنفَّذ الأمر دون إخراج، ويختفي النموذج من ollama ps. كما يُنفَّذ دون إخراج عند استخدامه مع نموذج سحبته، لكنه غير محمّل حالياً. لا يتحقق الأمر من النماذج الموجودة في الذاكرة؛ بل يرسل طلب إلغاء التحميل، ويعيد الخادم استجابة نجاح سواء كان أي نموذج موجوداً في الذاكرة أم لا. لا يظهر الخطأ couldn't find model "qwen3:8b" to stop إلا عندما لا يكون هناك نموذج بهذا الاسم مثبتاً على هذا الخادم. ويعني ذلك عادةً وجود خطأ مطبعي في الاسم أو الوسم. لذلك، لا يثبت ollama stop الصامت أن أي شيء قد أُزيل من الذاكرة. أما ollama ps فيثبت ذلك. صيغة API هي طلب بلا prompt، مع ضبط 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 عدد النماذج التي تبقى محمّلة في الوقت نفسه. واعتباراً من October 2026، تكون القيمة الافتراضية ثلاثة نماذج لكل GPU، أو ثلاثة نماذج على خادم يعمل بوحدة المعالجة المركزية فقط. يحسب هذا الحد عدد النماذج، بينما تمثل الذاكرة الحد الفعلي. لذلك قد يُرفض تحميل نموذج كبير ثانٍ قبل الوصول إلى ثلاثة نماذج بوقت طويل.

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

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

sudo journalctl -u ollama -f

اقرأ السبب المذكور بجانب الطلب الذي أدى إلى إخلاء النموذج. يعني max runners achieved, unloading one to make room بلوغ حد OLLAMA_MAX_LOADED_MODELS. وقد يحدث ذلك حتى عندما تتسع الذاكرة للنموذجين، لذا ارفع الحد إذا أظهر free -h توفر مساحة كافية. إذا ذكر السجل أن النموذج الجديد سيتجاوز الذاكرة المتاحة، ثم أتبع ذلك بإخلاء نموذج، فهذا يعني أن هذين النموذجين لا يتسعان معاً على هذا الخادم. والحل هو تشغيل عدد أقل من النماذج على هذا الخادم، أو تعيين نافذة طويلة للنموذج الذي يجب أن يجيب بسرعة، واستخدام 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 المتغير 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، إذ يجب ألا يعرض النموذج بعد ذلك.