سرعة تشغيل نماذج LLM محلياً (On-Prem): كيف تحصل على معدل إنتاجية (Throughput) أعلى بـ 3 أضعاف دون شراء عتاد جديد

عادةً ما يركز الحديث حول الذكاء الاصطناعي المحلي (on-premise AI) على الخصوصية والتحكم. ونادراً ما يتطرق إلى ما يتطلبه الأمر لجعله سريعاً بما يكفي لئلا يشتكي المستخدمون.

الحقيقة المزعجة بشأن معظم عمليات نشر نماذج LLM محلياً هي: العتاد (hardware) ليس هو عنق الزجاجة. بل بيئة التشغيل (serving stack) هي السبب. تنفق الفرق 20,000 دولار على خادم GPU، وتشغّل عليه Ollama، ثم تحصل على أرقام معدل إنتاجية (throughput) مخيبة للآمال مقارنة باستدعاءات API في عام 2022. بعد ذلك، يستنتجون أن الذكاء الاصطناعي المحلي "غير جاهز لبيئات الإنتاج".

لكنه جاهز بالفعل. كل ما في الأمر أنهم اختاروا المحرك الخاطئ.

الأداة الأكثر تأثيراً: اختيار محرك الاستنتاج (Inference Engine)

هذا هو المتغير الفردي الأكبر في أداء نماذج LLM المحلية، وغالباً ما يكون آخر ما تفكر فيه الفرق التقنية.

تظهر اختبارات الأداء (benchmarks) على نفس العتاد وباستخدام نفس النموذج القصة الحقيقية. على خادم H200:

نفس العتاد. نفس النموذج. اختيار المحرك وحده يصنع فارقاً يتراوح بين 5 إلى 7 أضعاف بين Ollama (الذي تبدأ به معظم الفرق) و SGLang.

على إعداد أكثر توفراً يتكون من 4 بطاقات RTX 3090 لتشغيل نموذج Mistral-Large 123B بتكميم (quantization) من نوع AWQ Q4، يصل SGLang مع NVLink وتفعيل torch.compile إلى 37 رمزاً في الثانية (tokens/second) بشكل مستقر — وهو أسرع بـ 3.1 ضعفاً من TabbyAPI على نفس العتاد، وأسرع بنسبة 15-18% من vLLM.

القاعدة العملية: يعتبر Ollama ممتازاً للتطوير المحلي والاستخدام الشخصي. أما بالنسبة لبيئات الإنتاج التي تخدم أكثر من 5 مستخدمين متزامنين، استخدم TensorRT-LLM (عتاد NVIDIA، أقصى سرعة)، أو SGLang (للمحادثات متعددة الأدوار، خطوط معالجة RAG، والمخرجات المهيكلة)، أو vLLM (للأغراض العامة، وأفضل منظومة عمل). لا تستخدم Ollama أبداً في بيئة الإنتاج.

لماذا ينهار استنتاج الـ Transformers الأساسي تحت ضغط الاستخدام المتزامن

عندما تقوم بتحميل نموذج باستخدام مكتبة transformers القياسية واستدعاء model.generate()، يتم تشغيل كل طلب بالتسلسل. ينتظر الطلب الثاني اكتمال الطلب الأول. وعند وجود 15 مستخدماً متزامناً، ينتظر كل مستخدم دور الـ 14 الآخرين.

تحل محركات الاستنتاج المخصصة لبيئات الإنتاج هذه المشكلة عبر تقنية التجميع المستمر (continuous batching): بدلاً من انتظار انتهاء الطلب قبل بدء الطلب التالي، تقوم بملء دورات GPU الشاغرة بتوليد الرموز (tokens) للطلبات الأخرى. والنتيجة هي معدل إنتاجية (throughput) يتوسع طردياً مع زيادة الحمل بدلاً من التراجع أمامه.

بالاقتران مع تقنية PagedAttention (التي تقوم بتقسيم ذاكرة الـ KV cache كصفحات مثل الذاكرة الافتراضية، مما يضمن استخدام ذاكرة الـ GPU بكفاءة عبر الطلبات)، يمكن لنسخة مهيأة بشكل صحيح من vLLM أو SGLang التعامل مع حمل متزامن أكبر بـ 10 إلى 20 ضعفاً مقارنة بطرق تشغيل النماذج التقليدية على نفس العتاد.

