لماذا يعتبر نموذج LLM المحلي لديك بطيئاً: أدوات تحسين حزمة التقديم بالترتيب

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

الأجهزة غالباً ما تكون ممتازة. عنق الزجاجة يكمن في البرمجيات التي تقدم النموذج.

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

أدناه تجد الأدوات (levers) بالترتيب الذي نتحقق منه. أول أداتين تكلفتها بسيطة وتحل معظم الشكاوى. البقية تصبح مهمة مع زيادة الحمل.

قس رقمين قبل تغيير أي شيء

خذ قياسين من نظامك الخاص أولاً. بدونها، كل إصلاح هو مجرد تخمين.

• ▸الوقت حتى أول رمز (Time to first token): كم من الوقت يحدق المستخدم في شاشة فارغة قبل أن تبدأ الإجابة. هذا ما يعنيه الناس عندما يقولون "بطيء".
• ▸معدل الإنتاجية تحت الحمل (Throughput under load): إجمالي النص الذي ينتجه الخادم في الثانية بينما يستخدمه العديد من الأشخاص في وقت واحد. هذا يحدد عدد المستخدمين الذين يمكن لخادم واحد استيعابهم.

يفشل هذان المقياسان لأسباب مختلفة. إذا كان أول رمز بطيئاً حتى مع مستخدم واحد، فغالباً ما يكون الموجّه (prompt) طويلاً جداً. أما إذا كان الأداء جيداً لمستخدم واحد وينهار مع عشرين مستخدماً، فابحث في محرك التقديم (serving engine). الفرق التي تخلط بين الأمرين تنتهي بشراء GPU ثانٍ لم تكن بحاجة إليه.

الأداة الأولى: محرك التقديم (serving engine)

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

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

• ▸التجميع المستمر (Continuous batching). يضع المحرك كل طلب جديد في عمل الـ GPU بمجرد توفر مساحة. ولا ينتظر انتهاء دفعة (batch) كاملة. لذلك يرتفع معدل الإنتاجية مع الحمل بدلاً من الانخفاض. يوثق Hugging Face التجميع المستمر في خادم Text Generation Inference الخاص به كطريقة لرفع إجمالي معدل الإنتاجية.
• ▸الذاكرة العاملة المقسمة لصفحات (Paged working memory). تحتاج كل محادثة إلى ذاكرة مؤقتة على الـ GPU، تسمى KV cache. إدارتها في صفحات صغيرة، بالطريقة التي يدير بها نظام التشغيل ذاكرة الوصول العشوائي (RAM)، يمنع الهدر ويستوعب عدداً أكبر من المستخدمين في وقت واحد. أفادت ورقة PagedAttention (Kwon et al., 2023) من فريق vLLM بزيادة معدل الإنتاجية من 2 إلى 4 أضعاف مقارنة بالأنظمة التي تمت مقارنتها بها، مع زمن الاستجابة (latency) مماثل. وادعى منشور الإطلاق لفريق vLLM تحقيق معدل إنتاجية يصل إلى 24 ضعفاً مقارنة بـ Hugging Face Transformers، دون أي تغييرات في النموذج.

كيف تختلف محركات الإنتاج الثلاثة من الناحية العملية:

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

لا يزال لـ Ollama و llama.cpp مكان. للتطوير، وأجهزة الكمبيوتر المحمولة، وعدد قليل من المستخدمين، فهي ممتازة. أما بالنسبة لخدمة مشتركة يستخدمها أكثر من بضعة أشخاص في وقت واحد، فإن محرك الإنتاج هو الخيار الصحيح.

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

الأداة الثانية: كمية النص التي ترسلها للنموذج

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

يجب أن يقرأ النموذج الموجّه بالكامل قبل أن يكتب كلمة واحدة. خطوة القراءة هذه تسمى prefill، وتكلفتها ترتفع مع طول الموجّه. بالنسبة للموجّهات الطويلة جداً، ترتفع التكلفة بشكل أسرع من الطول نفسه. إذا كان نظامك يلصق خمسة عشر مقطع (chunk) من المستندات في كل سؤال، سينتظر كل مستخدم بينما تتم قراءة جميع المقاطع الخمسة عشر.

تحقق من ذلك بأرقامك الخاصة:

رموز الموجّه لكل سؤال = تعليمات النظام + (المقاطع المسترجعة × الرموز لكل مقطع) + سجل الدردشة

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

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

مع واجهات برمجة التطبيقات (APIs) السحابية، يقلل نفس التغيير من فاتورتك، لأنك تدفع مقابل كل رمز إدخال. أما على أجهزتك الخاصة، فإنه يحرر سعة الـ GPU لمزيد من المستخدمين.

الأداة الثالثة: التكميم (Quantization)

يخزن التكميم الأرقام الداخلية للنموذج بدقة أقل. بالنسبة للعمل، هذا يعني أن نفس النموذج يتناسب مع ذاكرة GPU أقل. وهذا يترك مساحة لمزيد من المستخدمين المتزامنين، وعادة ما يعمل النموذج بشكل أسرع أيضاً.

يمكنك حساب الذاكرة بنفسك:

ذاكرة الأوزان ≈ عدد المعلمات × البايت لكل معلمة

