استضافة Ollama على خادم VPS: دليل التشغيل المتقدم

Ollama في الإنتاج: ما الذي يتغير بعد أول تشغيل

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

ما يقدمه الإدارة المتقدمة عمليًا

سحب انتقائي — تنزّل فقط النموذج الذي تحتاجه دون ملء القرص بمتغيرات غير مستخدمة.
حذف نظيف — ollama rm يحرر مساحة القرص ويقلل وقت تحميل النماذج المتبقية.
واجهة REST موثقة — يعرض Ollama المسارات /api/generate و/api/chat و/v1/chat/completions؛ وكيل عكسي أمامه يمنح نقطة ‎HTTPS مع مصادقة.
تحكم في التزامن — OLLAMA_MAX_LOADED_MODELS يمنع تحميل عدة نماذج في آنٍ واحد ونفاد ذاكرة ‎RAM.
متغيرات بيئة دائمة — تُضاف OLLAMA_KEEP_ALIVE وOLLAMA_NUM_THREADS وOLLAMA_CONTEXT_SIZE إلى أمر docker run أو ملف compose.yml خاضع للإصدارات.
تدوير نماذج قابل للبرمجة — استدعاء بسيط لـ curl على /api/pull يكفي لأتمتة تحديث النموذج من مسار ‎CI.
كشف انتقائي — يمكنك كشف الواجهة البرمجية لأدواتك الداخلية فقط (Open WebUI وn8n وLangFlow) دون جعلها عامة.

اختيار النماذج وإدارتها: الحجم وذاكرة RAM والتكميم

يُعبَّر عن حجم النموذج بمليارات المعاملات (B) وهو ما يحدد ذاكرة RAM المطلوبة. نموذج 1B/3B يتّسع في 2 إلى 3 GB ويناسب المهام البسيطة (تصنيف، ملخص قصير) على خادم VPS متواضع. نموذج 7B/8B يحتاج 5 إلى 6 GB في Q4: وهو أكثر نسب الجودة/الموارد شيوعًا. نموذج 13B يحتاج 9 إلى 10 GB، أما 70B فيتجاوز 40 GB — مخصص لخوادم VPS عالية الذاكرة أو تهيئات GPU. لكل حجم، يضبط التكميم مقايضة الجودة/السرعة: Q4_K_M يوفر أفضل توازن على المعالج، وQ8 يحافظ على دقة أكبر بتكلفة ضعف ذاكرة RAM. قبل سحب نموذج، تحقق من المساحة الحرة بـ df -h وذاكرة RAM المتاحة بـ free -h.

العمليات الشائعة: السحب والحذف وكشف الواجهة البرمجية

سرد النماذج المتاحة

نفّذ docker exec ollama ollama list لرؤية النماذج المنزّلة مسبقًا وحجمها على القرص وتاريخ إضافتها.

تنزيل نموذج جديد

شغّل docker exec ollama ollama pull llama3.2:3b لنموذج خفيف، أو docker exec ollama ollama pull qwen2.5:7b-instruct-q4_K_M لنموذج 7B مكمَّم. اللاحقة q4_K_M تحدد التكميم مباشرة في الوسم.

حذف نموذج قديم

حرّر مساحة بـ docker exec ollama ollama rm llama3.1:8b. تحقق بعدها بـ docker exec ollama ollama list أن النموذج لم يعد يظهر.

اختبار الواجهة REST محليًا

استدعِ نقطة chat: curl http://127.0.0.1:11434/api/chat -d '{"model":"qwen2.5:7b-instruct-q4_K_M","messages":[{"role":"user","content":"Ping"}],"stream":false}'. تحتوي استجابة JSON على الحقل message.content.

ضبط متغيرات البيئة

أعد تشغيل الحاوية بالخيارات المطلوبة : docker run -d -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 -e OLLAMA_KEEP_ALIVE=-1 -e OLLAMA_MAX_LOADED_MODELS=1 -e OLLAMA_NUM_THREADS=4 --name ollama ollama/ollama. تحافظ هذه المعاملات على النموذج في الذاكرة وتحدّ من حمل المعالج.

تطبيق حدّ معدّل الطلبات عبر nginx

في كتلة server الخاصة بـ nginx، أضف limit_req_zone $binary_remote_addr zone=ollama:10m rate=10r/m; في قسم http، ثم limit_req zone=ollama burst=5 nodelay; في location. يحمي هذا الواجهةَ البرمجية من الطلبات المتكررة المتسارعة.

تحديث Ollama نفسه

أوقف الحاوية واحذفها: docker stop ollama && docker rm ollama. اسحب الصورة الجديدة: docker pull ollama/ollama. أعد التشغيل بنفس المعاملات. النماذج مخزّنة في الحجم ollama ولا تتأثر.

التحقق من صحة الخدمة

شغّل curl http://127.0.0.1:11434/api/tags للحصول على قائمة النماذج المحمّلة. استجابة HTTP 200 مع JSON صالح تؤكد أن الخدمة تستجيب بشكل صحيح.

