چهاربیتی‌کردن مدل چه چیزی را ارزان می‌کند و چه چیزی را تغییر می‌دهد؟

یک مدل را می‌توان با نام یکسان و حجم‌های بسیار متفاوت دریافت کرد: نسخه‌ای بیش از پانزده گیگابایت است و نسخهٔ دیگری از همان مدل کمتر از پنج گیگابایت حجم دارد. توضیح کوتاه معمولاً این است که نسخهٔ دوم «چهاربیتی» شده است. اما برای کسی که می‌خواهد دستیار سازمانی راه بیندازد، پرسش اصلی تازه از اینجا شروع می‌شود: این کاهش حجم چه تغییری در هزینهٔ GPU، کیفیت پاسخ، سرعت اجرا و تعداد کاربران ایجاد می‌کند؟

چهاربیتی‌کردن وزن‌ها می‌تواند یک مدل را از محدودهٔ سخت‌افزارهای گران خارج کند، فضای بیشتری برای درخواست‌های فعال باقی بگذارد و اجرای محلی را عملی‌تر کند. در مقابل، بازنمایی عددی مدل تغییر می‌کند و نتیجه به روش تبدیل و مسیر اجرای آن وابسته است. برای انتخاب درست باید سه عدد را جدا دید: تعداد پارامترهای مدل، دقت ذخیره‌سازی وزن‌ها و حافظهٔ کامل سرویس. این یادداشت رابطهٔ آن‌ها را توضیح می‌دهد؛ نسخه‌های قابل دریافت و تناسب آن‌ها با سخت‌افزار را می‌توان در راهنمای انتخاب مدل زبانی مقایسه کرد.

وقتی مدل چهاربیتی می‌شود، چه چیزی تغییر می‌کند؟

بخش بزرگی از یک مدل زبانی را اعدادی تشکیل می‌دهند که هنگام آموزش یاد گرفته شده‌اند و به آن‌ها وزن می‌گوییم. این اعداد در نسخه‌های متداول ممکن است با قالب‌هایی مانند BF16 یا FP16، هر کدام با شانزده بیت، ذخیره شوند. کوانتیزه‌سازی یا کم‌دقت‌سازی، مجموعهٔ بزرگ‌تری از مقادیر ممکن را به مجموعه‌ای محدودتر نگاشت می‌کند. در بازنمایی چهاربیتی، برای هر مقدار حداکثر شانزده کد در اختیار است؛ مقیاس‌ها و گاهی پارامترهای کمکی مشخص می‌کنند این کدها در هر گروه از وزن‌ها به چه مقدارهایی اشاره دارند. شرح این مفهوم در راهنمای کوانتیزه‌سازی Hugging Face آمده است.

می‌توان موضوع را با ثبت اندازه‌ها در یک کارگاه مقایسه کرد: ابزار دقیق، اختلاف‌های بسیار کوچک را هم ثبت می‌کند؛ ابزار کم‌دقت‌تر چند اندازهٔ نزدیک را یکسان نشان می‌دهد. اگر آن اختلاف‌ها برای محصول نهایی تعیین‌کننده نباشند، نتیجه همچنان قابل استفاده است؛ اگر در نقطه‌ای حساس قرار گرفته باشند، خطا اهمیت پیدا می‌کند. در مدل نیز هدف این است که خطای ناشی از کاهش دقت، تا جای ممکن در رفتار نهایی اثر کمتری داشته باشد. به همین دلیل روش‌های پیشرفته صرفاً همهٔ عددها را با یک قاعدهٔ ثابت گرد نمی‌کنند.

