في الآونة الأخيرة، أصبحت نماذج توليد التعليمات البرمجية شائعة جدًا، خاصة مع إصدار أحدث النماذج مفتوحة المصدر مثل BigCode’s StarCoder وMeta AI’s Code Llama. يركز عدد متزايد من الأعمال على جعل نماذج اللغات الكبيرة (LLMs) أكثر تحسينًا ويمكن الوصول إليها. في هذه المدونة، يسعدنا أن نشارك أحدث نتائج تحسين LLM على Intel Xeon مع التركيز على توليد التعليمات البرمجية الشهير LLM، StarCoder.
يعد StarCoder Model عبارة عن LLM متطور مصمم خصيصًا لمساعدة المستخدم في مهام البرمجة المختلفة مثل إكمال التعليمات البرمجية وإصلاح الأخطاء وتلخيص التعليمات البرمجية وحتى إنشاء مقتطفات التعليمات البرمجية من أوصاف اللغة الطبيعية. يعد نموذج StarCoder عضوًا في عائلة StarCoder التي تتضمن متغير StarCoderBase أيضًا. يتم تدريب نماذج اللغات الكبيرة هذه للبرمجة (Code LLMs) على البيانات المرخصة من GitHub، بما في ذلك أكثر من 80 لغة برمجة، والتزامات Git، ومشكلات GitHub، ودفاتر Jupyter. نعرض في هذا العمل تسريع الاستدلال بأكثر من 7x لنموذج StarCoder-15B على الجيل الرابع من Intel Xeon من خلال دمج تكميم 8 بت و4 بت مع التوليد المساعد.
جرب العرض التوضيحي الخاص بنا حول Hugging Face Spaces الذي يتم تشغيله على معالج Intel Xeon Scalable من الجيل الرابع.
الخطوة 1: خط الأساس والتقييم
قمنا بإنشاء خط الأساس الخاص بنا باستخدام StarCoder (15B) إلى جانب PyTorch وIntel Extension for PyTorch (IPEX). هناك العديد من مجموعات البيانات المصممة لتقييم جودة إكمال التعليمات البرمجية تلقائيًا. في هذا العمل، نستخدم مجموعة بيانات HumanEval الشهيرة لتقييم جودة النموذج وأدائه. يتكون HumanEval من 164 مشكلة برمجية، في شكل توقيع دالة مع سلسلة مستندية ويكمل النموذج كود الوظيفة. متوسط طول المطالبة هو 139. نحن نقيس الجودة باستخدام Bigcode Evaluation Harness ونبلغ عن مقياس pass@1. نقوم بقياس أداء النموذج من خلال قياس الوقت حتى الرمز المميز الأول (TTFT) والوقت لكل رمز إخراج (TPOT) في مجموعة اختبار HumanEval والإبلاغ عن متوسط TTFT وTPOT. تتميز معالجات Intel Xeon من الجيل الرابع بتسارع معزز بالذكاء الاصطناعي يُعرف باسم Intel® Advanced Matrix Extensions (Intel® AMX). على وجه التحديد، يحتوي على مسرعات BFloat16 (BF16) وInt8 GEMM مدمجة في كل مركز لتسريع التدريب على التعلم العميق واستدلال أعباء العمل. يتم تقديم الاستدلال المتسارع لـ AMX من خلال PyTorch 2.0 وIntel Extension for PyTorch (IPEX) بالإضافة إلى تحسينات أخرى لمختلف عوامل التشغيل الشائعة المستخدمة في استدلال LLM (على سبيل المثال تطبيع الطبقة، SoftMax، منتج النقاط المقيسة). كنقطة بداية، نستخدم التحسينات المبتكرة في PyTorch وIPEX لإجراء الاستدلال باستخدام نموذج BF16. يوضح الشكل 1 زمن الوصول للنموذج الأساسي، ويوضح الجدولان 1 و2 زمن الوصول الخاص به بالإضافة إلى دقته.
الشكل 1. الكمون للنموذج الأساسي.
LLM التكميم
يتم تنفيذ إنشاء النص في LLMs بطريقة انحدارية تلقائية وبالتالي يتطلب تحميل النموذج بأكمله من الذاكرة إلى وحدة المعالجة المركزية لكل جيل جديد من الرموز المميزة. نجد أن عرض النطاق الترددي بين الذاكرة خارج الرقاقة (DRAM) ووحدة المعالجة المركزية يشكل أكبر عنق الزجاجة في عملية إنشاء الرمز المميز. التكميم هو نهج شائع للتخفيف من هذه المشكلة. إنه يقلل من حجم النموذج وبالتالي يقلل من وقت تحميل أوزان النموذج.
نركز في هذا العمل على نوعين من التكميم:
- تكميم الوزن فقط (WOQ) – أوزان النموذج التي يتم تكميمها ولكن ليس عمليات التنشيط أثناء إجراء الحساب بدقة أعلى (على سبيل المثال BF16) والتي تتطلب استخلاص الكمية.
- التكميم الثابت (SQ) – يتم تكميم كل من الأوزان وعمليات التنشيط. تتضمن عملية التكميم هذه إجراء حساب مسبق لمعلمات التكميم من خلال خطوة معايرة تمكن من تنفيذ الحساب بدقة أقل (مثل INT8). ويبين الشكل 2 عملية حساب الكمي الثابت INT8.
الخطوة 2: التكميم 8 بت (INT8)
SmoothQuant عبارة عن خوارزمية تكميم ما بعد التدريب يتم استخدامها لتكميم LLMs لـ INT8 مع الحد الأدنى من فقدان الدقة. تبين أن أساليب القياس الكمي الثابتة ضعيفة الأداء في LLMs بسبب القيم المتطرفة كبيرة الحجم الموجودة في قنوات محددة للتنشيط. نظرًا لأن عمليات التنشيط يتم قياسها بشكل رمزي، فإن التكميم الثابت يؤدي إما إلى القيم المتطرفة المقطوعة أو عمليات التنشيط منخفضة الحجم. تعمل خوارزمية SmoothQuant على حل هذه المشكلة عن طريق تقديم مرحلة ما قبل التكميم حيث يتم تطبيق عوامل قياس تجانس إضافية على كل من عمليات التنشيط والأوزان مما يعمل على تسهيل القيم المتطرفة في عمليات التنشيط ويضمن استخدام أفضل لمستويات التكميم.
الشكل 2. رسم تخطيطي لحساب التكميم الثابت INT8.
باستخدام IPEX، نقوم بتطبيق SmoothQuant على نموذج StarCoder. استخدمنا تقسيم الاختبار لمجموعة بيانات MBPP كمجموعة بيانات المعايرة الخاصة بنا وقدمنا Q8-StarCoder. يُظهر تقييمنا أن Q8-StarCoder لا يحمل أي خسارة في الدقة فوق خط الأساس (في الواقع، هناك تحسن طفيف). من حيث الأداء، يحقق Q8-StarCoder ~2.19x تسريع في TTFT و ~2.20x تسريع في TPOT. يوضح الشكل 3 زمن الوصول (TPOT) لـ Q8-StarCoder مقارنة بالنموذج الأساسي BF16.
الشكل 3. تسريع زمن الوصول للنموذج الكمي 8 بت.
الخطوة 3: التكميم 4 بت (INT4)
على الرغم من أن INT8 يقلل حجم النموذج بمقدار 2x مقارنة بـ BF16 (8 بت لكل وزن مقارنة بـ 16 بت)، إلا أن عرض النطاق الترددي للذاكرة لا يزال يمثل أكبر عنق الزجاجة. لتقليل وقت تحميل النموذج من الذاكرة بشكل أكبر، قمنا بقياس أوزان النموذج إلى 4 بتات باستخدام WOQ. لاحظ أن 4 بت WOQ يتطلب موازنة إلى 16 بت قبل الحساب (الشكل 4) مما يعني أن هناك حمل حسابي.
الشكل 4. رسم تخطيطي حسابي للنموذج الكمي إلى INT4.
يشكل تكميم الجولة إلى الأقرب (RTN) غير المتماثل من حيث الموتر، وهو تقنية WOQ أساسية، تحديات ويؤدي غالبًا إلى تقليل الدقة، ومع ذلك فقد ظهر في الأدبيات (Zhewei Yao، 2022) أن التكميم الجماعي لأوزان النموذج يساعد في الحفاظ على الدقة. لتجنب تدهور الدقة، نقوم بإجراء تكميم 4 بت في مجموعات (على سبيل المثال 128) للقيم اللاحقة على طول قناة الإدخال، مع احتساب عوامل القياس لكل مجموعة. لقد وجدنا أن نظام RTN 4 بت الخاص بالمجموعة كافٍ للاحتفاظ بدقة StarCoder في مجموعة بيانات HumanEval. نموذج 4 بت يحقق 3.35x تسريع في TPOT مقارنة بخط الأساس BF16 (الشكل 5)، ومع ذلك فإنه يعاني من التباطؤ المتوقع بمقدار 0.84x في TTFT (الجدول 1) بسبب الحمل الزائد لإلغاء تكميم 4 بت إلى 16 بت قبل الحساب.
الشكل 5. تسريع زمن الوصول للنموذج الكمي 4 بت.
اختناقات مختلفة بين إنشاء الرمز المميز الأول والرموز اللاحقة
تتطلب الخطوة الأولية لإنشاء الرمز المميز الأول، والتي تتضمن معالجة متوازية لموجه الإدخال بأكمله، موارد حسابية كبيرة عندما يكون طول الموجه مرتفعًا. ولذلك يصبح الحساب هو عنق الزجاجة في هذه المرحلة. ومن ثم، فإن التبديل من دقة BF16 إلى INT8 لهذه العملية يعمل على تحسين الأداء مقارنة بخط الأساس (و4 بت WOQ الذي يتضمن حساب النفقات العامة في شكل استخلاص الكمية). ومع ذلك، بدءًا من الخطوة الثانية، عندما يقوم النظام بإنشاء بقية الرموز المميزة واحدًا تلو الآخر بطريقة الانحدار التلقائي، يتم تحميل النموذج من الذاكرة مرارًا وتكرارًا لكل رمز مميز جديد تم إنشاؤه. ونتيجة لذلك، يصبح عنق الزجاجة هو عرض النطاق الترددي للذاكرة، بدلاً من عدد العمليات الحسابية (FLOPS) التي يتم إجراؤها، وبالتالي يتفوق INT4 على INT8 وBF16.
الخطوة 4: الجيل المدعوم (AG)
هناك طريقة أخرى للتخفيف من زمن الوصول العالي للاستدلال وتخفيف مشكلة عنق الزجاجة في عرض النطاق الترددي للذاكرة وهي الجيل المساعد (AG) وهو تطبيق عملي لفك التشفير التخميني. تعمل AG على تخفيف هذه المشكلة من خلال تحقيق توازن أفضل بين الذاكرة والعمليات الحسابية. يعتمد على فرضية مفادها أن نموذج المسودة المساعد الأصغر والأسرع غالبًا ما يولد نفس الرموز المميزة للنموذج المستهدف الأكبر.
تستخدم AG نموذجًا صغيرًا وسريعًا لإنشاء الرموز المميزة لمرشح K. يتم إنشاء رموز الإخراج المميزة هذه بشكل أسرع بكثير، ولكن قد لا يشبه بعضها رموز الإخراج المميزة للنموذج المستهدف الأصلي. وبالتالي، في الخطوة التالية، يتحقق النموذج المستهدف من صلاحية جميع الرموز المميزة لمرشح K بالتوازي في تمرير أمامي واحد. تعمل هذه العملية على تسريع عملية فك التشفير نظرًا لأن زمن الوصول لفك التشفير المتوازي لرموز K أصغر من إنشاء رموز K بشكل انحداري.
لتسريع StarCoder، نستخدم bigcode/tiny_starcoder_py كنموذج مسودة. يشترك هذا النموذج في بنية مشابهة مع StarCoder ولكنه يتضمن 164 مليون معلمة فقط – ~95x أصغر من StarCoder، وبالتالي أسرع بكثير. لتحقيق تسريع أكبر، بالإضافة إلى تكميم النموذج المستهدف، فإننا نطبق التكميم على مسودة النموذج أيضًا. نحن نأخذ في الاعتبار كلا من تكمية 8bit SmoothQuant و4bit WOQ للمسودة والنماذج المستهدفة. عند تقييم كل من خيارات التكمية للنماذج المسودة والهدف، وجدنا أن 8bit SmoothQuant لكلا النموذجين حقق أفضل النتائج: ~7.30x تسريع في TPOT (الشكل 6).
يتم دعم خيارات التكميم هذه بالملاحظات التالية:
- تقدير نموذج المسودة: عند استخدام StarCoder المكمّم 8 بت مع 164 مليون معلمة كمسودة للنموذج، فإن النموذج يتناسب في الغالب مع ذاكرة التخزين المؤقت لوحدة المعالجة المركزية. ونتيجة لذلك، يتم تخفيف عنق الزجاجة في عرض النطاق الترددي للذاكرة، حيث يحدث إنشاء الرمز المميز دون قراءة النموذج المستهدف بشكل متكرر من الذاكرة خارج الرقاقة لكل رمز مميز. في هذه الحالة، لا يوجد اختناق في الذاكرة، ونرى تسريعًا أفضل مع StarCoder-164M مكمّمًا إلى 8 بت مقارنةً بـ StarCoder-164M مكمّمًا إلى 4 بت WOQ. نلاحظ أن 4 بت WOQ يتمتع بميزة حيث يكون عرض النطاق الترددي للذاكرة هو عنق الزجاجة بسبب صغر حجم الذاكرة، ومع ذلك فإن 4 بت يأتي مع عبء حسابي بسبب متطلبات إجراء استخلاص 4 بت إلى 16 بت قبل الحساب.
- تكميم النموذج المستهدف: في التوليد المدعوم، يقوم النموذج المستهدف بمعالجة سلسلة من رموز K التي تم إنشاؤها بواسطة مسودة النموذج. يؤدي إعادة توجيه رموز K مرة واحدة (بالتوازي) من خلال النموذج المستهدف بدلاً من تطبيق معالجة الانحدار التلقائي المتسلسلة “القياسية”، إلى تحويل التوازن من عرض النطاق الترددي للذاكرة إلى حساب عنق الزجاجة. لذلك، لاحظنا أن استخدام نموذج مستهدف كمي 8 بت يؤدي إلى سرعات أعلى من استخدام نموذج 4 بت بسبب عبء الحوسبة الإضافي الذي ينبع من تجزئة كل قيمة فردية من 4 بت إلى 16 بت.
الشكل 6. تسريع زمن الوصول للنموذج الأمثل.
| ستاركودر | التكميم | دقة | تقييم الإنسان (تمرير@1) | TTFT (ملي ثانية) | تسريع TTFT | تبوت (مللي ثانية) | تسريع TPOT |
|---|---|---|---|---|---|---|---|
| خط الأساس | لا أحد | A16W16 | 33.54 | 357.9 | 1.00x | 181.0 | 1.00x |
| إنت8 | SmoothQuant | A8W8 | 33.96 | 163.4 | 2.19x | 82.4 | 2.20x |
| إنت4 | رتن (ز128) | A16W4 | 32.80 | 425.1 | 0.84x | 54.0 | 3.35x |
| إنت8 + أي جي | SmoothQuant | A8W8 | 33.96 | 183.6 | 1.95x | 24.8 | 7.30x |
الجدول 1: قياسات الدقة وزمن الوصول لنموذج StarCoder على Intel 4th Gen Xeon
لتحميل النماذج الناتجة وتشغيل الاستدلال، يمكنك فقط استبدال ملف AutoModelForXxx الطبقة مع المقابلة IPEXModelForXxx فئة من optimum-intel.
قبل البدء، تأكد من تثبيت كافة المكتبات الضرورية:
pip install --upgrade-strategy eager optimum[ipex]
- from transformers import AutoModelForCausalLM
+ from optimum.intel import IPEXModelForCausalLM
from transformers import AutoTokenizer, pipeline
- model = AutoModelForCausalLM.from_pretrained(model_id)
+ model = IPEXModelForCausalLM.from_pretrained(model_id)
tokenizer = AutoTokenizer.from_pretrained(model_id)
pipe = pipeline("text-generation", model=model, tokenizer=tokenizer)
results = pipe("He's a dreadful magician and")