هذا هو الفارق المعماري بين نظام "يعمل لـ 5 مستخدمين داخليين" ونظام "يتعامل مع 200 مستخدم متزامن دون تراجع في الأداء".

التكميم (Quantization): المقايضة بين التكلفة والجودة في بيئة الإنتاج

يقلل التكميم (Quantization) من دقة أوزان النموذج، مما يقلص متطلبات ذاكرة الـ VRAM ويزيد من سرعة الاستنتاج على حساب بعض الجودة. في عام 2026، تعتبر صيغتا MXFP4 و AWQ Q4 الخيارين الأمثل لبيئات الإنتاج.

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

الأثر التجاري هنا: الخادم الذي يشغل نموذج 14B بصيغة BF16 لـ 5 مستخدمين متزامنين، يمكنه باستخدام AWQ Q4 تشغيل نفس النموذج لـ 12 إلى 15 مستخدماً متزامناً. دون الحاجة لعتاد جديد، فقط بتغيير صيغة التكميم.

حجم الموجّه (Prompt Size): التحسين الذي يتفوق على كل شيء آخر

هذا التحسين قد يبدو غير بديهي. قبل أن تقوم بضبط أي معايير تشغيل أو شراء أي عتاد، ألقِ نظرة على متوسط طول الموجّه (prompt) لديك.

في إحدى عمليات النشر الفعلية التي تخدم أكثر من 100,000 مستخدم، تم تقليل متوسط زمن استجابة الاستعلام (query latency) من 9.87 ثانية إلى 0.71 ثانية — أي خفض بنسبة 91% — وذلك عبر الانتقال من نظام RAG كامل السياق (يمرر 15 مقطعاً مسترجعاً بإجمالي ~12,000 رمز) إلى استرجاع انتقائي (يمرر أكثر 3 مقاطع صلة فقط، بحوالي ~2,000 رمز).

دون تغيير النموذج. دون ترقية العتاد. دون تعديل إعدادات التشغيل. فقط عبر تمرير نص أقل إلى نموذج LLM.

تعني الموجّهات الأصغر حجماً مرحلة ملء مسبق (prefill) أسرع، وزمن استجابة أقل للرمز الأول (TTFT)، وتقليصاً هائلاً في التكلفة. وبالنسبة لواجهات برمجة تطبيقات LLM السحابية، فإن هذا يقلل مباشرة من إنفاقك لكل استدعاء.

التطبيق العملي: بدلاً من استرجاع أفضل 10 مقاطع وتمريرها بالكامل، قم باسترجاع أفضل 20 مقطعاً واستخدم نموذج إعادة ترتيب (reranker) لتحديد أفضل 3 أو 4 مقاطع ذات درجات ثقة عالية. مرر هذه المقاطع فقط. سيحصل نموذج الـ LLM الخاص بك على سياق أنقى، وسيحصل المستخدمون على ردود أسرع، وستنخفض فاتورة استهلاك الرموز لديك.

فك التشفير التخميني (Speculative Decoding): مضاعف السرعة الأقل شهرة

يعد فك التشفير التخميني (speculative decoding) أحد تحسينات السرعة الأقل مناقشة على الرغم من وجود أرقام إنتاجية حقيقية تدعمه. الفكرة: استخدام نموذج "مسودة" (draft model) صغير وسريع لتوليد رموز مرشحة، ثم التحقق منها بالتوازي باستخدام النموذج الرئيسي. الرموز المقبولة تكون مجانية تقريباً من حيث تكلفة المعالجة.

على بطاقة RTX 3090 تشغل نموذج Qwen-2.5-Coder-32B، أدى فك التشفير التخميني باستخدام نموذج مسودة 7B إلى رفع معدل الإنتاجية من 34.78 رمز/ثانية إلى 51.31 رمز/ثانية — وهو تحسن بنسبة 47% على نفس العتاد. وعلى بطاقة P40 (بطاقة مراكز بيانات قديمة)، ارتفع المعدل من 10.54 رمز/ثانية إلى 17.11 رمز/ثانية.

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

