Ollama أم llama.cpp على VPS؟ أيهما تختار؟

Ollama مقابل llama.cpp: أي طبقة تريد تشغيلها؟

Ollama وllama.cpp ليسا متنافسين بالطريقة التي يوحي بها السؤال. llama.cpp هو محرك الاستدلال: يحمّل ملف النموذج ويحوّل prompt إلى tokens. أما Ollama فهو مدير للنماذج، وخدمة خلفية، وواجهة HTTP API تعمل فوق ذلك المحرك. ما يزال README الخاص بـOllama يدرج llama.cpp كواجهة خلفية للاستدلال (تم التحقق في 2 أغسطس 2026). لذلك، السؤال الحقيقي هو أي طبقة تريد تشغيلها على VPS لديك، وليس أيهما أسرع.

شغّل Ollama عندما تريد خدمة تجلب النماذج بالاسم وتواصل العمل دون تدخل. شغّل llama.cpp مباشرة عندما تكون الآلة محدودة الموارد وتحتاج إلى اختيار ملف النموذج المحدد، وحجم السياق المحدد، وعدد مؤشرات الترابط المحدد، لأن كل إعداد من هذه الإعدادات يستهلك ذاكرة لا تتوفر لديك على VPS صغيرة.

ما هو كل مشروع فعليًا

llama.cpp هو تطبيق بلغة C وC++ لتنفيذ نماذج Transformer، ويعتمد على مكتبة ggml. يقرأ ملفات GGUF. تنسيق GGUF ‏(GGML universal file format) هو حاوية في ملف واحد تحتوي على الأوزان، ووحدة تقسيم الرموز، والبيانات الوصفية التي يحتاج إليها المحرك لتشغيل النموذج. يوفّر المشروع ملفات تنفيذية منفصلة لمهام منفصلة. llama-server هو خادم HTTP، وllama-cli هو موجّه تفاعلي، وllama-bench يقيس معدل النقل. تُوسَم الإصدارات برقم البناء بدلًا من رقم إصدار دلالي. الوسم الحالي هو b10224، وقد نُشر في 2 August 2026، ويصدر وسم جديد في معظم أيام العمل.

Ollama هو برنامج مكتوب بلغة Go. يحمّل برنامج خفي يعمل في الخلفية، ويُشغَّل باستخدام ollama serve، النماذجَ ويجيب عن طلبات HTTP، بينما يتصل عميل سطر الأوامر بذلك البرنامج الخفي. يوجد خلف كليهما سجلّ في ollama.com يضم نماذج مُعدّة مسبقًا. يستخدم Ollama الإصدارات الدلالية، وقد صدر v0.32.5 في 27 July 2026. يجلب ollama pull ملف GGUF مع قالب مطالبة ومجموعة من المعلمات الافتراضية، ثم يخزّنه ضمن /usr/share/ollama/.ollama/models في Linux.

هذه الحزمة هي الفرق الكامل بين المشروعين. يحدد Ollama لك التكميم والقالب وطول السياق، ويمنحك اسمًا واحدًا لتتذكره. أما llama.cpp فلا يحدد شيئًا، بل يمنحك أعلامًا.

المحور 1: التحكم في النموذج والتكميم

يقلّص التكميم حجم كل وزن من 16 أو 32 بت إلى 4 أو 5 أو 8 بت. وهذا ما يجعل نموذجًا يضم 8 مليارات مُعامِل مناسبًا لذاكرة RAM في VPS عادي. تصبح تسمية GGUF واضحة بعد معرفة النمط: يعني Q4_K_M تكميم K من 4 بت بحجم متوسط. يحافظ الرقم الأعلى على دقة أكبر، لكنه يستهلك ذاكرة أكثر.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

هذه هي أحجام الملفات المنشورة في مستودع bartowski/Meta-Llama-3.1-8B-Instruct-GGUF على Hugging Face، وقد قُرئت في 2 August 2026 وحُوّلت من البايت إلى GiB. توجد 6 نسخ بناء لنموذج واحد، وحجم أصغرها 2.96 GiB، مقابل 7.95 GiB لأكبرها. الخيار الافتراضي الشائع Q4_K_M حجمه 4.58 GiB. في VPS بسعة 4 GiB، يحدد هذا الاختيار وحده ما إذا كان النموذج سيُحمّل أصلًا.

