«خوشه‌بندی وزن‌ها در جداول جست‌وجو»؛ راهکار جدید برای بهینه‌سازی حافظه

اگر امروز در حال بهینه‌سازی یک مدل هوش مصنوعی برای آیفون هستید، احتمالاً با این چالش روبرو شده‌اید که یا باید حجم دانلود را فدای کیفیت کنید یا برعکس. طبق بررسی‌های فنی منتشر شده در ۱۲ اوت ۲۰۲۶ درباره‌ی coremltools، انتخاب اشتباه خانواده‌ی فشرده‌سازی — به‌ویژه ترجیح کوانتش خطی بر پالت‌سازی — می‌تواند منجر به اتلاف شدید منابع مهندسی و افت عملکرد مدل شود.

بسیاری از توسعه‌دهندگان به کوانتش (Quantization) — شبیه به تبدیل یک عکس با میلیون‌ها رنگ به یک عکس با ۱۶ رنگ محدود برای کاهش حجم — تنها به عنوان فرآیند تبدیل اعداد اعشاری به اعداد صحیح نگاه می‌کنند. اما اکوسیستم اپل دو مسیر مجزا ارائه می‌دهد: یکی برای کاهش حجم فایل روی دیسک و دیگری برای افزایش سرعت محاسبات. برای اکثر توسعه‌دهندگان، گلوگاه اصلی، مقدار داده‌ای است که از حافظه به پردازنده منتقل می‌شود، نه توان محاسباتی خام.

تصور کنید وزن‌های یک مدل مانند چشم‌اندازی وسیع از اعداد باشند. کوانتش خطی با این چشم‌انداز مانند یک شبکه‌ی سخت و منظم برخورد می‌کند و یک بازه‌ی اعشاری را با استفاده از یک مقیاس (Scale) و یک نقطه‌ی صفر (Zero Point) روی یک بازه‌ی عدد صحیح نگاشت می‌کند. این روش رزولوشن یکسانی را به فضاهای خالی و قله‌های شلوغ اختصاص می‌دهد. در مقابل، پالت‌سازی مانند یک پالت رنگ هوشمند عمل می‌کند؛ این روش نقاطی را که وزن‌ها در آنجا خوشه‌بندی شده‌اند شناسایی کرده و رزولوشن محدود خود را دقیقاً به همان مقادیر اختصاص می‌دهد.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی مدل‌های لبه اشاره کردیم، مدیریت حافظه در دستگاه‌های موبایل تعیین‌کننده‌ی نهایی تجربه کاربری است.

سازوکار پالت‌سازی

پالت‌سازی با خوشه‌بندی وزن‌های تنسور در $2^{nbits}$ مقدار متمایز عمل می‌کند. به جای ذخیره‌ی هر وزن به صورت یک عدد اعشاری کامل، سیستم یک جدول جست‌وجوی واحد (پالت) ذخیره می‌کند و هر وزن را با یک شاخص (Index) کوچک جایگزین می‌کند که به آن جدول اشاره دارد.

• یک پالت ۴ بیتی تنها ۱۶ مقدار اعشاری را ذخیره می‌کند و برای هر وزن یک شاخص ۴ بیتی می‌سازد.
• این رویکرد از این واقعیت بهره می‌برد که وزن‌های شبکه‌های آموزش‌دیده معمولاً نزدیک به صفر متمرکز هستند و یک «دم» بلند (Long Tail) دارند.
• به دلیل استفاده از کی-میانگین (k-means) — روشی شبیه به دسته‌بندی مشتریان یک فروشگاه بر اساس رفتارهای مشابه — این متد رزولوشن خود را جایی صرف می‌کند که داده‌ها واقعاً حضور دارند. این امر خطا را در مقایسه با یک شبکه‌ی خطی که بیشتر سطوح خود را روی بازه‌های خالی هدر می‌دهد، کاهش می‌دهد.
• در یک پهنای بیت یکسان، پالت‌سازی معمولاً صحت مدل را بهتر از کوانتش خطی حفظ می‌کند.

کوانتش وزن در برابر کوانتش فعال‌ساز

باید توجه داشت که پالت‌سازی یک فشرده‌سازی «فقط-وزن» (Weight-only) است. این روش نحوه‌ی ذخیره‌سازی پارامترها روی دیسک و جابه‌جایی آن‌ها در حافظه را تغییر می‌دهد، اما محاسبات زمان استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه به خودِ آشپزی و نه دوره‌ی آموزش آشپز — را تغییر نمی‌دهد. مقادیر پیش از ضرب، دوباره به اعداد اعشاری تبدیل (Expand) می‌شوند.

