تا همین یکی دو سال پیش، جواب هر پرسش هوش مصنوعی یک مسیر داشت: کلود. پرسش می‌رفت، مدل بزرگ در دیتاسنتر پاسخ می‌داد و شما منتظر می‌ماندید. اما صحنه عوض شده است. مدل‌هایی با یک تا سه میلیارد پارامتر — همان مدل‌های زبانی کوچک یا SLM — آن‌قدر خوب شده‌اند که بسیاری از کارهای روزمره را بدون خروج از دستگاه انجام می‌دهند: خلاصه‌ی نوتیفیکیشن، پاسخ به پرسش روی اسناد شخصی، تبدیل گفتار به فرمان، حتی کدنویسی کمکی. این مطلب یک مرور نظام‌مند است از سه خانواده‌ی تکنیکی که SLM را روی دستگاه ممکن می‌کنند — فشرده‌سازی، کوانتیزاسیون و استنتاج بهینه — با زبان ساده و با یک چک‌لیست انتخاب در پایان.
چرا اصلاً لبه؟
چهار دلیل واقعی، نه شعار: تأخیر — رفت‌وبرگشت شبکه چند ده تا چند صد میلی‌ثانیه هزینه دارد؛ برای رابط‌های صوتی و فراخوانی ابزار در حلقه‌ی عامل‌ها، این تأخیر حس می‌شود. حریم خصوصی — داده‌ی کاربر هرگز از دستگاه خارج نمی‌شود؛ برای اسناد شخصی و کارهای حساس یک مزیت تصمیم‌گیر است. هزینه — پردازش محلی بهای توکن ندارد؛ در محصولی با میلیون‌ها درخواست کوچک، این یعنی اقتصاد متفاوت. و آفلاین — سرویس شما با قطعی اینترنت نمی‌میرد.
در مقابل یک هزینه‌ی واقعی دارید: سقف سخت‌افزار. رم موبایل چند گیگابایت است، باتری محدود است و تراشه با GPU دیتاسنتر قابل مقایسه نیست. کل مهندسی لبه یعنی ساختن بیشترین کیفیت در همین سقف.
سه خانواده‌ی تکنیک
۱. فشرده‌سازی مدل موجود: مدل بزرگ را می‌گیرید و بدون بازآموزی کامل، کوچکش می‌کنید — کوانتیزاسیون، هرس وزن‌های بی‌اثر، ترکیب وزن‌های همسایه. ارزان و سریع است، اما کیفیت را تا جایی می‌برد که ساختار مدل اجازه دهد. ۲. مدلِ از پایه کوچک: مدل‌هایی که از ابتدا برای کوچکی طراحی و آموزش دیده‌اند — معماری بهینه، داده‌ی تمیز، و تقطیر دانش از مدل‌های بزرگ. این‌ها در اندازه‌ی خودشان معمولاً از نسخه‌ی فشرده‌شده‌ی یک مدل بزرگ بهتر عمل می‌کنند. ۳. استنتاج بهینه: وزن فشرده کافی نیست؛ نحوه‌ی خواندن و اجرای وزن‌ها هم نصف ماجراست که در ادامه می‌بینیم.
روی لبه، مدل خوب یعنی مدلِ متناسب با دستگاه — نه کوچک‌ترینِ بازار، نه بزرگ‌ترینِ بنچمارک.
کوانتیزاسیون در عمل
وزن‌های مدل به‌طور پیش‌فرض با ۱۶ بیت ذخیره می‌شوند؛ کوانتیزاسیون همان اعداد را با دقت کمتر — ۸ بیت یا ۴ بیت — بازنمایی می‌کند. حساب ساده است: کوانتیزاسیون ۸ بیتی حجم را نصف، ۴ بیتی یک‌چهارم می‌کند و سرعت را هم معمولاً بالا می‌برد، چون داده‌ی کمتر جابه‌جا می‌شود. تجربه‌ی رایج این است: ۸ بیت تقریباً بی‌درد است و تفاوت کیفیت حس نمی‌شود؛ ۴ بیت مرز باریک‌تری دارد — روی وظایف عمومی مثل خلاصه و گفتگو معمولاً قابل‌قبول است، اما در استدلال چندمرحله‌ای و ریاضی دقیق ممکن است لیز بخورد. قاعده‌ی عملی: روی وظیفه‌ی خودتان تست کنید، نه روی عدد بنچمارک عمومی؛ افت کیفیت هر مدل با دیگری فرق دارد.
تقطیر: کوچکِ آموزش‌دیده بهتر از بزرگِ فشرده است
یک یافته‌ی تکرارشونده: مدل کوچکی که از ابتدا با خروجی و توزیع جواب‌های یک مدل بزرگ بزرگ شده، در همان اندازه از مدل بزرگِ کوانتیزه‌شده جلو می‌زند. دلیلش این است که تقطیر فقط جواب را کپی نمی‌کند؛ «شکل فکر کردن» معلم را هم منتقل می‌کند. برای دامنه‌ی خاص، این مسیر حتی جذاب‌تر است: یک SLM عمومی را روی داده‌ی تولیدشده توسط مدل بزرگ برای حوزه‌ی خودتان تنظیم کنید و عملاً متخصصی کوچک بسازید. ابزارش همان تنظیم دقیق استاندارد است — و برای شروع، LoRA کفایت می‌کند.
نیمه‌ی دوم ماجرا: موتور استنتاج
روی دستگاه، گلوگاه اغلب محاسبه نیست؛ جابه‌جایی وزن‌ها از حافظه به واحد پردازش است. موتورهای استنتاج مدرن سه کار اصلی می‌کنند: اجرای fused عملیات‌ها به‌جای زنجیره‌ی طولانی، مدیریت پنجره‌ی زمینه و کش‌کردن هوشمند حالت‌های میانی، و بهره‌گیری از واحد درست سخت‌افزار — NPU تراشه اگر هست، وگرنه GPU یا CPU. دو تصمیم عملی هم دارید: پنجره‌ی زمینه را واقع‌بینانه انتخاب کنید — زمینه‌ی بزرگ یعنی حافظه و انرژی بیشتر — و حداکثر اندازه‌ی پاسخ را محدود کنید؛ هر دو مستقیم روی سرعت اثر می‌گذارند.
جمع‌بندی: چک‌لیست چهار سؤالی
پیش از انتخاب مدل برای اجرای روی دستگاه، چهار سؤال را صریح جواب بدهید: ۱) وظیفه‌ی من چقدر سخت است؟ خلاصه و دسته‌بندی با مدل کوچک حل می‌شود؛ استدلال عمیق شاید اصلاً برای لبه نباشد. ۲) کوانتیزاسیون ۴ بیتی روی وظیفه‌ی خودم چه افت کیفیت می‌دهد؟ تست کنید، حدس نزنید. ۳) آیا تقطیر دامنه‌ای، مدل کوچک مرا برای کار خودم کافی می‌کند؟ اغلب جواب بله است. ۴) پنجره‌ی زمینه و بودجه‌ی حافظه‌ام چقدر است؟ برای مقایسه‌ی ساختاریافته‌ی گزینه‌ها راهنمای انتخاب مدل را ببینید و حساب هزینه‌ی بخش کلودی را در راهنمای هزینه‌ی API. برای تجربه‌ی عملی روی کار واقعی، یک حساب بسازید.