در کوانتیزه‌سازی معمول وزن‌ها، تعداد لایه‌ها، پارامترها و ساختار اصلی شبکه حفظ می‌شود؛ یک مدل ۸ میلیاردی همچنان مدل ۸ میلیاردی است. روش‌هایی مانند تقطیر یا هرس، تغییرات دیگری در طراحی مدل ایجاد می‌کنند و انتخاب میان آن‌ها بحث جداگانه‌ای دارد. همچنین بازکردن وزن چهاربیتی در یک قالب شانزده‌بیتی، جزئیات ازدست‌رفته را خودبه‌خود بازسازی نمی‌کند؛ برای مقایسه با نسخهٔ اصلی باید به همان وزن اصلی مراجعه کرد. مستندات bitsandbytes نیز میان ذخیره‌سازی، دقت محاسبات و بازگردانی قالب تمایز می‌گذارد.

«چهاربیتی» بودن به‌تنهایی مشخصات کافی نیست

وزن‌های ذخیره‌شده، مقادیر میانی محاسبات یا activationها و حافظهٔ KV سه موضوع جدا هستند. در یک مسیر متداول W4A16، وزن‌ها چهاربیتی‌اند و activationها شانزده‌بیتی؛ دقت انباشت نتایج نیز به کرنل بستگی دارد. حافظهٔ KV ممکن است همچنان FP16 باشد، حتی اگر نام فایل مدل Q4 داشته باشد. بنابراین از روی عدد چهار نمی‌توان نتیجه گرفت که همهٔ محاسبات، حافظه‌ها و انتقال‌ها چهار برابر کوچک‌تر شده‌اند. نمونهٔ تفکیک وزن چهاربیتی از دقت محاسبه در تنظیمات رسمی bitsandbytes دیده می‌شود.

نام‌هایی که کنار مدل‌ها دیده می‌شوند نیز به یک نوع مفهوم اشاره ندارند. بعضی قالب فایل‌اند، بعضی روش انتخاب وزن‌های کم‌دقت و بعضی نوع بازنمایی عدد؛ جدول زیر کمک می‌کند هنگام دریافت مدل، این لایه‌ها با هم اشتباه نشوند.

تعریف GGUF در مشخصات این قالب و گزینه‌های کوانتیزه‌سازی آن در مستندات llama.cpp توضیح داده شده است. مقالهٔ GPTQ و مقالهٔ AWQ روش‌های کاهش خطا را تشریح می‌کنند؛ AWQ از آمار activation برای مقیاس‌گذاری کانال‌های مهم‌تر بهره می‌برد. برای تفاوت قالب‌های عددی نیز مقالهٔ QLoRA دربارهٔ NF4 و توضیح NVIDIA دربارهٔ NVFP4 و MXFP4 منابع مستقیم هستند.

کاهش هزینه از حجم وزن‌ها شروع می‌شود

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

برای نمونه، جدول زیر فایل‌های منتشرشده برای Qwen3-8B را نشان می‌دهد. ردیف BF16 مجموع فایل‌های وزن در مخزن اصلی مدل است و ردیف‌های دیگر از مخزن رسمی GGUF همان مدل آمده‌اند. اندازه‌ها بر حسب GiB، معادل ۲ به توان ۳۰ بایت، نوشته شده‌اند و درصد کاهش نسبت به مجموع فایل‌های BF16 محاسبه شده است؛ این جدول مقایسهٔ حجم بسته‌هاست و حافظه یا سرعت اجرای موتور را اندازه نمی‌گیرد.

در این نمونه، نسخهٔ Q4_K_M حدود ۳٫۲۶ برابر کم‌حجم‌تر از بستهٔ BF16 است. اثر مستقیم آن را می‌توان در فضای ذخیره‌سازی، حجم انتقال و حافظهٔ لازم برای نگهداری وزن فشرده دید؛ اثر بر زمان بارگذاری به مسیر دریافت، تبدیل و آماده‌سازی موتور هم وابسته است. مهم‌تر از همه، ممکن است مدل کامل در یک GPU جا بگیرد و نیاز به تقسیم آن میان چند کارت یا انتقال مکرر وزن‌ها از RAM برطرف شود. این تغییر گاهی بیش از کاهش تدریجی مصرف حافظه ارزش دارد، چون معماری استقرار را ساده‌تر می‌کند.

