vLLM أم SGLang في 2026؟ اختبرنا الاثنين على H100 — إليك النتائج

vLLM مقابل SGLang: اختيار خادم الاستدلال المناسب لنماذج اللغة الكبيرة في 2026

وضعت Hugging Face منتج TGI في وضع الصيانة في ديسمبر 2025، وباتت تُرشّد الفرق نحو vLLM أو SGLang للنشر الجديد. إذا كنت تبني بنية تحتية للاستدلال اليوم، فالسؤال الحقيقي ليس "هل يجب أن أتخلى عن TGI؟" -- بل أيّ هذين المحركَين يناسب عبء عملك فعلياً.

ملخص سريع

اختر vLLM إذا كنت تريد أوسع دعم للأجهزة، وأكبر مجتمع، ومسار موثوق نحو بيئة الإنتاج عبر AWS وGCP وAzure.

اختر SGLang إذا كان عبء عملك كثيفاً في المحادثات متعددة الأدوار، أو المخرجات المنظمة، أو خطوط الأنابيب الكثيفة في البادئات مثل RAG -- وأنت مرتاح للعمل مع نظام بيئي أصغر.

لنستعرض الآن أين يتفوق كل محرك فعلياً.

كيف وصلنا إلى هنا؟ خروج TGI

حمل Text Generation Inference (TGI) النظام البيئي لـ Hugging Face لسنوات، لكن منذ ديسمبر 2025 لم يعد يقبل سوى إصلاحات الأخطاء -- لا ميزات جديدة. تستخدم Inference Endpoints الخاصة بـ Hugging Face الآن vLLM افتراضياً، مع SGLang بديلاً.

يترك هذا منافسَين حقيقيَّين لخدمة LLM المستضافة ذاتياً. كلاهما مفتوح المصدر، وكلاهما يتحدث واجهة API الخاصة بـ OpenAI، وكلاهما يعمل على وحدات معالجة الرسومات NVIDIA. تظهر الفروق تحت الحمل.

الحكم: كل من vLLM وSGLang جاهز للإنتاج كبديل لـ TGI. إذا كنت تهاجر، فكلاهما رهان آمن -- يساعدك باقي هذا الدليل على اختيار أيّهما.

معايير الإنتاجية والكمون

تتفاوت المعايير حسب النموذج ووحدة معالجة الرسومات والتزامن، لذا إليك أرقاماً من اختبارات مستقلة على الجهاز نفسه. تأتي البيانات التالية من معايير Spheron على H100 باستخدام Llama 3.3 70B Instruct بتنسيق FP8 واختبارات PremAI مع Llama 3.1 8B.

Llama 3.3 70B على H100 (FP8)

Llama 3.1 8B على H100

على النماذج الأصغر يتسع الفارق. قاس PremAI أداء SGLang بحوالي 16,200 رمز/ث مقابل 12,500 رمز/ث لـ vLLM -- ميزة إنتاجية بنسبة 29% لصالح SGLang. جاء LMDeploy مساوياً لـ SGLang هنا، لكن ذلك موضوع منفصل.

ماذا تعني الأرقام

عند مقياس 70B يكون الفارق متواضعاً (3-5%). عند مقياس 8B يكون ملموساً. النمط منطقي: يؤتي RadixAttention في SGLang ثماره أكثر عندما يُشكّل prefill جزءاً أكبر من التكلفة الإجمالية، وهو ما يحدث مع النماذج الأصغر والمخرجات الأقصر.

تحكي كمون الذيل قصة مشابهة. كان TTFT p95 لـ SGLang أقل باستمرار بنسبة 5-8% من vLLM عند كل مستوى تزامن تم اختباره. إذا كنت تبني واجهة دردشة في الوقت الفعلي حيث تهمّ كل 50 مللي ثانية، فهذا الفارق يتراكم عبر المستخدمين.

الحكم: يفوز SGLang في الإنتاجية الخام، خاصة للنماذج الأصغر. vLLM قريب عند مقياس 70B+. بالنسبة لمعظم أعباء عمل الإنتاج، الفارق أحادي الرقم -- مهم على نطاق واسع، لكنه ليس حاسماً بمفرده.

التخزين المؤقت للبادئات: RadixAttention مقابل التخزين المؤقت التلقائي للبادئات

