ما هو vLLM؟ دليل عملي لمحرك خدمة نماذج اللغات الكبيرة عالي الإنتاجية

vLLM هو محرك استنتاج وخدمة مفتوح المصدر لنماذج اللغات الكبيرة (LLMs). ويقوم بتحميل النموذج على وحدة معالجة رسومات واحدة أو أكثر، ويعريه عبر واجهة برمجة تطبيقات HTTP متوافقة مع OpenAI، مستفيدًا من تقنيتين رئيسيتين هما: PagedAttention والتجميع المستمر (continuous batching)، وذلك لخدمة عدد كبير من الطلبات المتزامنة بمعدل إنتاجية أعلى بكثير من طرق الخدمة البدائية. وقد تم تطويره في مختبر حوسبة السماء (Sky Computing Lab) التابع لجامعة كاليفورنيا في بيركلي، وأُعلن عنه عام 2023.

ما هو vLLM ولمن يُوجَّه؟

فكِّر في vLLM على أنه الحل المُوجَّه للبيئات الإنتاجية، مقابل أدوات سطح المكتب مثل Ollama. فكلاهما يستقبل نموذجًا ويُجيب عن الطلبات، لكن كلًّا منهما يركِّز على أهداف مختلفة. إذ يركِّز Ollama على تمكين شخص واحد من الحصول على استجابة فعالة على عتاد محدود الإمكانيات، بينما يركِّز vLLM على معدل الإنتاجية (throughput)إجمالي عدد الرموز (tokens) التي يتم توليدها في الثانية الواحدة عبر عشرات أو مئات الطلبات المتزامنة التي تصل إلى نفس وحدة معالجة الرسومات (GPU).

وهذا يجعل vLLM الأداة المناسبة عندما تكون:

• تشغيل نموذج لغوي كبير (LLM) خلف واجهة برمجة تطبيقات (API) داخلية أو عامة يستخدمها عدة أشخاص أو خدمات
• تشغيل مهام دفعية (Batch Jobs) — مثل التصنيف، والاستخراج، وتوليد البيانات الاصطناعية — على مجموعات بيانات كبيرة
• استبدال واجهة برمجة تطبيقات مدفوعة بنموذج مفتوح المصدر مُستضاف ذاتيًا لتقليل التكلفة لكل رمز (توكين)، حيث إن آلة حساب التعادل بين الاستضافة الذاتية وواجهة برمجة التطبيقات (self-hosting vs API break-even calculator) تساعدك في التحقق مما إذا كانت تكلفة وحدة معالجة الرسومات (GPU) تفوق فعليًّا تكلفة واجهة برمجة التطبيقات عند حجم الاستخدام الخاص بك)

وهو الأداة غير المناسبة عندما ترغب في الحصول على مساعد دردشة على جهاز الكمبيوتر المحمول الشخصي، أو إجراء استنتاجات فردية متقطعة، أو أي استخدام على جهاز لا يحتوي على وحدة معالجة رسومات قوية. إذ يفترض vLLM وجود خادم: نظام تشغيل لينكس، ووحدة معالجة رسومات من شركة إنفيديا (NVIDIA GPU) كمسار افتراضي (وتوجد دعائم لوحدات معالجة الرسومات من شركة AMD ROCm، وشركة إنتل، ومنصات TPU وCPU، لكنها أقل شيوعًا واستخدامًا)، وحمل عمل يتطلب تنفيذًا متوازيًا.

عند إطلاقه عام 2023، أظهرت مقاييس الأداء (benchmarks) الخاصة بـ vLLM أداءً يصل إلى 24 ضعف معدل الإنتاجية (throughput) مقارنةً بالخدمة المقدمة عبر مكتبة Hugging Face Transformers القياسية، وأكثر بحوالي 2–3.5 مرة من أنظمة الخدمة السائدة آنذاك. وتتفاوت الأرقام الدقيقة باختلاف النموذج والعتاد ونوع حمل العمل — لكن سبب هذه الفجوة يستحق الفهم، لأنه يوضح لك متى يكون استخدام vLLM ذا أهمية بالغة.

