تسريع Llama 2 70B باستخدام NVIDIA H100

يدفعنا السعي وراء الأداء في محرك إجابات Perplexity إلى تبني أحدث التقنيات التي تقدمها NVIDIA وAWS. في هذه المدونة، يسعدنا مشاركة نتائج أحدث تجاربينا: مقارنة لاستدلال Llama 2 70B عبر مختلف إعدادات الأجهزة والبرامج.

منصة استدلال النماذج اللغوية الكبيرة لدينا، pplx-api، مبنية على بنية متطورة مدعومة بمكتبات مفتوحة المصدر. منذ بدء النسخة التجريبية العامة لـ pplx-api في أكتوبر، واجهنا تحديات التوسع وتعلمنا أفضل طريقة لضبط إعداداتنا لتحقيق نطاق واسع جداً. وقد قادنا هذا إلى إجراء تجارب بناءً على الأسئلة التوجيهية التالية:

ما هو مكسب الأداء الخام الناتج عن تبديل وحدات معالجة الرسومات (GPUs) الخاصة بنا من NVIDIA A100 إلى NVIDIA H100، مع بقاء جميع الإعدادات الأخرى كما هي؟

ما هو مكسب الكفاءة الناتج عن التكميم بفاصلة عائمة 8 بت (fp8)، والذي تضيف H100 دعماً أصلياً له؟ وما هي تكلفة الدقة لهذا التكميم؟

كيف تؤثر التوازية الموتّرية (tensor parallelism) وحجم الدفعة (batch size) على زمن الانتقال وإنتاجية الرموز (token throughput)؟

بالنظر إلى ما سبق، أي إعداد يؤدي إلى التوازن الأكثر قابلية للتوسع بين الأداء وكفاءة التكلفة؟

الإعداد التجريبي

أجرينا التجربة التالية كسلسلة من المعايير المحلية لتجنب زمن انتقال الشبكة.

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

زمن الانتقال (Latency): إجمالي الوقت الذي يستغرقه خادم الاستدلال لتوليد استجابته الكاملة.

إنتاجية (Throughput): عدد رموز الإخراج، في الثانية، لكل وحدة معالجة رسومات (GPU)، والتي يمكن لخادم الاستدلال توليدها عبر جميع المستخدمين والطلبات.

الثوابت:

ستؤثر العوامل التالية على المقاييس الرئيسية، لذلك حافظنا عليها ثابتة عبر التجارب المختلفة للتجربة.

نموذج الذكاء الاصطناعي

يتناسب الأداء طردياً مع حجم النموذج اللغوي الكبير. تتطلب المعلمات الأكثر حسابات أكثر مما يؤدي إلى استدلال أبطأ. على سبيل المثال، Llama 2 13B أسرع من Llama 2 70B عندما تكون الإعدادات الأخرى متساوية. نلتزم بـ Llama 2 70B في هذه التجربة لأننا نريد تحسين خدمة النماذج مفتوحة المصدر الأكثر قدرة.

مجموعة بيانات رموز الإدخال/الإخراج

يمكن أن تؤثر كمية رموز الإدخال والإخراج في كل زوج طلب/استجابة عينة على قياسات الأداء. بشكل عام، يسيطر توليد رموز الإخراج على وقت الاستجابة الإجمالي. عندما تؤدي بيانات العينة فقط إلى استجابات "نعم/لا" من النموذج اللغوي الكبير، تكون الاستجابة أسرع مقارنة بالعينات التي تطلب من النموذج كتابة مقالات. تتكون مجموعة بياناتنا من طلبات اصطناعية تحتوي على 1024 رمز إدخال تحفز 512 رمز إخراج. تم اختيار هذا التوزيع ليطابق توزيع حركة المرور الملوحظ على نشرنا العام لـ Llama2 70B.

إصدار البرمجيات

NVIDIA TensorRT-LLM (الإصدار v0.5.0) هي مكتبة مفتوحة المصدر لتحسين استدلال النماذج اللغوية الكبيرة. تم إطلاقها في أواخر عام 2023، وهي تدمج العديد من تحسينات الاستدلال الخاصة بـ NVIDIA وتوفر طبقة مرنة من التخصيص للمقاييس الرئيسية لهذه التجربة: حجم الدفعة، والتكميم، والتوازية الموتّرية.

