النقاط الرئيسية
- مجانية ومفتوحة المصدر بموجب رخصة Apache 2.0، نشأت في مختبر Sky Computing Lab بجامعة UC Berkeley
- PagedAttention تدير ذاكرة التخزين المؤقت KV في كتل غير متجاورة بحجم ثابت لتقليل هدر ذاكرة وحدة معالجة الرسومات
- التجميع المستمر يعالج عددًا كبيرًا من الطلبات المتزامنة بدلاً من دفعة ثابتة واحدة في كل مرة
- تأتي مزودة بخادم API متوافق مع OpenAI، يُشغَّل بأمر
vllm serve - تدعم صيغ تكميم مثل AWQ وGPTQ وFP8
- تدعم الخدمة بالتوازي الموتري وتوازي خطوط الأنابيب عبر عدة وحدات معالجة رسومية
- الأجهزة الأساسية والأفضل دعمًا هي وحدات معالجة رسومية NVIDIA؛ توجد خلفيات لـ AMD وIntel وغيرها لكن بتغطية أضيق
- ليست تطبيق سطح مكتب لمستخدم واحد — لا يوجد مثبّت رسومي، وليست مصممة للمعالج المركزي فقط أو Apple Silicon كما هو الحال مع llama.cpp وOllama
📍 في جملة واحدة
vLLM مكتبة مجانية مرخّصة بموجب Apache 2.0 نشأت في مختبر Sky Computing Lab بجامعة UC Berkeley، تستخدم PagedAttention والتجميع المستمر لخدمة عدد كبير من طلبات نماذج اللغة الكبيرة المتزامنة بكفاءة من وحدة معالجة رسومية واحدة، وتأتي مزودة بخادم API متوافق مع OpenAI.
💬 بعبارات بسيطة
بدلاً من تطبيق دردشة لسطح المكتب، فإن vLLM برنامج خادم: توجّهه إلى نموذج فيعرض واجهة برمجية يمكن لعدد كبير من الأشخاص أو التطبيقات استدعاؤها في الوقت نفسه، مستغلًا ذاكرة وحدة معالجة الرسومات بكفاءة أكبر من إعداد بسيط يعالج طلبًا واحدًا في كل مرة.
📌ملاحظة: يستند هذا المقال إلى مستودع GitHub الرسمي لـ vLLM والوثائق العامة، وليس إلى اختبارات أداء مستقلة. لا تُذكر أرقام محددة للإنتاجية أو زمن الاستجابة لأنها لم تُقَس بشكل مستقل لهذا المقال وتتفاوت بشدة حسب وحدة المعالجة الرسومية والنموذج وحجم الدفعة وإصدار vLLM.
ما هو vLLM؟
vLLM مكتبة وخادم مجانيان مرخّصان بموجب Apache 2.0 لتشغيل استدلال نماذج اللغة الكبيرة على نطاق واسع. نشأ كمشروع بحثي في مختبر Sky Computing Lab بجامعة UC Berkeley، وأصبح منذ ذلك الحين أحد أكثر محركات خدمة نماذج اللغة الكبيرة مفتوحة المصدر استخدامًا، بمساهمات من آلاف المطورين من مؤسسات أكاديمية وصناعية. وعلى عكس الأدوات المصممة أساسًا لمستخدم واحد يتحدث إلى نموذج على جهازه الخاص، صُمم vLLM لخدمة عدد كبير من الطلبات المتزامنة — من عدة مستخدمين أو تطبيقات — بأكبر قدر ممكن من الكفاءة من سعة وحدة معالجة رسومية مشتركة.
- نشأ في مختبر Sky Computing Lab بجامعة UC Berkeley، وهو اليوم مشروع مفتوح المصدر تحكمه المجتمعة
- مرخّص بموجب Apache 2.0: الشيفرة المصدرية متاحة للجمهور للاستخدام والتعديل وإعادة التوزيع وفق شروط الرخصة
- يحمّل النماذج بصيغة متوافقة مع Hugging Face Transformers، مما يمنحه تغطية واسعة للمعماريات — Llama وMistral وQwen وDeepSeek والعديد من عائلات النماذج الأخرى — دون الحاجة إلى خطوة تحويل منفصلة لمعظم النماذج
- مبني لخدمة عدد كبير من الطلبات المتزامنة بكفاءة، وليس فقط لتشغيل محادثة واحدة بسرعة
- أحد أكثر مشاريع خدمة نماذج اللغة الكبيرة مفتوحة المصدر إشارة إليها على GitHub
ما هو PagedAttention، ولماذا يهم؟
PagedAttention هي تقنية إدارة الذاكرة التي يُعرف بها vLLM أكثر من غيرها. أثناء التوليد، يخزّن نموذج المحوّل (transformer) ذاكرة تخزين مؤقت للانتباه (مفتاح-قيمة، KV) لكل رمز (token) في كل طلب نشط — عادةً تُخصَّص هذه الذاكرة المؤقتة ككتلة متجاورة كبيرة واحدة لكل طلب، بحجم يتناسب مع الطول الأقصى الممكن للطلب، مما يهدر ذاكرة وحدة معالجة الرسومات كلما انتهى طلب مبكرًا أو كان أقصر من الحد الأقصى المحجوز. بدلاً من ذلك، يقسّم PagedAttention ذاكرة KV المؤقتة إلى كتل صغيرة بحجم ثابت (صفحات) يمكن تخصيصها بشكل غير متجاور ومشاركتها بين الطلبات، مستعيرًا فكرة من كيفية إدارة أنظمة التشغيل للذاكرة الافتراضية.
- يقلل هدر الذاكرة الناتج عن حجز مساحة زائدة من ذاكرة KV المؤقتة لطلبات تتضح لاحقًا أنها أقصر من حدها الأقصى
- يسمح بمشاركة كتل الذاكرة بين الطلبات التي تشترك في بادئة مشتركة، مثل نفس موجّه النظام (system prompt)
- يتيح لوحدة معالجة الرسومات الاحتفاظ بذاكرة KV المؤقتة لعدد أكبر من الطلبات المتزامنة في نفس كمية الذاكرة مقارنة بتخصيص متجاور تقليدي
- يعمل جنبًا إلى جنب مع التجميع المستمر، الذي يتيح لـ vLLM إضافة الطلبات إلى دفعة قيد التنفيذ وإزالتها منها فور وصولها واكتمالها، بدلاً من الانتظار حتى تنتهي دفعة ثابتة بالكامل قبل بدء التالية
ما الأجهزة التي يحتاجها vLLM؟
الهدف الأساسي والأفضل دعمًا لـ vLLM هو وحدات معالجة رسومية NVIDIA مع CUDA، ومعظم عمليات النشر الإنتاجية تعمل على أجهزة NVIDIA. يوثّق المشروع أيضًا خلفيات إضافية، لكن التغطية والأداء ليسا متساويين عبر جميعها.
وحدات معالجة رسومية NVIDIA (CUDA)
- التفاصيل:
- الهدف الأساسي والأكثر نضجًا. الخدمة بالتوازي الموتري وتوازي خطوط الأنابيب عبر عدة وحدات معالجة رسومية NVIDIA موثّقة جيدًا ومستخدمة على نطاق واسع في الإنتاج.
وحدات معالجة رسومية AMD (ROCm)
- التفاصيل:
- موثّقة كخلفية مدعومة لأجهزة AMD عبر ROCm، لكن الاعتماد الفعلي وتغطية المجتمع أضيق من مسار CUDA.
وحدات معالجة رسومية Intel ومسرّعات Gaudi
- التفاصيل:
- خلفيات إضافية يوثّقها المشروع لأجهزة Intel؛ تُعامَل كمسار نشر أصغر وأقل اختبارًا مقارنة بوحدات معالجة رسومية NVIDIA.
وحدات معالجة Google TPU
- التفاصيل:
- خلفية موثّقة لأجهزة TPU الخاصة بـ Google Cloud، موجّهة للفرق التي تعمل بالفعل على تلك البنية التحتية.
المعالج المركزي (x86 / ARM / PowerPC)
- التفاصيل:
- توجد خلفية تعتمد على المعالج المركزي فقط، لكنها ليست حالة الاستخدام المستهدفة لـ vLLM — المشروع مبني لخدمة وحدات معالجة الرسومات، والتنفيذ على المعالج المركزي موثّق بأنه أبطأ بكثير من خلفيات وحدة معالجة الرسومات.
Apple Silicon (Mac)
- التفاصيل:
- ليس مسارًا رسميًا من الدرجة الأولى. تضيف مشاريع يصونها المجتمع (مثل إضافة خلفية Metal) دعمًا جزئيًا لـ Apple Silicon، لكن التغطية والنضج بعيدان جدًا عن دعم vLLM لوحدات معالجة رسومية NVIDIA.
إذا كان الهدف تشغيل نموذج على جهاز Mac واحد أو جهاز يعتمد على المعالج المركزي فقط، فإن vLLM ليس الأداة المصممة لذلك — llama.cpp والأدوات المبنية عليه، مثل Ollama وLM Studio، تستهدف مباشرة أجهزة المعالج المركزي وApple Silicon وتناسب هذا السيناريو بشكل أفضل.
ما صيغ التكميم التي يدعمها vLLM؟
يدعم vLLM خدمة النماذج بدقة عددية مخفّضة لتقليل استخدام الذاكرة، وفي كثير من الحالات زيادة الإنتاجية، باستخدام عدة صيغ تكميم راسخة بدلاً من صيغة واحدة مملوكة.
AWQ
- التفاصيل:
- Activation-aware Weight Quantization، طريقة تكميم أوزان واسعة الاستخدام بدقة 4 بت، مع نماذج مكمَّمة مسبقًا ينشرها المجتمع على Hugging Face.
GPTQ
- التفاصيل:
- طريقة تكميم بعد التدريب، تُوزَّع عادةً كنقاط تفتيش نماذج مكمَّمة مسبقًا، وعادةً أيضًا بدقة 4 بت.
FP8
- التفاصيل:
- دقة فاصلة عائمة بـ8 بت، مدعومة على أجيال أحدث من وحدات معالجة رسومية NVIDIA التي تتضمن دعمًا لـFP8 على مستوى العتاد — مقايضة بعض الدقة مقابل استخدام ذاكرة أقل وتنفيذ أسرع من FP16/BF16.
INT8 / INT4
- التفاصيل:
- مسارات تكميم عددي صحيح بدقة أقل يوثّقها المشروع إلى جانب AWQ وGPTQ لمزيد من تقليل الذاكرة.
لا يتضمن هذا المقال أرقامًا مقيسة بشكل مستقل لفقدان الجودة لكل صيغة — فهذه تتفاوت حسب معمارية النموذج والمهمة. تُعد مقارنة مخرجات صيغتين أو ثلاث على موجّهاتك (prompts) الخاصة الطريقة الأكثر موثوقية للحكم على المقايضة المناسبة لحمل عملك.
ماذا يوفر خادم vLLM المتوافق مع OpenAI؟
يؤدي تشغيل vllm serve إلى بدء تشغيل خادم HTTP يطبّق بروتوكول واجهة برمجة تطبيقات OpenAI، بحيث يمكن للتطبيقات وحِزم التطوير (SDKs) المبنية أصلًا على واجهة OpenAI أن تشير غالبًا إلى نسخة vLLM مستضافة ذاتيًا بمجرد تغيير عنوان URL الأساسي واسم النموذج.
- نقاط نهاية متوافقة مع OpenAI لإكمالات الدردشة والإكمالات، قابلة للاستخدام كبديل مباشر لشيفرة العميل المعتمدة على واجهة OpenAI
- مضيف ومنفذ قابلان للتهيئة (يستمع الخادم افتراضيًا على
http://localhost:8000) - أعلام محرك لحجم التوازي الموتري، وهدف استخدام ذاكرة وحدة معالجة الرسومات، وصيغة التكميم، تُضبط عند بدء تشغيل الخادم
- دعم لخدمة عدة محوّلات LoRA على نفس النموذج الأساسي المحمَّل
- دعم للمخرجات المهيكلة واستدعاء الدوال/الأدوات لصيغ الطلبات المتوافقة
كيف تُثبّت وتشغّل vLLM؟
يُوزَّع vLLM كحزمة بايثون، ويُثبَّت عادةً باستخدام pip في بيئة بايثون تتوفر فيها وحدة معالجة رسومية NVIDIA وتعريفات CUDA متوافقة.
- 1تأكد من وجود وحدة معالجة رسومية NVIDIA مدعومة مع تعريفات CUDA حديثة مثبَّتة (أو راجع وثائق المشروع لتعليمات تثبيت خاصة بـAMD/Intel/TPU إذا كنت تستهدف إحدى هذه الخلفيات).
- 2أنشئ بيئة بايثون افتراضية، ثم ثبّت vLLM:
pip install vllm. - 3شغّل الخادم المتوافق مع OpenAI بنموذج من Hugging Face، مثال:
vllm serve meta-llama/Llama-3.1-8B-Instruct. - 4لنموذج مكمَّم مسبقًا، مرّر العلم المطابق، مثال:
vllm serve TheBloke/Llama-2-13B-AWQ --quantization awq. - 5للخدمة عبر عدة وحدات معالجة رسومية، أضف علم التوازي الموتري، مثال:
vllm serve <model> --tensor-parallel-size 2لتوزيع النموذج على وحدتي معالجة رسومية. - 6يستمع الخادم افتراضيًا على
http://localhost:8000؛ أرسل طلبًا إلى نقطة النهاية/v1/chat/completionsباستخدام أي مكتبة عميل متوافقة مع واجهة OpenAI، أو باستخدامcurl. - 7وجّه شيفرة عميل OpenAI الحالية إلى خادمك المستضاف ذاتيًا بتغيير عنوان URL الأساسي واسم النموذج فقط.
هل أحتاج إلى وحدة معالجة رسومية لتشغيل vLLM؟
نعم، لأي استخدام يتجاوز الاختبار — الهدف الأساسي والأفضل دعمًا لـ vLLM هو وحدات معالجة رسومية NVIDIA. توجد خلفية تعتمد على المعالج المركزي فقط، لكنها موثّقة بأنها أبطأ بكثير وليست محور تركيز المشروع.
هل يمكنني تشغيل vLLM بنموذج مكمَّم؟
نعم — يدعم vLLM صيغًا مثل AWQ وGPTQ وFP8، وتتوفر العديد من النماذج المكمَّمة مسبقًا بهذه الصيغ على Hugging Face ويمكن خدمتها باستخدام علم --quantization المطابق.
كيف يقارَن vLLM بـ Ollama وLM Studio؟
تستهدف Ollama وLM Studio مشكلة مختلفة عن تلك التي يستهدفها vLLM: منح شخص واحد نموذجًا يمكنه الدردشة معه على جهازه الخاص، بسرعة وبساطة. أما vLLM فيستهدف خدمة عدد كبير من المستخدمين أو التطبيقات المتزامنة بأكبر قدر ممكن من الكفاءة من سعة وحدة معالجة رسومية مشتركة. فئتا الأدوات ليستا بديلين متقاربين لمعظم حالات الاستخدام.
- عادةً ما تُبنى Ollama وLM Studio على llama.cpp أو محركات مشابهة وصيغة نموذج GGUF، محسّنة للاستخدام أحادي المستخدم على أجهزة استهلاكية بما في ذلك الأجهزة التي تعتمد على المعالج المركزي فقط وApple Silicon
- يُبنى vLLM على PagedAttention والتجميع المستمر، محسّن لخدمة وحدة معالجة رسومية عالية التزامن بدلاً من استجابة المستخدم الواحد على أجهزة متواضعة
- تُثبَّت Ollama بأمر واحد دون الحاجة إلى وحدة معالجة رسومية؛ يتوقع vLLM بيئة بايثون، ووحدة معالجة رسومية NVIDIA في معظم عمليات النشر، وتهيئة عبر سطر الأوامر
- تضيف LM Studio واجهة دردشة رسومية لسطح المكتب؛ لا تملك vLLM واجهة رسومية — يُتاح الوصول إليها عبر واجهتها المتوافقة مع OpenAI أو أعلام سطر الأوامر
- يمكن لكل من vLLM والأدوات المبنية على llama.cpp عرض واجهة متوافقة مع OpenAI، لذا غالبًا ما تعمل أدوات الواجهة الأمامية المبنية لتلك الواجهة مع أي منهما
كيف يقارَن vLLM بـ TGI وTensorRT-LLM؟
تستهدف vLLM وText Generation Inference (TGI) من Hugging Face وTensorRT-LLM من NVIDIA جميعها المهمة الواسعة نفسها — خدمة نماذج اللغة الكبيرة في الإنتاج على نطاق واسع — لكن بتصاميم ومقايضات مختلفة.
vLLM
- التفاصيل:
- مرخّص بموجب Apache 2.0، مبني بلغة بايثون، ومبني حول PagedAttention والتجميع المستمر. يحمّل مباشرةً نماذج متوافقة مع Hugging Face Transformers، بتغطية واسعة للمعماريات ودعم خلفيات وحدات معالجة رسومية من عدة موردين (NVIDIA أساسًا؛ وAMD وIntel وTPU موثّقة).
TGI
- التفاصيل:
- محرك الخدمة الخاص بشركة Hugging Face، مرخّص بموجب Apache 2.0، ويدعم أيضًا التجميع المستمر وعدة صيغ تكميم. مندمج بشكل وثيق مع Hugging Face Hub ونظامه البيئي.
TensorRT-LLM
- التفاصيل:
- محرك NVIDIA، مبني خصيصًا لوحدات معالجة رسومية NVIDIA. تُجمَّع النماذج مسبقًا في محرك TensorRT محسَّن لوحدة معالجة الرسومات المستهدفة، مما قد يمنح أداءً قويًا على ذلك الجهاز المحدد، مقابل خطوة تجميع ومرونة أقل بين الأجهزة مقارنة بـ vLLM أو TGI.
لم يُجرِ هذا المقال اختبار أداء مستقلًا لهذه المحركات الثلاثة مقابل بعضها البعض ولا يدّعي أن أحدها أسرع عالميًا — تعتمد الإنتاجية بشدة على النموذج والجهاز وخصائص الدفعات وإصدار كل محرك. راجع دليل خوادم الاستدلال المؤسسية لمقارنة أكثر تفصيلًا للنشر والترخيص للمحركات الثلاثة.
لمن يناسب vLLM؟
يناسب vLLM الفرق التي تخدم نموذجًا لعدد كبير من المستخدمين أو التطبيقات المتزامنة على بنية تحتية لوحدات معالجة الرسومات، وليس الأشخاص الباحثين عن أسرع طريقة للدردشة مع نموذج على حاسوبهم الخاص.
vLLM مقابل البدائل في لمحة
تقع هذه الأدوات في نقاط مختلفة على طيف يمتد من الاستخدام أحادي المستخدم إلى الخدمة الإنتاجية.
vLLM
- الواجهة والتثبيت:
- حزمة بايثون تُثبَّت عبر pip؛ خادم API متوافق مع OpenAI يُشغَّل بأمر
vllm serve. يتطلب وحدة معالجة رسومية NVIDIA وCUDA في معظم عمليات النشر. - الأنسب لـ:
- خدمة وحدة معالجة رسومية عالية الإنتاجية ومتعددة المستخدمين في الإنتاج.
Ollama
- الواجهة والتثبيت:
- واجهة سطر أوامر وواجهة REST، يُذكر عادةً أنها تعمل على llama.cpp كخلفية في معظم المنصات. أمر واحد يثبّتها؛ أمر واحد يسحب النموذج ويشغّله.
- الأنسب لـ:
- أسرع طريق إلى نموذج محلي يعمل لمستخدم واحد، دون خطوة بناء أو وحدة معالجة رسومية مطلوبة.
LM Studio
- الواجهة والتثبيت:
- تطبيق سطح مكتب رسومي لأنظمة Mac وWindows وLinux. حمّله وثبّته، ثم تصفّح النماذج وحمّلها من داخل التطبيق.
- الأنسب لـ:
- المستخدمين غير التقنيين الذين يريدون تطبيق دردشة محلي يُدار بالنقر.
llama.cpp
- الواجهة والتثبيت:
- واجهة سطر أوامر، وواجهة ويب مدمجة، وواجهة API متوافقة مع OpenAI عبر llama-server. ابنِه من المصدر أو استخدم ملفًا ثنائيًا جاهزًا؛ يعمل على المعالج المركزي أو وحدة معالجة الرسومات.
- الأنسب لـ:
- التحكم المباشر على مستوى المحرك، والنشر المدمج/الطرفي، وأجهزة المعالج المركزي أو Apple Silicon.
لم يقارن هذا المقال بشكل مستقل بين سرعة أو جودة مخرجات هذه الأدوات ولا يدّعي تفوّق إحداها تقنيًا — تغطي المقارنة أعلاه فقط حقائق موثّقة عن المعمارية والتثبيت ونموذج الوصول. للحصول على أرقام إنتاجية حسب الجهاز، راجع مقارنة llama.cpp مقابل Ollama مقابل vLLM ودليل خوادم الاستدلال المؤسسية.
ما الذي لا يغطيه هذا المقال؟
هذا مقال تفسيري مبني على الوثائق العامة ومستودع vLLM، وليس تقرير اختبار أداء عملي.
- لا توجد أرقام إنتاجية أو زمن استجابة أو طلبات في الثانية مقيسة بشكل مستقل — تعتمد هذه بشدة على وحدة معالجة الرسومات والنموذج وتركيبة الدفعات وإصدار vLLM
- لا توجد نسب مئوية لفقدان الجودة مُتحقَّق منها بشكل مستقل لصيغ تكميم محددة — تتفاوت هذه حسب معمارية النموذج والمهمة
- لا يوجد تدقيق أمني سطرًا بسطر لشيفرة vLLM — فهي مفتوحة المصدر ومرخّصة بموجب Apache 2.0، لذا الشيفرة نفسها متاحة للمراجعة
- لا تغطية كاملة لكل خلفية جهاز مدعومة، أو علم محرك، أو خيار تنسيق نشر (Kubernetes، إعدادات خاصة بالسحابة) — يركّز هذا المقال على المفاهيم والأعلام التي تقيّمها معظم الفرق أولاً
- لا تغطية لاتفاقيات الدعم التجاري أو عروض الاستضافة المُدارة لـ vLLM، لأن vLLM نفسه مشروع مفتوح المصدر تديره المجتمعة وليس منتج مورّد بعقد دعم
أخطاء شائعة عند تجربة vLLM
يأتي معظم الاحتكاك مع vLLM من التعامل معه كأداة سطح مكتب أحادية المستخدم بدلاً من برنامج خادم إنتاجي.
الأسئلة الشائعة
ما هو vLLM؟
vLLM مكتبة وخادم مجانيان مرخّصان بموجب Apache 2.0 لاستدلال نماذج اللغة الكبيرة عالي الإنتاجية، نشآ في مختبر Sky Computing Lab بجامعة UC Berkeley. يستخدم PagedAttention والتجميع المستمر لخدمة عدد كبير من الطلبات المتزامنة بكفاءة من وحدة معالجة رسومية واحدة.
هل vLLM مجاني؟
نعم. vLLM برنامج مجاني ومفتوح المصدر صادر بموجب رخصة Apache 2.0، دون حاجة إلى اشتراك أو حساب لتشغيله بنفسك.
ما هو PagedAttention؟
PagedAttention هي تقنية vLLM لإدارة ذاكرة التخزين المؤقت KV الخاصة بالانتباه في كتل صغيرة غير متجاورة بحجم ثابت بدلاً من تخصيص متجاور كبير واحد لكل طلب، مما يقلل هدر ذاكرة وحدة معالجة الرسومات ويتيح مشاركة الذاكرة بين الطلبات ذات البادئة المشتركة.
هل يحتاج vLLM إلى وحدة معالجة رسومية؟
نعم لأي حمل عمل حقيقي — الهدف الأساسي والأفضل دعمًا لـ vLLM هو وحدات معالجة رسومية NVIDIA. توجد خلفية تعتمد على المعالج المركزي فقط، لكنها موثّقة بأنها أبطأ بكثير وليست محور تركيز المشروع، ويقتصر دعم Apple Silicon على إضافات يصونها المجتمع بدلاً من مسار من الدرجة الأولى.
ما صيغ التكميم التي يدعمها vLLM؟
يدعم vLLM عدة صيغ منها AWQ وGPTQ وFP8 وINT8/INT4، مع توفر العديد من النماذج المكمَّمة مسبقًا بهذه الصيغ على Hugging Face.
هل vLLM أفضل من Ollama؟
"الأفضل" يعتمد على المهمة: vLLM مبني لخدمة وحدة معالجة رسومية إنتاجية عالية التزامن، بينما Ollama مبني لأسرع طريق إلى نموذج محلي أحادي المستخدم دون الحاجة إلى وحدة معالجة رسومية. لمعظم حالات الاستخدام، ليسا بديلين متقاربين — راجع جدول المقارنة أعلاه.
هل يمكن لـ vLLM خدمة نماذج عبر عدة وحدات معالجة رسومية؟
نعم. يدعم vLLM الخدمة بالتوازي الموتري وتوازي خطوط الأنابيب عبر عدة وحدات معالجة رسومية، ويمكن ضبط ذلك عبر أعلام مثل --tensor-parallel-size عند بدء تشغيل الخادم.
هل يملك vLLM واجهة برمجية متوافقة مع OpenAI؟
نعم. يؤدي تشغيل vllm serve إلى بدء تشغيل خادم يطبّق بروتوكول واجهة OpenAI، بحيث يمكن للعديد من التطبيقات المبنية لواجهة OpenAI الإشارة إلى نسخة vLLM مستضافة ذاتيًا بمجرد تغيير عنوان URL الأساسي واسم النموذج.
كيف يختلف vLLM عن TensorRT-LLM؟
TensorRT-LLM هو محرك NVIDIA، الذي يجمّع النماذج مسبقًا في محرك محسَّن لوحدة معالجة رسومية NVIDIA محددة. يحمّل vLLM مباشرةً نماذج متوافقة مع Hugging Face Transformers دون خطوة تجميع مسبقة، ويوثّق دعمًا لخلفيات تتجاوز وحدات معالجة رسومية NVIDIA وحدها، مقابل تحسين أقل خصوصية بالجهاز لكن مع مرونة أكبر وتكرار أسرع.