SGLang vs vLLM: Suy luận LLM thông lượng cao, RadixAttention & Giải mã có cấu trúc

Cơ sở hạ tầng phục vụ LLM vào năm 2026 đòi hỏi thông lượng cực cao, độ trễ tối thiểu và hỗ trợ mạnh mẽ cho các mẫu tạo sinh phức tạp. Hướng dẫn này phân tích hai framework nổi bật là SGLang và vLLM, đánh giá các mô hình kiến trúc, đặc điểm hiệu suất và sự phù hợp của chúng cho các trường hợp sử dụng nâng cao như suy luận đa lượt và tạo đầu ra có cấu trúc. Chúng tôi tập trung vào các cơ chế cốt lõi của chúng: quản lý bộ nhớ KV cache, lập lịch và khả năng giải mã có cấu trúc, cung cấp dữ liệu benchmark trên GPU NVIDIA H100 và L4.

Tổng quan kiến trúc

Cả SGLang và vLLM đều nhằm mục đích tối đa hóa việc sử dụng GPU bằng cách nhóm các yêu cầu và tối ưu hóa quyền truy cập KV cache. Tuy nhiên, các phương pháp cơ bản của chúng khác nhau đáng kể.

vLLM: PagedAttention và Continuous Batching

vLLM đã giới thiệu PagedAttention, một lược đồ quản lý bộ nhớ lấy cảm hứng từ phân trang bộ nhớ ảo trong hệ điều hành. Nó tách rời chuỗi logic của các khối KV cache khỏi việc phân bổ bộ nhớ vật lý của chúng. Điều này giảm thiểu phân mảnh bộ nhớ và cho phép chia sẻ hiệu quả các khối KV cache giữa các yêu cầu khác nhau, đặc biệt trong các kịch bản đa người dùng. Continuous batching tiếp tục nâng cao thông lượng bằng cách tự động thêm các yêu cầu mới vào batch ngay khi tài nguyên GPU có sẵn, thay vì chờ đợi một kích thước batch cố định.

SGLang: RadixAttention và Speculative Execution

SGLang được xây dựng dựa trên khái niệm RadixAttention, mở rộng việc tái sử dụng KV cache vượt ra ngoài việc chia sẻ tiền tố đơn giản. Nó tận dụng cấu trúc giống cây radix để quản lý các khối KV cache, cho phép chia sẻ hiệu quả trên các chuỗi con chung tùy ý, không chỉ các tiền tố. Điều này đặc biệt có lợi cho các cuộc hội thoại đa lượt, các vòng lặp tác nhân và kỹ thuật prompt phức tạp, nơi các phần của prompt hoặc các lượt trước đó được sử dụng lặp đi lặp lại. SGLang cũng tích hợp giải mã suy đoán (speculative decoding), trong đó một mô hình nháp nhỏ hơn, nhanh hơn tạo ra các token ứng cử viên, sau đó được mô hình mục tiêu lớn hơn xác minh, giảm đáng kể độ trễ giải mã.

Quản lý KV Cache: PagedAttention so với RadixAttention

Hiệu quả của việc quản lý KV cache ảnh hưởng trực tiếp đến việc sử dụng bộ nhớ và thông lượng.

Cơ chế PagedAttention

Trong vLLM, KV cache cho mỗi chuỗi được chia thành các khối có kích thước cố định. Các khối này không nhất thiết phải liền kề trong bộ nhớ GPU vật lý. Một bảng trang ánh xạ các ID khối logic tới các ID khối vật lý. Khi một chuỗi mở rộng, các khối vật lý mới được phân bổ khi cần. Nếu một chuỗi phân nhánh (ví dụ: tìm kiếm chùm), bảng trang có thể được sao chép hiệu quả và chỉ các khối mới được phân bổ cho các đường dẫn phân kỳ.

# vLLM PagedAttention conceptual illustration (simplified)
import torch

