vLLM أم SGLang؟ اختيار محرك الاستدلال حسب حمل العمل

vLLM أم SGLang: أيهما يناسب مشروعك؟

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

إذا كنت تخدم عددًا كبيرًا من المحادثات القصيرة، فإن اشتراكها في موجّه نظام واحد يستدعي تجربة SGLang، لكنه لا يستدعي استبعاد vLLM؛ فكلاهما يعيد استخدام حسابات الموجّه. أما إذا كنت مؤسسًا تطلق واجهة API بسيطة ولا تملك وقتًا كبيرًا للبنية التحتية، فابدأ بـ vLLM، ولا تنتقل عنه إلا بعد إثبات تحسن في الخدمة أو التكلفة.

يضيف التوليد المعزّز بالاسترجاع، أو RAG، مستندات مسترجعة إلى موجّه النموذج. ما يجعل تخزين البادئات مؤقتًا مفيدًا هو تكرار بداية ذلك الموجّه، لا مجرد استخدام RAG.

تاريخ التحقق: 14 أكتوبر 2026. أحدث إصدارين مستقرين أمكن التحقق منهما عند إعداد المقال هما vLLM 0.31.0، الصادر في 5 أكتوبر، وSGLang 0.5.21، الصادر في 2 أكتوبر. تتبع أوصاف الميزات أدناه وثائق المشروعين المتاحة وقت التحقق؛ لذا اختبر توافق الميزات التي تحتاج إليها مع الإصدار الذي ثبّتّه. لم تُجرَ اختبارات أداء للاستدلال ضمن هذه المقارنة.

جرى التحقق من الترخيصين بالرجوع إلى ترخيص vLLM ومستودع SGLang. تراخيص أوزان النماذج والبنية التحتية والعمل الهندسي تكاليف منفصلة. ولا يقدّم المحرك المفتوح المصدر لأي من المشروعين خدمة مستضافة بتعرفة لكل رمز يمكن مقارنتها بالآخر.

ماذا يفعل كل محرك، وأين تظهر حدوده؟

vLLM: نقطة البداية لخدمة النماذج العامة

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

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

حدوده تتوقف على التهيئة التي تحققت من عملها. دعم وحدة GPU ليس سوى البداية؛ إذ يجب أن تتوافق بنية النموذج والتكميم والواجهة الخلفية للانتباه والميزات المطلوبة معًا. وثمة استثناء محدد في التخزين المؤقت يهم خدمات التقييم: يذكر vLLM أن الطلب الذي يطلب الاحتمالات اللوغاريتمية لرموز الموجّه يتجاوز ذاكرة البادئات المؤقتة ويعيد حساب الموجّه. لذلك قد تتصرف نقطة نهاية لتسجيل الدرجات بصورة مختلفة عن نقطة نهاية للمحادثة تستخدم المستند نفسه. دليل vLLM V1

تكلفة المحرك $0. اختره لخدمة النماذج العامة ولبيئة ذات عتاد متنوع؛ ولا تنتقل إليه إذا كان تثبيت SGLang لديك يحقق مستوى الخدمة المطلوب بالفعل ولا تنقصه أي قدرة تحتاج إليها.

SGLang: بداية قوية عندما يتكرر سياق الوكلاء

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

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

حدوده ترتبط بنطاق مشاركة الذاكرة المؤقتة وتكافؤ الميزات بين الواجهات الخلفية. تخص طبقتا GPU وذاكرة المضيف في HiCache مثيل استدلال واحدًا. ولا يصبح التخزين مشتركًا إلا عند تهيئة الواجهة الخلفية المختارة لهذا الغرض. فتفعيل ذاكرة مضيف مؤقتة أكبر لا ينشئ تلقائيًا ذاكرة مشتركة بين جميع مثيلات الخدمة. كما تعني الطبقات الإضافية ضرورة إدارة ميزانيات الذاكرة وعمليات النقل والإعدادات. نطاق المشاركة في HiCache