لمعظم الفرق: قم بتطبيق فك التشفير التخميني عندما تقوم بتشغيل نموذج ثابت في بيئة الإنتاج مع أنماط استعلام مستقرة (أي عندما يمكنك التحقق من أن معدلات القبول عالية بما يكفي لتحقيق إنتاجية إيجابية صافية). لا يستحق الأمر هذا التعقيد بالنسبة للنماذج قليلة الاستخدام أو أنواع الاستعلامات شديدة التباين.

التوازي (Parallelism): كيف تتوسع عبر عدة معالجات رسومية (GPUs) بشكل صحيح

إذا كان النموذج يتسع في ذاكرة GPU واحدة، فقم بتكراره (توازي البيانات - data parallelism). وإذا لم يتسع، فقم بتجزئته (توازي الموترات - tensor parallelism).

يبدو هذا بديهياً ولكن التفاصيل الدقيقة تصنع الفارق. أحد اختبارات الأداء: تمكن SGLang مع خيار --dp 2 (نسختين مكررتين) من خدمة طلبات أكثر بنسبة 150% مقارنة بـ vLLM مع خيار --tp 2 (توازي الموترات عبر وحدتي GPU) على نفس الجهاز المزود ببطاقتي GPU. التكرار (replication)، عندما يتسع النموذج في الذاكرة، يتفوق على التجزئة (sharding) من حيث معدل الإنتاجية.

بالنسبة للنماذج التي لا تتسع في GPU واحدة، فإن وجود اتصال NVLink بين المعالجات الرسومية يستحق التكلفة الإضافية. في إعداد يتكون من 4 بطاقات RTX 3090، أدى اتصال NVLink إلى تحسين معدل الإنتاجية بنسبة 12.5% مقارنة بـ PCIe Gen4 وحده — وهو فارق جوهري عند العمل بنطاق واسع.

التسلسل الهرمي الكامل لعمليات التحسين

عند تشخيص بطء تشغيل نموذج LLM محلي (on-prem)، اتبع هذه الخطوات بالترتيب:

1. ▸محرك الاستنتاج (Inference engine) — هل تستخدم محرك تشغيل مخصص لبيئات الإنتاج (vLLM، SGLang، TensorRT-LLM)؟ إذا لم يكن الأمر كذلك، فهذا هو الحل الأول. التأثير المتوقع: زيادة تصل إلى 3-7 أضعاف.
2. ▸حجم الموجّه (Prompt size) — ما هو متوسط عدد الرموز المدخلة لديك؟ قلله عن طريق تضييق نطاق الاسترجاع أو تقليص السياق. التأثير المتوقع: تقليل زمن الاستجابة بنسبة تصل إلى 91%.
3. ▸التكميم (Quantization) — هل تقوم بتشغيل صيغة التكميم الأكثر كفاءة لحالة الاستخدام الخاصة بك؟ التأثير المتوقع: زيادة معدل الإنتاجية بمقدار 1.3-2.5 ضعفاً.
4. ▸التجميع المستمر + ذاكرة الـ KV cache المقسمة — هل تم تهيئة محرك التشغيل بشكل صحيح؟ هل تم تفعيل التخزين المؤقت للبادئة (prefix caching)؟ التأثير المتوقع: تحسين القدرة على التعامل مع الطلبات المتزامنة بمقدار 3-5 أضعاف.
5. ▸فك التشفير التخميني (Speculative decoding) — هل يتوفر لديك نموذج مسودة؟ التأثير المتوقع: تحسن بمقدار 1.25-1.6 ضعفاً.
6. ▸استراتيجية التوازي (Parallelism strategy) — هل تستخدم تكرار الـ GPU الفردي أم توازي الموترات؟ هل تستخدم NVLink؟ التأثير المتوقع: تحسن بنسبة 10-150% اعتماداً على الإعداد.

الجدوى الاقتصادية للقيام بذلك بالشكل الصحيح