class PagedAttentionKVManager:
    def __init__(self, block_size, gpu_memory_limit_gb):
        self.block_size = block_size
        self.gpu_memory_limit_bytes = gpu_memory_limit_gb * 1024**3
        self.physical_blocks = {} # {block_id: torch.Tensor}
        self.free_block_ids = set()
        self.next_block_id = 0

    def _allocate_physical_block(self):
        if self.next_block_id in self.physical_blocks:
            raise RuntimeError("Block ID collision, memory management error.")
        # Simulate actual GPU memory allocation
        block_tensor = torch.empty((self.block_size, self.block_size, 2, 128), # K/V, head_dim
                                   dtype=torch.float16, device='cuda')
        self.physical_blocks[self.next_block_id] = block_tensor
        block_id = self.next_block_id
        self.next_block_id += 1
        return block_id

    def get_sequence_blocks(self, sequence_id, num_blocks_needed):
        # In a real system, this would involve a page table lookup
        # and allocation of new blocks if existing ones are full.
        allocated_blocks = []
        for _ in range(num_blocks_needed):
            if not self.free_block_ids:
                # Allocate new physical block if no free ones
                block_id = self._allocate_physical_block()
            else:
                block_id = self.free_block_ids.pop()
            allocated_blocks.append(block_id)
        return allocated_blocks

    def free_sequence_blocks(self, block_ids):
        self.free_block_ids.update(block_ids)
        # In a real system, physical blocks might be truly deallocated
        # or marked as reusable.

# Example usage (conceptual)
# manager = PagedAttentionKVManager(block_size=16, gpu_memory_limit_gb=24)
# seq1_blocks = manager.get_sequence_blocks(sequence_id=1, num_blocks_needed=10)
# seq2_blocks = manager.get_sequence_blocks(sequence_id=2, num_blocks_needed=15)
# manager.free_sequence_blocks(seq1_blocks)

Cơ chế RadixAttention

RadixAttention, như được triển khai trong SGLang, tổ chức các khối KV cache thành một cây radix. Mỗi nút trong cây đại diện cho một tiền tố chung của các chuỗi. Khi một chuỗi mới đến, SGLang duyệt cây để tìm tiền tố chung dài nhất với các chuỗi hiện có. Sau đó, nó tái sử dụng các khối KV cache tương ứng với tiền tố này. Chỉ phần hậu tố phân kỳ mới yêu cầu phân bổ khối mới. Điều này đặc biệt mạnh mẽ cho các kịch bản như:

1. Hội thoại đa lượt: Các lượt hội thoại ban đầu có thể được lưu vào bộ nhớ cache và tái sử dụng cho các lượt tiếp theo.
2. Vòng lặp tác nhân: Nếu một tác nhân liên tục thử các công cụ hoặc prompt khác nhau dựa trên một ngữ cảnh ban đầu chung, KV cache của ngữ cảnh đó sẽ được tái sử dụng.
3. Mẫu prompt phức tạp: Các prompt có tập lệnh hướng dẫn lớn, tĩnh có thể có KV cache được tính toán trước và chia sẻ.

# SGLang RadixAttention conceptual illustration (simplified)
class RadixTreeNode:
    def __init__(self, token_id=None, kv_cache_block_id=None):
        self.token_id = token_id # Token represented by this node
        self.kv_cache_block_id = kv_cache_block_id # Physical block ID for this token's KV
        self.children = {} # {token_id: RadixTreeNode}
        self.sequences = set() # Set of sequence_ids passing through this node