تكلفة المحرك $0. اختره عندما يكون أثر السياق المتكرر كبيرًا بما يكفي ليستحق الضبط؛ ولا تنتقل إليه لمجرد أن تطبيقك يستخدم «وكلاء» إذا كانت موجّهاته نادرًا ما تتشارك بادئة متطابقة.

تخزين البادئات وRadixAttention: ابدأ التجربة بـ SGLang

يتقدم SGLang في أولوية التقييم لأحمال العمل المتفرعة ذات السياق المتكرر؛ أما vLLM فيملك بالفعل القدرة الأساسية على التخزين المؤقت. المقارنة هنا ليست بين PagedAttention وإمكان التخزين المؤقت: الأولى تنظّم الذاكرة، بينما يختص تخزين البادئات بإعادة الاستخدام. وتغطي ميزة Automatic Prefix Caching في vLLM صراحةً الأسئلة المتكررة عن المستندات الطويلة والمحادثات متعددة الجولات. تخزين البادئات في vLLM

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

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

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

تنص وثائق SGLang على تفعيل RadixAttention افتراضيًا، مع التحكم فيها عبر --disable-radix-cache؛ أما HiCache فهو خيار إعداد إضافي. في كلا المحركين، افحص الإعدادات الفعلية بدل استنتاج سلوك الذاكرة المؤقتة من اسم المشروع. وسائط خادم SGLang

ميزات الوكلاء: تعادل في JSON، والمهايئات والتوليد التخميني يحتاجان إلى تحقق

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

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

يدعم vLLM مخططات JSON Schema عبر response_format وخيارات structured_outputs. ويدعمها SGLang أيضًا، ويستخدم XGrammar واجهةً خلفية افتراضية لقواعد البنية. هذه قيود تُطبَّق أثناء التوليد، وليست مجرد تعليمات تطلب من النموذج «إرجاع JSON». المخرجات المنظّمة في vLLM، المخرجات المنظّمة في SGLang

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

النتيجة: تعادل عند الحاجة المعتادة إلى JSON. استمر مع المحرك الذي تشغّله ما لم تكشف طلبات تمثل مخططاتك الفعلية عن فارق ملموس.

التوليد التخميني

التوليد التخميني خيار للضبط في المشروعين، وليس مبررًا لافتراض زيادة السرعة. تقترح آلية مسودة رموزًا، ثم يتحقق منها النموذج المستهدف. وقد تقلل المقترحات المفيدة التي يقبلها النموذج العمل المتسلسل اللازم للتوليد؛ لكن إعداد المسودة والتحقق منها والذاكرة المستخدمة تظل لها تكلفة.

توثّق vLLM طرق EAGLE والتنبؤ متعدد الرموز ونماذج المسودة المنفصلة وn-gram واللواحق. وتوثّق SGLang أيضًا مسارات EAGLE والتنبؤ متعدد الرموز ونماذج المسودة وNGRAM. توافق المسودة والنموذج المستهدف والعتاد ومستوى حركة الطلبات أهم من مجرد توافر الميزة. طرق vLLM، طرق SGLang

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

Multi-LoRA لتخصيص السلوك لكل عميل

يستطيع كلا المحركين خدمة عدة مهايئات LoRA، وهي إضافات صغيرة إلى الأوزان ناتجة عن الضبط الدقيق، وتخصّص نموذجًا أساسيًا مشتركًا. يتيح vLLM تسجيل المهايئات عبر --lora-modules، مع أدوات للتحكم في التزامن والرتبة. ويوفّر SGLang الخيارين --lora-paths و--max-loras-per-batch؛ والقيمة الافتراضية الموثقة لكل دفعة هي 8 مهايئات. ولا يمثل ذلك حدًا لإجمالي عدد العملاء. LoRA في vLLM، LoRA في SGLang

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

الاختيار الأفضل: احتفظ بالمحرك الذي تحققت من مسار المهايئات فيه. دعم multi-LoRA وحده لا يبرر الانتقال. ويستحق SGLang التجربة عندما يكون تحميل المهايئات أو حمل عمل كثيف الاعتماد على الذاكرة المؤقتة هو موطن الاختناق. أما مع TPU، فارجع إلى مصفوفة ميزات الواجهة الخلفية نفسها: لا يزال دليل SGLang-JAX يصنّف multi-LoRA ضمن الميزات قيد التطوير. مصفوفة TPU في SGLang