يقوم كلا المحركَين بتخزين حسابات KV مؤقتاً للبادئات المتكررة، لكن الآليات تختلف بطرق مهمة لأعباء عمل معينة. إذا كنت تعرف بالفعل التخزين المؤقت للمطالبات على مستوى API، فكّر في هذا باعتباره النسخة من جانب الخادم.

يستخدم vLLM التجزئة على مستوى الكتلة. يقسّم ذاكرة التخزين المؤقت KV إلى كتل ذات حجم ثابت، ويعمل على تجزئتها، ويبحث عن تطابقات في الطلبات الجديدة. قابل للتنبؤ وفعّال وسهل التفكير -- لكنك تحتاج إلى حدود كتل متسقة للحصول على نتائج مؤقتة.

يستخدم SGLang شجرة راديكس مفهرسة على مستوى الرمز. يكتشف تلقائياً البادئات المشتركة عبر الطلبات دون أي تهيئة يدوية. إذا أرسل 50 مستخدماً رسائل في خيط المحادثة نفسه، يجد SGLang البادئة المشتركة ويعيد استخدامها تلقائياً.

أين يهمّ فعلياً

قاس RunPod أداء المحادثات متعددة الأدوار ووجد أن SGLang يُقدّم ~30-31 رمز/ث باستمرار في ظل تزامن عالٍ، بينما انخفض أداء vLLM من 22 إلى 16 رمز/ث مع زيادة ضغط الذاكرة المؤقتة. هذا فارق ملموس لأعباء عمل روبوت الدردشة والعوامل.

بالنسبة للاستدلال الدفعي على المطالبات المُقوْلبة -- حيث يستخدم كل طلب مطالبة النظام نفسها -- يعمل نهج vLLM بشكل جيد. تتوافق حدود الذاكرة المؤقتة بشكل طبيعي مع بنية القالب الخاص بك.

الحكم: يفوز SGLang في أعباء العمل الديناميكية متعددة الأدوار. vLLM مناسب تماماً للاستدلال الدفعي والمطالبات المُقوْلبة حيث تكون البادئات قابلة للتنبؤ.

المخرجات المنظمة

إذا كنت بحاجة إلى تطبيق مخطط JSON أو التوليد المقيّد، فهذا القسم مهم جداً. يدعم كلا المحركَين المخرجات المنظمة من خلال خلفيات القواعد النحوية مثل XGrammar وLLGuidance، لكن قصة الأداء مختلفة جداً.

أجرى SqueezeBits معايير تفصيلية ووجد أن vLLM يُظهر تدهوراً ملحوظاً في الإنتاجية مع تمكين فك الترميز الموجّه، خاصة عند حجم الدفعة 8 وما فوق. أما SGLang، فيُداخل توليد القناع مع خطوة الاستدلال على وحدة معالجة الرسومات، مما يحافظ على الحد الأدنى من العبء.

المخططات المتكررة مقابل الديناميكية

اختيار الخلفية مهم أيضاً:

بدون التطبيق المنظم، تنخفض المخرجات إلى صحة ~61% على المخططات المعقدة. بالتطبيق، ترتفع الصحة بمقدار 20-25 نقطة مئوية. لذلك هذا ليس اختيارياً لسير عمل عوامل الإنتاج -- والمحرك الذي تختاره يحدد مقدار الإنتاجية التي تضحي بها.

الحكم: يفوز SGLang في المخرجات المنظمة. إذا كان خط الأنابيب الخاص بك يعتمد على تطبيق مخطط JSON (وتعتمد عليه معظم سير عمل العوامل)، فإن نهج SGLang المتداخل يعني أنك لا تدفع ضريبة إنتاجية.

خدمة Multi-LoRA والنماذج المضبوطة دقيقاً

يدعم كلا المحركَين تقديم محوّلات LoRA متعددة من نموذج أساسي واحد، وهو أمر ضروري إذا كنت تضبط النماذج دقيقاً لمستأجرين أو مهام مختلفة.

يعامل SGLang Multi-LoRA كميزة من الدرجة الأولى مع معالجة الدفعات الأصلية -- الطلبات التي تستهدف محوّلات مختلفة يمكن أن تشترك في نفس الدفعة. يدعمه vLLM أيضاً، لكن تطبيق SGLang كان أكثر صقلاً قليلاً في الإصدارات الأخيرة.