class RadixAttentionKVManager:
    def __init__(self, block_size):
        self.root = RadixTreeNode()
        self.block_size = block_size
        self.physical_blocks = {} # {block_id: torch.Tensor}
        self.next_block_id = 0

    def _allocate_physical_block(self):
        block_id = self.next_block_id
        self.physical_blocks[block_id] = torch.empty((self.block_size, self.block_size, 2, 128),
                                                     dtype=torch.float16, device='cuda')
        self.next_block_id += 1
        return block_id

    def get_or_create_path(self, sequence_id, tokens):
        current_node = self.root
        path_blocks = []
        for token in tokens:
            if token not in current_node.children:
                # Create new node and allocate KV block
                new_block_id = self._allocate_physical_block()
                current_node.children[token] = RadixTreeNode(token_id=token, kv_cache_block_id=new_block_id)
            current_node = current_node.children[token]
            current_node.sequences.add(sequence_id)
            path_blocks.append(current_node.kv_cache_block_id)
        return path_blocks

    def remove_sequence(self, sequence_id, tokens):
        # Traverse and remove sequence_id from nodes.
        # If a node's sequence set becomes empty and it's not a prefix for others,
        # its KV block can be marked for deallocation/reuse.
        pass # Complex logic for actual tree pruning and block freeing

# Example usage (conceptual)
# manager = RadixAttentionKVManager(block_size=16)
# seq1_tokens = [1, 5, 2, 8]
# seq1_blocks = manager.get_or_create_path(1, seq1_tokens)
# seq2_tokens = [1, 5, 3, 9] # Shares prefix [1, 5]
# seq2_blocks = manager.get_or_create_path(2, seq2_tokens)
# print(f"Seq1 blocks: {seq1_blocks}") # First two blocks might be shared
# print(f"Seq2 blocks: {seq2_blocks}") # First two blocks might be shared

Giải mã có cấu trúc: XGrammar so với Outlines

Tạo đầu ra có cấu trúc (ví dụ: JSON, XML, các định dạng cụ thể) là rất quan trọng để tích hợp LLM vào các quy trình làm việc có lập trình. Cả hai framework đều cung cấp các cơ chế cho việc này, nhưng với các phương pháp cơ bản khác nhau.

SGLang: XGrammar

SGLang tích hợp XGrammar, một hệ thống ràng buộc dựa trên ngữ pháp mạnh mẽ và linh hoạt. XGrammar cho phép người dùng định nghĩa các lược đồ đầu ra bằng cách sử dụng cú pháp tương tự như EBNF hoặc biểu thức chính quy. Trong quá trình tạo sinh, bộ lấy mẫu của SGLang cắt bớt từ vựng ở mỗi bước tạo token, đảm bảo rằng chỉ các token tuân thủ ngữ pháp đã chỉ định mới được xem xét. Điều này đảm bảo đầu ra có cấu trúc hợp lệ và có thể giảm đáng kể số lượng token cần thiết để tạo sinh bằng cách hướng dẫn mô hình hiệu quả hơn.

# SGLang XGrammar example for JSON output
import sglang as sg

@sg.function
def generate_json_object(s, user_query):
    s += sg.user(user_query)
    s += sg.assistant(
        r'```json' +
        r'{' +
        r'  "name": "' + sg.gen("name", max_tokens=16, stop='"') + r'",' +
        r'  "age": ' + sg.gen("age", max_tokens=4, stop=',') + r',' +
        r'  "city": "' + sg.gen("city", max_tokens=16, stop='"') + r'"' +
        r'}' +
        r'```'
    )

# Example usage (assuming sglang server is running)
# state = sg.State()
# state = generate_json_object(state, "Tell me about a person named Alice, 30 years old, living in New York.")
# print(state["name"])
# print(state["age"])
# print(state["city"])

vLLM: Tích hợp Outlines

vLLM không triển khai lấy mẫu dựa trên ngữ pháp một cách tự nhiên mà tích hợp tốt với các thư viện như Outlines. Outlines cung cấp cú pháp khai báo để chỉ định các ràng buộc tạo sinh bằng cách sử dụng biểu thức chính quy, lược đồ JSON hoặc các kiểu Python. Sau đó, nó biên dịch các ràng buộc này thành một máy trạng thái hữu hạn (FSM) hướng dẫn quá trình tạo token. API của vLLM có thể được sử dụng để truyền các ràng buộc có nguồn gốc từ FSM này đến nhân lấy mẫu, đảm bảo đầu ra hợp lệ.