المتغيرات

لقد قمنا بالتجربة عبر 4 محاور تكوين: التوازية الموتّرية، وبنية وحدة معالجة الرسومات، والتكميم، و الحد الأقصى لحجم الدفعة. هذه المحاور مترابطة لأن كل منها يمثل مقايضة فيما يتعلق بمورد عنق الزجاجة الحاسم وهو ذاكرة وحدة معالجة الرسومات.

بنية وحدة معالجة الرسومات (GPU)

تضم بنية وحدة معالجة الرسومات Hopper (H100-HBM3-80GB / p5.48xlarge) من الجيل التاسع قائمة ضخمة من الميزات مقارنة بسابقتها، Ampere (A100-SXM4-80GB / p4de.24xlarge)، بما في ذلك معدلات الحساب من 2 إلى 6 مرات وما يقرب من ضعف النطاق الترددي لذاكرة وحدة معالجة الرسومات. يُعد النطاق الترددي لذاكرة وحدة معالجة الرسومات مقياساً بالغ الأهمية للاستدلال لأن الاختناق الأساسي لزمن الانتقال لعمليات ضرب المصفوفات في الاستدلال يأتي من تحميل جيجابايت من بيانات النموذج من ذاكرة وحدة معالجة الرسومات إلى سجلات الحساب. بناءً على هذه الإحصائيات، افترضنا أن مقارنة متكافئة بين NVIDIA H100 و A100 ستظهر تحسناً بمقدار الضعف في كل من زمن الانتقال والإنتاجية.

هناك اختلاف رئيسي آخر بين NVIDIA H100 و A100 وهو أن نواة الموتر (tensor core) في H100 تضيف بشكل أصلي دعماً لتعليمات الفاصلة العائمة 8 بت (fp8)، مما يفتح الباب لمزيد من التحسينات الموضحة أدناه. ولهذا السبب نستخدم fp8 و fp16 خصيصاً لـ H100.

للحفاظ على ثبات الذاكرة لكل وحدة معالجة رسومات في هذه التجربة، التزمنا بالعقد التي تحتوي على ذاكرة وحدة معالجة رسومات 8x80GB لكل من وحدات NVIDIA A100 و H100 الخاصة بنا. بالإضافة إلى تمكين أحجام دفعات أعلى، تُعد ذاكرة وحدة معالجة الرسومات مهمة لأنه يتم تحميل معلمات النموذج في ذاكرة وحدة معالجة الرسومات أثناء بدء تشغيل الخادم للوصول السريع. على سبيل المثال، إذا كانت كل معلمة من المعلمات الـ 70 مليار في نموذجنا عبارة عن رقم فاصلة عائمة بـ 16 بت، فإن حجم النموذج يبلغ حوالي 140 جيجابايت، وهو ما لا يتسع على وحدة معالجة رسومات واحدة. ومن هنا جاءت الحاجة إلى التوازية الموتّرية، والتي سنشرحها أدناه.

التوازية الموتّرية (Tensor Parallelism)

تشير التوازية الموتّرية إلى عدد أجهزة وحدة معالجة الرسومات المستهلكة لتشغيل خادم الاستدلال. عندما نخصص عدداً من وحدات معالجة الرسومات، يقوم TensorRT-LLM بتجميع مواردها معاً لمساعدتنا في الوصول إلى الحد الأدنى لميزانية الذاكرة المطلوبة لتشغيل Llama2 70B. فرضيتنا هي أن التوازية الموتّرية الأقل ستؤدي إلى زمن انتقال أعلى (بسبب الموارد الأقل المستهلكة لتلبية كل دفعة) ولكن بإنتاجية أعلى لكل وحدة معالجة رسومات (بسبب الاستخدام الأفضل) عند مقارنتها بالتوازية الموتّرية الأعلى.

التكميم (Quantization)