چرا حافظهٔ کل سرویس به همان نسبت کم نمی‌شود؟

پس از بارگذاری وزن‌ها، هنوز باید برای KV cache، فضای کاری محاسبات، بافرها و مدیریت درخواست‌ها حافظه کنار گذاشت. کوانتیزه‌سازی وزن، سهم KV را خودبه‌خود تغییر نمی‌دهد؛ سهمی که با زمینهٔ طولانی و درخواست‌های فعال بیشتر رشد می‌کند. برای نشان دادن تفاوت، همان Qwen3-8B را در نظر بگیریم: معماری آن ۳۶ لایه، ۸ سر KV و بُعد ۱۲۸ برای هر سر دارد. با KV شانزده‌بیتی و بدون اشتراک پیشوند، یک درخواست با مجموع زمینه و خروجی ۳۲٬۷۶۸ توکن، ۴٫۵ GiB حافظهٔ خام KV می‌خواهد. مبنای این محاسبه پیکربندی مدل و رابطهٔ تعداد مقادیر K و V است.

در مقایسهٔ زیر، حجم فایل وزن مبنای تخمین حافظهٔ وزن‌هاست و ۲ GiB فضای کاری فرضی برای موتور در نظر گرفته شده است؛ مصرف واقعی بسته به موتور، کرنل و تنظیمات می‌تواند متفاوت باشد. چهار درخواست فعال نیز در این مثال هر کدام بودجهٔ کامل ۳۲٬۷۶۸ توکن دارند و KV مشترک یا کوانتیزه استفاده نمی‌کنند. بنابراین اعداد جدول برآورد برنامه‌ریزی‌اند و به تعداد کاربران یا سرعت پاسخ تعبیر نمی‌شوند.

در سناریوی تک‌درخواست، مصرف برآوردی کل حدود ۴۹٪ کاهش یافته است؛ کمتر از کاهش ۶۹٪ حجم فایل وزن. از سوی دیگر، با چهار درخواست بلند حتی نسخهٔ Q4 هم از بودجهٔ اسمی یک GPU با حافظهٔ ۲۴ گیگابایت عبور می‌کند. راه‌حل می‌تواند تنظیم زمینه، کاهش هم‌زمانی، تکثیر سرویس روی کارت دیگر یا کوانتیزه‌سازی جداگانهٔ KV باشد. نمونهٔ این بهینه‌سازی مستقل در مستندات KV cache کوانتیزهٔ vLLM توضیح داده شده است؛ مقایسهٔ سخت‌افزار نیز در یادداشت تفاوت 4090 با حافظهٔ ۲۴ و ۴۸ گیگابایت ادامه پیدا می‌کند.

آیا مدل چهاربیتی سریع‌تر پاسخ می‌دهد؟

کاهش حجم وزن‌ها می‌تواند مقدار داده‌ای را که از حافظه به واحدهای پردازش می‌رود کم کند. این مزیت در بخشی از سناریوهای تولید توکن که محدودیت اصلی پهنای باند حافظه است، ارزش زیادی دارد. با این حال، وزن‌های فشرده باید توسط یک کرنل مناسب مصرف شوند؛ در بعضی مسیرها بخشی از بازگردانی مقادیر به دقت بالاتر، داخل همان کرنل انجام می‌شود. اگر هزینهٔ بازکردن و بازچینی وزن‌ها زیاد باشد یا مسیر اجرا بهینه نباشد، بخشی از صرفه‌جویی از دست می‌رود. پروژهٔ Marlin نمونه‌ای از طراحی کرنل برای تبدیل مزیت وزن چهاربیتی به اجرای سریع‌تر است؛ نتیجهٔ یک کرنل یا ضرب ماتریسی را باید در همان دامنه خواند.