# vLLM with Outlines example for JSON output
import outlines
from vllm import LLM, SamplingParams

# 1. Define the JSON schema
json_schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string"},
        "age": {"type": "integer"},
        "city": {"type": "string"}
    },
    "required": ["name", "age", "city"]
}

# 2. Create a JSON schema guided generator using Outlines
generator = outlines.generate.json(LLM, json_schema) # LLM here is a placeholder for vLLM's model instance

# 3. Define the prompt
prompt = "Generate a JSON object for a person named Bob, 25 years old, living in London."

# 4. Generate with constraints (conceptual, actual integration might vary slightly)
# This part would involve passing the FSM from outlines to vLLm's sampling parameters.
# For vLLM, this typically means using a custom `logits_processor` or similar mechanism
# that Outlines provides to interface with vLLM's sampling.
#
# A more direct integration might look like this with Outlines' vLLM support:
# model = LLM(model="mistralai/Mistral-7B-Instruct-v0.2", trust_remote_code=True)
# generator = outlines.generate.json(model, json_schema)
# result = generator(prompt)
# print(result)

# For a more direct vLLM-only approach (without Outlines, less flexible):
# This would require manually implementing a logits processor.
# class JsonLogitsProcessor:
#     def __call__(self, token_ids: List[int], logits: torch.Tensor) -> torch.Tensor:
#         # Implement logic to mask logits based on expected JSON structure
#         # This is significantly more complex than using Outlines.
#         return logits
#
# sampling_params = SamplingParams(temperature=0.0, top_p=1.0, max_tokens=100,
#                                  logits_processor=[JsonLogitsProcessor()])
# outputs = model.generate(prompt, sampling_params)

Benchmarking: Hiệu suất H100 so với L4

Chúng tôi đã tiến hành các benchmark trên GPU NVIDIA H100 (80GB) và L4 (24GB) để đánh giá thông lượng và độ trễ trong các điều kiện tải khác nhau. Các mô hình được sử dụng là Llama-3-8B-Instruct và Mistral-7B-Instruct-v0.2.

Thiết lập:

• H100: Một GPU, 80GB VRAM.
• L4: Một GPU, 24GB VRAM.
• Khối lượng công việc: Các yêu cầu đồng thời với độ dài prompt khác nhau (50-500 token) và độ dài tạo sinh (50-200 token).
• Số liệu: Thông lượng (token/giây) và độ trễ P95 (giây).
• Batching: Continuous batching cho vLLM, dynamic batching cho SGLang.

Thông lượng (Token/giây)

Giải thích: SGLang luôn vượt trội hơn vLLM về thông lượng thô, đặc biệt khi có sự tái sử dụng KV cache đáng kể (được chỉ ra bởi độ dài prompt "shared"). Khả năng của RadixAttention trong việc chia sẻ các chuỗi con chung tùy ý mang lại lợi thế hữu hình trong các khối lượng công việc thực tế, đa lượt hoặc tác nhân. Giải mã suy đoán cũng góp phần vào tốc độ tạo token cao hơn của SGLang.

Độ trễ P95 (Giây)

Giải thích: SGLang thường có độ trễ P95 thấp hơn. Điều này là do giải mã suy đoán làm giảm thời gian tạo sinh hiệu quả trên mỗi token và RadixAttention giảm thiểu việc tính toán lại KV cache cho các tiền tố chung, dẫn đến việc tạo token ban đầu nhanh hơn.

Các vấn đề và khắc phục sự cố trong sản xuất

1. KV Cache bị hết bộ nhớ

