vLLM مقابل Ollama هو السؤال الذي تطرحه على نفسك في اللحظة التي يتوقف فيها الذكاء الاصطناعي المحلي عن كونه تجربة شخصية، ويبدأ في خدمة آخرين. وكلا الأداتين تعملان على نفس النماذج المفتوحة المصدر على عتادك الخاص، لكن الفرق يكمن في ما تُحسِّنانه: فـOllama يركِّز على راحة المستخدم الفردي، بينما يركِّز vLLM على التعامل مع طلبات متعددة في وقت واحد عبر وحدة معالجة الرسومات (GPU).
Quick answer
استخدم Ollama للأغراض الشخصية، ومرحلة التطوير، والأدوات الداخلية الصغيرة — فهو يُثبَّت خلال دقيقة واحدة، ويمكنه تشغيل أي نموذج يسمح به جهازك. استخدم vLLM عندما يتوجَّه عددٌ من المستخدمين أو الوكلاء إلى النموذج في وقت واحد: إذ يوفِّر نظام التجميع المتواصل (continuous batching) وإدارة الذاكرة عبر تقنية PagedAttention من vLLM معدل إنتاجية أعلى بعدة مرات مقارنةً بأي خادم بسيط يعمل على نفس وحدة معالجة الرسومات (GPU). والمقايضة هنا تتعلَّق بالتكوين — إذ يتطلَّب vLLM نظام تشغيل لينكس، ووحدة معالجة رسومات من شركة إنفيديا (NVIDIA)، وكمية كافية من الذاكرة المخصصة للرسومات (VRAM) لتشغيل النموذج دون تكميم (unquantised).
مقارنة سريعة بين vLLM وOllama
| Ollama | vLLM | |
|---|---|---|
| مُصمَّم خصيصًا لـ | مستخدم واحد، تطوير محلي | تشغيل إنتاجي، مستخدمون متزامنون عديدون |
| التزامن | يتعامل مع عدد قليل من الطلبات المتوازية | التجميع المتواصل — عشرات إلى مئات الطلبات |
| استراتيجية إدارة الذاكرة | تخصيص ذاكرة قياسي وفقًا لـ llama.cpp | تقنية PagedAttention — تقليل هدر ذاكرة KV-cache بشكل كبير |
| النماذج النموذجية | نماذج مكمَّمة بصيغة GGUF (4 بت فما فوق) | نماذج كاملة الدقة أو مكمَّمة باستخدام AWQ/GPTQ |
| العتاد | وحدات معالجة مركزية (CPU)، شرائح أبل (Apple Silicon)، إنفيديا (NVIDIA)، إيه إم دي (AMD) | وحدة معالجة رسومات من إنفيديا (NVIDIA GPU) (على نظام لينكس أساسًا) |
| مدة التكوين | دقائق | أطول — بيئة بايثون، CUDA، إعدادات تكوينية |
| واجهة برمجة التطبيقات (API) | متوافق مع واجهة برمجة تطبيقات OpenAI، المنفذ 11434 | خادم متوافق مع OpenAI |
| الأفضل ملاءمةً | أجهزة لابتوب، أجهزة سطح مكتب، خوادم منزلية | خوادم وحدات معالجة رسومات مستأجرة أو مملوكة |
لماذا يكون vLLM أسرع تحت الأحمال المرتفعة؟
الفرق الجوهري لا يكمن في سرعة تنفيذ طلب واحد فقط، بل في ما يحدث عندما تصل الطلبات معًا. فـ التجميع المتواصل (continuous batching) يُضيف الطلبات الجديدة إلى دفعة قيد التشغيل بدل انتظار انتهاء الدفعة الحالية، وبالتالي لا تتوقف وحدة معالجة الرسومات (GPU) عن العمل بين استقبال الموجهات. أما تقنية PagedAttention فتخصص ذاكرة KV cache على شكل صفحات صغيرة، تمامًا كما تدير أنظمة التشغيل الذاكرة، مما يلغي معظم الهدر الناتج عن تجزئة الحمل العملي عند السياقات الطويلة. وعلى نفس وحدة معالجة الرسومات (GPU)، غالبًا ما تترجم هاتان الفكرتان إلى زيادة تتجاوز عدة مرات في عدد الرموز (tokens) المُنتَجة في الثانية عبر نقطة نهاية مشغَّلة بكثافة.
أما Ollama فيقدِّم مقايضة عكسية عمدها. فهو يفترض وجود مستخدم واحد فقط، ويحافظ على بساطة تخصيص الذاكرة، ويُفضِّل افتراضيًّا النماذج المكمَّمة حتى تتمكن الأوزان الكبيرة من العمل على أجهزة عادية، ويظل بعيدًا عن طريقك. وهذا التصميم هو الأنسب لأجهزة اللابتوب أو الخوادم المنزلية، لأن وحدة معالجة الرسومات (GPU) تكون عادةً غير نشطة معظم الوقت أصلًا.
السؤال الخاطئ الذي يطرحه الناس حول الذاكرة
كفاءة vLLM تتعلق بالذاكرة المؤقتة (cache)، وليس بالأوزان. فهو عادةً ما يشغل النماذج بدقة أعلى من الدقة الافتراضية 4 بت التي يستخدمها Ollama، وبالتالي قد يتطلَّب نفس النموذج كمية أكبر بكثير من الذاكرة المخصصة للرسومات (VRAM) قبل أن يُنجَز طلب واحد. فقد يتناسب نموذج بحجم 70 مليار معلَّمة (70B) مع محطة عمل ذات 48 غيغابايت من VRAM عند استخدام Ollama، بينما قد يحتاج في المقابل إلى عقدة متعددة وحدات معالجة رسومات (multi-GPU node) عند استخدام vLLM. لذا، حدد مواصفات العتاد وفق الدقة التي تنوي تقديم النموذج بها — فـ حاسبة الذاكرة المخصصة للرسومات (VRAM) حاسبة الذاكرة المخصصة للرسومات (VRAM) حاسبة مقارنة بين الاستضافة الذاتية وواجهات برمجة التطبيقات (API) حاسبة المقارنة بين الاستضافة الذاتية وواجهة برمجة التطبيقات (API)
Convly’s take
لا تختار بين الأداتين، بل استخدمهما بالتسلسل. ابدأ بتجريب النموذج على Ollama لأن سرعة التكرار أهم من معدل الإنتاجية في المرحلة التي لم تُقرِّر فيها بعد ما تريد بناءه. ثم انتقل إلى vLLM في اللحظة بالضبط التي يظهر فيها مستخدم ثانٍ متزامن، لأن هذه هي اللحظة التي يبدأ فيها التجميع المتواصل في تعويض الجهد الإضافي المبذول في التكوين. وأكثر الأخطاء شيوعًا التي نراها هي قيام الفرق بتشغيل حركة مرور إنتاجية عبر أداة صُمِّمت لمستخدم واحد، ثم الاستنتاج بأن وحدة معالجة الرسومات (GPU) بطيئة جدًّا، في حين أن المشكلة الحقيقية تكمن في جدولة الطلبات.
الأسئلة الشائعة
هل يفوق vLLM أداء Ollama؟
نعم، تحت الأحمال المتزامنة — وغالبًا ما يكون الفارق عدة مرات بفضل التجميع المتواصل وتقنية PagedAttention. أما بالنسبة لطلب واحد فقط وبنفس مستوى التكميم، فإن الفارق يكون أصغر بكثير، وفي حالة أجهزة اللابتوب يكون Ollama عادةً الأسرع تشغيلًا.
هل يمكن لـ vLLM التشغيل على جهاز كمبيوتر محمول؟
نادرًا ما يعمل ذلك بطريقة مفيدة. يستهدف vLLM أنظمة لينكس المزوَّدة بوحدة معالجة رسوميات من شركة إنفيديا (NVIDIA) وبكمية كافية من الذاكرة عالية السرعة VRAM لمعالجة الأوزان بدقة أعلى؛ أما وحدات معالجة الرسوميات المدمجة في أجهزة الكمبيوتر المحمولة أو معالجات آبل سيليكون فهي خارج نطاق عمله الأمثل. وفي هذه الحالة، يُعد Ollama الأداة الأنسب.
هل يدعم vLLM النماذج المُكمَّنة (Quantised Models)؟
نعم — فالمقاييس مثل AWQ وGPTQ وأشكالها المشابهة مدعومة، ما يقلِّل متطلبات الذاكرة VRAM بشكلٍ كبير. ولا يستخدم vLLM نظام GGUF الخاص بـ Ollama، وبالتالي يجب تنزيل إصدارات مختلفة من نفس النموذج.
أيُّهما يمتلك واجهة برمجة تطبيقات (API) أفضل؟
كلا النظامين يقدِّم واجهات نهاية متوافقة مع واجهة OpenAI، لذا فإن كود العميل قابل للنقل بينهما دون تعديل. ويبدأ خادم Ollama تلقائيًّا عند تشغيل الجهاز، بينما يُفعَّل خادم vLLM لكل نشر على حدة، مع تحديد صريح للمعلمات الخاصة بالنموذج والدقة ودرجة التوازي عبر العلمات (flags).
لمقارنة أكثر من نموذجين، راجع مقارنة Ollama مع LM Studio مقابل vLLM مقابل llama.cpp، أو المقال المركَّز على أجهزة سطح المكتب Ollama مقابل LM Studio.