مرحلهٔ خواندن ورودی یا prefill نیز با تولید تدریجی خروجی یا decode یکسان نیست. در ورودی بلند و دسته‌های بزرگ، استفادهٔ مجدد از وزن‌ها و سهم محاسبات تغییر می‌کند؛ در زمینه‌های بلند، خواندن KV هم می‌تواند سهم مهمی داشته باشد. در نتیجه ممکن است یک روش، تولید توکن برای یک کاربر را بهتر کند، ولی زمان رسیدن اولین توکن یا توان عملیاتی کل سرویس را به همان نسبت بهبود ندهد. برای قضاوت دربارهٔ سرعت باید طول ورودی و خروجی، تعداد درخواست‌های فعال و موتور اجرا مشخص باشند؛ زمان آغاز پاسخ، فاصلهٔ توکن‌ها و تعداد درخواست‌های موفق را در هر پیکربندی جدا ثبت کنید.

برچسب پشتیبانی چهاربیتی روی GPU نیز پاسخ کامل این پرسش نیست. یک مسیر W4A16 می‌تواند وزن فشرده را بخواند و محاسبات اصلی را با دقت بالاتر انجام دهد، در حالی که مسیری دیگر از دستورهای عددی کم‌دقتِ بومی سخت‌افزار استفاده می‌کند. سازگاری باید برای ترکیب دقیق مدل، قالب عددی، کرنل و نسخهٔ موتور بررسی شود؛ جدول پشتیبانی کوانتیزه‌سازی vLLM نمونه‌ای از این تفکیک است. ترکیب‌های مدل و موتور را می‌توان در جدول سازگاری اجرای مدل بررسی کرد.

چه مقدار از کیفیت تغییر می‌کند؟

برای همهٔ مدل‌ها و کاربردها نمی‌توان یک درصد ثابت اعلام کرد. مقدار تغییر به معماری، اندازهٔ مدل، روش کوانتیزه‌سازی، تانسورهای مشمول آن و کاری که از مدل انتظار می‌رود بستگی دارد. در بسیاری از آزمایش‌های منتشرشده، کوانتیزه‌سازی وزن در چهار بیت بخش بزرگی از کیفیت نسخهٔ مرجع را حفظ کرده است؛ در عین حال، حساسیت وظایف و خانواده‌های مدل یکسان نبوده است. مطالعهٔ Evaluating Quantized Large Language Models، با بررسی وزن، activation و KV در چندین خانواده، همین تفاوت را نشان می‌دهد؛ یافته‌های آن به مدل‌ها و روش‌های بررسی‌شده مربوط‌اند و درصد افت ثابتی برای همهٔ مدل‌های جدید تعیین نمی‌کنند.

در یک چت ساده ممکن است متن هر دو نسخه روان و طبیعی به نظر برسد، اما در استخراج یک شناسه، رعایت شرط استثنا در قرارداد یا انتخاب آرگومان درست برای فراخوانی ابزار، یک تفاوت کوچک اهمیت عملی داشته باشد. در آن مطالعه نیز استدلال چندمرحله‌ای در بخشی از مدل‌ها حساس‌تر از بعضی توانایی‌های دیگر بوده است. برای یک سرویس فارسی باید کیفیت فارسی همان نسخه بررسی شود؛ نتیجهٔ انگلیسی یا میانگین چند معیار، پاسخ مستقیمی دربارهٔ نام‌های فارسی، اعداد، متن رسمی و زبان تخصصی سازمان نمی‌دهد.

روش عملی، مقایسهٔ نسخهٔ مرجع و نسخهٔ کوانتیزه روی ورودی‌های یکسان و معیار متناسب با کار است. برای RAG، صحت پاسخ و اتکا به سند؛ برای استخراج، درستی مقدار هر فیلد؛ برای کدنویسی، عبور از آزمون اجرایی؛ و برای ابزار، درستی انتخاب ابزار و آرگومان‌ها اهمیت دارند. یکسان بودن ساختار JSON فقط درستی قالب را نشان می‌دهد و دربارهٔ صحت مقادیر کافی نیست. تغییر متن پاسخ نیز به‌تنهایی افت کیفیت محسوب نمی‌شود، به‌ویژه اگر تولید تصادفی فعال باشد؛ آنچه باید سنجیده شود موفقیت در انجام وظیفه است.

