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

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

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

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

مراجعة واقعية لمتطلبات الموارد بالأرقام البسيطة

تساوي البصمة الذاكرية للنموذج تقريباً حجم ملفه، مضافاً إليه نحو 1 GB من الحمل التشغيلي، ثم مساحة إضافية لنافذة السياق. نماذج Ollama الافتراضية مكمّمة إلى 4 بت (وتُسمّى Q4)، وهذا يتطلب نحو نصف GB من RAM لكل مليار مَعلمة. لذلك تكون العملية الحسابية بسيطة، وهي التي تحدد كل شيء. أما الحد الأخير فتضبطه أنت: إن رفعت num_ctx فوق القيمة الافتراضية الصغيرة في Ollama فستحصل على مساحة أكبر للمطالبات الأطول، لكن ذلك يزيد حجم ذاكرة KV cache في RAM. لذلك حدّد طول السياق قبل أن تحكم على ملاءمة النموذج.

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

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

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

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

تثبيت 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 key، ولا تسجيل دخول، ولا حد لمعدل الطلبات، ولا قائمة سماح. يمكن لأي شخص يستطيع الوصول إلى المنفذ 11434 تشغيل أي نموذج نزّلته، وتنزيل نماذج جديدة، وحذفها، وإبقاء CPU أو GPU لديك تحت حمل كامل إلى أجل غير محدد. تفهرس أدوات المسح مثل Shodan مثيلات Ollama المكشوفة بالآلاف، ويُعثر على المثيل المكشوف ويُساء استخدامه خلال ساعات.

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

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

• اتركه محلياً. إذا كان المستدعي الوحيد برنامجاً آخر على VPS نفسه، أو cron script، أو bot، أو خادم 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 واطلب كلمة مرور أو token في nginx أو Traefik أو Caddy، ثم مرّر الطلبات إلى 127.0.0.1:11434. يحتفظ Ollama بالارتباط المحلي، ويكون الـ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 اسماً سبق أن نزّلته؛ ويُرجع الاسم غير المعروف model "x" not found, try pulling it first. ويؤدي استدعاء 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، بحيث تنفّذ أعمال الصياغة الخاصة منخفضة التكلفة بعيداً عن واجهة API مدفوعة، بينما يبقى الاستدلال المعقد مع نموذج مستضاف.

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

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

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

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

كل شيء بطيء ببساطة. تحصل على عشرة رموز في الثانية أو أقل، من دون ظهور أي خطأ. هذا هو استدلال CPU الذي يعمل بالطريقة المعتادة. يعرض ollama ps القيمة 100% CPU، ما يعني عدم وجود GPU. هذا ليس خطأ، ولا يعالجه أي إعداد، لأن القيد هو عرض نطاق الذاكرة وليس إعداداً غير صحيح. استخدم نموذجاً أصغر، أو تقبّل السرعة، أو انتقل إلى instance مزودة بـ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، والحسابات، وسجل المحادثات، والإعدادات، وأي systemd drop-in أنشأته. انسخ الوحدة احتياطياً باستخدام حاوية مؤقتة:

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

رقِّ Ollama بإعادة تشغيل install script؛ ورقِّ Open WebUI باستخدام docker pull ghcr.io/open-webui/open-webui:main، ثم أعد إنشاء الحاوية. لا تثبّت الإصدارات على المدى الطويل: تتغير جودة النماذج وبيئة التشغيل بسرعة، لذلك اقرأ ملاحظات الإصدار وأعد قياس الأداء على خادمك بدلاً من الاعتماد على أرقام الربع السابق.

FAQ

هل يمكنني فعلاً تشغيل LLM على VPS يعتمد على CPU فقط؟

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

ما مقدار RAM الذي يحتاج إليه كل نموذج؟

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

هل تتم مصادقة Ollama API؟

لا. لا يوفر Ollama مصادقة مدمجة أو مفتاح API أو حداً لمعدل الطلبات. وكل من يستطيع الوصول إلى المنفذ 11434 يملك تحكماً كاملاً فيه. ولهذا تحديداً يرتبط افتراضياً بالعنوان 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. وجّه أي OpenAI SDK إلى عنوان URL الأساسي هذا، ومرّر أي سلسلة نصية كمفتاح API لأن النظام يتجاهله، واضبط model على اسم نموذج سبق أن نفّذت له pull. يعمل كود OpenAI الموجود عادةً دون تعديل، باستثناء عنوان URL الأساسي والمفتاح.