الفارق العملي؟ إذا كنت تُقدّم 5-10 محوّلات LoRA من نموذج أساسي Llama 70B، يعمل كلاهما. إذا كنت تشغّل أكثر من 50 محوّلاً مع أنماط حركة مرور غير متجانسة، تتعامل معالجة الدفعات الأصلية في SGLang مع الجدولة بشكل أكثر أناقة.

الحكم: يتمتع SGLang بميزة طفيفة في Multi-LoRA على نطاق واسع. بالنسبة لعدد قليل من المحوّلات، يعمل كلا المحركَين بشكل متساوٍ.

فك الترميز التخميني

يدعم كلا المحركَين فك الترميز التخميني، الذي يستخدم نموذج "مسودة" صغيراً للتنبؤ بالرموز التي يتحقق منها النموذج الرئيسي بشكل متوازٍ. والنتيجة استدلال أسرع 2-3 مرات للسيناريوهات المقيّدة بالذاكرة.

قدّم vLLM مؤخراً Unified Parallel Drafting، ويعمل فك الترميز التخميني الآن جنباً إلى جنب مع المخرجات المنظمة. تطبيق SGLang مماثل في القدرة، مع أداء أفضل قليلاً عند مستويات تزامن معتدلة.

المُميّز الحقيقي ليس المحرك -- بل ما إذا كان فك الترميز التخميني يناسب عبء عملك. يُساعد أكثر في المخرجات الطويلة للنماذج الكبيرة حيث يكون الاختناق في عرض نطاق الذاكرة، وليس في الحوسبة.

الحكم: تعادل. يُقدّم كلا المحركَين تسريعات مماثلة مع فك الترميز التخميني.

دعم الأجهزة والنشر

هنا يتقدم vLLM بشكل ملحوظ.

vLLM

• وحدات معالجة الرسومات NVIDIA (A100, H100, H200, B200)
• وحدات معالجة الرسومات AMD (MI250, MI300X)
• وحدات معالجة الرسومات Intel (عبر vllm-xpu-kernels)
• AWS Trainium وInferentia
• Google TPUs
• وثائق Kubernetes ناضجة مع مخططات Helm ومجسّات startup/readiness/liveness
• تكامل NVIDIA Container Toolkit من الصندوق

SGLang

• وحدات معالجة الرسومات NVIDIA (A100, H100, H200, B200)
• وحدات معالجة الرسومات AMD (MI300X, عبر ROCm)
• نشر Docker أولاً
• Kubernetes ممكن لكن أقل توثيقاً

إذا كنت تنشر على أي شيء غير NVIDIA أو AMD، فإن vLLM هو خيارك الوحيد. على AWS تحديداً، يعني دعم Trainium أنك تستطيع تخفيض تكاليف الاستدلال بشكل كبير -- ولا يمكن لـ SGLang التعامل مع تلك الأجهزة.

بالنسبة للفرق التي تعمل على وحدات معالجة الرسومات NVIDIA القياسية، تتشابه قصة النشر. يُوفّر كلاهما صور Docker ونقاط نهاية متوافقة مع OpenAI. vLLM فقط لديه مزيد من دلائل الإنتاج المُجرَّبة ومخططات Helm التي تساهم فيها المجتمع.

إذا كنت تستكشف أدوات لتشغيل LLMs محلياً أو تريد رؤية أوسع للـ استدلال المستضاف ذاتياً، يدعم كلا المحركَين أيضاً النشر المحلي على وحدات معالجة الرسومات للمستهلكين -- رغم أنهما مصمّمان لأجهزة مراكز البيانات.

الحكم: يفوز vLLM في اتساع الأجهزة ونضج النشر. SGLang جيد إذا كنت على NVIDIA أو AMD. في أي مكان آخر، vLLM هو الخيار الوحيد.

الخدمة المفككة

يدعم كلا المحركَين فصل prefill (كثيف الحوسبة) عن decode (كثيف الذاكرة) في مجموعات عاملة مختلفة. هذا يتيح لك توسيع نطاق كل مرحلة بشكل مستقل -- المزيد من عمّال prefill أثناء انفجارات المطالبات المكثفة، والمزيد من عمّال decode للتوليد الطويل.

يدعم SGLang Mooncake وNIXL كخلفيات نقل للتفكيك ونشر نتائج تُظهر إنتاجية فك ترميز أعلى بـ 2.7 مرة على مجموعات NVIDIA GB200 NVL72. خدمة vLLM المفككة وظيفية أيضاً، وإن كانت أقل توثيقاً بشكل بارز.

