«مهاری برای مدیریت حافظه»؛ نقش اندازهٔ گروه در کوانتش مدل‌ها

یک مدل ۷۰ میلیارد پارامتری می‌تواند به‌راحتی روی یک GPU با ۴۸ گیگابایت حافظه جای بگیرد یا کل سیستم شما را به دلیل کمبود حافظه متوقف کند؛ تفاوت تنها در یک تنظیمات است: اندازهٔ گروه (Group Size). در ۱۵ اوت ۲۰۲۶، یک تحلیل فنی عمیق در dev.to فاش کرد که انتخاب بین اندازه‌های ۳۲، ۶۴ و ۱۲۸، یک هزینهٔ ریاضی قابل محاسبه است و نه یک توصیهٔ تجربی یا افسانه‌های رایج در جامعهٔ توسعه‌دهندگان.

بسیاری از توسعه‌دهندگان با اندازهٔ گروه مثل یک پیچ تنظیم کیفیت برخورد می‌کنند که هزینه‌ای نامعلوم و مرموز دارد. در واقع، این مقدار اندازه‌گیری مستقیم بیت‌ها به ازای هر وزن است. این سازوکار هستهٔ اصلی فشرده‌سازی مدل‌های عظیم برای میزبانی شخصی (Local Hosting) است. این موضوع بر پایه همان چالش‌های حافظه‌ای است که پیش‌تر در پوشش خود درباره‌ی دلیل اینکه چرا کوانتش مدل‌های زبانی بزرگ (LLMs) گاهی حافظه بیشتری نسبت به خودِ استنتاج مصرف می‌کند، بررسی کردیم.

درک سازوکار گروه‌بندی

کوانتش (Quantization) — شبیه تبدیل یک عکس باکیفیت به فرمت JPEG است که حجم را کم می‌کند اما اگر زیاده‌روی شود، پیکسل‌ها به‌صورت مربع‌های زشت دیده می‌شوند — در اینجا بر روی وزن‌ها اعمال می‌شود. برای درک این سازوکار، تصور کنید یک وزن ۴ بیتی صرفاً یک عدد صحیح ساده بین ۰ تا ۱۵ است. برای تبدیل این عدد صحیح به یک عدد واقعی (Floating Point)، سیستم به دو مقدار کمکی نیاز دارد: «مقیاس» (Scale) که تعیین می‌کند هر گام عددی چقدر ارزش دارد، و «نقطهٔ صفر» (Zero Point) که مشخص می‌کند کدام عدد صحیح معادل صفر واقعی است. یک «گروه» در واقع مجموعه‌ای از وزن‌هاست که یک مقیاس و یک نقطهٔ صفر مشترک را به اشتراک می‌گذارند.

طبق مستندات GPTQConfig یا AwqConfig، وقتی group_size=128 را تنظیم می‌کنید، ۱۲۸ وزن متوالی در بُعد ورودی (Input Dimension) یک ردیف، این متاداده‌ها را به اشتراک می‌گذارند. جهت این گروه‌بندی بسیار حیاتی است: این عملیات در امتداد «بُعد کاهش» (Reduction Dimension) انجام می‌شود. این بدان معناست که تمام وزن‌های موجود در یک گروه، کانال‌های ورودی مختلفی از یک خروجی واحد را ضرب می‌کنند. از آنجایی که شدت فعال‌سازی‌ها (Activation Magnitudes) در این بُعد خاص به‌شدت متغیر است، اندازهٔ گروه مستقیماً روی عملکرد و دقت مدل اثر می‌گذارد.

ریاضیات سربار حافظه

هزینهٔ ذخیره‌سازی با تقسیم متاداده‌های هر گروه بر اندازهٔ گروه محاسبه می‌شود. بر اساس قراردادهای رایج (۱۶ بیت برای مقیاس و ۴ بیت برای نقطهٔ صفر در هر گروه)، فرمول سربار به این صورت است: overhead(g) = (16 + 4) / g بیت به ازای هر وزن:

• گروه ۱۲۸: ۲۰ بیت تقسیم بر ۱۲۸ ≈ ۰.۱۵۶ بیت سربار (مجموعاً ۴.۱۵۶ بیت به ازای هر وزن)
• گروه ۶۴: ۲۰ بیت تقسیم بر ۶۴ ≈ ۰.۳۱۳ بیت سربار (مجموعاً ۴.۳۱۳ بیت به ازای هر وزن)
• گروه ۳۲: ۲۰ بیت تقسیم بر ۳۲ ≈ ۰.۶۲۵ بیت سربار (مجموعاً ۴.۶۲۵ بیت به ازای هر وزن)
• گروه ۱-: در این حالت، کل ردیف یک گروه محسوب می‌شود و در نتیجه برای هر کانال خروجی تنها یک مقیاس وجود دارد. این خشن‌ترین (Coarsest) گزینه است و هزینهٔ آن حدود ۴.۰۰۰ بیت به ازای هر وزن است.