Ollama خلف وكيل عكسي nginx مع رمز مصادقة

يستمع Ollama افتراضيًا على 127.0.0.1:11434 دون مصادقة. لكشفه لأدواتك (Open WebUI وn8n وسكريبت بعيد)، ضع nginx في الواجهة مع رمز Bearer. تُفوِّض كتلة التهيئة أدناه الوصولَ إلى رمز سري معرَّف في المتغير $api_token، وتتحقق من ترويسة Authorization وتعيد التوجيه إلى Ollama. يُهيَّأ CORS لقبول طلبات واجهتك دون كشف الواجهة البرمجية لجميع المصادر.

في /etc/nginx/sites-available/ollama:

map $http_authorization $api_token_valid {
    default 0;
    "Bearer YOUR_SECRET_TOKEN" 1;
}
server {
    listen 443 ssl;
    server_name api-ia.your-domain.com;
    ssl_certificate /etc/letsencrypt/live/api-ia.your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api-ia.your-domain.com/privkey.pem;
    location / {
        if ($api_token_valid = 0) { return 401; }
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        add_header Access-Control-Allow-Origin "https://ui.your-domain.com";
    }
}

فعّل بـ ln -s /etc/nginx/sites-available/ollama /etc/nginx/sites-enabled/ ثم nginx -t && systemctl reload nginx.

أداء المعالج: اختيار التكميم الصحيح

على المعالج، Q4_K_M هو نقطة التوازن الموصى بها: فقدان جودة هامشي مقارنةً بـ Q8، مع سرعة توليد أعلى بنحو 40٪ واستهلاك ذاكرة أقل بالنصف. احتفظ بـ Q8 للحالات التي تكون فيها الدقة حاسمة (الشفرات البرمجية، المنطق الرسمي) وخادمك لديه 16 GB من ذاكرة RAM الحرة على الأقل. اضبط OLLAMA_NUM_THREADS على عدد النوى الفيزيائية (لا المنطقية) لتجنب التنازع: على خادم VPS بـ 4 vCPU، ابدأ بـ 3. يؤثر المعامل OLLAMA_CONTEXT_SIZE (الافتراضي: 2048 token) مباشرةً على ذاكرة RAM لكل طلب؛ قلّصه إذا كنت تعالج كثيرًا من الاستدعاءات القصيرة بالتوازي.

استكشاف الأخطاء: الحالات الأكثر شيوعًا

أربع حالات تتكرر بانتظام في الإنتاج.

النموذج بطيء للغاية. التوليد يتجاوز 2-3 رموز في الثانية على المعالج لنموذج 7B؟ تحقق أن OLLAMA_NUM_THREADS ليس عند القيمة 1 (الافتراضي إن لم يُضبط في بعض الصور). تحقق أيضًا أن نموذجًا واحدًا فقط محمّل (OLLAMA_MAX_LOADED_MODELS=1): نموذجان متزامنان يتنافسان على النوى وعرض نطاق الذاكرة.

ذاكرة VRAM غير كافية (GPU). إذا أظهر سجل Docker رسالة CUDA out of memory أو ROCm error، فالنموذج لا يتّسع في VRAM. انتقل إلى وسم q4_K_M أو قلّص OLLAMA_CONTEXT_SIZE. يتراجع Ollama إلى المعالج إذا كانت VRAM غير كافية، لكن دون الإشارة إلى ذلك بوضوح: قارن سرعات التوليد للكشف عن ذلك.

رفض اتصال الواجهة البرمجية. curl: (7) Failed to connect من الخارج بينما الخدمة تستمع؟ جدار الحماية يحجب المنفذ 11434، أو nginx غير مشغّل. تحقق بـ ss -tlnp | grep 11434 (يجب أن يُظهر 127.0.0.1، لا 0.0.0.0) ثم systemctl status nginx.

Signal killed / OOM. العملية تُقتل من النواة (OOM killer). ذاكرة RAM للخادم غير كافية للنموذج المختار. انتقل إلى حجم أصغر أو فعّل swap بحجم 4 إلى 8 GB كمخزن مؤقت: fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile. يبطّئ swap التوليد لكنه يتجنب الإيقافات المفاجئة.

التكامل مع أدوات أخرى على VPS

Ollama هو خلفية تقنية: تظهر قيمته الكاملة حين تتصل به خدمات أخرى. ثلاثة أدوات تتكامل بشكل طبيعي على نفس الخادم.

Open WebUI يعرض واجهة محادثة مشابهة لـ ChatGPT مربوطة بواجهة Ollama المحلية. في ملف البيئة، عرّف OLLAMA_BASE_URL=http://ollama:11434 (إذا شاركت الحاويتان شبكة Docker) أو OLLAMA_BASE_URL=http://127.0.0.1:11434 إذا كان Open WebUI يعمل على نفس المضيف. يتولى Open WebUI اختيار النموذج وسجل المحادثات وإدارة المستخدمين. تنبيه: يُضيف الاقتران بين Ollama وOpen WebUI سطح هجوم إضافيًا يستوجب المراقبة — راجع قسم CVE-2026-45672 أدناه.