این ابزار زمانی درست است که محدودیت شما حجم دانلود یا مقدار بایت‌هایی باشد که در هر استنتاج باید از حافظه به پردازنده منتقل شوند. اما اگر هدف شما افزایش سرعت محاسبات (Arithmetic Throughput) است، پالت‌سازی ابزار مناسبی نیست. در واقع، برای درک بهتر این تفاوت، باید به تاثیر معماری سخت‌افزاری بر سرعت و هزینه مدل‌ها توجه کرد تا مشخص شود کدام گلوگاه سخت‌افزاری در اولویت است.

اگر هدف اصلی شما محاسبات سریع‌تر است و نه لزوماً فایل کوچک‌تر، خانواده‌ی کوانتش خطی فعال‌ساز (Linear Activation Quantization) گزینه لازم است. این متد به داده‌های کالیبراسیون نیاز دارد و معمولاً برای یک پهنای بیت اسمی یکسان، هزینه بیشتری از نظر افت صحت مدل دارد.

قواعد تصمیم‌گیری برای محدودیت‌های مدل

انتخاب متد مناسب به نوع محدودیتی که با آن روبرو هستید بستگی دارد:

• حجم دانلود یا اشغال حافظه بالا: اگر مدل در حافظه جا می‌شود اما حجم دانلود اپلیکیشن را بیش از حد زیاد می‌کند، یا اگر مدل در حافظه‌ی دستگاه‌های قدیمی‌تر جا نمی‌شود، از پالت‌سازی با کمترین بیت‌های ممکن (تا جایی که صحت حفظ شود) استفاده کنید.
• اجرای کند: اگر مدل از قبل کوچک است اما صرفاً سرعت اجرای آن پایین است، نه پالت‌سازی و نه کوانتش خطی کمک زیادی نمی‌کنند. در این حالت راهکار، استفاده از یک معماری کوچک‌تر است، نه نمایش کوچک‌تر از همان معماری.

تله‌ی هدف استقرار (Deployment Target)

یکی از رایج‌ترین نقاط شکست در coremltools، تنظیم minimum_deployment_target است. اپل قابلیت‌های فشرده‌سازی را بر اساس نسخه‌ی سیستم‌عامل محدود می‌کند. نمایش وزن‌های پالت‌شده برای مدل‌های mlprogram به iOS 16 یا macOS 13 نیاز دارد.

گزینه‌های پیشرفته‌تر مانند جداول جست‌وجوی ۸ بیتی و دانه‌بندی per_grouped_channel تنها در iOS 18 و macOS 15 در دسترس هستند. اگر توسعه‌دهنده هدف استقرار را پایین‌تر تنظیم کند، این قابلیت‌های بهینه به‌طور خاموش غیرفعال می‌شوند و منجر به خطاهای گیج‌کننده در تبدیل مدل می‌گردند. توسعه‌دهندگان باید نسخه‌ی نصب‌شده‌ی coremltools خود را با مستندات اپل برای آن نسخه‌ی خاص چک کنند، نه اینکه به یک راهنمای کلی تکیه کنند.

گردش‌کار پیاده‌سازی عملی

برای اجرای این فرآیند، توسعه‌دهندگان باید ابزارها را روی macOS نصب کنند (pip install coremltools). مراحل تبدیل و فشرده‌سازی روی مک انجام می‌شود، نه روی دستگاه. این فرآیند باید به دو خروجی مجزا تقسیم شود: یک مدل مرجع fp16 و یک نسخه‌ی فشرده.

۱. تبدیل مدل منبع به mlprogram با هدف مشخص (مثلاً ct.target.iOS18). این مدل fp16 را به عنوان مرجعی برای مقایسه‌های بعدی نگه دارید.
۲. اعمال cto.coreml.palettize_weights با استفاده از OpPalettizerConfig.
۳. تنظیم nbits (معمولاً ۴) و حالت mode روی "kmeans". حالت mode می‌تواند برای وزن‌هایی که از قبل گسسته هستند روی "unique" یا "uniform" تنظیم شود، اما kmeans پیش‌فرض برای فشرده‌سازی پس از آموزش است.
۴. استفاده از granularity="per_grouped_channel" با group_size ۱۶ برای دقت بیشتر.
۵. پیکربندی weight_threshold (پیش‌فرض ۲۰۴۸)؛ پالت‌سازی تنسورهای بسیار کوچک هزینه‌ی ایجاد یک جدول جست‌وجو را دارد اما صرفه‌جویی ناچیزی ایجاد می‌کند، لذا تنسورهای کوچک‌تر از این آستانه نادیده گرفته می‌شوند.

ضرورت اعتبارسنجی

