هوش مصنوعی روی میکروکنترلر فقط کوچککردن فایل مدل نیست. در یک دستگاه Edge AI، حافظهٔ کاری، پشتیبانی نرمافزار از عملگرها، زمان پاسخ و بودجهٔ انرژی همزمان تعیین میکنند که مدل واقعاً روی برد اجرا شود یا نه. این راهنما مسیر انتخاب سختافزار و آمادهسازی مدل را از اندازهگیری نیازها تا آزمون روی PCB توضیح میدهد.
Edge AI چه زمانی انتخاب مناسبی است؟
در Edge AI، استنباط مدل نزدیک حسگر و روی خود دستگاه انجام میشود. این معماری میتواند زمان رفتوبرگشت شبکه و ارسال دادهٔ خام را کم کند و در قطع اینترنت هم کار کند؛ اما اجرای محلی بهخودیخود امنیت داده را تضمین نمیکند و محدودیت توان، گرما و نگهداری مدل را به دستگاه منتقل میکند. برای تشخیص لرزش موتور، طبقهبندی صدای کوتاه یا شناسایی ناهنجاری حسگر، میکروکنترلر کممصرف ممکن است کافی باشد. برای تصویر بزرگ یا مدل زبانی، شاید SoC مجهز به NPU و حافظهٔ بیشتر لازم شود.
پیش از انتخاب MCU یا NPU، سه نوع حافظه را جدا کنید
اندازهٔ فایل مدل در Flash فقط بخشی از مسئله است. وزنها معمولاً در Flash یا حافظهٔ خارجی نگهداری میشوند، اما activationهای لایهها، بافرهای ورودی/خروجی و حافظهٔ موقت اپراتورها میتوانند SRAM را پر کنند. بنابراین معیار مهم، اوج مصرف حافظه هنگام اجرای واقعی است؛ نه فقط حجم فایل مدل یا تعداد پارامترها. مقالهٔ مروری TinyML نیز محدودیت حافظهٔ activation را از گلوگاههای کلیدی استقرار مدل روی MCU میداند.
| منبع محدود | چه چیزی مصرفش میکند؟ | چه چیزی اندازه بگیریم؟ |
|---|---|---|
| Flash / حافظهٔ برنامه | وزنهای مدل، runtime، کد و جدولهای ثابت | اندازهٔ مدل نهایی و فضای باقیمانده پس از لینک |
| SRAM | activationها، ورودی حسگر، بافرهای میانی و scratch | بیشینهٔ مصرف در بدترین مسیر inference |
| حافظهٔ خارجی | وزن یا دادهٔ حجیمتر، با هزینهٔ تأخیر و انرژی دسترسی | پهنای باند، الگوی دسترسی و هزینهٔ انتقال داده |
کوانتیزهسازی INT8: کاهش حجم با آزمون دقت
در مدل FP32 هر وزن معمولاً ۳۲ بیت دارد؛ نمایش INT8 از ۸ بیت استفاده میکند، پس بخش وزنها در حالت ایدهآل حدود یکچهارم بایتهای FP32 میشود. این نسبت به معنی چهار برابر کاهش در کل RAM یا چهار برابر افزایش سرعت نیست: activationها، سربار runtime، اپراتورهای پشتیبانینشده و رفتوآمد حافظه نتیجهٔ واقعی را تغییر میدهند. LiteRT عملگرهای کوانتیزهشدهٔ INT8/UINT8 را پشتیبانی میکند، اما سازگاری به اپراتورهای بهکاررفته در همان مدل هم بستگی دارد.
Post-training quantization یا QAT؟
- کوانتیزهسازی پس از آموزش: نقطهٔ شروع سریعتری است. برای کالیبراسیون، نمونههایی نزدیک به ورودی واقعی دستگاه انتخاب کنید؛ از شرایط نوری، نویز و دامنهٔ حسگر که در میدان دیده میشوند هم نمونه داشته باشید.
- Quantization-aware training: وقتی افت دقت پس از تبدیل زیاد است، آموزش با شبیهسازی اثر کوانتیزهسازی میتواند گزینهٔ بعدی باشد؛ سپس مدل تبدیلشده را روی دادهٔ آزمون دستنخورده بسنجید.
- حفظ عملگرهای ناسازگار: اگر مدل از عملگری استفاده کند که backend انتخابی پشتیبانی نمیکند، ممکن است تبدیل ناموفق شود یا بخشی از گراف روی CPU اجرا شود. خروجی ابزار تبدیل و گزارش تقسیمبندی گراف را بخوانید.
CPU، شتابدهندهٔ برداری یا NPU؟
CPU سادهترین مسیر برای نمونهٔ اولیه است، ولی سرعت و مصرف انرژی را باید با workload واقعی سنجید. کتابخانههای بهینهشده مانند CMSIS-NN میتوانند کرنلهای عصبی را روی Cortex-M کارآمدتر اجرا کنند؛ NPU زمانی مفید است که عملگرها، نوع داده و گراف مدل با backend آن سازگار باشند. برای نمونه در مسیر Arm Ethos-U، اجرای شتابگرفته به گراف کوانتیزهشده و بخشهای قابل واگذاری به NPU وابسته است؛ اپراتورهایی که شرایط backend را ندارند ممکن است بیرون از بخش شتابگرفته بمانند. پس فقط عدد TOPS یا نام NPU را معیار خرید نگذارید.
روال عملی طراحی روی برد
- کار را محدود تعریف کنید: نوع ورودی، تعداد کلاسها، نرخ نمونهبرداری، زمان مجاز پاسخ و رفتار امن هنگام خطا را مشخص کنید.
- نسخهٔ پایه بسازید: یک مدل کوچک با دادهٔ نماینده آموزش دهید و دقت، ماتریس خطا و عملکرد روی دادهٔ جداگانه را ثبت کنید.
- پروفایل سختافزار بگیرید: Flash، اوج SRAM، latency، مصرف انرژی هر inference و دمای برد را روی همان MCU/NPU هدف اندازه بگیرید.
- مدل را بهینه کنید: ابتدا معماری کوچکتر یا ورودی کموضوحتر را بررسی کنید، سپس INT8 و در صورت نیاز pruning یا QAT را آزمایش کنید.
- سازگاری گراف را بررسی کنید: لیست اپراتورهای پشتیبانیشده، fallback به CPU و نیاز runtime را کنترل کنید؛ در صورت امکان لایهبهلایه زمان اجرا را پروفایل بگیرید.
- روی برد نهایی اعتبارسنجی کنید: pipeline پیشپردازش باید با آموزش یکسان باشد. پس از آزمون رومیزی، دادهٔ واقعی حسگر، تغییر دما، افت ولتاژ و اجرای پیوسته را هم بسنجید.
یک نمونهٔ پژوهشی؛ عددها را تعمیم ندهید
در پژوهشی منتشرشده در مارس ۲۰۲۶ برای پردازش تصویر ماهوارهای روی STM32N6، نویسندگان هرس ساختاری، کوانتیزهسازی INT8 و نگاشت آگاه از سختافزار را ترکیب کردند. در مجموعهآزمایش همان مقاله، میانگین کاهش RAM برابر ۸۹٫۵۵٪ و کاهش Flash برابر ۷۰٫۰۹٪ گزارش شده و افت دقت مدلها بین ۰٫۴ تا ۸٫۶ واحد درصد بوده است. این نتیجه به مدلها، دادهها و پلتفرم همان آزمایش مربوط است؛ آن را تضمین عملکرد برای هر برد یا کاربرد دیگری ندانید. معیار شما باید آزمون تکرارپذیر روی سختافزار مقصد باشد.
جدول تصمیمگیری سریع
| شرایط پروژه | مسیر پیشنهادی برای ارزیابی | ریسک اصلی |
|---|---|---|
| حسگر ساده و بودجهٔ توان بسیار کم | MCU و مدل کوچک؛ ابتدا CPU بهینهشده | کمبود SRAM یا تأخیر بیش از حد |
| مدل CNN با inference مکرر | MCU با DSP/NPU و backend سازگار | بخشهایی از گراف به CPU برگردند |
| تصویر بزرگ یا چند مدل همزمان | SoC با حافظهٔ بیشتر و شتابدهندهٔ مناسب | توان، گرما و پهنای باند حافظه |
چکلیست پیش از تولید PCB
- اوج SRAM و فضای Flash با حاشیهٔ رشد اندازهگیری شده است.
- دقت مدل کوانتیزهشده روی دادهٔ واقعی و مجموعهٔ آزمون جدا سنجیده شده است.
- latency و انرژی در نرخ inference مورد نیاز ثبت شدهاند.
- نسخهٔ runtime، اپراتورها و backend روی firmware نهایی بررسی شدهاند.
- برای شبکه یا حافظهٔ خارجی، توان، نویز، پهنای باند و مسیرهای PCB در نظر گرفته شدهاند.
- رفتار دستگاه در صورت ورودی نامعتبر، عدم قطعیت بالا یا افت ارتباط مشخص است.
سوالات متداول
آیا INT8 همیشه بهترین انتخاب برای مدل MCU است؟
نه. INT8 معمولاً حجم وزنها را کم میکند و با بعضی backendها سازگاری خوبی دارد، اما ممکن است دقت را کاهش دهد یا بعضی اپراتورها را ناسازگار کند. دقت و سرعت مدل تبدیلشده را روی دستگاه واقعی بسنجید.
اگر فایل مدل در Flash جا میشود، یعنی RAM هم کافی است؟
خیر. activationها و بافرهای میانی RAM میخواهند و ممکن است اوج مصرفشان از اندازهٔ وزنها مهمتر باشد. اندازهگیری runtime روی مسیر واقعی ضروری است.
NPU همیشه از CPU سریعتر و کممصرفتر است؟
نه لزوماً. نتیجه به سازگاری گراف، اندازهٔ ورودی، انتقال داده و بار راهاندازی وابسته است. هر دو backend را با سناریوی نهایی و ابزار اندازهگیری یکسان مقایسه کنید.