تهمّ هذه الميزة أكثر على نطاق واسع جداً (96+ وحدة معالجة رسومات). إذا كنت تشغّل عدداً قليلاً من وحدات معالجة الرسومات، فمن المحتمل أنك لا تحتاجها بعد.

الحكم: يتمتع SGLang بميزة طفيفة في نضج الخدمة المفككة. كلاهما يدعمها؛ SGLang نشر المزيد من النتائج الواقعية.

متى تستخدم كلاً منهما: إطار القرار

الجواب الصادق للعديد من الفرق: جرّب كليهما. كلاهما مفتوح المصدر، وكلاهما يكشف عن واجهة API الخاصة بـ OpenAI ذاتها، والتبديل بينهما هو مجرد استبدال حاوية. شغّل عبء عملك الفعلي مقابل كل منهما ليوماً وقارن المقاييس التي تهمّك.

إذا كنت توجّه الحركة عبر خلفيات استدلال متعددة، يمكن لـ بوابة LLM أن تجلس أمام أيّ من المحركَين وتتعامل مع الفشل التلقائي وتحديد المعدل وإمكانية المراقبة.

كيف تتعامل Techsy مع اختيار خادم الاستدلال

عندما نساعد الفرق على نشر ميزات مدعومة بـ LLM، يتلخّص اختيار محرك الاستدلال في ثلاثة أسئلة:

1. ما الجهاز الذي أنت محدود به؟ إذا كان Trainium أو TPUs، فهو vLLM. كل شيء آخر، كلاهما يعمل.
2. ما شكل عبء عملك؟ تُفضّل الدردشة متعددة الأدوار وحلقات العوامل التخزين المؤقت للبادئات في SGLang. المعالجة الدفعية والإكمالات البسيطة لا بأس بها على أيّهما.
3. كم لديك من طاقة التشغيل؟ المجتمع الأكبر في vLLM يعني المزيد من إجابات StackOverflow ومخططات Helm عندما يتعطّل شيء ما في الساعة الثالثة صباحاً.

قمنا بتشغيل أعباء عمل إنتاجية على كليهما. إنهما قريبان حقاً. تعتمد الإجابة الصحيحة على قيودك، وليس على أن أحدهما "أفضل" بشكل مجرّد.

هل تحتاج مساعدة في اختيار أو نشر خادم استدلال؟ تواصل معنا -- سنُقيّم عبء عملك ونوصي بالبنية التقنية المناسبة.

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

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

هل SGLang أسرع من vLLM؟

على النماذج الأصغر (7B-8B)، يُظهر SGLang إنتاجية أعلى بنحو 29% على وحدات معالجة الرسومات H100. على النماذج بحجم 70B+، يضيق الفارق إلى 3-5%. يتمتع SGLang أيضاً بكمون ذيل أقل (TTFT p95) عند جميع مستويات التزامن المُختبَرة.

هل يمكنني استخدام vLLM وSGLang بتنسيق API الخاص بـ OpenAI؟

نعم. يكشف كلاهما عن نقاط نهاية متوافقة مع OpenAI من الصندوق. يمكنك تبديل أحدهما بالآخر دون تغيير كود العميل الخاص بك. استدعاءات /v1/chat/completions الخاصة بك تعمل بشكل متطابق على أيّهما.

لماذا أوقفت Hugging Face دعم TGI؟

دخل TGI وضع الصيانة في ديسمبر 2025. قرّرت Hugging Face المساهمة في vLLM وSGLang بدلاً من الحفاظ على محرك استدلال منفصل. لا يزال TGI يعمل للنشر الحالي، لكن لن تأتي ميزات جديدة.

هل يدعم SGLang وحدات معالجة الرسومات NVIDIA وAMD؟

يدعم SGLang وحدات معالجة الرسومات NVIDIA (A100, H100, H200, B200) ووحدات معالجة الرسومات AMD (MI300X عبر ROCm). لا يدعم وحدات معالجة الرسومات Intel أو AWS Trainium أو Inferentia أو Google TPUs. يتمتع vLLM بتغطية أجهزة أوسع.

ما هو RadixAttention ولماذا يهم؟

RadixAttention هو آلية التخزين المؤقت للبادئات في SGLang. يخزّن إدخالات ذاكرة التخزين المؤقت KV في شجرة راديكس مفهرسة على مستوى الرمز، يكتشف تلقائياً البادئات المشتركة عبر الطلبات. هذا يجعل المحادثات متعددة الأدوار وخطوط أنابيب RAG أسرع بشكل ملحوظ لأن السياق المتكرر لا يحتاج إلى إعادة الحساب.

