Hướng dẫn lượng tử hóa LLM: So sánh 7 phương pháp (kèm số benchmark)

Hướng dẫn lượng tử hóa LLM: So sánh 7 phương pháp (kèm số benchmark)

Llama 3.3 70B ở FP16 cần tới 140 GB chỉ riêng cho trọng số. Hai chiếc H100. Ở Q4_K_M, cùng mô hình đó nằm gọn trong khoảng 42 GB, tức một chiếc RTX A6000 cũ mua trên eBay. Khoảng cách đó chính là toàn bộ lý do lượng tử hóa LLM tồn tại, và chọn sai phương pháp sẽ khiến bạn trả giá bằng chất lượng bạn nhìn thấy được, hoặc bằng VRAM mà bạn không có.

Hướng dẫn lượng tử hóa LLM này so sánh 7 phương pháp đáng kể nhất năm 2026, với mọi con số đều truy được về một nguồn đã công bố.

Điểm chính

• Lượng tử hóa đánh đổi bộ nhớ và băng thông lấy một mức giảm chất lượng đo được, và thường là nhỏ.
• GPTQ và AWQ ưu tiên GPU; GGUF là định dạng chạy được cả trên CPU.
• Q4_K_M đạt khoảng 4,8 bit trên mỗi trọng số, không phải 4. Cách đặt tên che mất phần overhead.
• Theo PR k-quants của llama.cpp, lượng tử hóa 6-bit chỉ kém perplexity của FP16 khoảng 0,1%.

Lượng tử hóa LLM thực sự làm gì với mô hình của bạn?

Lượng tử hóa LLM lưu trọng số mô hình ở độ chính xác số thấp hơn, thu gọn bộ nhớ và băng thông với cái giá là sai số làm tròn. Một mô hình 70B tham số giảm từ 140 GB ở FP16 xuống còn khoảng 42 GB ở 4-bit. Trí thông minh vẫn còn; chỉ các chữ số thập phân là mất đi. Mọi phương pháp trong hướng dẫn này đều là một biến thể của sự đánh đổi đó.

Thang độ chính xác chạy từ FP32 (32 bit) xuống FP16 và BF16 (mỗi loại 16 bit), rồi INT8, rồi INT4. Mỗi bậc giảm một nửa số byte trên mỗi tham số. Chuẩn IEEE 754 định nghĩa các định dạng số thực; bài báo năm 2014 của Mark Horowitz "Computing's Energy Problem" đã chỉ ra vì sao việc di chuyển những byte đó, chứ không phải phép tính trên chúng, mới chiếm phần lớn chi phí năng lượng. Đó là lý do vật lý khiến lượng tử hóa tăng tốc suy luận.

Hai tham số làm cho lượng tử hóa hoạt động: một hệ số tỷ lệ (scale factor, hệ số nhân ánh xạ khoảng số nguyên về lại giá trị thực) và một điểm không (zero-point, số nguyên đại diện cho 0,0). Lượng tử hóa đối xứng đặt khoảng giá trị vào giữa số không và bỏ qua điểm không; lượng tử hóa bất đối xứng dịch khoảng đó để dùng trọn khoảng số nguyên khi trọng số dồn lệch khỏi số không.

Trọng số lượng tử hóa gọn vì chúng tĩnh và phân bố chuẩn. Activation thì không. Các activation ngoại lai, đôi khi gấp 100 lần trung vị, sẽ thổi bùng sai số làm tròn nếu bạn lượng tử hóa chúng một cách ngây thơ. Sự bất đối xứng đó là lý do hầu hết phương pháp ở đây chỉ lượng tử hóa trọng số (W4A16) và giữ activation ở FP16.

Lượng tử hóa sau huấn luyện (PTQ) chuyển đổi một mô hình đã hoàn thiện sau khi huấn luyện. Huấn luyện nhận biết lượng tử hóa (QAT) mô phỏng việc làm tròn ngay trong lúc huấn luyện để mô hình thích nghi. Mọi thứ trong bài này là PTQ. QAT tốn nhiều compute hơn và cần một lần chạy huấn luyện; đó là một quyết định riêng.

