قدمت جوجل واجهة برمجة التطبيقات LiteRT Tensor API، وهي واجهة C++ خفيفة الوزن تتيح للمطورين بناء نماذج التعلم الآلي وتخصيصها وتحسينها مباشرة للتنفيذ على الأجهزة. وبحسب جوجل، فإنها تجمع بين مرونة تأليف النماذج الأصلية وقابلية النقل عبر الأنظمة الأساسية.
ما هي التحديات التي تعالجها LiteRT Tensor API؟
النهج التقليدي، بحسب جوجل، هو أن يكتب المطورون العمليات الحسابية يدويًا بلغة C++ للتحكم الأقصى، وهو ما يأتي مع عيب كبير: تكون التطبيقات مرتبطة ارتباطًا وثيقًا بخلفيات محددة (مثل Metal أو OpenCL أو Vulkan) ويجب إعادة كتابتها لكل هدف أجهزة جديد. علاوة على ذلك، فإن إدارة قابلية التشغيل البيني للمخازن المؤقتة بدون نسخ والمزامنة عبر وحدات المعالجة المركزية (CPU) ووحدات معالجة الرسوميات (GPU) ووحدات المعالجة العصبية (NPU)، مع ربط المعالجة المسبقة والاستدلال والمعالجة اللاحقة، يتطلب جهدًا هندسيًا يدويًا كبيرًا.
تهدف واجهة برمجة التطبيقات LiteRT Tensor API إلى معالجة هذه التحديات من خلال السماح للمطورين ببناء رسوم بيانية حسابية عملية تلو الأخرى بلغة C++. يوفر هذا تحكمًا أكبر في بنية النموذج وتحسينه وتنفيذ المسرّع، مع تمكين نفس الرسوم البيانية من التشغيل عبر LiteRT على أجهزة CPU و GPU و NPU دون الحاجة إلى إعادة كتابة لكل هدف جديد.
بالإضافة إلى توفير التحكم الكامل في رسوم بيانية النماذج، تشمل القدرات الرئيسية الأخرى لواجهة برمجة التطبيقات إدخال الأوزان مباشرة، مما يسمح للمطورين بتحميل الأوزان مباشرة من نقاط التفتيش، بما في ذلك ملفات Hugging Face .safetensors؛ وقابلية التشغيل البيني للمخازن المؤقتة بدون نسخ، والتي تتجنب نسخ مخازن المسرّع المؤقتة عبر المعالجة المسبقة والاستدلال والمعالجة اللاحقة؛ والتوافق مع وكلاء برمجة الذكاء الاصطناعي، الذين يمكنهم بناء وتعديل والتحقق من صحة واختبار رسوم بيانية النماذج عن طريق توليد كود C++.
وقد كان التطبيق أيضًا أساسًا لاختبار الأداء عبر الأنظمة الأساسية. وبحسب جوجل، "لقد قمنا بتشغيل نفس كود C++ لنموذج SAM 2 على وحدات معالجة الرسوميات لثلاثة أجهزة: حاسوب محمول يعمل بنظام macOS (Metal)، وهاتف iOS (Metal)، وهاتف Android (OpenCL). في اختباراتنا على جهاز MacBook Pro، عمل أسرع بحوالي 1.5 مرة من Apple MLX (fp16، مشفر الصور بالإضافة إلى مفكك القناع)."
أكدت جوجل أن وكيل البرمجة تمكن من إجراء عدد من التحسينات بفضل تعريف الرسم البياني للنموذج بلغة C++ العادية. على وجه التحديد، "نقل قرارات SAM 2 لكل إطار، مثل ما إذا كان الكائن لا يزال مرئيًا، من كود وحدة المعالجة المركزية إلى الرسم البياني" وأعاد كتابة العمليات التي أدت إلى تراجع وحدة المعالجة المركزية على WebGPU باستخدام عمليات حسابية متوافقة مع وحدة معالجة الرسوميات.
في تعليق على الإعلان على LinkedIn، أكد مدير الذكاء الاصطناعي في Arm، لورانس موروني، أنه يجب على المطورين دائمًا البدء بتحويل النموذج واللجوء إلى واجهة برمجة تطبيقات C++ فقط 'عندما تحتاج إلى تحكم على مستوى الرسم البياني أو تريد أن تبقى المعالجة المسبقة واللاحقة على المسرّع'.
ما هي التحسينات المستقبلية المخطط لها؟
تعمل جوجل أيضًا على العديد من التحسينات المخطط لها، بما في ذلك الدعم المباشر لخلفية ML Drift، وعمليات إضافية صديقة لوحدات المعالجة العصبية (NPU)، وتكميم الرسم البياني الكامل التلقائي، والشكل الديناميكي الموسع لأحجام الصور المختلفة، وأحجام الدفعات، وأطوال التسلسل.
