استضافة Ollama على VPS بأمان وتشغيل نموذج لغوي

ما الذي ستبنيه

نموذج لغوي واحد بوزن مفتوح يعمل على خادم تملكه، ويستجيب عبر HTTP API، ويمكنك عند الحاجة استخدام صفحة دردشة في متصفحك. يتولى Ollama تنزيل النموذج وتحميله إلى الذاكرة ومعالجة الطلبات على http://127.0.0.1:11434. يتطلب التثبيت أمراً واحداً. أما الأجزاء الصعبة فتتعلق بأمور أخرى: اختيار نموذج يستطيع VPS تخزينه فعلياً في RAM، وعدم نشر خادم inference من دون مصادقة على الإنترنت بالكامل عن طريق الخطأ.

إليك تحذيرين واضحين أولاً. يعمل VPS الذي يستخدم CPU فقط على النماذج الصغيرة ببطء، ولا توفر API أي مصادقة مضمّنة على الإطلاق. سنغطي الأمرين بالتفصيل أدناه، لأنهما مصدر الخطر الأكبر.

التحقق الواقعي من الحجم بالأرقام

بصمة الذاكرة لأي نموذج هي تقريباً حجم ملفه، مضافاً إليها حوالي جيجابايت واحد من استهلاك وقت التشغيل، بالإضافة إلى مساحة إضافية لنافذة السياق. الوسوم الافتراضية لأشهر نماذج Ollama، ومن بينها llama3.2:3b وllama3.1:8b وmistral:7b، هي نماذج مكممة بـ 4-بت (تحمل الرمز Q4_K_M)، وهو ما يتطلب حوالي نصف جيجابايت من ذاكرة الوصول العشوائي (RAM) لكل مليار معامل. ليست كل الإعدادات الافتراضية هي Q4: فالنماذج الصغيرة مثل smollm2:135m تأتي بدقة 16-بت، لذا تحقق من سطر التكميم في صفحة المكتبة الخاصة بالنموذج قبل إجراء الحسابات. الحساب بسيط وهو الذي يحدد كل شيء. المصطلح الأخير هو ما تحدده أنت بنفسك: رفع num_ctx فوق القيمة الافتراضية الصغيرة لـ Ollama يمنحك مساحة أكبر للمطالبات الطويلة ولكنه يزيد من حجم ذاكرة التخزين المؤقت KV في الـ RAM، لذا استقر على طول سياق معين قبل أن تقرر ما إذا كان النموذج مناسباً أم لا.

النموذج بحجم 3B مثل llama3.2:3b يتطلب تنزيل حوالي 2 جيجابايت ويحتاج إلى حوالي 4 جيجابايت من الـ RAM الحرة للعمل. النموذج بحجم 7B أو 8B مثل mistral:7b أو llama3.1:8b يبلغ حجمه حوالي 5 جيجابايت على القرص ويحتاج إلى حوالي 8 جيجابايت من الـ RAM، و16 جيجابايت ليعمل بأريحية. النموذج بحجم 13B أو 14B يحتاج تقريباً إلى 16 جيجابايت. أي نموذج في نطاق 30B إلى 70B يحتاج إلى خادم بذاكرة RAM كبيرة أو، واقعياً، إلى وحدة معالجة رسومية (GPU)؛ ففي خادم VPS يعتمد على المعالج المركزي (CPU)، لن يتسع النموذج أو ستكون سرعة استجابته بطيئة جداً لدرجة تجعله غير مفيد.

الآن بخصوص السرعة، لأن هذا هو الجزء الذي يقلل الناس من شأنه. الاستنتاج عبر المعالج المركزي (CPU) مقيد بعرض نطاق الذاكرة، وليس بسرعة الساعة، وخادم VPS الذي يشارك الـ vCPU لديه عرض نطاق متواضع. توقع سرعة تتراوح بين أرقام أحادية إلى أرقام مزدوجة صغيرة من الرموز (tokens) في الثانية: نموذج 7-8B بدقة Q4 قد يحقق 4 إلى 10 رموز في الثانية، ونموذج 3B يحقق 10 إلى 25. وحدة معالجة الرسوميات (GPU) أسرع بمرتبة مقدارية تقريباً. هذه أرقام تقريبية عن قصد، والتصرف الصادق هو قياس أداء خادمك الخاص، وهو ما توضحه خطوة التشغيل أدناه. ثق بـ eval rate الخاص بك، وليس برقم في أي مقال، بما في ذلك هذا المقال.

الخلاصة العملية: النماذج الصغيرة المكممة التي تعمل على المعالج المركزي مفيدة حقاً للمسودات، والتلخيص، والتصنيف إذا كنت تستطيع تقبل السرعة. لأي شيء أكبر أو أسرع، خصص ميزانية لمثيل (instance) يحتوي على GPU. إذا كنت تفضل رؤية هذه الحسابات مطبقة بالكامل على نموذج محدد، فإن تشغيل Nemotron 3.5 Lightning على خادم VPS يغطي الوسم الذي يجب سحبه، والـ RAM التي يحتاجها فعلياً، وما إذا كان الاعتماد على المعالج المركزي فقط يفي بالغرض.

للمقارنة بين نموذج معين وخادم معين، قدّر بصمة الذاكرة الخاصة به هنا:

تثبيت Ollama

هناك طريقتان واضحتان. يكون استخدام البرنامج النصي الرسمي أبسط على VPS مستقل:

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

ينشئ هذا مستخدم نظام باسم ollama، ويثبّت الملف التنفيذي في /usr/local/bin/ollama، ويسجّل خدمة systemd باسم ollama.service تبدأ عند الإقلاع وتستمع على 127.0.0.1:11434. تحقّق من أنها تعمل:

systemctl status ollama
ollama --version

إذا كنت تشغّل Docker بالفعل، فاستخدم الحاوية بدلاً من ذلك:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

انتبه إلى البادئة 127.0.0.1: في تعيين المنفذ. فهي تربط المنفذ بـlocalhost فقط. أما كتابة -p 11434:11434 فتنشره على جميع الواجهات، وهذا هو الخطأ الذي يحذّر منه قسم الأمان. اختر طريقة تثبيت واحدة. لا تشغّل البرنامج النصي والحاوية في الوقت نفسه، وإلا سيتنافس processان على المنفذ.

اسحب نموذجك الأول وشغّله

ollama pull llama3.2:3b
ollama run llama3.2:3b

ينزّل pull طبقات النموذج إلى القرص (نحو 2 GB لهذا النموذج). يحمّل run هذه الطبقات إلى الذاكرة ويعرض لك مطالبة >>>. اكتب سؤالاً. قد يستغرق ظهور الرمز الأول عدة ثوانٍ أثناء تحميل الأوزان من القرص إلى RAM، ثم تُعرض الإجابة تدريجياً. اكتب /bye لمغادرة المحادثة؛ ويستمر Ollama في العمل في الخلفية.

تعرّف على ما تم تحميله وكيفية ملاءمته:

ollama ps

يُظهر العمود PROCESSOR الحالة الفعلية. تعني 100% CPU عدم استخدام GPU، وهذا هو سبب البطء. قِس السرعة الفعلية باستخدام الراية المطوّلة:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

يمثل السطر eval rate المطبوع في النهاية عدد الرموز في الثانية على هذا الجهاز. اعتمد هذا الرقم عند التخطيط.

مكان تخزين النماذج، وحجم القرص المطلوب

تُثبَّت النماذج بواسطة البرنامج النصي وتعمل كخدمة، وتُخزَّن في المجلد الرئيسي للمستخدم ollama:

sudo du -sh /usr/share/ollama/.ollama/models

عند تشغيلها تفاعلياً بصفتك المستخدم الخاص بك، تُخزَّن في ~/.ollama/models. أما داخل الحاوية، فتُخزَّن في وحدة التخزين المسماة ollama. هذا مهم لأن أحجام الأوزان المضغوطة تتراكم بسرعة: يبلغ حجم نموذج 3B نحو 2 GB، ونموذج 7-8B نحو 5 GB، ونموذج 14B نحو 9 GB. إذا نزّلت أربعة نماذج لمقارنتها، فستستهلك 20 GB من دون أن تلاحظ. خصّص مساحة القرص للنماذج التي تنوي الاحتفاظ بها، واحذف البقية باستخدام ollama rm <model>. إذا كان VPS نفسه يشغّل بالفعل شيئاً يستهلك مساحة كبيرة، مثل PhotoPrism أو Immich مع مكتبة صور، فاطرح هذه المساحة من المساحة الحرة أولاً، واعتبر المساحة المتبقية ميزانيتك الفعلية للنماذج.

شغِّله كخدمة تتحكم بها

