vLLM

تُعد vLLM مكتبة مفتوحة المصدر لاستنتاج وخدمة النماذج اللغوية الكبيرة بسرعة وكفاءة عالية في استهلاك الذاكرة. تم إنشاؤها في مختبر UC Berkeley Sky Computing Lab في عام 2023 بواسطة Woosuk Kwon و Zhuohan Li و Siyuan Zhuang ومعاونيهم، وتم التبرع بها لاحقًا إلى PyTorch Foundation لضمان إدارة محايدة ومستقلة عن الشركات. المشكلة الأساسية التي تحلها هي تجزئة ذاكرة وحدة معالجة الرسومات (GPU) أثناء خدمة النماذج اللغوية الكبيرة: قبل vLLM، كانت خوادم الاستنتاج تهدر 60-80% من ذاكرة التخزين المؤقت (KV cache) المحجوزة عن طريق تخصيص كتل متجاورة لكل تسلسل. تستعير خوارزمية PagedAttention الخاصة بـ vLLM مفهوم ترحيل الذاكرة الافتراضية من أنظمة التشغيل لتخزين ذاكرة التخزين المؤقت (KV cache) في صفحات غير متجاورة، مما يقلل الهدر إلى ما يقرب من الصفر ويتيح تشغيل عدد أكبر بكثير من التسلسلات المتزامنة على نفس الأجهزة.

تأتي المكتبة مزودة بخادم REST API متوافق مع OpenAI، وتجميع مستمر (continuous batching) على مستوى التكرار (وليس مستوى الطلب)، وتوازي الموترات (tensor parallelism) وتوازي خطوط الأنابيب (pipeline parallelism) لعمليات النشر على وحدات معالجة رسومات وعقد متعددة، وفك التشفير التخميني (speculative decoding)، ودعم أصلي لتنسيقات التكميم (quantization) بما في ذلك GPTQ و AWQ و INT8 و FP8. تدعم المكتبة مئات النماذج من خلال تكامل HuggingFace Transformers: مثل Llama 3.x و Mistral و Mixtral و Qwen و DeepSeek و Gemma و Phi، ونماذج الرؤية واللغة مثل LLaVA و Pixtral. أدت إعادة كتابة بنية الإصدار v1 في يناير 2025 إلى فصل المجدول (scheduler) عن حلقة العامل (worker loop)، مما أنتج بنية داخلية أنظف وأدوات أفضل لتحليل أداء عمليات النشر في بيئة الإنتاج. تعمل vLLM على أجهزة NVIDIA و AMD ROCm و Intel Gaudi و AWS Trainium.

ما الذي تفعله vLLM فعليًا في أبريل 2026

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

كانت النتيجة، الموثقة في ورقة SOSP 2023، إنتاجية أعلى تصل إلى 24 ضعفًا مقارنة بحلقة خدمة HuggingFace Transformers التقليدية على نفس الأجهزة. من الناحية العملية: يمكن لوحدة معالجة رسومات واحدة من نوع A100 80GB تخدم نموذج Llama 3.1 8B التعامل مع حوالي 200 مستخدم متزامن للبث بزمن انتقال مقبول، في حين أن الحلقة التقليدية قد تصل إلى حدها الأقصى عند 10-20 مستخدمًا.

بدء تشغيل الخادم يتطلب أمرًا واحدًا: vllm serve meta-llama/Llama-3.1-8B-Instruct --tensor-parallel-size 1. يعرض الخادم بعد ذلك نقاط النهاية /v1/chat/completions و /v1/completions التي تتطابق مع مواصفات OpenAI API. يمكن لأي تطبيق حالي يستخدم عميل OpenAI Python إعادة التوجيه إلى خادم vLLM عن طريق تغيير عنوان URL الأساسي ومفتاح API، دون أي تغييرات أخرى في التعليمات البرمجية. يُشار إلى هذا التوافق من قبل مهندسي المنصات باعتباره الدافع الأكبر للاعتماد، لأنه يزيل حاجز الانتقال من النموذج الأولي إلى بيئة الإنتاج المستضافة ذاتيًا.

