كيف تُبقي نموذج Ollama محمّلاً في الذاكرة؟

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

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

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

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

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

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

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

free -h

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

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

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

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

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

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

ollama stop qwen3:8b

يعود الأمر دون مخرجات، ويختفي النموذج من ollama ps. يعيد الاسم غير المحمّل القيمة couldn't find model "qwen3:8b" to stop. صيغة 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 عدد النماذج التي تبقى محمّلة في الوقت نفسه. واعتباراً من 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 ما تم تحميله فعلياً، بصرف النظر عما يذكر ملف الإعدادات أنه يجب تحميله.

إذا كان محرر أو وكيل يدير خادمك، فتحقق مما يرسله ذلك العميل قبل إلقاء اللوم على الخادم. يوضح توجيه وكيل برمجي إلى خادم 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، وإذا لم يظهر المتغير في الناتج، فهذا يعني أن الخادم لم يستلمه، لأن المتغير الذي تصدّره في الصدفة لا يصل إلى خدمة systemd. عيّنه باستخدام sudo systemctl edit ollama.service، ثم شغّل sudo systemctl daemon-reload وsudo systemctl restart ollama. والسبب الآخر هو أن عميلاً يرسل قيمة keep_alive خاصة به في الطلب، فتتجاوز القيمة الافتراضية للخادم.

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

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