Ollama أم vLLM: أي خادم LLM تختار؟

Ollama مقابل vLLM، في فقرة واحدة

Ollama هو مدير نماذج مرفق به خادم: ينزّل الأوزان المكمّمة، ويحمّلها، ويجيب عبر 127.0.0.1:11434، باستخدام CPU إذا كان هذا هو المورد الوحيد المتاح على الجهاز. أما vLLM فهو محرك لزيادة معدل المعالجة: يحافظ على تشغيل GPU بأقصى استفادة عبر معالجة طلبات كثيرة في الوقت نفسه، ولذلك فهو الأداة غير المناسبة على جهاز لا يحتوي على GPU. هذا هو القرار بأكمله. تحدث شخص واحد مع مساعد محلي هي مهمة Ollama. أما تطبيق يخدم فريقاً فهي مهمة vLLM.

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

ماهيّة Ollama الفعلية

Ollama طبقة لتسهيل الاستخدام. فهي توفر سجل نماذج (ollama pull llama3.1:8b)، ومخزناً محلياً للأوزان، وموجهاً لطلبات المحادثة، وخدمة systemd، وواجهة HTTP API، من خلال أمر تثبيت واحد. والنماذج التي تشغّلها هي ملفات GGUF، وتكون عادةً مكمّمة إلى 4 بت. لذلك يشغل نموذج 7B أو 8B نحو 5 GB على القرص بدلاً من 16 GB. وتتيح الكمّية الاستدلال باستخدام CPU أساساً.

يعتمد المشغّل على llama.cpp، وهي مكتبة استدلال بلغة C++ جعلت تكميم GGUF عملياً على الأجهزة العادية. وقد أضافت Ollama منذ ذلك الحين محرّكها الخاص لبعض عائلات النماذج الأحدث، لكن llama.cpp لا تزال الطبقة الأساسية لمعظم ما تشغّله. لذلك، عند مقارنة Ollama بـ llama.cpp، تكون المقارنة في الغالب بين طبقة لتحسين سهولة الاستخدام والمكوّن الذي تغلّفه.

يستهدف التصميم مستخدماً واحداً. اعتباراً من July 2026، تكون القيمة الافتراضية لـ OLLAMA_NUM_PARALLEL هي 1، ما يعني أن نموذجاً واحداً يعالج طلباً واحداً في كل مرة، بينما تنتظر الطلبات الأخرى في قائمة انتظار تتسع افتراضياً لـ 512 إدخالاً (OLLAMA_MAX_QUEUE). يمكنك زيادة إعداد التوازي، ويوضح القسم أدناه تكلفته. إذا لم تكن قد شغّلت Ollama من قبل، فابدأ بقراءة استضافة Ollama على VPS وإبقاء المنفذ 11434 مغلقاً، لأن واجهة API لا توفر أي نوع من المصادقة.

ما هو vLLM فعلياً

vLLM هو خادم استدلال لا أكثر. لا يدير مكتبة نماذج، ولا يحتوي على prompt للمحادثة، ولن يسحب نموذجاً نيابةً عنك عند وقت الطلب. تحدد مستودعاً على Hugging Face عند بدء التشغيل، فيحمّل ذلك النموذج الواحد ويقدمه حتى توقف العملية.

ما تحصل عليه مقابل هذا النطاق المحدود هو معدل نقل مرتفع. وتنفذ آليتان العمل. تخزّن PagedAttention ذاكرة KV المؤقتة (ذاكرة key-value المؤقتة، وهي حالة الانتباه لكل token التي يحتفظ بها النموذج لكل طلب نشط) في كتل ثابتة الحجم، مثلما يجزّئ نظام التشغيل الذاكرة إلى صفحات. لم يعد الطلب يحتاج إلى حجز متصل وكبير بحجم أسوأ حالة محتملة، لذلك تصبح الذاكرة التي كانت محجوزة وغير مستخدمة متاحة لمزيد من الطلبات المتزامنة. وتسمح Continuous batching بانضمام طلب جديد إلى الدفعة قيد التشغيل في خطوة فك الترميز التالية، بدلاً من انتظار انتهاء الدفعة الحالية. وتغادر السلسلة المكتملة الدفعة فوراً، ثم يُعاد ملء موضعها.

