مدل چندوجهی جیبی: دیدن و شنیدن روی دستگاه

ت

تیم ژرف ای‌آی

۵ مرداد ۱۴۰۵به‌روزرسانی ۸ مرداد ۱۴۰۵۹ دقیقه مطالعه
مدل چندوجهی جیبی: دیدن و شنیدن روی دستگاه

مدل کوچک روی تلفن، دوربین، خودرو، پوشیدنی، مرورگر یا کنترلر صنعتی می‌تواند تصویر، صدا، متن و حسگر را بدون ارسال همه ورودی خام به ابر بفهمد. این معماری تأخیر، حریم خصوصی، کار آفلاین، هزینه و دامنه خرابی را تغییر می‌دهد؛ اما محیط یکنواخت سرور را نیز با هزاران ترکیب سخت‌افزار و سیستم‌عامل عوض می‌کند.

پرسش درست فقط «آیا مدل روی دستگاه اجرا می‌شود؟» نیست. باید پرسید «آیا کل قابلیت روی ضعیف‌ترین دستگاه پشتیبانی‌شده، زیر فشار حافظه، گرما، نور، صدا، شبکه و باتری همان وعده را حفظ می‌کند؟»

وعده لبه را محدود و قابل سنجش کنید

مدل چندوجهی محلی برای کارهای زیر مناسب است:

  • تشخیص واژه بیدارباش یا رخداد صوتی؛
  • قاب‌بندی و ارزیابی سند پیش از ثبت؛
  • تشخیص وضعیت تجهیز یا ناهنجاری دیداری؛
  • تولید نشانه دسترس‌پذیری از دوربین و صدا؛
  • استخراج سیگنال ساختاریافته از رسانه خصوصی؛
  • ترجمه یا تبدیل گفتار رایج به‌صورت آفلاین؛
  • رتبه‌بندی پایگاه دانش محلی کوچک؛
  • تشخیص اینکه ورودی به سرویس بزرگ‌تر نیاز دارد یا نه.

کارهایی که دانش وسیع روز، زمینه بسیار بلند، تحلیل چندین فریم با وضوح بالا یا برنامه‌ریزی باز می‌خواهند معمولاً برای مدل کوچک محلی مناسب نیستند. طراحی ترکیبی می‌تواند رسانه خام را روی دستگاه نگه دارد، فقط نمایش ساختاریافته مجاز را به ابر بفرستد و نتیجه را برای اقدام برگرداند.

وعده را اندازه‌پذیر بنویسید. «کمک هوش مصنوعی با دوربین» مبهم است. «تشخیص دیده‌شدن چهار گوشه کارت با تأخیر صدک ۹۵ کمتر از ۱۵۰ میلی‌ثانیه و بدون آپلود preview» قابل آزمون است.

هر مرحله را میان دستگاه و ابر تقسیم کنید

یک تصمیم برای کل قابلیت نگیرید:

مرحلهدستگاه بهتر است وقتیابر بهتر است وقتی
ثبت و فیلتررسانه خام حساس یا پرحجم استثبت مرکزی الزام دارد
ادراک اولیهتأخیر و آفلاین مهم استشتاب‌دهنده سرور برای کیفیت لازم است
بازیابیدانش کوچک، خصوصی و محلی استcorpus بزرگ یا دائماً متغیر است
استدلالکار محدود و زمینه کوتاه استدانش وسیع یا زمینه بلند لازم است
اقدامسخت‌افزار باید فوری پاسخ دهداقدام به وضعیت مرجع سرور وابسته است
تحلیلتجمیع کم‌خطر کافی استتحلیل مرکزی جزئی مبنای معتبر دارد

معماری ترکیبی باید انتقال داده را واقعاً کم کند. دقیق بنویسید کدام feature vector، crop، transcript یا فایل تأییدشده اجازه خروج دارد. راهنمای حریم خصوصی در هوش مصنوعی روی دستگاه مرز داده و مطلب مدل زبانی کوچک در لبه انتخاب مدل را بررسی می‌کند.