Các hàng INT4 và NF4 là dạng 4-bit thuần túy lý thuyết: 4 bit trên mỗi trọng số và không thêm gì nữa. Các định dạng 4-bit thực tế còn gánh thêm scale và min của từng khối, nên chúng nằm cao hơn. Mô hình 70B ở Q4_K_M khoảng 42 GB, không phải 35. Bảng VRAM ở phần sau dùng các tỷ lệ hiệu dụng.

Lượng tử hóa không làm co trí thông minh của mô hình. Nó làm co số chữ số thập phân dùng để lưu trí thông minh đó. Và nếu bạn đang trả tiền theo token cho suy luận qua API, việc cắt giảm hóa đơn API LLM thường bắt đầu bằng việc tự chạy một mô hình đã lượng tử hóa.

7 phương pháp lượng tử hóa, đặt cạnh nhau

Bảy phương pháp dưới đây bao quát mọi con đường production để lượng tử hóa một LLM vào năm 2026. Hai phương pháp chỉ chạy GPU (GPTQ, AWQ), một chạy ở bất cứ đâu (GGUF), một lượng tử hóa lúc tải (BitsandBytes), hai nhắm tới phục vụ thông lượng cao (SmoothQuant, FP8), và một thuộc về PyTorch bản địa (TorchAO). Lựa chọn đúng phụ thuộc phần cứng của bạn, chứ không phụ thuộc phương pháp nào đứng đầu một bảng xếp hạng.

GPTQ lượng tử hóa từng lớp một, dùng ma trận Hessian nghịch đảo để phân bổ lại sai số làm tròn sang các trọng số còn lại. Nó cần một tập hiệu chuẩn và một GPU. Bài báo GPTQ cho biết đã lượng tử hóa mô hình 175B về 3-4 bit trong khoảng 4 giờ GPU.

AWQ xác định khoảng 1% trọng số quan trọng nhất (các trọng số nổi trội, tìm từ độ lớn activation) và co giãn chúng để bảo vệ chúng khỏi bị làm tròn. Bài báo AWQ (bài báo xuất sắc nhất MLSys 2024) cho biết mức tăng tốc hơn 3 lần so với bản cài đặt FP16 của HuggingFace trên cả GPU desktop lẫn mobile.

GGUF là một định dạng tệp, không phải một thuật toán. Thuật toán bên trong là lược đồ khối k-quant từ PR #1684 của llama.cpp. Đây là phương pháp duy nhất ở đây chạy trên CPU, và điều đó khiến nó thành mặc định cho suy luận cục bộ. Xem các mô hình mở đáng để lượng tử hóa để biết nên nạp gì cho nó.

BitsandBytes lượng tử hóa lúc tải thay vì làm trước. NF4 (4-bit NormalFloat) là định dạng đặc trưng của nó, và nó là xương sống của tinh chỉnh QLoRA. Không cần tập hiệu chuẩn.

SmoothQuant chuyển các activation ngoại lai vào trọng số để cả hai có thể chạy ở INT8. Bài báo cho biết mức tăng tốc tới 1,56 lần và giảm 2 lần bộ nhớ, nhắm tới thông lượng khi phục vụ batch lớn, nơi các phương pháp W4A16 bỏ phí hiệu năng.

FP8 (W8A8) là con đường bản địa trên GPU H100 và B200. Gần như không mất chất lượng ở 8-bit, không đau đầu vì hiệu chuẩn, và vLLM hỗ trợ trực tiếp.

TorchAO là thư viện lượng tử hóa của chính PyTorch, được xây để chạy với torch.compile. Nếu pipeline của bạn đã là PyTorch, đây là con đường ít lực cản nhất.

Chỉ có hai câu hỏi thực sự: phần cứng của bạn có chạy được nó không, và bạn có chấp nhận được cái giá chất lượng mà nó gây ra không?

