یک مدل زبانی ۷۰ میلیاردی در دقت کامل حدود ۱۴۰ گیگابایت حافظه کارت گرافیک لازم دارد؛ یعنی دست‌کم دو کارت دیتاسنتری گران‌قیمت. Quantization یا کوانتایز این عدد را به حدود ۴۰ گیگابایت می‌رساند و همان مدل را روی یک کارت اجرا می‌کند. در این مقاله توضیح می‌دهیم Quantization چیست، چطور کار می‌کند، چه اثری روی کیفیت و سرعت دارد و کدام فرمت (GGUF، AWQ، GPTQ یا FP8) برای پروژه شما مناسب است.
فهرست مطالب
Quantization چیست؟
وزن‌های یک شبکه عصبی اعدادی هستند که معمولاً با دقت ۱۶ بیتی ذخیره می‌شوند. Quantization فرایند تبدیل این اعداد به دقت پایین‌تر، مثلاً ۸ یا ۴ بیت، است. نتیجه، مدلی با حجم بسیار کمتر است که در حافظه کوچک‌تر جا می‌شود و معمولاً سریع‌تر اجرا می‌شود، با کمی افت کیفیت که در بیشتر کاربردها قابل چشم‌پوشی است.
دقت‌های عددی: FP32 تا INT4
| دقت | بیت به‌ازای هر وزن | کاربرد رایج |
|---|---|---|
| FP32 | ۳۲ | بخش‌هایی از آموزش؛ برای اجرا هدر دادن حافظه است |
| FP16 / BF16 | ۱۶ | استاندارد انتشار و اجرای مدل‌ها؛ کیفیت مرجع |
| FP8 / INT8 | ۸ | کاهش نصف حافظه با افت کیفیت ناچیز |
| INT4 و ۴ بیتی | ۴ | کاهش حدود ۷۰ تا ۷۵ درصدی حافظه با افت اندک |
| ۳ و ۲ بیتی | ۲ تا ۳ | فقط وقتی چاره دیگری نیست؛ افت کیفیت محسوس |
کوانتایز چطور کار می‌کند؟
ساده‌ترین روش این است که بازه اعداد یک گروه از وزن‌ها پیدا و به تعداد محدودی سطح تقسیم شود؛ هر وزن با نزدیک‌ترین سطح جایگزین می‌شود و فقط شماره آن سطح ذخیره می‌شود. برای اینکه دقت حفظ شود، روش‌های امروزی:
- وزن‌ها را در گروه‌های کوچک (مثلاً ۳۲ یا ۱۲۸ تایی) کوانتایز می‌کنند و برای هر گروه ضریب مقیاس جداگانه نگه می‌دارند.
- وزن‌های مهم‌تر را شناسایی و با دقت بیشتر حفظ می‌کنند. روش AWQ بر اساس اثر وزن‌ها روی خروجی (Activation) این کار را انجام می‌دهد.
- خطای ناشی از گرد کردن را با داده نمونه (Calibration) جبران می‌کنند، مثل روش GPTQ.
این تکنیک‌ها باعث شده‌اند که کوانتایز ۴ بیتی امروز کیفیتی بسیار نزدیک به مدل اصلی داشته باشد.
صرفه‌جویی در حافظه
| مدل | FP16 | ۸ بیتی | ۴ بیتی |
|---|---|---|---|
| Llama 3.1 8B | حدود ۱۶ گیگابایت | حدود ۸٫۵ گیگابایت | حدود ۵ گیگابایت |
| Qwen 2.5 14B | حدود ۲۹ گیگابایت | حدود ۱۵ گیگابایت | حدود ۹ گیگابایت |
| Qwen 2.5 32B | حدود ۶۵ گیگابایت | حدود ۳۴ گیگابایت | حدود ۲۰ گیگابایت |
| Llama 3.3 70B | حدود ۱۴۰ گیگابایت | حدود ۷۵ گیگابایت | حدود ۴۳ گیگابایت |
این اعداد فقط وزن‌ها هستند. KV Cache و سربار نرم‌افزار هم باید اضافه شوند؛ محاسبه کامل در VRAM برای هوش مصنوعی.
اثر روی کیفیت
معیار رایج سنجش افت کیفیت، Perplexity است: هرچه کمتر، مدل در پیش‌بینی متن مطمئن‌تر است. در کنار آن، بنچمارک‌های وظیفه‌محور (استدلال، ریاضی، کدنویسی) هم بررسی می‌شوند. الگوی کلی نتایج منتشرشده:
- ۸ بیتی: تقریباً غیرقابل تشخیص از مدل اصلی.
- ۵ و ۶ بیتی: افت بسیار جزئی.
- ۴ بیتی (Q4_K_M، AWQ): افت اندک؛ در گفتگو، خلاصه‌سازی و پاسخ به سوال معمولاً محسوس نیست، اما در ریاضی، کدنویسی دقیق و زبان‌های کم‌منبع‌تر مثل فارسی ممکن است بیشتر دیده شود.
- ۳ بیتی و کمتر: افت محسوس، به‌خصوص در مدل‌های کوچک.
یک قاعده مفید: مدل‌های بزرگ‌تر در برابر کوانتایز مقاوم‌ترند. یک مدل ۳۲ میلیاردی ۴ بیتی معمولاً از یک مدل ۱۴ میلیاردی ۸ بیتی با حافظه مشابه، نتیجه بهتری می‌دهد.
اثر روی سرعت
در تولید متن، گلوگاه اصلی سرعت خواندن وزن‌ها از حافظه است. وزن‌های کوچک‌تر سریع‌تر خوانده می‌شوند؛ پس کوانتایز معمولاً سرعت تولید توکن را افزایش می‌دهد، به شرط اینکه موتور اجرا کرنل‌های بهینه برای آن فرمت داشته باشد. کارت‌های جدید NVIDIA (Ada، Hopper و Blackwell) از FP8 به‌صورت سخت‌افزاری پشتیبانی می‌کنند و Blackwell از FP4 هم پشتیبانی می‌کند.
مقایسه فرمت‌ها
| فرمت | موتورهای اصلی | ویژگی | مناسب برای |
|---|---|---|---|
| GGUF | llama.cpp، Ollama، LM Studio | تک‌فایل، سطوح متنوع، اجرای ترکیبی CPU و GPU | توسعه، استفاده شخصی، سرورهای کوچک |
| AWQ | vLLM، SGLang، Transformers | حفظ وزن‌های مهم؛ کیفیت خوب در ۴ بیت | سرویس‌دهی عملیاتی روی GPU |
| GPTQ | vLLM، Transformers | کالیبراسیون با داده؛ پشتیبانی گسترده | سرویس‌دهی روی GPU |
| FP8 | vLLM، TensorRT-LLM، SGLang | پشتیبانی سخت‌افزاری روی کارت‌های جدید؛ کیفیت نزدیک به FP16 | H100، L40S و کارت‌های جدیدتر |
| EXL2 | ExLlamaV2 | بیت‌ریت قابل تنظیم با دقت بالا | کاربران حرفه‌ای روی کارت‌های NVIDIA |
سطوح کوانتایز GGUF
در Ollama و llama.cpp نام‌هایی مثل Q4_K_M می‌بینید. عدد، تعداد بیت تقریبی و حروف بعدی، نسخه روش و اندازه را نشان می‌دهند:
- Q8_0: بالاترین کیفیت، حجم حدود نصف FP16.
- Q6_K و Q5_K_M: تعادل بسیار خوب؛ اگر حافظه اجازه می‌دهد، انتخاب امنی است.
- Q4_K_M: پیش‌فرض رایج و نقطه تعادل حجم و کیفیت.
- Q3_K و Q2_K: فقط برای جا دادن مدل‌های بزرگ در حافظه بسیار کم.
در Ollama می‌توانید سطح را در نام مدل مشخص کنید؛ مثلاً ollama pull qwen2.5:14b-instruct-q5_K_M.
کدام فرمت را انتخاب کنیم؟
- Ollama یا استفاده شخصی: GGUF با Q4_K_M، یا Q5_K_M و Q8_0 اگر حافظه کافی دارید.
- سرویس‌دهی با vLLM روی H100 یا L40S: FP8 اگر حافظه کافی است؛ AWQ ۴ بیتی اگر باید مدل بزرگ‌تری جا شود.
- کاربردهای حساس به دقت (کد، ریاضی، استخراج اطلاعات دقیق): ۸ بیت یا FP8.
همیشه نسخه کوانتایزشده را روی نمونه‌ای از داده‌ها و سوال‌های واقعی خودتان، به‌خصوص به زبان فارسی، با مدل اصلی مقایسه کنید. تفاوت دو موتور اصلی را هم در Ollama یا vLLM ببینید.
سوالات متداول
آیا کوانتایز سرعت تولید متن را افزایش می‌دهد؟
معمولاً بله، چون وزن‌های کوچک‌تر سریع‌تر از حافظه خوانده می‌شوند و گلوگاه اصلی تولید متن همین است. شرط آن پشتیبانی موتور اجرا از کرنل‌های بهینه آن فرمت است.
آیا می‌توان مدل کوانتایزشده را Fine-Tune کرد؟
بله، با روش QLoRA مدل پایه با دقت ۴ بیتی بارگذاری و فقط آداپتورهای کوچک آموزش داده می‌شوند. جزئیات در Inference و Fine-Tuning.
کوانتایز KV Cache با کوانتایز مدل چه فرقی دارد؟
کوانتایز مدل حجم وزن‌ها را کم می‌کند؛ کوانتایز KV Cache حافظه‌ای را که برای متن ورودی و کاربران همزمان مصرف می‌شود. هر دو را می‌توان همزمان استفاده کرد. توضیح بیشتر در KV Cache چیست.
آیا خودم باید مدل را کوانتایز کنم؟
معمولاً نه. نسخه‌های کوانتایزشده مدل‌های محبوب در کتابخانه Ollama و Hugging Face آماده‌اند. فقط برای مدل‌های Fine-Tuneشده خودتان باید کوانتایز را انجام دهید.
اجرای مدل‌های بزرگ با سخت‌افزار مناسب
در سرورهای GPU تراست هاست با کارت‌های L40S و H100 که از FP8 پشتیبانی می‌کنند، مدل‌های کوانتایزشده را با سرعت بالا اجرا کنید.
