تصور کنید یک دستیار هوش مصنوعی قدرتمند داشته باشید که حتی بدون اتصال به اینترنت و بدون ارسال یک بیت داده به سرورهای خارجی، در مرورگر شما اجرا شود. این دیگر یک رویای آینده نیست، بلکه دستاوردی است که WebLLM آن را به واقعیت تبدیل کرده است. اجرای یک مدل زبانی بزرگ (LLM) دیگر نیازمند یک سرور ابری عظیم یا نصب پیچیده نرمافزارهای محلی در سیستمعامل نیست.
این موتور استنتاج که توسط جامعه MLC-AI توسعه یافته، بار محاسباتی را از دوش ارائهدهنده به واحد پردازش گرافیکی (GPU) کاربر منتقل میکند — شبیه به موتور یک ماشین که بهجای سوختگیری از یک مخزن مرکزی، از باتری داخلی خودش استفاده میکند. در واقع، نوع معماری سختافزاری مورد استفاده، مستقیماً بر سرعت و هزینه استنتاج اثر میگذارد، موضوعی که در تحلیل معماری سختافزاری و تفاوتهای GPU و ASIC به تفصیل بررسی کردهایم. طبق مستندات github.com، این سیستم با استفاده از استاندارد WebGPU، اجرای مدلها را در محیط مرورگر شتاب میدهد و مانع از خروج دادههای حساس کاربر از دستگاه محلی میشود. این معماری باعث میشود که موانع اصلی حریم خصوصی برای پذیرش هوش مصنوعی در سازمانها و شرکتهای بزرگ برطرف شود.
همانطور که در تحلیل قبلی ما دربارهی vLLM و کاهش هزینههای استنتاج در محیطهای ابری برای مدلهایی مانند Grok-2 اشاره کردیم، WebLLM مسیر متفاوتی را برگزیده است؛ بهجای بهینهسازی خوشههای سرور، این پروژه محیط مرورگر را برای مدیریت وزنها (Weights) و محاسبات محلی بهینه میکند تا هزینه ابری را بهطور کامل حذف کند.
موتور فنی و سازگاری
به نقل از مستندات پروژه، WebLLM مکمل MLC LLM است و اجازه میدهد مدلها در محیطهای سختافزاری متنوع مستقر شوند. این موتور از طراحی ماژولار بهره میبرد که اجازه میدهد بهصورت یک بسته npm یا از طریق CDN در پروژهها ادغام شود.
نکته کلیدی این موتور، سازگاری کامل با OpenAI API است. این یعنی توسعهدهندگان میتوانند از همان الگوهای آشنا برای استریم کردن پاسخها، حالت JSON (JSON-mode) و تعیین Seed استفاده کنند، در حالی که مدل بهصورت کاملاً محلی اجرا میشود. این سازگاری شامل کنترل در سطح Logit و توانایی استفاده از یک API واحد برای هر مدل متنباز پشتیبانی شده است.
مدلهای پشتیبانی شده و ادغام
این پلتفرم طیف گستردهای از خانوادههای مدل استاندارد صنعت را پشتیبانی میکند و کاربران میتوانند مدلهای زیر را بهصورت بومی مستقر کنند:
- Llama: شامل نسخههای Llama 3، Llama 2 و Hermes-2-Pro-Llama-3.
- Phi: پشتیبانی از Phi 3، Phi 2 و Phi 1.5.
- Gemma: بهویژه مدل Gemma-2B.
- Mistral: شامل Mistral-7B-v0.3، Hermes-2-Pro-Mistral-7B، NeuralHermes-2.5-Mistral-7B و OpenHermes-2.5-Mistral-7B.
- Qwen (通义千问): پشتیبانی از Qwen2 در ابعاد ۰.۵، ۱.۵ و ۷ میلیارد پارامتری.
برای کسانی که نیازهای خاصی دارند، این پلتفرم امکان ادغام مدلهای سفارشی را فراهم میکند. توسعهدهندگان میتوانند مدلهای خود را به فرمت MLC کامپایل کرده و یک URL برای آرتیفکتهای مدل (وزنها و متادیتا) و کتابخانه WebAssembly (WASM) مربوطه — که همان فایل اجرایی شتابدهنده محاسبات است — ارائه دهند.
در بسیاری از موارد، یک نسخه جدید از وزنهای مدل میتواند از کتابخانه مدل موجود استفاده کند. برای مثال، مدل NeuralHermes-Mistral میتواند از کتابخانه استاندارد Mistral استفاده کند که این امر استقرار نسخههای Fine-tune شده را بسیار سادهتر میکند.
مکانیزمهای بهینهسازی عملکرد
برای جلوگیری از هنگ کردن رابط کاربری (UI) هنگام محاسبات سنگین، WebLLM از چندین استراتژی تردینگ (Threading) استفاده میکند.
نخست، استفاده از Dedicated Web Workers است. با انتقال فرآیند تولید توکن به یک ترد Worker مجزا از طریق WebWorkerMLCEngineHandler، رابط کاربری اصلی پاسخگو باقی میماند در حالی که GPU در حال پردازش توکنها است. این کار تضمین میکند که محاسبات در ترد Worker باعث اختلال در تجربه بصری کاربر نشود.
دوم، پشتیبانی از Service Worker است. این قابلیت برای تجربه کاربر حیاتی است زیرا مانع از آن میشود که مرورگر در هر بار بازدید از صفحه، کل مدل را دوباره بارگذاری کند و بهطور قابل توجهی تجربه آفلاین را بهینه میکند.
از آنجایی که مرورگر چرخه حیات Service Worker را مدیریت میکند و میتواند آن را بدون اطلاع میبندد، ServiceWorkerMLCEngine بهطور دورهای رویدادهای heartbeat ارسال میکند تا ترد را زنده نگه دارد. توسعهدهندگان میتوانند این مورد را از طریق تنظیمات keepAliveMs و missedHeatbeat مدیریت کنند، هرچند مدیریت صحیح خطاها همچنان ضروری است.
ذخیرهسازی و امنیت
بارگذاری مدلهای حجیم در مرورگر نیازمند کشینگ بهینه است. WebLLM چهار پسزمینه برای کش از طریق AppConfig.cacheBackend پشتیبانی میکند:
- Browser Cache API: تنظیمات پیشفرض برای اکثر کاربران.
- IndexedDB: یک پایگاهداده قدرتمند مبتنی بر مرورگر.
- Origin Private File System (OPFS): برای دسترسی با کارایی بالا به فایلها. این مورد از طریق
appConfig.opfsAccessModeبه صورت "auto"، "sync" (نیازمند هندلهای دسترسی همزمان) یا "async" (پیشفرض) قابل تنظیم است. - Cross-Origin Storage API: یک افزونه آزمایشی برای کروم که نیازمند یک افزونه مرورگر سازگار است؛ در غیر این صورت، WebLLM به کش پیشفرض باز میگردد. توجه داشته باشید که این پسزمینه از حذف برنامهنویسی شدهی tensor-cache پشتیبانی نمیکند.
امنیت این سیستم از طریق هشهای Subresource Integrity (SRI) تضمین میشود. توسعهدهندگان میتوانند هشهای SHA-256، SHA-384 یا SHA-512 را برای فایلهای تنظیمات (config)، WASM و توکنایزر مشخص کنند.
اگر فایل دانلود شده با هش مطابقت نداشته باشد، موتور بهطور پیشفرض (زمانی که onFailure روی "error" باشد) خطای IntegrityError صادر میکند تا از اجرای وزنهای دستکاری شده جلوگیری شود. همچنین میتوان آن را روی "warn" تنظیم کرد تا فقط مشکل را ثبت کرده و به اجرا ادامه دهد.
پیادهسازی برای توسعهدهندگان
ادغام این موتور بهگونهای طراحی شده که Plug-and-Play باشد. توسعهدهنده میتواند بسته را از طریق npm install @mlc-ai/web-llm یا yarn add @mlc-ai/web-llm یا pnpm install @mlc-ai/web-llm نصب کند.
همچنین میتوان آن را مستقیماً از طریق CDN با آدرس https://esm.run/@mlc-ai/web-llm وارد کرد که آن را با پلتفرمهای ابری مانند jsfiddle.net، Codepen.io و Scribbler سازگار میکند.
مقداردهی اولیه از طریق تابع فکتوری CreateMLCEngine(selectedModel) انجام میشود. این تابع دو مرحله را طی میکند: ایجاد همزمان (Synchronous) نمونه موتور و بارگذاری غیرهمزمان (Asynchronous) مدل. از آنجایی که بارگذاری نیازمند دانلود فایلهای حجیم است، توصیه میشود از initProgressCallback برای بهروزرسانی کاربر درباره پیشرفت بارگذاری استفاده شود.
برای تعاملات بلادرنگ، موتور از استریم کردن پاسخهای چت پشتیبانی میکند. با ارسال stream: true به فراخوانی API، مرورگر یک AsyncGenerator دریافت میکند که تکههای متن را در لحظه تولید بازمیگرداند. این قابلیت با stream_options: { include_usage: true } برای ردیابی میزان مصرف توکن در تکه نهایی قابل ارتقا است.
قابلیتهای پیشرفته
WebLLM فراتر از یک چت ساده است و ویژگیهای سطح بالایی برای اپلیکیشنهای پیچیده ارائه میدهد:
- تولید JSON ساختاریافته: پشتیبانی از حالت JSON پیشرفته. این قابلیت در بخش WebAssembly کتابخانه مدل پیاده شده تا هنگام تولید خروجی بر اساس یک JSON Schema سفارشی، بیشترین کارایی حاصل شود.
- فراخوانی تابع (Function Calling): موتور پشتیبانی اولیهای از فراخوانی توابع از طریق فیلدهای
toolsوtool_choiceو همچنین فراخوانی دستی توابع برای حداکثر انعطافپذیری ارائه میدهد. - افزونههای کروم: WebLLM میتواند برای ساخت افزونههای مرورگر استفاده شود. مثالها شامل افزونههای ساده و نسخههای پیشرفتهای است که از WebGPU service worker برای باقی ماندن در پسزمینه استفاده میکنند.
جزئیات ساخت و اجرا
در حالی که اکثر کاربران از بسته npm استفاده میکنند، توسعهدهندگان میتوانند WebLLM را از سورس با دستور npm run build بسازند. زمان اجرا بهشدت به TVMjs وابسته است.
ساخت TVMjs از سورس نیازمند کامپایلر Emscripten است (بهطور خاص نسخه ۳.۱.۵۶ توصیه میشود تا از خطاهای LinkError مربوط به wasi_snapshot_preview1 جلوگیری شود). فرآیند ساخت شامل کلون کردن مخزن mlc-ai/relax و استفاده از یک شل یونیکسی (macOS/Linux یا Git Bash/WSL در ویندوز) برای مدیریت وابستگیها است.
بررسی عمیق: جزئیات پیادهسازی
برای درک بهتر انعطافپذیری موتور، بررسی مکانیزمهای مدیریت مدل و پیکربندی زمان اجرا مفید است.
مکانیزمهای بارگذاری مدل:
- الگوی فکتوری: تابع
CreateMLCEngineتنظیمات را ساده میکند، اما توسعهدهندگان میتوانند مستقیماً از کلاسMLCEngineاستفاده کنند. این اجازه میدهد ابتدا یک نمونه بهصورت همزمان ساخته شود و سپس متدengine.reload(selectedModel)بهصورت غیرهمزمان فراخوانی شود. - ردیابی پیشرفت: به دلیل حجم بالای وزنهای مدل،
initProgressCallbackبرای ارائه بازخورد بصری به کاربر در طول دانلود اولیه ضروری است. - لیست مدلها: مدلهای موجود از طریق
prebuiltAppConfig.model_listقابل دسترسی هستند که حاوی متادیتای لازم برای دریافت وزنهای صحیح توسط موتور است. - مدیریت غیرهمزمان: بارگذاری مدلها فرآیندی غیرهمزمان است که در اولین اجرا (بدون کش) زمانبر است؛ توسعهدهندگان باید این فراخوانیها را بهدرستی مدیریت کنند تا UI مسدود نشود.
ظرافتهای پسزمینه کش:
- در دسترس بودن OPFS: اگر "opfs" در محیطی انتخاب شود که از Origin Private File System پشتیبانی نمیکند، موتور خطای در دسترس نبودن OPFS را صادر میکند.
- مدیریت Cross-Origin: پسزمینه "cross-origin" توسط یک افزونه مرورگر مدیریت میشود. به همین دلیل، پاک کردن tensor-cache باید از طریق افزونه انجام شود و نه بهصورت برنامهنویسی شده.
- جایگزینهای پیشفرض: WebLLM منعطف طراحی شده است؛ اگر پسزمینه آزمایشی cross-origin موجود نباشد، بهطور خودکار به کش پیشفرض مرورگر باز میگردد.
- حالتهای دسترسی: هنگام استفاده از OPFS، مقدار
appConfig.opfsAccessModeمیتواند برای دسترسیهای همزمان (در صورت پشتیبانی) روی "auto" یا برای الزام به آنها روی "sync" تنظیم شود.
گردش کار تأیید یکپارچگی:
- تولید هش: توسعهدهندگان میتوانند هشهای SRI مورد نیاز را با دستورات OpenSSL تولید کنند. برای مثال، دستور
openssl dgst -sha256 -binary <file> | openssl base64 -A | sed 's/^/sha256-/'یک هش SHA-256 ایجاد میکند. - دامنه تأیید: تأیید یکپارچگی اختیاری و جزئی است. توسعهدهندگان میتوانند انتخاب کنند که فقط تنظیمات، فقط کتابخانه WASM یا فقط فایلهای توکنایزر خاصی را تأیید کنند.
- مدیریت خطا: پارامتر
onFailureبه توسعهدهنده اجازه میدهد بین توقف کامل (IntegrityError) یا یک هشدار ساده انتخاب کند. - الگوریتمهای پشتیبانی شده: سیستم برای پوشش امنیتی جامع از SHA-256، SHA-384 و SHA-512 پشتیبانی میکند.
پیکربندی مدل سفارشی:
- URLهای آرتیفکت: مدلهای سفارشی به یک URL برای وزنها (
model) و یک URL برای فایل اجرایی WASM (model_lib) نیاز دارند. - بازنویسی پارامترها: هنگام مقداردهی اولیه یک مدل سفارشی، توسعهدهندگان میتوانند
chatOptsرا برای بازنویسی تنظیمات پیشفرض (مانند تنظیمrepetition_penaltyروی ۱.۰۱) ارسال کنند. - اشتراک کتابخانه: چندین نسخه از یک مدل (مثلاً کوانتیزاسیونهای مختلف از یک مدل پایه) میتوانند از یک
model_libواحد استفاده کنند تا پهنای باند و فضای ذخیرهسازی ذخیره شود. - فرمت MLC: WebLLM از آرتیفکتها و جریان کاری MLC LLM استفاده میکند که انتقال از محیط اجرای بومی (Native) به محیط مرورگر را بدون درز میکند.
TVMjs و محیط ساخت:
- الزامات Emscripten: برای ساخت از سورس، آخرین نسخه emsdk مورد نیاز است، هرچند نسخه ۳.۱.۵۶ بهطور خاص برای جلوگیری از خطاهای import مربوط به
proc_exitدرwasi_snapshot_preview1توصیه میشود. - کلون کردن وابستگیها: فرآیند ساخت نیازمند کلون کردن
https://github.com/mlc-ai/relaxدر مسیر3rdparty/tvm-unityبا فلگ--recursiveاست تا از نبود هدرهایی مانندdlpack/dlpack.hجلوگیری شود. - تطبیق نسخه: نسخههای خاص npm از WebLLM به کامیتهای خاصی از
apache/tvmیاmlc-ai/relaxوابسته هستند و نه لزوماً به آخرین نسخه (HEAD)، همانطور که در PRهای تغییر نسخه (مثلاً نسخه ۰.۲.۵۲) ذکر شده است. - باندلینگ: از Parcelv2 برای باندل کردن مثالها استفاده میشود. توسعهدهندگان ممکن است نیاز داشته باشند
package.jsonرا ویرایش کنند تا در صورت عدم ردیابی تغییرات دایرکتوری والد، بازسازی (rebuild) را فعال کنند.
تحلیل: انتقال به لبه (The Shift to the Edge)
WebLLM نشاندهنده یک تغییر بنیادین در دینامیک قدرت هوش مصنوعی است. با انتقال استنتاج به مرورگر، «هزینه هوشمندی» از صورت صورتحساب API توسعهدهنده به سختافزار کاربر تغییر میکند. این امر دسترسی به هوش مصنوعی را برای کسانی که دارای GPUهای توانمند هستند دموکراتیزه میکند و در عین حال تأخیر (Latency) و خطرات حریم خصوصی مرتبط با رفتوبرگشت دادهها به ابر را حذف میکند.
برای کاربر عادی، این به معنای دستیارهای هوش مصنوعی است که بهصورت آفلاین کار میکنند و حاکمیت کامل بر دادهها را تضمین میکنند. برای توسعهدهندگان، این یک دستهبندی جدید از اپلیکیشنهای هوش مصنوعی «بدون بکاند» (Zero-backend) را باز میکند که در آن مرورگر تنها پیشنیاز برای یک تجربه کامل LLM است.
گام بعدی شما
- برای تجربه قدرت تولید JSON در مرورگر، همین حالا به JSON Playground پروژه WebLLM در HuggingFace مراجعه کنید تا ببینید تولید ساختاریافته در مرورگر چگونه عمل میکند.
- اگر توسعهدهنده هستید، مدلهای کوچکتر مانند Phi-3 را برای کاهش زمان بارگذاری اولیه در اپلیکیشن خود تست کنید.
- تغییرات استاندارد WebGPU را دنبال کنید، زیرا بهروزرسانیهای آتی مرورگرها احتمالاً اجرای مدلهای حتی بزرگتر را برای اجرای محلی ممکن میسازد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.




گفتگو