What actually runs: a measurement study of language model placement and decode speed on the Apple Neural Engine
من خلال دراسة قياس صارمة لموضع النموذج اللغوي وسرعة فك التشفير على محرك أبل العصبي (Apple Neural Engine)، يوضح المؤلف أن التعبير الحسابي وتشفير الأوزان، وليس بنية النموذج وحدها، هما ما يحددان الإقامة في المسرع والأداء، مما يؤدي إلى إجراء تصميم يعطي الأولوية لكفاءة التشفير لتحقيق نماذج ثلاثية (ternary models) أصغر وأسرع بشكل ملحوظ.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل هاتفًا ذكيًا يحاول فهم محادثة. للقيام بذلك، يجب عليه تشغيل عقل رقمي ضخم، وهو نموذج لغوي، مباشرة على الجهاز. ولكي يعمل هذا بسلاسة، يحتاج الهاتف إلى استخدام معالج خاص فائق السرعة صُمم خصيصًا لهذا النوع من التفكير، بدلًا من عقله الرئيسي العام الأغراض. التحدي يكمكمن في أن هذا المعالج الخاص متطلب؛ فهو لن يشغل إلا أنواعًا معينة من الحسابات، ويرفض تشغيل غيرها، حتى لو كانت تلك الأخرى متطابقة رياضيًا. لسنوات، حاول المطورون تخمين أي الحسابات ستعمل وكيفية جعلها سريعة، معتمدين غالبًا على قواعد تقريبية تبين أنها خاطئة. لقد افترضوا أنه إذا كان النموذج صغيرًا بما يكفي، فسيعمل على المعالج السريع، أو أن تصغير حجم الأرقام سيساعد دائمًا. لكن لم يقم أحد حقًا بمراقبة المعالج ليرى ما يفعله حقًا، أو لقياس كيف يغير حجم النموذج وطريقة تخزين أرقامه من سرعته.
قرر باحث يدعى شاهير م. أ (Shahir M A) التوقف عن التخمين والبدء في المراقبة. باستخدام جهاز كمبيوتر من نوع "أبل" مزود بشريحة "M1"، بنى سلسلة من التجارب ليرى بالضبط ما يحدث عندما يحاول نموذج لغوي العمل على المعالج الخاص بالهاتف، والمعروف باسم "المحرك العصبي" (Neural Engine). لم يكتفِ بالنظر إلى ما يقول البرنامج إنه سيفعله، بل قام بقياس الكهرباء والبيانات الفعلية التي تتحرك عبر الشريحة ليرى ما يحدث حقًا. اختبر عشرات الطرق المختلفة لبناء نفس العملية الرياضية، ودرب نماذج حقيقية بأحجام مختلفة، وغير كيفية تخزين الأرقام داخل هذه النماذج، بدءًا من الدقة القياسية وصولًا إلى التنسيقات المضغوطة للغاية ذات الدقة المنخفضة. كان هدفه بسيطًا: اكتشاف ما الذي يسمح للنموذج فعليًا بالدخول إلى المعالج السريع، ومدى سرعة قدرته على التحدث بمجرد دخوله.
اكتشف أولاً أن المعالج لا يهتم بما يعنيه الحساب، بل يهتم بكيفية كتابته. وجدوا أنه إذا كتبت نوعًا معينًا من "التطبيع" (normalization) — وهي خطوة تساعد النموذج على الحفاظ على استقرار أرقامه — بطريقة واحدة، فإن المعالج يقبله فورًا ويشغله بالسرعة الكاملة. ولكن إذا كتبت الخطوة الرياضية نفسها باستخدام مجموعة مختلفة قليلاً وأكثر تعقيدًا من التعليمات، فإن المعالج يرفض لمسها ويجبر الهاتف على استخدام عقله العام الأبطأ بدلًا من ذلك. الأمر يشبه أن المعالج يتحدث لهجة رياضية محددة؛ إذا استخدمت اللهجة الصحيحة، فإنه يستمع إليك، أما إذا استخدمت لهجة أخرى، حتى لو كان المعنى هو نفسه، فإنه يبتعد. وهذا يعني أن الطريقة التي يكتب بها المطور الكود لا تقل أهمية عن الرياضيات نفسها.
الاكتشاف الثاني، وربما الأكثر إثارة للدهشة، هو أن حجم النموذج ليس الشيء الوحيد الذي يحدد ما إذا كان يمكن تشغيله على المعالج السريع. وجد الباحثون أن نموذجًا يحتوي على حوالي ستة وعشرين مليون معلمة (parameter)، مكتوب بدقة قياسية، كان أصغر من أن يعمل على المعالج الخاص على الإطلاق. فقد أُجبر على العمل على العقل البطيء، مستغرقًا أكثر من ثانية لتوليد كل كلمة. ومع ذلك، عندما أخذوا هذا النموذج نفسه وضغطوا الأرقام بداخله لاستخدام بتات أقل، قبل المعالج فجأة تشغيله. النسخة المضغوطة عملت على المعالج السريع وولدت الكلمات في أقل من ثانية. في الواقع، بالنسبة للنماذج الصغيرة، كان ضغط الأرقام هو الطريقة الوحيدة لإدخالها إلى المعالج السريع. كان لدى المعالج قاعدة خفية: لن يشغل النماذج الصغيرة ما لم تكن مضغوطة. لقد قلب هذا الافتراض الشائع بأن النماذج الكبيرة هي دائمًا التي تحتاج إلى المعالج السريع؛ هنا، كانت النماذج الصغيرة هي التي احتاجت إلى الضغط للدخول من الباب.
بمجرد دخول النموذج إلى المعالج السريع، كانت السرعة تتحدد بالكامل بناءً على كمية البيانات التي يجب نقلها، وليس بمدى تعقيد الرياضيات. قاس الباحثون تدفق البيانات ووجدوا أنه مقابل كل كلمة يولدها النموذج، يتعين عليه بث مجموعة أوزانه بالكامل — وهي الأرقام التي تشكل معرفته — عبر المعالج. حدث هذا مع كل كلمة، بغض النظر عن طول المحادثة. وبسبب ذلك، كانت السرعة مرتبطة مباشرة بعدد البتات الموجودة في تلك الأوزان. النموذج الذي يستخدم أرقامًا مضغوطة ومنخفضة الدقة ينقل بيانات أقل، وبالتالي يكون أسرع بكثير. وجدوا أن نموذجًا يستخدم أرقامًا بنظام "البتين" (two-bit) كان أسرع بنحو ثلاث مرات من النموذج الذي يستخدم الأرقام القياسية، ببساطة لأنه كان يحتاج لنقل بيانات أقل. نوع الرياضيات التي استخدمها النموذج، مثل ما إذا كان يركز أكثر على "الانتباه" (attention) أو على "الالتفاف" (convolution)، لم يؤثر تقريبًا على السرعة بمجرد تشغيله على المعالج. الشيء الوحيد الذي كان يهم هو حجم البيانات التي يتم نقلها.
خلص الباحثون إلى أن أفضل طريقة لبناء نموذج لغوي للهاتف هي البدء بالضغط، وليس بالحجم. فبدلًا من بناء نموذج كبير ثم محاولة تصغيره، يجب اختيار التنسيق الأكثر ضغطًا أولاً، ثم تخصيص ميزانية الذاكرة المتاحة لإضافة المزيد من المعلمات. وجدوا أن نموذجًا يحتوي على خمسة وعشرين مليون معلمة، باستخدام نوع معين من الرياضيات المضغوطة، يمكن أن يتسع في مساحة عشرة ميجابايت فقط ويولد الكلمات في حوالي ستة أعشار الميلي ثانية. كان هذا أصغر بنحو عشر مرات وأسرع بثلاث مرات من النماذج القياسية غير المضغوطة التي يبدأ بها المطورون عادةً. أظهرت الدراسة أن طريق الوصول إلى نموذج لغوي سريع يعمل على الجهاز ليس في جعل النموذج أكبر أو أكثر تعقيدًا، بل في اختيار الطريقة الصحيحة لكتابة الرياضيات والطريقة الصحيحة لتخزين الأرقام. ومن خلال قياس تدفق البيانات الفعلي، أثبتوا أن مفتاح السرعة ليس فقط امتلاك معالج سريع، بل معرفة كيفية تغذيته بدقة.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.