- في إل إل إم هو الخيار الآمن الافتراضيأوسع دعم للنماذج والأجهزة، وأكبر نظام بيئي، وأقل تعقيد في النشر.
- اختر SGLang عندما يعيد حملك التشغيلي استخدام بادئات المُدخلات (prompts) بشكل مكثف (مثل الوكلاء، أو الدردشة متعددة الدورات، أو المُدخلات النظامية الطويلة)، أو عند إنتاج كمٍّ كبير من المخرجات المنظمة بصيغة JSON — فهنا تتفوق تقنيتا RadixAttention والفك التخطي القافز (jump-forward decoding).
- الفجوة في الأداء تعتمد على نوع الحمل التشغيلي، وتتقلص مع كل إصدار جديد. وكلا المحركين يدعمان واجهة برمجة تطبيقات OpenAI، لذا فإن اختبار أحدهما مقابل الآخر باستخدام حملك التشغيلي الفعلي لا يتطلب جهدًا أو تكلفة كبيرة.
- لا يعمل أيٌّ منهما أصليًّا على أنظمة ويندوز أو ماك أو إس — استخدم لينكس (أو WSL2)، أو أداة سطح مكتب مثل أولاما/إل إم ستوديو للاستخدام المحلي.
في إل إل إم وSGLang هما المحركان الرائدين مفتوحا المصدر لتشغيل نماذج اللغة الكبيرة على وحدات معالجة الرسوميات الخاصة بك، وللغالبية العظمى من الفِرق في إل إل إم هو الخيار الآمن الافتراضييدعمان عددًا أكبر من النماذج، وعددًا أكبر من واجهات الأجهزة الخلفية، ونظامًا بيئيًّا أوسع. اختر SGLang عندما يهيمن على حملك التشغيلي تكرار بادئات المُدخلات المشتركة — مثل الوكلاء، أو الدردشة متعددة الدورات، أو المُدخلات النظامية الطويلة — أو عند إنتاج مخرجات منظمة بشدة بصيغة JSON، حيث تمنحه تقنية ذاكرة التخزين المؤقت RadixAttention وتقنية فك التشفير القائمة على القواعد ميزة حقيقية. وكلا المحركين يقدِّم واجهة برمجة تطبيقات متوافقة مع OpenAI، لذا فإن التحوُّل بينهما لاحقًا لا يكلِّف تقريبًا شيئًا.
يقارن هذا الدليل المحركين بالطريقة التي ستختار بها فعليًّا: ما الذي يركِّز عليه كل مشروع، وكيف تختلف تقنيتا RadixAttention وPagedAttention في التطبيق العملي، وأين يتفوق كل منهما في الإنتاجية (throughput) والتأخير (latency)، مع توصية واضحة حسب نوع الحمل التشغيلي.
ما الذي يركِّز عليه كل مشروع
في إل إل إم بدأ المشروع في جامعة كاليفورنيا في بيركلي عام 2023 باعتباره التنفيذ المرجعي لورقة بحث PagedAttention، وتطور منذ ذلك الحين ليصبح المحرك المفتوح المصدر القياسي لتشغيل النماذج، وهو الآن مشروع تابع لمؤسسة PyTorch. وتتمحور أولوياته حول الشمولية والمتانة: تشغيل ما يقرب من كل النماذج المفتوحة الوزن على ما يقرب من كل وحدة تسريع — سواء كانت وحدات إنفيديا CUDA، أو AMD ROCm، أو إنتل، أو وحدات معالجة الرسوميات Google TPU، أو وحدات AWS Neuron، بل وحتى وحدات المعالجة المركزية x86 — مع تحقيق إنتاجية عالية جدًّا افتراضيًّا. وعادةً ما تحصل عائلات النماذج الجديدة على دعم في إل إل إم في اليوم الأول أو قريبًا منه.
SGLang ينبع من فريق LMSYS المسؤول عن منصة Chatbot Arena. ويركِّز هذا المشروع على أمرين محددين: إعادة استخدام ذاكرة التخزين المؤقت KV (RadixAttention) و التوليد الهيكلي السريع. الاسم مختصر لـ Structured Generation Language — وقد أُطلق في الأصل مع لغة برمجة نصية (DSL) بلغة بايثون لتسلسل واستدعاءات النماذج اللغوية الكبيرة (LLM) وفرعها — لكن وقت التشغيل الخاص بالخدمة هو ما يُنشر عادةً اليوم. ولديه سجل إنتاجي قوي: فقد كان من بين محركات الخدمة التي أُوصي بها عند الإطلاق الرسمي للإصدار الثالث (V3)، وهو معروف بتحسيناته الجريئة المتعددة لوحدات معالجة الرسومات (Multi-GPU) (مثل فصل مرحلتي التحضير والفكّ، والتوازي الواسع للمُختصين في نماذج MoE). ديب سيك تتناول التقنيتان الرئيسيتان مشكلتين مختلفتين، كما أن أسماءهما تُوحي خطأً بأن أحدهما يُستبعد لصالح الآخر.
RadixAttention مقابل PagedAttention، بلغة مبسَّطة
PagedAttention (vLLM) هي آلية لإدارة الذاكرة.
فهي تخزن ذاكرة التخزين المؤقت KV في كتل ذات أحجام ثابتة، على غرار طريقة نظام التشغيل في إدارة الذاكرة الافتراضية عبر الترحيل (paging)، بدلًا من تخصيص قطعة واحدة كبيرة متصلة من الذاكرة لكل طلب. وهذا يقلل التجزئة إلى حدٍ كبير، مما يسمح بإدخال عدد أكبر بكثير من التسلسلات المتزامنة ضمن نفس سعة الذاكرة العشوائية للوحدة الرسومية (VRAM)، وبالمقابل تؤدي الدفعات الأكبر إلى ارتفاع معدل الإنتاجية. وهي تتعلق بـ إدخال المزيد داخل الذاكرة المتوفرة إدخال المزيد داخل الذاكرة المتوفرة.
RadixAttention (SGLang) هي آلية لإعادة استخدام الذاكرة. فهي تنظّم ذاكرة التخزين المؤقت KV على هيئة شجرة راديكس (radix tree) تكون مفاتيحها تسلسلات الرموز (tokens). وعند ورود طلب جديد، يقوم المحرك بالتنقّل عبر الشجرة للعثور على أطول بادئة متطابقة، ويتجاهل إعادة حسابها. وتُحسب مقدّمات النظام (system prompts) وأمثلة التعلّم القليل (few-shot examples) وتاريخ المحادثات ومساحات العمل المؤقتة الخاصة بالوكلاء (agent scratchpads) التي تتكرر عبر الطلبات مرة واحدة فقط في مرحلة التحضير (prefill) ثم تُعاد استخدامها. وهي تتعلق بـ إجراء عمليات حسابية أقل.
وفي عام 2026، اقتربت المحركان من التقارب أكثر مما توحي به أسماؤهما التجارية: فقد أضاف vLLM خاصية التخزين المؤقت التلقائي للبادئات (prefix caching) — وهي مُفعّلة افتراضيًا في الإصدارات الحديثة — كما أن SGLang يستخدم أيضًا تقنية الترحيل (paging) في إدارة ذاكرته. أما الفرق العملي المتبقي فهو أن SGLang صُمم منذ اليوم الأول حول مبدأ إعادة الاستخدام — إذ إن جدول تشغيله (scheduler) يراعي التخزين المؤقت، ويُرتّب الطلبات ويوجّهها لتحقيق أعلى معدل استفادة (hit rate). والقاعدة العامة هي: كلما زادت نسبة البادئات المتكررة في طلباتك النموذجية، زادت الفائدة المحققة من تصميم SGLang.
وبأي حال، فإن ذاكرة التخزين المؤقت KV تتنافس مع أوزان النموذج على نفس الذاكرة المخصصة لوحدة معالجة الرسومات (GPU)، أما هامش التزامن (concurrency headroom) فهو ما يوفّره محرك الخدمة فعليًّا. لذا استخدم حاسبة الذاكرة عالية السرعة VRAM حاسبة الذاكرة هذه
الإنتاجية والتأخير: أين يتفوق كل منهما
| الحمل التشغيلي | عادةً ما يكون أسرع | لماذا |
|---|---|---|
| المحادثات متعددة الدورات، حلقات الوكلاء، مقدمات النظام المشتركة الكبيرة | SGLang | RadixAttention تتجاهل إعادة تحضير البادئات المتكررة، مما يقلل زمن الوصول إلى أول رمز (time-to-first-token) ويحرر قوة الحوسبة |
| طلبات فردية ذات تداخل ضئيل (مستندات فريدة، تلخيص دفعات) | متساوي تقريبًا | يستخدم كلاهما التجميع المستمر (continuous batching) والتحضير المجزّأ (chunked prefill)؛ ونادرًا ما تُفعّل إعادة الاستخدام من الذاكرة المؤقتة |
| إخراج JSON عالي الحجم أو مقيد بالشكل | SGLang | يُولِّد فك التشفير القافز (jump-forward decoding) رموزًا مُجبَرة بواسطة القواعد دون الحاجة إلى تمريرة أمامية (forward pass) للنموذج |
| حديقة نماذج متنوعة، كميات غير تقليدية (quantisation)، أجهزة غير تابعة لشركة NVIDIA | في إل إل إم | تغطية أوسع للبنية التحتية والصيغ تعني وجود مسارات احتياطية غير مُحسَّنة أقل |
اعتبر أي أرقام محددة للأداء تجدها عبر الإنترنت مرتبطة بالإصدار الذي تم قياسها عليه. فكلا المشروعين يُصدران تحسينات باستمرار، وكل منهما نشر مقاييس أداء تفوّق فيها على الآخر. والإجابة الصادقة هي أنه في حركة المرور المُفضِّلة لإعادة الاستخدام من الذاكرة المؤقتة (cache-friendly traffic)، يتفوق SGLang عادةً؛ بينما في حركة المرور التي لا تحتوي على ذاكرة مؤقتة سابقة (cold-cache traffic)، يكون الأداء متكافئًا تقريبًا؛ والمقياس الوحيد الذي يهم حقًّا هو اختبارك الشخصي: فكلا المشروعين يوفّر أدوات لاختبار الأحمال (vLLM تقدّم vllm bench serve، وSGLang تقدّم python -m sglang.bench_serving)، والتي تقوم بإعادة تشغيل تدفقات طلبات واقعية.
المخرجات المنظمة والمقيَّدة
يمكن لكلا المحركين إجبار الإخراج على الامتثال لمخطط JSON أو تعبير منتظم أو قاعدة نحوية، وذلك عبر المعامل المُتوافق مع واجهة OpenAI response_format بالإضافة إلى امتدادات مُخصصة لكل محرك.
وكان SGLang الرواد في تطوير المسار السريع هنا: فهو يحوّل القيود إلى آلة حالة منتهية (finite-state machine) مضغوطة، ويستخدم فك التشفير القافز (jump-forward decoding) — فعندما تجعل القواعد الرموز التالية عدة رموز محددة بشكل قاطع (أقواس، علامات اقتباس، أسماء مفاتيح ثابتة)، فإنه يُلحّقها مباشرةً بدلًا من تشغيل النموذج لكل رمز منها. وفي خطوط معالجة الاستخراج التي تُنتج ملفات JSON غنية بالرموز، يشكّل ذلك تسريعًا ملموسًا.
يدعم vLLM نفس الفئة من القيود عبر واجهات خلفية قابلة للتوصيل (pluggable grammar backends) مثل xgrammar وguidance وoutlines، وبما أن كلا المشروعين اعتمدا xgrammar كواجهة خلفية افتراضية، فقد ضاقت الفجوة بينهما بشكل كبير. الحكم النهائي: كلا المحركين جاهزان للإنتاج؛ لكن SGLang لا يزال يتمتع بميزة في مهام العمل عالية الحجم والشديدة التنظيم.
النظام البيئي، ودعم الأجهزة، وسهولة النشر
| في إل إل إم | SGLang | |
|---|---|---|
| المصدر | جامعة كاليفورنيا في بيركلي؛ مشروع تابع لمؤسسة PyTorch | LMSYS (فريق Chatbot Arena) |
| الأجهزة | NVIDIA، AMD ROCm، Intel، Google TPU، AWS Neuron، وحدات معالجة مركزية x86 | دعم كامل لـ NVIDIA، ودعم لـ AMD ROCm؛ بينما الدعم للمنصات الأخرى أقل نضجًا |
| تغطية النماذج | الأوسع بين جميع المحركات، بما في ذلك العديد من النماذج متعددة الوسائط والمعماريات المتخصصة | جميع العائلات الرئيسية (Llama، Qwen، DeepSeek، Mistral، GPT-OSS...)، مع قائمة أقصر للنماذج الأقل انتشارًا |
| التكميم | FP8، AWQ، GPTQ، INT8، bitsandbytes، وغيرها | FP8، AWQ، GPTQ؛ وقائمة أضيق |
| واجهة برمجة التطبيقات (API) | متوافق مع واجهة OpenAI، المنفذ الافتراضي 8000 | متوافق مع واجهة OpenAI، المنفذ الافتراضي 30000 |
| صورة Docker | vllm/vllm-openai | lmsysorg/sglang |
يبدأ التشغيل بكل سهولة عبر أمر واحد لكل منهما على نظام لينكس مزوّد ببيئة CUDA:
pip install vllm ثم vllm serve Qwen/Qwen2.5-7B-Instruct — ويُوفّر واجهة برمجية متوافقة مع OpenAI على المنفذ 8000.
pip install "sglang[all]" ثم python -m sglang.launch_server --model-path Qwen/Qwen2.5-7B-Instruct — نفس هيكل الواجهة البرمجية على المنفذ 30000.
التوازي التنسوري متعدد وحدات معالجة الرسومات (Multi-GPU tensor parallelism) يتم تحديده عبر --tensor-parallel-size 2 في vLLM و --tp 2 في SGLang. وكلاهما يسحب الأوزان مباشرةً من Hugging Face. ولتحديد البطاقة المناسبة، راجع الدليل الخاص بـ أفضل وحدات معالجة الرسوميات لتشغيل نماذج اللغة الكبيرة محليًّا وتحقَّق من متطلبات النموذج الفردي في قسم قاعدة بيانات النماذج.
أين تكمن الفروقات في سهولة الاستخدام: وثائق vLLM وأدوات Kubernetes والإجابات المجتمعية أكثر انتشارًا بكثير — ومن المرجح أن تجد حلاً لمشكلات نادرة عبر قضايا GitHub المحلولة. أما عمليات تثبيت SGLang فهي أحيانًا أكثر تطلبًا فيما يخص توافق إصدارات CUDA/PyTorch؛ ويُعد الصورة الافتراضية (Docker image) هي المسار الأقل تعقيدًا.
دعم المنصات
لينكس
المنصة الوحيدة المدعومة رسميًّا لكليهما. وبطاقات الرسوميات من NVIDIA مع برنامج تشغيل حديث متوافق مع CUDA تشكِّل المسار القياسي؛ بينما يعمل ROCm من AMD على كلا المحركين مع بطاقات مدعومة. واستخدم الصور الرسمية لـ Docker للحد الأدنى من مشكلات التوافق بين الإصدارات.
ويندوز
لا يدعم أيٌّ من المحركين نظام Windows بشكل أصلي. وكلاهما يعمل تحت WSL2 مع برنامج تشغيل WSL CUDA من NVIDIA، وهذه التهيئة مناسبة تمامًا للتطوير. أما للتشغيل في بيئة إنتاجية، فاستخدم مضيفًا حقيقيًّا يعمل بنظام Linux. وإذا كنت ترغب فقط في تشغيل نموذج محلي على جهاز كمبيوتر شخصي يعمل بنظام Windows بدلًا من نقطة نهاية لخدمة الاستعلامات، فإن أولاما هو الأداة الأبسط.
ماك أو إس
لا يوجد دعم لتشغيل النماذج على وحدات معالجة الرسوميات (GPU) في معالجات Apple Silicon من أيٍّ من المشروعين. ويمكن بناء vLLM من الكود المصدري للاستدلال على وحدة المعالجة المركزية (CPU-only) فقط في نظام macOS، لكن هذا يُعتبر تسهيلًا للتطوير وليس هدفًا للنشر؛ أما SGLang فلا يستهدف نظام macOS إطلاقًا. وللاستدلال المحلي على أجهزة Mac، استخدم Ollama أو إل إم ستوديو، اللذين يستفيدان من تسريع وحدة معالجة الرسوميات عبر تقنية Metal من Apple.
أيُّهما تختار، حسب نوع الحمل التشغيلي
- محادثات الروبوتات (Chatbots)، والمساعدون، وإطارات العمل الخاصة بالوكلاء (agent frameworks) — مثل الأوامر النظامية الطويلة، والأدوات، وتاريخ المحادثات المتعددة: SGLang. وهذا بالضبط نوع الحركة المرورية التي صُمِّمت خوارزمية RadixAttention خصيصًا للتعامل معها.
- الاستخراج المنظَّم عالي الحجم — التصنيف والاستخراج إلى تنسيق JSON على نطاق واسع: SGLang، لفك التشفير القافز للأمام (jump-forward decoding).
- معالجة الدفعات المكوَّنة من وثائق فريدة — مثل التلخيص، وأنابيب استخلاص المتجهات (embeddings-adjacent pipelines) ذات التداخل الضئيل في الأوامر: في إل إل إم؛ حيث لن تفيد إعادة استخدام ذاكرة التخزين المؤقت (cache reuse)، كما أن أدوات vLLM أعمق في هذه السياقات.
- استخدام العديد من النماذج المختلفة، أو أجهزة غير تابعة لشركة NVIDIA — مثل بطاقات AMD أو Intel أو وحدات معالجة الذكاء الاصطناعي من Google (TPU) أو Amazon Inferentia أو نقاط التحقق (checkpoints) المُكمَّنة بشكل غير تقليدي: في إل إل إم، ولا جدال في تفوُّقه الواضح من حيث التغطية.
- إذا لم تكن متأكدًا: ابدأ باستخدام vLLM أولًا، ثم قارن أداؤه مع SGLang عبر اختبار A/B باستخدام سجلات طلباتك الفعلية. وتوفر واجهة برمجة التطبيقات (API) المتوافقة مع OpenAI تبديل المحركين بسهولة تامة عبر تغيير عنوان URL الأساسي فقط.
وبالإضافة إلى ذلك، وقبل الالتزام بأيٍّ من المحركين، تأكَّد من أن الاستضافة الذاتية (self-hosting) أفضل من مجرد استدعاء واجهة برمجة تطبيقات خارجية عند حجم طلباتك — حيث يقوم حاسبة نقطة التعادل بين الاستضافة الذاتية وواجهة برمجة التطبيقات API بإجراء هذه المقارنة الحسابية لكل نموذج وحمولة طلبات.
الأسئلة الشائعة
هل يتفوق SGLang في السرعة على vLLM؟
نعم، عادةً ما يكون الأمر كذلك في حالات العمل التي تتضمَّن إعادة استخدام واسعة للمقدمة (prefix reuse) أو إخراج منظم؛ وقد يكون التفوق كبيرًا أحيانًا. أما في حالات الأوامر الفردية التي لا توجد فيها ذاكرة تخزين مؤقت سابقة (cold-cache)، فالأداء متشابه جدًّا بين المحركين، وقد تتغير النتائج بين الإصدارات المختلفة. لذا يُوصى بإجراء الاختبارات على أنماط حركة مرورك الفعلية بدلًا من الاعتماد على أي رقم منشور واحد.
هل يمكنني استخدام مكتبة Python SDK الخاصة بـ OpenAI مع كليهما؟
نعم. فكلا المحركين يوفِّر واجهة برمجة تطبيقات (API) متوافقة مع OpenAI /v1/chat/completions ، وبالتالي فإن توجيه معلَّمة base_url في المكتبة الرسمية إلى http://localhost:8000/v1 (لـ vLLM) أو http://localhost:30000/v1 (لـ SGLang) يعمل بشكل طبيعي مع أي مفتاح وهمي (placeholder API key). وهذا ما يجعل اختبار A/B بينهما شبه مجاني.
أليس لدى vLLM أيضًا خاصية التخزين المؤقت للمقدمة (prefix caching)؟
نعم، لديه ذلك — فالتخزين المؤقت التلقائي للمقدمة مفعَّل افتراضيًّا في الإصدارات الحديثة، وهو يعيد استخدام كتل KV (Key-Value) التي تتطابق محتوياتها المشفرة (hashed content). أما خوارزمية SGLang القائمة على شجرة الجذر (radix tree) فتتماشى مع المحتوى بدقة أعلى، ومُجدوله (scheduler) يرتِّب الطلبات بنشاط لرفع معدل التوافق (hit rate)، ولذلك يظل أداء SGLang متفوقًا في حالات الحركة المرورية التي تعتمد بشدة على التخزين المؤقت.
أي محرك يدعم عددًا أكبر من النماذج؟
vLLM بلا شك — فقائمته للهياكل المدعومة هي الأطول بين جميع المحركات المفتوحة المصدر، خاصةً فيما يتعلق بالنماذج متعددة الوسائط والنماذج المتخصصة. أما SGLang فيغطي كل العائلات الرئيسية المفتوحة الوزن (open-weight families)، وغالبًا ما يقدم دعمًا فوريًّا لإصدارات النماذج الرائدة (مثل تحسيناته الممتازة لنماذج DeepSeek)، لكن الجزء الأكبر من النماذج المتخصصة والمتفرقة يبقى من نصيب vLLM. وتحقق مما يحتاجه نموذج معين في قسم دليل متطلبات الذاكرة عالية السرعة VRAM.
أين يقع Ollama وllama.cpp في هذا السياق؟
فئة مختلفة تمامًا. فـ Ollama و إل إم ستوديو هما أداتان محليتان موجَّهتان لمستخدم واحد، ومُحسَّنتان للراحة على أجهزة سطح المكتب، بما في ذلك أجهزة Mac؛ أما SGLang وvLLM فهما محركا خوادم عاليَي التوازي، مُحسَّنان لأقصى أداء ممكن لوحدات معالجة الرسوميات (GPU throughput) عبر العديد من الطلبات المتزامنة. فإذا كنت تقدِّم الخدمة لمستخدم واحد فقط، فاستخدم Ollama؛ أما إذا كنت تقدِّم الخدمة لتطبيق ما، فاستخدم أحد هذين المحركين.
