لا تختر محرك الاستدلال. اختر استراتيجية الأجهزة.

أسسٌ بأحجام مختلفة (الأجهزة) تحدد شكل البرمجيات التي تتدفق فوقها.

نظرة عامة

حين تقرر تقديم LLM، السؤال الأول الذي تطرحه عادةً هو “أي محرك استدلال أستخدم؟” تصطف الأسماء: vLLM وSGLang وTensorRT-LLM وllama.cpp، وتبدأ مقارنة جداول المعايير. مؤخراً أشار مهندس إلى أن هذا السؤال بحد ذاته يأتي بترتيب خاطئ، فاستقطب الملاحظة اهتماماً. الحجة الجوهرية بسيطة: “لا تختر محرك استدلال، بل استراتيجية أجهزة؛ والمحرك ينبثق منها.”

تدير ThakiCloud منصةً تجمع موارد GPU على Kubernetes وتُقدِّم أعباء عمل الاستدلال لعملاء متعددين. إطار “الأجهزة أولاً” ليس بالنسبة إلينا مجرد ملاحظة ذكية في تغريدة. إنه لغة القرارات التي نتخذها يومياً في تصميم جدولة GPU وأدوات التقديم. تُلخِّص هذه المقالة الإطار وتشرح لماذا نبدأ بـ vLLM في معظم الحالات ولا ننتقل إلى محرك آخر إلا حين يُقاس عنق الزجاجة بوضوح.

الحجة الأساسية: اختر استراتيجية أجهزة لا محركاً

يذهب المؤلف الأصلي إلى عدم ترتيب محركات الاستدلال في قائمة أداء مجردة. المحرك ليس سريعاً أو بطيئاً في فراغ. هو سريع أو بطيء على أجهزة بعينها، لشكل عبء عمل بعينه. لذا نقطة انطلاق القرار لا ينبغي أن تكون “ما أسرع محرك؟” بل “ما الأجهزة المتاحة لديَّ، وما شكل عبء عملي؟” حين تتحدد الأجهزة وعبء العمل، تتضيق المحركات المرشحة تلقائياً إلى واحد أو اثنين.

أهمية هذا التفكير أن الناس كثيراً ما يختارون محركات بناءً على معايير لا صلة لها ببيئتهم. أرقام الإنتاجية القصوى المقاسة على مجموعة من ثمانية GPU من طراز H100 لا معنى لها تقريباً لمن يعمل على MacBook أو بطاقتَي RTX. في المقابل، أخذ محرك خفيف يعمل جيداً على جهاز حافة وتحميله على تقديم طلبات متزامنة واسعة النطاق كفيل بانهياره. ما يجب مطابقته هو “بيئة التشغيل مع شكل عبء العمل والأجهزة ومقدار العبء التشغيلي القابل للتحمل.”

خريطة الأجهزة إلى المحركات

ورقة الغش التي قدَّمها المنشور الأصلي ترسم المحركات على حالات الأجهزة. الخلاصة:

الأجهزة / الحالة                                المحرك المناسب
------------------------------------------------------------
CPU، Mac، حافة، بيئة غير مألوفة، VRAM منخفض  -> llama.cpp (GGUF، إلغاء تحميل هجين)
  مع RAM كافٍ في النظام
سير عمل مرتكز على Mac (Apple Silicon)          -> MLX
GPU مستهلك 1-4 بطاقات RTX                       -> ExLlamaV2 / ExLlamaV3
تقديم إنتاجي عام                                -> vLLM
بنية تحتية معقدة، سياق طويل، MoE              -> SGLang (RadixAttention)
أقصى أداء على NVIDIA                            -> TensorRT-LLM (محرك مُصرَّف)

مزيد من التفصيل في طبيعة كل محرك:

• llama.cpp: يعمل في أي مكان تقريباً. قوي حين يكون VRAM محدوداً والـ RAM متوفراً، محققاً التكميم GGUF وإلغاء التحميل الهجين. مناسب للتجارب الشخصية وأجهزة الحافة وأجهزة الكمبيوتر المحمولة.
• MLX: محسَّن لـ Apple Silicon. الخيار الطبيعي لسير العمل المرتكز على Mac.
• ExLlamaV2/V3: متخصص في تشغيل النماذج المكمَّمة بكفاءة على بطاقة إلى أربع بطاقات GPU للمستهلكين.
• vLLM: أوسع تغطية للأجهزة والنماذج مع أداء قابل للتنبؤ. المرشح الافتراضي للتقديم الإنتاجي العام.
• SGLang: قوي للطلبات المتزامنة العالية والسياق الطويل وأعباء عمل MoE عبر RadixAttention وجدولة الاستدعاءات المتعددة. يأتي بتعقيد بنية تحتية أعلى.
• TensorRT-LLM: يُحقق أعلى إنتاجية خام عبر مسار المحرك المُصرَّف على NVIDIA. يأتي بتعقيد تشغيلي كبير.