مدل بزرگ‌تر با چهار بیت یا مدل کوچک‌تر با دقت بیشتر؟

کوانتیزه‌سازی این امکان را ایجاد می‌کند که در یک بودجهٔ حافظه، مدل بزرگ‌تری انتخاب شود. اگر مدل کوچک در فهم دستور یا حل مسئله ناتوان باشد و نسخهٔ چهاربیتی مدل بزرگ‌تر کیفیت بهتری حفظ کند، این انتخاب می‌تواند مفید باشد. اما افزایش تعداد پارامترها معمولاً هزینهٔ پردازش دیگری هم دارد و کاهش حجم وزن‌ها آن را به‌طور کامل حذف نمی‌کند. بنابراین مقایسه باید میان دو راهکار واقعی انجام شود: مثلاً یک مدل کوچک‌تر با دقت بالاتر و یک مدل بزرگ‌تر با چهار بیت، روی همان کار و همان سخت‌افزار.

اگر کار با یک مدل تخصصی یا SLM به کیفیت لازم می‌رسد، حافظهٔ آزادشده می‌تواند صرف درخواست‌های بیشتر یا اجرای اجزای دیگر سامانه شود. اگر کار تحلیلی دشوار است و مدل کوچک کیفیت کافی ندارد، استفاده از مدل بزرگ‌تر کوانتیزه ارزش بررسی دارد. هیچ‌کدام از این انتخاب‌ها با شمارش پارامتر یا حجم فایل به‌تنهایی نهایی نمی‌شود؛ منطق انتخاب نقطهٔ شروع در «برای هر کاربرد واقعاً چه اندازه مدلی لازم داریم؟ از مدل تخصصی و SLM تا LLM» توضیح داده شده است.

آموزش کم‌دقت با تبدیل فایل یکی نیست

در جدول ParetoQ، HellaSwag مدل MobileLLM-350M در BF16 برابر 53.3 و در نسخهٔ 4-bit برابر 53.5 است؛ perplexity گزارش‌شدهٔ Wiki از 10.5 به 10.3 می‌رسد. این نتیجه مربوط به گونه‌های آموزش‌دیده و fine-tuneشدهٔ ParetoQ است. نمی‌توان از آن نتیجه گرفت تبدیل هر مدل به GGUF چهار‌بیتی کیفیت را افزایش می‌دهد. برای مقایسهٔ کاربردی باید علاوه بر معماری و بیت، روش کوانتیزه‌سازی و وضعیت آموزش نیز یکسان یا آشکار باشند.

برای چهاربیتی‌کردن باید مدل را دوباره آموزش داد؟

بسیاری از نسخه‌های قابل دریافت با کوانتیزه‌سازی پس از آموزش یا PTQ ساخته می‌شوند. مدل اصلی از قبل آموزش دیده است و فرایند تبدیل ممکن است از مجموعه‌ای کوچک از نمونه‌ها برای کالیبراسیون استفاده کند؛ GPTQ و AWQ از مسیرهای شناخته‌شدهٔ این رده‌اند. دادهٔ کالیبراسیون برای انتخاب بهتر تقریب عددی به کار می‌رود و استفاده از آن را نباید معادل آموزش دانش سازمانی به مدل گرفت. اگر نسخهٔ کوانتیزهٔ مناسب آماده باشد، مصرف‌کننده می‌تواند همان را دریافت کند و نیازی ندارد فرایند تبدیل را از ابتدا انجام دهد.