سجّل برنامج التثبيت ollama.service مسبقاً، لذلك يعيد تشغيلها عند الإقلاع دون خطوات إضافية. الإعداد الذي يستحق التغيير هو مدة بقاء النموذج محمّلاً في الذاكرة، وعنوان الربط في بعض الإعدادات. ضع كلا الإعدادين في ملف إسقاط لـsystemd حتى لا تستبدلهما ترقية Ollama:

sudo systemctl edit ollama.service

أضف ذلك تحت الترويسة [Service] التي يعرضها لك المحرر:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

يحدد OLLAMA_KEEP_ALIVE مدة بقاء النموذج في الذاكرة بعد آخر طلب، والقيمة الافتراضية هي 5 دقائق. ارفع هذه المدة على خادم تستعلم منه طوال اليوم لتجنب إعادة تحميل الأوزان في كل مرة. اضبطها على 0 على خادم محدود الموارد لتحرير ذاكرة RAM فور انتهاء الطلب. إذا أردت إبقاء النموذج محمّلاً باستمرار بدلاً من مدة محددة، يشرح إبقاء نموذج Ollama محمّلاً دائماً حقل keep_alive لكل طلب، وكيفية إعادة تدفئة الأوزان بعد إعادة التشغيل بدلاً من تحميلها عند أول طلب بطيء. يعيد systemctl edit تحميل ملفات الوحدة نيابةً عنك، لذلك أعد تشغيل الخدمة لتطبيق التغيير:

sudo systemctl restart ollama

النقطة الأمنية الأكثر أهمية

بشكل افتراضي، يرتبط Ollama بـ 127.0.0.1:11434، لذا لا يمكن الوصول إليه إلا من خلال العمليات الموجودة على الـ VPS نفسه. هذا الإعداد الافتراضي صحيح. حافظ عليه.

لا تحتوي واجهة برمجة التطبيقات (API) على أي مصادقة. لا يوجد مفتاح API، ولا تسجيل دخول، ولا حدود لمعدل الطلبات. القائمة المسموح بها الوحيدة التي يمتلكها، OLLAMA_ORIGINS، تتحكم فقط في أصول المتصفح التي يمكنها استدعاء الواجهة (CORS)؛ وهي لا تفعل شيئاً لمنع curl أو أي سكربت على جهاز آخر. أي شخص يمكنه الوصول إلى المنفذ 11434 يمكنه تشغيل أي نموذج قمت بسحبه، أو سحب نماذج جديدة، أو حذفها، أو إشغال وحدة المعالجة المركزية (CPU) أو معالج الرسوميات (GPU) بكامل طاقتهما إلى أجل غير مسمى. تقوم الماسحات الضوئية مثل Shodan بفهرسة آلاف مثيلات Ollama المفتوحة، ويتم العثور على أي مثيل مكشوف وإساءة استخدامه في غضون ساعات.

إليك الخطأ الوحيد الذي يجب ألا ترتكبه أبداً: لا تضبط OLLAMA_HOST=0.0.0.0 وتفتح المنفذ 11434 في جدار الحماية الخاص بك. هذا ينشر خادم استنتاج (inference server) غير مصادق عليه على الإنترنت بأكمله. لا يوجد قدر من الإعدادات يجعل المنفذ 11434 الخام على 0.0.0.0 آمناً، لأن أياً من إعدادات Ollama الموثقة لا تضيف مصادقة إلى واجهة برمجة التطبيقات المحلية، وقائمة الأصول المسموح بها ليست تسجيل دخول. هذه قاعدة تتعلق بهذه الخدمة تحديداً، وليست حظراً على فتح المنافذ بشكل عام: مرحل RustDesk ذاتي الاستضافة لسطح المكتب البعيد يجب أن يقبل حركة المرور العامة ليؤدي وظيفته، وهو يستحق ذلك لأنه يحمل مصادقة خاصة به تعتمد على المفاتيح وقائمة قصيرة وموثقة من المنافذ، وهو ما يفتقر إليه Ollama تماماً.

هناك ثلاث طرق آمنة للوصول إلى النموذج من خارج الخادم:

