Apple Neural Engine: Architecture, Programming, and Performance
تقدم هذه الورقة بحثاً شاملاً للهندسة العكسية لمحرك أبل العصبي (ANE) عبر أجيال متعددة من الرقائق، حيث تفصل بنيته، وحزمة البرمجيات الخاصة به، وخصائص الأداء من خلال الوصول المباشر من مساحة المستخدم وفك التجميع لتوفير مورد تأسيسي للأبحاث على الأجهزة رغم غياب الوثائق الرسمية.
في العالم الحديث، تمتلئ هواتفنا الذكية وحواسيبنا بأدوات متخصصة مصممة لحل مشكلات محددة بسرعة. وبينما يتولى المعالج المركزي المهام العامة، ويعالج معالج الرسوميات الصور، أصبح هناك مكون ثالث، غالباً ما يكون مخفياً، ضرورياً لتشغيل الذكاء الاصطناعي مباشرة على الجهاز. هذا المكون هو محرك مخصص صُمم لأداء أعداد هائلة من الحسابات الرياضية البسيطة، وتحديداً ضرب وجمع الأرقام، وهو العمل الجوهري للتعرف على وجه في صورة أو ترجمة أمر صوتي. لسنوات، ظل هذا المحرك بمثابة "صندوق أسود"؛ فبينما كان بإمكان مطوري البرامج أن يطلبوا من الكمبيوتر استخدامه، لم يكن لديهم أي وسيلة لرؤية كيف يعمل، أو ما الذي يمكنه فعله حقاً، أو كيفية التحدث إليه مباشرة دون المرور عبر وسيط معقد.
لقد نجح باحث الآن في فتح ذلك الصندوق الأسود. فمن خلال الفحص الدقيق للبرمجيات التي تعمل على أجهزة آبل وقياس العتاد نفسه، قام برسم خريطة للنظام بأكره، بدءاً من رقائق السيليكون الفيزيائية وصولاً إلى التعليمات غير المرئية التي تحركها. ويكشف عمله أن هذا المحرك ليس حاسوباً عام الأغراض، بل هو آلة متخصصة للغاية صُممت للتعامل مع نوع محدد من الرياضيات بسرعة فائقة واستهلاك منخفض للطاقة. وقد اكتشف أنه بينما يتميز المحرك بسرعة مذهلة في مهام معينة، إلا أن لديه حدوداً صارمة فيما يتعلق بما يمكنه حسابه وكيفية تعامله مع الأرقام. هذا الفهم يسمح للمطورين ببناء تطبيقات أفضل تعمل بشكل أسرع وتستهلك بطارية أقل، ولكنه يظهر أيضاً أن المحرك ليس حلاً سحرياً لكل مشكلة؛ بل هو أداة دقيقة ذات وظيفة محددة، ويتطلب استخدامه بشكل صحيح فهم قواعده الفريدة.
بدأ الباحث بتجاوز طبقات البرمجيات القياسية التي عادة ما تخفي المحرك عن المستخدمين. وبدلاً من سؤال تطبيق عالي المستوى ليقرر أين يتم تشغيل المهمة، وجد مساراً مباشراً إلى المحرك نفسه، مما سمح له بإرسال الأوامر وقياس النتائج بضبط كامل. لقد تعامل مع المحرك كآلة مستقلة تستقبل مجموعة من التعليمات، وتنفذها، ثم ترسل إشارة عند انتهائها. ووجد أن المحرك لا يعالج التعليمات واحدة تلو الأخرى مثل الحاسوب القياسي؛ بل ينفذ تسلسلاً مخططاً مسبقاً من عمليات نقل البيانات والحسابات التي يتم تحديدها قبل بدء العمل حتى. وهذا يعني أن المحرك لا يمكنه اتخاذ قرارات بناءً على البيانات التي يعالجها أثناء تشغيله؛ إذ يجب وضع المسار مسبقاً.
يتعلق أحد أهم الاكتشافات بكيفية تعامل المحرك مع الأرقام. فهو يجري حساباته باستخدام تنسيق يسمى "دقة النصف" (half-precision)، والذي يستخدم عدداً أقل من البتات لتخزين الرقم مقارنة بالتنسيق القياسي المستخدم في معظم الحواسب. هذا الخيار يسمح للمحرك بنقل البيانات بشكل أسرع واستخدام طاقة أقل، ولكنه يأتي على حساب الدقة. وقد اكتشف الباحث أن المحرك يعوض ذلك باستخدام "سجل داخلي" واسع جداً للاحتفاظ بالمجموع الجاري لحساباته. يعمل هذا السجل الواسع مثل شبكة أمان، مما يضمن بقاء النتيجة النهائية دقيقة حتى وإن كانت الخطوات الفردية تستخدم أرقاماً أصغر. ومع ذلك، فإن هذا النظام له نقطة انكسار؛ فإذا تضمن الحساب إلغاء رقم موجب كبير برقم سالب كبير لإيجاد فرق ضئيل، يفقد المحرك دقته لأن الفرق الصغير يضيع في عملية تقريب الأرقام الكبيرة الأولية. وفي هذه الحالات المحددة، لا يمكن استخدام المحرك، ويجب نقل المهمة إلى جزء آخر من الكمبيوتر.
رسمت الدراسة أيضاً خريطة توضح العمليات التي يمكن للمحرك القيام بها بدقة. فهو ممتاز في المهام التي تدعم الرؤية والكلام، مثل التعرف على الأشكال في صورة أو معالجة الموجات الصوتية. ويمكنه التعامل مع الأنماط المعقدة مثل "الالتفافات" (convolutions)، وهي العمليات الرياضية المستخدمة للكشف عن الحواف والميزات في الصورة. ومع ذلك، وجد الباحث أن المحرك لا يستطيع فعل كل شيء؛ فبعض أنواع الحسابات، مثل تلك التي تتضمن بيانات ثلاثية الأبعاد أو أنواعاً معينة من تحديثات الذاكرة، لا يدعمها العتاد ببساطة. كما اكتشفوا أن قدرات المحرك تتغير اعتماداً على جيل الشريحة المحدد. فعلى سبيل المثال، يمكن للشرائح القديمة ضغط البيانات بطرق معينة فقط لتوفير المساحة، بينما يمكن للشرائح الأحدث ضغط البيانات بتنسيقات أكثر، مما يسمح لها بنقل المعلومات بشكل أسرع واستخدام طاقة أقل.
أظهرت قياسات الأداء أنه عندما يُستخدم المحرك في النوع الصحيح من العمل، فإنه يكون أسرع وأكثر كفاءة بشكل كبير من معالج الرسوميات، الذي غالباً ما يُستخدم لمهام مماثلة. ففي مهمة محددة لمعالجة الصور، وُجد أن المح_
المشكلة يُعد المحرك العصبي من أبل (ANE) أكثر مسرعات تعلم الآلة انتشاراً، حيث يتواجد في أكثر من 2.5 مليار جهاز نشط من أجهزة أبل منذ معالج A11 (2017) ومعالج M1 (2020). ورغم انتشاره الواسع، إلا أنه يظل المحرك الأكثر غموضاً وقابلية للبرمجة في منظومة رقائق أبل. لا توجد مجموعة تعليمات عامة، ولا واجهة تعريف مشغّل (driver) موثقة، ولا آلية تتيح للبرنامج التحقق مما إذا كانت عملية حسابية قد تمت بالفعل على الـ ANE. تتفاعل التطبيقات مع الـ ANE حصرياً من خلال إطار عمل Core ML، الذي يعمل كمخطط لتوزيع المهام، حيث يقوم بتقسيم النماذج عبر وحدة المعالجة المركزية (CPU)، ووحدة معالجة الرسومات (GPU)، والـ ANE بناءً على نموذج تكلفة غامض. وتحت سطح Core ML، تظل مسارات البيانات، والقيم العددية، ونطاقات الأداء، والمترجم (compiler)، وتنسيق البرامج، ومشغل النواة (kernel driver)، والبرامج الثابتة (firmware) غير موثقة وغير مدعومة. هذا النقص في الرؤية يعيق الأبحاث على الأجهزة، وضبط الأداء، وتطوير أحمال العمل المخصصة التي لا تتناسب مع استراتيجية التوزيع القياسية لـ Core ML.
المنهجية يعتمد هذا العمل نهج هندسة عكسية متكامل (full-stack)، يجمع بين القياس المباشر للسيليكون والتحليل الساكن والديناميكي لمكونات النظام الخاصة.
الوصول المباشر: حدد المؤلف واستخدم مساراً مباشراً للوصول إلى الـ ANE من عملية مستخدم عادية، متجاوزاً مخطط التوزيع الخاص بـ Core ML. يستخدم هذا المسار وقت التشغيل الخاص "Espresso" (e5rt)، والذي يمكن استدعاؤه دون امتيازات خاصة للعمليات المقبولة.
القياس: تم قياس مقاييس الأداء والطاقة مباشرة على رقائق أبل، وتحديداً على رقائق M1 وM5. شمل ذلك تحليل زمن الاستجابة (latency)، والإنتاجية (throughput)، واستهلاك الطاقة باستخدام أدوات داخل الجهاز.
تفكيك الشفرة والتحليل: قام المؤلف بتفكيك وتحليل وقت التشغيل الخاص، والمترجم، ومشغل النواة، والبرامج الثابتة. كما فحص بروتوكول الأوامر، وآليات ترجمة العناوين (DART)، والواجهة بين المضيف (host) والبرامج الثابتة.
التحقق من الصحة: تم تصنيف الادعاءات إلى "مقاسة" (تم رصدها على السيليكون)، أو "مستنتجة من تفكيك الشفرة" (استُنتجت من الملفات الثنائية المفككة)، أو "متوقعة" (استُنتجت من جداول لكل شريحة). تحقق المؤلف من صحة النتائج عبر مطابقة سلوك المترجم مع التنفيذ الفعلي للأجهزة، مؤكداً أن بتات القدرة (capability bits) لا تعني دائماً عمليات يمكن الوصول إليها.
المساهمات الرئيسية يقدم البحث أول وصف تقني شامل ومتكامل للـ ANE، يغطي البنية من مسار البيانات بنظام fp16 وصولاً إلى واجهة النظام.
البنية والقيم العددية:
مسار البيانات: الـ ANE هو مسرع مصفوفات ثابت الوظائف بنظام fp16 مع مجمع (accumulator) واسع (من فئة fp32). وبينما تكون المدخلات والمخرجات بنظام fp16، يتم الاحتفاظ بعملية التجميع في سجل (register) أوسع، مما يحافظ على الدقة لعمليات الالتفاف (convolution) والنمذجة (normalization)، ولكنه يفشل في الخطوات التي تشهد عمليات إلغاء (cancellation-heavy) مثل عمليات الإسقاط السفلي في نماذج Transformer بسبب تقريب المدخلات.
نموذج التنفيذ: يعمل المحرك كمعالج مساعد مستقل. يتم تجميع الشبكة مرة واحدة في رسم بياني ثابت ("البرنامج") ويتم إرساله عدة مرات. تدفق التحكم ثابت عند وقت التجميع؛ ولا يتم دعم التفرع المعتمد على البيانات.
إدارة الحالة: يدعم المحرك الحالة المستقرة (resident state) عبر عمليات الإرسال المتعددة عبر محاكاة التخصيص (buffer aliasing)، حيث يصبح مخرج خطوة ما هو مدخل الخطوة التالية، مما يتيح فك التشفير التوليدي (autoregressive decoding) وحلقات التدريب بكفاءة دون الحاجة لرحلات ذهاب وإياب للمضيف لنقل تانسرات الحالة.
البرمجة وأدوات التطوير:
المسار المباشر: يفصل المؤلف "المسار المباشر" باستخدام وقت تشغيل Espresso (e5rt)، والذي يسمح للمطورين بتجميع وتحميل وإرسال الرسوم البيانية مباشرة إلى الـ ANE دون الحاجة لمقسم Core ML.
المترجم والتنسيق: فك المترجم لغة الـ backend الخاصة به (anec.*)، واللغة الوسيطة، وتنسيق البرنامج على القرص. البرنامج المجمع عبارة عن حاوية بتنسيق Mach-O (الرمز السحري 0xbeefface) تحتوي على تدفق كتابة السجلات وبنوك الأوزان، مغلفة بوصف إرسال من نوع FlatBuffer.
ضغط الأوزان: يحلل البحث أربعة أشكال للضغط (int4 palette، وint8 affine، وstructured sparsity، وblockwise affine). ويكشف أن سلوك التدفق (فك الضغط على الشريحة مقابل الدمج في fp16 كثيف في ذاكرة DRAM) يختلف باختلاف أجيال الرقائق. فعلى سبيل المثال، في رقاقة M1، يتم تدفق int4 وstructured sparsity بشكل طبيعي فقط، بينما يتم دمج int8، مما يلغي مكاسب عرض النطاق الترددي.
الأداء والكفاءة:
نموذج Roofline: وضع المؤلف نموذج Roofline للـ ANE. في رقاقة M1، يبلغ سقف الحوسبة حوالي 12 ترافلوب (TFLOP/s) بنظام fp16، وهو مقيد بعرض نطاق تردد DRAM يبلغ حوالي 85 جيجابايت/ثانية. نقطة الذروة (الشد الحسابي) هي حوالي 141 FLOP/byte.
الكفاءة: الـ ANE أكثر كفاءة بكثير من وحدة معالجة الرسومات (GPU) في أحمال العمل المرتبطة بالحوسبة. في عملية التواء (convolution) بـ 256 قناة و3x3، يعد الـ ANE أسرع بـ 3.8 مرة وأكثر كفاءة في استهلاك الطاقة بـ 9 مرات من الـ GPU.
زمن الاستجابة: يتسبب الإرسال الواحد في تأخير ملحوء (حوالي 190 ميكروثانية في M1)، حيث يعود 98% منه إلى برمجيات/برامج ثابتة (software/firmware) بدلاً من الحوسبة الفعلية.
سطح القدرات والقيود:
إمكانية الوصول: يميز البحث بين القدرات "المعلنة" (بتات الأجهزة) والعمليات "الممكنة" (التي تنجح في عملية التنزيل والتشغيل). على سبيل المثال، عملية الالتفاف ثلاثي الأبعاد (3D convolution) معلنة ولكنها تفشل في عملية التنزيل الخلفي (lowering) على جميع الأجهزة. ز الامتيازات: رغم أن المسار المباشر لا يتطلب امتيازات خاصة للعمليات القياسية، إلا أنه محكوم بفحص توقيع على مستوى النواة. لا يمكن تحميل البرامج المكتوبة يدوياً؛ إذ يجب على نظام التشغيل (daemon) تجميع وتوقيع البرنامج.
الميزات المقيدة: الميزات مثل الأنواع الحالة الأصلية (ring buffers)، ومدخلات bf16، والأشكال الرمزية المرنة، إما أنها غائبة في M1 أو تتطلب مسار الإطار الرسمي المعتمد، مما يضيف عبئاً إضافياً.
النتائج
الأداء: يحقق الـ ANE كفاءة قصوى تقترب من 0.37 بيكوجول لكل FLOP عند ذروة الحوسبة. إنه يتفوق على الـ GPU في عمليات الالتفاف وضرب المصفوفات المجمعة (أقل من N=2048)، ولكنه أبطأ في عمليات فك التشفيد التوليدي المرتبطة بعرض النطاق الترددي.
السلوك العددي: يضمن المجمع الواسع (wide accumulator) أن المجاميع القابلة للتمثيل (مثل 16,000 واحد) تكون دقيقة تماماً، بينما تفشل عمليات الجمع التقليدية بنظام fp16. ومع ذلك، فإن العمليات التي تشهد إلغاءً كبيراً (cancellation-heavy) تفقد الدقة بسبب تقريب مدخلات fp16.
الضغط: يوفر البحث أن جداول البحث (lookup tables) بنظام int4 تسريع سرعة الطبقات المرتبطة بعرض النطاق الترددي بمقدار 2.37 ضعفاً مقارنة بـ fp16، بينما يوفر structured sparsity تسريعاً بمقدار 1.55–1.64 ضعفاً. أما دمج int8 في M1 فيوفر مساحة التخزين لكنه لا يوفر ميزة في عرض النطاق الترددي.
الأنظمة الداخلية: فك المؤلف بروتوكول الأوامر (93 أمراً)، وهيكل البرامج الثابتة (نظام التشغيل الفوري Styx RTOS)، وآلية ترجمة العناوين، مما كشف عن كيفية ربط المضيف للمخازن المؤقتة (buffers) بالفضاء الافتراضي للمحرك.
الأهمية يدعي البحث أنه يقدم أول "سطح وصول" (reachable surface) للـ ANE، متجاوزاً إطار عمل Core ML الغامض ليكشف عن قدرات المحرك وحدوده الفعلية. من خلال توثيق المسار المباشر، يُمكّن المؤلف من إجراء الأبحاث والقياسات على الأجهزة والتي كانت مستحيلة سابقاً. يصحح العمل المفاهيم الخاطئة حول قدرات المحرك (مثل عدم وجود مسارات للالتفاف ثلاثي الأبعاد) ويوفر أساساً صارماً لتحسين النماذج لرقائق أبل. ويؤكد المؤلف أنه بينما يعد المسار المباشر قوياً للأبحاث، إلا أنه غير موثق وغير مدعوم وهش عبر تحديثات نظام التشغيل، ويظل Core ML هو المسار الوحيد المدعوم للبرمجيات التجارية. تعمل هذه النتائج كمرجع لفهم المقايضات بين الحوسبة، وعرض النطاق الترددي للذاكرة، وكفاءة الطاقة في وحدات المعالجة العصبية (NPUs) الحديثة.