مع llama.cpp، تحدد اسم الملف، لذلك تختار ذلك الصف بنفسك.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

يمثل -c حجم السياق بالرموز، ويمثل -t عدد مؤشرات الترابط، ويحدد -ngl عدد الطبقات التي تُنقل إلى GPU (القيمة 0 على جهاز يعمل بوحدة CPU فقط). لا يُخمّن النظام أي شيء نيابةً عنك.

مع Ollama، يأتي التكميم مرفقًا بالوسم الذي تسحبه، ويعرض ollama ls ما هو موجود فعليًا على القرص. عندما لا يحتوي السجل على النسخة التي تريدها، استورد ملف GGUF بنفسك. اكتب Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

ثم أنشئه وتحقق من النتيجة:

ollama create llama31-q4 -f ./Modelfile
ollama ls

طول السياق هو الإعداد الذي يسبب المشكلات للمستخدمين. يختار Ollama قيمته الافتراضية من VRAM المتاحة، ويدخل الجهاز الذي لا يحتوي على GPU في أصغر نطاق: 4096 رمزًا. إذا أرسلت إليه مستندًا من 20,000 رمز، تُحذف الرموز الزائدة قبل أن يراها النموذج أصلًا، ولذلك تكون الإجابة واثقة لكنها خاطئة بشأن ملف لم يقرأ منه إلا نصفه. ارفع القيمة باستخدام OLLAMA_CONTEXT_LENGTH على البرنامج الخدمي، أو باستخدام PARAMETER num_ctx في Modelfile. لا يحتوي llama.cpp أيضًا على قيمة افتراضية يمكن الوثوق بها. عيّن -c صراحةً، واعرف القيمة التي عيّنتها.

الحساب الفعلي للذاكرة الذي لا يوضحه أحد

ملف النموذج ليس التكلفة الكاملة. تخزّن ذاكرة KV المؤقتة (ذاكرة التخزين المؤقت للمفتاح/القيمة) إدخالًا واحدًا لكل طبقة ولكل رمز من سياق المحادثة، وتزداد مع ازدياد طول المحادثة.

احسبها لنموذج Llama 3.1 8B. يحتوي النموذج على 32 طبقة، و8 رؤوس للمفتاح/القيمة، وبُعد رأس مقداره 128. يخزّن كل رمز مفتاحًا وقيمة، بحجم 2 بايت لكل منهما عند استخدام f16، ولذلك يكون الحساب 2 x 8 x 128 x 2 = 4096 بايت لكل طبقة. وعبر 32 طبقة، يصبح ذلك 128 KiB لكل رمز. ولذلك يحتاج سياق من 4096 رمزًا إلى 512 MiB، بينما يحتاج سياق من 32,768 رمزًا إلى 4 GiB.

لذلك يحتاج نموذج Q4_K_M 8B عند استخدام سياق من 4k إلى نحو 4.58 GiB للأوزان، إضافة إلى نحو 0.5 GiB لذاكرة التخزين المؤقت، وإضافة إلى بيئة التشغيل نفسها. ولا يتسع ذلك لذاكرة RAM بحجم 4 GiB. ويتسع لذاكرة RAM بحجم 8 GiB مع توفر مساحة للتشغيل. إذا رفعت السياق إلى 32k على الجهاز نفسه ذي ذاكرة 8 GiB، فستستهلك ذاكرة التخزين المؤقت وحدها المساحة المتاحة. راقب ذلك مباشرة باستخدام free -h أثناء تحميل النموذج، ولا تعتمد على تقدير لم تقسه.

