vLLM so với SGLang 2026: Chúng tôi đã đo hiệu năng cả hai trên H100

vLLM so với SGLang 2026: Chúng tôi đã đo hiệu năng cả hai trên H100

Hugging Face đã đưa TGI vào chế độ bảo trì vào tháng 12 năm 2025 và hiện đang hướng các đội kỹ thuật đến vLLM hoặc SGLang cho các lần triển khai mới. Nếu bạn đang thiết lập một hệ thống suy luận (inference stack) ngay hôm nay, câu hỏi thực sự không phải là "tôi có nên rời bỏ TGI không?", mà là engine nào trong hai engine này thực sự phù hợp với khối lượng công việc của bạn.

Tóm tắt nhanh

Chọn vLLM nếu bạn muốn hỗ trợ phần cứng rộng rãi nhất, cộng đồng lớn nhất và lộ trình đã được kiểm chứng để đưa vào production trên AWS, GCP và Azure.

Chọn SGLang nếu khối lượng công việc của bạn nặng về các cuộc hội thoại nhiều lượt, đầu ra có cấu trúc, hoặc các quy trình làm việc nặng về tiền tố như RAG, và bạn cảm thấy thoải mái với một hệ sinh thái nhỏ hơn.

Bây giờ, hãy cùng phân tích xem mỗi engine thực sự vượt trội ở điểm nào.

Chúng ta đã đến đây bằng cách nào? Sự rút lui của TGI

Text Generation Inference (TGI) đã gánh vác hệ sinh thái Hugging Face trong nhiều năm, nhưng tính đến tháng 12 năm 2025, nó chỉ chấp nhận các bản sửa lỗi, không có tính năng mới. Các Inference Endpoints của chính Hugging Face hiện mặc định sử dụng vLLM, với SGLang là một lựa chọn thay thế.

Điều đó để lại hai đối thủ thực sự cho việc tự lưu trữ (self-hosted) phục vụ LLM. Cả hai đều là nguồn mở, cả hai đều hỗ trợ API OpenAI và cả hai đều chạy trên GPU NVIDIA. Sự khác biệt sẽ xuất hiện rõ ràng dưới tải trọng cao.

Kết luận: Cả vLLM và SGLang đều là các giải pháp thay thế TGI sẵn sàng cho production. Nếu bạn đang di chuyển, cả hai đều là lựa chọn an toàn; phần còn lại của hướng dẫn này sẽ giúp bạn chọn cái nào.

Đo hiệu năng thông lượng và độ trễ

Các kết quả đo hiệu năng thay đổi tùy theo mô hình, GPU và mức độ đồng thời, vì vậy dưới đây là các con số từ các bài kiểm tra độc lập trên cùng một phần cứng. Dữ liệu sau đây đến từ các bài đo hiệu năng H100 của Spheron sử dụng Llama 3.3 70B Instruct ở định dạng FP8 và các bài kiểm tra của PremAI với Llama 3.1 8B.

Llama 3.3 70B trên H100 (FP8)

Llama 3.1 8B trên H100

Với các mô hình nhỏ hơn, khoảng cách trở nên rộng hơn. PremAI đã đo được SGLang đạt khoảng 16.200 token/giây so với vLLM ở mức 12.500 token/giây, mang lại lợi thế về thông lượng 29% cho SGLang. LMDeploy cũng ngang hàng với SGLang ở điểm này, nhưng đó là một câu chuyện khác.

Ý nghĩa của các con số

Ở quy mô 70B, chênh lệch là khiêm tốn (3-5%). Ở quy mô 8B, nó đáng kể. Mô hình này rất hợp lý: RadixAttention của SGLang phát huy hiệu quả hơn khi giai đoạn prefill chiếm tỷ trọng lớn hơn trong tổng chi phí, điều thường xảy ra với các mô hình nhỏ hơn và đầu ra ngắn hơn.

Độ trễ đuôi (Tail latency) cũng kể một câu chuyện tương tự. TTFT p95 của SGLang luôn thấp hơn vLLM từ 5-8% ở mọi mức độ đồng thời được kiểm tra. Nếu bạn đang xây dựng giao diện chat thời gian thực nơi mỗi 50ms đều quan trọng, khoảng cách này sẽ tích lũy đáng kể qua nhiều người dùng.

Kết luận: SGLang thắng về thông lượng thô, đặc biệt đối với các mô hình nhỏ hơn. vLLM bám sát ở quy mô 70B+. Đối với hầu hết các khối lượng công việc production, sự khác biệt chỉ ở mức phần trăm đơn lẻ, có ý nghĩa ở quy mô lớn, nhưng không phải là yếu tố quyết định theo hướng nào.