• Triệu chứng: Lỗi CUDA out of memory, đặc biệt khi có độ đồng thời cao hoặc với các chuỗi dài.
• vLLM: PagedAttention có ích, nhưng các mô hình lớn và nhiều chuỗi dài đồng thời vẫn sẽ làm hết VRAM.
  • Cách khắc phục:
    • Giảm max_model_len nếu có thể.
    • Giảm gpu_memory_utilization để dành nhiều bộ nhớ host hơn cho các tiến trình khác hoặc để cho phép hoán đổi tích cực hơn (mặc dù điều này ảnh hưởng đến hiệu suất).
    • Nâng cấp lên GPU có nhiều VRAM hơn (ví dụ: H100 80GB).
    • Triển khai hàng đợi yêu cầu và giới hạn tốc độ ở lớp ứng dụng.
• SGLang: RadixAttention có thể giảm áp lực bộ nhớ cho các khối lượng công việc cụ thể, nhưng nó không phải là giải pháp vạn năng.
  • Cách khắc phục: Tương tự như vLLM. Ngoài ra, hãy đảm bảo ứng dụng của bạn tận dụng hiệu quả các mẫu tái sử dụng KV cache. Nếu mỗi yêu cầu là duy nhất, lợi ích của RadixAttention sẽ giảm đi. Theo dõi tỷ lệ truy cập KV cache.

2. Lỗi giải mã có cấu trúc

• Triệu chứng: JSON được tạo ra không hợp lệ, hoặc mô hình bị kẹt trong một vòng lặp.
• SGLang (XGrammar):
  • Chế độ lỗi: Định nghĩa ngữ pháp không chính xác. Một lỗi nhỏ trong cú pháp giống EBNF có thể dẫn đến các trạng thái không thể hoặc cắt bớt token không mong muốn.
  • Cách khắc phục:
    • Kiểm tra kỹ các định nghĩa ngữ pháp với các đầu vào đơn giản.
    • Sử dụng các công cụ gỡ lỗi của SGLang (nếu có) để kiểm tra trạng thái ngữ pháp.
    • Đảm bảo mô hình đã được tinh chỉnh trên dữ liệu có cấu trúc, vì một mô hình không quen tạo đầu ra có cấu trúc có thể gặp khó khăn ngay cả với các ràng buộc ngữ pháp mạnh mẽ.
• vLLM (Outlines):
  • Chế độ lỗi: Không khớp giữa FSM của Outlines và lấy mẫu của vLLM. Outlines có thể tạo ra một FSM quá hạn chế hoặc có các trường hợp biên mà mô hình cơ bản gặp khó khăn.
  • Cách khắc phục:
    • Xác minh việc tạo FSM của Outlines với một mô hình đơn giản hơn hoặc bằng cách kiểm tra trạng thái FSM.
    • Đảm bảo logits_processor áp dụng đúng các ràng buộc FSM mà không gây ra tắc nghẽn hiệu suất.
    • Kiểm tra khả năng tương thích phiên bản giữa vLLM và Outlines.

3. Thông lượng/Độ trễ không tối ưu

• Triệu chứng: Các benchmark không khớp với hiệu suất mong đợi, hoặc độ trễ thực tế cao.
• Phổ biến cho cả hai:
  • Chế độ lỗi: Sử dụng GPU không đủ do độ đồng thời yêu cầu thấp, kích thước batch nhỏ hoặc tắc nghẽn CPU.
  • Cách khắc phục:
    • Tăng các yêu cầu đồng thời để bão hòa GPU.
    • Theo dõi việc sử dụng GPU (nvidia-smi). Nếu thấp, ứng dụng của bạn không gửi đủ yêu cầu.
    • Kiểm tra việc sử dụng CPU. Nếu CPU bị quá tải, đó có thể là một tắc nghẽn trong việc truyền dữ liệu hoặc tiền/hậu xử lý.
    • Đảm bảo max_batch_size (hoặc tương đương) được cấu hình phù hợp.
    • Đối với SGLang, đảm bảo giải mã suy đoán được bật và cấu hình với một mô hình nháp phù hợp. Một mô hình nháp được chọn kém có thể làm giảm hiệu suất.
  • Đặc trưng của SGLang:
    • Chế độ lỗi: Lợi ích của RadixAttention không được hiện thực hóa nếu khối lượng công việc không có tiền tố/chuỗi con chung.
    • Cách khắc phục: Phân tích các mẫu prompt của ứng dụng của bạn. Nếu các prompt rất độc đáo, chi phí của RadixAttention có thể hơi lớn hơn lợi ích của nó. Xem xét liệu kỹ thuật prompt có thể tạo ra nhiều điểm chung hơn không.

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