يزيد Ollama هذا الاستهلاك. تكون قيمة OLLAMA_NUM_PARALLEL الافتراضية هي 1، وتتدرج الذاكرة التي يحتاجها النموذج وفق حاصل ضرب هذه القيمة في طول السياق. إذا رفعت القيمتين معًا، فسيطلب البرنامج الخفي بهدوء عدة أضعاف ذاكرة RAM التي توقعتها.

المحور 2: البرنامج الخدمي الذي يجب عليك تشغيله

ينشئ برنامج تثبيت Ollama وحدة systemd، وينشئ مستخدم نظام ollama، ويفعّل الخدمة. تحصل على إدارة دورة الحياة من دون كتابة أي من ذلك بنفسك. تجري عملية الضبط عبر systemd:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

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

لا يوفر llama.cpp برنامجًا خَدَميًا، لذلك تكتب الوحدة بنفسك باستخدام /etc/systemd/system/llama-server.service:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

فعّلها باستخدام sudo systemctl enable --now llama-server. تحتفظ العملية بالنموذج طوال فترة تشغيلها. لا يتم تفريغ النموذج عند الخمول، ما يعني عدم حدوث إعادة تحميل مفاجئة، وعدم وجود طريقة لاستعادة الذاكرة إلا بإيقاف الخدمة. إذا كانت كتابة الوحدات جديدة عليك، فهي تتبع النمط نفسه المتعلق بـ تشغيل خدماتك الخاصة باستخدام systemd على VPS.

المحور 3: واجهة API التي سيتصل بها تطبيقك

لقد تقلصت الفروق في هذا المحور كثيرًا. يدعم المشروعان الآن تنسيق محادثات OpenAI، لذلك تعمل معظم مكتبات العميل مع أيٍّ منهما بعد تغيير عنوان URL الأساسي فقط.

يستمع Ollama على 127.0.0.1:11434. ومساره المتوافق مع OpenAI هو http://localhost:11434/v1/chat/completions، كما يحتفظ بواجهة API أصلية على /api/chat إلى جانبه. كما توجد وثائق لمسار متوافق مع Anthropic.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

يستمع llama-server على 127.0.0.1:8080 ويقدم /v1/chat/completions و/v1/completions و/v1/embeddings، إضافةً إلى نقطة النهاية الخاصة به /completion وواجهة ويب مدمجة. كما يوفر مسارات تشغيلية لا يوفرها Ollama: المسار /health لفحص الجاهزية، و/props لإعدادات النموذج المحمّل، و/slots لمعرفة ما ينفذه كل موضع طلب، و/metrics بتنسيق Prometheus. إذا كنت تخطط لمراقبة هذه الخدمة، فمن المرجح أن يكون هذا الفرق هو العامل الحاسم.

لا يفعّل أي من الخادمين المصادقة تلقائيًا. ويستخدم كلاهما عنوان loopback افتراضيًا لسبب وجيه. اتصل بهما عبر نفق SSH أو من خلف reverse proxy، ولا تفتح المنفذين 11434 أو 8080 على الإنترنت مطلقًا.

ما الذي يستطيع VPS يعمل بالمعالج فقط فعليًا

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

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

يمثل العمود pp سرعة معالجة الموجه، ويمثل العمود tg سرعة توليد الرموز، وكلتاهما بوحدة الرموز في الثانية. في خطة vCPU مشتركة، يحقق نموذج 8B باستخدام Q4_K_M عادةً سرعة منخفضة من خانة الآحاد في tg. معالجة الموجه هي الجزء الأبطأ: تتم معالجة الموجه كاملًا قبل ظهور أول رمز في الناتج، لذلك يضيف موجه النظام الطويل وقت انتظار إلى كل طلب.

يمكن استخدام CPU في الحالات التالية: نموذج بحجم 1B إلى 4B للتصنيف أو الاستخراج أو التلخيصات القصيرة أو التوجيه. تصل الردود خلال ثوانٍ، وتتسع الذاكرة لها في خطة عادية. لا يمكن استخدام CPU في الحالات التالية: محادثة تفاعلية بسرعة القراءة، أو مساعدات البرمجة، أو معالجة المستندات الطويلة، أو أي مهمة تتضمن حلقة وكيل تنفذ العديد من الاستدعاءات بالتتابع. إذا نفذت الحلقة اثني عشر استدعاءً، واستغرق كل منها أربع ثوانٍ، فستحتاج إلى دقيقة قبل إنتاج أي نتيجة.