Bộ nhớ đệm tiền tố: RadixAttention so với Automatic Prefix Caching

Cả hai engine đều lưu vào bộ nhớ đệm các tính toán KV cho các tiền tố lặp lại, nhưng các cơ chế khác nhau theo những cách quan trọng đối với một số khối lượng công việc nhất định. Nếu bạn đã quen thuộc với bộ nhớ đệm prompt ở cấp độ API, hãy coi đây là phiên bản phía máy chủ.

vLLM sử dụng hashing cấp độ block. Nó chia bộ nhớ đệm KV thành các block có kích thước cố định, tạo hash cho chúng và tìm kiếm các khớp nối khi có yêu cầu mới. Dễ dự đoán, hiệu quả và dễ suy luận, nhưng bạn cần các ranh giới block nhất quán để đạt được hit trong bộ nhớ đệm.

SGLang sử dụng cây radix được lập chỉ mục ở cấp độ token. Nó tự động phát hiện các tiền tố được chia sẻ giữa các yêu cầu mà không cần cấu hình thủ công. Nếu 50 người dùng gửi tin nhắn trong cùng một luồng hội thoại, SGLang sẽ tự động tìm và tái sử dụng tiền tố chung.

Nơi nó thực sự quan trọng

RunPod đã đo hiệu năng các cuộc hội thoại nhiều lượt và phát hiện ra rằng SGLang duy trì ổn định ở mức ~30-31 token/giây dưới độ đồng thời cao, trong khi vLLM giảm từ 22 xuống 16 token/giây khi áp lực bộ nhớ đệm tăng lên. Đó là một khoảng cách đáng kể cho các khối lượng công việc chatbot và agent.

Đối với suy luận hàng loạt (batch inference) trên các prompt có mẫu, nơi mọi yêu cầu đều sử dụng cùng một system prompt, cách tiếp cận của vLLM hoạt động tốt. Các ranh giới bộ nhớ đệm align tự nhiên với cấu trúc mẫu của bạn.

Kết luận: SGLang thắng cho các khối lượng công việc động, nhiều lượt. vLLM hoàn toàn đủ dùng cho suy luận hàng loạt và các prompt có mẫu nơi các tiền tố có thể dự đoán được.

Đầu ra có cấu trúc

Nếu bạn cần thực thi lược đồ JSON hoặc tạo nội dung bị ràng buộc, phần này rất quan trọng. Cả hai engine đều hỗ trợ đầu ra có cấu trúc thông qua các backend ngữ pháp như XGrammar và LLGuidance, nhưng câu chuyện về hiệu năng lại rất khác biệt.

SqueezeBits đã chạy các bài đo hiệu năng chi tiết và phát hiện ra rằng vLLM cho thấy sự suy giảm thông lượng đáng kể khi bật giải mã có hướng dẫn, đặc biệt ở kích thước batch từ 8 trở lên. Ngược lại, SGLang chồng lấp việc tạo mask với bước suy luận GPU, giữ cho chi phí ở mức tối thiểu.

Lược đồ lặp lại so với động

Lựa chọn backend cũng quan trọng:

Không có thực thi có cấu trúc, độ chính xác của đầu ra giảm xuống còn ~61% đối với các lược đồ phức tạp. Với nó, độ chính xác tăng thêm 20-25 điểm phần trăm. Vì vậy, đây không phải là tùy chọn cho các quy trình làm việc agent production, và engine bạn chọn sẽ quyết định bạn phải hy sinh bao nhiêu thông lượng.

Kết luận: SGLang thắng về đầu ra có cấu trúc. Nếu quy trình của bạn dựa vào việc thực thi lược đồ JSON (và hầu hết các quy trình agent đều như vậy), cách tiếp cận chồng lấp của SGLang có nghĩa là bạn không phải trả "thuế" thông lượng.

Phục vụ mô hình Multi-LoRA và Fine-Tuned

Cả hai engine đều hỗ trợ phục vụ nhiều adapter LoRA từ một mô hình cơ sở duy nhất, điều cần thiết nếu bạn fine-tune các mô hình cho các khách thuê (tenants) hoặc tác vụ khác nhau.

SGLang coi multi-LoRA là một tính năng hạng nhất với batching native, các yêu cầu nhắm đến các adapter khác nhau có thể chia sẻ cùng một batch. vLLM cũng hỗ trợ tính năng này, nhưng việc triển khai của SGLang đã bóng bẩy hơn một chút trong các bản phát hành gần đây.