1. Khi nào tôi nên chọn SGLang thay vì vLLM?

Hãy chọn SGLang khi khối lượng công việc của bạn liên quan đến việc tái sử dụng KV cache đáng kể, chẳng hạn như các cuộc hội thoại đa lượt, các vòng lặp tác nhân hoặc các mẫu prompt phức tạp với các hướng dẫn được chia sẻ. RadixAttention và giải mã suy đoán của nó mang lại thông lượng vượt trội và độ trễ thấp hơn trong các kịch bản này. Nếu tạo đầu ra có cấu trúc với các đảm bảo mạnh mẽ là yêu cầu chính, XGrammar của SGLang cũng là một tính năng hấp dẫn.

2. vLLM có còn phù hợp vào năm 2026 không khi SGLang đã có những tiến bộ?

Hoàn toàn có. vLLM vẫn là một framework phục vụ hiệu suất cao và trưởng thành. Đối với các khối lượng công việc chủ yếu là các yêu cầu một lượt, duy nhất mà không chia sẻ KV cache rộng rãi, PagedAttention và continuous batching của vLLM cung cấp hiệu suất cơ bản tuyệt vời. Việc được chấp nhận rộng rãi hơn và hỗ trợ cộng đồng cũng có thể là một yếu tố đối với một số nhóm. Lựa chọn phụ thuộc vào các đặc điểm cụ thể của ứng dụng LLM của bạn.

3. Giải mã suy đoán trong SGLang ảnh hưởng đến việc sử dụng bộ nhớ như thế nào?

Giải mã suy đoán yêu cầu tải một mô hình nháp bổ sung, nhỏ hơn vào bộ nhớ GPU. Điều này làm tăng dung lượng VRAM cơ bản. Tuy nhiên, lợi ích về hiệu suất (giảm độ trễ giải mã) thường lớn hơn chi phí bộ nhớ này, đặc biệt đối với các mô hình mục tiêu lớn hơn, nơi bước giải mã là một nút thắt cổ chai. Mô hình nháp thường nhỏ hơn nhiều (ví dụ: 1B-3B tham số) so với mô hình mục tiêu (ví dụ: 7B-70B tham số).

4. Tôi có thể sử dụng RadixAttention của SGLang với PagedAttention của vLLM không?

Không, đây là các triển khai quản lý KV cache riêng biệt trong các framework tương ứng của chúng. Chúng không được thiết kế để tương tác hoặc kết hợp trực tiếp. Bạn chọn một framework, và do đó một chiến lược quản lý KV cache, cho cơ sở hạ tầng phục vụ của mình.

5. Việc sử dụng giải mã có cấu trúc ảnh hưởng đến độ trễ suy luận như thế nào?

Giải mã có cấu trúc, dù thông qua XGrammar của SGLang hay vLLM với Outlines, thường làm tăng độ trễ trên mỗi token so với việc tạo sinh không bị ràng buộc. Điều này là do quá trình lấy mẫu liên quan đến tính toán bổ sung để lọc các token dựa trên các quy tắc ngữ pháp. Tuy nhiên, nó làm giảm đáng kể thời gian tạo sinh tổng thể cho đầu ra hợp lệ bằng cách ngăn mô hình tạo ra các token không hợp lệ và có khả năng giảm số lần thử lại hoặc các bước xử lý hậu kỳ cần thiết. Sự đánh đổi là đầu ra hợp lệ được đảm bảo với một chi phí nhỏ trên mỗi token.