• أبقه محلياً. إذا كان المتصل الوحيد هو برنامج آخر على نفس الـ VPS، أو سكربت cron، أو بوت، أو خادم MCP يربط أدواتك بالنموذج، فاترك الربط على 127.0.0.1 واجعل ذلك البرنامج يتصل بـ http://127.0.0.1:11434. لا شيء مكشوف ولا حاجة لأي شيء آخر.
• الوصول إليه عبر نفق خاص. ضع الـ VPS على شبكة WireGuard VPN تستضيفها بنفسك، واضبط OLLAMA_HOST على عنوان النفق (على سبيل المثال 10.8.0.1، وليس 0.0.0.0)، ولن يتمكن سوى أقران الـ VPN من الاتصال. لا يزال الإنترنت العام لا يرى شيئاً على المنفذ 11434.
• ضع Reverse Proxy يتطلب مصادقة أمامه. قم بإنهاء TLS واطلب كلمة مرور أو رمزاً مميزاً عند nginx أو Traefik أو Caddy، ثم قم بعمل proxy إلى 127.0.0.1:11434. يحتفظ Ollama بربطه بـ localhost؛ والـ proxy هو الشيء الوحيد الذي يستمع على المنفذ العام. هذا يشبه تماماً وضع شهادة Let's Encrypt على nginx أمام أي خدمة محلية.

خيار الـ Reverse Proxy هو بالضبط ما توفره لك واجهة الدردشة التالية، مع إرفاق تسجيل دخول حقيقي.

أضف واجهة دردشة باستخدام Open WebUI خلف TLS

Open WebUI هي واجهة دردشة مستضافة ذاتياً. شغّلها في Docker ووجّهها إلى Ollama المحلي:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

العلامة --network=host هي التفصيل المهم على Linux VPS. فهي تضع الحاوية في مساحة أسماء الشبكة الخاصة بالمضيف، لذلك يشير 127.0.0.1 داخل الحاوية إلى loopback الخاص بالمضيف نفسه، وتصل الحاوية إلى Ollama عبر 127.0.0.1:11434 من دون أن يستمع Ollama على أي واجهة أخرى. لا تعمل وصفة شبكة الجسر التي ستراها في موضع آخر، --add-host=host.docker.internal:host-gateway مع OLLAMA_BASE_URL=http://host.docker.internal:11434، هنا. يحل ذلك الاسم إلى بوابة Docker bridge، ولا يمكن الوصول عبر الجسر إلى خدمة مرتبطة بـ127.0.0.1 على المضيف. لذلك تبقى Open WebUI تعرض رسالة تعذّر الاتصال بـOllama.

مقابل استخدام شبكة المضيف هو أن Open WebUI تستمع الآن على منفذ المضيف 8080 عبر كل الواجهات. ويُتجاهل أي تعيين -p، ويطبع Docker تحذيراً يوضح ذلك. لذلك أغلق 8080 في جدار حماية المضيف وجدار حماية مزود الخدمة، واجعل reverse proxy الخاص بـTLS نقطة الدخول العامة الوحيدة. عند الزيارة الأولى، تطلب Open WebUI إنشاء حساب مسؤول. هذا الحساب هو طبقة المصادقة لديك، لذلك اختر كلمة مرور قوية.

لفتح الدردشة من حاسوبك المحمول عبر HTTPS، ضع reverse proxy لـTLS أمام 127.0.0.1:8080. إذا كنت توجّه عدة تطبيقات Docker على الخادم نفسه، فإن Traefik مع TLS تلقائي عبر عدة تطبيقات هو الخيار الأنسب. إذ تصدر كتلة labels واحدة الشهادة وتوجّه chat.example.com إلى Open WebUI. ويُستخدم توجيه label لكل تطبيق نفسه مع كل واجهة أمامية أخرى في المتصفح على الخادم، سواء كانت لوحة حالة أو شيئاً أكثر ترفيهاً مثل Halcyon، التي تعرض مكتبة Jellyfin كمتجر تأجير من التسعينيات، بحيث يعمل كل تطبيق على اسم مضيف مستقل خلف تسجيل دخول خاص به. وتظل قاعدة قسم الأمان سارية: يتولى الـreverse proxy المنفذ العام وتسجيل الدخول، بينما يبقى Ollama على localhost ويظل 8080 الخاص بـOpen WebUI محمياً بجدار الحماية.

استخدم نقطة النهاية المتوافقة مع OpenAI من كودك

يدعم Ollama مجموعة فرعية من واجهة برمجة تطبيقات الدردشة الخاصة بـ OpenAI عبر /v1، لذا تعمل معظم مكتبات عميل OpenAI بعد تغيير شيئين: عنوان URL الأساسي ومفتاح عشوائي.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