Các benchmark đã công bố thực sự cho thấy điều gì?

Các benchmark công bố nói rằng lượng tử hóa 4-bit tốn 1-2% perplexity trên mô hình 7B, còn 6-bit tốn chưa tới 0,1%. Những con số đó đến từ PR #1684 của llama.cpp (2023), do những người bảo trì llama.cpp đo trên một mô hình 7B duy nhất với RTX 4080. Chúng là những con số được trích dẫn nhiều nhất trong giới lượng tử hóa, và chúng có thật. Chúng cũng chỉ có n = 1.

Nguồn: PR #1684 của llama.cpp (2023). Mô hình 7B, RTX 4080, do nhóm bảo trì llama.cpp đo. n = 1 mô hình.

Một lưu ý về cột bit/trọng số: đó là các tỷ lệ danh nghĩa cho kiểu k-quant cơ sở, và các bản trộn _K đẩy tỷ lệ hiệu dụng lên cao hơn. Q2_K là một ví dụ. Áp công thức của chính bài viết vào con số danh nghĩa 2.5625 và một mô hình 6,74B tham số, bạn được khoảng 2,0 GB, nhưng hàng này ghi tệp 2.67 GB, suy ngược ra khoảng 3,4 bit trên mỗi trọng số. Phần còn lại của bài dùng các tỷ lệ hiệu dụng, suy ra từ chính những kích thước tệp này.

Các con số của nhóm phương pháp GPU đến trực tiếp từ các bài báo. GPTQ cho biết mức tăng tốc suy luận đầu-cuối so với FP16 xấp xỉ 3,25 lần trên A100 và khoảng 4,5 lần trên A6000, với một mô hình 175B được lượng tử hóa về 3-4 bit trong khoảng 4 giờ GPU. AWQ cho biết "tăng tốc hơn 3 lần so với bản cài đặt FP16 của Huggingface trên cả GPU desktop và mobile", cộng với lần triển khai Llama-2 70B đầu tiên trên GPU mobile qua TinyChat. Chúng tôi trích nguyên văn cách diễn đạt của bài báo thay vì diễn giải một con số thành độ chính xác giả.

Đóng góp nguyên bản ở đây là số học. Bộ nhớ cho trọng số tuân theo: weights (GB) ≈ params (B) × bits per weight ÷ 8. Cái bẫy là bạn nạp con số bit-trên-mỗi-trọng số nào vào. PR #1684 công bố tỷ lệ cho kiểu k-quant cơ sở (Q4_K = 4.5), và các bản trộn _S/_M/_L nằm trên tỷ lệ cơ sở đó vì chúng dành thêm bit cho các tensor attention và feed-forward. Vì vậy chúng tôi suy ra các tỷ lệ hiệu dụng từ kích thước tệp mà chính PR công bố, trên một mô hình 7B thực chất là 6,74B tham số: Q2_K ở 2.67 GB suy ngược về khoảng 3,4 bpw, Q4_K_S ở 3.56 GB về khoảng 4,5, Q6_K ở 5.15 GB về khoảng 6,6. Q4_K_M đạt khoảng 4,8.

Điều đó thay đổi con số tiêu đề. Một mô hình 70B ở Q4_K_M: 70 × 4,8 ÷ 8 = 42 GB. Hầu hết các bài viết nói 35 GB. Họ đang dùng 4,0 bpw và bỏ qua hoàn toàn phần overhead của scale khối. Phép kiểm tra chéo chỉ cần một cú nhấp: Llama-3.3-70B-Instruct-Q4_K_M.gguf nặng 42,5 GB trên HuggingFace, trong cả ba repo bartowski, lmstudio-community và second-state. Chúng tôi đã tính lại mọi ô trong bảng VRAM bên dưới trên cơ sở đó.

