مجموعه تست شتاب‌دهنده LiteRT (ATS)

مجموعه تست شتاب‌دهنده LiteRT (ATS) ابزاری جامع است که برای اعتبارسنجی صحت عملکرد و اندازه‌گیری عملکرد پیاده‌سازی‌های شتاب‌دهنده سفارشی یکپارچه با چارچوب LiteRT استفاده می‌شود.

مرور کلی و قابلیت‌های اصلی

وظیفه اصلی ATS اجرای مدل‌های یادگیری ماشین از پیش تعریف‌شده در برابر یک شتاب‌دهنده هدف و مقایسه نتایج با پردازنده استاندارد LiteRT است.

• اعتبارسنجی: این مجموعه با مقایسه تانسورهای خروجی (فعال‌سازی‌ها) تولید شده توسط شتاب‌دهنده در برابر تانسورهای تولید شده توسط CPU backend که عملکرد خوبی دارد ، اعتبارسنجی عددی را انجام می‌دهد. این امر تضمین می‌کند که پیاده‌سازی شتاب‌دهنده دقت و صحت لازم را حفظ می‌کند.
• معیارهای عملکرد: این ابزار به طور خودکار جزئیات مهم عملکرد، از جمله تأخیر و سایر معیارهای مرتبط را ثبت و ضبط می‌کند و در اختیار کاربر قرار می‌دهد.
• اجرا: تست‌ها معمولاً روی یک دستگاه هدف (مثلاً یک تلفن اندروید) اجرا می‌شوند و توسط یک بسته‌بندی اسکریپت پوسته مدیریت می‌شوند که انتقال فایل‌ها و راه‌اندازی را با استفاده از ابزار adb (پل اشکال‌زدایی اندروید) مدیریت می‌کند.

داده‌های آزمایشی (مدل‌ها)

مجموعه ATS از مجموعه‌ای از مدل‌های .tflite که به‌طور گسترده استفاده می‌شوند، به‌عنوان داده‌های آزمایشی خود استفاده می‌کند. داده‌های ورودی به‌طور تصادفی بر اساس نوع داده تولید می‌شوند و می‌توانند در صورت نیاز، بارگذاری شوند.

مدل‌های موجود

مدل‌های زیر به طور خودکار برای آزمایش (در صورت تغییر) گنجانده و دانلود می‌شوند:

• hf_all_minilm_l6_v2
• hf_mobilevit_small
• qai_hub_midas
• qai_hub_real_esrgan_x4plus
• torchvision_mobilenet_v2
• torchvision_resnet18
• torchvision_squeezenet1_1
• u2net_lite
• whisper_tiny_decoder
• whisper_tiny_encoder
• yamnet
• yolo11n

بازیابی مدل دستی

در حالی که مدل‌ها به طور خودکار در طول bazel run دانلود می‌شوند، می‌توانید کل مجموعه مدل را با استفاده از wget به صورت دستی بازیابی کنید:

wget -p -O <target_file> https://storage.googleapis.com/litert/ats_models.tar.gz

تعریف یک مجموعه ATS با Bazel

از ماکروی litert_define_ats Bazel برای پیکربندی و تعریف یک هدف تست ATS مختص شتاب‌دهنده خود استفاده کنید.

ماکرو به طور خودکار دو هدف قابل اجرا ایجاد می‌کند:

1. تست استاندارد JIT روی دستگاه (برای اجرا و اعتبارسنجی).
2. یک تست حالت «فقط کامپایل» AOT اختصاصی (برای کامپایل میزبان).

مثال litert_define_ats کاربرد

این مثال یک مجموعه ATS با نام example_ats برای یک شتاب‌دهنده با نام backend example تعریف می‌کند:

# Emits aot-mode and jit-mode test targets, one for running compilation test on host
# and another for running JIT and inference on device
# These targets are named with their respective suffix attribute.
litert_define_ats(
    name = "example_ats",
    backend = "example",
    compile_only_suffix = "_aot",
    do_register = [
        "*mobilenet*",
    ],
    extra_flags = ["--limit=1"],
    jit_suffix = "",
)