مفتاح api_key مطلوب بواسطة مكتبة العميل ولكنه مُتجاهل من قِبل Ollama، لذا يمكنك استخدام أي نص. يجب أن يكون model اسماً لنموذج قمت بسحبه مسبقاً؛ يؤدي استخدام اسم غير معروف إلى إرجاع خطأ 404 مع model 'x' not found. ينطبق المبدأ نفسه عند استخدام أمر curl بسيط:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

هذه هي الطريقة التي تربط بها النموذج بأدوات الوكلاء والمحررات. إذا كنت تطور برمجياتك على الخادم بالفعل، يمكن لنموذج محلي دعم النصوص البرمجية والإضافات جنباً إلى جنب مع تشغيل Claude Code على VPS داخل tmux، مما يبقي مهام المسودة الرخيصة والخاصة بعيداً عن واجهة برمجة التطبيقات المدفوعة، بينما تظل مهام الاستنتاج المعقدة معتمدة على نموذج مستضاف.

أوضاع الفشل، مع السلاسل النصية الدقيقة التي ستراها

تظهر الرسالة "Killed" أثناء التوليد. تشغّل نموذجاً كبيراً، فتطبع الطرفية Killed، أو يعرض سجل الخادم (journalctl -u ollama) سطراً يبدأ بـ llama-server process has terminated. هذه هي الصياغة المستخدمة في Ollama 0.40.3، وقد جرى التحقق منها في 12 October 2026؛ أما الإصدارات الأقدم فكانت تعرض llama runner process has terminated: signal: killed. أوقف Linux OOM killer العملية لأن النموذج احتاج إلى RAM أكبر مما يتوفر على الخادم. أكّد السبب باستخدام sudo dmesg | grep -i oom، حيث سترى سطراً مثل Out of memory: Killed process .... يكمن الحل في استخدام نموذج أصغر أو نموذجاً بكمّية أكبر، مثل llama3.2:3b بدلاً من 13B، أو إضافة swap حتى ينجو الحمل الذي يتجاوز RAM الفعلية بفارق ضئيل، ولكن ببطء، بدلاً من توقفه. يحوّل swap الانهيار الفوري إلى استجابة بطيئة؛ لكنه لا يجعل نموذج 70B عملياً على 4 GB. يكون التوقف صامتاً ما لم تكن تراقب الطرفية في تلك اللحظة، لذلك، على خادم تستعلم منه من مكان آخر، يؤدي إرفاق وحدة OnFailure= بـ ollama.service تنشر إشعاراً إلى خادم ntfy تستضيفه لإرسال التنبيهات الفورية إلى إبلاغك لحظة توقفه، بدلاً من اكتشاف ذلك عند الطلب التالي.

يرفض Ollama تحميل النموذج. يفشل الطلب فوراً مع ظهور خطأ بدلاً من حدوث انهيار، ويسجل سجل الخادم model is too large for system memory (Ollama 0.40.3، وقد جرى التحقق منه في 12 October 2026). كانت الإصدارات الأقدم تطبع Error: model requires more system memory (X GiB) than is available (Y GiB) مباشرة عند موجّه الأوامر. هذه هي النسخة المنظمة من الانهيار السابق: أجرى Ollama الحسابات وأوقف العملية بدلاً من ترك OOM killer ينفذ ذلك. اختر نموذجاً يقل احتياجه عن RAM الحرة لديك (تحقق باستخدام free -h)، أو قلّل طول السياق، أو انتقل إلى VPS أكبر. لا توجد أي راية تجعل النموذج يلائم الذاكرة؛ فالذاكرة المطلوبة فعلية.

يستغرق ظهور الرمز الأول وقتاً طويلاً، ثم يعمل كل شيء بشكل طبيعي. لا يطبع النموذج البارد أي شيء لمدة خمس إلى ثلاثين ثانية، ثم يبدأ التدفق بشكل طبيعي. يحدث هذا التوقف لأن الأوزان تُحمّل من القرص إلى RAM للمرة الأولى، ويزيد التخزين البطيء من مدته. بعد تحميل النموذج، يبقى مقيماً طوال مدة OLLAMA_KEEP_ALIVE، لذلك يستجيب الطلب الثاني فوراً. إذا تجاوز التحميل الأول مهلة زمنية في مكان ما ضمن مسار الاستدعاء، فستحصل على خطأ بدلاً من استجابة بطيئة، ويحدد معرفة الطبقة التي أبلغت عن تجاوز مهلة السياق ما إذا كان العميل أو الـproxy أو التحميل نفسه قد نفد صبره. ارفع هذه القيمة إذا كانت فترات الانتظار تزعجك، واستخدم ollama ps لمعرفة ما إذا كان نموذج محمّلاً حالياً.

