vLLM là gì: 4 thông số PagedAttention tăng thông lượng GPU

vLLM là gì? Đó là thư viện phục vụ suy luận mô hình ngôn ngữ lớn, mã nguồn mở. Nó dùng PagedAttention để quản lý bộ nhớ KV cache gần như không lãng phí. Nhờ vậy, một GPU phục vụ được nhiều request cùng lúc hơn.

vLLM khởi đầu tại Phòng thí nghiệm Sky Computing, Đại học UC Berkeley. Dự án hiện có hơn 2.000 người đóng góp và hỗ trợ hơn 200 kiến trúc mô hình trên Hugging Face. Bài báo gốc nộp ngày 12/09/2023. Nó đo thông lượng vLLM cao hơn 2 đến 4 lần so với FasterTransformer và Orca, ở cùng mức độ trễ.

Thông số 1: --gpu-memory-utilization chia VRAM cho KV cache

Thông số này đặt tỷ lệ bộ nhớ GPU dành cho bộ máy thực thi. Giá trị nằm từ 0 đến 1. Đặt 0,5 nghĩa là dùng 50 phần trăm bộ nhớ GPU. Giới hạn này tính theo từng instance vLLM. Hai instance chạy chung một GPU có thể đặt 0,5 mỗi instance.

Mặc định khi không truyền cờ này là 1,0 với KV cache mở rộng, và 0,92 trong trường hợp còn lại. Con số này lấy từ tài liệu tham số engine của vLLM, đọc ngày 12/11/2026.

Quy tắc đặt giá trị này rất thực tế. Đặt quá cao thì không còn chỗ cho CUDA graph và phần mềm khác trên cùng GPU. Đặt quá thấp thì KV cache nhỏ, số request chạy song song giảm xuống. Đội vận hành nên đo thông lượng ở vài mức rồi mới chốt.

Thông số 2: --max-model-len giới hạn độ dài ngữ cảnh

Thông số này đặt độ dài ngữ cảnh tối đa của mô hình, tính cả prompt và output. Nếu không truyền, vLLM tự suy ra từ cấu hình mô hình. Truyền -1 hoặc auto nghĩa là chọn độ dài lớn nhất vừa với bộ nhớ GPU.

Cờ này chấp nhận định dạng con người đọc được như 1k hay 25.6k. Trong đó, 1k nghĩa là 1.000 còn 1K nghĩa là 1.024. Đội phục vụ nên đặt con số này theo prompt dài nhất thật sự cần. Đặt dài hơn nhu cầu chỉ làm KV cache phình to mà không thêm request nào.

Lưu ý: độ dài này là giới hạn của từng request, không phải tổng của cả batch. Request nào vượt giới hạn sẽ bị từ chối thay vì làm chậm cả hàng đợi.

Chú thích ảnh: Cận cảnh các quân cờ trên bàn cờ, minh họa cho việc sắp xếp tài nguyên GPU theo nước đi có tính toán. Ảnh: Tima Miroshnichenko, Pexels, giấy phép Pexels (link gốc xem mục Nguồn, phần Ảnh).

Thông số 3: --tensor-parallel-size chia mô hình qua nhiều GPU

Thông số này đặt số nhóm song song theo tensor, mặc định là 1. Khi đặt lớn hơn 1, mô hình được chia nhỏ và chạy trên nhiều GPU cùng lúc. Đây là cách chạy mô hình quá lớn cho một GPU duy nhất.

Chia tensor giúp mô hình vừa bộ nhớ và giảm độ trễ mỗi token. Nhưng nó thêm chi phí đồng bộ giữa các GPU. Vì vậy, chỉ tăng con số này khi mô hình thật sự không vừa một GPU, hoặc khi độ trễ mỗi token là nút thắt.

Tài liệu vLLM liệt kê song song theo tensor, pipeline, dữ liệu, expert và ngữ cảnh. Đội mới bắt đầu chỉ cần nhớ hai ý. Tensor parallel chia một mô hình qua nhiều GPU. Data parallel chạy nhiều bản sao mô hình để nhận nhiều request hơn.

Thông số 4: Continuous Batching gom yêu cầu liên tục

Continuous Batching là cách vLLM gom request đang chờ vào batch đang chạy, thay vì đợi batch cũ chạy xong mới nhận batch mới. Tài liệu chính của vLLM liệt kê tính năng này cùng chunked prefill và prefix caching.

Cơ chế này giải quyết đúng điểm yếu mà bài báo PagedAttention chỉ ra. Bộ nhớ KV cache của mỗi request vừa lớn vừa thay đổi liên tục theo độ dài sinh. Quản lý kém sẽ lãng phí bộ nhớ vì phân mảnh và trùng lặp, làm batch tối đa bị thu hẹp. PagedAttention mượn ý tưởng phân trang bộ nhớ của hệ điều hành để chia KV cache thành khối. Nhờ đó, bộ nhớ lãng phí gần bằng 0 và KV cache được chia sẻ linh hoạt trong và giữa các request.

Kết quả đo trong bài báo: thông lượng cao hơn 2 đến 4 lần so với hệ thống tốt nhất cùng thời. Mức so sánh giữ nguyên độ trễ. Mức cải thiện càng rõ với chuỗi dài, mô hình lớn và thuật toán giải mã phức tạp. Bài này không tự đo lại con số này. Đội nào cần số trên phần cứng của mình thì chạy benchmark của vLLM rồi mới chốt.

Bảng đối chiếu: vLLM, Ollama và TGI

Rủi ro và giới hạn khi vận hành vLLM

Rủi ro lớn nhất là hết bộ nhớ GPU khi batch tăng đột biến. Đặt gpu-memory-utilization quá cao thì không còn chỗ cho CUDA graph. Đặt max-model-len dài hơn nhu cầu thì KV cache phình to mà không thêm request nào. Giới hạn thứ hai là phiên bản. Tham số engine đổi theo phiên bản, nên đội vận hành cần khóa phiên bản vLLM trong file cấu hình. Giới hạn thứ ba là đo lường. Con số 2 đến 4 lần trong bài báo gốc đo trên phần cứng của nhóm tác giả, không phải trên máy của bạn.

Đọc thêm trên 3a.com.vn:

• Mô hình mã nguồn mở chạy trên máy cá nhân
• LM Studio vs Ollama: 7 khác biệt khi chạy AI trên máy
• Cách đọc bảng benchmark AI không bị đánh lừa

— Quang Minh, từ phòng đo kiểm 3A.