اگر امروز برای اجرای مدلهای هوش مصنوعی در وب هزینه سرور میپردازید، این هزینه میتواند به صفر برسد. گوگل با معرفی LiteRT.js، سرعت استنتاج در مرورگر را تا ۳ برابر افزایش داد.
این ابزار در واقع یک اتصال جاوااسکریپتی برای کتابخانه استنتاج روی دستگاه گوگل است (که پیشتر TensorFlow Lite نام داشت) و به مدلهای .tflite اجازه میدهد با عملکردی در سطح سیستمعامل، بهصورت محلی در مرورگر اجرا شوند. وبسایتهای مبتنی بر هوش مصنوعی پیش از این به هستههای جاوااسکریپتی متکی بودند که طبق اعلام گوگل، بازدهی پایینی داشتند. همانطور که در پوشش پیشین ما از نقشههای راه امنیتی گوگل دیپمایند دیدیم، این شرکت اکنون لایه اجرا را به سختافزار کاربر نزدیکتر میکند. گوگل به جای نوشتن کدهای جدید برای هر مرورگر، محیط اجرای بومی خود را به WebAssembly تبدیل کرد تا بهینهسازیهای اندروید، iOS و دسکتاپ مستقیماً روی وباپلیکیشنها اعمال شود. این رویکرد تضمین میکند که ارتقاهای عملکردی و بهبودهای کوانتیزاسیون (Quantization) که برای سیستمعاملهای موبایل و دسکتاپ ساخته شدهاند، اکنون برای وباپها نیز در دسترس باشند.
مزیت اجرای محلی
بر اساس مستندات گوگل، استنتاج محلی سه مزیت اصلی دارد: افزایش حریم خصوصی کاربران (چون دادهها دستگاه را ترک نمیکنند)، حذف کامل هزینههای سرور و تأخیر بسیار کم (Ultra-low latency). LiteRT.js یک فرمت جدید برای مدلها نیست، بلکه راهی است تا یک محیط اجرای چندپلتفرمی بومی (Native) را با تمام بهینهسازیهایش به کاربر برساند. این رویکرد یادآور تلاشهای گستردهتر برای بهینهسازی سختافزاری است که در ابزارهای متنباز برای استنتاج مدلهای زبانی محلی نیز شاهد آن بودیم.
به نقل از وبلاگ توسعهدهندگان گوگل، LiteRT.js برای بهرهبرداری حداکثری از سختافزار از سه درگاه (Backend) متمایز استفاده میکند:
- CPU: با کمک XNNPACK — کتابخانه بهینه CPU گوگل که از پشتیبانی چند-رشتهای (Multi-thread) و یک ساختار SIMD تسهیلشده بهره میبرد.
- GPU: استفاده از ML Drift (راهکار GPU روی دستگاه گوگل) که از طریق API WebGPU اجرا میشود. این تمرکز بر بهرهوری گرافیکی در مرورگر، مشابه رویکردی است که برای کاهش زمان رندر WebGL با جایگزینی SwiftShader به کار گرفته شد.
- NPU (واحد پردازش عصبی) — یعنی تراشهای تخصصی که مثل یک ماشینحساب فوقسریع برای ریاضیات هوش مصنوعی است؛ این بخش از API آزمایشی WebNN در مرورگرهای کروم و مایکروسافت اج استفاده میکند.
جزئیات پیادهسازی
دو قانون حیاتی در نحوه توزیع تکالیف LiteRT.js وجود دارد. اول اینکه تفویض جزئی (Partial Delegation) پشتیبانی نمیشود؛ یعنی یک گراف محاسباتی نمیتواند بهطور همزمان بین CPU و GPU تقسیم شود. دوم اینکه تفویض برای هر مدل بهصورت «همه یا هیچ» است. اگر مدلی نتواند بهطور کامل به شتابدهنده منتخب منتقل شود، سیستم بهطور خودکار به اجرای wasm بازمیگردد. با این حال، در حالی که مسیر CPU گستردهترین پوشش از عملگرها (Operators) را ارائه میدهد، شتابدهندهها بیشترین سرعت را فراهم میکنند.
بنچمارکهای انجام شده روی مکبوک پرو ۲۰۲۴ با تراشه M4 Apple Silicon نشان میدهد که در کارهای سنگین و در لحظه (Real-time) مثل ردیابی اشیا و تبدیل گفتار به متن، سرعت اجرا هنگام انتقال از CPU به GPU یا NPU بین ۵ تا ۶۰ برابر افزایش مییابد. برای پردازشهای استاندارد بینایی ماشین و صوت، این سیستم تا ۳ برابر سریعتر از سایر محیطهای اجرای وب است، هرچند گوگل اشاره کرد که نتایج نهایی بسته به نوع GPU محلی، بهینهسازی درایورها و گلوگاههای حرارتی (Thermal Throttling) متغیر است.
اتصال مدلها به این سیستم نیاز به یک خط لوله (Pipeline) سختگیرانه دارد. برای انتقال یک مدل PyTorch به LiteRT، توسعهدهندگان باید از دستور torch.export.export استفاده کنند، به این معنی که مدل حتماً باید قابلیت خروجیگیری از طریق TorchDynamo را داشته باشد. مدل نمیتواند شامل شاخههای شرطی پایتون باشد که به مقادیر تنسور در زمان اجرا بستگی دارد و همچنین ابعاد ورودی و خروجی (از جمله بعد دستهای یا Batch Dimension) نمیتوانند پویا (Dynamic) باشند.
برای بهینهسازی اندازه مدل، از AI Edge Quantizer برای پیکربندی طرحهای کوانتیزاسیون در لایههای مختلف استفاده میشود. همچنین مدلهای .tflite پیشآموزشدیده از طریق پلتفرم Kaggle و جامعه LiteRT در Hugging Face در دسترس هستند.
در مدیریت حافظه، LiteRT.js با رفتار استاندارد جاوااسکریپت متفاوت است و تنسورها را بهصورت خودکار پاک نمیکند (Garbage-collection ندارد). توسعهدهندگان باید صراحتاً متد .delete() را برای هر تنسور صدا بزنند تا از نشت حافظه (Memory Leak) در دستگاه جلوگیری کنند؛ نکتهای که حتی در قطعه کد ارائه شده در پست معرفی گوگل نیز نادیده گرفته شده بود. علاوه بر این، برای استفاده از WebNN، باید پرچم jspi: true فعال باشد تا پل ارتباطی بین زمانبندی هستههای سنکرون و نظارت غیرسنکرون دستگاه برقرار شود.
گوگل کاربرد این ساختار را در چهار دمو نمایش داد:
- تشخیص اشیا در لحظه: با استفاده از مدل Ultralytics YOLO از طریق خروجی رسمی در بسته پایتون Ultralytics.
- عمقسنجی از وبکم: استفاده از Depth-Anything-V2 برای تبدیل پیکسلهای ویدیو به یک ابر نقاط سهبعدی زنده از طریق WebGPU.
- بزرگنمایی تصویر: استفاده از Real-ESRGAN برای ارتقای ابعاد تکههای ۱۲۸×۱۲۸ پیکسل به ۵۱۲×۵۱۲ بهصورت محلی.
- جستوجوی معنایی: اجرای جستوجوی برداری Gemma در صفحه با استفاده از بردار معنایی (Embedding) سمت کاربر.
این تغییر، فرض بنیادین تیمهای یادگیری ماشین در وب را عوض میکند. گوگل LiteRT.js را بهعنوان جایگزینی برای Graph Models در TensorFlow.js معرفی کرده است و بدین ترتیب محیط اجرا (Runtime) را از پیشپردازش تفکیک میکند. توسعهدهندگان همچنان میتوانند از TensorFlow.js برای دستکاری دادهها استفاده کنند، اما انتقال تنسورها بین این دو کتابخانه از طریق بسته @litertjs/tfjs-interop و متد runWithTfjsTensors انجام میشود. گوگل هشدار داده است که از tensor.dataSync اجتناب شود، زیرا در بکاندهای WebGPU جریمه عملکردی شدیدی دارد.
برای تأیید مدل پیش از استقرار، توسعهدهندگان میتوانند از بسته @litertjs/model-tester (از طریق npx model-tester) استفاده کنند تا تستهای خودکار را با ورودیهای تصادفی روی درگاههای WebNN، WebGPU و CPU اجرا نمایند. همچنین برای خواندن نامها و ابعاد ورودی، باید از model.getInputDetails() استفاده شود.
از نظر اقتصادی، این یعنی هزینه صفر برای سرورهای استنتاج و جهشی بزرگ در حریم خصوصی کاربران. اما نقطه مقابل این مزایا، مدل مدیریت حافظه پیچیدهتر و الزامات سختگیرانه برای خروجی گرفتن کاربران PyTorch است.
گام بعدی شما
- اگر از TensorFlow.js استفاده میکنید، مدلهای خود را با LiteRT.js تست کنید تا کاهش تأخیر را بسنجید.
- برای مدلهای PyTorch، بررسی کنید که آیا مدل شما با استانداردهای TorchDynamo برای خروجی گرفتن سازگار است یا خیر.
- مدیریت دستی حافظه با
.delete()را به استانداردهای کدنویسی تیم خود اضافه کنید تا از کرش کردن مرورگر کاربران جلوگیری شود.
اما چالش اصلی هنوز در دسترسی به سختافزارهای بهینه است؛ به تحلیل ما درباره تراشههای Blackwell و آینده استنتاج در لبه مراجعه کنید.
گفتگو