لماذا يتفوق VPS على AWS أو GCP لأدوات الذكاء الاصطناعي
خدمات السحابة المُدارة (AWS وGCP وAzure) قوية، لكن نموذج الفوترة حسب الموارد المستهلكة يصبح مكلفاً بسرعة حين يعمل الحاوي باستمرار. فحاوي Docker بسيط لـ Open WebUI يعمل 24/7 على AWS EC2 (نموذج t3.large، وحدتا CPU / 8 جيجابايت RAM) يكلف نحو 60–80 يورو شهرياً قبل حساب التخزين ونقل البيانات. في المقابل، يوفر VPS بالموارد نفسها جزءاً يسيراً من هذا السعر بتكلفة ثابتة وقابلة للتوقع.
ثمة ثلاثة مزايا أخرى أهم من التكلفة لأدوات الذكاء الاصطناعي:
زمن استجابة API محلي. حين يستدعي Open WebUI خدمة Ollama، يكون الاثنان على الجهاز نفسه فيصبح زمن الاستجابة في حدود الميلي ثانية. أما في بنية سحابية موزعة، فكل تبادل يعبر الشبكة الداخلية — وهو احتكاك ملموس عند توليد الرموز المتتالية.
سيادة البيانات. تبقى مطالباتك ووثائق RAG وسجلات المحادثة داخل بنيتك التحتية دون انتقال إلى أطراف خارجية — وهو أمر غير قابل للتنازل في حالات الاستخدام المهنية التي تنطوي على بيانات حساسة.
التحكم في البيئة. وصول root كامل: تختار برنامج تشغيل GPU وإصدارات CUDA وتكوين الشبكة. خدمات السحابة المُدارة تُجرد هذه الطبقة — مريح للانطلاق، لكن مُقيِّد للمجموعات التي تستلزم ضبطاً دقيقاً.
6 مزايا ملموسة للـ VPS لاستضافة أدوات الذكاء الاصطناعي
- تكلفة ثابتة وقابلة للتوقع — دون فاتورة مفاجئة مرتبطة بنشاط النماذج
- بيانات تبقى على بنيتك التحتية — دون نقل إلى أطراف ثالثة
- وصول root كامل — تكوين البيئة تماماً كما تريد
- شبكة Docker الداخلية — يتشارك Open WebUI وOllama على الجهاز نفسه شبكة bridge الخاصة بـ Docker، دون المرور عبر الشبكة العامة
- إمكانية تشغيل أدوات متعددة على خادم واحد باستخدام Docker Compose
- لا قيود على عدد الطلبات أو المستخدمين أو الرموز المولَّدة
اختيار أداة الذكاء الاصطناعي حسب الحاجة — دليل محدَّث 2026
يعتمد الاختيار على ما تريد تحقيقه. Open WebUI (الإصدار v0.11.x) رسّخ نفسه واجهةَ المحادثة المرجعية لـ Ollama والواجهات البرمجية المتوافقة مع OpenAI، مع دعم الأدوات والوثائق والخطوط الأنبوبية وإدارة المستخدمين. ويتميز Dify (الإصدار v1.15.x) ببناء تطبيقات اللغة الكبيرة بواجهة بصرية متكاملة تشمل مسارات العمل وRAG والعوامل والمراقبة المدمجة. ويظل n8n (الإصدار v1.123.x) مرجع أتمتة مسارات العمل الهجينة الجامعة بين عُقَد الذكاء الاصطناعي وتكاملات الأعمال الكلاسيكية. ويستهدف كل من LangFlow (الإصدار v1.11.x) وFlowise (الإصدار v3.1.x) الشريحة ذاتها — خطوط أنابيب LLM بصرية مبنية على LangChain — بفلسفتين مختلفتين: LangFlow يركز على تخصيص Python، وFlowise على البساطة. أما LangFuse (الإصدار v3.x) فليس أداة توليد بل أداة مراقبة: يتتبع استدعاءات LLM ويقيس زمن الاستجابة وجودة الردود، ويتكامل في بضعة أسطر مع سائر الأدوات في هذه القائمة.
دليل الاختيار الموسَّع — حالة 2026
مرّر الجدول أفقيًا
| الحاجة | الأداة الموصى بها | الحد الأدنى لموارد VPS |
|---|---|---|
| واجهة محادثة مع LLM (Ollama أو OpenAI API) | Open WebUI v0.11.x | 2 جيجابايت RAM، وحدتا CPU |
| بناء تطبيقات LLM بصرياً (RAG والعوامل) | Dify v1.15.x | 4 جيجابايت RAM، وحدتا CPU |
| أتمتة مسارات عمل تجمع الذكاء الاصطناعي وأدوات الأعمال | n8n v1.123.x + عُقَد الذكاء الاصطناعي | 2 جيجابايت RAM، وحدتا CPU |
| خطوط أنابيب RAG وروبوتات محادثة بلا كود مع LangChain | Flowise v3.1.x | 2 جيجابايت RAM، وحدة CPU واحدة |
| خطوط أنابيب LLM قابلة للتخصيص بـ Python | LangFlow v1.11.x | 3 جيجابايت RAM، وحدتا CPU |
| مراقبة استدعاءات LLM وتتبعها | LangFuse v3.x | 2 جيجابايت RAM، وحدة CPU واحدة |
| قاعدة معرفة شخصية (PKM) مع ذكاء اصطناعي | Karakeep أو Anytype مستضاف ذاتياً | 2 جيجابايت RAM، وحدة CPU واحدة |
| واجهة محادثة محلية بلا واجهة ويب (CLI) | Jan.ai (وضع الخادم) | 2 جيجابايت RAM، وحدتا CPU |
| أدوات متعددة على VPS واحد | Coolify أو Dokploy | 8 جيجابايت RAM، 4 وحدات CPU |
متطلبات VPS حسب أداة الذكاء الاصطناعي — RAM وCPU وGPU
تتفاوت الاحتياجات تفاوتاً كبيراً بين الأدوات. إليك الموارد الواجب توفيرها لكل حالة استخدام:
الواجهات والمنسقون (بدون نموذج محلي). يستهلك Open WebUI وحده أقل من 500 ميجابايت RAM: فهو عديم الحالة ويفوّض الاستدلال إلى Ollama أو واجهة برمجية خارجية. أما Dify فأكثر استهلاكاً للموارد — تضم مجموعة Docker Compose الخاصة به خدمات متعددة متشابكة (worker وAPI وweb وقاعدة بيانات متجهية وRedis وPostgreSQL) وتستهلك نحو 3.5–4 جيجابايت عند الخمول. n8n وFlowise خفيفتان: احسب 256–512 ميجابايت لكل خدمة.
Ollama مع نماذج محلية. هنا تُحسم المعادلة الحقيقية للموارد. تنطبق القاعدة الأساسية على كمية Q4 الافتراضية (التي يُنزّلها Ollama ما لم تحدد غير ذلك): نموذج 7B يحتاج 4–5 جيجابايت RAM (يُوصى بـ 8 جيجابايت للهامش)، و13B نحو 8–9 جيجابايت (يُوصى بـ 16)، و70B بين 38 و48 جيجابايت حسب طول السياق. وبدون GPU مخصصة يعمل الاستدلال على المعالج — صالح للاختبار، لكن توليد 100 رمز قد يستغرق 30 إلى 60 ثانية على 7B بالمعالج وحده.
GPU مخصصة. للاستخدام اليومي مع نماذج 13B وما فوق، أو لمعالجة طلبات متزامنة، يلزم خادم بـ GPU. تتيح نسخ VPS بـ NVIDIA GPU تخزين النموذج بالكامل في VRAM وتقليص التوليد إلى 1–3 ثوانٍ لكل 100 رمز.
اختيار كمية Ollama المناسبة
يُنزّل Ollama افتراضياً النسخة Q4_K_M من النموذج — أفضل توازن بين الجودة والذاكرة لمعظم الاستخدامات. إذا كان VPS الخاص بك يحتوي بالضبط على 8 جيجابايت RAM لنموذج 7B، فاختر Q4_K_S (دقة أقل قليلاً، وحجم أقل بنحو 200 ميجابايت) للإبقاء على هامش كافٍ. الأمر ollama run llama3.2:7b-instruct-q4_K_S يختار هذه النسخة صراحةً.
نشر مجموعة أدوات ذكاء اصطناعي متعددة باستخدام Docker Compose
تهيئة VPS
اتصل عبر SSH وثبّت Docker Engine وإضافة Compose:
curl -fsSL https://get.docker.com | sh systemctl enable --now dockerتحقق من عمل Docker:
docker run --rm hello-world.إنشاء هيكل المشروع
أنشئ مجلداً لمجموعة أدوات الذكاء الاصطناعي:
mkdir -p /opt/ai-stack && cd /opt/ai-stackسيحتوي هذا المجلد على ملف
docker-compose.ymlووحدات البيانات.كتابة ملف docker-compose.yml
إليك مثالاً لمجموعة تجمع Open WebUI وOllama وn8n:
services: ollama: image: ollama/ollama:latest volumes: - ollama_data:/root/.ollama restart: unless-stopped open-webui: image: ghcr.io/open-webui/open-webui:main ports: - "3000:8080" environment: - OLLAMA_BASE_URL=http://ollama:11434 volumes: - open_webui_data:/app/backend/data depends_on: - ollama restart: unless-stopped n8n: image: n8nio/n8n:latest ports: - "5678:5678" environment: - N8N_HOST=n8n.yourdomain.com - N8N_PROTOCOL=https - WEBHOOK_URL=https://n8n.yourdomain.com/ volumes: - n8n_data:/home/node/.n8n restart: unless-stopped volumes: ollama_data: open_webui_data: n8n_data:لاحظ أن الخدمات على شبكة Docker نفسها تتواصل باسم الخدمة:
ollama:11434يمكن الوصول إليه منopen-webuiدون كشف المنفذ على المضيف.تشغيل المجموعة
أطلق جميع الخدمات:
docker compose up -dتحقق من تشغيل الحاويات:
docker compose psثم نزّل أول نموذج Ollama:
docker compose exec ollama ollama pull llama3.2:latestتكوين البروكسي العكسي Nginx
ثبّت Nginx على المضيف وأنشئ vhost لكل أداة. مثال لـ Open WebUI:
server { server_name chat.yourdomain.com; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }فعّل HTTPS باستخدام Certbot:
certbot --nginx -d chat.yourdomain.com.
تكوين البروكسيات العكسية للوصول إلى كل أداة
مع وجود أدوات متعددة على VPS واحد، تتمثل أفضل الممارسات في تخصيص نطاق فرعي لكل خدمة والسماح لبروكسي عكسي (Nginx أو Caddy) بتوجيه حركة HTTPS إلى المنفذ الصحيح.
الهيكل الموصى به:
- chat.yourdomain.com ← Open WebUI (المنفذ 3000)
- n8n.yourdomain.com ← n8n (المنفذ 5678)
- dify.yourdomain.com ← Dify (المنفذ 80 لحاوي الويب)
- langfuse.yourdomain.com ← LangFuse (المنفذ 3000)
لا تكشف أبداً المنفذ 11434 الخاص بـ Ollama على الواجهة العامة — فهو لا يمتلك مصادقة أصلية. أبقه قابلاً للوصول فقط من داخل شبكة Docker الداخلية.
Caddy يبسّط تكوين TLS: يحصل على شهادات Let's Encrypt ويجددها تلقائياً. ملف Caddyfile بسيط:
chat.yourdomain.com {
reverse_proxy localhost:3000
}
n8n.yourdomain.com {
reverse_proxy localhost:5678
}caddy run --config /etc/caddy/Caddyfile — وتُدار الشهادات دون تدخل.
تأمين الوصول إلى أدوات الذكاء الاصطناعي
قبل كشف أداة ذكاء اصطناعي على نطاق فرعي عام، تحقق من ثلاثة أمور:
1. تفعيل المصادقة. يُنشئ Open WebUI حساباً للمسؤول عند أول وصول — افعل ذلك فوراً. Dify وn8n يتطلبان أيضاً إعداداً أولياً: لا تترك هذه الواجهات مفتوحة دون كلمة مرور.
2. عدم كشف المنفذ 11434 (Ollama). هذا المنفذ لا يمتلك مصادقة — لا تفتح قاعدة جدار حماية عليه. تحقق بـ ss -tlnp | grep 11434: يجب أن يكون الربط على 127.0.0.1 أو واجهة Docker، ليس على 0.0.0.0.
3. HTTPS إلزامي. تمنع شهادة TLS صالحة اعتراض المطالبات ورموز المصادقة أثناء النقل. Certbot وCaddy يؤتمتان التجديد.
استكشاف الأخطاء — الأخطاء الشائعة
Ollama: نفاد الذاكرة. النموذج يتجاوز RAM المتاحة. تحقق من الذاكرة الحرة بـ free -h، ثم اختر كمية أخف (q4_K_S أو q3_K_M) أو نموذجاً أصغر. إذا حدث الخطأ على VPS بـ GPU، فالـ VRAM ممتلئة — تحقق بـ nvidia-smi.
Open WebUI لا يجد Ollama. عنوان URL المُكوَّن غير صحيح أو شبكة Docker لا تسمح بالتواصل. إذا كان Open WebUI وOllama في ملف docker-compose.yml نفسه، فالعنوان الصحيح هو http://ollama:11434 (اسم الخدمة، ليس localhost ولا IP المضيف). وإذا كان Ollama على المضيف (خارج Docker)، استخدم http://host.docker.internal:11434 (Linux) أو IP جسر Docker (172.17.0.1 افتراضياً).
المنفذ 11434 غير مُتاح من حاوي آخر. ربما Ollama مُكوَّن للاستماع على 127.0.0.1 فقط. أضف OLLAMA_HOST=0.0.0.0 إلى متغيرات بيئة خدمة Ollama في ملف Compose — هذا يكشفه على جميع واجهات الحاوي فقط، لا على المضيف العام.
n8n: عنوان URL للـ webhook غير صحيح. يبني n8n عناوين الـ webhook من N8N_HOST وWEBHOOK_URL. إذا لم تتطابق هذه المتغيرات مع النطاق الفرعي HTTPS الخاص بك، ستفشل الـ webhooks الواردة. تحقق ثم أعد تشغيل الحاوي بعد التعديل: docker compose restart n8n.
Dify: خدمات لا تبدأ. يستخدم Dify خدمات متعددة مترابطة (PostgreSQL وRedis وخدمة worker). افحص السجلات: docker compose logs --tail=50 worker api. المشكلة في الغالب هجرة قاعدة بيانات معلقة أو وحدة تخزين غير مُهيَّأة بشكل صحيح.
للاستزادة — مقالات ذات صلة
يغطي هذا الدليل إعداد مجموعة أدوات ذكاء اصطناعي عامة. للتعمق في كل أداة:
- Open WebUI: النشر الكامل مع إدارة المستخدمين والخطوط الأنبوبية وتكاملات API — انظر استضافة Open WebUI على VPS.
- Dify: تثبيت Docker Compose وتكوين الإضافات دون اتصال والبروكسي العكسي — انظر نشر Dify على VPS.
- LangFlow: نشر متقدم مع backend Python مخصص — انظر المقال المخصص.
- LangFuse: مراقبة LLM مستضافة ذاتياً — انظر مقال LangFuse المخصص.
- Coolify / Dokploy: إذا كنت تفضل واجهة رسومية لإدارة حاوياتك بدلاً من تحرير ملفات Compose — انظر Coolify مقابل Dokploy.
