GPUDirect وTurboQuant: AWS تُسرّع تحميل نماذج LLM الضخمة على وحدات GPU

تناولت AWS في مدونة AWS Machine Learning Blog مشكلة تواجهها فرق متزايدة تنشر نماذج اللغة الكبيرة (LLM) على مثيلات GPU في السحابة: كلما كبر حجم النموذج الذي يجب تحميله في الذاكرة عالية النطاق الترددي (High Bandwidth Memory, HBM) الخاصة بالمسرّعات الرسومية، طالت مدة الانتظار قبل أن تصبح وحدات GPU جاهزة للاستدلال. ويُفهم من عنوان المنشور أن الشركة تقترح حل هذه المشكلة عبر الجمع بين تقنيتي GPUDirect وTurboQuant اللتين تُسرّعان تحميل النماذج الكبيرة على وحدات GPU.

ما المشكلة في تحميل النماذج الكبيرة

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

أبرز الوقائع:

• يتعلق الأمر بتحميل نماذج LLM في الذاكرة عالية السرعة لوحدات GPU (HBM).
• تتفاقم المشكلة مع نمو النماذج إلى مئات المليارات من المعاملات.
• عناقيد GPU المخصصة للاستدلال تواصل النمو من حيث الحجم.
• يجمع الحل المعلن من AWS بين تقنيتي GPUDirect وTurboQuant.
• نُشرت المادة في AWS Machine Learning Blog.

كيف يُسرّع GPUDirect العملية

GPUDirect هو اسم عام لعائلة من التقنيات التي تتيح الوصول المباشر إلى ذاكرة GPU، بحيث تنتقل البيانات بين وحدة التخزين (أو بطاقة الشبكة) وذاكرة بطاقة الرسوميات مباشرة، دون نسخ إضافية عبر الذاكرة العشوائية والمعالج المركزي للمضيف. وفي سياق تحميل النماذج الكبيرة، يعني ذلك أن أوزان النموذج يمكن أن تصل من وحدة تخزين سريعة إلى HBM الخاصة بـ GPU مباشرة، دون أن تتشكل عنق زجاجة على جانب CPU. وهذه النسخ الوسيطة تحديدًا كانت تقليديًا أحد أسباب طول زمن بدء تشغيل النماذج الكبيرة على مثيلات GPU.

ماذا يضيف TurboQuant

الجزء الثاني من الحل، TurboQuant، يرتبط بحسب اسمه بالتكميم (Quantization)، وهي تقنية لضغط أوزان النموذج عبر خفض دقة تمثيل الأعداد، كالانتقال من أعداد بدقة 32 أو 16 بت إلى صيغ أكثر إحكامًا. وكلما قل حجم البيانات المطلوب نقلها إلى ذاكرة GPU، أسرع التحميل، مع بقاء العوامل الأخرى ثابتة. وبالنسبة للفرق التي تشغّل نماذج LLM في بيئة الإنتاج، فإن الجمع بين مسار أسرع لنقل البيانات (GPUDirect) وحجم أصغر للبيانات نفسها بفضل التكميم قد يقلّص نظريًا وبشكل ملحوظ الفترة بين تشغيل مثيل GPU ولحظة جاهزية النموذج لخدمة أول طلب. وهذا مؤشر بالغ الأهمية للتوسع التلقائي وفق الحمل، ولإجمالي تكلفة امتلاك البنية التحتية للذكاء الاصطناعي في السحابة.

لماذا يهم هذا الأمر الآن تحديدًا

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

أما بالنسبة لمزوّد سحابي مثل AWS، فإن تسريع تحميل النماذج مسألة تنافسية تتعلق ببنيته التحتية أيضًا: فالعملاء الذين ينشرون نماذج LLM في بيئة الإنتاج لا يقارنون تكلفة استئجار مثيلات GPU فحسب، بل أيضًا الوقت والمال اللذين تستهلكهما الدورة الكاملة من التشغيل حتى جاهزية الخدمة لاستقبال حركة مرور حقيقية. ونشر مثل هذه التحليلات الهندسية في AWS Machine Learning Blog يؤدي مهمتين في آن واحد: يشارك مجتمع المطورين تحسينات عملية، ويُظهر أن المزوّد يعمل بصورة منهجية على إزالة الاختناقات التي يواجهها مستخدمو وحدات GPU السحابية عمليًا عند توسيع خدماتهم القائمة على الذكاء الاصطناعي.