Cách đọc của chúng tôi về những con số này: khoảng cách perplexity giữa Q6_K (5.9110) và F16 (5.9066) là 0,0044, nhỏ hơn khoảng cách giữa hai bản tinh chỉnh khác nhau của cùng một mô hình gốc. Đó là lý do lời khuyên "cứ dùng Q4_K_M hoặc Q5_K_M" là lời khuyên sống sót khi chạm trán phần cứng thật. Cột ms/token cũng cho thấy Q2_K không mua thêm tốc độ nào so với Q4_K_S (cả hai đều 15,5 ms/token) trong khi tốn thêm 0,75 perplexity. Q2_K là vụ trao đổi tệ nhất trong bảng.

Điều các con số không nói với bạn: perplexity trên wikitext không giống với chất lượng trên prompt của bạn. Một mô hình trên một GPU là n = 1. Các con số tốc độ phụ thuộc kích thước batch. Hãy xem chúng là định hướng, không phải chân lý phổ quát.

Lượng tử hóa 6-bit nằm trong khoảng 0,1% perplexity của mô hình đầy đủ độ chính xác. Ở mức đó, việc nén gần như miễn phí.

GPTQ và AWQ: chọn giữa hai phương pháp GPU

GPTQ và AWQ đều tạo checkpoint 4-bit cho GPU từ một tập hiệu chuẩn, và cả hai đều được vLLM hỗ trợ tốt. Khác biệt nằm ở cách chúng xử lý sai số làm tròn. GPTQ phân bổ lại nó sang các trọng số còn lại bằng Hessian nghịch đảo. AWQ bảo vệ 1% trọng số mà activation đánh dấu là quan trọng. Cả hai đều hiệu quả. Lựa chọn là về mô hình phục vụ của bạn.

GPTQ làm việc từng lớp. Với mỗi lớp, nó lượng tử hóa từng trọng số một, rồi điều chỉnh các trọng số còn lại trong lớp đó để bù cho phần vừa làm tròn. Việc điều chỉnh dùng thông tin bậc hai từ ma trận Hessian, đó là lý do nó cần một tập hiệu chuẩn để tính. Kết quả rất mạnh cho suy luận theo batch, nơi thông lượng quan trọng hơn độ trễ mỗi token.

AWQ đi theo một góc khác. Nó xác định các trọng số nổi trội bằng cách nhìn vào độ lớn activation trên khắp tập hiệu chuẩn, khoảng 1% kênh đứng đầu. Những trọng số đó nhận một hệ số tỷ lệ theo từng kênh, giữ chúng ở khoảng độ chính xác cao hơn trong lúc làm tròn. Tập hiệu chuẩn có thể nhỏ hơn của GPTQ, và AWQ ít overfit vào nó hơn vì nó bảo vệ các đặc trưng cấu trúc thay vì khớp theo những đầu vào cụ thể. Bài báo cho biết kết quả mạnh ở phục vụ nhạy cảm độ trễ.

Chọn GPTQ nếu: bạn suy luận theo batch trên GPU, bạn có một tập hiệu chuẩn tốt khớp với miền của mình, và thông lượng là thước đo.

Chọn AWQ nếu: bạn phục vụ các yêu cầu đơn người dùng với độ trễ thấp, bạn muốn một tập hiệu chuẩn nhỏ hơn, hoặc bạn triển khai trên GPU edge/mobile.

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

Nếu bạn cũng đang chọn giữa các engine phục vụ, bài vLLM so với SGLang bàn riêng về quyết định đó.

GGUF và K-Quants: Q4_K_M thực sự có nghĩa gì

GGUF là một định dạng tệp, không phải một thuật toán lượng tử hóa. Đặc tả GGUF định nghĩa một container cho trọng số mô hình, siêu dữ liệu và dữ liệu tokenizer. Thuật toán lượng tử hóa bên trong một tệp GGUF là lược đồ khối k-quant (hoặc i-quant) từ PR #1684 của llama.cpp. Nhầm container với thuật toán là sai lầm phổ biến nhất trong lĩnh vực này, và nó dẫn tới những câu hỏi kiểu "GGUF hay GPTQ cái nào tốt hơn?", vốn không hẳn có nghĩa.