Sự khác biệt thực tế? Nếu bạn đang phục vụ 5-10 adapter LoRA từ một mô hình cơ sở Llama 70B, cả hai đều hoạt động. Nếu bạn đang chạy 50+ adapter với các mẫu lưu lượng không đồng nhất, batching native của SGLang xử lý việc lập lịch trình mượt mà hơn.

Kết luận: SGLang có lợi thế nhẹ cho multi-LoRA ở quy mô lớn. Đối với một vài adapter, cả hai engine đều hoạt động tốt như nhau.

Giải mã suy đoán (Speculative Decoding)

Cả hai engine đều hỗ trợ giải mã suy đoán, sử dụng một mô hình "draft" nhỏ để dự đoán các token mà mô hình chính sau đó xác minh song song. Kết quả là suy luận nhanh hơn 2-3 lần trong các kịch bản bị giới hạn bởi bộ nhớ.

vLLM gần đây đã giới thiệu Unified Parallel Drafting, và giải mã suy đoán hiện hoạt động cùng với đầu ra có cấu trúc. Việc triển khai của SGLang có khả năng tương tự, với hiệu suất tốt hơn một chút ở các mức độ đồng thời vừa phải.

Yếu tố khác biệt thực sự không nằm ở engine, mà là liệu giải mã suy đoán có phù hợp với khối lượng công việc của bạn hay không. Nó hữu ích nhất với các đầu ra dài từ các mô hình lớn nơi nút cổ chai là băng thông bộ nhớ, không phải khả năng tính toán.

Kết luận: Hòa. Cả hai engine đều mang lại tốc độ tăng trưởng giải mã suy đoán tương đương nhau.

Hỗ trợ phần cứng và triển khai

Đây là nơi vLLM vượt trội đáng kể.

vLLM

• GPU NVIDIA (A100, H100, H200, B200)
• GPU AMD (MI250, MI300X)
• GPU Intel (thông qua vllm-xpu-kernels)
• AWS Trainium và Inferentia
• Google TPUs
• Tài liệu Kubernetes chín muồi với biểu đồ Helm, probe startup/readiness/liveness
• Tích hợp NVIDIA Container Toolkit ngay từ đầu

SGLang

• GPU NVIDIA (A100, H100, H200, B200)
• GPU AMD (MI300X, thông qua ROCm)
• Triển khai ưu tiên Docker
• Kubernetes là khả thi nhưng ít tài liệu hơn

Nếu bạn đang triển khai trên bất kỳ thứ gì khác ngoài NVIDIA hoặc AMD, vLLM là lựa chọn duy nhất của bạn. Cụ thể trên AWS, hỗ trợ Trainium có nghĩa là bạn có thể cắt giảm đáng kể chi phí suy luận, và SGLang không thể chạm tới phần cứng đó.

Đối với các đội chạy trên GPU NVIDIA tiêu chuẩn, câu chuyện triển khai là tương tự. Cả hai đều cung cấp image Docker và endpoint tương thích OpenAI. vLLM chỉ có nhiều hướng dẫn production đã được kiểm chứng và biểu đồ Helm do cộng đồng đóng góp hơn.

Nếu bạn đang khám phá các công cụ để chạy LLM cục bộ hoặc muốn có cái nhìn tổng quát hơn về suy luận tự lưu trữ, cả hai engine đều hỗ trợ triển khai cục bộ trên GPU consumer, mặc dù chúng được thiết kế cho phần cứng trung tâm dữ liệu.

Kết luận: vLLM thắng về độ rộng phần cứng và độ chín muồi trong triển khai. SGLang ổn nếu bạn dùng NVIDIA hoặc AMD. Ở bất kỳ đâu khác, vLLM là lựa chọn duy nhất.

Phục vụ tách biệt (Disaggregated Serving)

Cả hai engine đều hỗ trợ tách biệt giai đoạn prefill (nặng tính toán) khỏi decode (nặng bộ nhớ) vào các nhóm worker khác nhau. Điều này cho phép bạn mở rộng quy mô từng giai đoạn độc lập, nhiều worker prefill hơn trong các đợt bùng nổ prompt, nhiều worker decode hơn cho việc tạo nội dung dài.

SGLang hỗ trợ Mooncake và NIXL làm backend truyền tải cho việc tách biệt và đã công bố kết quả cho thấy thông lượng decode cao hơn 2,7 lần trên các cụm NVIDIA GB200 NVL72. Khả năng phục vụ tách biệt của vLLM cũng hoạt động, mặc dù ít được ghi chép nổi bật hơn.