بالإضافة إلى الخادم، توفر vLLM واجهة برمجة تطبيقات للاستنتاج دون اتصال بالإنترنت (offline inference API) للمهام المجمعة. يمكن لفريق علوم البيانات الذي يعالج 100,000 عملية إكمال تصنيف تحميل نموذج مرة واحدة وتشغيل استدعاء LLM.generate() على قائمة من المطالبات، مما يحقق إنتاجية أعلى بـ 5-10 أضعاف مقارنة باستدعاءات API المتسلسلة. تستخدم الفرق في Together AI هذا المسار لمهام الاستنتاج المجمعة واسعة النطاق حيث يكون زمن الانتقال أقل أهمية من التكلفة لكل رمز مميز (token).

"لقد انتقلنا من خدمة حوالي 20 مستخدمًا متزامنًا إلى أكثر من 200 مستخدم على نفس الأجهزة بعد التبديل إلى vLLM. التجميع المستمر يغير قواعد اللعبة بشكل حقيقي بالنسبة لتكلفة الاستنتاج لدينا." - u/ml_infra_eng، Reddit r/LocalLLaMA، نوفمبر 2023

"vLLM هي ما يشغل معظم حزمة الاستنتاج الخاصة بـ Together AI. أدت PagedAttention وحدها إلى خفض استخدام ذاكرة التخزين المؤقت (KV cache) بنسبة 55% تقريبًا في الطلبات ذات السياق الطويل، وهو المكان الذي كانت هوامش أرباحنا تتعرض فيه لأكبر ضغط." - Tim Dettmers، فريق الاستنتاج، مدونة هندسة Together AI، فبراير 2024

موقع vLLM مقارنة بـ TGI و SGLang

محركات الاستنتاج مفتوحة المصدر الثلاثة الأكثر نشرًا في عام 2026 هي vLLM و HuggingFace TGI و SGLang. إنها تشترك في الأهداف ولكنها تختلف ميكانيكيًا بطرق تهم أعباء عمل محددة.

vLLM مقابل TGI (Text Generation Inference): يتمتع HuggingFace TGI بنقطة دخول أبسط تعتمد على Docker أولاً. النشر القياسي هو أمر docker run واحد مع معرف النموذج. أضاف TGI دعم PagedAttention في إصداره v2 في عام 2024، مما أدى إلى تضييق فجوة الإنتاجية. ومع ذلك، يعمل التجميع المستمر في vLLM بدقة أعلى: فهو يُدرج رموزًا جديدة في الدفعة النشطة في كل خطوة فك تشفير، بينما يقوم TGI بالتجميع على مستوى أقل دقة في بعض التكوينات. في معايير المجتمع على Llama 3 70B بتكميم 4 بت (r/LocalLLaMA، نوفمبر 2024)، تحقق vLLM عادةً إنتاجية أعلى لرموز الإخراج بنسبة 15-25% من TGI في أعباء العمل عالية التزامن. تتمثل ميزة TGI في تكامل HuggingFace Hub، وخادم مدعوم بـ Rust مع عبء Python أقل، وعملية نشر تتطلب تكوينًا أقل. بالنسبة للفرق المتعمقة بالفعل في نظام HuggingFace البيئي، يُعد TGI الخيار الأول الطبيعي. أما بالنسبة للفرق التي تعمل على تحسين الإنتاجية الخام على نطاق واسع، فإن vLLM هي الفائزة عمومًا.

