Qwen3.8 27B tại 256K trên GPU 24 GB RTX PRO 4000 SFF (432 GB/s): 50 tok/s với MTP

Một thử nghiệm cực kỳ chi tiết từ blog piszczek.pl vừa gây chú ý trong cộng đồng AI khi kỹ sư Michał Piszczek thành công chạy mô hình dense 27B tham số với ngữ cảnh đầy đủ 262.144 token trên một GPU Blackwell chỉ có 24 GB VRAM. Điểm nhấn không chỉ là con số 50 token/giây ấn tượng mà còn là chuỗi quyết định tối ưu hóa thông minh: từ việc từ chối lượng tử hóa NVFP4 có sẵn, tự hiệu chỉnh bộ trọng số lai, đến việc chọn bộ dự thảo MTP có "độ chính xác thấp hơn" để tăng tốc tổng thể.

Hệ thống cuối cùng trung bình đạt 50,44 tok/s trong loạt benchmark sản xuất 10 lần chạy, và khi so sánh trực tiếp cùng khối lượng công việc, bản llama.cpp tùy chỉnh nhanh hơn 21,97% so với bản master sạch. Điều đặc biệt: ở đầu xa của cache 261,5K token thực sự được lấp đầy, mô hình vẫn tạo ra 12,61 token/giây mà không gặp lỗi hết bộ nhớ.

Mục tiêu và phần cứng: Sự kết hợp "bất hợp lý" nhưng có chủ đích

Mô hình Qwen3.8 27B thuộc họ dense với 64 lớp, trong đó có 48 lớp Gated DeltaNet (tái phát) và 16 lớp attention truyền thống. Điều này có nghĩa chỉ 16 lớp attention mới phát triển bộ nhớ cache KV theo độ dài chuỗi, giúp việc xử lý 256K token trở nên khả thi hơn.

Phần cứng sử dụng hai GPU:

• GPU0: RTX PRO 4000 Blackwell SFF, 24 GB GDDR7 ECC, băng thông 432 GB/s, chứa mô hình chính, MTP nhúng, trạng thái tái phát và KV cache 256K.
• GPU1: RTX 2000 Ada, 16 GB, dành cho bộ chiếu đa phương thức F16 (vision) và các dịch vụ phụ trợ.

Với vectơ Q4_K và V, cache KV cho 256K tiêu tốn khoảng 4,25 GiB. Phần còn lại là các checkpoint trạng thái tái phát, và tác giả phát hiện ra rằng chỉ cần 4 checkpoint là đủ, thay vì mặc định 32.

Bài học đầu tiên: Lượng tử hóa nhanh không phải là lượng tử hóa tốt nhất

Cuộc thử nghiệm bắt đầu với các tệp GGUF công khai. Kết quả ban đầu khiến người ta bất ngờ: Q4_0 nhanh hơn hẳn các biến thể khác nhờ kernel CUDA phù hợp, đạt 44,95 tok/s với MTP, nhưng chất lượng lại kém. Điểm perplexity trên WikiText-2 là 6,3798 so với 6,1175 của IQ4_XS.

Ở chiều ngược lại, Q4_1 cho chất lượng tốt nhất (6,1127 PPL) nhưng chiếm quá nhiều bộ nhớ, không đủ chỗ cho vision và 256K context. Tác giả nhấn mạnh: "Nhãn lượng tử hóa không mô tả kernel CUDA thực sự chạy".

NVFP4 có sẵn: Thất bại về chất lượng và bài học về chuyển đổi trọng số

Blackwell hỗ trợ phần cứng FP4, vì vậy một tệp GGUF NVFP4-MEDIUM có sẵn trông rất hợp lý. Nó đạt 40,46 tok/s và phù hợp với toàn bộ hồ sơ 256K plus vision. Tuy nhiên, PPL của nó là 6,4949 — tệ hơn cả Q4_0. Nguyên nhân: quy trình chuyển đổi đã ép tất cả trọng số, kể cả các phần nhạy cảm của mô hình, xuống NVFP4.