کاهش حجم پیش‌بینی‌پذیر است — وزنی که ۱۶ بیت بود اکنون ۴ بیت می‌شود و فضای ذخیره‌سازی تقریباً به یک‌چهارم می‌رسد (منهای تنسورهای زیر آستانه و به‌علاوه‌ی جداول جست‌وجو). اما افت صحت پیش‌بینی‌پذیر نیست. فشرده‌سازی که به‌طور خاموش روی یک دسته‌ی خاص از ورودی‌ها شکست بخورد، خطرناک‌تر از عدم فشرده‌سازی است.

توسعه‌دهندگان باید خروجی‌های مدل fp16 و مدل ۴ بیتی را با ورودی‌های واقعی کالیبراسیون مقایسه کنند، نه با نویز تصادفی. نویز تصادفی به شکل متفاوتی از شبکه‌ها عبور می‌کند و می‌تواند شکست‌های بحرانی را پنهان کند. معیار پیشنهادی، فاصله‌ی کسینوسی (Cosine Distance) بین خروجی‌های اصلی و فشرده است.

اگر فاصله‌ی کسینوسی بیش از حد باشد، مسیر بازیابی به صورت سلسله‌مراتبی به این ترتیب است:

• افزایش nbits از ۴ به ۶ یا ۸.
• تغییر از per_tensor به per_grouped_channel با group_size کوچک‌تر.
• استثنا کردن لایه‌های خاص با استفاده از op_name_configs.
• در آخرین مرحله و به عنوان آخرین راهکار، بررسی آموزش آگاه از پالت‌سازی (Palettization-aware training).

اشتباهات رایج در اعتبارسنجی

تست روی مک تضمینی برای رفتار یکسان در آیفون نیست. متد predict در macOS از هر واحد محاسباتی که Core ML انتخاب کند استفاده می‌کند، اما دستگاه ممکن است مدل را به شکل متفاوتی بخش‌بندی (Partition) کند. بررسی نهایی روی سخت‌افزار واقعی اجباری است.

همچنین، چون .mlpackage یک دایرکتوری است، استفاده از os.path.getsize روی پوشه، حجم ورودی دایرکتوری را برمی‌گرداند نه حجم واقعی مدل را؛ توسعه‌دهندگان باید تمام فایل‌های داخلی دایرکتوری را پیمایش کنند تا عدد دقیقی به دست آورند.

سایر ملاحظات حیاتی:

• محدودیت‌های حافظه: پالت‌سازی فعال‌سازها یا حافظه‌ی میانی را کوچک نمی‌کند. مدلی که به دلیل کمبود حافظه (OOM) روی ورودی‌های طولانی کرش می‌کند، بعد از پالت‌سازی هم کرش خواهد کرد.
• افت غیریکنواخت: افت صحت یکنواخت نیست. ممکن است یک معیار کلی روی یک مجموعه‌ی داده‌ی مجزا ثابت بماند، اما یک دسته‌ی خاص یا توزیع ورودی خاص به‌شدت تخریب شود، زیرا خطا در جایی متمرکز می‌شود که توزیع وزن‌ها «دم بلند» داشته است. خروجی‌ها را به تفکیک کلاس یا برش (Slice)، به‌ویژه برای ورودی‌های نادر، مقایسه کنید.
• نسبت‌های غیرقابل پیش‌بینی: هیچ منبعی نسبت دقیق حجم یا صحت را منتشر نمی‌کند. نسبت حجم به این بستگی دارد که چه مقدار از جرم وزن‌ها در تنسورهای بالای آستانه قرار دارد (یک ویژگی معماری)، و صحت به داده‌های شما بستگی دارد.

این تغییر در رویکرد، تمرکز را از «چقدر می‌توانیم مدل را کوچک کنیم» به «چگونه توزیع خطا را اعتبارسنجی کنیم» منتقل می‌کند. با در نظر گرفتن مدل fp16 به عنوان یک مرجع دائمی، تیم‌ها می‌توانند از فرآیند کند تبدیل مجدد مدل در هر بار تست پهنای بیت یا تنظیمات دانه‌بندی جدید اجتناب کنند.

گام بعدی شما

• مدل‌های فعلی خود را با coremltools و متد kmeans پالت‌سازی کنید و افت صحت را با فاصله‌ی کسینوسی بسنجید.
• هدف استقرار (Deployment Target) را به iOS 18 ارتقا دهید تا از دانه‌بندی per_grouped_channel برای دقت بالاتر بهره ببرید.
• برای مدل‌هایی که همچنان با خطای OOM مواجه می‌شوند، به جای فشرده‌سازی، روی کاهش ابعاد معماری تمرکز کنید.

اما بهینه‌سازی‌های سخت‌افزاری در لایه‌های پایین‌تر حتی پیچیده‌تر است — به تحلیل ما درباره‌ی شتاب‌دهنده‌های NPU در تراشه‌های جدید اپل مراجعه کنید.