پردازش تصویر روی دستگاه یا سرور؟
هر پروژهٔ بینایی ماشینی به این تصمیم میرسد: تصویر کجا پردازش شود؟
روی خود دستگاه — دوربین هوشمند، موبایل، رایانهٔ صنعتی کنار خط.
روی سرور — دستگاه فقط تصویر میفرستد.
و برخلاف بیشتر تصمیمهای فنی، این یکی مدل هزینه و قابلیت اتکای کل سامانه را تعیین میکند، نه فقط معماریاش.
پنج معیار
۱. تأخیر
چقدر سریع باید جواب بیاید؟
- دروازهٔ پارکینگ: کمتر از یکی دو ثانیه. رفتوبرگشت شبکه گران است.
- خط تولید سریع: میلیثانیه. فقط روی دستگاه.
- پردازش فاکتور: چند ثانیه قابل قبول است. سرور مشکلی ندارد.
قاعده: اگر انسان یا ماشینی منتظر جواب ایستاده، روی دستگاه. اگر پردازش دستهای است، سرور.
۲. پهنای باند
ویدیوی مداوم، حجم زیادی مصرف میکند. برای چند دوربین، این هزینهٔ دائمی است نه یکباره.
اگر تصویر پیوسته است، پردازش روی دستگاه و ارسال فقط نتیجه، تقریباً همیشه درست است. یک خط متن بهجای مگابایتها ویدیو.
اگر ورودی تکتصویر است — عکس فاکتور، سلفی احراز هویت — پهنای باند مسئله نیست.
۳. حریم خصوصی
در چند حوزه، خروج تصویر از محل اصلاً مجاز نیست:
- تصویر مدرک هویتی و چهره.
- تصویر پزشکی.
- محیط کارخانهای که فرایندش محرمانه است.
- تصویر داخل منزل.
اگر این محدودیت را دارید، تصمیم گرفته شده و بقیهٔ معیارها فرقی نمیکنند.
و در بازار ما یک لایهٔ اضافه: سرویس ابری خارجی، ریسک دسترسی هم دارد. سامانهای که پردازشش روی سرویسی است که ممکن است فردا در دسترس نباشد، ریسکی برداشته که باید آگاهانه باشد — همان بندی که در وابستگی به تأمینکننده گفتیم.
۴. هزینه
روی دستگاه: سرمایهگذاری اولیه (سختافزار)، هزینهٔ جاری نزدیک صفر.
روی سرور: ورود ارزان، هزینهٔ جاری که با حجم رشد میکند.
نقطهٔ سربهسر به حجم بستگی دارد. برای حجم بالا و پیوسته، پردازش روی دستگاه تقریباً همیشه ارزانتر تمام میشود — و برخلاف سرور، موفقیت شما هزینهتان را بالا نمیبرد.
همان منطقی که در هزینهٔ مالکیت گفتیم: رقم ورود، هزینهٔ مالکیت نیست.
۵. قطعی شبکه
اگر شبکه قطع شود، سامانه باید کار کند؟
پارکینگ، خط تولید و اپلیکیشن میدانی: بله. پس روی دستگاه.
پردازش دستهای اسناد: نه. صف بماند تا شبکه برگردد.
معماری ترکیبی، که معمولاً درستترین است
بیشتر سامانههای واقعی هر دو را دارند:
روی دستگاه: غربال سریع. مدل سبک تشخیص میدهد که اصلاً چیزی هست یا نه. اگر نه، دور ریخته میشود.
روی سرور: پردازش دقیق برای مواردی که از غربال گذشتهاند.
مثالها:
- دوربین نظارتی: تشخیص حرکت و حضور انسان روی دستگاه؛ تحلیل دقیق روی سرور. حجم ارسالی چند مرتبه کم میشود.
- اپلیکیشن موبایل: بررسی کیفیت و کادر تصویر روی گوشی، OCR روی سرور. جلوگیری از آپلود عکس بد، مؤثرترین بهینهسازی این حالت است.
- خط تولید: طبقهبند سریع محلی، تحلیل عیب روی سرور.
پردازش روی موبایل، حالت خاص
اگر اپلیکیشن میسازید:
چه چیزی روی گوشی معقول است: تشخیص کادر و لبهٔ سند، بررسی تاری و نور، تشخیص چهره برای کادربندی، بارکد و QR، و طبقهبندی ساده.
چه چیزی معمولاً نه: OCR دقیق فارسی، مدلهای بزرگ، هر چیزی که حجم زیادی به اپ اضافه کند.
سه ملاحظهٔ عملی:
حجم اپ. مدل چند ده مگابایتی، حجم نصب را بالا میبرد — که در بازار ما روی نرخ نصب اثر دارد، همانطور که در کارایی اپلیکیشن گفتیم.
باتری و گرما. پردازش پیوستهٔ تصویر، پرمصرفترین کاری است که یک اپ میکند.
تنوع سختافزار. مدلی که روی گوشی جدید روان است، روی دستگاه چندساله کند است. روی دستگاه مرجع ضعیف تست کنید.
جزئیات بیشتر در هوش مصنوعی روی خود دستگاه.
بهروزرسانی مدل، که دستکم گرفته میشود
روی سرور: ساده. مدل جدید مستقر میشود و همه از همان لحظه استفاده میکنند.
روی دستگاه: مسئلهدار. باید مدل را به دهها یا صدها دستگاه برسانید.
اگر این مسیر را میروید، از روز اول سازوکار بهروزرسانی مدل را بسازید: نسخهبندی، انتشار تدریجی، بازگشت خودکار در صورت خرابی. همان اصولی که در مدیریت دستگاههای IoT گفتیم — و همان نکته که افزودنش بعداً به دستگاههای مستقرشده تقریباً غیرممکن است.
جدول تصمیم
| وضعیت | پیشنهاد |
|---|---|
| تأخیر بحرانی | دستگاه |
| ویدیوی پیوسته | دستگاه (غربال) + سرور |
| تصویر حساس، ممنوعیت خروج | دستگاه یا سرور داخلی |
| حجم بالا و پایدار | دستگاه |
| حجم کم یا نامنظم | سرور |
| مدل بزرگ و سنگین | سرور |
| نیاز به کار بدون شبکه | دستگاه |
| نیاز به بهروزرسانی مکرر مدل | سرور |
| بودجهٔ اولیهٔ محدود | سرور |
و یک توصیهٔ ترتیبی
اگر مطمئن نیستید: با سرور شروع کنید، ولی معماری را جوری ببندید که انتقال به دستگاه ممکن باشد.
یعنی پیشپردازش و منطق را از محل اجرا جدا نگه دارید — همان کد پیشپردازش باید در هر دو مسیر قابل اجرا باشد، به دلیلی که در پیشپردازش تصویر گفتیم: تفاوت پیشپردازش بین آموزش و تولید، شایعترین باگ خاموش این حوزه است.
با سرور، سریعتر به نتیجه میرسید و میفهمید سامانه واقعاً چه دقتی دارد و چه حجمی. آنوقت تصمیم انتقال، بر اساس عدد گرفته میشود نه حدس.