Cách đặt tên giải mã như sau. Q nghĩa là lược đồ khối k-quant; IQ nghĩa là i-quant dùng ma trận quan trọng (importance-matrix, một biến thể mới hơn dùng ma trận quan trọng để có chất lượng tốt hơn ở cùng độ sâu bit). Con số là độ sâu bit danh nghĩa. _K đánh dấu họ k-quant so với các định dạng cũ như Q4_0. _S, _M, _L kiểm soát nhóm tensor nào nhận thêm bit: small, medium, large. Hậu tố cao hơn nghĩa là nhiều bit hơn được cấp cho các tensor attention và feed-forward quan trọng nhất.

Các tỷ lệ hiệu dụng, suy ngược từ kích thước tệp 7B (6,74B tham số) công bố trong PR #1684, không phải con số của kiểu cơ sở. Các hàng legacy là chính xác theo cấu trúc: một khối Q4_0 là 32 trọng số ở 4 bit cộng một scale FP16, tức 4,5 bit trên mỗi trọng số, còn Q8_0 là 32 trọng số ở 8 bit cộng một scale FP16, tức 8,5. PR xác nhận điều đó, khi liệt kê tệp Q4_0 và Q4_K_S của 7B ở cùng mức 3.56 GB.

Q4_K_M không phải 4 bit trên mỗi trọng số. Nó khoảng 4,8. Scale và min của khối phải nằm ở đâu đó, và bản trộn _M sau đó chi thêm bit cho các tensor attention và feed-forward, đó chính xác là lý do Q4_K_M nằm trên Q4_K_S và Q3_K_M nằm trên Q3_K_S thay vì ngang bằng.

Vì sao GGUF chạy được ở nơi GPTQ bó tay: nó hỗ trợ suy luận CPU và offload lớp giữa VRAM GPU và RAM hệ thống. Một mô hình 32B không vừa hẳn trên GPU vẫn có thể chạy với một nửa số lớp được offload, chậm nhưng hoạt động. GPTQ không có đường CPU.

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

Mới chơi mô hình cục bộ? Hãy bắt đầu với bài chạy mô hình cục bộ đầu tiên của bạn trước khi lượng tử hóa bất cứ thứ gì. Và nếu bạn muốn một giao diện trình duyệt, Open WebUI trên nền Ollama chỉ mất khoảng mười phút. Tài liệu GGUF của HuggingFace giải thích cách Hub phơi bày cách đặt tên kiểu lượng tử hóa.

BitsandBytes, Marlin, SmoothQuant và TorchAO

Bốn thứ này bao quát các con đường production còn lại. Không cái nào là "GPTQ tốt hơn". Chúng giải quyết những vấn đề khác nhau.

BitsandBytes lượng tử hóa lúc tải, không phải làm trước. Bạn trỏ nó vào một checkpoint FP16 và nó chuyển đổi ngay lập tức sang NF4 hoặc FP4. Không tập hiệu chuẩn, không bước offline. Claim to fame chính của nó là QLoRA: một mô hình gốc 4-bit đóng băng với các adapter LoRA được huấn luyện bên trên, điều đó giúp việc tinh chỉnh mô hình 65B trên một GPU duy nhất khả thi với 48 GB VRAM. QLoRA là một kỹ thuật huấn luyện, không phải kỹ thuật suy luận, nhưng nó là lý do hầu hết mọi người gặp BitsandBytes lần đầu.

Marlin không phải một phương pháp lượng tử hóa. Nó là một kernel GEMM hỗn hợp INT4xFP16, giúp các checkpoint 4-bit hiện có nhanh hơn ở kích thước batch vừa phải. Bài báo Marlin cho biết mức tăng tốc trên A100 và H100. Nếu stack phục vụ hỗ trợ nó, bạn bật nó trên một mô hình đã lượng tử hóa. Bạn không "lượng tử hóa bằng Marlin".

