اجرای مدل‌های زبانی بزرگ (LLM) در مقیاس عملیاتی همواره با چالش کمبود حافظه و پهنای باند مواجه است. بدون فشرده‌سازی، یک مدل 70B معمولی در دقت پیش‌فرض 16 بیتی به حدود 140 گیگابایت حافظه تنها برای بارگذاری وزنها نیاز دارد؛ فضایی که حتی کش کلید-مقدار (KV cache) کاربران همزمان را در بر نمی‌گیرد. کوانتیزهسازی (Quantization) دقیقاً پاسخی به این گلوگاه است.
با این حال، هیچ قالب کوانتیزهسازی یگانه‌ای وجود ندارد که برای تمام سناریوها ایده‌آل باشد. انتخاب میان AWQ، GPTQ، فرمت‌های GGUF یا دقت‌های جدیدتر مانند FP8 و NVFP4 کاملاً به موتور استنتاج (مانند vLLM یا llama.cpp)، سخت‌افزار مقصد و نوع تسک بستگی دارد. این درس معیارهای دقیق انتخاب فرمت مناسب و محاسبات حافظه را در اختیارتان می‌گذارد.
با توجه به این‌که تهیه‌ی پردازنده‌های گرافیکی قدرتمند دیتاسنتری یا اجاره‌ی آن‌ها از سرویس‌های ابری خارجی به دلیل محدودیت‌های پرداخت ارزی و هزینه‌های بالا چالش‌برانگیز است، فشرده‌سازی مدل‌ها و اجرای بهینه روی سخت‌افزارهای محلی، سرورهای اقتصادی یا لبه‌ی شبکه اهمیتی دوچندان پیدا میکند.
قالب کوانتیزهسازی (Quantization) انتخابی جهان‌شمول و همه‌منظوره نیست؛ بلکه تابعی از سخت‌افزار، موتور سرویس‌دهی و نوع بار کاری شماست. قالب‌های GGUF Q4_K_M یا Q5_K_M حاکم مطلق پردازنده (CPU) و لبه‌ی شبکه (Edge) هستند که از طریق llama.cpp و Ollama ارائه می‌شوند. در vLLM، وقتی به اجرای همزمان چند تطبیق‌دهنده‌ی LoRA (یا multi-LoRA) روی یک مدل پایه‌ی مشترک نیاز دارید، GPTQ برنده‌ی میدان است. روش AWQ همراه با کرنل‌های Marlin-AWQ به نرخ پردازش حدود 741 توکن بر ثانیه روی مدل‌های رده‌ی 7B می‌رسد و بالاترین نمره‌ی Pass@1 را در فرمت‌های INT4 ثبت میکند؛ به همین دلیل در سال 2026 پیش‌فرض استاندارد محیط عملیاتی (پروداکشن) دیتاسنترهاست. در معماری‌های Hopper ،Ada و Blackwell، فرمت FP8 با افت کیفیتی نزدیک به صفر و پشتیبانی گسترده، نقطه‌ی تعادل امن به شمار می‌رود. قالب‌های NVFP4 و MXFP4 (میکرواسکیلینگ در Blackwell) بسیار تهاجمی هستند و اعتبارسنجی تک‌تک بلوک‌ها را می‌طلبند. دو تله‌ی خطرناک گریبان‌گیر تیم‌ها میشود: نخست، مجموعه‌داده‌ی کالیبراسیون (Calibration) باید دقیقاً با دامنه‌ی ترافیک محیط عملیاتی هم‌خوانی داشته باشد؛ دوم، کش کلید-مقدار (KV cache) کاملاً مجزا از کوانتیزهسازی وزن‌هاست. درس مهم AWQ این است: نباید با دیدن این‌که «حجم مدلم به 4 GB رسید» ذوق‌زده شوید و 10 تا 30 گیگابایت فضای کش KV را در اندازه‌ی بچِ (batch size) محیط عملیاتی از یاد ببرید.
اهداف یادگیری
- نام بردن از شش قالب کوانتیزهسازی پروداکشن و نقطه‌ی قوت ایده‌آل (sweet spot) هر یک در سال 2026.
- انتخاب قالب مناسب بر اساس سخت‌افزار (CPU در برابر GPU، یا Hopper در برابر Blackwell)، موتور سرویس‌دهی (vLLM ،TRT-LLM ،llama.cpp) و نوع بار کاری (گفت‌وگوی روتین، استدلال، multi-LoRA).
- محاسبه‌ی حافظهی آزادشده در بخش وزنها و برآورد سهمِ دست‌نخورده‌ی کش کلید-مقدار (KV cache) در یک قالب مشخص.
- شناخت تله‌ی مجموعه‌داده‌ی کالیبراسیون که موجب افت کیفیت مدل‌های کوانتیزه‌شده روی ترافیک‌های تخصصی میشود.
صورت مسئله
کوانتیزهسازی، حافظه و پهنای باند حافظهی با پهنای باند بالا (HBM) را به شدت کاهش میدهد؛ دقیقاً همان چیزی که فاز رمزگشایی (Decode) تشنه‌ی آن است. یک مدل 70B با فرمت FP16 حدود 140 گیگابایت وزن دارد. اگر وزنها را به INT4 کوانتیزه کنید (با AWQ یا GPTQ)، حجم مدل به 35 گیگابایت می‌رسد؛ یعنی کل مدل در یک کارت H100 جا می‌گیرد و جا برای کش KV هم باقی می‌ماند. این نکته از آن جهت حیاتی است که در اجرای همزمان 128 توالی با طول کانتکست 2k، کش KV به‌تنهایی 20 تا 30 گیگابایت فضا مصرف میکند.
اما کوانتیزهسازی بی‌هزینه نیست. کوانتیزهسازی تهاجمی به کیفیت مدل آسیب می‌زند؛ به‌ویژه در وظایف سنگین استدلالی. قالب‌های مختلف با موتورهای متفاوتی کار می‌کنند. سخت‌افزارهای گوناگون نیز از دقت‌های متفاوتی به‌صورت سخت‌افزاری پشتیبانی می‌کنند. تنوع قالب‌ها در سال 2026 کاملاً جدی است؛ نمی‌توانید از انتخاب دیگران کپی‌برداری کنید، بلکه باید متناسب با پشته‌ی نرم‌افزاری و سخت‌افزاری خودتان دست به انتخاب بزنید.
مفاهیم کلیدی
شش قالب اصلی
| قالب | بیت | نقطه‌ی قوت ایده‌آل | موتورها |
|---|---|---|---|
| GGUF Q4_K_M / Q5_K_M | 4-5 | پردازنده، لبه‌ی شبکه، لپ‌تاپ‌ها | llama.cpp, Ollama |
| GPTQ | 4-8 | اجرای Multi-LoRA در vLLM | vLLM, TGI |
| AWQ | 4 | محیط‌های عملیاتی مبتنی بر GPU در دیتاسنتر | vLLM (Marlin-AWQ), TGI |
| FP8 | 8 | دیتاسنترهای مجهز به Hopper/Ada/Blackwell | vLLM, TRT-LLM, SGLang |
| MXFP4 | 4 | محیط‌های چندکاربره در Blackwell | TRT-LLM |
| NVFP4 | 4 | محیط‌های چندکاربره در Blackwell | TRT-LLM |
GGUF؛ گزینه‌ی پیش‌فرض پردازنده و لبه‌ی شبکه
فرمت GGUF صرفاً یک قالب فایل است، نه یک طرح کوانتیزهسازی مستقل؛ این قالب انواع K-quant (شامل Q2_K ،Q3_K_M ،Q4_K_M ،Q5_K_M ،Q6_K و Q8_0) را در یک ظرف یکپارچه بسته‌بندی میکند. گزینه‌های Q4_K_M و Q5_K_M استانداردهای اصلی محیط عملیاتی هستند که با 4 تا 5 بیت کیفیتی بسیار نزدیک به BF16 تحویل میدهند. اگر مقصد استقرار شما CPU یا لبه‌ی شبکه است، این فرمت بهترین گزینه است؛ زیرا llama.cpp با اختلاف سریع‌ترین موتور استنتاج مبتنی بر CPU به حساب می‌آید.
جریمه‌ی نرخ پردازش در vLLM: حدود 93 توکن بر ثانیه روی مدل‌های 7B؛ چون این قالب برای کرنل‌های GPU بهینه‌سازی نشده است. تنها زمانی از GGUF استفاده کنید که مقصد استقرار واقعاً CPU یا لبه‌ی شبکه باشد، نه غیر آن.
GPTQ؛ راه‌حل Multi-LoRA در vLLM
روش GPTQ نوعی الگوریتم کوانتیزهسازی پس از آموزش است که از یک مرحله‌ی کالیبراسیون بهره می‌برد. کرنل‌های Marlin اجرای آن را روی GPU بسیار پرسرعت کرده‌اند (2.6 برابر سریع‌تر در مقایسه با GPTQ بدون Marlin)؛ یعنی حدود 712 توکن بر ثانیه روی مدل‌های 7B.
برتری منحصربه‌فرد این روش در این است که GPTQ-Int4 از تطبیق‌دهنده‌های LoRA در vLLM پشتیبانی میکند. اگر قصد دارید یک مدل پایه را به همراه 10 تا 50 گونه‌ی بازتنظیم‌شده (Fine-tuned) در قالب LoRA سرویس‌دهی کنید، مسیر شما GPTQ است. تا اوایل سال 2026، فرمت NVFP4 هنوز از LoRA پشتیبانی نمی‌کند.
AWQ؛ گزینه‌ی پیش‌فرض GPU در دیتاسنتر
کوانتیزهسازی وزنها با آگاهی از اکتیویشن (Activation-aware Weight Quantization یا AWQ) در فرآیند کوانتیزهسازی از حدود 1 درصد از حیاتی‌ترین وزن‌های مدل محافظت میکند. ترکیب آن با کرنل‌های Marlin-AWQ جهشی 10.9 برابری در سرعت نسبت به حالت پایه ایجاد میکند: حدود 741 توکن بر ثانیه روی مدل‌های 7B و بالاترین نمره‌ی Pass@1 در میان فرمت‌های INT4.
برای راه‌اندازی سرویس‌های جدید بر بستر GPU به سراغ AWQ بروید؛ مگر این‌که به multi-LoRA نیاز داشته باشید (که قلمرو GPTQ است) یا به سراغ FP4 تهاجمی در Blackwell بروید (NVFP4).
FP8؛ حد وسط مطمئن
ممیز شناور 8 بیتی (FP8) افت کیفیتی بسیار نزدیک به صفر دارد و پشتیبانی گسترده‌ای از آن میشود. هسته‌های تنسور (Tensor Core) در معماری Hopper مستقیماً پردازش FP8 را شتاب‌بخشی سخت‌افزاری می‌کنند و Blackwell هم همین مسیر را در پیش گرفته است. اگر کیفیت خط قرمز شماست (مانند استدلال، کاربردهای پزشکی یا تولید کد)، FP8 در سال 2026 گزینه‌ی امن پیش‌فرض است. صرفه‌جویی در حافظه در این روش نصف INT4 است، اما ریسک افت کیفیت بسیار کمتر خواهد بود.
MXFP4 / NVFP4؛ گزینه‌های تهاجمی بلک‌ول
میکرواسکیلینگ در ممیز شناور 4 بیتی (Microscaling FP4). در این روش هر بلوک از وزنها ضریب مقیاس (Scale factor) مختص به خود را دارد. با وجود تهاجمی بودن، هسته‌های تنسور Blackwell این محاسبات را شتاب‌بخشی سخت‌افزاری می‌کنند. این فرمت‌ها بایت مصرفی به ازای هر توکن را نسبت به FP8 به نصف می‌رسانند؛ همان مزیت اقتصادی که در درس 17.07 با آن روبه‌رو می‌شوید.
هشدارهای مهم:
- تا اوایل 2026 هنوز خبری از پشتیبانی LoRA نیست.
- افت کیفیت در بارهای کاری سنگین استدلالی کاملاً مشهود است.
- باید صحت عملکرد را حتماً روی مجموعه‌ی ارزیابی مدل خود بسنجید.
تله‌ی کالیبراسیون
روش‌های AWQ و GPTQ به یک مجموعه‌داده‌ی کالیبراسیون نیاز دارند؛ معمولاً C4 یا WikiText. برای مدل‌های تخصصی (برنامه‌نویسی، پزشکی، حقوقی)، کالیبراسیون با متن‌های وب عمومی باعث میشود الگوریتم در تشخیص این‌که از کدام وزنها محافظت کند دچار اشتباه شود. این اشتباه میتواند نمره‌ی Pass@1 را در آزمون HumanEval چندین نمره کاهش دهد.
راهکار: کالیبراسیون را حتماً روی داده‌های همان دامنه‌ی تخصصی انجام دهید. معمولاً چند صد نمونه‌ی تخصصی کفایت میکند. پیش از ارسال به پروداکشن، خروجی را روی مجموعه‌ی ارزیابی بسنجید.
تله‌ی کش کلید-مقدار (KV Cache)
روش AWQ وزنها را به 4 بیت فشرده میکند؛ اما کش KV ساختاری جداگانه دارد و روی دقت FP16 یا FP8 باقی می‌ماند. برای یک مدل 70B با AWQ وضعیت به این صورت است:
- وزنها: حدود 35 گیگابایت (کاهش از 140 گیگابایت به لطف INT4).
- کش KV برای 128 توالی همزمان با طول کانتکست 2k: حدود 20 گیگابایت.
- اکتیویشن‌ها: حدود 5 گیگابایت.
- مجموع کل: حدود 60 گیگابایت؛ که به‌راحتی در یک کارت H100 هشتاد گیگابایتی (80GB) جا میشود.
این‌که ساده‌انگارانه بگویید «حجم مدلم به 4 GB رسید» و آن 30 تا 50 گیگابایت دیگر را فراموش کنید، خطایی مهلک است. بودجهبندی حافظهی HBM را همیشه یکپارچه و کلی در نظر بگیرید.
به‌علاوه، کوانتیزهسازی کش کلید-مقدار (مانند FP8 KV یا INT8 KV) تصمیمی کاملاً مجزا با مصالحه‌های خاص خودش است؛ این کار مستقیماً بر دقت اتنشن (Attention) اثر می‌گذارد و به هیچ وجه بدون هزینه نیست.
خطرات AWQ INT4 در وظایف استدلالی
زنجیره‌ی تفکر (CoT)، ریاضیات و تولید کد با کانتکست طولانی، همگی از کوانتیزهسازی تهاجمی ضربه می‌خورند. روش AWQ INT4 حدود 3 تا 5 نمره افت در بنچمارک MATH ثبت میکند. برای بارهای کاری سنگین استدلالی، FP8 یا BF16 را به محیط عملیاتی ببرید و هزینه‌ی حافظهی بیشتر را قبول کنید.
راهنمای انتخاب در سال 2026
- سرویس‌دهی روی پردازنده یا لبه‌ی شبکه: یک‌راست GGUF Q4_K_M؛ تمام.
- سرویس‌دهی روی GPU برای چت‌های روتین، بدون LoRA: فرمت AWQ.
- سرویس‌دهی روی GPU همراه با multi-LoRA: فرمت GPTQ با Marlin.
- بار کاری استدلالی: فرمت FP8.
- دیتاسنتر مبتنی بر Blackwell با کیفیت اعتبارسنجی‌شده: فرمت NVFP4 به همراه FP8 KV.
- شرایط مبهم: اجرای یک ارزیابی 1000 نمونه‌ای روی تک‌تک فرمت‌های مد نظر.
استفاده در عمل
اسکریپت code/main.py ردپای حافظه (وزنها + کش KV + اکتیویشن‌ها) و نرخ پردازش نسبی را برای شش قالب مختلف و در دامنه‌ای از اندازه‌های مدل محاسبه میکند. این اسکریپت نشان میدهد کش KV کجا بخش اصلی حافظه را می‌بلعد، فشرده‌سازی وزنها کجا به‌صرفه است و در چه مواردی FP8 انتخاب امن به حساب می‌آید.
ماشین تعاملی Inside an LLM Serving GPU عملکرد FP8 را روی پردازنده‌ی گرافیکی NVIDIA L4 نشان میدهد. در این سناریو، حجم وزنها از 15.28 گیگابایت به 8.81 گیگابایت افت میکند، استخر توکن‌های KV از 24,094 به 142,369 توکن افزایش می‌یابد و نرخ خروجی در حضور 64 کاربر از 250.85 به 735.91 توکن بر ثانیه می‌رسد.
تحویل پروژه
خروجی این درس فایل outputs/skill-quantization-picker.md است. این ابزار با دریافت مشخصات سخت‌افزار، اندازه‌ی مدل، نوع بار کاری و میزان تحمل افت کیفیت، قالب مناسب را پیشنهاد میدهد و برنامه‌ای مدون برای کالیبراسیون و اعتبارسنجی آن تولید میکند.
تمرین‌ها
- اسکریپت
code/main.pyرا اجرا کنید. برای یک مدل 70B در سناریوی 128 توالی همزمان با طول کانتکست 2k، کل حافظهی HBM مصرفی را برای هر یک از قالب‌ها محاسبه کنید. کدام قالب به شما اجازه میدهد مدل را روی یک کارت H100 هشتاد گیگابایتی (80GB) مستقر کنید؟ - یک مدل 7B کدنویسی در اختیار دارید. قالب مناسب را انتخاب و دلیل آن را توضیح دهید. اگر در برآورد میزان تحمل افت کیفیت اشتباه کرده باشید، مسیر بازیابی و جبران چیست؟
- حجم مجموعه‌داده‌ی کالیبراسیون مورد نیاز برای کوانتیزهسازی AWQ روی مدلی در حوزه‌ی پزشکی را محاسبه کنید. چرا داده‌ی بیشتر لزوماً همیشه بهتر نیست؟
- مقاله‌ی مربوط به کرنل Marlin-AWQ یا یادداشت‌های انتشار آن را بخوانید. در سه جمله توضیح دهید چرا AWQ روی مدل 7B به سرعت 741 توکن بر ثانیه می‌رسد، در حالی که GPTQ خام حدود 712 توکن بر ثانیه ثبت میکند.
- در چه مواردی ترکیب وزن‌های AWQ با کش کلید-مقدار FP8 منطقی است و در چه شرایطی باید کش را روی BF16 نگه داشت؟
اصطلاحات کلیدی
| اصطلاح | اصطلاح عامیانه | معنای دقیق فنی |
|---|---|---|
| GGUF | «فرمت llama.cpp» | قالب فایلی برای بسته‌بندی انواع K-quant؛ پیش‌فرض پردازنده‌ها و لبه‌ی شبکه |
| Q4_K_M | «کیو فور کِی ام» | فرمت 4 بیتیِ K-quant در اندازه‌ی متوسط؛ پیش‌فرض پروداکشن در اکوسیستم GGUF |
| GPTQ | «جی‌پی‌تی‌کیو» | روش کوانتیزهسازی INT4 پس از آموزش با مرحله‌ی کالیبراسیون؛ پشتیبانی از LoRA در vLLM |
| AWQ | «ای‌دبلیو‌کیو» | روش INT4 با آگاهی از اکتیویشن؛ کرنل‌های Marlin؛ بالاترین Pass@1 در بین قالب‌های INT4 |
| Marlin kernels | «کرنل‌های سریع INT4» | کرنل‌های بهینه‌سازی‌شده‌ی CUDA برای INT4 روی Hopper؛ ارائه‌دهنده‌ی جهش سرعتی تا 10 برابر |
| FP8 | «ممیز شناور هشت بیتی» | پیش‌فرض ایمن و باکیفیت روی تراشه‌های Hopper ،Ada و Blackwell |
| MXFP4 / NVFP4 | «میکرواسکیلینگ چهار» | فرمت ممیز شناور 4 بیتی در معماری Blackwell با ضرایب مقیاس مجزا برای هر بلوک |
| Calibration dataset | «دیتای کالیبراسیون» | متن‌های ورودی برای تعیین پارامترهای کوانتیزهسازی؛ باید حتماً با دامنه‌ی کاری پروداکشن منطبق باشد |
| KV cache quantization | «کی‌وی اینت‌ایت» | انتخابی مجزا از وزنها؛ مستقیماً روی دقت اتنشن تأثیر می‌گذارد |
مطالعه‌ی بیشتر
- VRLA Tech — LLM Quantization 2026 — بنچمارک‌های تطبیقی قالب‌ها.
- Jarvis Labs — vLLM Quantization Complete Guide — آمارهای نرخ پردازش به تفکیک فرمت‌ها.
- PremAI — GGUF vs AWQ vs GPTQ vs bitsandbytes 2026 — راهنمای انتخاب قالب به تفکیک سناریوها.
- vLLM docs — Quantization — مستندات پرچم‌ها و قالب‌های تحت پشتیبانی.
- AWQ paper (arXiv:2306.00978) — مقاله‌ی اصلی معرفی AWQ.
- GPTQ paper (arXiv:2210.17323) — مقاله‌ی اصلی معرفی GPTQ.