بدقة 16 بت، تأخذ كل معلمة 2 بايت. لذلك يحتاج نموذج بـ 14 مليار معلمة إلى حوالي 28 جيجابايت لأوزانه فقط. تنسيقات 8 بت تخفض ذلك إلى النصف. تنسيقات 4 بت مثل AWQ أو GPTQ أو GGUF Q4 تخفضها إلى الربع تقريباً، بالإضافة إلى بعض النفقات الإضافية (overhead). كل جيجابايت يتم تحريره يذهب إلى الذاكرة العاملة، وهو ما يسمح لمزيد من الأشخاص باستخدام النظام في وقت واحد.

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

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

الأداة الرابعة: إعدادات المحرك

اختيار vLLM أو SGLang هو نصف المهمة فقط. إعداداتها الافتراضية تناسب الاستخدام العام، وليس عبء العمل الخاص بك. ثلاثة إعدادات هي الأهم:

• ▸التخزين المؤقت للبادئة (Prefix caching). إذا كان كل طلب يفتح بنفس التعليمات الطويلة، فقم بتخزينها مؤقتاً مرة واحدة. يقوم SGLang بذلك تلقائياً. يدعمه vLLM أيضاً، لذا تأكد من تشغيله في إصدارك.
• ▸الحد الأقصى لطول السياق (Maximum context length). إذا قمت بتعيين هذا على النافذة الكاملة المعلن عنها للنموذج، فإن المحرك يحجز ذاكرة قد لا تستخدمها أبداً. حده بما تحتاجه موجّهاتك الحقيقية.
• ▸حصة ذاكرة GPU (GPU memory share). يطالب المحرك بجزء ثابت من ذاكرة GPU للذاكرة العاملة. إذا عينته منخفضاً جداً، فستضيع السعة. وإذا كان مرتفعاً جداً، فقد يتعطل الخادم عندما تحتاج عملية أخرى إلى البطاقة.

لا شيء من هذه يكلف مالاً. بل تكلف فترة ما بعد الظهيرة من شخص يعرف أين يبحث.

الأداة الخامسة: فك التشفير التخميني (Speculative decoding)

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

أفادت الورقة الأصلية بواسطة Leviathan et al. (2023) بتوليد أسرع بـ 2 إلى 3 مرات على نماذج الاختبار الخاصة بها. يعتمد مكسبك على عدد المرات التي يخمن فيها نموذج المسودة بشكل صحيح. هذا المعدل مرتفع للنصوص المتوقعة مثل الأكواد البرمجية أو الردود المقولبة. وينخفض للكتابة المفتوحة. أفادت NVIDIA بمكاسب في معدل الإنتاجية تصل إلى 3.61x من فك التشفير التخميني لـ TensorRT-LLM مع نموذج Llama بحجم 405B كهدف.

استخدمه عندما تقدم نموذجاً ثابتاً واحداً بحجم ثابت ويمكنك قياس معدل الإصابة (hit rate) على حركة المرور الحقيقية. تخطاه إذا كنت تبدل النماذج كثيراً. لأنه يعني نموذجاً إضافياً يجب تشغيله ومراقبته وترقيته.

الأداة السادسة: استخدام أكثر من GPU واحد

مع وجود عدة وحدات GPU، لديك خياران.

• ▸النسخ المتماثل (Replication): ضع نسخة كاملة من النموذج على كل GPU وقسم المستخدمين بين النسخ. إذا كان النموذج يتسع على بطاقة واحدة، فهذا عادة ما يكون الخيار الأفضل لمعدل الإنتاجية، لأن النسخ لا تنتظر بعضها البعض أبداً.
• ▸التقسيم (Sharding): قسم نموذجاً واحداً عبر عدة وحدات GPU. تحتاج إلى هذا عندما يكون النموذج أكبر من أن يتسع لبطاقة واحدة. تتبادل وحدات الـ GPU البيانات باستمرار، لذا فإن الاتصال بينها مهم. يساعد رابط GPU المباشر مثل NVLink، بينما تكون فتحات PCIe العادية أبطأ.

من الأخطاء الشائعة تقسيم نموذج كان من الممكن أن يتسع على بطاقة واحدة. أنت تدفع تكلفة الاتصال (overhead) ولا تحصل على شيء مقابل ذلك.

تشخيص البطء لديك

ابحث عن العرض، ثم انتقل إلى الأداة الخاصة به. اعمل على الجدول بالترتيب. غالباً ما تجعل الإصلاحات المبكرة الإصلاحات اللاحقة غير ضرورية.

تأثير ذلك على دراسة الجدوى

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

التكلفة لكل إجابة = (التكلفة الشهرية للأجهزة + الطاقة + الدعم) ÷ الإجابات المقدمة شهرياً

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

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

ما هو أصغر GPU يعمل لنشر محلي مشترك؟ اجمع ثلاثة أشياء: ذاكرة الأوزان من الصيغة أعلاه، والذاكرة العاملة للمستخدمين المتوقعين، وبعض المساحة الإضافية (headroom). بطاقة 24 جيجابايت تستوعب بشكل مريح نموذجاً بحجم 7B إلى 14B بدقة 4 بت، مع ترك مساحة لعدة مستخدمين. بدقة 4 بت، تأخذ أوزان نموذج 70B وحدها حوالي 35 إلى 40 جيجابايت. هذا يعني بطاقة 48 جيجابايت أو وحدتي GPU تعملان معاً. بالنسبة لفريق واحد على بطاقة استهلاكية واحدة، يوضح بناء 6 إلى 8 جيجابايت ما يتسع وما لا يتسع.

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

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

خطوتك التالية هذا الأسبوع: اسحب سجلات يوم واحد. لاحظ متوسط طول الموجّه والمحرك الذي يقدم النموذج. هاتان الحقيقتان تخبرانك في أي صف من الجدول أنت.