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

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

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

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

ما هي 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 خادم للاستدلال، ولا يقدّم أي وظيفة أخرى. لا يدير مكتبة نماذج، ولا يحتوي على مطالبة محادثة، ولا ينزّل نموذجًا لك أثناء الطلب. تحدد مستودعًا على Hugging Face عند التشغيل، فيحمّل ذلك النموذج فقط ويقدّمه حتى توقف العملية.

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

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

المعالجة الدفعية المستمرة هي العامل الحاسم

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

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

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

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

التثبيت والتقديم باستخدام 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 عدد الرموز الفعلي الذي تتم معالجته في الثانية على ذلك الخادم. اعتمد عليه بدلًا من أي رقم منشور.

لرفع التزامن، استخدم ملف إسقاط لـ 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 بطيء.

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

يتطلب vLLM نظام Linux وPython من الإصدار 3.10 إلى الإصدار 3.13. ثبّته في بيئة افتراضية خاصة به، لأنه يثبّت إصدارًا محددًا من PyTorch:

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

بعد ذلك، قدّم نموذجًا. الاسم هو معرّف مستودع على Hugging Face، وليس وسمًا مختصرًا:

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

يستغرق بدء التشغيل وقتًا طويلًا في المرة الأولى، لأنه ينزّل الأوزان ثم يجري توصيفًا لوحدة GPU لتحديد عدد كتل ذاكرة التخزين المؤقت KV التي تتسع لها. يستمع على المنفذ 8000. تحقّق منه قبل كتابة أي شيفرة للعميل:

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 مثبتًا بالفعل على الخادم، فإن الصورة الرسمية تتجنب العمل المتعلق بتبعيات 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 الموترات بين العمليات عبر الذاكرة المشتركة، ويكون تخصيص Docker الافتراضي للذاكرة المشتركة صغيرًا جدًا للاستدلال المتوازي على مستوى الموترات.

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

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

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

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

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

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

العتاد: ما يحتاجه كل منهما

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

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

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

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

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

حالات الفشل، مع النصوص التي ستراها

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

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 يعالجها بالتتابع. ارفع قيمته واقبل بسياق أصغر لكل طلب، أو انقل الحمل إلى vLLM.

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

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

تشغيل كليهما إجابة معقولة

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

FAQ

هل vLLM أسرع من Ollama؟

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

هل يمكن لـ vLLM العمل من دون وحدة GPU؟

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

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

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

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

بدقة 16 بت، تحتاج الأوزان وحدها إلى نحو 16 GB، أي ما يقارب 2 GB لكل مليار معلمة، كما تحتاج ذاكرة KV cache إلى مساحة إضافية. تكون بطاقة بسعة 24 GB مناسبة. أما بطاقة بسعة 16 GB فتتطلب نقطة تحقق كمية أو نموذجًا أصغر. يحدّد 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.