اعدام

برای اجرای تست استاندارد مورد نظر برای اندروید (که تمام عملیات adb را مدیریت می‌کند):

# Handles environment setup, and build + push of library and data dependencies to the device,
# executes the suite on the target.
bazel run -c opt --config=android_arm64 :example_ats

برای اجرای تست کامپایل AOT:

# Handle environment setup, and builds library dependencies for host platform.
# Executes the ats compile only flow. The "--compile_mode" flag is already
# bound to the program arguments.
bazel run :example_ats_aot

اجرای لینوکس (میزبان)

برای اجرای لینوکس، که در آن ATS روی همان دستگاهی که ساخت را انجام می‌دهد اجرا می‌شود، کاربران باید مستقیماً از فایل باینری :ats استفاده کنند:

bazel run -c opt :ats

اجرای اینترنت اشیا

برای اجرای IoT، کاربران باید فایل باینری را روی میزبان بسازند و به صورت دستی آن را به دستگاه خود ارسال کنند.

پرچم‌های خط فرمان

فایل اجرایی ats چندین پرچم (flag) را برای کنترل جزئی‌تر بر روی تست و گزارش‌گیری می‌پذیرد.

استفاده از ابزارهای ساخت litert_device_script برای ATS

The ATS targets users execute automatically include a shell entry point which handles all of the environment setup, and any pushing of required libraries when the target device differs from the host on which the build was completed (eg adb push ).

این قابلیت به طور کلی از طریق ابزارهای litert_device_script که ATS buildها در پشت صحنه از آنها استفاده می‌کنند، ارائه می‌شود. شتاب‌دهنده‌ها برای دسترسی به این قابلیت build باید یک فرآیند ثبت‌نام انجام دهند. این ابزارها علاوه بر پشتیبانی ats ، می‌توانند به صورت مستقل برای شبیه‌سازی cc_binary و cc_test که قرار است روی دستگاهی متفاوت از میزبان build که نیاز به وابستگی‌های push شده دارد، اجرا شوند، استفاده شوند.

ثبت نام در بخش مدیریت

برای فعال کردن یک شتاب‌دهنده جدید برای استفاده با litert_device_script (و بنابراین ATS)، کتابخانه‌های مورد نیاز آن باید در فایل Bazel به نام litert_device_common.bzl ثبت شوند. ثبت بر اساس یک نام "backend" منحصر به فرد انجام می‌شود که به مجموعه‌ای از کتابخانه‌های قابل ساخت یا از پیش کامپایل شده مورد نیاز برای LiteRT جهت کار با آن شتاب‌دهنده نگاشت می‌شود.

مراحل ثبت نام

1. تعریف یک تابع BackendSpec : تابعی ایجاد کنید که یک دیکشنری حاوی مشخصات شتاب‌دهنده جدید شما را برمی‌گرداند.

2. مشخص کردن کتابخانه‌ها ( libs ): این لیستی از تاپل‌ها است که مسیر هدف Bazel را برای کتابخانه مشترک و متغیر محیطی ( LD_LIBRARY_PATH ) مورد نیاز برای یافتن آن توسط اتصال‌دهنده دستگاه، شرح می‌دهد.

   • کتابخانه‌ی اعزام (Dispatch Library): برای اجرای زمان اجرا (runtime) مورد نیاز است.
   • کتابخانه افزونه کامپایلر: برای حالت کامپایل AOT مورد نیاز است.

3. نام‌های کتابخانه ( plugin ، dispatch ) را مشخص کنید: نام فایل‌های کتابخانه‌های افزونه و dispatch را ارائه دهید.

4. ثبت مشخصات: تابع مشخصات جدید خود را در تابع اصلی _Specs ادغام کنید تا با شناسه منحصر به فرد backend خود در دسترس باشد.