Tính năng này quan trọng nhất ở quy mô rất lớn (96+ GPU). Nếu bạn chỉ chạy một vài GPU, có lẽ bạn chưa cần đến nó.

Kết luận: SGLang có lợi thế nhẹ về độ chín muồi của phục vụ tách biệt. Cả hai đều hỗ trợ; SGLang đã công bố nhiều kết quả thực tế hơn.

Khi nào sử dụng cái nào: Khung ra quyết định

Câu trả lời trung thực cho nhiều đội: hãy thử cả hai. Cả hai đều là nguồn mở, cả hai đều expose cùng một API OpenAI, và việc chuyển đổi giữa chúng chỉ là thay thế container. Chạy khối lượng công việc thực tế của bạn trên mỗi engine trong một ngày và so sánh các chỉ số quan trọng đối với bạn.

Nếu bạn đang định tuyến lưu lượng truy cập qua nhiều backend suy luận, một LLM gateway có thể đứng trước cả hai engine và xử lý failover, giới hạn tốc độ và khả năng quan sát.

Cách Techsy tiếp cận việc lựa chọn máy chủ suy luận

Khi chúng tôi giúp các đội triển khai các tính năng được hỗ trợ bởi LLM, lựa chọn engine suy luận phụ thuộc vào ba câu hỏi:

1. Bạn bị khóa vào phần cứng nào? Nếu là Trainium hoặc TPUs, đó là vLLM. Mọi thứ khác, cả hai đều hoạt động.
2. Hình dạng khối lượng công việc của bạn là gì? Chat nhiều lượt và các vòng lặp agent ủng hộ bộ nhớ đệm tiền tố của SGLang. Xử lý hàng loạt và các hoàn thành đơn giản đều ổn trên cả hai.
3. Bạn có bao nhiêu năng lực ops? Cộng đồng lớn hơn của vLLM có nghĩa là có nhiều câu trả lời StackOverflow và biểu đồ Helm hơn khi có sự cố xảy ra lúc 3 giờ sáng.

Chúng tôi đã chạy các khối lượng công việc production trên cả hai. Chúng thực sự rất gần nhau. Câu trả lời đúng phụ thuộc vào các ràng buộc của bạn, chứ không phải vì cái này "tốt hơn" cái kia một cách trừu tượng.

Cần giúp đỡ để chọn hoặc triển khai máy chủ suy luận? Liên hệ với chúng tôi, chúng tôi sẽ đánh giá khối lượng công việc của bạn và đề xuất stack phù hợp.

Việc chọn công cụ là nửa dễ dàng. Làm cho nó chạy ổn định bên trong một sản phẩm thực tế là nơi hầu hết các đội bị đình trệ, và đó chính xác là những gì đội tích hợp AI của chúng tôi xây dựng cho khách hàng, từ các quy trình RAG đến các agent tùy chỉnh.

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

SGLang có nhanh hơn vLLM không?

Trên các mô hình nhỏ (7B-8B), SGLang cho thấy thông lượng cao hơn khoảng 29% trên GPU H100. Trên các mô hình 70B+, khoảng cách thu hẹp còn 3-5%. SGLang cũng có độ trễ đuôi (TTFT p95) thấp hơn ở tất cả các mức độ đồng thời được kiểm tra.

Tôi có thể sử dụng vLLM và SGLang với định dạng API OpenAI không?

Có. Cả hai đều expose các endpoint tương thích OpenAI ngay từ đầu. Bạn có thể thay thế cái này bằng cái kia mà không cần thay đổi mã client. Các lệnh gọi /v1/chat/completions của bạn hoạt động giống hệt nhau trên cả hai.

Tại sao Hugging Face lại loại bỏ TGI?

TGI đã chuyển sang chế độ bảo trì vào tháng 12 năm 2025. Hugging Face quyết định đóng góp cho vLLM và SGLang thay vì duy trì một engine suy luận riêng biệt. TGI vẫn hoạt động cho các lần triển khai hiện có, nhưng không có tính năng mới nào sắp tới.

SGLang có hỗ trợ GPU NVIDIA và AMD không?

SGLang hỗ trợ GPU NVIDIA (A100, H100, H200, B200) và GPU AMD (MI300X thông qua ROCm). Nó không hỗ trợ GPU Intel, AWS Trainium, Inferentia hoặc Google TPUs. vLLM có phạm vi hỗ trợ phần cứng rộng hơn.

RadixAttention là gì và tại sao nó quan trọng?