هناك خياران عندما لا تحقق الأرقام الأداء المطلوب. إذا كانت المشكلة هي التزامن، أي وصول العديد من المستخدمين إلى نموذج واحد في الوقت نفسه، فيتغير اختيار المحرك، ويغطي مقارنة Ollama مع vLLM لتقديم الخدمة المتزامن هذا الموضوع. وإذا كانت المشكلة هي السرعة الخام، فالحل هو VPS مزود بوحدة GPU، حيث يبدأ -ngl في أن يكون ذا دلالة. وقبل تجربة أي من الخيارين، احصل على خط أساس لأداء العتاد نفسه، لأن عرض نطاق القرص والذاكرة يؤثر في زمن التحميل بقدر تأثير CPU. ويستحق اختبار VPS قابل للتكرار تخصيص ساعة له.

تثبيت llama.cpp مع تثبيت الإصدار على بنية محددة

يتغير المشروعان أسبوعيًا، لذلك سجّل الإصدار الذي نشرته. يثبت الأمر المختصر من المصدر البنية الحالية:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

لتثبيت بنية محددة، نزّل أرشيف tarball المسبق البناء من صفحة الإصدارات بدلًا من ذلك. البنية b10224 هي الوسم الحالي اعتبارًا من 2 أغسطس 2026:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

أو ابنِ الوسم نفسه من المصدر:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

يُعد libssl-dev التبعية الموثقة لميزات HTTPS. تستغرق عملية التجميع عدة دقائق وتتطلب ذاكرة RAM أكبر مما توفره أصغر الخطط، لذا نفّذ التجميع على جهاز أكبر وانسخ الملفات الثنائية إذا نفدت الموارد في الجهاز الصغير.

تثبيت Ollama مع تثبيت الإصدار

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

يقرأ البرنامج النصي OLLAMA_VERSION، وبذلك يمكنك تثبيت إصدار معروف بسلامته بدلاً من استخدام الإصدار الذي صدر هذا الصباح. نُشر الإصدار v0.32.5 في 27 July 2026. يتوفر أيضاً مسار يدوي إذا كنت تفضل عدم تمرير برنامج نصي إلى shell:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

لا ينشئ المسار اليدوي وحدة systemd أو مستخدم الخدمة، لذلك عليك إضافتهما بنفسك. يشرح الدليل الكامل لتشغيل Ollama على VPS خطوة إعداد الخدمة بالتفصيل.

حالات الفشل، والرسائل التي ستظهر

يرفض Ollama تحميل النموذج. يعرض ollama run سطرًا بهذا الشكل:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

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

لا يفشل llama.cpp، بل يصبح بطيئًا جدًا. يربط llama.cpp ملف GGUF بالذاكرة افتراضيًا، لذلك يبدأ حتى إذا كان الملف أكبر من RAM. بعد ذلك تنقل النواة الأوزان من القرص وإليه مع كل رمز، وينخفض التوليد إلى عدة ثوانٍ لكل رمز، بينما يصل استخدام القرص إلى 100 بالمئة. مرّر --no-mmap لفرض تخصيص فعلي للذاكرة، بحيث يفشل فورًا بدلًا من التدهور. عندما تتدخل النواة، يعرض dmesg السبب:

Out of memory: Killed process 1234 (llama-server)

لن يُحمّل ملف النموذج إطلاقًا. يعرض GGUF المبني لعائلة نماذج أحدث من محركك خطأ يذكر البنية التي لا يعرفها:

error loading model architecture: unknown model architecture: 'qwen3next'

الحل هو ترقية المحرك، وليس استخدام ملف مختلف. هذه هي تكلفة تثبيت الإصدار، ولذلك يجب أن تدوّن رقم البناء. تحتاج إلى معرفة الإصدار الذي ستُرقي منه.