شرح مبسَّط لمفهوم PagedAttention

عندما يولِّد النموذج اللغوي الكبير (LLM) نصًّا، فإنه يحتفظ بـ ذاكرة التخزين المؤقت للمفاتيح والقيم (KV cache) ذاكرة التخزين المؤقت للقيم والمفاتيح الانتباهية (KV cache) في ذاكرة وحدة معالجة الرسومات (GPU memory): وهي تشمل مفاتيح الانتباه وقيم الانتباه لكل رمز في كل محادثة نشطة. وتزداد هذه الذاكرة المؤقتة مع كل رمز يتم توليده، وقد تستهلك في السياقات الطويلة مساحة أكبر من ذاكرة VRAM مقارنةً بأوزان النموذج نفسه.

قبل ظهور vLLM، كانت محركات الخدمة تخصص لكل طلب قطعة واحدة متصلة من الذاكرة بحجم يتناسب مع أقصى طول ممكن لتسلسل الإدخال/الإخراج، لأنها لم تكن تعرف مسبقًا كم سيكون طول المخرجات. وغالبًا ما تنتهي معظم الطلبات قبل الوصول إلى هذا الحد الأقصى، وبالتالي تظل معظم الذاكرة المحجوزة غير مستخدمة. وقد قاسَ بحث vLLM نسبة الهدر في ذاكرة التخزين المؤقت للقيم والمفاتيح الانتباهية (KV cache) في الأنظمة السابقة فوجد أنها تتراوح بين 60% و80% بسبب هذا النوع من التجزئة.

أما تقنية PagedAttention فهي تستعير الحل من أنظمة التشغيل: الترحيل الافتراضي للذاكرة (virtual memory paging). إذ تُقسَّم ذاكرة التخزين المؤقت للقيم والمفاتيح الانتباهية (KV cache) إلى كتل صغيرة ثابتة الحجم (16 رمزًا لكل كتلة افتراضيًا)، وتُخصَّص هذه الكتل عند الحاجة دون الحاجة إلى أن تكون متجاورة في الذاكرة. وتقوم جدول الكتل (block table) بربط المواضع المنطقية لكل تسلسل بتلك الكتل الفيزيائية المتاحة — تمامًا كما تقوم أنظمة التشغيل بربط الصفحات الافتراضية بالذاكرة العشوائية الفيزيائية (RAM). وبذلك ينخفض هدر الذاكرة إلى أقل من 4%، بل ويمكن مشاركة الكتل بين التسلسلات المختلفة (وهو أمر مفيد عند توليد عدة إكمالات من نفس الموجه).

والنتيجة العملية لذلك هي: إمكانية استيعاب عددٍ أكبر بكثير من التسلسلات المتزامنة في نفس مساحة ذاكرة VRAM. وكلما زاد عدد التسلسلات في الذاكرة، زاد حجم الدفعات الفعالة (effective batches)، وهذه الدفعات الأكبر هي ما يحافظ على انشغال وحدة معالجة الرسومات (GPU) بشكل مستمر. وهذه هي القصة الكاملة وراء ارتفاع معدل الإنتاجية (throughput) — إذ لا تجعل تقنية PagedAttention طلبًا واحدًا أسرع، بل تسمح بتشغيل عددٍ أكبر بكثير من الطلبات في وقت واحد.

التجميع المستمر (Continuous batching)

أما التقنية الثانية فتركّز على جدولة عمليات التنفيذ بدلًا من إدارة الذاكرة. فالتجميع البدائي (naive batching) يجمع الطلبات معًا، ثم ينفذ الدفعة بأكملها حتى الانتهاء، ثم يبدأ الدفعة التالية — وبالتالي ينتظر طلبٌ ينتهي بعد توليد 20 رمزًا حتى ينتهي طلب آخر يولّد 2000 رمز، بينما تبقى الطلبات الجديدة القادمة في قائمة الانتظار خارج الدفعة. التجميع المستمر (Continuous batching) (وتُعرف أيضًا باسم الجدولة على مستوى التكرار iteration-level scheduling) تعدّ تكوين الدفعة في كل خطوة توليد: فتخرج التسلسلات المنتهية فورًا، وتدخل الطلبات المُنتظرة فورًا.

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