vLLM مقابل SGLang: يقدم SGLang، من مجموعة LMSYS، تقنية RadixAttention: مشاركة ذاكرة التخزين المؤقت (KV cache) عبر الطلبات التي تشترك في بادئة مشتركة. من الناحية العملية، هذا يعني أن مطالبة النظام المكونة من 2,000 رمز مميز والتي يستخدمها 1,000 مستخدم متزامن يتم حسابها وتخزينها مؤقتًا مرة واحدة، وليس 1,000 مرة. في أعباء عمل الوكلاء (agentic workloads)، والمحادثات متعددة الأدوار، والاستنتاج المجمع مع البادئات المشتركة، يمكن لـ RadixAttention الخاص بـ SGLang تقليل الوقت المستغرق للرمز الأول (time-to-first-token) بنسبة 50-80% مقارنة بـ vLLM. أضافت vLLM التخزين المؤقت للبادئة الخاص بها لسد هذه الفجوة، لكن تنفيذ SGLang يظل أكثر نضجًا. حيث تتمتع vLLM بميزة واضحة: اتساع دعم النماذج (المئات مقابل قائمة أضيق)، وأدوات توازي خطوط الأنابيب متعددة العقد، وتغطية تنسيق التكميم، وحجم مجتمع عمليات الإنتاج المحيط بها. بالنسبة لأعباء عمل الذكاء الاصطناعي القائمة على الوكلاء تحديدًا، ضع SGLang في الاعتبار؛ أما بالنسبة للخدمة ذات الأغراض العامة مع أقصى توافق للنماذج، تظل vLLM هي الخيار الافتراضي.

يقوم منافس ثالث، وهو TensorRT-LLM من NVIDIA، بتجميع النماذج إلى رسوم بيانية محسنة لـ CUDA ويحقق إنتاجية ذروة أعلى على أجهزة NVIDIA. المقايضة هنا تشغيلية: يستغرق تجميع نموذج TensorRT-LLM من 30 إلى 60 دقيقة لكل نموذج لكل نوع من وحدات معالجة الرسومات. بينما تقوم vLLM بتحميل نموذج من القرص في أقل من دقيقة. بالنسبة للفرق التي تقوم بتشغيل العديد من النماذج أو التكرار بشكل متكرر، تفوز البساطة التشغيلية لـ vLLM بشكل حاسم. يستحق TensorRT-LLM تكلفة التجميع فقط عند محاولة استخراج أقصى عدد من الرموز في الثانية على نموذج ثابت على نطاق واسع. تعمل vLLM أيضًا على AMD ROCm و Intel Gaudi و AWS Trainium؛ بينما يقتصر TensorRT-LLM على NVIDIA فقط.

كيف يبدو واقع النشر

يتضمن النشر النموذجي في بيئة الإنتاج اختيار مثيل وحدة معالجة الرسومات (A10G للنماذج الأصغر، A100/H100 لنماذج 70B+)، وتثبيت vLLM عبر pip، وتشغيل أمر الخدمة. بالنسبة لنموذج 70B على 4 وحدات A100، يضيف الأمر --tensor-parallel-size 4. يتم تنزيل أوزان النموذج من HuggingFace Hub عند التشغيل الأول، ثم يتم تخزينها مؤقتًا محليًا. يستغرق البدء البارد (Cold start) لنموذج 70B من 3 إلى 8 دقائق حسب سرعة التخزين. بالنسبة للخدمات التي تحتاج إلى التوسع إلى الصفر (scale to zero)، يمثل زمن الانتقال هذا قيدًا حقيقيًا.

تتطلب عمليات النشر متعددة العقد (توازي خطوط الأنابيب عبر خوادم متعددة) إما Ray أو واجهة خلفية موزعة مخصصة. إعداد مجموعة Ray هو المكان الذي تبلغ فيه معظم الفرق عن إضاعة ساعات. تغطي وثائق vLLM هذا الأمر بشكل كافٍ، لكن أوضاع الفشل (تكوين الشبكة، أخطاء NCCL، ارتباك لوحة معلومات Ray) ليست موثقة جيدًا. يوصي المهندسون الذين قاموا بذلك بنجاح بتشغيل إعداد عقدة واحدة أولاً، والتحقق من سلوك النموذج، وإضافة العقد فقط بمجرد استقرار خط الأساس.

بالنسبة للفرق التي ترغب في تجنب إدارة البنية التحتية تمامًا، تتوفر نقاط نهاية مُدارة تعتمد على vLLM على Modal و Replicate و Together AI، حيث يقدم كل منها نفس واجهة برمجة التطبيقات المتوافقة مع OpenAI مع تسعير لكل رمز مميز (per-token) وبدون إدارة للخوادم. المقايضة هنا هي التكلفة ومكان إقامة البيانات: الاستضافة الذاتية على وحدة معالجة الرسومات الخاصة بك أرخص على نطاق واسع وتحافظ على البيانات داخل مؤسستك.

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