SmoothQuant dịch các activation ngoại lai vào trọng số qua một hệ số co giãn theo từng kênh, làm cho W8A8 (cả trọng số và activation đều ở INT8) trở nên khả thi. Bài báo nhắm tới phục vụ batch lớn, nơi các phương pháp W4A16 bỏ phí thông lượng. Nếu bạn phục vụ hàng trăm yêu cầu đồng thời, đây là nước đi đúng.

TorchAO là lượng tử hóa bản địa của PyTorch, chạy với torch.compile. Không phụ thuộc ngoài, không chuyển đổi định dạng. Nếu pipeline suy luận của bạn đã là PyTorch, đây là lựa chọn ít ma sát nhất. Với việc chạy mô hình embedding cục bộ, đường Ollama thường đơn giản hơn, nhưng TorchAO hợp với các stack PyTorch tùy biến.

Mô hình đã lượng tử hóa cần bao nhiêu VRAM?

Công thức là weights (GB) ≈ params (B) × bits per weight ÷ 8. Một mô hình 70B ở Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 GB. Các tỷ lệ dưới đây là tỷ lệ hiệu dụng, suy ngược từ kích thước tệp mà PR #1684 của llama.cpp công bố, thay vì từ con số của kiểu cơ sở, vì các bản trộn _M luôn chạy trên tỷ lệ k-quant cơ sở của chúng. Chúng tôi đã tính lại thay vì chép lối tắt 4,0 bpw quen thuộc.

Tính từ bit-trên-mỗi-trọng số hiệu dụng: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Suy ra từ kích thước tệp 7B (6,74B tham số) trong PR #1684, rồi kiểm tra chéo với một bản build 70B đã công bố: Llama-3.3-70B-Instruct-Q4_K_M.gguf nặng 42,5 GB trên HuggingFace, so với 42,0 GB dự đoán ở đây.

Lưu ý thành thật: đây chỉ là trọng số. KV cache, độ dài ngữ cảnh và overhead của framework cộng thêm vào. KV cache co giãn theo độ dài ngữ cảnh và kích thước batch. Một phiên ngữ cảnh 32k trên mô hình 70B có thể thêm vài GB. Bảng trọng số là sàn, không phải ngân sách. Cửa sổ ngữ cảnh của bạn cũng thuê VRAM. Để có bức tranh đầy đủ, xem yêu cầu VRAM chi tiết theo từng mô hình.

Bạn nên dùng phương pháp lượng tử hóa nào?

Phần cứng của bạn quyết định trước cả sở thích của bạn. Một phương pháp không chạy trên GPU của bạn không phải một lựa chọn, nó là một điều ước. Bảng dưới đây ánh xạ các cấu hình phổ biến sang phương pháp thực sự chạy được cho chúng, dựa trên các ràng buộc phần cứng và đánh đổi chất lượng đã bàn ở trên.

Với đa số người đọc trên phần cứng tiêu dùng, một GGUF Q4_K_M hoặc Q5_K_M lượng tử hóa sẵn là câu trả lời đúng. Kéo nó từ HuggingFace, chạy trong Ollama hoặc llama.cpp, và dừng tối ưu. Khác biệt chất lượng giữa Q4_K_M và Q5_K_M đủ nhỏ để bạn nên chọn dựa trên việc tệp có vừa hay không, chứ không dựa trên một bảng perplexity. Mọi thứ vượt quá mức đó là tối ưu vì chính nó, và chỉ đáng làm sau khi bạn đã xác nhận mô hình thực sự giải quyết được vấn đề của bạn ở Q4.

Bài các công cụ thực sự chạy được những mô hình này cục bộ bàn về phía phục vụ sau khi bạn đã chọn mức lượng tử hóa.

Năm cách lượng tử hóa đổ vỡ

Các thất bại của lượng tử hóa gần như luôn là vấn đề cấu hình, không phải vấn đề phương pháp. Năm thứ này xuất hiện liên tục.

1. Tập hiệu chuẩn không khớp miền của bạn. Cả GPTQ và AWQ đều khớp theo dữ liệu hiệu chuẩn. Nếu bạn hiệu chuẩn trên Wikipedia và triển khai trên các bản ghi y tế, mô hình lượng tử hóa sẽ kém đi ở những token nó chưa từng thấy. Cách sửa: dùng một tập hiệu chuẩn rút ra từ phân bố đầu vào thực tế của bạn, thậm chí 128 mẫu cũng giúp ích.

2. Đặt kích thước nhóm quá lớn. Kích thước nhóm của GPTQ kiểm soát bao nhiêu trọng số dùng chung một hệ số tỷ lệ. 128 là chuẩn. 256 hoặc 512 tiết kiệm compute lúc lượng tử hóa nhưng đâm vào vách chất lượng trên các mô hình nhỏ hơn. Cách sửa: giữ ở 128 trừ khi bạn đã xác nhận chất lượng đứng vững trên prompt của mình.

3. Kỳ vọng Q2_K dùng được. Theo dữ liệu PR #1684, Q2_K tốn khoảng 0,87 perplexity so với F16 và không mua thêm tốc độ nào so với Q4_K_S (cả hai đều 15,5 ms/token trên benchmark 7B). Bạn được một tệp nhỏ hơn và đầu ra tệ hơn mà không thêm chút độ trễ nào. Cách sửa: Q4_K_S là sàn trừ khi kích thước tệp là ràng buộc cứng.

4. Benchmark trên perplexity wikitext thay vì prompt của chính bạn. Perplexity là một chỉ số mô hình hóa ngôn ngữ. Nó không đo việc mô hình có tuân theo system prompt của bạn, định dạng JSON đúng, hay xử lý từ vựng miền của bạn không. Cách sửa: chạy 20-30 prompt thật của bạn qua cả mô hình đã lượng tử hóa và chưa lượng tử hóa rồi so sánh đầu ra.

5. Nhầm container GGUF với thuật toán lượng tử hóa bên trong nó. Điều này dẫn tới việc so "GGUF với GPTQ" như thể chúng cùng hạng mục. Không phải. GGUF là một định dạng tệp. Lược đồ k-quant bên trong nó mới là thuật toán. Cách sửa: so các mức k-quant (Q4_K_M với Q5_K_M), không phải so định dạng tệp.

Câu hỏi thường gặp

Lượng tử hóa LLM là gì?

Lượng tử hóa LLM giảm độ chính xác số của trọng số mô hình, thường từ số thực 16-bit xuống số nguyên 4-bit hoặc 8-bit. Việc này cắt mức dùng bộ nhớ và tăng tốc suy luận bằng cách giảm băng thông. Một mô hình 70B giảm từ 140 GB xuống còn khoảng 42 GB ở 4-bit. Cái giá chất lượng thường là 1-2% perplexity ở 4-bit, và ít hơn ở 6-bit.

Lượng tử hóa có làm giảm độ chính xác của mô hình không?

Có, nhưng ít hơn hầu hết mọi người nghĩ. Theo benchmark PR #1684 của llama.cpp, Q4_K_S trên mô hình 7B tốn khoảng 2% perplexity so với F16, và Q6_K tốn chưa tới 0,1%. Tác động thực tế trên prompt thật thường nhỏ hơn con số perplexity gợi ý, đặc biệt ở Q4_K_M trở lên.

GPTQ hay AWQ tốt hơn?

Không cái nào tốt hơn một cách phổ quát. GPTQ dùng phân bổ lại sai số bằng Hessian nghịch đảo và hợp với suy luận GPU theo batch. AWQ bảo vệ các trọng số nổi trội qua co giãn nhận biết activation và hợp với phục vụ nhạy cảm độ trễ. AWQ cần một tập hiệu chuẩn nhỏ hơn và ít overfit vào nó hơn. Nếu bạn phục vụ các yêu cầu đơn người dùng với độ trễ thấp, hãy bắt đầu với AWQ.

Q4_K_M nghĩa là gì?

Q4_K_M là một mức lượng tử hóa GGUF dạng k-quant. "Q4" nghĩa là độ sâu 4-bit danh nghĩa, "K" đánh dấu lược đồ khối k-quant (so với Q4_0 legacy), và "M" nghĩa là medium: các tensor attention và feed-forward nhận thêm bit. Số bit hiệu dụng trên mỗi trọng số khoảng 4,8, không phải 4,0, vì scale và min của khối thêm overhead và bản trộn medium chi thêm vào đó.

Tôi có thể chạy mô hình đã lượng tử hóa trên CPU không?

Có, nhưng chỉ qua GGUF. GPTQ và AWQ là các định dạng chỉ chạy GPU. Mô hình k-quant của GGUF chạy trên CPU qua llama.cpp hoặc Ollama, và hỗ trợ offload lớp giữa VRAM GPU và RAM hệ thống. Q4_K_M là mức lượng tử hóa CPU chuẩn. Hãy chờ việc sinh token chậm hơn GPU, nhưng suy luận vẫn hoạt động.

Khác biệt giữa GGUF và GGML là gì?

GGML là thư viện tensor và định dạng tệp cũ hơn mà llama.cpp dùng ban đầu. GGUF thay thế nó vào tháng 8 năm 2023 như một định dạng container linh hoạt hơn với hỗ trợ siêu dữ liệu tốt hơn. Tệp GGUF là thứ bạn tải từ HuggingFace ngày nay. Tệp GGML là legacy và hiếm khi còn được phân phối.

Tôi nên tự lượng tử hóa mô hình hay tải bản lượng tử hóa sẵn?

Hãy tải bản lượng tử hóa sẵn trước. Cộng đồng llama.cpp và HuggingFace đã lượng tử hóa hầu hết các mô hình phổ biến ở mọi mức. Tự lượng tử hóa chỉ hợp lý nếu bạn cần một tập hiệu chuẩn cụ thể cho miền của mình, hoặc nếu chưa có phiên bản lượng tử hóa sẵn cho mô hình của bạn.

Khi nào nên dùng lượng tử hóa thay vì một mô hình nhỏ hơn?

Dùng lượng tử hóa khi bạn cần năng lực của mô hình lớn hơn nhưng không nhét vừa nó vào bộ nhớ. Một mô hình 70B đã lượng tử hóa nhìn chung vượt một mô hình 13B chưa lượng tử hóa trên các tác vụ suy luận phức tạp. Thay vào đó hãy dùng mô hình nhỏ hơn khi độ trễ là ràng buộc, vì mô hình nhỏ hơn sinh token nhanh hơn bất kể lượng tử hóa.

Khác biệt giữa lượng tử hóa và chưng cất là gì?

Lượng tử hóa giảm độ chính xác số của trọng số một mô hình hiện có. Chưng cất (distillation) huấn luyện một mô hình nhỏ hơn bắt chước mô hình lớn hơn, tạo ra một kiến trúc (nhỏ hơn) thực sự khác. Lượng tử hóa giữ nguyên kiến trúc mô hình gốc và về nguyên tắc có thể đảo ngược. Chưng cất tạo ra một mô hình mới và cần một lần chạy huấn luyện.

Phiên bản ngắn gọn: lượng tử hóa là cách bạn nhét mô hình mình muốn vào phần cứng mình có. Với đa số mọi người trên GPU tiêu dùng hoặc Apple Silicon, một GGUF Q4_K_M lượng tử hóa sẵn kéo từ HuggingFace là toàn bộ giải pháp. GPTQ và AWQ là câu trả lời cho phục vụ trên GPU. FP8 và SmoothQuant là câu trả lời cho thông lượng production. Mọi thứ khác là tối ưu sau khi bạn đã xác nhận mô hình chạy được.

Nếu bạn đang quyết định tự host những gì và muốn một ý kiến thứ hai về cặp phần cứng-phương pháp, chúng tôi sẵn lòng trò chuyện.