دعم العتاد: vLLM هو البداية الأرجح للبيئات المتنوعة

يعلن المشروعان دعم NVIDIA وAMD وTPU وCPU. لكن حدود الدعم تحددها تركيبة الواجهة الخلفية والنموذج. لا تتعامل مع قائمة العتاد المدعوم على مستوى المشروع بوصفها ضمانًا لانتقال كل إعداد GPU أو مهايئ أو طريقة توليد دون تغيير.

• NVIDIA: توثّق vLLM تثبيت وحدات GPU باستخدام CUDA؛ ويسرد مستودع SGLang عائلات مراكز البيانات وRTX. يجب أن تتوافق صور الإصدار الحالي مع برنامج تشغيل المضيف. تثبيت GPU في vLLM، قائمة العتاد في SGLang
• AMD: يوثّق كلاهما النشر باستخدام ROCm. وتسرد SGLang وحدات Instinct MI300X وMI325X وMI350X وMI355X، مع دليل تثبيت منفصل. استخدم صورة ROCm وإعداد النموذج المتوافقين. دليل AMD في SGLang
• Google TPU: تحيل vLLM إلى تثبيت tpu-inference المنفصل. ويستخدم دليل TPU في SGLang الواجهة الخلفية المنفصلة SGLang-JAX، ويسرد v6e وv7. هذه مسارات نشر مستقلة تتطلب فحص ميزاتها كلًّا على حدة. تثبيت TPU في vLLM، دليل TPU في SGLang
• CPU: توثّق vLLM مسارات CPU تشمل Intel/AMD x86 وARM AArch64. أما دليل خادم CPU في SGLang فيستهدف تحديدًا Intel AMX على معالجات Xeon Scalable من الجيل الرابع أو الأحدث. عبارة «يدعم CPU» لا تعني تطابق نطاق الدعم. دليل CPU في vLLM، دليل CPU في SGLang

قد يحسم فرق تشغيلي محدد قرار النشر التالي: يوفّر vLLM 0.31.0 صورة CUDA 12.9 إلى جانب صورته الافتراضية CUDA 13.0. أما دليل التثبيت الحالي لـ SGLang فيشترط CUDA 13، ويذكر أن سلسلة صور CUDA 12 انتهت عند 0.5.19. إذا لم تكن بيئتك قادرة بعد على الانتقال إلى برامج تشغيل متوافقة، فافحص هذه النقطة قبل مقارنة أي نتيجة لمعدل المعالجة. ملفات إصدار vLLM، تثبيت SGLang

الخوادم المتوافقة مع OpenAI: نقل العميل أسهل من نقل حمل العمل

يمكن لكلا المحركين العمل خلف عميل يستخدم واجهة إكمال المحادثات على نمط OpenAI. وتوثّق المنصتان /v1/chat/completions و/v1/completions؛ ما يقلل كود الربط الذي يلزم استبداله في التطبيق. لكنه لا يعني قابلية تبادل كل نقطة نهاية أو امتداد أو محلّل أدوات أو سلوك للنموذج. خادم vLLM، واجهة API في SGLang

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

إذا كان لديك عميل vLLM قائم، فافحص حقول المخرجات المقيّدة القديمة قبل الانتقال أو الترقية. تقول الوثائق إن guided_json والحقول المرتبطة به أُزيلت في 0.12.0؛ ويجب أن يستخدم الكود الحالي الصيغة المدعومة لـ structured_outputs أو response_format. فقد يبدو متن طلب قديم وكأنه مشكلة عدم توافق في المحرك. ملاحظة الانتقال في vLLM

النتيجة: تعادل في واجهة العميل الأساسية؛ وvLLM هو التوصية المبدئية من ناحية التشغيل. يجب أن يغطي اختبار القبول جولات كاملة للوكيل، تشمل بث وسائط الأدوات والأخطاء وإعادة المحاولة، بدل الاكتفاء بنجاح استجابة نصية واحدة.

