نمایندگان با استفاده از شتابدهندههای روی دستگاه مانند GPU و پردازنده سیگنال دیجیتال (DSP)، شتاب سختافزاری مدلهای LiteRT را فعال میکنند.
به طور پیشفرض، LiteRT از هستههای CPU که برای مجموعه دستورالعملهای ARM Neon بهینه شدهاند، استفاده میکند. با این حال، CPU یک پردازنده چند منظوره است که لزوماً برای محاسبات سنگین که معمولاً در مدلهای یادگیری ماشینی یافت میشود (به عنوان مثال، ریاضیات ماتریسی درگیر در کانولوشن و لایههای متراکم) بهینه نشده است.
از سوی دیگر، اکثر تلفنهای همراه مدرن حاوی تراشههایی هستند که در مدیریت این عملیات سنگین بهتر عمل میکنند. استفاده از آنها برای عملیات شبکه عصبی مزایای زیادی از نظر تأخیر و بهرهوری انرژی دارد. به عنوان مثال، پردازندههای گرافیکی (GPU) میتوانند تا 5 برابر سرعت تأخیر را افزایش دهند.
هر یک از این شتابدهندهها دارای APIهای مرتبطی هستند که محاسبات سفارشی مانند OpenCL یا OpenGL ES را برای پردازنده گرافیکی موبایل امکانپذیر میکنند. معمولاً برای اجرای یک شبکه عصبی از طریق این رابطها، باید کدهای سفارشی زیادی بنویسید. وقتی در نظر بگیرید که هر شتابدهنده مزایا و معایب خود را دارد و نمیتواند هر عملیاتی را در یک شبکه عصبی اجرا کند، اوضاع پیچیدهتر میشود. API نماینده TensorFlow Lite با عمل کردن به عنوان پلی بین زمان اجرای TFLite و این APIهای سطح پایینتر، این مشکل را حل میکند.
انتخاب نماینده
LiteRT از چندین delegate پشتیبانی میکند که هر کدام برای پلتفرم(های) خاص و انواع خاصی از مدلها بهینه شدهاند. معمولاً بسته به دو معیار اصلی، چندین delegate برای مورد استفاده شما قابل استفاده خواهند بود: پلتفرم (اندروید یا iOS؟) مورد نظر شما، و نوع مدل (ممیز شناور یا کوانتیزه؟) که سعی در شتابدهی آن دارید.
نمایندگان بر اساس پلتفرم
کراس پلتفرم (اندروید و iOS)
- نماینده GPU - نماینده GPU میتواند هم در اندروید و هم در iOS استفاده شود. این نماینده برای اجرای مدلهای مبتنی بر اعشار ۳۲ بیتی و ۱۶ بیتی در صورت وجود GPU بهینه شده است. همچنین از مدلهای کوانتیزه ۸ بیتی پشتیبانی میکند و عملکرد GPU را در حد نسخههای اعشاری آنها ارائه میدهد. برای جزئیات بیشتر در مورد نماینده GPU، به LiteRT در مورد GPU مراجعه کنید.
آیاواس
- نماینده Core ML برای آیفونها و آیپدهای جدیدتر - برای آیفونها و آیپدهای جدیدتر که موتور عصبی (Neural Engine) در آنها موجود است، میتوانید از نماینده Core ML برای تسریع استنتاج برای مدلهای ممیز شناور ۳۲ بیتی یا ۱۶ بیتی استفاده کنید. موتور عصبی (Neural Engine) در دستگاههای تلفن همراه اپل با پردازنده A12 SoC یا بالاتر موجود است. برای مرور کلی نماینده Core ML و دستورالعملهای گام به گام، به LiteRT Core ML delegate مراجعه کنید.
نمایندگان بر اساس نوع مدل
هر شتابدهنده با در نظر گرفتن پهنای بیت مشخصی از دادهها طراحی شده است. اگر یک مدل ممیز شناور را به نمایندهای ارائه دهید که فقط از عملیات کوانتیزه ۸ بیتی پشتیبانی میکند، تمام عملیات آن را رد میکند و مدل کاملاً روی CPU اجرا میشود. برای جلوگیری از چنین غافلگیریهایی، جدول زیر مروری بر پشتیبانی نماینده بر اساس نوع مدل ارائه میدهد:
| نوع مدل | پردازنده گرافیکی | کور ام ال |
|---|---|---|
| ممیز شناور (۳۲ بیتی) | بله | بله |
| کوانتیزاسیون float16 پس از آموزش | بله | بله |
| کوانتیزاسیون محدوده دینامیکی پس از آموزش | بله | خیر |
| کوانتیزاسیون عدد صحیح پس از آموزش | بله | خیر |
| آموزش آگاه از کوانتیزاسیون | بله | خیر |
اعتبارسنجی عملکرد
اطلاعات موجود در این بخش به عنوان یک راهنمای تقریبی برای فهرست کردن نمایندگانی که میتوانند برنامه شما را بهبود بخشند، عمل میکند. با این حال، توجه به این نکته مهم است که هر نماینده مجموعهای از عملیات از پیش تعریف شده را پشتیبانی میکند و ممکن است بسته به مدل و دستگاه، عملکرد متفاوتی داشته باشد. بنابراین، معمولاً توصیه میشود که برای سنجش میزان مفید بودن یک نماینده برای نیازهای خود، برخی از معیارهای سنجش را انجام دهید. این امر همچنین به توجیه افزایش اندازه باینری مرتبط با اتصال یک نماینده به زمان اجرای LiteRT کمک میکند.
LiteRT ابزارهای گستردهای برای ارزیابی عملکرد و دقت دارد که میتواند توسعهدهندگان را قادر سازد تا با اطمینان خاطر از delegateها در برنامههای خود استفاده کنند. این ابزارها در بخش بعدی مورد بحث قرار خواهند گرفت.
ابزارهای ارزیابی
تأخیر و میزان حافظه اشغال شده
ابزار بنچمارک LiteRT را میتوان با پارامترهای مناسب برای تخمین عملکرد مدل، از جمله میانگین تأخیر استنتاج، سربار مقداردهی اولیه، ردپای حافظه و غیره، استفاده کرد. این ابزار از چندین پرچم پشتیبانی میکند تا بهترین پیکربندی نماینده را برای مدل شما تعیین کند. به عنوان مثال، --gpu_backend=gl را میتوان با --use_gpu برای اندازهگیری اجرای GPU با OpenGL مشخص کرد. لیست کامل پارامترهای نماینده پشتیبانی شده در مستندات دقیق تعریف شده است.
در اینجا مثالی برای اجرای یک مدل کوانتیزه شده با GPU از طریق adb آورده شده است:
adb shell /data/local/tmp/benchmark_model \
--graph=/data/local/tmp/mobilenet_v1_224_quant.tflite \
--use_gpu=true
شما میتوانید نسخه از پیش ساخته شده این ابزار را برای اندروید، معماری ARM 64 بیتی از اینجا دانلود کنید ( جزئیات بیشتر ).
دقت و صحت
معمولاً Delegates محاسبات را با دقتی متفاوت از همتایان CPU خود انجام میدهند. در نتیجه، یک بدهبستان (معمولاً جزئی) در دقت با استفاده از یک Delegate برای شتابدهی سختافزاری مرتبط است. توجه داشته باشید که این همیشه درست نیست. برای مثال، از آنجایی که GPU از دقت اعشاری برای اجرای مدلهای کوانتیزه استفاده میکند، ممکن است بهبود دقت کمی وجود داشته باشد (برای مثال، بهبود کمتر از ۱٪ در ۵ مورد برتر در طبقهبندی تصویر ILSVRC).
LiteRT دو نوع ابزار برای اندازهگیری میزان دقت رفتار یک نماینده برای یک مدل مشخص دارد: مبتنی بر وظیفه و بدون وابستگی به وظیفه . تمام ابزارهای شرح داده شده در این بخش از پارامترهای پیشرفته واگذاری که توسط ابزار بنچمارک از بخش قبلی استفاده میشود، پشتیبانی میکنند. توجه داشته باشید که زیربخشهای زیر بر ارزیابی نماینده (آیا نماینده مانند CPU عمل میکند؟) تمرکز دارند، نه ارزیابی مدل (آیا خود مدل برای وظیفه مناسب است؟).
ارزیابی مبتنی بر وظیفه
LiteRT ابزارهایی برای ارزیابی صحت در دو وظیفه مبتنی بر تصویر دارد:
ILSVRC 2012 (طبقهبندی تصویر) با دقت top-K
تشخیص شیء COCO (با جعبههای محصورکننده) با دقت میانگین (mAP)
فایلهای باینری از پیش ساخته شده این ابزارها (اندروید، معماری ARM 64 بیتی) به همراه مستندات را میتوانید در اینجا بیابید:
مثال زیر ارزیابی طبقهبندی تصویر با GPU در Pixel 4 را نشان میدهد:
adb shell /data/local/tmp/run_eval \
--model_file=/data/local/tmp/mobilenet_quant_v1_224.tflite \
--ground_truth_images_path=/data/local/tmp/ilsvrc_images \
--ground_truth_labels=/data/local/tmp/ilsvrc_validation_labels.txt \
--model_output_labels=/data/local/tmp/model_output_labels.txt \
--output_file_path=/data/local/tmp/accuracy_output.txt \
--num_images=0 # Run on all images. \
--use_gpu=true
خروجی مورد انتظار، فهرستی از معیارهای برتر از ۱ تا ۱۰ است:
Top-1 Accuracy: 0.733333
Top-2 Accuracy: 0.826667
Top-3 Accuracy: 0.856667
Top-4 Accuracy: 0.87
Top-5 Accuracy: 0.89
Top-6 Accuracy: 0.903333
Top-7 Accuracy: 0.906667
Top-8 Accuracy: 0.913333
Top-9 Accuracy: 0.92
Top-10 Accuracy: 0.923333
ارزیابی بدون توجه به وظیفه
برای کارهایی که ابزار ارزیابی روی دستگاه وجود ندارد، یا اگر در حال آزمایش مدلهای سفارشی هستید، LiteRT ابزار Inference Diff را دارد. (اندروید، معماری دودویی ARM 64 بیتی دودویی اینجا )
Inference Diff اجرای LiteRT را (از نظر تأخیر و انحراف مقدار خروجی) در دو حالت مقایسه میکند:
- استنتاج تکرشتهای پردازنده
- استنتاج تعریفشده توسط کاربر - تعریفشده توسط این پارامترها
برای انجام این کار، این ابزار دادههای تصادفی گاوسی تولید میکند و آن را از دو مفسر TFLite عبور میدهد - یکی هستههای CPU تکرشتهای را اجرا میکند و دیگری توسط آرگومانهای کاربر پارامتردهی میشود.
این روش، تأخیر هر دو و همچنین تفاوت مطلق بین تانسورهای خروجی از هر مفسر را بر اساس هر عنصر اندازهگیری میکند.
برای مدلی با یک تانسور خروجی واحد، خروجی ممکن است به شکل زیر باشد:
Num evaluation runs: 50
Reference run latency: avg=84364.2(us), std_dev=12525(us)
Test run latency: avg=7281.64(us), std_dev=2089(us)
OutputDiff[0]: avg_error=1.96277e-05, std_dev=6.95767e-06
این یعنی برای تانسور خروجی با اندیس 0 ، عناصر خروجی CPU به طور متوسط 1.96e-05 با خروجی delegate متفاوت هستند.
توجه داشته باشید که تفسیر این اعداد نیاز به دانش عمیقتری از مدل و اینکه هر تانسور خروجی چه چیزی را نشان میدهد، دارد. اگر یک رگرسیون ساده باشد که نوعی امتیاز یا جاسازی را تعیین میکند، تفاوت باید کم باشد (در غیر این صورت، خطایی در delegate وجود دارد). با این حال، تفسیر خروجیهایی مانند خروجی «کلاس تشخیص» از مدلهای SSD کمی دشوارتر است. برای مثال، ممکن است با استفاده از این ابزار تفاوتی نشان داده شود، اما این ممکن است به معنای وجود مشکلی در delegate نباشد: دو کلاس (جعلی) را در نظر بگیرید: "TV (ID: 10)" و "Monitor (ID: 20)" - اگر یک delegate کمی از حقیقت طلایی دور باشد و monitor را به جای TV نشان دهد، تفاوت خروجی برای این تانسور ممکن است چیزی به بزرگی 20-10 = 10 باشد.