تستجيب API محليًا، لكنها لا تستجيب من تطبيقك. يربط Ollama الخدمة على 127.0.0.1:11434، لذلك يحصل مضيف آخر على رفض للاتصال. اضبط OLLAMA_HOST=0.0.0.0:11434 عبر systemctl edit ollama فقط عندما يكون المنفذ خلف جدار ناري أو شبكة خاصة، لأن API لا تملك مصادقة أمامها.

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

إذن، أيّهما ينبغي أن تستخدم؟

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

استخدم llama.cpp مباشرةً عندما تكون الذاكرة محدودة بما يكفي لتحتاج إلى اختيار صف quantisation بنفسك، أو عندما تريد /health و/slots و/metrics للمراقبة، أو عندما تحتاج إلى خيار لا يتيحه Ollama. وهذا هو الخيار الصريح على VPS بالكاد يتسع للنموذج، لأن الإعدادات التي تجعله مناسبًا هي نفسها التي يختارها Ollama نيابةً عنك.

من الطبيعي تشغيل كليهما. استخدم Ollama للتجارب، وllama.cpp للنموذج الوحيد الذي تضعه في بيئة الإنتاج ولا تريد أن يتغير.

FAQ

هل Ollama مجرد غلاف حول llama.cpp؟

إلى حد كبير، لكن الغلاف ينفذ مهام فعلية. يذكر ملف README الخاص بـ Ollama أن llama.cpp هو خلفية الاستدلال الخاصة به (وفقًا للتحقق في 2 أغسطس 2026). يضيف Ollama فوقه سجلًا للنماذج، وقالبًا للموجه يحول رسائل الدردشة إلى موجه، ومجموعة من معلمات أخذ العينات الافتراضية، وخدمةً تفرغ النماذج غير النشطة، وواجهة HTTP. عند مقارنة عدد الرموز في الثانية باستخدام الإعدادات نفسها، فأنت تقارن المحرك نفسه بنفسه. الاختيار الفعلي يكون بين طبقتي الإدارة.

أيهما أسرع على VPS يعمل على CPU فقط؟

يشتركان في المحرك، لذلك تكون النتائج متقاربة عند استخدام ملف النموذج نفسه، ومستوى التكميم نفسه، وحجم السياق نفسه، وعدد الخيوط نفسه. عادةً ما تنتج الفروق التي يبلغ عنها المستخدمون عن إعدادات افتراضية مختلفة، وغالبًا عن طول السياق وعدد الخيوط، لا عن المحرك. قِس الأداء باستخدام llama-bench -m <file> -p 512 -n 128، وقارن عمود tg على خادمك قبل تصديق أي رقم منشور.

هل يمكنني استخدام ملف GGUF الخاص بي مع Ollama؟

نعم. ضع الملف على الخادم، واكتب ملف Modelfile يكون سطره الأول FROM ./your-model.gguf، وأضف أي أسطر PARAMETER تحتاج إليها، مثل num_ctx، ثم شغّل ollama create your-name -f ./Modelfile. سيسرده ollama ls إلى جانب أي نموذج سحبته من السجل. بهذه الطريقة تستخدم مستوى تكميم لا يوفره السجل.

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

احسب حجم الملف، وأضف إليه ذاكرة التخزين المؤقت KV وذاكرة وقت التشغيل. يبلغ حجم إصدار Q4_K_M من Llama 3.1 8B نحو 4.58 GiB على القرص، ويضيف سياق من 4096 رمزًا نحو 512 MiB من ذاكرة التخزين المؤقت. لذلك تكون سعة RAM البالغة 8 GiB مناسبة، بينما لا تكفي سعة 4 GiB. تتناسب ذاكرة التخزين المؤقت مع حجم السياق. يحتاج النموذج نفسه عند استخدام سياق من 32,768 رمزًا إلى نحو 4 GiB من ذاكرة التخزين المؤقت بمفرده. مع Ollama، تذكر أن المتطلب يتناسب أيضًا مع OLLAMA_NUM_PARALLEL.