مثال ثبت نام ( _ExampleSpec )

کد زیر از litert_device_common.bzl نحوه ثبت شتاب‌دهنده "example" را نشان می‌دهد:

def _ExampleSpec():
    return {
        # The unique backend ID
        "example": BackendSpec(
            id = "example",
            libs = [
                # Dispatch Library and how to find it on device
                ("//third_party/odml/litert/litert/vendors/examples:libLiteRtDispatch_Example.so", "LD_LIBRARY_PATH"),
                # Compiler Plugin Library
                ("//third_party/odml/litert/litert/vendors/examples:libLiteRtCompilerPlugin_Example.so", "LD_LIBRARY_PATH"),
            ],
            plugin = "libLiteRtCompilerPlugin_Example.so",
            dispatch = "libLiteRtDispatch_Example.so",
        ),
    }

# ... (Other specs are defined here)

def _Specs(name):
    # Your new spec function must be included here
    return (_QualcommSpec() | _GoogleTensorSpec() | _MediatekSpec() | _CpuSpec() | _GpuSpec() | _ExampleSpec())[name]

استفاده از ثبت نام با litert_device_exec

پس از ثبت، از litert_device_exec و ماکروهای مرتبط با backend_id جدید استفاده کنید. این ماکرو به طور خودکار کتابخانه‌های مورد نیاز و هر فایل داده مشخص شده را با فایل باینری هدف همراه می‌کند.

cc_binary(
    name = "example_bin",
    srcs = ["example_bin.cc"],
)

litert_device_exec(
    name = "example_bin_device",
    backend_id = "example",  # Uses the libraries registered under "example"
    data = [
        "//third_party/odml/litert/litert/test:testdata/constant_output_tensor.tflite",
    ],
    target = ":example_bin",
)

اجرای این هدف ( bazel run ... :example_bin_device ) باعث خواهد شد:

1. فایل باینری example_bin ++C را بسازید.
2. فایل‌های باینری libLiteRtDispatch_Example.so ، libLiteRtCompilerPlugin_Example.so و فایل .tflite را به دستگاه ارسال کنید.
3. فایل باینری را با استفاده از adb shell اجرا کنید.

نکته‌ای در مورد مسیرهای دستگاه: مکان استاندارد برای فایل‌ها روی دستگاه، درخت اجرایی Bazel، به طور خاص /data/local/tmp/runfiles/runfiles_relative_path را منعکس می‌کند. اسکریپت دستگاه به طور خودکار تنظیم مسیرهای مناسب برای پیونددهنده پویا را مدیریت می‌کند.

حالت کامپایل (AOT)

برای شتاب‌دهنده‌هایی که از مرحله کامپایل Ahead-of-Time (AOT) پشتیبانی می‌کنند، ATS می‌تواند در یک «حالت کامپایل» اختصاصی اجرا شود.

• هدف: این حالت برای اجرا روی یک ایستگاه کاری (ماشین میزبان) طراحی شده است، نه روی دستگاه هدف. این حالت مدل‌ها را برای سخت‌افزار هدف مشخص‌شده، بدون اجرای آنها، کامپایل می‌کند.
• خروجی: تمام مدل‌های کامپایل شده به یک دایرکتوری تعیین شده در ایستگاه کاری خروجی داده می‌شوند.
• فعال‌سازی: ماکروهای ساخت ATS یک هدف خاص برای aot منتشر می‌کنند که در آن کتابخانه‌ها برای پلتفرم میزبان ساخته می‌شوند. این جریان را می‌توان در هر باینری با پرچم --compile_mode فعال کرد، اما به طور خودکار به آرگومان‌های ساخت aot محدود می‌شود.

توسعه‌های آینده

قرار است این مجموعه علاوه بر مدل‌های کامل، شامل تست‌های اختصاصی برای عملیات‌های تکی (ops) نیز بشود.