Thất bại này dẫn đến thiết kế lượng tử hóa tùy chỉnh: dùng NVFP4 cho các ma trận lớn "dễ tính", nhưng bảo vệ các tensor nhạy cảm như attention, DeltaNet bằng Q5_K/Q6_K, embedding bằng Q6_K và output head bằng Q8_0.

Hiệu chỉnh iMatrix theo dữ liệu sử dụng thực tế

Điểm mấu chốt nằm ở việc hiệu chỉnh mô hình dựa trên dữ liệu thực tế của chính tác giả: 5.472 tin nhắn từ 296 phiên sử dụng Hermes, bao gồm lập trình, hội thoại Ba Lan và Anh, công việc hạ tầng, lời gọi công cụ. Bản quét bảo mật đảm bảo không có khóa API hay email nào bị lộ.

Bản hybrid đầu tiên (5,14 BPW) đạt chất lượng tốt nhất (6,0967 PPL) nhưng quá chậm (34,19 tok/s) và quá lớn. Bản thứ hai được siết lại:

• Kích thước: 16.321,38 MiB, 5,01 BPW
• PPL: 6,1197, gần bằng Q4_1 (6,1127) — chênh lệch 0,11% nằm trong sai số kiểm tra
• Nhanh hơn Q4_1 và đủ chỗ cho toàn bộ hệ thống

Đây là lúc tác giả rút ra công thức: NVFP4 cho phần lớn, bảo vệ các tensor nhạy cảm, và đặt dữ liệu hiệu chỉnh làm trung tâm.

MTP n=8: Điểm ngọt kỳ lạ của kernel

Bộ dự thảo MTP (Multi-Token Prediction) là công cụ tăng tốc chính. Quét sớm cho thấy n=3 là tốt nhất, nhưng khi tăng lên n=8, tốc độ bất ngờ nhảy vọt lên 49,31 tok/s. Sở dĩ có sự bất thường này là vì 8 ứng viên chạm được hình dạng batch và kernel thuận lợi.

Tuy nhiên, n=9 không nhanh hơn và mỗi ứng viên thêm tốn khoảng 150 MiB. Ở n=9 với đầy đủ 256K, một bộ đệm CUDA graph 162 MiB khiến quá trình nạp thất bại. Giảm ubatch xuống 128 giúp nạp được nhưng tốc độ giảm còn 52,70 tok/s và prefill 32K chậm hơn. Tác giả quyết định giữ n=8 vì đó là "điểm nhanh cuối cùng trước khi allocator bắt đầu cắn".

Bài học lớn: Độ chính xác của drafter không quan trọng bằng sự tương thích

Thử nghiệm quan trọng nhất: nâng cấp bộ trọng số MTP ngược lên Q5_K/Q6_K với hy vọng cải thiện độ chính xác. Kết quả ngược hoàn toàn:

MTP weights	Extra size	Mean TPS	Acceptance	Kết quả
NVFP4 (sản xuất)	baseline	50,44	48,33%	Giữ nguyên
iMatrix Q5_K	50,625 MiB	48,73	46,75%	-3,39%
Q5_K + Q6_K quan trọng	69,219 MiB	37,02	33,07%	-26,60%

Lời giải thích: NVFP4 drafter dự đoán các token phù hợp hơn với mục tiêu NVFP4-heavy, trong khi drafter chính xác hơn dự đoán các token "lý tưởng" mà mục tiêu lượng tử hóa không tạo ra. "Độ chính xác độc lập thua sự tương thích lượng tử hóa" — một triết lý mà mọi kỹ sư inference nên ghi nhớ.

DSpark: GPU phụ thứ hai vẫn thua MTP nhúng