يمتلك الذكاء الاصطناعي المحلي هيكل تكلفة مختلفاً تماماً عن واجهات البرمجة السحابية (cloud APIs): العتاد يمثل تكلفة ثابتة، والتكلفة الهامشية لعمليات الاستنتاج الإضافية تقترب من الصفر (الكهرباء والصيانة). وتعتمد حسابات العائد على الاستثمار (ROI) بالكامل على معدل الاستخدام.

إن خادم GPU بقيمة 15,000 دولار يخدم 200 مستخدم بمتوسط زمن استجابة يبلغ 30 ثانية له عائد استثمار مختلف تماماً عن نفس الخادم الذي يخدم 200 مستخدم بمتوسط زمن استجابة يبلغ 800 مللي ثانية. يرتبط تبني المستخدمين للنظام — وبالتالي القيمة التجارية المستخلصة منه — ارتباطاً مباشراً بمدى سرعة الاستجابة الملموسة.

تشير التقارير الواردة من الفرق التي تبني بيئة التشغيل (serving stack) بشكل صحيح إلى أن مشاريع الذكاء الاصطناعي الخاصة بها تُستخدم بالفعل على نطاق واسع، بدلاً من أن يقتصر استخدامها على فئة قليلة من المتبنين الأوائل ثم تُهمل بهدوء بعد ذلك.

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

ما هو الحد الأدنى من المعالجات الرسومية (GPU) للتشغيل المحلي في بيئة الإنتاج؟ تشغل بطاقة RTX 4090 (بذاكرة 24GB VRAM) نماذج بحجم 7B–14B بتكميم Q4 مع قدرة جيدة على معالجة الطلبات المتزامنة. بالنسبة للنماذج بحجم 14B–34B، فإن بطاقة A10G (بذاكرة 24GB) أو RTX 3090 (بذاكرة 24GB) هي الحد الأدنى. أما بالنسبة للنماذج بحجم 70B+، فأنت بحاجة إما إلى بطاقة بذاكرة 48GB+ (مثل A6000 أو RTX 6000 Ada) أو إعداد متعدد البطاقات (multi-GPU) مع NVLink. وتعتبر بطاقات A100 80GB و H100 80GB هي المعايير القياسية للمؤسسات في عمليات النشر واسعة النطاق.

هل يستحق TensorRT-LLM عناء تعقيد عملية التجميع (Compilation)؟ نعم، بالنسبة للنماذج الثابتة التي لن تتغير — فهو أسرع بنسبة 30-70% من llama.cpp على نفس العتاد، وأسرع بنسبة 20-40% من vLLM في العديد من الإعدادات. تكمن التكلفة هنا في خطوة التجميع (والتي تستغرق من 2 إلى 4 ساعات لكل إصدار من النموذج). أما بالنسبة للنماذج التي تقوم بتحديثها وتكرار العمل عليها باستمرار، فإن SGLang أو vLLM (اللذين لا يتطلبان تجميعاً) يعتبران خيارين أكثر عملية.

كيف يتعامل SGLang مع المخرجات المهيكلة (JSON) بشكل مختلف عن vLLM؟ يحتوي SGLang على تقنية RadixAttention المدمجة للتخزين المؤقت للبادئة (prefix caching)، وهي ميزة قيمة للغاية في خطوط معالجة RAG حيث تتم مشاركة موجّهات النظام (system prompts) عبر العديد من الطلبات. وبالنسبة لتوليد المخرجات المهيكلة (JSON schemas)، فإن أسلوب أخذ العينات المستند إلى القيود (constraint-based sampling) في SGLang أسرع أيضاً مقارنة بـ vLLM. ولهذا السبب أصبح SGLang المحرك المفضل لعمليات النشر التي تعتمد بكثافة على أنظمة RAG.

هل يمكننا استخدام عدة محركات استنتاج في نفس عملية النشر؟ نعم. أحد الأنماط الشائعة في بيئات الإنتاج: استخدام SGLang لاستعلامات RAG الأساسية الموجهة للمستخدمين، واستخدام TensorRT-LLM لنموذج ثانوي مخصص لمعالجة المستندات على دفعات (batch processing). يمكنك توجيه أنواع الطلبات المختلفة إلى المحرك الأكثر ملاءمة لضغط العمل هذا.