Hướng dẫn mô hình và phương thức6 tháng 11, 2026Flatkey Team

Lượng tử hóa vLLM: Chọn định dạng, tính bộ nhớ GPU và xác thực thông lượng

Hướng dẫn thực tế để chọn định dạng lượng tử hóa vLLM, ước tính bộ nhớ GPU và so sánh độ trễ, thông lượng तथा chất lượng trước khi triển khai.

Lượng tử hóa vLLM: Chọn định dạng, tính bộ nhớ GPU và xác thực thông lượng

Lượng tử hóa vLLM có thể giúp một mô hình vừa với ít bộ nhớ GPU hơn, nhưng không phải là công tắc tăng tốc áp dụng cho mọi trường hợp. Một checkpoint nhỏ hơn có thể để lại nhiều chỗ hơn cho bộ nhớ đệm KV và các yêu cầu đồng thời. Thông lượng thực tế phụ thuộc vào mô hình, định dạng lượng tử hóa, kiến trúc GPU, kernel, độ dài prompt, độ dài đầu ra và mẫu lưu lượng. Quyết định hợp lý là chọn một định dạng được hỗ trợ, sau đó đo lường khối lượng công việc mang tính đại diện so với đường cơ sở không lượng tử hóa.

Hướng dẫn về lượng tử hóa vLLM này cung cấp cho bạn quy trình lựa chọn và kiểm thử thực tế. Hướng dẫn này không tuyên bố kết quả benchmark cho GPU hoặc mô hình mà chúng tôi chưa kiểm thử.

Lượng tử hóa vLLM thay đổi những gì

Lượng tử hóa lưu trữ một số giá trị của mô hình bằng ít bit hơn so với checkpoint FP16 hoặc BF16 thông thường. Tác động bậc một rõ ràng nhất là giảm bộ nhớ trọng số. Nếu bộ nhớ trọng số là lý do khiến một mô hình không thể vừa, một checkpoint lượng tử hóa tương thích có thể cho phép mô hình chạy trên GPU nhỏ hơn hoặc còn nhiều bộ nhớ hơn cho các yêu cầu. GPU vẫn cần bộ nhớ cho activation, bộ nhớ đệm KV, chi phí thời gian chạy và mọi worker song song. Vì vậy, lấy số lượng tham số chia cho số bit trên mỗi trọng số chỉ là cận dưới sơ bộ, không phải ước tính bộ nhớ có thể triển khai.

Có hai hướng phổ biến cho lượng tử hóa vLLM. Bạn có thể tải một checkpoint đã được lượng tử hóa trước, hoặc sử dụng quy trình lượng tử hóa trực tuyến được hỗ trợ tại thời điểm tải. Trong cả hai trường hợp, hãy kiểm tra model card và ma trận tương thích vLLM hiện tại trước khi chọn định dạng. Tài liệu lượng tử hóa vLLM là nguồn tham chiếu chính xác cho các phương pháp và hỗ trợ phần cứng; tài liệu này nêu rõ rằng ma trận thay đổi khi mức hỗ trợ phát triển.

Chọn định dạng dựa trên checkpoint và GPU

Tùy chọn Điểm khởi đầu thực tế Xác minh trước khi triển khai
AWQ Một mô hình được phân phối dưới dạng checkpoint AWQ và GPU tương thích Chất lượng mô hình, lựa chọn kernel, độ dài prompt và độ trễ thực tế.
GPTQ Một mô hình được phân phối dưới dạng checkpoint GPTQ Cấu hình checkpoint chính xác, phiên bản vLLM, hỗ trợ GPU và suy giảm chất lượng.
FP8 Một checkpoint tương thích và GPU có khả năng thực thi FP8 được hỗ trợ Liệu cách triển khai vLLM đã chọn có hỗ trợ kiến trúc và các lớp mô hình của bạn hay không.
GGUF Một mô hình đã được phân phối ở định dạng GGUF Kiến trúc cụ thể và hỗ trợ tính năng của vLLM; không giả định hành vi của Ollama ánh xạ một-một.
BitsAndBytes hoặc tensor nén Một checkpoint và quy trình triển khai yêu cầu rõ ràng chúng Các phụ thuộc thời gian chạy, hành vi tải, kernel được hỗ trợ và thông lượng.

