GPUDirect و TurboQuant: AWS تسرع تحميل نماذج LLM الكبيرة على GPU

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

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

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

الحقائق الرئيسية:

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

كيف يسرع GPUDirect العملية؟

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

ما الذي يوفره TurboQuant؟

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

لماذا هذا مهم الآن

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

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