لمن تم بناء vLLM

تُعد vLLM برنامج بنية تحتية، وليست منتجًا موجهًا للمستخدم النهائي. تم بناؤها لمهندسي تعلم الآلة وفرق المنصات الذين لديهم إمكانية الوصول إلى أجهزة وحدات معالجة الرسومات (GPU)، ويشعرون بالراحة مع بيئات Python و Linux، ويحتاجون إلى خدمة نماذج لغوية مفتوحة المصدر بإنتاجية تبرر تكلفة البنية التحتية.

أقوى حالات الاستخدام: مؤسسة تبني واجهة برمجة تطبيقات (API) خاصة للنماذج اللغوية الكبيرة للاستخدام الداخلي (تبقى البيانات داخل المؤسسة، ولا يوجد اعتماد على مورد خارجي)؛ فريق وجد أن تكاليف الاستنتاج باهظة على واجهات برمجة التطبيقات التجارية ويريد تشغيل نموذج أصغر مضبوط بدقة (fine-tuned) بدلاً من ذلك؛ مختبر أبحاث يحتاج إلى تشغيل الاستنتاج على دفعات كبيرة من النصوص للتجارب؛ شركة ناشئة تبني منتجًا يعتمد على نماذج مفتوحة المصدر حيث يتطلب هامش الربح الاستضافة الذاتية.

بالنسبة للفرق التي تستخدم بالفعل نماذج مفتوحة المصدر محليًا عبر واجهة مستخدم رسومية (GUI)، فإن إقران vLLM بواجهة دردشة أمر مباشر. يمكن لـ AnythingLLM والواجهات الأمامية المشابهة التوجيه إلى خادم vLLM محلي. بالنسبة للمستخدمين الذين يريدون تجربة نموذج محلي جاهزة للاستخدام دون تكوين خادم، يُعد Ollama نقطة البداية الأفضل. تُعد vLLM الأداة المناسبة بمجرد أن تصبح الإنتاجية والتزامن هما الشاغل الأساسي، وليس سهولة التشغيل الأول. ستجد الفرق التي تنشر على نطاق تجاري باستخدام أوزان نماذج مفتوحة المصدر، مثل تلك التي قد تقوم بالفعل بتشغيل نماذج على بنيات عائلة Llama، أن vLLM هي خيار الإنتاج الأكثر نضجًا.

ما لا تقدمه vLLM

لا تعمل vLLM على نظام Windows بشكل أصلي. يجب على المستخدمين استخدام WSL2 أو Docker، مما يضيف صعوبة للتطوير المحلي. إنها ليست تطبيقًا بواجهة مستخدم رسومية (GUI)، أو واجهة دردشة، أو أداة لإدارة النماذج بأسلوب LM Studio. إنها لا تقوم بضبط النماذج بدقة (fine-tune). ولا توفر تحديدًا مدمجًا لمعدل الطلبات (rate limiting)، أو مصادقة، أو فوترة: تتطلب هذه الميزات طبقة وكيل (proxy) مثل LiteLLM. إنها ليست خدمة مُدارة؛ لا توجد "vLLM Cloud" من المشروع نفسه. يجب على الفرق التي تحتاج إلى واجهة برمجة تطبيقات استنتاج مُدارة بالكامل دون مسؤولية البنية التحتية أن تنظر إلى Replicate أو Together AI (التي تقوم بتشغيل vLLM داخليًا). بالنسبة للمهندسين الذين يقيمون ما إذا كانوا سيستضيفون ذاتيًا أو يستخدمون واجهة برمجة تطبيقات مُدارة، فإن vLLM ترجح كفة الاستضافة الذاتية بمجرد أن تصل حركة المرور إلى نطاق تكون فيه تكاليف مثيل وحدة معالجة الرسومات أقل من رسوم واجهة برمجة التطبيقات لكل رمز مميز، وعادة ما يكون ذلك في مكان ما بين 1-10 مليون رمز مميز يوميًا اعتمادًا على حجم النموذج ومزود السحابة.