تشغيل نماذج اللغة الكبيرة على سحابة GPU

ابدأ بحاوية ذات إصدار مثبّت ونموذج صغير لاختبار التشغيل الأولي، ثم استبدله بنموذج الإنتاج وميزانية الذاكرة الخاصة بك. تكيّف الأمثلة التالية أوامر Docker والتشغيل الموثقة في المشروعين لتعمل على مضيف Linux مزوّد بوحدة NVIDIA GPU، مع Docker وبيئة تشغيل حاويات NVIDIA وبرنامج تشغيل متوافق مع الصورة. جرى التحقق منها بمراجعة الوثائق، ولم تُنفّذ على وحدة GPU مستأجرة. Docker في vLLM، البدء السريع في SGLang

النموذج Qwen/Qwen3-0.6B أدناه مخصص للتحقق من سلامة الربط، وليس توصية بجودة إجاباته لوكيلك. شغّل محركًا واحدًا في كل مرة على المنفذ نفسه. وحدّ السياق إعداد صريح لهذا المثال، وليس الحد الأقصى المعلن للنموذج.

حاوية vLLM

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  vllm/vllm-openai:v0.31.0 \
  --model Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 8192 \
  --enable-prefix-caching

حاوية SGLang

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  lmsysorg/sglang:v0.5.21 \
  python3 -m sglang.launch_server \
  --model-path Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --context-length 8192

نفّذ هذا الطلب على مضيف GPU بعد اكتمال التهيئة:

curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Qwen/Qwen3-0.6B",
    "messages": [{"role": "user", "content": "Say hello."}],
    "max_tokens": 64
  }'

تربط الأمثلة منفذ المضيف بعنوان الحلقة المحلية. ضع بوابة تطبيقك المزوّدة بالمصادقة أمام الخادم قبل إتاحته للمستخدمين عن بُعد. وتزداد أهمية ذلك مع vLLM: إذ تنص وثائقه على أن --api-key لا يفرض المصادقة على كل مسارات خادم HTTP. نطاق المصادقة في vLLM

عامل vLLM الموثق من Runpod

يوفّر Runpod عامل vLLM موثقًا وجاهزًا للنشر عبر Hub. هذا المسار السحابي المختصر يدعم التوصية به خيارًا مبدئيًا للتشغيل. وحزمة العامل منتج نشر منفصل؛ لذا تحقّق من إصدار المحرك المضمّن فيها بدل افتراض مطابقته لأحدث إصدار من المشروع الأصلي. دليل النشر في Runpod

أما مسار SGLang السحابي القابل لإعادة التنفيذ والموضح هنا، فهو حاويته الرسمية على مضيف GPU متوافق. ويخص اختصار Runpod أعلاه عامل vLLM الذي توثّقه Runpod تحديدًا.

فرق السعر: وحدة GPU نفسها تعني الفاتورة نفسها

لا يكون أي من المحركين أرخص عند استئجار السعة نفسها. في 14 أكتوبر 2026، عرضت صفحة تسعير Runpod المباشرة وحدة A100 PCIe بذاكرة 80 GB مقابل $1.79/ساعة لخدمة Pods. هذا سعر وحدة GPU مخصصة، وليس تعرفة عامل Serverless. وهو مُدخل تكلفة البنية التحتية المشترك في الحساب التالي. أسعار Runpod

على أساس شهر من 730 ساعة لأغراض الميزانية، تبلغ تكلفة وحدة GPU واحدة مخصّصة باستمرار $1,306.70/شهر مع vLLM أو SGLang. وتبلغ تكلفة وحدتين $2,613.40/شهر. لا تشمل هذه الأرقام التخزين ورسوم الشبكة والتكرار لضمان الاعتمادية والعمل الهندسي.