خطوات تثبيت vLLM: القيود التي تسبب صعوبات للمستخدمين

يتطلب التثبيت أمرًا واحدًا فقط، لكن ثلاثة قيود تسبّب معظم حالات الفشل في التثبيت:

1. نسخة بايثون (Python version). تستهدف الإصدارات الحديثة نطاق نسخ بايثون 3.9–3.12 تقريبًا، ويختلف هذا النطاق المدعوم بين الإصدارات. فإذا أبلغك الأمر pip بعدم توفر توزيعة مطابقة، فإن نسخة بايثون لديك تكون أول ما يجب الشك فيه.
2. نسخة CUDA. إن حزم التثبيت الجاهزة (prebuilt wheels) مُجمَّعة ضد إصدار رئيسي معيّن من CUDA (مثل CUDA 12.x في الإصدارات الحالية). ولذلك تحتاج إلى أحدث تعريف لسائق إنفيديا (NVIDIA driver)، أما الحزم المبنية لإصدارات أخرى من CUDA فهي متوفرة في بعض الإصدارات عبر عناوين URL خاصة موثَّقة في وثائق vLLM.
3. تضارب إصدارات PyTorch. يُثبِّت vLLM إصدارًا محدَّدًا من مكتبة PyTorch. وإذا قمت بتثبيته في بيئة تحتوي بالفعل على إصدار مختلف من PyTorch، فهذه الطريقة الكلاسيكية التي تؤدي عادةً إلى أخطاء غامضة عند الاستيراد. لذا استخدم دائمًا بيئة افتراضية جديدة (fresh virtual environment).

من الناحية المادية، يتطلب المسار القياسي وحدة معالجة رسومات من إنفيديا (NVIDIA GPU) تدعم إمكانية الحوسبة (compute capability) 7.0 أو أعلى — مثل بطاقات V100 وT4 وسلسلة RTX 20 وما بعدها. وإذا كنت تختار العتاد، فراجع الدليل الخاص بأفضل وحدات معالجة الرسومات لتشغيل النماذج اللغوية الكبيرة محليًّا. أفضل وحدات معالجة الرسومات لتشغيل النماذج اللغوية الكبيرة محليًّا.

لينكس (نظام التشغيل المدعوم)

python3 -m venv vllm-env
source vllm-env/bin/activate
pip install vllm

كما توصي وثائق vLLM باستخدام أداة uv (uv venv ثم uv pip install vllm)، والتي تقوم بحل التبعيات المثبتة مسبقًا (pinned dependencies) بشكل أسرع. وفي كلتا الحالتين، فإن النقطة الأساسية هي ضرورة استخدام بيئة نظيفة.

نظام ويندوز: استخدم WSL2 أو Docker

لا يوجد إصدار أصلي لنظام ويندوز. أما طرق التشغيل الفعّالة فهي: WSL2 مع توزيعة أوبونتو (حيث يتيح سائق إنفيديا لوندوز تمرير تقنية CUDA إلى بيئة WSL2، لذا فإن تعليمات لينكس المذكورة أعلاه تعمل داخلها) أو Docker Desktop مع تمكين دعم وحدة معالجة الرسومات، وذلك باستخدام الصورة الرسمية:

docker run --gpus all -p 8000:8000 vllm/vllm-openai --model Qwen/Qwen2.5-7B-Instruct

نظام ماك أو إس: ليست الأداة المناسبة

لا يدعم vLLM واجهة Metal أو وحدات معالجة الرسومات من آبل. ويمكن تجميع إصدار تجريبي يعمل على وحدة المعالجة المركزية (CPU) من الكود المصدري، لكن ذلك يتناقض مع الغرض الأساسي من محرك عالي الإنتاجية (throughput engine). وعلى أجهزة ماك، استخدم LM Studio LM Studio