Thử nghiệm với DSpark, một bộ dự thảo khuếch tán 1,36B chạy trên GPU1 trong khi mô hình chính trên GPU0, cho kết quả tối đa 26,49 tok/s — chậm hơn 46,6% so với MTP nhúng (49,61 tok/s). Lý do: DSpark được huấn luyện trên mục tiêu FP8, trong khi mô hình hiện tại là hỗn hợp NVFP4/Q5/Q6, cộng thêm chi phí traffic PCIe.

Bản llama.cpp tùy chỉnh: +21,97% so với bản master

Các bản vá được chọn lọc mang lại hiệu quả rõ rệt. Trong đó, bản vá Flash Attention riêng biệt cải thiện prefill 32K lên 7,41% (từ 759,38 lên 815,64 tok/s) và hot decode lên 2,61%. Hệ thống builder tự động từ chối xây dựng nếu có bất kỳ thay đổi nào trong các pull request liên quan, đảm bảo tính ổn định.

N-gram speculation bị tắt trong mọi bài benchmark A/B vì lặp lại prompt làm tăng giả tạo throughput từ 46,77 lên khoảng 180 tok/s. Tuy nhiên, trong sản xuất thực tế, nó được bật vì tác nhân (agent) thường lặp lại các đoạn mã, schema công cụ và tiền tố prompt — cực kỳ hữu ích.

Các con số cuối cùng được giữ lại

• Sản xuất, 10 lần chạy: 50,441 tok/s trung bình, dải 49,420–51,397
• So sánh A/B cùng khối lượng: 45,422 → 55,402 tok/s (+21,97%)
• Greedy target vs MTP: 21,189 → 59,456 tok/s (×2,81)
• Cache 261,5K đầy: 12,606 tok/s decode xa ngữ cảnh
• Prefill full context: 226,750 tok/s với 261.500 token đầu vào
• GPU0 gần đầy: 23.952 / 24.467 MiB, dư khoảng 515 MiB

Một lưu ý quan trọng về độ đúng đắn: MTP n=8 không bảo toàn phân phối bitwise. Hai chế độ greedy và MTP tạo ra các tiếp diễn khác nhau trên mục tiêu lượng tử hóa, khớp với vấn đề batch-invariance #25618 của llama.cpp. Nếu cần tính chất đó, dùng n=1.

Bài học cho cộng đồng Việt Nam và các kỹ sư LLM

Thử nghiệm này mang lại bốn bài học thực tiễn cho bất kỳ ai đang tối ưu mô hình ngôn ngữ lớn cục bộ:

1. Đừng tin vào nhãn lượng tử hóa. Hãy đo PPL và tốc độ thực tế trên chính dữ liệu và kernel bạn dùng. Q4_0 nhanh hơn Q4_K_M trong cùng một kịch bản — điều ngược với trực giác.
2. Lượng tử hóa lai là chìa khóa cho Blackwell. NVFP4 chỉ dùng cho các ma trận "dễ tính", còn các tensor nhạy cảm cần được bảo vệ. Việc chọn ma trận nhạy cảm nên dựa trên iMatrix hiệu chỉnh từ dữ liệu sử dụng thực tế, không phải chuẩn chung.
3. Tối ưu tích hợp quan trọng hơn tối ưu từng bộ phận. Bộ dự thảo MTP "kém chính xác" hơn lại cho kết quả tốt hơn vì nó tương thích với mục tiêu lượng tử hóa. Hãy luôn kiểm tra drafter với chính mục tiêu của bạn, ngay từ ngày đầu.
4. Benchmark dài ngữ cảnh phải trung thực. Chỉ tải 256K lên là chưa đủ; phải thực sự lấp đầy cache, tạo token ở đầu xa, ghi lại VRAM và công bố mọi hạn chế.

Với việc các dòng card RTX PRO và RTX Blackwell ngày càng phổ biến tại Việt Nam trong giới nghiên cứu và khởi nghiệp AI, những kỹ thuật này hoàn toàn có thể áp dụng để chạy các mô hình 27B tham số với chi phí thấp, mở ra cơ hội xây dựng các tác nhân AI cục bộ mà không cần phụ thuộc hoàn toàn vào đám mây.