Ma trận vLLM hiện tại liệt kê AWQ và GPTQ cho Ampere, Ada và Hopper. Ma trận liệt kê FP8 thông qua llm-compressor cho Ada, Hopper và một số quy trình GPU AMD, trong khi GGUF có mô hình hỗ trợ khác. A100 là GPU Ampere và H100 là GPU Hopper, nhưng mức hỗ trợ phụ thuộc vào từng phương pháp. Đừng suy luận rằng mọi biến thể FP8, FP4 hoặc Marlin đều hoạt động trên mọi card trong một họ. Hãy kiểm tra hàng chính xác trong bảng tương thích phần cứng và metadata riêng của checkpoint.

Nếu bạn chưa chọn mô hình, hãy so sánh hai checkpoint ứng viên sử dụng cùng mô hình cơ sở và tập đánh giá. So sánh mô hình AWQ từ một họ với mô hình không lượng tử hóa từ họ khác sẽ làm nhiễu lẫn lượng tử hóa vLLM với chất lượng mô hình.

Quy trình triển khai tránh các kết quả thắng lợi giả

  1. Xác định mục tiêu dịch vụ. Ghi lại mô hình, độ dài ngữ cảnh, độ dài đầu vào và đầu ra dự kiến, số yêu cầu đồng thời, mục tiêu độ trễ p95 và các bài kiểm tra chất lượng. Chatbot, bộ phân loại theo lô và tác tử ngữ cảnh dài có các nút thắt khác nhau.
  2. Ghi lại đường cơ sở. Chạy checkpoint không lượng tử hóa trên cùng GPU và phiên bản vLLM. Thu thập bộ nhớ GPU đỉnh, thời gian đến token đầu tiên, thông lượng token đầu ra, độ trễ p50/p95 đầu-cuối, lỗi và tỷ lệ kết quả được chấp nhận.
  3. Chọn checkpoint lượng tử hóa tương thích. Đọc model card của nó và ma trận phương pháp hiện tại của vLLM. Cố định bản sửa đổi checkpoint, phiên bản vLLM, ngăn xếp CUDA/driver và SKU phần cứng trong bản ghi kiểm thử.
  4. Bắt đầu bằng một canary nhỏ. Xác nhận mô hình tải được, phục vụ endpoint và các thiết lập tạo sinh bắt buộc của bạn, đồng thời tạo ra đầu ra hợp lý trước khi áp dụng lưu lượng.
  5. Benchmark ở nhiều mức độ đồng thời. Đo lường với độ dài prompt và phản hồi thực tế của bạn. Một yêu cầu đơn lẻ có thể ưu ái cấu hình khác với việc phục vụ liên tục.
  6. Chạy cùng bộ kiểm thử chất lượng. Lượng tử hóa có thể thay đổi đầu ra. Hãy đánh giá tính đúng đắn theo miền, khả năng tuân thủ định dạng, các phản hồi từ chối và các trường hợp nhạy cảm về an toàn thay vì chỉ tin vào perplexity.
  7. Tính chi phí trên mỗi kết quả được chấp nhận. Giá GPU theo giờ chia cho số token thô mỗi giây là chưa đủ nếu mô hình lượng tử hóa thất bại ở nhiều tác vụ hơn hoặc cần thử lại.

Đối với benchmark phục vụ, vLLM có tài liệu về vllm bench serve cùng các tùy chọn tập dữ liệu và endpoint trong hướng dẫn CLI benchmark chính thức. Hãy sử dụng tập dữ liệu lưu lượng phù hợp với ứng dụng của bạn; các prompt ngẫu nhiên tổng hợp hữu ích cho các so sánh có kiểm soát nhưng không nên được trình bày như hiệu năng môi trường sản xuất.

