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

vLLM هو محرك استدلال وخدمة مفتوح المصدر للنماذج اللغوية الكبيرة. يحمّل نموذجًا على وحدة معالجة رسومات واحدة أو أكثر ويعرضه من خلال HTTP API متوافق مع OpenAI، باستخدام تقنيتين — PagedAttention والمعالجة الدفعية المستمرة — لخدمة طلبات متزامنة عديدة بإنتاجية أعلى بكثير من الخدمة البسيطة. تم إنشاؤه في معمل Sky Computing بجامعة UC Berkeley وتم إطلاقه في 2023.

ما هو vLLM وللمن موجه

Think of vLLM as the production counterpart to desktop tools like Ollama. Both take a model and answer requests, but they optimize for opposite things. Ollama optimizes for one person getting a response on modest hardware. vLLM optimizes for معدل الإنتاجية (throughput): إجمالي التوكنات المولدة في الثانية الواحدة عبر عشرات أو مئات من الطلبات المتزامنة التي تصل إلى وحدة معالجة الرسومات ذاتها.

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

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

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

عند إطلاقه في عام 2023، أظهرت مقاييس vLLM إنتاجية أكبر بـ 24 مرة من الخدمة باستخدام Hugging Face Transformers العادي وتقريبًا 2–3.5 مرات من أنظمة الخدمة في ذلك الوقت. تختلف الأرقام الدقيقة حسب النموذج والأجهزة وحمل العمل — لكن فهم سبب الفجوة يستحق الانتباه، لأنه يخبرك متى يكون vLLM مهمًا.

PagedAttention، بكلمات بسيطة

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

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

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

النتيجة العملية: تناسب عدد أكبر بكثير من التسلسلات المتزامنة في نفس VRAM. المزيد من التسلسلات في الذاكرة يعني حزم فعالة أكبر، والحزم الأكبر هي ما يبقي GPU مشغولاً. هذه هي قصة الإنتاجية بأكملها — PagedAttention لا يجعل أي طلب واحد أسرع؛ بل يسمح بتشغيل طلبات أكثر بكثير في نفس الوقت.

المعالجة المتتالية (Continuous batching)

الأسلوب الثاني يستهدف الجدولة بدلاً من الذاكرة. التجميع الساذج يجمع الطلبات، ينفذ الدفعة كاملة حتى النهاية، ثم يبدأ الدفعة التالية — لذلك طلب ينتهي في 20 رمز ينتظر طلباً آخر يولد 2,000، والوصول الجديد ينتظر بالخارج. المعالجة المتتالية (Continuous batching) (يُسمى أيضاً جدولة على مستوى التكرار) يعيد تشكيل الدفعة في كل خطوة توليد: التسلسلات المنتهية تغادر فوراً والطلبات المنتظرة تنضم فوراً.

بطاقة الرسومات تبقى مشغولة، الطلبات القصيرة لا تُحتجز رهينة من قبل الطلبات الطويلة، وكمون التأخير تحت الحمل يتحسن جنباً إلى جنب مع الإنتاجية. PagedAttention والتجميع المستمر يعملان معاً: الأول يناسب تسلسلات أكثر في الذاكرة، والثاني يحافظ على تلك السعة تعمل بالفعل.

تثبيت vLLM: القيود التي تربك المستخدمين

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

1. إصدار Python. الإصدارات الأخيرة تستهدف تقريباً نطاق Python 3.9–3.12، والنافذة المدعومة تتحول بين الإصدارات. إذا pip أبلغ عن عدم وجود توزيع مطابق، فإن إصدار Python الخاص بك هو المشتبه به الأول.
2. إصدار CUDA. العجلات المدمجة مسبقاً تُجمع ضد إصدار CUDA رئيسي محدد (CUDA 12.x للإصدارات الحالية). تحتاج إلى برنامج تشغيل NVIDIA حديث؛ عجلات لإصدارات CUDA أخرى موجودة لبعض الإصدارات عبر عناوين فهرس خاصة موثقة في وثائق vLLM.
3. تضاربات PyTorch. vLLM يثبت إصدار PyTorch الخاص به. تثبيته في بيئة بها بنية Torch مختلفة بالفعل هو الطريقة الكلاسيكية للانتهاء برسائل استيراد غامضة. استخدم دائماً بيئة افتراضية جديدة.