النتيجة العملية: على GPU واحد، يؤدي الانتقال من مستخدم متزامن واحد إلى ثلاثين مستخدماً إلى زيادة كبيرة في إجمالي عدد tokens في الثانية، بينما تنخفض السرعة لكل مستخدم بدرجة أقل بكثير مما قد تتوقع. في الإعداد الافتراضي لـOllama، يؤدي الانتقال من مستخدم واحد إلى ثلاثين مستخدماً فقط إلى جعل 29 شخصاً ينتظرون.

الـContinuous batching هو الفارق الأساسي

تخيّل وصول خمسة طلبات إلى كل خادم في اللحظة نفسها، على أجهزة متطابقة.

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

يفكك vLLM جميع الطلبات الخمسة في عملية forward pass واحدة. لا تكلف عملية توليد token واحد لخمسة تسلسلات أكثر بكثير من توليد token واحد لتسلسل واحد، لأن الجزء المكلف هو قراءة أوزان النموذج من الذاكرة، وتتم مشاركة هذه القراءة بين عناصر الدفعة كلها. هذه هي حقيقة عرض نطاق الذاكرة نفسها التي تجعل الاستدلال باستخدام CPU بطيئاً: أنت تدفع تكلفة نقل الأوزان، لا تكلفة العمليات الحسابية.

يمكنك ضبط OLLAMA_NUM_PARALLEL=4 والاستفادة من جزء من ذلك. لكن التكلفة هي الذاكرة. تحتاج كل خانة متوازية إلى KV cache خاص بها، ويقسّم Ollama نافذة السياق بين الخانات. لذلك، تؤدي أربعة طلبات متوازية إلى نموذج مضبوط على 8192 token إلى ترك 2048 token من السياق لكل طلب. وقيمة 8192 نفسها خيار وليست قيمة مفروضة، لذا فإن رفع num_ctx وتحديد حجم RAM الذي يتطلبه هو ما يحدد ما إذا كانت أربع خانات قابلة للاستخدام أصلاً. يتجنب الـpaged cache في vLLM هذه المفاضلة، لأن الكتل تُخصَّص للطلب مع نموه الفعلي. في كلتا الحالتين، يعتمد الحد الأقصى لعدد الأشخاص الذين يستطيع جهاز واحد خدمتهم في الوقت نفسه على حجم KV cache، وتكلفة prefill، وعمق قائمة الانتظار. وهذا هو سبب تباطؤ خادم كان يعمل جيداً لشخص واحد عند خمسة أشخاص.

التثبيت والتشغيل باستخدام Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

ينشئ برنامج التثبيت مستخدم نظام ollama، ويثبّت الملف الثنائي، ويسجّل ollama.service المرتبط بـ127.0.0.1:11434. يمثّل السطر eval rate الذي يطبعه --verbose معدل الرموز الحقيقي في الثانية على ذلك الخادم. اعتمد عليه بدلاً من أي رقم منشور. تُعد قراءة واحدة من مطالبة واحدة نقطة بداية، وليست رقماً للسعة. لذلك فإن قياس معدل الرموز في الثانية عبر مجموعة من مستويات التزامن هو ما يوضح قدرة الخادم على تحمل الحمل المتوقع فعلياً، وما إذا كان استئجار GPU أفضل من الدفع لكل رمز.

لرفع مستوى التزامن، استخدم drop-in لـsystemd حتى لا يستبدل التحديث هذا التغيير:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

يوضح ollama ps ما تم تحميله، ويعرض عمود PROCESSOR الحقيقة. يعني 100% CPU عدم استخدام GPU، وهذا هو التفسير الفعلي لمعظم التقارير التي تفيد بأن Ollama بطيء. يكتسب السطر OLLAMA_KEEP_ALIVE=30m في ملف drop-in أهمية مماثلة على الخادم غير النشط، لأن الإعداد الافتراضي يفرغ النموذج بعد خمس دقائق من دون أي طلب. أما إبقاء النموذج مقيماً بين الطلبات فيمنع المطالبة الأولى بعد ساعة من الخمول من دفع زمن التحميل الكامل مرة أخرى.

التثبيت والتشغيل باستخدام vLLM

يتطلب vLLM نظام Linux وPython من الإصدار 3.10 إلى الإصدار 3.13. ثبّته في virtual environment مستقل، لأنّه يثبّت إصداراً محدداً من PyTorch:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