باید توجه داشت که این اعداد ثابت، قراردادهای رایج هستند و نه قوانین تغییرناپذیر. برای مثال، در کوانتش متقارن (sym=True) هیچ نقطهٔ صفری ذخیره نمی‌شود و صورت کسر در فرمول بالا به ۱۶ کاهش می‌یابد. همچنین برخی روش‌های بسته‌بندی (Packing) از مقیاس ۳۲ بیتی استفاده می‌کنند. برای تطبیق با حجم واقعی یک فایل، باید بررسی کنید که فرمت خاص آن مدل چه چیزی را ذخیره می‌کند، نه اینکه صرفاً به این اعداد ثابت تکیه کنید.

مقیاس‌پذیری بر اساس اندازهٔ مدل

تأثیر این تنظیمات روی مدل‌های کوچک نسبتاً ناچیز است. برای یک مدل ۷ میلیارد پارامتری (با در نظر گرفتن فقط وزن‌های خطی قابل کوانتش)، تأثیر روی VRAM به این صورت است:

• g=128: مقدار ۷.۰e9 * ۴.۱۵۶ / ۸ = ۳.۶۴ گیگابایت
• g=64: مقدار ۷.۰e9 * ۴.۳۱۳ / ۸ = ۳.۷۷ گیگابایت
• g=32: مقدار ۷.۰e9 * ۴.۶۲۵ / ۸ = ۴.۰۵ گیگابایت

در اینجا، کل فاصلهٔ بین گروه ۱۲۸ تا ۳۲ حدود ۰.۴۱ گیگابایت یا تقریباً ۱۱٪ است.

اما برای یک مدل ۷۰ میلیارد پارامتری، همین تفاوت ۰.۴۶۹ بیتی در هر وزن، حدود ۴.۱ گیگابایت VRAM مصرف می‌کند. این مقدار دقیقاً همان مرزی است که تعیین می‌کند مدل روی یک کارت ۴۸ گیگابایتی جای بگیرد یا خیر. چون محاسبات به‌صورت خطی با تعداد پارامترها مقیاس می‌یابند، تصمیم‌گیری در مورد اندازهٔ گروه دقیقاً زمانی گران‌تر و حساس‌تر می‌شود که مدل‌ها آن‌قدر بزرگ شوند که حافظه محدود گردد.

چرا گروه‌های کوچک‌تر کیفیت را حفظ می‌کنند؟

خطای کوانتش زمانی رخ می‌دهد که یک «وزن پرت» (Outlier) با مقدار بسیار زیاد، باعث شود مقیاس کل گروه منبسط شود. مقیاس توسط محدودهٔ (Range) وزن‌ها تعیین می‌شود؛ گام شبکه (Grid Step) در واقع همان محدوده تقسیم بر ۱۵ است.

گروهی را تصور کنید که وزن‌های آن در بازه [۰.۰۲, ۰.۰۲-] قرار دارند؛ در این حالت گام حدود ۰.۰۰۲۷ خواهد بود. اگر این گروه با همسایه‌ای ادغام شود که تنها یک وزن با مقدار ۰.۵ دارد، گام ناگهان به حدود ۰.۰۶۷ می‌پرد؛ یعنی ۲۵ برابر خشن‌تر می‌شود. حالا هر وزن در آن گروه ادغام‌شده، برای اینکه فقط یک وزن پرت را جای دهد، ۲۵ برابر بدتر گرد می‌شود.

گروه‌های کوچک‌تر این آسیب را ایزوله می‌کنند. یک وزن پرت در گروه ۳۲ تایی، تنها دقت ۳۱ همسایه را خراب می‌کند، در حالی که در گروه ۱۲۸ تایی، ۱۲۷ وزن دیگر آسیب می‌بینند. این موضوع دو مشاهدهٔ کلیدی را توضیح می‌دهد:

۱. پهنای بیت پایین: در ۴ بیت، شما ۱۶ سطح برای از دست دادن دارید. در ۳ بیت، ۸ سطح و در ۲ بیت، تنها ۴ سطح دارید. وقتی سطوح کمتری برای جذب خطا وجود داشته باشد، یک مقیاس خشن به‌طور متناسب مخرب‌تر خواهد بود.
۲. مدل‌های پرت‌محور: مدلی که وزن‌های آن به‌طور یکنواخت توزیع شده‌اند، با گروه‌های بزرگ کیفیت کمی از دست می‌دهد. اما مدلی با ساختار پرت‌های شدید، آسیب زیادی می‌بیند. به همین دلیل است که قانونی که برای یک خانوادهٔ مدل کپی شده، ممکن است برای خانواده‌ای دیگر کاربرد نداشته باشد.