كل شيء بطيء ببساطة. تحصل على عشر وحدات أو أقل في الثانية، من دون أي خطأ. هذا هو استدلال CPU الذي ينفذ ما ينفذه استدلال CPU. يعرض ollama ps القيمة 100% CPU، ما يعني عدم وجود GPU. هذا ليس خطأً، ولا توجد أي إعدادات تحوّل CPU إلى GPU، لأن القيد الرئيسي هو عرض نطاق الذاكرة. مع ذلك، يستحق أحد الإعدادات الاختبار على VM: يختار Ollama عدد الخيوط من عدد الأنوية الفعلية التي يكتشفها، وقد يعرض hypervisor هذه القيمة بشكل غير صحيح. في جلسة ollama run --verbose، جرّب /set parameter num_thread 4 (أو عدد vCPU لديك)، وأعد تشغيل الطلب نفسه، ثم احتفظ بالقيمة التي تمنحك أفضل eval rate. بعد ذلك، استخدم نموذجاً أصغر، أو اقبل السرعة الحالية، أو انتقل إلى مثيل GPU، وقِس معدلك الفعلي باستخدام --verbose قبل أن تقرر أن شيئاً ما معطّل. عندما يكون الانتظار ناتجاً عن طول الإجابة بدلاً من معدل التوليد، فإن تحديد حد للإجابة باستخدام num_predict يمنع نموذجاً يميل إلى الاستطراد من قضاء دقائق في توليد رموز لن تقرأها أصلاً.

يُرفض الاتصال من جهاز آخر. من حاسوبك المحمول تحصل على curl: (7) Failed to connect to <ip> port 11434: Connection refused. هذا هو السلوك المقصود: يربط Ollama نفسه بـlocalhost فقط. لا تحاول "إصلاح" ذلك بربطه بـ 0.0.0.0، فهذا هو خطأ التعريض المذكور أعلاه تحديداً. صِل إلى النموذج عبر VPN أو من خلال proxy يتولى المصادقة.

عرّضت المنفذ 11434 للإنترنت. إذا ضبطت OLLAMA_HOST=0.0.0.0، وفتحت جدار الحماية، ثم بدأت ترى عمليات سحب لنماذج لم تبدأها أنت أو استخدام CPU بنسبة 100% من عملاء مجهولين، فهذا يعني أن جهات أخرى عثرت على خادمك واستخدمته. هذا هو الخطأ الرئيسي، وليس حالة نادرة. أعد الربط إلى 127.0.0.1 أو إلى عنوان VPN، وأغلق 11434 في جدار الحماية، وضع المصادقة أمام الخدمة. افترض أن أي شيء كان قابلاً للوصول عبر ذلك العنوان أثناء فتحه قد استعلم عنه أشخاص مجهولون.

النسخ الاحتياطي والترقيات

لا توجد بيانات كثيرة قد تفقدها. يمكن إعادة تحميل النماذج، لذا فإن الأشياء الوحيدة التي تستحق النسخ الاحتياطي هي مجلد بيانات Open WebUI، والحسابات، وسجل المحادثات، والإعدادات، وأي ملف إعدادات إضافي (drop-in) لـ systemd قمت بإنشائه. انسخ المجلد احتياطياً باستخدام حاوية مؤقتة:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

قم بترقية Ollama عن طريق إعادة تشغيل نص التثبيت؛ وقم بترقية Open WebUI باستخدام docker pull ghcr.io/open-webui/open-webui:main متبوعاً بإعادة إنشاء الحاوية. ملاحظة بخصوص القرص لسلسلة الإصدارات 0.40: بدأت Ollama 0.40.2 في ترقية النماذج التي تم سحبها بإصدارات سابقة في الخلفية، وتحتفظ بنسخ أصلية كنسخ احتياطية، لذا فهي تستهلك مساحة إضافية على القرص حتى يتم حذفها، بينما أوقفت نسخة 0.40.3 (11 أكتوبر 2026) عملية الترقية في الخلفية تلك. تحقق من df -h بعد الترقية، واقرأ ملاحظات الإصدار للتعرف على الأمر الذي يحذف تلك النسخ الاحتياطية. لا تثبّت إصدارات محددة (Pin) على المدى الطويل: فكلاً من جودة النماذج وبيئة التشغيل تتطور بسرعة، لذا اقرأ ملاحظات الإصدار وأعد إجراء اختبارات الأداء على خادمك الخاص بدلاً من الوثوق بأرقام الربع السابق.