در آموزش آگاه از کوانتیزه‌سازی یا QAT، اثر کاهش دقت هنگام آموزش یا تنظیم مدل وارد محاسبه می‌شود تا وزن‌ها با این محدودیت سازگار شوند. این مسیر هزینهٔ آموزشی دارد، اما می‌تواند در بعضی پیکربندی‌ها بخشی از افت کیفیت PTQ را جبران کند. توضیح و آزمایش PyTorch دربارهٔ QAT نمونه‌ای از این رویکرد است. شبیه‌سازی خطای کوانتیزه‌سازی هنگام آموزش نیز الزاماً به معنی انجام همهٔ محاسبات و نگهداری همهٔ وضعیت‌های آموزش در چهار بیت نیست.

QLoRA هدف مرتبط اما متفاوتی دارد: وزن‌های اصلی به‌شکل کم‌دقت و ثابت نگهداری می‌شوند و آداپترهای محدودی آموزش می‌بینند تا تنظیم مدل کم‌هزینه‌تر شود. مقالهٔ QLoRA علاوه بر NF4، روش‌هایی برای کاهش حافظهٔ همین فرایند ارائه کرده است؛ این روش را نباید معادل آموزش همهٔ وزن‌های مدل در چهار بیت دانست. اینکه اصولاً تنظیم مدل لازم است یا مسئله با بازیابی دانش و طراحی بهتر ورودی حل می‌شود، تصمیمی پیش از انتخاب روش آموزش است؛ تفاوت این مسیرها در مقایسهٔ RAG، CAG، KAG، Fine-tuning و Instruction tuning بررسی شده است.

از کدام نسخه شروع کنیم؟

انتخاب یک نسخهٔ آمادهٔ معتبر معمولاً از ساختن چندین کوانتیزهٔ آزمایشی ساده‌تر است. پیش از دریافت باید مدل پایه و نسخهٔ آن، نام کامل روش و دقت، ناشر فایل و مسیر اجرای پیشنهادی روشن باشد؛ tokenizer و قالب گفت‌وگو هم باید با همان مدل هماهنگ باشند. اگر قرار است فرایند تبدیل تکرار شود، بهتر است از وزن اصلی مناسب شروع شود، زیرا تبدیل متوالی از یک نسخهٔ کم‌دقت به نسخهٔ کم‌دقت دیگر می‌تواند خطای قبلی را نیز با خود حمل کند.

این جدول ترتیب بررسی را پیشنهاد می‌کند و جایگزین مشخصات نسخهٔ منتخب نیست. برای نسخه‌های موجود، پیوند وزن‌ها و سازگاری موتور باید به فهرست مدل‌ها و جدول نرم‌افزارهای اجرا و سرویس‌دهی مراجعه کرد. در مقایسهٔ کنترل‌شدهٔ کیفیت، بهتر است مدل پایه، ورودی و تنظیمات تولید ثابت بمانند؛ در مقایسهٔ راهکار نهایی، هر مسیر می‌تواند تنظیم بهینهٔ خودش را داشته باشد، به شرط آنکه این تفاوت‌ها روشن گزارش شوند.

ارزان شدن واقعی وقتی اتفاق می‌افتد که برای انجام همان کار با کیفیت و زمان پاسخ قابل‌قبول، منابع کمتری مصرف شود یا همان منابع پاسخ‌های بیشتری تولید کنند. فایل کوچک‌تر و VRAM آزادتر ابزار رسیدن به این هدف‌اند؛ هزینهٔ تبدیل، نگهداری نسخه‌ها، زمان مهندسی و پاسخ‌های ناموفق هم در نتیجه حضور دارند. برای بسیاری از سرویس‌ها، یک نسخهٔ چهاربیتی مناسب راهی عملی برای کاهش هزینه است؛ نقطهٔ مطلوب جایی است که صرفه‌جویی حافظه به منفعت قابل استفاده تبدیل شود و کیفیت موردنیاز حفظ بماند.