هوش مصنوعی لبه یا پردازش ابری؛ مدل شما باید کجا اجرا شود؟

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

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

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

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

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

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

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