LangFlow هو منشئ مرئي لمسارات LLM. أضف عقدة Ollama في تدفقك، أدخل http://127.0.0.1:11434 كعنوان URL أساسي واختر النموذج من القائمة المنسدلة. يستدعي LangFlow المسار /api/generate مباشرةً دون مصادقة داخلية — ضعه على الشبكة الخاصة للخادم، لا مكشوفًا للعموم.

n8n يتيح لك تشغيل استدعاءات Ollama من سير عمل الأتمتة. استخدم عقدة HTTP Request التي تشير إلى http://127.0.0.1:11434/api/chat مع جسم JSON يحتوي على model وmessages. من n8n يمكنك ربط استدعاء Ollama بخطوة استرجاع بيانات أو إرسال بريد أو webhook صادر دون كتابة شفرة برمجية.

‏CVE-2026-45672: تجاوز التفويض في Open WebUI

نُشرت هذه الثغرة في 21 مايو 2026 (GHSA-482j-2pq6-q5w4)، وتؤثر على جميع إصدارات Open WebUI السابقة للإصدار 0.8.12. درجة CVSS: 8.8 (عالية).

آلية الهجوم. يستطيع مستخدم موثَّق تنفيذ شفرة Python تعسفية عبر المسار /api/v1/utils/code/execute، حتى لو أوقف المسؤول تنفيذ الشفرات في الإعدادات (ENABLE_CODE_EXECUTION=false). الحارس مُعلَن في التهيئة لكنه لا يُطبَّق أبدًا على مستوى الواجهة البرمجية: أي حساب موثَّق على النظام يمكنه تشغيل التنفيذ.

الأثر. يحصل المهاجم على وصول إلى خلفية Jupyter الأساسية ويمكنه قراءة ملفات تعسفية على الخادم، وسرقة الأسرار (مفاتيح API، ورمز Bearer لـ Ollama، ومتغيرات البيئة)، أو تأسيس تثبيت مستمر. السرية والسلامة والتوافر للخادم مخترَقة جميعًا.

لماذا يُعدّ هذا خطيرًا في اقتران Ollama مع Open WebUI. يعمل Ollama وOpen WebUI في الغالب على نفس الخادم VPS، وأحيانًا في نفس شبكة Docker، مع أسرار مشتركة (مفتاح OpenAI الاحتياطي، ورمز Bearer لواجهة Ollama). وبالتالي يمنح وصول RCE على Open WebUI وصولًا مباشرًا لواجهة Ollama والنماذج في الذاكرة، متجاوزًا الوكيل العكسي بالكامل.

الإصلاح. حدّث Open WebUI إلى الإصدار 0.8.12 أو أحدث. يُطبِّق هذا الإصدار التحقق من ENABLE_CODE_EXECUTION على مستوى نقطة نهاية الواجهة البرمجية، حيث كان يجب دائمًا أن يكون.

التحقق من إصدارك. من الحاوية: docker exec open-webui cat /app/package.json | grep '"version"'. إذا كانت النتيجة أقل من 0.8.12، فالتحديث عاجل: docker pull ghcr.io/open-webui/open-webui:main && docker stop open-webui && docker rm open-webui ثم أعد التشغيل بنفس معاملات البيئة.

تصليب اقتران Ollama مع Open WebUI بعد CVE-2026-45672

أربعة إجراءات تكميلية يُطبَّق بعد التحديث إلى 0.8.12.

1. عزل شبكات Docker. أنشئ شبكة bridge مخصصة (docker network create llm-private) وضع فيها الحاويتين. حينئذٍ لا يكون Ollama قابلًا للوصول من Open WebUI إلا عبر اسم الخدمة (http://ollama:11434)، دون المرور بواجهة الخادم العامة.

2. عدم كشف المنفذ 11434 خارجيًا أبدًا. أكّد أن الربط يبقى على 127.0.0.1:11434. على شبكة Docker الداخلية، يستجيب Ollama على المنفذ 11434 دون مصادقة — هذا مقبول إذا كانت الشبكة خاصة؛ يصبح ناقلًا للهجوم فور إمكانية الوصول إليه من الخارج.

3. تعطيل تنفيذ الشفرات إن لم تحتج إليه. في متغيرات بيئة Open WebUI، عيّن ENABLE_CODE_EXECUTION=false. بعد التحديث إلى 0.8.12، بات هذا الإعداد مُطبَّقًا على مستوى الواجهة البرمجية. إن لم يتضمن استخدامك تنفيذ شفرات، عطّله كتدبير دفاع في العمق.

4. تقييد التسجيل. في واجهة إدارة Open WebUI (الإعدادات ← الإدارة)، أوقف التسجيل العلني (ENABLE_SIGNUP=false) إذا كان النظام مكشوفًا على الإنترنت. تتطلب ثغرة CVE-2026-45672 حسابًا موثَّقًا: تقليص سطح التسجيل يقلص سطح الهجوم.