التكميم هو تقليل الدقة في الأوزان والتنشيطات التي تستخدمها الشبكات العصبية. نستخدم هذه التقنية لتنصيف استهلاك ذاكرة وحدة معالجة الرسومات عندما ننتقل من fp16 إلى fp8. هذا يجعل من الممكن تشغيل نفس النموذج باستخدام إجمالي أقل لذاكرة وحدة معالجة الرسومات، مما يتيح توازية موتّرية أقل، مما يؤدي إلى زيادة الإنتاجية.

تنفيذات التكميم لديها القدرة على تقليل الدقة. وبالتالي، قمنا بتقييم الدقة للدرجات المختلفة من خلال مقارنة إحصائية الحيرة (perplexity) الخاصة بهم، وهي مقياس لمدى جودة تنبؤ النموذج اللغوي الكبير بكل رمز تالي في الجملة، على مجموعة بيانات WikiText. بالنسبة للفاصلة العائمة 8 بت ووزن 8 بت مع تنشيط 8 بت و SmoothQuant (w8a8 SQ)، لم يكن هناك تغيير كبير في الحيرة (< 1%) مقارنة بـ fp16 على WikiText، لذلك شعرنا بالثقة للمتابعة. ومع ذلك، أظهر w4a16 تغييراً كبيراً بنسبة 7% في الحيرة، والذي يمكن أن يُعزى ربما إلى الدقة الأقل والتحويلات الديناميكية الضرورية بين int4 و fp16.

حجم الدفعة (Batch Size)

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

تكبير

في حالة Llama 2 70B (الذي يحتوي على 80 طبقة)، و fp16 مع حجم دفعة 32 لحجم سياق 4096، يبلغ حجم ذاكرة التخزين المؤقت KV حوالي 40 جيجابايت. هذا يمنع في النهاية Llama 2 70B fp16، الذي تستهلك أوزانه وحدها 140 جيجابايت، من الملء بشكل مريح في ذاكرة وحدة معالجة الرسومات البالغة 160 جيجابايت والمتوفرة عند التوازية الموتّرية 2 (TP-2).

النتائج

لقد قمنا باستعراض المجموعات المتوافقة للمتغيرات الأربعة للتجربة ونعرض الاتجاهات الأكثر إضاءة أدناه.

تكبير

تحسن زمن الانتقال للتكميم يقع في حدود 10% عند مقارنة H100 fp16 → fp8 و A100 fp16 → w8a8 مع SmoothQuant. ومع ذلك، فإن الدقة المختلطة w4a16 تؤدي في الواقع بشكل أفضل في أحجام الدفعات المنخفضة وبشكل أسوأ في أحجام الدفعات الأعلى مقارنة بـ fp16. قد يكون هذا بسبب عدد من العوامل، بما في ذلك نوى الحساب الأقل تحسيناً، ووقت الصب بين int4 و fp16، وحقيقة أن w4a16 لا يزال يستخدم نقاط فاصلة عائمة بـ 16 بت للتنشيطات، مما لا يؤدي إلى توفير في أبعاد ذاكرة التخزين المؤقت KV. نظراً لأن w4a16 أظهر أيضاً دقة أقل، فإننا نخلص إلى أنه يجب علينا الالتزام بـ w8a8 SQ لوحدات A100 و fp8 لوحدات H100.

تكبير

في أول شكلين لدينا، نعرض فقط تكوينات TP-8. تحقق H100 نسبة 54% من زمن الانتقال و184% من الإنتاجية مقارنة بـ A100 عندما يستخدم كلاهما fp16 / BS-128 / TP-8، والتي تتحسن إلى 49% من زمن الانتقال و 202% من الإنتاجية عند استخدام fp8 على H100. يمكن تعزية هذا التحسن في الأداء إلى الزيادات في قوة الحساب والنطاق الترددي للذاكرة بين H100 و A100. والجدير بالذكر أن الفارق يكون أقل وضوحاً تحت أحجام الدفعات الأصغر حيث قد يكون الاستخدام أقل.