ابتدا محدوده سخت‌افزار را تعریف کنید

دستگاه‌های پشتیبانی‌شده را فهرست کنید:

  • CPU، GPU، NPU و شتاب‌دهنده عصبی؛
  • حافظه کل و آزاد؛
  • سیستم‌عامل، driver و runtime؛
  • ویژگی دوربین، میکروفن و حسگر؛
  • محدودیت ذخیره و دانلود؛
  • باتری و طراحی حرارتی؛
  • محدودیت اجرای پس‌زمینه؛
  • عمر دستگاه و دوره پشتیبانی.

یک tier حداقلی و tierهای بهتر تعریف کنید. اگر یک artifact برای همه مناسب نیست، با capability handshake نسخه تأییدشده را انتخاب کنید. هرگز بی‌صدا از پردازش محلی به آپلود ابری برنگردید؛ این کار وعده حریم را تغییر می‌دهد و رضایت روشن می‌خواهد.

Google AI Edge استقرار شتاب‌گرفته و benchmark روی دستگاه واقعی Android را پشتیبانی می‌کند. Core ML اپل اجرا روی CPU، GPU و Neural Engine را با توجه به حافظه و توان بهینه می‌کند. این runtimeها اجرا را آسان می‌کنند، اما جای آزمون کیفیت محصول را نمی‌گیرند.

کل pipeline را بهینه کنید

فقط حجم فایل مدل تعیین‌کننده نیست. زمان شروع حسگر، decode، resize، normalize، بارگذاری، warm-up، اولین خروجی، inference مداوم، post-processing و به‌روزرسانی UI را جدا اندازه بگیرید. اوج حافظه، fragmentation، مصرف باتری، throttling و زمان دانلود نیز مهم‌اند.

ابتدا کار پرهزینه را حذف کنید. crop کوچک‌تر یا inference رویدادمحور شاید از فشرده‌سازی شدید وزن بیشتر سود دهد. buffer را بازاستفاده، تبدیل رسانه تکراری را حذف و model lifecycle را با محدودیت سیستم‌عامل هماهنگ کنید.

برای صدا یا ویدیوی پیوسته، cascade بسازید:

آشکارساز ارزان -> پنجره محتمل -> مدل محلی غنی‌تر -> گام ابری اختیاری با رضایت

مرحله ارزان را برای رخداد از‌دست‌رفته بسنجید؛ cascade سریع اگر حالت مهم را حذف کند بی‌فایده است.

فشرده‌سازی رفتار را عوض می‌کند

کوانتیزه‌سازی، pruning، distillation و تغییر معماری می‌توانند حافظه و تأخیر را کم کنند، اما الگوی خرابی را نیز تغییر می‌دهند.

پس از هر artifact:

  • کل ارزیابی کار را تکرار کنید؛
  • گروه و وضعیت محیطی را مقایسه کنید؛
  • calibration و آستانه خودداری را بسنجید؛
  • برچسب نادر و جزئیات کوچک دیداری یا صوتی را بررسی کنید؛
  • backend سخت‌افزاری را جداگانه آزمون کنید؛
  • hash، runtime، operator و پیکربندی quantization را ثبت کنید.

«کمتر از یک امتیاز افت میانگین» کافی نیست. فشرده‌سازی ممکن است لهجه، گفتار آرام، نور کم، شیء کوچک، تاری حرکت یا حسگر قدیمی را بیشتر خراب کند.

روی دستگاه واقعی benchmark بگیرید

ماتریس باید ضعیف‌ترین دستگاه، میان‌رده رایج، مرجع قوی، cold و warm start، فشار پس‌زمینه، حالت کم‌باتری، دستگاه گرم، کمبود حافظه و نسخه‌های سیستم‌عامل را پوشش دهد.

میانه و tail latency، اوج حافظه، انرژی هر کار، throughput مداوم، kill rate و کیفیت همان artifact نهایی را گزارش کنید.