لنثبّت حمل دعم افتراضيًا للمقارنة: 50,000 طلب شهريًا، لكل منها 2,000 رمز إدخال و200 رمز إخراج. أي 100 مليون رمز إدخال و10 ملايين رمز إخراج مُسلَّم. إذا استوعبت وحدة GPU واحدة هذا الحمل ضمن زمن الاستجابة المطلوب، فإن فاتورة GPU لأي من المحركين تبلغ $0.13067 لكل 1,000 رمز إخراج مُسلَّم. المقام هنا هو رموز الإخراج؛ لكن الفاتورة تغطي أيضًا قراءة المدخلات.

هذا حساب للتكلفة، وليس قياسًا للسعة. وإذا لم تستوعب وحدة واحدة حمل العمل، فلا تنطبق نتيجة الوحدة الواحدة.

نقطة اختلاف التكلفة هي اللحظة التي تحتاج فيها إحدى التهيئتين إلى نسخة تشغيل إضافية لتحقيق مستوى الخدمة نفسه. إذا احتاج SGLang إلى وحدة GPU واحدة واحتاج vLLM إلى وحدتين، فإن SGLang يوفّر $1,306.70/شهر. وإذا انعكست العلاقة عند قياس السعة، فإن vLLM يوفّر المبلغ نفسه. وإذا احتاج كلاهما إلى وحدة واحدة، فإن الوفر في البنية التحتية يساوي صفرًا.

إذا خصصت للانتقال 8 ساعات بسعر مفترض قدره $100/ساعة، فتكون التكلفة $800. ويسترد الاستغناء عن وحدة GPU واحدة من هذا النوع تلك التكلفة خلال نحو 0.61 شهر، قبل احتساب أي فرق في التشغيل المستمر. ومن دون الاستغناء عن نسخة تشغيل أو تحقيق تحسن في الخدمة له قيمة، قد لا تمنحك «السرعة الأعلى» أي عائد مالي.

الفائز في السعر: التهيئة التي تحقق الهدف بأقل تكلفة تشغيل إجمالية. ولا يمكن تحديد عتبة صادقة لحركة الطلبات يصبح بعدها محرك بعينه أوفر، قبل قياس السعة التي يمكن الاعتماد عليها لحمل عملك.

معدل المعالجة: احكم بالعمل المنجز ضمن زمن الاستجابة المطلوب

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

ابدأ بأدوات المشروعين نفسيهما: واجهة اختبارات الأداء من سطر الأوامر في vLLM ودليل اختبار أداء الخدمة في SGLang. تحتاج المقارنة إلى جولات بذاكرة مؤقتة دافئة وأخرى بذاكرة باردة، وإلى نمط حمل العمل الذي ينتجه تطبيقك.

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

سجّل الطلبات المكتملة ورموز الإخراج المُسلَّمة والأخطاء وزمن الوصول إلى الرمز الأول. وافحص أيضًا زمن الاستجابة عند p95 وp99، أي المئينين 95 و99، فقد يخفي المتوسط الجيد طلبات بطيئة جدًا عند طرف التوزيع. واحتسب المخرجات التي تفشل في فحوص مخطط التطبيق أو صحة النتائج بوصفها إخفاقات، لا سعة مفيدة.

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

الانتقال بين المحركين: حافظ على عقد الواجهة وأبقِ مسارًا للرجوع

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

لا تستبدل نشر vLLM يعمل جيدًا لمجرد الحصول على تخزين البادئات أو قيود JSON؛ فهو يدعم كليهما بالفعل. ولا تستبدل نشر SGLang يعمل جيدًا لمجرد أن vLLM هو التوصية المبدئية هنا. المعرفة التشغيلية المتراكمة جزء من مقارنة التكلفة.

إذا كان القرار الذي لم تحسمه بعد هو حاجتك أصلًا إلى خادم إنتاج مشترك، فاقرأ مقارنة Ollama وvLLM. تتناول تلك المقارنة القرار السابق: الاختيار بين سير عمل مريح للنماذج المحلية وطبقة خدمة تتعامل مع طلبات متداخلة.

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

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

استخدم قائمة تدقيق سير العمل التجاري بالذكاء الاصطناعي لتحديد سير العمل الذي يستحق خادم نماذج مشتركًا، واشترك في النشرة لمتابعة التغييرات اللاحقة في الأدوات.