ثم شغّل model. الاسم هنا هو معرّف repository في Hugging Face، وليس tag مختصراً:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

يستغرق بدء التشغيل وقتاً أطول في المرة الأولى، لأنّه ينزّل weights ثم يجري profiling لـGPU لتحديد عدد كتل KV cache التي يمكن أن تتسع لها. يستمع إلى port 8000. تحقّق منه قبل كتابة أي client code:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

إذا كان Docker مثبتاً على الخادم، فتتجنب image الرسمية أعمال إعداد تبعية CUDA:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

يُعد --ipc=host مطلوباً وليس للزينة: يمرّر PyTorch tensors بين العمليات عبر shared memory، ويكون تخصيص Docker الافتراضي للذاكرة المشتركة صغيراً جداً بالنسبة إلى inference المتوازي على tensors.

أهم flags في بيئة production هي --max-model-len، أي نافذة السياق التي تقبل دفع تكلفتها، و--gpu-memory-utilization، أي النسبة التي يُسمح لـvLLM باستخدامها من ذاكرة GPU، وتبلغ 0.92 افتراضياً اعتباراً من July 2026، و--tensor-parallel-size لتقسيم model واحد على عدة GPUs، و--api-key.

المصادقة خيار واحد في vLLM وغير متاحة في Ollama

يفرض vLLM رمز bearer token إذا زوّدته به:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

يمكن أيضاً الحصول على القيمة نفسها من متغير البيئة VLLM_API_KEY. يحصل الطلب الذي لا يتضمنها على استجابة HTTP 401. لكن هذا لا يبرر الاستماع على المنفذ 8000 عبر واجهة عامة، لأن vLLM لا يوفّر تحديداً لمعدل الطلبات، ولأن قراءة الرمز المرسل عبر HTTP عادي ممكنة أثناء النقل. مع ذلك، فهذا يعني أن الخادم يميّز بين الجهة التي تجري الطلب.

لا يوفّر Ollama أي آلية مصادقة. لا يوجد مفتاح، ولا تسجيل دخول، ولا قائمة سماح. يمكن لأي عملية تصل إلى 11434 تشغيل النماذج أو سحبها أو حذفها. أبقه على loopback، واتصل به عبر شبكة WireGuard VPN تستضيفها بنفسك، أو عبر Reverse Proxy يطبّق المصادقة وينهي TLS (أمان طبقة النقل).

المتطلبات العتادية لكل خيار

يعمل Ollama على CPU. يستهلك النموذج المكمَّم إلى 4-bit نحو نصف غيغابايت من RAM لكل مليار مَعلمة، إضافة إلى نحو غيغابايت واحد من الحمل التشغيلي ومساحة أكبر للسياق. لذلك يحتاج نموذج 3B إلى نحو 4 GB من الذاكرة الحرة، بينما يحتاج نموذج 8B إلى نحو 8 GB. تتراوح السرعة على vCPU مشترك بين رقم أحادي ورقمين منخفضين من الرموز في الثانية. هذا ناتج عن عرض نطاق الذاكرة، وليس عن خطأ في الإعداد، ولا يصلحه أي flag. ولمراقبة هذه الحسابات على إصدار محدد بدلاً من الاعتماد على قاعدة تقريبية، يحدد تشغيل Nemotron 3.5 Lightning على VPS الوسم الدقيق الذي يجب تنزيله، وحجم RAM الذي يشغله بعد تحميله، وما إذا كانت السرعة باستخدام CPU فقط مقبولة للاستخدام اليومي.

يفترض vLLM وجود GPU. يقدّم مساره الافتراضي الأوزان غير المكمَّمة بدقة 16-bit، أي نحو 2 GB لكل مليار مَعلمة. لذلك يحتاج نموذج 8B إلى نحو 16 GB من ذاكرة الفيديو للأوزان وحدها، قبل إضافة ذاكرة KV cache التي توفّر التزامن الذي ثبّتَّ vLLM من أجله. تترك بطاقة بسعة 24 GB مساحة عملية لـKV cache. أما بطاقة بسعة 16 GB فلا تفعل ذلك، ولذلك تختار نموذجاً أصغر أو تمرر --quantization مع checkpoint مكمَّم. يتوفر backend لـCPU، لكن standard wheels لا تُبنى له، كما أنه يلغي سبب تشغيل vLLM من الأساس.