من حيث الأجهزة، المسار السائد يتطلب معالج رسومات NVIDIA بقدرة حسابية 7.0 أو أعلى — V100 أو T4 أو RTX 20-series والإصدارات الأحدث. إذا كنت تختار الأجهزة، راجع الدليل الخاص بـ أفضل وحدات معالجة الرسومات لتشغيل LLMs محليًا.

Linux (المنصة المدعومة)

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

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

Windows: استخدم WSL2 أو Docker

لا توجد نسخة Windows أصلية. الإعدادات التي تعمل هي WSL2 مع توزيعة Ubuntu (برنامج تشغيل NVIDIA على Windows يمرر CUDA إلى WSL2، لذا تعمل تعليمات Linux أعلاه داخله) أو Docker Desktop مع تفعيل دعم GPU، باستخدام الصورة الرسمية:

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

macOS: ليست الأداة المناسبة

vLLM لا يملك واجهة خلفية Metal/Apple GPU. يمكن ترجمة نسخة CPU تجريبية من المصدر، لكنها تتعارض مع الغرض من محرك الإنتاجية. على Mac، استخدم LM Studio أو Ollama بدلاً من ذلك — كلاهما يستخدم GPU للمعالجات من Apple Silicon بشكل صحيح.

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

أمر واحد يبدأ خادم الاستدلال (يتم تحميل النموذج من Hugging Face عند التشغيل الأول):

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

هذا يخدم النموذج على المنفذ 8000. الخيارات التي ستستخدمها فعلياً:

الخيار	ما الذي يفعله	عندما تحتاجه
--max-model-len	يحد من طول السياق، مما يقلل حجز ذاكرة KV	الإصلاح الأكثر شيوعاً عند فشل البدء برسالة خطأ نقص الذاكرة
--gpu-memory-utilization	نسبة VRAM التي يخصصها vLLM مسبقاً (الافتراضي 0.9)	قللها إذا كان GPU مشتركاً مع أي شيء آخر
--tensor-parallel-size	يقسم النموذج عبر N من وحدات GPU	نماذج كبيرة جداً لبطاقة واحدة
--quantization	يختار طريقة التكميم (AWQ, GPTQ, FP8…)	عادة ما يتم كشفها تلقائياً من نقطة التفتيش؛ عينها بشكل صريح إذا لم تكن كذلك
--dtype	دقة الأوزان (auto, float16, bfloat16)	وحدات GPU الأقدم بدون دعم bfloat16
--api-key	يتطلب رمز Bearer على كل طلب	أي خادم يمكن الوصول إليه خارج localhost
--port	منفذ الاستماع (الافتراضي 8000)	تضارب المنافذ، نماذج متعددة على مضيف واحد

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

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

يطبق الخادم سطح OpenAI API: /v1/chat/completions, /v1/completions, /v1/models، و /v1/embeddings (لنماذج التضمين). أي شيء بني مقابل OpenAI SDK يعمل بتغيير عنوان URL الأساسي:

curl http://localhost:8000/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{
    "model": "Qwen/Qwen2.5-7B-Instruct",
    "messages": [{"role": "user", "content": "Explain PagedAttention in one sentence."}]
  }'

في Python، OpenAI(base_url="http://localhost:8000/v1", api_key="none") هذا هو الهجرة الكاملة. هذه التوافقية جزء كبير من اعتماد vLLM: تعمل الأدوات والوكلاء والأطر الموجودة بدون تعديل.

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

	vLLM	Ollama	llama.cpp
مُصمَّم لـ	خدمة GPU متعددة المستخدمين	الاستخدام الشخصي/سطح المكتب	قابلية النقل، CPU+GPU، التضمين في التطبيقات
الأجهزة	وحدات معالجة الخوادم (NVIDIA بالأساس)	أي شيء، بما في ذلك Apple Silicon	أي شيء، بما في ذلك الهواتف
صيغة النموذج	Hugging Face safetensors (AWQ/GPTQ/FP8)	GGUF	GGUF
التزامن	ممتازة — وهذا هو الغرض الرئيسي منها	محدود	محدود
التهيئة	بيئة بايثون وCUDA	برنامج تثبيت واحد	ملف تنفيذي واحد أو مكتبة واحدة

اختر 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.