۵۰ مگابایت حافظه مرورگر و زمان تولید اولین توکن زیر ۱۰ میلی‌ثانیه؛ این‌ها استانداردهای جدید برای یک مدل هوش مصنوعی ۱۰۰ میلیون پارامتری در دنیای امروز هستند. این ارقام حاصل آزمایشگاه MicroLLM از مجموعه State of Utopia است که ثابت می‌کند استنتاج با کارایی بالا دیگر به خوشه‌های ابری گران‌قیمت وابسته نیست. این آزمایش به طور عملی نشان می‌دهد که چگونه هفت مدل زبانی کوچک (Tiny LLMs)، در بازه ۲۵ تا ۳۶۰ میلیون پارامتر، می‌توانند مستقیماً در یک مرورگر وب بارگذاری، بنچ‌مارک و مورد استفاده قرار گیرند.
سال‌هاست که صنعت هوش مصنوعی به دنبال مدل‌های بزرگ‌تر بوده است، اما هزینه اجرای غول‌های ۱۷۵ میلیارد پارامتری در محیط عملیاتی برای اکثر تیم‌ها کمرشکن و غیرممکن است. ما پیش از این بررسی کردیم که چگونه می‌توان این هزینه‌ها را از طریق پروفایل‌های استنتاج و کاهش ۸۳ درصدی توکن‌های ورودی بهینه کرد، اما رویکرد MicroLLM کلاً سرور را از چرخه حذف می‌کند. با انتقال محاسبات به لبه (Edge)، توسعه‌دهندگان می‌توانند صورت‌حساب‌های API و تأخیرهای شبکه را به‌طور کامل دور بزنند. این موضوع به‌ویژه در بازار کره جنوبی اهمیت دارد، جایی که شرکت‌ها نسبت به ارسال داده‌های اختصاصی و محرمانه به APIهای خارجی بسیار محتاط هستند؛ نگرانی‌ای که سرویس بررسی فنی فناوری هوش مصنوعی Knowverse به کمی‌سازی و کاهش آن کمک می‌کند.
سازوکار هوش مصنوعی مبتنی بر مرورگر
این سامانه بر پایه WebGPU کار می‌کند؛ یک استاندارد W3C که به مرورگرها اجازه می‌دهد به توان‌های محاسباتی سطح پایین GPU دسترسی داشته باشند. WebGPU در واقع به عنوان یک لایه انتزاعی (Abstraction Layer) روی Metal اپل، DirectX 12 ویندوز و Vulkan لینوکس عمل می‌کند. این فناوری به توسعه‌دهندگان اجازه می‌دهد «شیدرهای محاسباتی» (Compute Shaders) بنویسند که به‌جای تکیه بر حلقه کندِ رویدادهای جاوااسکریپت، مستقیماً و به‌صورت بومی روی سخت‌افزار گرافیکی کاربر اجرا شوند. از آنجایی که WebGPU خارج از این حلقه اجرا می‌شود، رابط کاربری (UI) حتی در حین تولید فعال متن، سریع و پاسخگو باقی می‌ماند.
برای جا دادن این مدل‌ها در فضای محدود مرورگر، این آزمایشگاه از کوانتیزاسیون Q4 استفاده کرده است. این فرآیند — که شبیه به فشرده‌سازی یک عکس با کیفیت بالا برای ارسال سریع‌تر است — وزن‌های مدل را از اعداد اعشاری ۱۶ بیتی به نمایش‌های ۴ بیتی تبدیل می‌کند. نتیجه این کار، کاهش ۷۵ درصدی فضای مورد نیاز در حافظه است. این رویکرد بهینه‌سازی حافظه یادآور دستاوردهای پروژه PrismML است که توانست اثر حافظه را تا ۹ برابر کاهش دهد در حالی که دقت مدل را حفظ می‌کرد. برای مثال، یک مدل ۱۰۰ میلیون پارامتری تنها به ۵۰ تا ۸۴ مگابایت فضا در IndexedDB مرورگر نیاز دارد، در حالی که کیفیت تولید متن برای بسیاری از دستورات کاربردی، «تقریباً بدون افت» (Near-lossless) باقی می‌ماند.
جزئیات پیاده‌سازی فنی
بر اساس مستندات این پروژه، گردش کار عملیاتی از یک خط لوله سه مرحله‌ای تشکیل شده است:
- بارگذاری مدل: نقاط بازرسی (Checkpoints) کوانتیده به‌صورت استریم وارد IndexedDB خصوصی مرورگر می‌شوند. این فایل‌ها کش می‌شوند تا اطمینان حاصل شود که بارگذاری‌های بعدی به‌صورت آنی انجام می‌گیرد.
- ارسال کرنل: لایه‌های ترنسفورمر (Transformer) به خط لوله‌های محاسباتی WebGPU کامپایل می‌شوند. در این مرحله، هر ضرب ماتریسی به یک شیدر نگاشت می‌شود که به‌صورت موازی روی هسته‌های GPU اجرا می‌گردد.
- تولید توکن: یک حلقه نمونه‌گیری (Sampling) یا حریصانه (Greedy)، توکن بعدی را واکشی کرده، آن را در یک بافر مشترک می‌نویسد و این روند را تا رسیدن به شرط توقف تکرار می‌کند.
برای توسعه‌دهندگان، یک پیاده‌سازی عملی شامل آماده‌سازی یک نقطه بازرسی کوانتیده Q4 (مثلاً ۱۰۰ میلیون پارامتر)، تبدیل وزن‌ها به یک Uint8Array سازگار با WebGPU و ارائه یک بسته استاتیک HTML/JS است. این بسته وزن‌ها را در IndexedDB فراخوانی کرده و شیدرهای محاسباتی را برای هر بلوک ترنسفورمر نمونه‌سازی می‌کند و در نهایت یک تابع generate(prompt) را در اختیار رابط کاربری قرار می‌دهد.
موازنه عملکرد و محدودیت‌ها
سرعت این سیستم خیره‌کننده است، اما موازنه‌ها (Trade-offs) بسیار شدید هستند. مدل‌های MicroLLM (که در اینجا مدل‌های بین ۲۵ تا ۳۶۰ میلیون پارامتر تعریف شده‌اند) فاقد دانش گسترده جهانی مدل‌های پیشرو (Frontier Models) هستند. این مدل‌ها به‌جای هوش عمومی، برای کارایی در وظایف خاص (Task-specific) مهندسی شده‌اند.
داده‌های وب‌سایت stateofutopia.com نشان می‌دهد در حالی که یک مدل ۱۳۵ میلیونی ممکن است در برخی تست‌های عینی پیچیده شکست بخورد، اما در کارهای محدود و تخصصی عالی عمل می‌کند. در مقابل، برای کاربردهایی که به ظرفیت‌های پردازشی نامحدود نیاز دارند، مدل‌های زبانی با پارامتر نامحدود راهکارهای متفاوتی را برای بازنویسی وزن‌ها در لحظه ارائه می‌دهند. مزایای اصلی این رویکرد عبارتند از:
- حریم خصوصی: هیچ داده‌ای از دستورات (Prompts) هرگز دستگاه را ترک نمی‌کند، که برای صنایع تحت نظارت مانند بهداشت و درمان و امور مالی حیاتی است.
- هزینه صفر ابری: با بهره‌گیری از GPU کاربر نهایی، ظرفیت پردازش نامحدود (Infinite Concurrency) حاصل می‌شود و صورت‌حساب‌های API حذف می‌گردد.
- تأخیر بسیار کم: با حذف رفت‌وبرگشت‌های شبکه، دستیابی به زمان زیر ۱۰ میلی‌ثانیه برای تولید اولین توکن امکان‌پذیر است.
- غربالگری سریع: مدل‌های لبه می‌توانند قصد کاربر را تشخیص داده یا اسپم‌ها را به‌صورت محلی فیلتر کنند.
با این حال، وابستگی به سخت‌افزار همچنان یک مانع است. دستگاه‌های قدیمی (مثلاً GPUهای داخلی بدون پشتیبانی از WebGPU) باید به مسیرهای CPU برگردند که به‌شدت کندتر هستند یا ممکن است اصلاً اجرا نشوند. علاوه بر این، چون وزن‌های مدل به‌صورت عمومی برای کلاینت قابل دانلود است، حفاظت از مالکیت معنوی (IP) ضعیف‌تر از استقرار مدل‌ها در APIهای ابری است.
معماری «اول-لبه» (Edge-First)
شرکت Knowverse یک الگوی دو مرحله‌ای را برای هوش مصنوعی سازمانی پیشنهاد می‌کند. در این معماری، یک MicroLLM به‌عنوان یک پیش‌فیلتر با توان عملیاتی بالا عمل می‌کند. این مدل قصد کاربر را طبقه‌بندی کرده یا اسپم‌ها را به‌صورت محلی روی دستگاه فیلتر می‌کند. تنها پرس‌وجوهای باارزش یا پیچیده سپس به یک خط لوله بازیابی داخلی امن یا یک مدل ابری بزرگ‌تر هدایت می‌شوند.
در سناریوهای تولید بازیابی‌افزا (RAG)، مدل MicroLLM می‌تواند یک برچسب قصد (Intent Tag) کوتاه را به‌صورت محلی تولید کند. این برچسب برای کوئری زدن به یک ذخیره‌ساز برداری سمت سرور مانند Milvus یا pgvector استفاده می‌شود. این کار تضمین می‌کند که مدل بزرگ و سنگین LLM تنها زمانی فراخوانی شود که مرتبط‌ترین اسناد از قبل در دست باشند.
ملاحظات عملیاتی
استقرار این مدل‌ها نیازمند توجه به چندین محدودیت فنی است:
- تنوع دستگاه‌ها: تست‌ها باید روی کروم، اج و سافاری گسترده شود، زیرا هر یک WebGPU را به‌گونه‌ای متفاوت پیاده کرده‌اند. یک راهکار جایگزین (Fallback) مناسب (مثلاً استنتاج CPU مبتنی بر WebGL) برای مرورگرهای پشتیبانی‌نشده ضروری است.
- مدیریت کش: از آنجایی که محدودیت‌های ذخیره‌سازی IndexedDB در پلتفرم‌های مختلف متفاوت است، توسعه‌دهندگان باید یک سیاست حذف داده‌های قدیمی (LRU - Least Recently Used) را برای نگه داشتن مدل‌های پرکاربردتر پیاده کنند.
- مشاهده‌پذیری: باید از Performance API مرورگر برای ابزارگذاری تأخیر توکن، میزان بهره‌برداری از GPU و مصرف حافظه جهت برنامه‌ریزی ظرفیت استفاده کرد.
- ممیزی امنیتی: زنجیره تأمین مدل باید تأیید شود. بررسی‌های فنی Knowverse می‌تواند منشأ نقاط بازرسی کوانتیده را ارزیابی کند تا از انطباق شرکتی و امنیتی اطمینان حاصل شود.
کاربردهای استراتژیک
انتخاب بین MicroLLM و مدل ابری به مورد استفاده خاص بستگی دارد:
- تکمیل خودکار (Autocomplete) آنی: یک مدل محلی ۲۵ میلیون پارامتری به‌دلیل نیازهای حیاتی در تأخیر و ماهیت محدود وظیفه، ترجیح داده می‌شود.
- غربالگری پشتیبانی مشتری: یک مدل لبه ۱۰۰ میلیون پارامتری می‌تواند قصد کاربر را طبقه‌بندی کند و سپس موارد مبهم را برای تولید متن کامل به ابر ارجاع دهد.
- خلاصه‌سازی اسناد حساس: مدل‌های محلی می‌توانند عبارات کلیدی را از اسناد خصوصی بدون تماس با APIهای خارجی استخراج کرده و آن‌ها را به یک خط لوله RAG داخلی تغذیه کنند.
- نویسندگی خلاق: مدل‌های ابری همچنان برتر هستند زیرا پایگاه دانش غنی‌تر آن‌ها بر نگرانی‌های مربوط به تأخیر غلبه می‌کند.
این چرخش به سمت عامل‌های «اول-لبه» نشان‌دهنده آینده‌ای است که در آن تولید توکن زیر ۵ میلی‌ثانیه برای مدل‌های زیر ۲۰۰ میلیون پارامتر به پیش‌فرض تبدیل می‌شود. با رایج‌تر شدن تراشه‌های سری M اپل و Xe اینتل، مرورگر از یک نمایش‌دهنده ساده به یک لایه اجرای قدرتمند هوش مصنوعی تکامل می‌یابد. برای تیم‌هایی که آماده نمونه‌سازی این استک هستند، Knowverse منابعی از چارچوب‌های ارزیابی LLM محلی تا گزارش‌های بررسی فنی برای اندازه‌گیری تأثیر امنیتی و هزینه انتقال استنتاج به کلاینت ارائه می‌دهد.
گام بعدی شما
- بررسی سازگاری GPU دستگاه‌های کاربران هدف با استاندارد WebGPU.
- تست مدل‌های زیر ۲۰۰ میلیون پارامتر برای وظایف طبقه‌بندی (Classification) به‌جای تولید متن پیچیده.
- پیاده‌سازی معماری دو مرحله‌ای (فیلتر محلی $ \rightrightarrows $ پردازش ابری) برای کاهش هزینه‌های API.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو