Thủ thuật
Đánh giá thực tế các mức nén Qwen3.8 27B: Q4_K_M ổn định, mức 1-bit gần như vô dụng
(giờ Việt Nam)
Tóm tắt AI
Bài viết thử nghiệm hiệu năng của các phiên bản nén GGUF (Unsloth) trên mô hình Qwen3.8 27B qua các bộ benchmark GPQA Diamond, IFBench và Terminal-Bench 2.1.
Bản dịch AI
Bạn thực sự cần bao nhiêu dung lượng GPU RAM để chạy Qwen3.8 27B mà không làm giảm chất lượng?
Mô hình BF16 đầy đủ nặng 55 GB, vượt quá khả năng của hầu hết phần cứng người dùng phổ thông. Tuy nhiên, phiên bản Q4_K_M nặng 17 GB lại cho kết quả tương đương với mô hình đầy đủ trên một benchmark lập trình agent phổ biến là Terminal-Bench 2.1. Nó vừa vặn trên một card 24 GB như RTX 4090, đồng thời vẫn chừa chỗ cho khoảng 64k token ngữ cảnh.
Việc nén dữ liệu cuối cùng cũng sẽ chạm ngưỡng giới hạn. Ở mức 1-bit, hiệu suất của mô hình chỉ ngang bằng với đoán ngẫu nhiên trên GPQA Diamond, và việc suy luận dài hơn thậm chí còn làm kết quả tệ hơn.
Bối cảnh
Các bản lượng tử hóa GGUF của Qwen3.8 27B có sẵn từ Unsloth trên Hugging Face. Có quá nhiều lựa chọn! Tôi sẽ kiểm tra bản 8-bit Q8_0 (29 GB), 4-bit Q4_K_M (17 GB), 2-bit UD-Q2_K_XL (10.7 GB) và bản nhỏ nhất có thể là 1-bit UD-IQ1_S (6.2 GB).
Trước đây, tôi đã nghiên cứu mô hình Qwen3.6 27B, vốn rất giỏi trong việc tạo hình ảnh bồ nông bằng SVG ngay cả ở mức 12GB và duy trì hầu hết kiến thức của nó lên đến 16GB. Đồng thời, trên các luồng Reddit, nhiều người phàn nàn rằng tất cả các bản lượng tử hóa, ngay cả bản 8-bit, đều cho kết quả tệ hơn - với những câu hỏi tại sao LLM cục bộ của bạn lại có vẻ "ngu ngốc" hơn thực tế. Liệu những lời phàn nàn này có cơ sở không?
Việc đo lường sự khác biệt trong dự đoán token (KL-divergence, dự đoán top-1) thì dễ, nhưng nó không cho chúng ta biết liệu mô hình có trở nên kém hơn trong việc giải quyết các tác vụ hay không. Một số nhiễu có thể không liên quan đến việc giải quyết tác vụ, ví dụ như một mô hình đã lượng tử hóa tạo ra câu trả lời có chất lượng chính xác như nhau nhưng được diễn đạt lại một chút. Trong các trường hợp khác, chỉ cần một token khác biệt cũng có thể dẫn đến lỗi logic, hoặc thậm chí làm kết thúc đầu ra đột ngột.
[Biểu đồ: 70% 80% 90% 100% 6 10 20 30 50 GB kích thước mô hình trên đĩa, cùng token top-1 như BF16, UD-IQ1_S, UD-IQ1_M, UD-Q2_K_XL, Q4_K_M, Q8_0, BF16]
Vì vậy, tôi tập trung vào việc đo lường trực tiếp kết quả trên các benchmark phổ biến - GPQA Diamond, benchmark tuân thủ chỉ dẫn IFBench, và benchmark lập trình Terminal-Bench 2.1. Đầu tiên là để tái lập kết quả chính thức của mô hình BF16 đầy đủ, sau đó là xem việc lượng tử hóa ảnh hưởng đến kết quả như thế nào.
Tôi đã tiêu tốn khoảng 3.000 USD cho các GPU trên Modal khi chạy các mô hình với llama.cpp sử dụng bản build ngày 16 tháng 8 năm 2026, vì các bản build cũ hơn không hoạt động với mô hình này. Về nguyên tắc, tôi có thể chạy nó trên máy tính xách tay của mình, nhưng (không giống như việc tạo hình bồ nông), đây là những benchmark tốn rất nhiều thời gian.
Lưu ý rằng tôi sử dụng F16 KV-cache bất kể mô hình được lượng tử hóa như thế nào, nặng khoảng 2.3 GB cho mỗi 32k token.
Tôi đã sử dụng các bản lượng tử hóa của Unsloth: v2 cho các mô hình 2-, 4- và 8-bit, và v3 cho các mô hình 1-bit. Unsloth đã thay thế các tệp v2 vào ngày 19 tháng 8 năm 2026, vì vậy các tệp chính xác được sử dụng cho hầu hết các thử nghiệm hiện không còn khả dụng.
Tóm lại, nếu bạn chọn bản lượng tử hóa 4-bit Q4_K_M (17GB), bạn sẽ không nhận thấy sự khác biệt trên các benchmark này. Đồng thời, mức độ nỗ lực (effort setting) rất quan trọng (lưu ý rằng mặc định là xhigh) - và đây là một lựa chọn khó khăn vì nó có thể dẫn đến việc suy nghĩ quá mức (overthink).
Các thử nghiệm một lần (One-shot tests)
Dễ dàng nhất là các thử nghiệm một lần: trong trường hợp này là khoa học trình độ đại học GPQA Diamond và tuân thủ chỉ dẫn IFBench. Tôi chạy mỗi bài ở ba mức độ nỗ lực suy luận: thấp (low), trung bình (medium) và mặc định là xhigh.
GPQA Diamond
[Biểu đồ: 70% 75% 80% 85% 90% 95% 100% 10 20 30 50 GB kích thước mô hình trên đĩa, điểm số GPQA Diamond, xhigh (mặc định), báo cáo bởi Qwen, thấp, trung bình, UD-Q2_K_XL, Q4_K_M, Q8_0, BF16]
Trước hết, tôi rất vui vì đã tái lập được các kết quả chính thức. Việc chạy benchmark rất khó; có nhiều cài đặt hoặc giả định ẩn có thể thay đổi kết quả một cách đáng kể. Ở đây, ngay lần thử đầu tiên, kết quả đã đúng như những gì Qwen báo cáo.
Thứ hai, ngoài nhiễu (các thanh là khoảng tin cậy Wilson 95%, rất thận trọng đối với nhiễu giữa các lần chạy), có rất ít sự khác biệt xuống đến mức 4-bit; chỉ có bản 2-bit là đạt điểm thấp hơn một chút.
Đồng thời, mức độ suy nghĩ đã thay đổi điểm số một cách đáng kể. Kết quả tốt nhất, đối với xhigh, cần khoảng 8k token suy luận.
IFBench
[Biểu đồ: 60% 80% 10 20 30 50 GB kích thước mô hình trên đĩa, IFBench tuân thủ (nghiêm ngặt), xhigh (mặc định), báo cáo bởi Qwen, trung bình, thấp, UD-Q2_K_XL, Q4_K_M, Q8_0, BF16]
Ở đây, điều làm tôi rất ngạc nhiên là không có sự thay đổi nào giữa các mô hình, xuống đến tận bản 2-bit khá tốt, nặng dưới 11 GB. Tuy nhiên, ngữ cảnh thậm chí còn thấp hơn, khoảng 4k token.
Lập trình Agent và Terminal-Bench 2.1
Nó hoạt động như thế nào đối với lập trình? Terminal-Bench 2.1 là một benchmark agent tiêu chuẩn với 89 tác vụ. Ở đây tôi sử dụng thời gian chờ 3 giờ, mức nỗ lực xhigh. Tôi dành riêng 98k ngữ cảnh.
[Biểu đồ: báo cáo bởi Qwen 55% 60% 65% 70% 75% 80% 10 20 30 40 50 GB kích thước mô hình trên đĩa (thang log), Terminal-Bench 2.1 đã vượt qua, UD-Q2_K_XL, Q4_K_M, BF16]
Không chỉ phép đo của tôi về BF16 tái lập kết quả đã nêu, mà đáng ngạc nhiên là Q4_K_M cũng vậy. Tôi vô tình bỏ qua việc chạy Q8_0; tuy nhiên, trong trường hợp này, tôi có thể nội suy một cách an toàn giữa 4-bit và các giá trị của mô hình đầy đủ. Việc chạy nó sẽ vừa tốn kém vừa không cần thiết (và sẽ vượt quá ngân sách của một bài blog thông thường). Chỉ ở mức 2-bit UD-Q2_K_XL, mọi thứ mới bắt đầu suy giảm một chút. Một sự sụt giảm đáng chú ý, nhưng vẫn ở mức của Opus 4.7 hoặc Gemini 3.1 Pro. Một lần nữa, còn xa mới là đỉnh cao, nhưng cũng - còn lâu mới vô dụng.
Kết quả là một chuyện, nhưng còn quá trình thì sao? Các mô hình nhỏ hơn có cần nhiều lượt, token hoặc thời gian hơn để đạt được kết quả không?
[Biểu đồ: giống như BF16 0.8x 1.0x 1.2x 1.4x 1.6x 1.8x output tokens so với BF16, cùng tác vụ đã giải quyết, UD-Q2_K_XL Terminal-Bench 2.1 lượt GPQA Diamond IFBench Q4_K_M Terminal-Bench 2.1 lượt GPQA Diamond IFBench Q8_0 GPQA Diamond IFBench]
Trên cùng các tác vụ đã giải quyết, UD-Q2_K_XL mất số lượt tương đương với BF16 nhưng viết nhiều hơn khoảng một phần tư số token. Số lượt vẫn giữ nguyên gần như tương đương.
Vực thẳm 1-bit
Chất lượng sụt giảm nghiêm trọng ở mức 1-bit. Giống như kiến thức, thiệt hại do lượng tử hóa là phi tuyến tính: ban đầu không có thay đổi đáng kể nào, sau đó là sự suy giảm nhỏ, và cuối cùng là sụp đổ hoàn toàn.
Trong khi các bản lượng tử hóa 2-bit hoạt động ở một mức độ nào đó, thì ngay cả mô hình 1-bit tốt nhất cũng vô dụng đối với các benchmark này:
[Biểu đồ: 0% 20% 40% 60% 80% 100% thấp trung bình xhigh mức nỗ lực suy luận (xhigh là mặc định của mô hình) điểm số GPQA Diamond Q4_K_M báo cáo bởi Qwen UD-Q2_K_XL UD-IQ1_M đoán ngẫu nhiên UD-IQ1_S]
Như bạn có thể thấy, điểm số nằm ở mức đoán ngẫu nhiên, với mô hình nhỏ nhất còn thấp hơn cả ngưỡng đó. Và việc suy luận dài hơn làm cho nó tệ hơn: ở mức xhigh, điểm số giảm xuống dưới mức thấp, vì mô hình thường xuyên suy luận cho đến khi hết ngân sách token và trả về một câu trả lời trống. Chắc chắn, Unsloth tự hào rằng:
Chúng tôi cũng đã tạo ra một số bản lượng tử hóa 1-bit nhỏ hơn với UD-IQ1_S nặng 6.2GB (không có MTP), giữ lại khoảng 72% độ chính xác top-1 nhưng nhỏ hơn 89%.
Nhưng trong trường hợp này, 28% còn lại đó rất quan trọng. Và điều này khớp với trải nghiệm của một người dùng khác, xem Qwen3.8 27b 1bit brain damage quant trên r/LocalLLaMA.
Chi phí
Chạy các benchmark này không hề rẻ. Chạy benchmark qua API rất tốn kém, như tôi đã biết từ các benchmark trước đây của mình. Chạy trên GPU thuê còn tốn kém hơn nhiều.
Bài viết được AI dịch và tổng hợp tự động từ Hacker News Nổi bật (buzzing.cc bản dịch tiếng Trung). Liên kết bài gốc ở phía trên. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.