تشغيل الخادم: الأمر vllm serve

أمر واحد يكفي لبدء خادم الاستنتاج (ويتم تنزيل النموذج تلقائيًّا من Hugging Face عند التشغيل الأول):

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

وهذا يُفعّل الخدمة على المنفذ 8000. أما الخيارات (flags) التي ستستخدمها غالبًا فهي:

لاحظ أن vLLM يخصص مسبقًا معظم ذاكرة وحدة معالجة الرسوميات (VRAM) تصميميًّا — لذا فإن قراءة استخدام الـ VRAM بالقرب من السعة الكاملة أمرٌ طبيعيٌّ وليس تسريبًا. قبل اختيار النموذج، تأكَّد من أن حجم أوزانه بالإضافة إلى ذاكرة التخزين المؤقت للقيم الرئيسية (KV cache) يتناسب مع سعة بطاقتك الرسومية باستخدام حاسبة ذاكرة VRAM؛ كقاعدة تقريبية، تتطلب الأوزان بتنسيق FP16 حوالي 2 غيغابايت لكل مليار معلَّمة، بينما تتطلب الأوزان بتقنية 8-bit نحو نصف هذه الكمية، علاوةً على هامش إضافي لذاكرة التخزين المؤقت.

واجهة برمجة التطبيقات المتوافقة مع OpenAI

يُطبِّق الخادم واجهة برمجة التطبيقات (API) الخاصة بشركة OpenAI: /v1/chat/completions, /v1/completions, /v1/models، و /v1/embeddings (للنماذج المُولِّدة للتضمينات). وبالتالي، تعمل أي أدوات بُنِيَت على واجهة برمجة تطبيقات OpenAI دون تعديل، فقط عبر تغيير عنوان URL الأساسي:

curl http://localhost:8000/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{
    "model": "Qwen/Qwen2.5-7B-Instruct",
    "messages": [{"role": "user", "content": "اشرح مفهوم PagedAttention في جملة واحدة."}]
  }'

وفي لغة بايثون: OpenAI(base_url="http://localhost:8000/v1", api_key="none") هو التعديل الوحيد المطلوب للانتقال الكامل. وتُعَدُّ هذه التوافقية جزءًا كبيرًا من سبب انتشار vLLM: إذ تعمل أدوات ووكلاء وأطر العمل الحالية دون أي تعديل.

متى يكون Ollama أو llama.cpp الخيار الأفضل

اختر Ollama عندما يكون عدد المستخدمين واحدًا، والمعدات عبارة عن جهاز كمبيوتر محمول أو سطح مكتب — حيث يقتصر إعداده على برنامج تثبيت واحد، ويمكنه تشغيل نماذج GGUF المُكمَّنة بكفاءة على وحدات المعالجة المركزية وشرائح Apple Silicon (انظر دليل شامل لاستخدام Ollama). اختر llama.cpp بشكل مباشر عندما تحتاج إلى أقصى درجات إمكانية النقل، أو عندما ترغب في دمج عملية الاستنتاج داخل تطبيق آخر. اختر vLLM عندما تصل الطلبات بشكل متزامن، وعندما تكون المعيار المُستخدَم هو عدد الرموز المُولَّدة في الثانية مقابل كل دولار من التكلفة. ف workload ذو مستخدم واحد يستفيد قليلًا جدًّا من تقنية PagedAttention، بينما يستفيد workload مكوَّن من 50 مستخدمًا استفادةً هائلة.

الأسئلة الشائعة

هل vLLM مجاني؟

نعم. vLLM مفتوح المصدر بموجب رخصة Apache 2.0، وقد طوَّرته في الأصل جامعة كاليفورنيا في بيركلي، وهو الآن مشروع مجتمعي تابع لمؤسسة PyTorch. ولا توجد نسخة مدفوعة منه؛ أما تكاليفك فهي تقتصر على تكلفة الأجهزة والطاقة الكهربائية.