لذلك يجيب العتاد عن سؤال البرمجيات في معظم الحالات. إذا لم يكن لديك GPU، فاستخدم Ollama. وإذا كان لديك GPU مستأجر ولا يتجاوز استخدامه 5 بالمئة لأن الطلبات تُنفَّذ بالتسلسل، فاستخدم vLLM.

ما الخيار المناسب لأعباء العمل لديك

• مستخدم واحد، وVPS مزوّد بوحدة CPU، لإنشاء المسودات والتلخيص: Ollama. سرعته مقبولة، ولا يوجد خيار أبسط.
• مساعد برمجي، أو خادم MCP يربط أدواتك بنموذج محلي، لا تستدعيه إلا أنت: Ollama. التزامن بمقدار واحد هو عبء العمل الفعلي.
• مقارنة خمسة نماذج هذا الأسبوع: Ollama. سحب النماذج المعلّمة وحذفها هو بالضبط ما يجيده، بينما يحتاج vLLM إلى إعادة تشغيل العملية لكل نموذج.
• تطبيق داخلي، أو منتج محادثة، أو مسار استرجاع يستخدمه مستخدمون فعليون: vLLM. هنا تحقق المعالجة الدفعية قيمة تكلفة GPU.
• مهمة دفعية تقيّم مئة ألف مستند خلال الليل: vLLM، مع قيمة --max-num-seqs مرتفعة. الإنتاجية هي المقياس الوحيد المهم، أما زمن الاستجابة لكل مستند فليس مهماً.
• منصة وكلاء تستدعي فيها عدة وكلاء ذكاء اصطناعي مستضافين ذاتياً النموذج في الوقت نفسه: vLLM، لأن حركة الوكلاء متقطعة بطبيعتها ومتوازية بطبيعتها.

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

يرفض vLLM البدء بسبب خطأ في ذاكرة KV cache. تعرض الرسالة الرقمين معاً:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

يعرّف النموذج نافذة سياق أكبر من الذاكرة المتبقية بعد تحميل الأوزان. خفّضها باستخدام --max-model-len 8192، أو ارفع --gpu-memory-utilization إذا لم تكن هناك عملية أخرى تستخدم البطاقة. يؤدي رفع نسبة الاستخدام إلى ما بعد 0.95 تقريباً غالباً إلى استبدال خطأ بدء التشغيل بتعطل لاحق بسبب نفاد ذاكرة CUDA تحت الحمل. وهذا أسوأ من الخطأ الأول.

يطبع Ollama Killed أثناء إنشاء النص. أوقف قاتل نفاد الذاكرة في Linux العملية لأن النموذج احتاج إلى RAM أكبر من المتاح على الخادم. أكّد ذلك باستخدام sudo dmesg | grep -i oom. الحل هو استخدام نموذج أصغر أو نموذج ذي تكميم أعلى، وليس تغيير إعداد.

يجيب Ollama بشكل طبيعي عند تشغيله منفرداً، لكنه يتوقف تحت الحمل. لا يظهر أي خطأ في أي مكان. تستغرق الطلبات وقتاً أطول كلما زاد عدد المتصلين، لأن OLLAMA_NUM_PARALLEL=1 يعالجها بالتسلسل. تجعل الإجابات الطويلة قائمة الانتظار أسوأ، لأن متصلاً واحداً يحتفظ بالفتحة الوحيدة حتى يقرر النموذج التوقف، فيحظر جميع الطلبات التي تليه. لذلك يضع تحديد الرد باستخدام num_predict حداً لمدة احتفاظ أي دور واحد بالخادم. ارفع إعداد المعالجة المتوازية واقبل سياقاً أصغر لكل طلب، أو انقل عبء العمل إلى vLLM.

يعيد vLLM الحالة 401 مع كل طلب. شغّلته باستخدام --api-key، لكن العميل لا يرسل ترويسة Authorization. ترسل معظم مكتبات عميل OpenAI القيمة التي تمررها كمفتاح، لذا اضبطها في العميل بدلاً من حذف الخيار.

يقول vLLM إن النموذج غير موجود. ينزّل Ollama النماذج عند الطلب، أما vLLM فلا يفعل ذلك. يجب أن يطابق الحقل model في نص الطلب معرّف المستودع الذي شغّلت به vLLM، أو قيمة --served-model-name إذا عيّنتها. أكّد السلسلة النصية الدقيقة باستخدام curl http://localhost:8000/v1/models.

