Chiến lược batching quyết định SLO
Yếu tố ảnh hưởng trực tiếp nhất đến SLO trong kiến trúc LLM serving là cách xây dựng batching. Dù trang bị GPU hiệu suất cao đến đâu, để đáp ứng đồng thời ba chỉ số TTFT (Time To First Token), ITL (Inter-Token Latency) và aggregate throughput, cần thiết kế chiến lược batch phù hợp với dạng sóng đến của request, phân phối độ dài đầu vào, phân phối độ dài đầu ra và pattern chiếm dụng KV cache. Bài viết này tổng hợp đặc tính của năm phương pháp được đưa vào thực chiến tính đến năm 2026 — continuous batching, chunked prefill, PagedAttention, RadixAttention, sorted batching — cùng tác động đến SLO và sự kết hợp với prompt cache.
Continuous Batching
Continuous batching (còn gọi là iteration-level scheduling) là phương pháp quyết định lại thành phần batch sau mỗi bước decode. Trong khi static batching truyền thống "không nhận request mới cho đến khi tất cả request trong cùng batch hoàn thành", continuous batching "rút ngay request đã hoàn thành, chèn request mới vào slot trống". Kết quả là GPU utilization ít bị ảnh hưởng bởi sự chênh lệch độ dài request, và effective throughput tăng 2-4 lần đặc biệt với workload chat có variance đầu ra lớn.
Tuy nhiên, chỉ với continuous batching vẫn còn vấn đề prefill và decode va chạm trong cùng một step. Prefill của request có prompt dài (hơn 8K token) mất vài trăm ms trở lên, trong thời gian đó decode của các request khác bị dừng lại. Prefill stall này tạo ra long tail trong phân phối ITL.
Chunked Prefill
Chunked prefill là cơ chế chia prompt dài thành các chunk nhỏ (thường 512-2048 token) và xử lý đồng thời "1 chunk prefill + decode của các request khác" trong mỗi iteration. Nhờ đó tải prefill được phân tán qua nhiều step, và jitter của ITL giảm mạnh. Đây là tính năng bắt buộc cho hệ thống cần giữ p99 ITL dưới 50ms, được hỗ trợ tiêu chuẩn trong cả vLLM, SGLang và TensorRT-LLM.
Nếu chunk size quá nhỏ, kernel launch overhead chiếm ưu thế; nếu quá lớn, decode bị stall. Theo kinh nghiệm của KGA, 4096-8192 token là điểm khởi đầu hợp lý cho H200, và 8192-16384 token cho B200. Khi mix compute-bound prefill với memory-bound decode, có thêm hiệu ứng phụ là cả compute lẫn memory của GPU được sử dụng đồng thời, giúp MFU cao hơn so với xử lý riêng lẻ.
PagedAttention
PagedAttention là phương pháp quản lý KV cache bằng cách chia thành các trang kích thước cố định (thường 16 token mỗi trang), là cốt lõi của vLLM. Giảm đáng kể memory fragmentation và đạt được dung lượng bộ nhớ hiệu quả gấp 2-4 lần. Tính đến năm 2026, không chỉ vLLM mà hầu hết TensorRT-LLM, SGLang, DeepSpeed-Inference đều áp dụng cơ chế paging tương tự.
PagedAttention cũng quan trọng như nền tảng cho "prefix sharing", khi nhiều request sử dụng cùng system prompt có thể tham chiếu cùng page mà chỉ giữ một KV vật lý. Tuy nhiên, prefix caching của vLLM chính thức chỉ dùng "đơn vị prefix khớp hoàn toàn", và tối ưu hóa khớp một phần hay tối ưu xuyên tenant đòi hỏi RadixAttention.
RadixAttention
RadixAttention do SGLang đề xuất quản lý KV cache bằng cấu trúc radix tree, cho phép chia sẻ "bất kỳ fragment prefix nào". Các cấu trúc chia sẻ lồng nhau như system prompt, few-shot examples, định nghĩa tool, context chung của tenant được tự động phát hiện và tập trung KV vật lý vào một nơi.
Trong benchmark thực đo với multi-turn chat có shared system prompt (trung bình 8 lượt, 256 session đồng thời), RadixAttention giảm 40-60% chi phí prefill và cải thiện TTFT trung vị 30-45% so với prefix caching của vLLM. Với workload agent có nhiều định nghĩa tool dài, có trường hợp chênh lệch gấp 2-3 lần.
Mặt khác, việc thiết kế eviction policy khó khăn — áp dụng LRU đơn giản sẽ khiến TTFT tăng vọt khi tenant hot và cold xen kẽ. Tại KGA, tùy tình huống chúng tôi chọn giữa weighted LRU có gán ưu tiên theo tenant, hoặc hard partitioning với phân bổ cố định theo tenant.
Sorted Batching
Sorted batching là chiến lược "gộp các request có độ dài đầu vào hoặc độ dài đầu ra còn lại gần nhau vào cùng batch". Continuous batching naive khi mix dài ngắn sẽ có kém hiệu quả do padding và padding mask, nhưng sorted batching giảm thiểu điều này. Tính đến năm 2026, đây không phải tính năng được triển khai sẵn trong serving framework mà là tính năng do router/scheduler ở tầng trên triển khai.
Thiết kế đơn giản nhất và hiệu quả nhất là phân tách endpoint dành riêng cho response ngắn (classification, reranking, tóm tắt ngắn) với endpoint cho response dài (tạo báo cáo, tạo code dài), và áp dụng sorted batching cho từng loại, với cải thiện effective throughput 20-35% đo được thực tế.
Tổng kết tác động đến SLO
- TTFT: chunked prefill và prefix caching/RadixAttention là yếu tố chi phối. Nếu có hai cái này, p50 TTFT khoảng 100ms, p99 cũng dưới 500ms.
- ITL: continuous batching và chunked prefill có hiệu quả. Nếu không có chunked prefill, p99 ITL dễ dàng vượt 200ms.
- Throughput: Tối đa hóa bằng bộ ba — PagedAttention đảm bảo hiệu quả bộ nhớ, continuous batching lấp đầy slot, RadixAttention loại bỏ lãng phí prefill.
- p99 tail: Bảo vệ bằng sorted batching và admission control. Khi QPS spike, cần admission policy để xếp hàng các request ưu tiên thấp.
Chiến lược Prompt Cache
Khi thiết kế prompt cache cho stack production, có bốn trục chính:
System prompt sharing. System prompt chung cho tất cả tenant được pre-warm khi khởi động và luôn sẵn sàng. Với RadixAttention, best practice là gửi request `warmup` bằng script khởi động để đưa vào KV tree.
Tenant partitioning. Khi mix multi-tenant kiểu SaaS, context của tenant A và B có thể bị trộn lẫn, gây vấn đề về security/compliance. Vì RadixAttention không cung cấp cách ly mật mã học, trong domain nghiêm ngặt như tài chính, y tế, cần thiết kế phân tách process (hoặc nhóm GPU) theo tenant và giới hạn lớp chia sẻ chỉ ở "system prompt không bảo mật".
TTL và eviction. Với chat agent có session dài, thiết kế lưu tạm KV trung gian của conversation nhiều lượt và evict sau N phút khi conversation bị ngắt là hiệu quả. Trong trường hợp khách hàng của KGA, TTL được đặt 15-30 phút để cân bằng áp lực bộ nhớ và chi phí prefill lại.
Cross-request dedup. Trong hệ thống agent, phổ biến có pattern truyền cùng một tool response cho nhiều LLM call; bằng cách dedup tool response này bằng fingerprint và chỉ đặt vào KV tree một lần, TTFT giảm hơn 30%.
Ví dụ cấu hình: vLLM + chunked prefill + prefix caching
```python llm = LLM( model="Qwen/Qwen3-72B-Instruct", tensor_parallel_size=8, kv_cache_dtype="fp8", enable_prefix_caching=True, enable_chunked_prefill=True, max_num_batched_tokens=8192, max_num_seqs=256, gpu_memory_utilization=0.92, block_size=16, preemption_mode="recompute", ) ```
Nếu `max_num_seqs` quá lớn, swap xảy ra thường xuyên do áp lực bộ nhớ, nên trong vận hành thực tế cần tính ngược từ QPS dự kiến và độ dài đầu ra p99. Giá trị kinh nghiệm của KGA là QPS_peak × p99_output_length / expected_decode_rate là giới hạn xấp xỉ.
Tóm tắt
Chiến lược batching không phải là "chọn một trong năm phương pháp" mà là "đưa tất cả vào rồi điều chỉnh tham số theo SLO" — đó là câu trả lời đúng của năm 2026. Để bảo vệ TTFT thì dùng chunked prefill và RadixAttention; để bảo vệ ITL thì dùng chunked prefill và sorted batching; để tăng throughput thì dùng continuous batching và PagedAttention; để bảo vệ tenant isolation thì dùng hard partitioning và tenant-aware eviction. Thiết kế kiến trúc theo bốn trục này, cấu hình 8 GPU H200 SXM với model 70B hoàn toàn có thể đạt SLO aggregate 2500 tok/s và p99 TTFT dưới 400ms.