FAQ

هل يمكنني حقاً تشغيل نموذج لغوي ضخم (LLM) على خادم VPS يعمل بالمعالج (CPU) فقط؟

نعم، ضمن حدود معينة. تعمل النماذج الصغيرة المكممة (quantized) التي تتراوح بين 3B و8B على المعالج وتكون مفيدة فعلياً في الصياغة والتلخيص والتصنيف، لكنها تعمل ببطء، بمعدل يتراوح بين رقم واحد إلى رقمين من الرموز (tokens) في الثانية على معالج افتراضي مشترك. أي نموذج بحجم 13B فما فوق سيكون بطيئاً جداً أو لن يتسع في الذاكرة العشوائية (RAM) على الإطلاق. للحصول على سرعة حقيقية أو تشغيل نماذج أكبر، أنت بحاجة إلى خادم مزود بمعالج رسومي (GPU).

كم تبلغ سعة الذاكرة العشوائية (RAM) التي يحتاجها كل نموذج؟

قاعدة تقريبية لإصدارات 4-bit (Q4) التي تستخدمها معظم النماذج الشائعة افتراضياً: حوالي 0.5 جيجابايت من الذاكرة العشوائية لكل مليار معامل (parameter) للأوزان، بالإضافة إلى حوالي 1 جيجابايت للنفقات العامة وقليل من المساحة الإضافية للسياق. لذا، يحتاج نموذج 3B إلى حوالي 4 جيجابايت من الذاكرة الحرة، ونموذج 7-8B إلى حوالي 8 جيجابايت، ونموذج 14B إلى حوالي 16 جيجابايت. تحقق من المساحة المتاحة لديك باستخدام free -h واترك مساحة كافية لنظام التشغيل وأي برامج أخرى على الخادم.

هل واجهة برمجة تطبيقات Ollama محمية بمصادقة؟

لا. لا تحتوي Ollama على مصادقة مدمجة، أو مفتاح واجهة برمجة تطبيقات (API key)، أو حدود لمعدل الطلبات؛ أي شخص يمكنه الوصول إلى المنفذ 11434 لديه تحكم كامل بها. إعداد OLLAMA_ORIGINS الخاص بها يحد فقط من مصادر المتصفح التي يمكنها استدعاؤها، وليس من يمكنه الاتصال. لهذا السبب تحديداً ترتبط الخدمة بـ 127.0.0.1 افتراضياً، ولهذا السبب يجب ألا تعرض المنفذ 11434 على 0.0.0.0 للإنترنت أبداً. يمكنك الوصول إليها محلياً، أو عبر شبكة افتراضية خاصة (VPN)، أو من خلال Reverse Proxy يضيف طبقة تسجيل دخول.

كيف أضيف واجهة دردشة ويب؟

قم بتشغيل Open WebUI في Docker باستخدام --network=host لكي تشارك واجهة الاسترجاع (loopback) الخاصة بالمضيف وتصل إلى Ollama الأصلية على http://127.0.0.1:11434، ثم ضع Reverse Proxy مع TLS أمام المنفذ 8080 الخاص بها للوصول إليها من حاسوبك المحمول. أبقِ 8080 مغلقاً في جدار الحماية ليكون الـ Proxy هو البوابة العامة الوحيدة. يوفر حساب المسؤول في Open WebUI إمكانية تسجيل الدخول، وتحدد كلمة المرور الخاصة به عند التشغيل الأول.

كيف أستدعي النموذج من تطبيقي الخاص؟

استخدم نقطة النهاية المتوافقة مع OpenAI على http://127.0.0.1:11434/v1. وجّه أي حزمة تطوير برمجيات (SDK) خاصة بـ OpenAI إلى عنوان URL الأساسي هذا، ومرر أي سلسلة نصية كمفتاح واجهة برمجة تطبيقات (API key) لأنه يتم تجاهله، واضبط model على اسم النموذج الذي قمت بسحبه. عادةً ما تعمل أكواد OpenAI الحالية دون تغيير باستثناء عنوان URL الأساسي والمفتاح.