MLPerf Mobile v6.0 در ژوئن ۲۰۲۶ آزمون LLM روی موبایل را به workloadهای دیداری و تولید تصویر افزود. تعریف benchmark موبایل نشان می‌دهد عملکرد و هدف کیفیت باید کنار هم باشند. benchmark استاندارد برای مقایسه پلتفرم مفید است، اما benchmark محصول با حسگر، ورودی، preprocessing و بودجه تأخیر واقعی لازم می‌ماند.

محیط چندوجهی را ارزیابی کنید

تصویر

نور کم و ترکیبی، glare، سایه، پوشیدگی، لرزش، چرخش، فاصله، شیء کوچک، لنز کثیف، رنگ پوست، سند فرسوده، ثبت دوباره نمایشگر و الگوی خصمانه.

صدا

لهجه و گویش، اختلال گفتاری، گفتار آرام، چند گوینده، پژواک، باد، ماشین‌آلات، موسیقی، میکروفن مختلف، packet loss و playback attack.

حسگر و زمینه

حسگر مفقود، drift ساعت، orientation، تفاوت calibration، مجوز مکان، حرکت، sample rate متغیر و وضعیت محلی کهنه.

همجوشی چندوجهی

تعارض کانال‌ها، timestamp ناهماهنگ، خرابی یک modality و مدل مطمئنی که کانال آسان‌تر را بیش از حد وزن می‌دهد.

داده میدانی رضایت‌مندانه، شبیه‌سازی کنترل‌شده و تقویت مصنوعی با محدودیت مستند را ترکیب کنید. مصنوعی نباید جای آزمون واقعی را بگیرد؛ حکمرانی داده مصنوعی را ببینید.

حریم و امنیت ویژگی معماری‌اند

پردازش محلی انتقال رسانه خام را کم می‌کند، اما feature خودکار خصوصی نیست. cache، embedding، transcript، crash log، analytics، screenshot و backup می‌توانند اطلاعات را بیرون ببرند.

کنترل‌ها:

  • فهرست و مدت نگهداری داده محلی؛
  • رمزنگاری با امکانات سیستم‌عامل؛
  • منع داده حساس در لاگ عادی؛
  • permission روشن و متصل به ارزش feature؛
  • نشانه فعال‌بودن حسگر؛
  • حذف حافظه و artifact توسط کاربر؛
  • package امضاشده و update قابل راستی‌آزمایی؛
  • پاسخ به آسیب‌پذیری و rollback؛
  • رضایت پیش از fallback ابری.

استخراج مدل، adversarial example، تزریق پرامپت از تصویر یا صدا و update آلوده را مدل تهدید کنید. مدل محلی شاید به دوربین، میکروفن، فایل یا clipboard دسترسی داشته باشد؛ اصل کمترین اختیار همچنان برقرار است.

افت کیفیت را صادقانه مدیریت کنید

دستگاه باید اطمینان کم، ورودی پوشیده یا noisy، زبان و حسگر پشتیبانی‌نشده، فشار حافظه، throttling، مدل منقضی و نبود شبکه را تشخیص دهد.

راه بازیابی دقیق بدهید: نور را بهتر کنید، نزدیک‌تر شوید، عبارت را تکرار کنید، بسته زبان را دانلود کنید، صبر کنید دستگاه خنک شود، مسیر دستی را ادامه دهید یا با رضایت از ابر استفاده کنید. کار کاربر را حفظ کنید.

«نمی‌توانم این تصویر را روی این دستگاه راستی‌آزمایی کنم» بهتر از حدس روان است. کیفیت خودداری بخشی از کیفیت کار است.

مدل را مانند نرم‌افزار به‌روز کنید

artifact را امضا و hash کنید؛ نسخه آموزش، ارزیابی، runtime و بهینه‌سازی را ثبت کنید؛ همه tierها را بیازمایید؛ rollout مرحله‌ای و مقایسه کیفیت، تأخیر، توان و fallback داشته باشید؛ rollback امن نگه دارید؛ و برای دستگاهی که مدل تازه را اجرا نمی‌کند پایان پشتیبانی تعریف کنید.

