GGUF Quantization: Nên Chọn Mức Nào?

Mặc định hãy chọn Q4_K_M; chỉ lên Q6_K hoặc Q8_0 khi dư VRAM và cần vài phần trăm chất lượng cuối cùng. Quantization thu nhỏ trọng số của mô hình từ 16 bit xuống ít hơn — Q4_K_M lưu khoảng 4.85 bit mỗi trọng số, nên mô hình 7B giảm từ ~14 GB xuống ~4.1 GB với perplexity thường chỉ tệ hơn bản gốc dưới 1%. Câu hỏi “nên dùng mức gguf quantization nào” có một câu trả lời ổn định đến nhàm chán, bị phần lớn drama trên mạng che khuất. Bên dưới: quantization thực sự làm gì với trọng số, mỗi mức đánh đổi bao nhiêu chất lượng, cách tự tính kích thước, và một lệnh để đo tổn thất ngay trên phần cứng của bạn thay vì tin benchmark của người lạ.

GGUF quantization thực sự làm gì?

Mô hình được huấn luyện ở dạng dấu phẩy động 16 bit (FP16 hoặc BF16): mỗi một trong hàng tỷ trọng số là một số 2 byte. Quantization nén từng trọng số xuống ít bit hơn. Cách ngây thơ nhất — làm tròn mọi trọng số thành số nguyên 4 bit — phá hủy các giá trị nhỏ nhưng quan trọng, nên GGUF dùng hai mẹo:

1. Block scaling. Các trọng số được nhóm thành block (thường là 32), mỗi block có một hệ số scale riêng. Giá trị 4 bit là offset bên trong block đó, nên dải độ lớn rộng vẫn tồn tại được.
2. K-quant nhận biết độ quan trọng. Chữ “K” trong Q4_K_M nghĩa là super-block các hệ số scale, cộng với việc đối xử với các lớp attention và feed-forward khác nhau, vì chúng chịu nén với mức độ khác nhau.

Nhà “I” (IQ4_XS và các bạn của nó) đi xa hơn với codebook dựa trên lý thuyết thông tin, mượn từ nén ảnh. Cùng ý tưởng, cách mã hóa cầu kỳ hơn: ít bit hơn mỗi trọng số ở chất lượng tương đương, đổi lại inference chậm hơn chút trên một số backend.

Một làm rõ ngăn được phần lớn sự nhầm lẫn: quantization chỉ thay đổi trọng số được lưu trữ. Kiến trúc, tokenizer và cách xử lý context đều không đụng tới. File Q4 và file Q8 của cùng một mô hình là cùng một mô hình, chỉ khác bộ áo.

Q4 vs Q8: quantization càng cao càng tốt?

Về mặt kỹ thuật: có. Về cảm nhận: không. Lấy chính các lần đo perplexity của llama.cpp trên các mô hình Llama làm chuẩn: Q8_0 nằm trong khoảng ~0.02% so với FP16 — với mọi mục đích thực tế là không mất mát. Q6_K gần như không phân biệt được. Q4_K_M tăng khoảng 1–2% perplexity, Q4_0 hơn chút, còn Q2_K là nơi các câu trả lời mạch lạc bắt đầu sụp đổ trên mô hình nhỏ.

Hai quy tắc mà các con số này ngụ ý:

• Mô hình càng lớn thì dư địa cho quantization càng nhiều. Mô hình 70B sống qua Q2/Q3 tốt hơn xa mô hình 7B, vì mô hình lớn thừa thãi hơn. Quant hóa 7B xuống Q2 là cắt cụt; quant hóa 70B xuống Q3 là may đo.
• Sàn chất lượng phụ thuộc vào tác vụ. Chat chấp nhận được Q4. Sinh code chính xác, toán, và RAG trên tài liệu chi tiết sớm lộ nhiễu quantization. Nếu mô hình Q4 cứ viết code sai một cách tinh vi, hãy thử cùng mô hình đó ở Q6_K trước khi đổ lỗi cho mô hình.

Mức	Bit/trọng số	Kích thước so với FP16	Mất chất lượng	Dùng khi
Q2_K	~3.4	~21%	Nghiêm trọng dưới 13B	Không lựa chọn nào khác vừa, chỉ dành cho mô hình lớn
Q3_K_M	~3.9	~25%	Nhận thấy được	VRAM ít, mô hình ≥14B
Q4_K_S	~4.6	~29%	Nhỏ	Q4_K_M không vừa nhưng chênh ít
Q4_K_M	~4.85	~30%	~1% perplexity	Mặc định. Đánh đổi chất lượng/kích thước tốt nhất
Q5_K_M	~5.7	~35%	~0.5%	Còn dư VRAM, tác vụ cần chất lượng cao
Q6_K	~6.6	~41%	Gần như bằng không	Code/toán, vẫn vừa thoải mái
Q8_0	~8.5	~53%	Thực tế bằng không	Chạy tham chiếu, làm nền fine-tune
IQ4_XS	~4.3	~27%	≈Q4_K_M	Q4_K_M hơi to, backend hỗ trợ i-quant