تتقارب تحليلات المقارنة عموماً على الاستنتاجات ذاتها: للتقديم الإنتاجي متوسط إلى عالي الحجم، يُحقق vLLM أو SGLang توازناً مقبولاً بين الإنتاجية وتجربة المطور. مسار TensorRT-LLM المُصرَّف يستحق الاستثمار فقط للحجم الهائل جداً أو المتطلبات الحرجة للكمون. نقطة البداية الموصى بها لمعظم الفرق هي vLLM، مع الانتقال إلى محرك آخر فقط بعد تأكيد عنق الزجاجة بالقياس.

لماذا هذا الترتيب صحيح

“المحرك أولاً” خطر لأنه تحسين مبكر. اختيار المحرك الأسرع قبل معرفة عنق الزجاجة المقيَّس فعلياً يعني دفع تكلفة التعقيد التشغيلي مقدَّماً مقابل مكاسب غير مؤكدة. مسار TensorRT-LLM المُصرَّف سريع فعلاً، لكنه يصحبه عبء تشغيلي مستمر: بناء المحرك وإدارة الإصدارات وخطوط تحويل النماذج. إن كان عبء العمل لا يبرر هذا التعقيد، فذلك خسارة صافية.

“الأجهزة وعبء العمل أولاً” ينطلق من وقائع قابلة للقياس. نوع GPU وعددها وحجم النموذج وطول السياق وأنماط الطلبات المتزامنة قيم قابلة للملاحظة جميعاً. حين تتحدد هذه القيم، تتضيق المحركات المرشحة، ويكون اختيار أبسط محرك يعالج عنق الزجاجة المقيَّس هو القرار الرشيد. البساطة قيمة تشغيلية بحد ذاتها: أعطال أقل، وترقيات أيسر، وأقل ربطاً للموارد البشرية.

التطبيق على منصة ThakiCloud K8s AI/ML SaaS والدلالات

يتطابق هذا الإطار تقريباً مع فلسفة ThakiCloud في عمليات التقديم. نجمع GPU في مجمَّعات على Kubernetes ونُدير قوائم الانتظار والجدولة بـ Kueue، ونُقدِّم أعباء عمل الاستدلال في إعداد متعدد المستأجرين. في هذه البيئة، تتجسد “استراتيجية الأجهزة أولاً” على النحو التالي.

• شكل مجمَّع GPU يحدد المحركات المرشحة. أنواع GPU وطبولوجيا مجمَّعات العقد لدينا هي استراتيجية الأجهزة. في حالتنا الأساسية المتمثلة في التقديم للأغراض العامة لعدة مستأجرين على GPU من مستوى مراكز البيانات بـ NVIDIA، يُشكِّل vLLM بتغطيته الواسعة وأدائه القابل للتنبؤ الخيار الافتراضي الطبيعي. لذا نبدأ بـ vLLM عند تهيئة نموذج جديد.
• شكل عبء العمل يقود التفريع. حين يميل عبء عمل مستأجر بعينه نحو السياق الطويل أو MoE أو التزامن العالي، تكتسب خصائص مثل RadixAttention في SGLang معنىً. في المقابل، لخدمة شديدة الحساسية للكمون مع أجهزة ونموذج ثابتَين، نقيِّم حينئذٍ مسار TensorRT-LLM المُصرَّف. النقطة الجوهرية أن هذا التفريع يستند إلى عناق زجاجة مقيَّسة لا إلى تخمين.
• ينطبق مباشرةً على النشر المحلي والاستضافة الذاتية. للمؤسسات العامة والجامعات والعملاء الماليين الذين لا يستطيعون الاعتماد على واجهات API خارجية، “ما الأجهزة المتاحة؟” يحدد كل شيء. مطابقة المحرك مع جيل GPU المتاح وعددها، ثم تحسين التكلفة لكل وحدة إنتاجية داخل بنيتهم التحتية الخاصة، هو التمييز بعينه. التفكير بمنطق الأجهزة أولاً أقوى ما يكون في البيئات المقيَّدة.

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

القيود والحجج المضادة

هذا الإطار ليس حلاً شاملاً. ثمة نقاط تستحق التأمل.

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

خلاصةً، نصيحة “لا تختر محرك استدلال، بل استراتيجية أجهزة” انضباطٌ جيد لتجنب التحسين المبكر والبدء من وقائع قابلة للقياس. بالنسبة لـ ThakiCloud، ليست هذه فكرة جديدة. هي تلخيص مقتضب للمبدأ الذي نتبعه أصلاً في تصميم مجمَّع GPU والتقديم متعدد المستأجرين: ابدأ بالمحرك الأبسط والأوسع نطاقاً، وأدخل المحركات المعقدة المتخصصة فقط حين يُثبت عنق الزجاجة نفسه بنفسه.

المصادر

• التغريدة الأصلية (@TheAhmadOsman): x.com/TheAhmadOsman/status/2051779046468673986
• تغريدة المشاركة (عبر @hjguyhan): x.com/hjguyhan/status/2069049583276298276
• تحليلات مقارنة تكميلية: vLLM vs SGLang vs TensorRT-LLM vs Ollama (LeetLLM, 2026), Best LLM Inference Engines 2026 (Yotta Labs)