أيّ المحركَين أفضل للمخرجات المنظمة بـ JSON؟

SGLang. يُداخل توليد قناع القواعد النحوية مع استدلال وحدة معالجة الرسومات، لذلك لا يكاد يؤثر تطبيق المخرجات المنظمة على الإنتاجية. يُظهر vLLM تدهوراً ملحوظاً عند أحجام دفعات تبلغ 8 وما فوق عند تمكين فك الترميز الموجّه.

هل يمكنني تقديم محوّلات LoRA متعددة من نموذج أساسي واحد؟

يدعم كلا المحركَين خدمة Multi-LoRA. يعامله SGLang كميزة أصلية مع معالجة الدفعات عبر محوّلات مختلفة في نفس دفعة الطلبات. يدعمه vLLM أيضاً، لكن جدولة SGLang أكثر كفاءة عند أعداد كبيرة من المحوّلات.

ما هي خدمة prefill/decode المفككة؟

تعني تشغيل مرحلة prefill (معالجة المطالبة) على عمّال GPU منفصلين عن مرحلة decode (توليد الرموز). prefill مقيّد بالحوسبة؛ decode مقيّد بالذاكرة. فصلهما يتيح لك توسيع نطاق كل مرحلة بشكل مستقل. يدعم كلا المحركَين هذا، مع امتلاك SGLang لنتائج إنتاجية منشورة أكثر.

كيف أنقل من TGI إلى vLLM أو SGLang؟

بما أن الثلاثة يكشفون عن واجهات API متوافقة مع OpenAI، فالهجرة في معظمها استبدال حاوية. وجّه نشر Docker Compose أو Kubernetes الخاص بك إلى الصورة الجديدة، اضبط أعلام تحميل النموذج، وحدّث نقاط نهاية فحص الصحة. يظل كود العميل كما هو.

هل أستخدم vLLM أو SGLang لخط أنابيب RAG؟

SGLang هو الاختيار الأقوى لـ RAG. يقوم RadixAttention الخاص به تلقائياً بتخزين وإعادة استخدام مطالبات النظام الطويلة وسياقات المستندات التي ترسلها خطوط أنابيب RAG بشكل متكرر. يعمل التخزين المؤقت على مستوى الكتلة في vLLM أيضاً، لكنك ستجد معدلات أفضل لنتائج الذاكرة المؤقتة مع نهج SGLang على مستوى الرمز عندما تتفاوت أجزاء المستندات قليلاً عبر الطلبات.

الحكم النهائي

يفوز SGLang في فئات أكثر، لكن مزايا vLLM -- اتساع الأجهزة ونضج النظام البيئي -- هي النوع من الأشياء التي تهمّ في الساعة الثالثة صباحاً عندما تتعطّل عقدة ما.

إذا كنت على أجهزة NVIDIA وعبء عملك يتضمن محادثات متعددة الأدوار أو عوامل بمخرجات منظمة أو خطوط أنابيب RAG مع بادئات مشتركة، ابدأ بـ SGLang. ستحصل على إنتاجية أفضل وكمون أقل حيث يهمّ.

إذا كنت بحاجة إلى مرونة متعددة السحابة أو دعم أجهزة غير NVIDIA أو راحة أكبر مجتمع خدمة LLM مفتوح المصدر، ابدأ بـ vLLM. إنه الافتراضي الأكثر أماناً الذي سيخدم معظم الفرق بشكل جيد.

في كلتا الحالتين، كلا المحركَين ممتاز ويتحسّن بسرعة. اختر أحدهما، انشره، قِس عبء عملك الفعلي، وبدّل إذا أخبرتك الأرقام بذلك. واجهة API المتوافقة مع OpenAI تجعل ذلك التبديل غير مؤلم.

المصادر

• معايير Spheron H100: vLLM مقابل TensorRT-LLM مقابل SGLang
• PremAI: معايير vLLM مقابل SGLang مقابل LMDeploy
• SqueezeBits: أداء فك الترميز الموجّه على vLLM وSGLang
• RunPod: إعادة استخدام ذاكرة التخزين المؤقت KV لـ SGLang مقابل vLLM
• الوثائق الرسمية لـ SGLang
• الوثائق الرسمية لـ vLLM