هل يمكن لـ vLLM تشغيل نماذج بصيغة GGUF كما يفعل Ollama؟

توجد دعم تجريبي لصيغة GGUF، لكنه ليس المسار المُقصود أو الموصى به. فقد صُمِّم vLLM أساسًا ليتعامل مع ملفات النماذج القياسية من Hugging Face (safetensors)، مع إمكانية تكمينها باستخدام تقنيات مثل AWQ أو GPTQ أو FP8. فإذا كانت نماذجك موجودة فقط بصيغة GGUF، فإن Ollama أو llama.cpp سيكونان الخيار الأنسب لها.

هل يعمل vLLM بدون وحدة معالجة رسوميات من شركة NVIDIA؟

توجد واجهات دعم لوحدات معالجة الرسوميات من AMD (ROCm)، ومن إنتل، ولوحدات معالجة الذكاء الاصطناعي من جوجل (TPUs)، ولوحدات AWS Neuron، وحتى للوحدات المركزية (CPUs)، لكن الدعم الخاص بـ NVIDIA عبر CUDA هو الأكثر نضجًا وتفصيلًا وثائقياً بكثير. أما الإصدار الذي يعمل على وحدة المعالجة المركزية فقط فهو مناسب لاختبارات التطوير، وليس للأداء العالي المطلوب في عمليات الخدمة الإنتاجية التي صُمِّم vLLM من أجلها.

كم تبلغ كمية ذاكرة VRAM المطلوبة لتشغيل vLLM؟

يجب أن تكون كافية لتضمَّن أوزان النموذج بالإضافة إلى ذاكرة التخزين المؤقت للقيم الرئيسية (KV cache): أي ما يقارب 2 غيغابايت لكل مليار معلَّمة عند دقة FP16، وحوالي نصف هذه الكمية عند دقة 8-bit، مع هامش إضافي لذاكرة التخزين المؤقت يتزايد مع طول السياق وعدد العمليات المتزامنة. فنموذج بحجم 7 مليارات معلَّمة عند دقة FP16 يشغل بسهولة بطاقة ذات سعة 24 غيغابايت، أما نموذج بحجم 70 مليار معلَّمة فيتطلب استخدام عدة وحدات معالجة رسوميات أو تكمينًا قويًّا. وتوفر مرجعية متطلبات VRAM حسب النموذج أرقامًا مفصَّلة حسب كل نموذج.

كيف يقارن vLLM مع TensorRT-LLM أو SGLang أو TGI؟

جميعها تنتمي إلى نفس الفئة — وهي محركات الاستنتاج الإنتاجية. ويتميز vLLM عمومًا بأوسع دعم للنماذج، وأسهل إعداد، وأكبر مجتمع داعم؛ بينما قد يحقق TensorRT-LLM أداءً أعلى قليلًا على أجهزة NVIDIA، لكن ذلك يأتي على حساب تعقيد أكبر في عملية البناء والضبط؛ أما SGLang فهو منافس قوي، خاصةً في مهام الإخراج المنظَّم. لذا يُوصى بإجراء الاختبارات المعيارية (Benchmark) على نموذجك وحمولة عملك الخاصة قبل الالتزام بأي منها، لأن الترتيب بين هذه المحركات قد يتغير من إصدارٍ لآخر.

هل يمكنني ضبط النماذج (Fine-tune) باستخدام vLLM؟

لا — فـ vLLM مخصص فقط لعملية الاستنتاج (Inference). وغالبًا ما يُستخدم كمحرك توليد سريع ضمن أطر عمل تدريب النماذج باستخدام التعزيز بالتعلم الآلي (RLHF)، لكن عملية التدريب نفسها تتم في مكان آخر. لذا قم بضبط النماذج باستخدام أدوات مثل Hugging Face TRL أو Axolotl أو Unsloth، ثم قدِّم النموذج الناتج عبر vLLM.