Tại sao KV cache là nút cổ chai của serving
Khi chạy 256 session song song với mô hình dense cỡ 70B và độ dài chuỗi 128K, chỉ KV cache đã đòi hỏi HBM cỡ 1TB. Với MoE (Mixtral-8x22B, dòng DeepSeek-V3), tính toán hoạt động thưa nhờ lựa chọn expert nên nhẹ hơn, nhưng áp lực dung lượng KV cache tương đương hoặc hơn dense vì KV cache được giữ nguyên hoàn toàn. Vấn đề mà nhóm serving năm 2026 dành phần lớn ngày của mình là "nhồi nhét KV như thế nào để GPU compute hoạt động", và HBM đơn thuần rõ ràng là không đủ. Bài viết này tổng hợp lượng tử hóa FP8, paging, offload CPU / NVMe, RadixAttention và cô lập multi-tenant như một lý luận thiết kế thống nhất.
Đánh đổi chất lượng của FP8 KV cache
FP8 KV (thường là E5M2 hoặc E4M3) giảm một nửa mức sử dụng HBM so với FP16. Tính đến năm 2025, sự suy giảm chất lượng đầu ra còn là mối lo ngại, nhưng hiện tại năm 2026, quan điểm thông thường từ nhiều bài báo và benchmark nội bộ là "nếu chọn phương pháp lượng tử hóa phù hợp, tổn thất chất lượng dưới 0,5%". Khuyến nghị như sau.
- E5M2 (5 exp, 2 mantissa): Dynamic range rộng hơn. Mạnh với workload ngữ cảnh dài, đa ngôn ngữ. Tổn thất độ chính xác lớn hơn E4M3 đôi chút, nhưng ít thất bại kiểu hallucination hơn.
- E4M3 (4 exp, 3 mantissa): Nhiều mantissa hơn, nghiêng về độ chính xác. Phù hợp với tạo code, lập luận toán học. Activation có outlier bị clip.
- per-channel scale + per-token shift: Là lượng tử hóa nhận thức activation, hấp thụ outlier. Đã được triển khai trong cả dòng SGLang 0.4 và vLLM 0.7.
Trong benchmark chất lượng của KGA (MT-Bench, HumanEval, JMMLU, 4 benchmark RAG tiếng Nhật nội bộ), khi hạ Llama-3.3-70B từ FP16 KV xuống FP8 E5M2 KV, suy giảm aggregate score là -0,3%, và với Qwen3-72B là -0,6%. Trong khi đó, mức sử dụng HBM giảm một nửa và số session đồng thời trên cùng GPU có thể tăng gấp 1,8 lần. Nếu triển khai sản xuất, nên đặt E5M2 làm cấu hình ban đầu và cân nhắc E4M3 cho endpoint chuyên code/toán.
Profile bộ nhớ của MoE
Mô hình MoE dễ bị hiểu nhầm do tính thưa của routing, nhưng KV cache được fully materialize cho tất cả token. Với dòng DeepSeek-V3 (671B tổng, 37B được kích hoạt), tham số expert chiếm phần lớn HBM, nhưng trong vận hành ngữ cảnh dài, KV vượt qua và trở nên thống trị.
Có ba điểm thiết kế KV đặc thù của MoE. Thứ nhất, mô hình dòng MLA (Multi-head Latent Attention) có biểu diễn nén của KV từ training, và dung lượng KV nhỏ hơn hơn 70% so với mô hình dense có tham số tương đương. Ở các mô hình như DeepSeek-V3 và dòng Qwen3-MoE, điều này giảm đáng kể chi phí serving. Thứ hai, khi trộn lẫn vị trí expert theo GPU (expert parallelism) và vị trí KV cache (tensor parallelism), sự lệch tải khiến KV của một số GPU tràn trước. Thiết kế phân tách EP và TP đúng cách và phân phối KV đều lên tất cả GPU là bắt buộc. Thứ ba, do có độ lệch trong pattern hot/cold của expert được kích hoạt bởi routing, cần thiết kế prefetch với tiền đề là KV của expert được kích hoạt thường xuyên được truy cập thường xuyên.
Paging và offload CPU / NVMe
PagedAttention quản lý KV theo đơn vị trang 16 token và không cần cấp phát HBM vật lý liên tục. Hiện tại năm 2026, cấu hình trải rộng "trang" này qua ba tầng HBM, bộ nhớ CPU và NVMe đã bước vào giai đoạn thực dụng.
Offload CPU. Chuyển KV của session nhàn rỗi (chờ người dùng, agent step đang suy nghĩ) sang bộ nhớ CPU. Chi phí truyền PCIe khi khởi động lại là khoảng 40GB/s, và KV của chuỗi 128K với mô hình 70B có thể đưa về GPU trong vài trăm ms. Sử dụng một trong: vLLM swap, offload backend của SGLang, LMCache.
Offload NVMe. Hạ thêm session ít thường xuyên hơn (nhàn rỗi vài phút đến vài giờ) xuống NVMe. Với Gen5 NVMe đạt 12GB/s hiệu quả, chi phí khôi phục cho KV 128K là 2~3 giây. Khi khôi phục sau khi nhàn rỗi lâu, pipeline hóa bất đồng bộ khôi phục hai giai đoạn "NVMe đến CPU, CPU đến GPU".
Policy phân cấp. Trong trường hợp của khách hàng KGA, heuristic hạ KV 30 giây hoạt động gần nhất xuống HBM, 30 giây đến 10 phút xuống CPU, hơn 10 phút xuống NVMe là đa năng. Tuy nhiên, trong multi-tenant cần đặt TTL riêng cho từng tenant.
Benchmark LMCache và SGLang RadixAttention
Benchmark được chuẩn bị nội bộ tại KGA trong Q1 năm 2026. Workload là RAG chat (system prompt 1,5K, context được truy xuất 8K, user turn trung bình 200 token, đa lượt trung bình 6 lượt), mô hình là Qwen3-72B FP8, phần cứng H200 SXM 8 thẻ.
- Chỉ vLLM prefix caching: aggregate throughput 2100 tok/s, TTFT p50 210ms, TTFT p99 720ms, tỷ lệ tính lại prefill 38%.
- SGLang RadixAttention: throughput 2650 tok/s, TTFT p50 140ms, TTFT p99 510ms, tỷ lệ tính lại prefill 17%.
- vLLM + LMCache (CPU+NVMe local): throughput 2450 tok/s, TTFT p50 160ms, TTFT p99 430ms, tỷ lệ tính lại prefill 11%.
- vLLM + LMCache (phân tán, NVMe chia sẻ): throughput 2380 tok/s, TTFT p50 180ms, TTFT p99 480ms, tỷ lệ tính lại prefill 6%. Khi phân tán, không thể đánh bại việc tái sử dụng HBM local theo node, nhưng hiệu quả chia sẻ cache trên toàn cluster có ảnh hưởng đến p99.
Kết luận, với single node là SGLang RadixAttention, khi cần cache chia sẻ multi-node là vLLM + LMCache là hai mạnh nhất hiện tại. TensorRT-LLM cũng có tính năng tương đương nhưng vLLM và SGLang có lợi thế về tính linh hoạt cấu hình.
Cô lập và công bằng trong multi-tenant
Khi serving multi-tenant trong SaaS, tầng KV có bốn ràng buộc thiết kế.
Rủi ro rò rỉ. Khi chia sẻ cùng system prompt không có vấn đề gì, nhưng khả năng "cache timing side channel" mà request của tenant khác tham chiếu KV chứa dữ liệu riêng của tenant không hoàn toàn bằng không. Với lĩnh vực bảo mật cao như tài chính, y tế, chính phủ, giải pháp thực tế là cô lập đến cấp GPU process hoặc nhóm GPU theo từng tenant và phân tách KV vật lý.
Công bằng. LRU đơn giản sẽ khiến tenant gửi nhiều request chiếm KV, làm TTFT của tenant khác suy giảm. KGA đề xuất hybrid policy "đặt quota KV theo từng tenant, phần vượt quota là LRU nhưng trong vận hành bình thường giới hạn tối đa 1 tenant là 50%".
Chất lượng dịch vụ theo SLA. Đã trở nên phổ biến việc đảm bảo slot thường trú HBM cho tenant premium, và ưu tiên offload CPU/NVMe cho tenant cơ bản. Cả vLLM và SGLang đều có pluggable scheduler và có thể triển khai policy tùy chỉnh.
Khả năng quan sát. Khi dashboard hóa KV hit rate theo tenant, KV eviction rate và mức sử dụng KV quota bằng prometheus exporter, thanh toán và kế hoạch capacity có thể liên kết. Trong stack chuẩn của KGA, điều này được trực quan hóa bằng Grafana.
Ví dụ cấu hình: vLLM + LMCache + FP8 KV
```python from vllm import LLM from lmcache.integration.vllm import LMCacheConnector
llm = LLM( model="Qwen/Qwen3-72B-Instruct", tensor_parallel_size=8, kv_cache_dtype="fp8_e5m2", enable_prefix_caching=True, enable_chunked_prefill=True, max_num_batched_tokens=8192, kv_transfer_config={ "kv_connector": "LMCacheConnector", "kv_role": "kv_both", "kv_buffer_size": 5e9, }, ) ```
Phía LMCache phân bổ 256GB cho tầng CPU và 2TB cho tầng NVMe, cắt logical namespace theo từng tenant và quản lý quota.
Kết luận
KV cache năm 2026 không còn là thời đại "giữ một cách thô sơ lượng vừa vào HBM". Giảm một nửa dung lượng bằng FP8 KV, thu nhỏ theo cấu trúc bằng mô hình dòng MLA, loại bỏ fragmentation bằng PagedAttention, khai thác chia sẻ prefix bằng LMCache hoặc RadixAttention, lưu trữ KV dài hạn bằng phân cấp CPU / NVMe, bảo vệ chất lượng dịch vụ bằng policy cô lập multi-tenant và công bằng. Sáu tầng này hoạt động đồng thời mới có thể đạt được throughput thực tế vài nghìn tok/s mỗi node và SLO TTFT p99 500ms. Người kiểm soát KV kiểm soát LLM serving năm 2026.