بينما نبني منصتنا، نريد احترام متطلبات زمن الانتقال المعينة لمستخدمينا مع تعظيم الإنتاجية. وبالتالي، بدلاً من مقارنة A100 مقابل H100 بنفس حجم الدفعة، من المنطقي في الواقع بالنسبة لنا مقارنة إنتاجيتها فقط في ظل التكوينات التي تلبي فيها متطلبات زمن الانتقال. لقد حددنا قطعاً عند زمن انتقال 25600 مللي ثانية لإكمال رموز الإخراج الـ 512 ووجدنا أن H100 / TP-8 / fp8 / BS-128 ينتج 251% من الإنتاجية مقارنة بـ A100 / TP-8 / fp16 / BS-64، نظراً لقدرته على معالجة ضعف حجم الدفعة بزمن انتقال أقل. بالنظر إلى أن التكميم يوفر وفورات في ذاكرة وحدة معالجة الرسومات، نحتاج الآن إلى تقييم كيف يمكن للتوازية الموتّرية إضافة طبقة تالية من التحسين.

تكبير

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

تكبير

تكوين تعظيم الإنتاجية لتجربتنا هو H100 / fp8 / TP-2 / BS-128، بمعدل 767 رمز إخراج في الثانية لكل وحدة معالجة رسومات. هذا تحسن بنسبة 460% مقارنة بـ A100 / fp16 / TP-8 / BS-64. ومع ذلك، يأتي ذلك على حساب مضاعفة زمن الانتقال - أقرب إلى 42000 مللي ثانية لـ 512 رمز إخراج - لذلك قد يكون غير مناسب كتهيئة للإنتاج. قد تمثل نتائج TP-4 BS-128 (626 رمز/ثانية/وحدة معالجة رسومات عند وقت استجابة 26188 مللي ثانية) و TP-2 BS-32 (435 رمز/ثانية/وحدة معالجة رسومات عند وقت استجابة 18821 مللي ثانية) مقايضات أفضل على مقاييسنا الرئيسية.

الخاتمة

تظهر نتائجنا ما يلي:

نصل إلى نسبة 54% من زمن الانتقال و184% من الإنتاجية باستخدام H100 مقارنة بـ A100 بالنظر إلى نفس التهيئة، والتي تتحسن إلى 49% و 202% على التوالي عندما تستفيد H100 من دعمها الأصلي لـ fp8.

عند تعظيم الإنتاجية مع مراعاة قيد زمن الانتقال، تنتج H100 / fp8 / TP-8 / BS-128 نسبة 251% من الإنتاجية مقارنة بـ A100 / fp16 / TP-8 / BS-64، حيث يمكنها معالجة ضعف الدفعة بسرعة أكبر.

بالاستفادة من H100 مع TP-2 مع fp8، يمكننا تحقيق 373% من إنتاجية A100 / fp16 / TP-8 / BS-128، مع زيادة أقل من 10% في زمن الانتقال.

يقدم حجم الدفعة والتوازية الموتّرية مقايضة بين الإنتاجية وزمن الانتقال لمشغل نظام استدلال النماذج اللغوية الكبيرة.

هذه النتائج تجعلنا نشعر بالثقة بشأن الانتقال الكامل إلى وحدات معالجة الرسومات H100 في بنية الأجهزة المدعومة سابقاً بـ A100. نحن متحمسون لقدرتنا على تأكيد مكاسب الأداء التي أعلنت عنها NVIDIA ونتطلع إلى اختراقاتهم القادمة في الأجهزة المسرعة.

ما التالي

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

على المدى القريب، ستقوم pplx-api برفع حدود المعدل وتقديم المزيد من نماذج Perplexity اللغوية الكبيرة المخصصة، بما في ذلك نموذج لغوي كبير مدعوم بالإنترنت مع التأريض للحقائق.

اشترك في Perplexity Pro على perplexity.ai/pro. احصل على إمكانية الوصول إلى pplx-api المتطورة لدينا، واستفد من هذه الإمكانيات المتقدمة في مشاريعك. اكتشف المزيد حول pplx-api على مدونتنا.

هل أنت مهتم بتشكيل مستقبل الذكاء الاصطناعي؟ نحن نوظف! كن جزءاً من فريق يقود البنية التحتية التوليدية للنماذج اللغوية الكبيرة واسعة النطاق. استكشف الفرص في وظائف Perplexity.

المؤلفون:

آراش حيدري، غريغوري أليكسييف، كيفن هو، دينيس ياريتس