Lập kế hoạch bộ nhớ: trọng số chỉ là một hạng mục

Một bảng tính lập kế hoạch đơn giản tách thành bốn nhóm:

tổng bộ nhớ GPU cần thiết ≈ trọng số mô hình + bộ nhớ đệm KV + chi phí chạy/kích hoạt + phần dự phòng an toàn

Định dạng lượng tử hóa chủ yếu thay đổi thành phần trọng số mô hình. Áp lực lên bộ nhớ đệm KV tăng theo độ dài ngữ cảnh và số chuỗi đang hoạt động. Một mô hình vừa đủ cho một yêu cầu vẫn có thể thất bại hoặc chậm đi đáng kể khi xử lý lưu lượng đồng thời với ngữ cảnh dài. Trên các thiết lập đa GPU, song song tensor thay đổi cả bộ nhớ trên mỗi card lẫn chi phí giao tiếp; checkpoint nhỏ nhất có thể không tự động là phương án triển khai rẻ nhất.

Trước khi thuê GPU, hãy xác định liệu bạn cần chứa vừa một mô hình lớn hơn, tăng mức đồng thời cho một mô hình nhỏ hơn, hay giảm chi phí trong khi vẫn duy trì chất lượng. Câu trả lời sẽ quyết định sự đánh đổi giữa bộ nhớ và thông lượng nào là quan trọng. Cloud GPU Compute của Flatkey liệt kê các tùy chọn thuê GPU và yêu cầu khách hàng xác nhận cấu hình, khu vực, dung lượng và điều khoản thuê. Hãy coi tình trạng sẵn có và giá theo thời điểm thực tế là các đầu vào tại thời điểm báo giá, không phải các con số cố định trong một bài viết benchmark.

Đánh giá công bằng việc lượng tử hóa vLLM

Giữ cố định mô hình cơ sở, tham số sinh, tập prompt, giới hạn đầu ra, trạng thái bộ nhớ đệm và GPU. Đo ít nhất ba mức tải: một yêu cầu đơn lẻ để đánh giá độ phản hồi, mức đồng thời đại diện cho môi trường sản xuất và một điểm chịu tải nơi độ trễ bắt đầu suy giảm. Báo cáo cả tổng thông lượng lẫn độ trễ p95. Nếu bạn chỉ báo cáo số token mỗi giây khi bão hòa, người dùng sẽ không thể biết liệu các yêu cầu tương tác còn chấp nhận được hay không.

Đưa chất lượng mô hình vào bảng đánh giá:

Chỉ số Lý do quan trọng
Bộ nhớ GPU đỉnh Cho biết liệu lượng tử hóa có tạo ra phần dung lượng dự phòng có thể sử dụng hay không.
Thời gian đến token đầu tiên Quan trọng đối với các giao diện streaming.
Token đầu ra mỗi giây Cho biết thông lượng sinh, nhưng không cho biết chất lượng tác vụ.
Độ trễ đầu cuối p95 Cho thấy hành vi ở phần đuôi khi có tải.
Tỷ lệ lỗi và OOM Phát hiện cấu hình trông có vẻ nhanh chỉ khi các yêu cầu thành công.
Tỷ lệ kết quả được chấp nhận Chuyển đổi tốc độ thô thành công việc hữu ích.

So sánh then chốt đối với lượng tử hóa vLLM không phải là “đã lượng tử hóa so với chưa lượng tử hóa” một cách trừu tượng. Đó là “checkpoint và kernel này trên GPU này, với khối lượng công việc này, so với đường cơ sở của chúng tôi.” Hãy công bố các điều kiện cùng với mọi kết quả. Nếu bài kiểm tra của bạn thiếu bước kiểm tra chất lượng, hãy gọi đó là một thử nghiệm chỉ về hiệu năng.

Các dạng lỗi thường gặp