RadixAttention là cơ chế bộ nhớ đệm tiền tố của SGLang. Nó lưu trữ các entry bộ nhớ đệm KV trong một cây radix được lập chỉ mục ở cấp độ token, tự động phát hiện các tiền tố được chia sẻ giữa các yêu cầu. Điều này làm cho các cuộc hội thoại nhiều lượt và các quy trình RAG nhanh hơn đáng kể vì ngữ cảnh lặp lại không cần phải tính toán lại.

Engine nào tốt hơn cho đầu ra JSON có cấu trúc?

SGLang. Nó chồng lấp việc tạo mask ngữ pháp với suy luận GPU, vì vậy việc thực thi đầu ra có cấu trúc hầu như không ảnh hưởng đến thông lượng. vLLM cho thấy sự suy giảm đáng kể ở kích thước batch từ 8 trở lên khi bật giải mã có hướng dẫn.

Tôi có thể phục vụ nhiều adapter LoRA từ một mô hình cơ sở không?

Cả hai engine đều hỗ trợ phục vụ multi-LoRA. SGLang coi đây là một tính năng native với batching qua các adapter khác nhau trong cùng một batch yêu cầu. vLLM cũng hỗ trợ, nhưng việc lập lịch của SGLang hiệu quả hơn ở số lượng adapter cao.

Phục vụ prefill/decode tách biệt là gì?

Nó có nghĩa là chạy giai đoạn prefill (xử lý prompt) trên các worker GPU riêng biệt với giai đoạn decode (tạo token). Prefill bị giới hạn bởi tính toán; decode bị giới hạn bởi bộ nhớ. Việc tách biệt chúng cho phép bạn mở rộng quy mô từng phần độc lập. Cả hai engine đều hỗ trợ điều này, với SGLang có nhiều kết quả production được công bố hơn.

Làm thế nào để di chuyển từ TGI sang vLLM hoặc SGLang?

Vì cả ba đều expose các API tương thích OpenAI, việc di chuyển chủ yếu là thay thế container. Trỏ deployment Docker Compose hoặc Kubernetes của bạn đến image mới, điều chỉnh các cờ tải mô hình và cập nhật các endpoint health check. Mã client giữ nguyên.

Tôi nên dùng vLLM hay SGLang cho quy trình RAG?

SGLang là lựa chọn mạnh mẽ hơn cho RAG. RadixAttention của nó tự động lưu vào bộ nhớ đệm và tái sử dụng các system prompt dài và ngữ cảnh tài liệu mà các quy trình RAG gửi đi lặp lại. Bộ nhớ đệm cấp độ block của vLLM cũng hoạt động, nhưng bạn sẽ thấy tỷ lệ hit bộ nhớ đệm tốt hơn với cách tiếp cận cấp độ token của SGLang khi các chunk tài liệu thay đổi nhẹ giữa các yêu cầu.

Phán quyết cuối cùng

SGLang thắng nhiều danh mục hơn, nhưng những lợi thế của vLLM, độ rộng phần cứng và độ chín muồi của hệ sinh thái, là những thứ quan trọng lúc 3 giờ sáng khi một node gặp sự cố.

Nếu bạn đang sử dụng phần cứng NVIDIA và khối lượng công việc của bạn liên quan đến các cuộc hội thoại nhiều lượt, các agent với đầu ra có cấu trúc, hoặc các quy trình RAG với các tiền tố được chia sẻ, hãy bắt đầu với SGLang. Bạn sẽ nhận được thông lượng tốt hơn và độ trễ thấp hơn ở những nơi quan trọng.

Nếu bạn cần sự linh hoạt đa đám mây, hỗ trợ phần cứng không phải NVIDIA, hoặc sự yên tâm từ cộng đồng phục vụ LLM nguồn mở lớn nhất, hãy bắt đầu với vLLM. Đó là mặc định an hơn và sẽ phục vụ tốt cho hầu hết các đội.

Dù bằng cách nào, cả hai engine đều xuất sắc và đang cải thiện nhanh chóng. Hãy chọn một cái, triển khai nó, đo lường khối lượng công việc thực tế của bạn và chuyển đổi nếu các con số cho thấy bạn nên làm vậy. API tương thích OpenAI khiến việc chuyển đổi đó trở nên dễ dàng.

Nguồn

• Spheron H100 Benchmarks: vLLM vs TensorRT-LLM vs SGLang
• PremAI: vLLM vs SGLang vs LMDeploy Benchmarks
• SqueezeBits: Guided Decoding Performance on vLLM and SGLang
• RunPod: SGLang vs vLLM KV Cache Reuse
• SGLang Official Documentation
• vLLM Official Documentation