شناسه نسخه و outcome کم‌خطر را ثبت کنید تا نسخه قدیم و جدید در تحلیل گم نشوند.

معیارهای محصول

  • موفقیت کار و کیفیت خودداری؛
  • false positive و false negative بر اساس گروه و محیط؛
  • cold start، اولین خروجی، end-to-end و tail latency؛
  • اوج حافظه و termination سیستم‌عامل؛
  • انرژی هر کار و اثر باتری؛
  • رفتار حرارتی مداوم؛
  • نرخ تکمیل آفلاین؛
  • نرخ fallback ابری و رضایت؛
  • موفقیت دانلود، فعال‌سازی و rollback؛
  • اصلاح کاربر و تکمیل مسیر دستی؛
  • رخداد حریم و امنیت.

کوچک‌ترین یا سریع‌ترین مدل الزاماً بهترین نیست. معیار، نتیجه موفق کاربر داخل بودجه سخت‌افزار، حریم و انرژی است.

مسیر عرضه مرحله‌ای

  1. کار را با مدل سروری اثبات و مجموعه ارزیابی واقعی بسازید.
  2. وعده محلی و محدوده دستگاه را تعریف کنید.
  3. خط پایه کیفیت و تأخیر بگیرید.
  4. کوچک‌ترین pipeline محلی که آن را حفظ می‌کند بسازید.
  5. fallback ترکیبی را فقط برای حالت نام‌گذاری‌شده و با رضایت اضافه کنید.
  6. سخت‌افزار، محیط، زبان و دسترس‌پذیری را بیازمایید.
  7. روی cohort محدود عرضه کنید.
  8. فقط با شواهد تولید دامنه را توسعه دهید.

برای دروازه انتشار، چک‌لیست آمادگی تولید هوش مصنوعی را اجرا کنید.

پرسش‌های رایج

آیا on-device یعنی هیچ داده‌ای خارج نمی‌شود؟

فقط اگر کل feature همین‌طور طراحی شده باشد. analytics، crash log، backup، fallback و سرویس متصل ممکن است داده منتقل کنند. جریان کامل را مستند و آزمون کنید.

مدل چقدر کوچک باشد؟

به‌اندازه‌ای کوچک که روی ضعیف‌ترین دستگاه، کیفیت، tail latency، حافظه، انرژی، ذخیره و پشتیبانی را حفظ کند. تعداد پارامتر رفتار runtime را به‌تنهایی پیش‌بینی نمی‌کند.

یک مدل برای همه دستگاه‌ها؟

اگر envelope را حفظ می‌کند، بله. در غیر این صورت tierهای آزموده‌شده با انتخاب بر اساس capability بسازید و رفتار حریم و feature را ثابت و آشکار نگه دارید.

مدل ابری همیشه دقیق‌تر است؟

خیر. مدل تخصصی محلی در کار محدود می‌تواند بهتر باشد. artifact واقعی را روی داده نماینده مقایسه کنید.

منابع و تاریخ بازبینی

این راهنما در ۸ مرداد ۱۴۰۵ (۳۰ ژوئیه ۲۰۲۶) به‌طور اساسی با منابع زیر بازبینی شد:

هوشمندی لبه به دلیل فوریت و حریم خصوصی ارزش دارد. طراحی قوی، مدل کوچک را مسئول یک وعده کوچک اما مهم می‌کند و همان وعده را روی سخت‌افزار واقعی ثابت می‌کند.

#هوش مصنوعی لبه#هوش مصنوعی چندوجهی#مدل کوچک#حریم خصوصی

مطالب مرتبط

داده مصنوعی با شناسنامه
بینش‌های صنعت

داده مصنوعی با شناسنامه

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

ادامه مطلب

ادامه مطالعه

گزارش روزانه و راهنماهای عملیاتی ژرف را ببینید. این صفحه یک آرشیو موضوعی است، نه دعوت به شروع پروژه.