Mô hình không tải được. Kiểm tra siêu dữ liệu checkpoint, phương pháp lượng tử hóa, phiên bản vLLM, khả năng GPU và liệu phương pháp đó có hỗ trợ mọi lớp được kiến trúc sử dụng hay không. Cần kiểm tra ma trận phương pháp vLLM trước khi thay đổi các cờ lệnh một cách mù quáng.

Tiết kiệm bộ nhớ không cải thiện độ trễ. Dung lượng trọng số nhỏ hơn không đảm bảo kernel nhanh hơn. Hãy kiểm tra ở mức đồng thời mục tiêu và xem xét thời gian đến token đầu tiên, tốc độ giải mã và mức sử dụng GPU. Dung lượng dự phòng lớn hơn cho bộ nhớ đệm KV có thể mới là lợi ích thực sự.

Một checkpoint ít bit trông có vẻ nhanh nhưng không vượt qua các kiểm tra chất lượng. Duy trì một tập chấp nhận cho môi trường sản xuất và đo tỷ lệ đầu ra đáp ứng các tiêu chí ứng dụng của bạn. Ngưỡng rollback cần được đặt trước khi canary.

Không thể tái tạo benchmark. Ghi lại các bản sửa đổi mô hình và checkpoint, phiên bản vLLM và driver, SKU GPU, tập dữ liệu, mức đồng thời, độ dài prompt, độ dài đầu ra và đối số lệnh. Không có những thông tin này, một con số thông lượng chỉ là tiếp thị thay vì bằng chứng kỹ thuật.

Khi nào nên dùng Flatkey Cloud GPU

Nếu bạn cần chạy máy chủ vLLM của riêng mình và so sánh các checkpoint đã lượng tử hóa, hãy chọn dung lượng GPU dựa trên yêu cầu bộ nhớ và mức đồng thời đã được đo lường. Flatkey cung cấp các tùy chọn thuê GPU NVIDIA thông qua Cloud GPU Compute. Hãy xác nhận SKU hiện có, khu vực triển khai, dung lượng, giá và điều khoản dịch vụ trước khi cam kết. Bài kiểm tra lượng tử hóa vLLM nên được thực hiện trên cấu hình mà bạn thực sự dự định thuê. Nếu bạn cần một API mô hình được quản lý thay vì vận hành vLLM, hãy đánh giá riêng tuyến API và danh mục mô hình của Flatkey; đó là một mô hình vận hành khác.

Để tham khảo các quyết định triển khai liên quan, xem hướng dẫn triển khai vLLM, hướng dẫn suy luận vLLM đa GPU và so sánh vLLM với Ollama của chúng tôi.

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

Lượng tử hóa vLLM có luôn làm suy luận nhanh hơn không?

Không. Nó có thể giảm bộ nhớ trọng số, nhưng độ trễ và thông lượng phụ thuộc vào checkpoint, kernel, GPU, độ dài chuỗi và tải yêu cầu. Hãy benchmark một khối lượng công việc thực tế với đường cơ sở.

Tôi có thể dùng AWQ trên A100 hoặc H100 không?

Ma trận tương thích vLLM hiện tại liệt kê hỗ trợ AWQ cho Ampere và Hopper, bao gồm A100 và H100. Hãy kiểm tra checkpoint chính xác, phiên bản vLLM hiện tại và kiến trúc mô hình trước khi triển khai.

FP8 có được hỗ trợ trên mọi GPU NVIDIA không?

Không. Khả năng hỗ trợ khác nhau tùy theo cách triển khai lượng tử hóa và kiến trúc. Ma trận hiện tại phân biệt các phương pháp như llm-compressor FP8 và Marlin; hãy xác minh hàng chính xác dành cho phần cứng của bạn.

Tôi nên lượng tử hóa trước hay sau khi chọn GPU?

Trước tiên, hãy xác định quy mô khối lượng công việc và mục tiêu chất lượng, sau đó kiểm thử các checkpoint ứng viên trên GPU tương thích. Cần đánh giá lựa chọn định dạng và phần cứng cùng với nhau.