vLLM vượt qua SGLang với các prompt 64K token, nhưng SGLang lại bứt phá khi ngữ cảnh đạt tới 200K trên máy chủ 8-GPU B300. Sự thay đổi này cho thấy các nút thắt ở giai đoạn decode, chứ không phải công việc prefill, mới là yếu tố quyết định hiệu suất khi cửa sổ token mở rộng.
Tại sao bài kiểm tra hiệu năng (benchmark) này lại quan trọng
Suy luận ngữ cảnh dài (long-context inference) là yếu tố chính quyết định chi phí cho các trợ lý chat, trợ lý lập trình và bất kỳ ứng dụng nào cần duy trì hàng trăm nghìn token trong bộ nhớ. Kimi-K3, một mô hình có tham số lớn, là một trong những LLM trọng số mở (open-weight) đầu tiên có thể xử lý thoải mái các cửa sổ ngữ cảnh như vậy, nhưng chính công cụ (engine) chạy mô hình đó sẽ quyết định xem một yêu cầu sẽ hoàn thành trong vài giây hay vài phút.
Cả vLLM và SGLang đều hứa hẹn khả năng suy luận thông lượng cao (high-throughput), nhưng chúng lại áp dụng các phương pháp tiếp cận trái ngược nhau ở giai đoạn decode. vLLM giữ cho đường dẫn decode đơn giản, tránh việc đồng bộ hóa bổ sung mà Decode Context Parallelism (DCP) gây ra. SGLang phân tán việc đọc bộ nhớ đệm key-value (KV cache) trên nhiều GPU bằng cách sử dụng DCP, một kỹ thuật có thể tối ưu hóa băng thông bộ nhớ nhưng phải đánh đổi bằng việc tăng thêm giao tiếp giữa các GPU.
Môi trường thử nghiệm
- Phần cứng: một máy chủ duy nhất với tám GPU NVIDIA B300, mỗi GPU có bộ nhớ giống hệt nhau.
- Khối lượng công việc: hai thiết lập độ dài ngữ cảnh – 64K token (ngưỡng dưới của “ngữ cảnh dài”) và 200K token (ngưỡng trên mà nhiều bản demo nghiên cứu hướng tới).
- Chỉ số: tổng thời gian để xử lý một batch prompt cố định; thông lượng (throughput) được tính toán từ sự chênh lệch thời gian.
Chúng tôi giữ nguyên kích thước batch, trọng số mô hình và mục tiêu sử dụng bộ nhớ. Biến số duy nhất mà chúng tôi thay đổi giữa các lần chạy là công cụ suy luận (inference engine).
Các con số thực tế
| Ngữ cảnh | Engine | Thời gian (s) | Tốc độ tương đối |
|---|---|---|---|
| 64K | vLLM | 100.5 | – |
| SGLang | 150.8 | vLLM ≈ 1.5 lần nhanh hơn | |
| 200K | vLLM | 295.2 | – |
| SGLang | 225.3 | SGLang ≈ 1.31 lần nhanh hơn |
Thông lượng (tokens mỗi giây) của vLLM giảm mạnh khi ngữ cảnh tăng lên: giảm 3.29 lần từ 64K lên 200K. Thông lượng của SGLang chỉ giảm 1.25 lần trong cùng phạm vi đó.
Nguyên nhân dẫn đến sự chênh lệch
Cả hai engine đều dành một lượng thời gian tương đương cho giai đoạn prefill – nạp prompt vào KV cache. Sự phân tách xuất hiện ở giai đoạn decode, nơi mô hình tạo ra các token theo từng bước một.
- 64K token: giao tiếp giữa các GPU chiếm ưu thế. Đường dẫn decode trên một GPU của vLLM tránh được việc đồng bộ hóa bổ sung mà DCP yêu cầu, giúp nó hoàn thành nhanh hơn khoảng 1.5 lần.
- 200K token: KV cache trở nên lớn đến mức việc đọc nó trở thành nút thắt cổ chai. DCP của SGLang, được thiết lập ở kích thước 8, phân tán các lượt đọc đó trên cả tám GPU. Lợi ích về băng thông vượt xa chi phí giao tiếp, giúp SGLang dẫn trước rõ rệt.
Một quan sát thực tế phụ liên quan đến áp lực bộ nhớ. Việc chạy bất kỳ engine nào với mục tiêu sử dụng bộ nhớ là 0.95 đã gây ra các lần thử lại do lỗi hết bộ nhớ (OOM) trên các chip B300. Việc giảm mục tiêu xuống 0.92 đã loại bỏ các lần thử lại này và ổn định thời gian chạy, đổi lại là sự gia tăng nhẹ về độ trễ (latency).
Ai thắng, ai thua
- Các nhà phát triển với ngữ cảnh ngắn đến trung bình (≤ 64K token) sẽ hưởng lợi nhiều hơn từ đường dẫn decode tinh gọn của vLLM. Thời gian phản hồi nhanh hơn đồng nghĩa với hóa đơn điện toán đám mây thấp hơn và vòng lặp trải nghiệm người dùng chặt chẽ hơn.
- Các đội ngũ xây dựng công cụ phân tích sâu hoặc nghiên cứu cần duy trì hàng trăm nghìn token trong ngữ cảnh nên nghiêng về SGLang với DCP được bật. Thông lượng ổn định hơn của nó giúp giảm rủi ro hết thời gian chờ (time-out) và giữ cho hiệu suất sử dụng GPU cao hơn khi nhu cầu bộ nhớ tăng lên.
- Các nhà hoạch định phần cứng thấy rằng chỉ riêng số lượng GPU thô không đảm bảo khả năng mở rộng tuyến tính. Khi băng thông KV trở thành điểm nghẽn, các kiến trúc có thể song song hóa việc đọc bộ nhớ đệm – thông qua DCP hoặc các nâng cấp hệ thống bộ nhớ trong tương lai – sẽ khai thác được nhiều giá trị hơn từ cùng một lượng silicon.
Ý kiến phản biện: liệu vLLM có thể thu hẹp khoảng cách?
Cho đến khi có dữ liệu mới, các con số hiện tại vẫn là sự so sánh công khai tốt nhất.
Điều cần theo dõi tiếp theo
- Các cửa sổ ngữ cảnh lớn hơn sẽ gây áp lực lên băng thông KV nhiều hơn nữa, có khả năng nới rộng khoảng cách dẫn đầu của SGLang.
Kết luận
Khi bạn cần phục vụ các yêu cầu ngữ cảnh dài trên một cụm máy chủ dựa trên B300, hãy chọn engine phù hợp với cửa sổ token của bạn. Đối với khối lượng công việc 64K token, vLLM mang lại tốc độ suy luận nhanh hơn khoảng 1.5 lần. Nếu vượt quá 200K token, quá trình decode dựa trên DCP của SGLang sẽ trở thành lựa chọn hiệu quả hơn, với thông lượng chỉ giảm 1.25 lần so với mức giảm 3.29 lần của vLLM. Hãy điều chỉnh mức sử dụng bộ nhớ xuống 0.92 để tránh các lần thử lại do OOM, và hãy nhớ rằng engine "tốt nhất" phụ thuộc vào ngữ cảnh, chứ không phải là một giải pháp vạn năng cho mọi trường hợp.