تشغيل كليهما إجابة مناسبة

لا يستبعد أحدهما الآخر. من النماذج الشائعة تشغيل vLLM على instance مزوّد بـGPU لخدمة التطبيق، وتشغيل Ollama على VPS عادي إلى جانبه لتشغيل النصوص البرمجية المحلية، ومهام cron، وتجربة إصدارات النماذج الجديدة. تتوافق نقطتا النهاية مع OpenAI، لذلك تكفي مكتبة عميلة واحدة وتبديل base URL لاستخدامهما. التحكم في التكلفة أهم هنا من اختيار أيٍّ من المحركين، لأن GPU الخامل يُحاسَب بالسعر نفسه الذي يُحاسَب به GPU المشغّل، كما أن إبقاء تكاليف الوكلاء والاستدلال قابلة للتنبؤ مجال منفصل عن اختيار الخادم.

FAQ

هل vLLM أسرع من Ollama؟

بالنسبة إلى طلب واحد على وحدة GPU نفسها، يكون الفرق محدوداً، لأن كليهما ينفّذ العمليات الحسابية نفسها. أما مع الطلبات المتزامنة الكثيرة، فيتقدم vLLM بفارق كبير، لأن التجميع المستمر يفك ترميز كل تسلسل نشط في تمريرة أمامية واحدة، بينما ينفذ الإعداد الافتراضي في Ollama الطلبات واحداً تلو الآخر. على جهاز يعمل بالمعالج المركزي فقط، لا ينطبق هذا السؤال؛ إذ يعمل Ollama هناك، بينما لا يعمل vLLM عملياً.

هل يمكن تشغيل vLLM من دون وحدة GPU؟

ليس بطريقة مفيدة. تستهدف الحزم القياسية وحدات GPU من NVIDIA أو AMD، وتختفي على المعالج المركزي الفائدة الأساسية من vLLM، وهي إبقاء مسرّع العمليات مشبعاً بالطلبات المجمّعة. يتوفر backend للمعالج المركزي لأعمال التطوير. أما للاستدلال الفعلي على المعالج المركزي، فاستخدم Ollama أو llama.cpp مباشرة.

ما الفرق بين Ollama وllama.cpp؟

llama.cpp هي مكتبة الاستدلال، وGGUF هو تنسيق الأوزان المكمّمة الخاص بها. يعتمد مشغّل Ollama عليها، ويضيف الأجزاء التي يتركها llama.cpp لك: سجل النماذج، والتنزيل التلقائي، وخادماً مقيماً، ووحدة systemd، ونقطة نهاية متوافقة مع OpenAI. أضاف Ollama محركه الخاص لبعض عائلات النماذج الأحدث، لذلك لم يعد الاثنان متطابقين في الطبقة الداخلية.

ما مقدار ذاكرة GPU التي يحتاج إليها vLLM لنموذج 8B؟

عند استخدام دقة 16-bit، تستهلك الأوزان وحدها نحو 16 GB، أي ما يقارب 2 GB لكل مليار معلمة، ويحتاج KV cache إلى مساحة إضافية. تكون بطاقة بسعة 24 GB مناسبة. أما بطاقة بسعة 16 GB فتتطلب checkpoint مكمّماً أو نموذجاً أصغر. يحجز vLLM جزءاً من سعة البطاقة تحدده --gpu-memory-utilization، وتبلغ قيمته الافتراضية 0.92 اعتباراً من July 2026.

هل أحتاج إلى تغيير رمز تطبيقي للتبديل بينهما؟

عادةً لا تحتاج إلا إلى تغيير عنوان URL الأساسي، ومفتاح API، واسم النموذج. يوفّر Ollama واجهته المتوافقة مع OpenAI على http://127.0.0.1:11434/v1 ويتجاهل المفتاح، بينما يوفّر vLLM واجهته على http://localhost:8000/v1 ويفرض استخدام المفتاح إذا ضبطت واحداً. تختلف أسماء النماذج من حيث الصيغة: llama3.1:8b في Ollama، ومعرّف مستودع كامل مثل Qwen/Qwen2.5-1.5B-Instruct في vLLM.