منطق پشت پیش‌فرض ۱۲۸

پلتفرم Hugging Face Transformers و ابزارهای رایج کوانتش، مقدار ۱۲۸ را به دلایلی فراتر از دقت، پیش‌فرض قرار داده‌اند. اول اینکه سربار ۰.۱۵۶ بیت به ازای هر وزن بسیار ارزان است (زیر ۴٪ برای یک وزن ۴ بیتی) و در مقابل، بهبود ۱۲۸ برابری در دانه‌بندی (Granularity) نسبت به مقیاس‌بندی در سطح ردیف، هزینه‌ای ناچیز است.

دوم، هسته‌های سخت‌افزاری (Hardware Kernels) برای این عدد بهینه شده‌اند. هسته‌های ضرب ماتریسی با دقت مختلط (Mixed-precision matmul)، وزن‌ها را در قالب کاشی‌هایی (Tiles) بارگذاری می‌کنند. چون ۱۲۸ به‌راحتی بر ابعاد مورد استفاده در این هسته‌ها بخش‌پذیر است، مقیاس می‌تواند یک بار برای هر کاشی بارگذاری شده و در ثبات‌ها (Registers) اعمال شود. اندازهٔ گروهی که به‌طور یکنواخت بر کاشی بخش‌پذیر نباشد، سیستم را مجبور به بارگذاری مجدد یا استفاده از مسیر پردازشی کندتر می‌کند.

در نهایت، این یک استاندارد صنعتی است. اکثر فایل‌های GPTQ و AWQ منتشر شده در Hugging Face از ۱۲۸ استفاده می‌کنند، به این معنی که این پیکربندی دارای بیشترین مسیرهای استنتاج آزمایش‌شده است.

چه زمانی تنظیمات خود را تغییر دهید؟

بر اساس تحلیل dev.to، شما تنها در سه حالت باید از پیش‌فرض ۱۲۸ فاصله بگیرید:

• کوانتش زیر ۴ بیت: وقتی مدل را روی ۳ بیت یا کمتر می‌سازید، بهبود کیفیت حاصل از گروه‌های کوچک‌تر، جریمهٔ اندک حافظه را توجیه می‌کند. متناوباً، می‌توانید از کوانتش با دقت مختلط استفاده کنید تا بودجهٔ حافظه را به جای هر گروه، به ازای هر لایه تخصیص دهید.
• ساختارهای پرت شناخته‌شده: اگر یک خانوادهٔ مدل خاص به توزیع‌های وزنی شدید معروف است، گروه‌های کوچک‌تر آسیب را محدود کرده و از پخش شدن آن جلوگیری می‌کنند.
• مازاد حافظه: اگر GPU شما فضای خالی دارد، گروه ۳۲ تقریب دقیق‌تری از مدل اصلی ارائه می‌دهد.

یک اشتباه رایج این است که توسعه‌دهندگان به دلیل اینکه خروجی مدل «اشتباه به نظر می‌رسد»، اندازهٔ گروه را نصف کنند. اندازهٔ گروه روی گرد کردن اعداد اثر دارد، نه روی قالب‌های چت (Chat Templates)، توکن‌های توقف (Stop Tokens) یا پارامترهای نمونه‌گیری (Sampling Parameters). رفع این مشکلات نیازمند اصلاح پرامپت یا Sampler است، نه تغییر در فرآیند کوانتش.

این تغییر در دیدگاه، کوانتش را از یک فرآیند آزمون و خطا به یک سبک مهندسی پیش‌بینی‌پذیر تبدیل می‌کند. با محاسبهٔ دقیق هزینهٔ VRAM، توسعه‌دهندگان می‌توانند کیفیت مدل را به حداکثر برسانند بدون اینکه ریسک خطاهای Out-of-Memory را بپذیرند.

گام بعدی شما

• پیش از شروع کوانتش مجدد، بررسی کنید که آیا هستهٔ استنتاج (Inference Kernel) شما از گروه‌های ۳۲ یا ۶۴ با سرعت کامل پشتیبانی می‌کند یا خیر.
• اگر از مدل‌های زیر ۳ بیت استفاده می‌کنید، حتماً اندازهٔ گروه را به ۶۴ یا ۳۲ کاهش دهید تا از فروپاشی منطق مدل جلوگیری کنید.
• در مدل‌های ۷۰ میلیارد پارامتری، ابتدا حجم VRAM در دسترس را محاسبه کنید و سپس اندازهٔ گروه را انتخاب کنید تا از کرش کردن سیستم جلوگیری شود.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.