Mỗi mức cần bao nhiêu VRAM?

Tự tính kích thước thay vì học thuộc bảng — chỉ một dòng:

size_GB ≈ (bits_per_weight × params) / 8
# Mô hình 8B @ Q4_K_M: 4.85 × 8 / 8 ≈ 4.9 GB
# Mô hình 8B @ Q8_0:   8.50 × 8 / 8 ≈ 8.5 GB

Rồi cộng thêm những phần công thức bỏ qua: KV cache (tăng theo độ dài context — từ vài trăm MB đến vài GB), activations, và compute buffer. Biên độ thực tế: mô hình “4.9 GB” cần card 6 GB ở context 4k, cùng flash-attention và quantization KV-cache để giữ vững ở 16k. Trọng số mới chỉ là tiêu đề, không phải toàn bộ hóa đơn.

Bạn nên dùng mức GGUF quantization nào?

Thứ tự ra quyết định, chẳng có ngoại lệ nào đáng nhớ:

1. Tính trước ngân sách context + KV, rồi mới đến trọng số. Context không vừa còn tệ hơn chất lượng không đo được.
2. Mặc định chọn Q4_K_M. Cả cộng đồng chọn nó là có lý — chỉ ~1% perplexity, tiết kiệm ~70% dung lượng. Mọi registry, kể cả của Ollama, đều phát hành nó làm baseline.
3. Lên Q6_K khi tác vụ trừng phạt nhiễu: code, toán, trích xuất, bất cứ thứ gì bạn nạp vào pipeline chạy tự động.
4. Chỉ dùng Q8_0 để tham chiếu — test A/B, đo tổn thất quantization, hoặc làm nền fine-tune. Dùng hằng ngày thì nó chủ yếu chỉ làm ấm cảm biến VRAM của bạn.
5. Chỉ xuống dưới Q4 khi bị ép, và chỉ trên mô hình lớn. Test bằng một prompt khó đã biết trước khi tin nó.

Nếu đang chọn file nào để tải trên Hugging Face, hãy ưu tiên một file Q4_K_M.gguf duy nhất thay vì bản chia sharded, trừ khi người tải lên chỉ phát hành bản chia — ít bộ phận chuyển động hơn. Còn nếu đang chọn chạy ở đâu, việc chọn engine là chuyện riêng: xem llama.cpp vs Ollama cho trục đó.

Làm sao tự đo tổn thất do quantization?

Benchmark ai cũng khác; prompt của bạn thì cố định. Build llama.cpp một lần, tải hai mức của cùng một mô hình, rồi đo cả perplexity (thấp hơn là tốt hơn) lẫn tokens/second:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf 
  --local-dir models

# perplexity trên một đoạn wiki-text (thấp hơn = gần mô hình gốc hơn)
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99

# và tốc độ trên cùng phần cứng
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

Con số của Q4_K_M sẽ tệ hơn Q8_0 vài phần trăm điểm và file sẽ nhỏ hơn ~40%. Nếu tác vụ downstream của bạn không phân biệt được sự khác nhau — và với phần lớn là không — bạn đã có câu trả lời mà không cần đọc leaderboard của ai.

Quantization có hại cho quyền riêng tư hay lời khẳng định “chạy hoàn toàn local” không?

Không — nó chỉ là phép tính trên trọng số, hoàn toàn offline, và file quant hóa chỉ là một container nhỏ hơn chứa chính các tham số đó. Chạy Q4_K_M local rò rỉ đúng bằng (hoặc ít bằng) chạy mô hình full-precision local: không gì rời khỏi máy. Biến số liên quan đến quyền riêng tư là inference chạy ở đâu, chứ không phải độ rộng bit. Những lưu ý thường thấy về nguồn gốc mô hình áp dụng như nhau cho mọi mức quant: một bản fine-tune “uncensored” làm từ base ăn cắp ở Q8 không an toàn hơn chính những trọng số đó ở Q4. Về khía cạnh định dạng file, xem cách chạy mô hình GGUF local.

Bạn nên chọn mức nào?

Q4_K_M, và thôi đừng lục lại các diễn đàn về chuyện này. Lên Q6_K cho công việc cần chính xác nếu VRAM cho phép, giữ một bản Q8_0 để so sánh A/B, và coi mọi thứ dưới Q4 là khẩu phần khẩn cấp chỉ dành cho mô hình lớn. Sai lầm duy nhất đáng tránh thì đối xứng: lo chuyện Q4-hay-Q5 trong khi phớt lờ độ dài context — thứ phá hỏng nhiều setup local hơn bất kỳ mức quant nào từng làm.