Thuế KV Cache: Vì sao máy chủ suy luận LLM cạn kiệt VRAM trước khi hết năng lực tính toán

Khi vận hành các mô hình ngôn ngữ lớn (LLM) trong môi trường sản xuất, nhiều kỹ sư bất ngờ phát hiện ra rằng máy chủ GPU thường cạn kiệt bộ nhớ (OOM) trước khi đạt đến giới hạn năng lực tính toán. Thủ phạm chính là KV Cache — bộ nhớ đệm lưu trữ các vector Key và Value của cơ chế attention.

Bài viết này sẽ mổ xẻ hiện tượng "thuế KV Cache" và đưa ra công thức tính ngân sách VRAM thực tế, cùng ba chiến lược tối ưu hóa tương ứng với từng kiểu lưu lượng truy cập.

KV Cache là gì và vì sao nó "đánh thuế" lên VRAM?

Trong kiến trúc Transformer, khi mô hình sinh từng token mới, nó cần tính toán attention với toàn bộ các token trước đó. Nếu không có bộ nhớ đệm, mỗi bước sinh sẽ phải tính lại toàn bộ chuỗi — cực kỳ tốn kém.

KV Cache giải quyết vấn đề này bằng cách lưu sẵn các vector Key và Value của mọi token đã sinh. Nhờ đó, mỗi bước chỉ cần tính attention cho token mới nhất. Đây là yếu tố then chốt giúp suy luận LLM khả thi về mặt tốc độ.

Tuy nhiên, cái giá phải trả là bộ nhớ. Kích thước KV Cache tỉ lệ thuận với:

• Độ dài ngữ cảnh (số token trong cửa sổ context)
• Số lượng request đồng thời (batch size)
• Kích thước mô hình (số lớp, số head attention, chiều ẩn)

Với các mô hình hiện đại hỗ trợ context hàng trăm nghìn token, KV Cache có thể chiếm phần lớn dung lượng VRAM — vượt xa cả trọng số mô hình trong nhiều trường hợp.

Công thức tính ngân sách VRAM cho máy chủ suy luận

Một công thức ước lượng thực dụng cho dung lượng VRAM cần thiết:

VRAM tổng = Trọng số mô hình + KV Cache + Bộ nhớ hoạt động (activations) + Overhead của framework

Trong đó, dung lượng KV Cache được tính xấp xỉ:

KV Cache (bytes) = 2 × số_lớp × số_head_kv × chiều_head × độ_dài_context × batch_size × độ_chính_xác (bytes)

Yếu tố 2 đại diện cho cả Key và Value. Với các mô hình dùng GQA (Grouped Query Attention) hoặc MQA (Multi-Query Attention), số_head_kv nhỏ hơn nhiều so với số head truyền thống — giúp tiết kiệm VRAM đáng kể.

Ví dụ, một mô hình 70B tham số ở độ chính xác FP16 cần khoảng 140GB chỉ riêng cho trọng số. Khi phục vụ nhiều request với context dài, KV Cache có thể dễ dàng "ngốn" thêm hàng chục GB nữa.

Ba chiến lược tối ưu hóa theo kiểu lưu lượng

Không phải mọi lưu lượng đều giống nhau. Việc chọn chiến lược tối ưu cần dựa trên đặc điểm request thực tế.

1. Paged Attention — cho lưu lượng biến động

Kỹ thuật này chia KV Cache thành các "trang" nhỏ, cấp phát động thay vì giữ một vùng nhớ liền mạch cho mỗi request. Điều này giảm phân mảnh bộ nhớ và tăng tỉ lệ sử dụng VRAM.

• Phù hợp khi: Độ dài output của các request rất khác nhau, lưu lượng dao động mạnh.
• Lợi ích: Tiết kiệm 60-80% VRAM so với cấp phát tĩnh truyền thống.
• Đại diện: vLLM là framework tiên phong triển khai kỹ thuật này.

2. Lượng tử hóa KV Cache — cho mô hình lớn, phần cứng hạn chế

Thay vì lưu KV Cache ở FP16, ta có thể lượng tử hóa xuống INT8 hoặc thậm chí INT4. Điều này giảm một nửa hoặc ba phần tư dung lượng bộ nhớ đệm.

• Phù hợp khi: Cần chạy mô hình lớn trên GPU có VRAM hạn chế.
• Đánh đổi: Có thể giảm nhẹ chất lượng output, cần kiểm thử kỹ.

3. Chia sẻ tiền tố (Prefix Caching) — cho lưu lượng lặp lại

Nhiều ứng dụng có system prompt hoặc ngữ cảnh chung giống nhau giữa các request. Prefix Caching cho phép tái sử dụng KV Cache của phần tiền tố chung, chỉ tính toán phần mới.

• Phù hợp khi: Chatbot có system prompt dài, ứng dụng RAG với tài liệu nền tảng cố định.
• Lợi ích: Giảm đáng kể cả độ trễ lẫn bộ nhớ cho các request lặp lại.

Góc nhìn cho đội ngũ kỹ thuật tại Việt Nam

Với các startup và doanh nghiệp Việt Nam đang triển khai LLM nội bộ, việc hiểu rõ ngân sách VRAM là yếu tố sống còn để kiểm soát chi phí hạ tầng cloud. Chi phí thuê GPU H100 hay A100 vẫn ở mức cao, nên tối ưu KV Cache đồng nghĩa với việc phục vụ được nhiều người dùng hơn trên cùng một tài nguyên.

Lời khuyên thực tế:

• Đo lường trước khi tối ưu: Theo dõi tỉ lệ VRAM dành cho KV Cache so với trọng số mô hình.
• Chọn framework phù hợp: vLLM, TGI (Text Generation Inference) hay TensorRT-LLM đều có cơ chế quản lý KV Cache khác nhau.
• Cân nhắc GQA/MQA: Ưu tiên các mô hình hỗ trợ Grouped Query Attention để giảm nhu cầu bộ nhớ ngay từ thiết kế.

Kết luận

"Thuế KV Cache" là một thực tế không thể tránh khỏi khi phục vụ LLM ở quy mô lớn. Hiểu rõ công thức tính ngân sách VRAM và ánh xạ đúng chiến lược tối ưu với kiểu lưu lượng sẽ giúp đội ngũ kỹ thuật tránh được những sự cố OOM bất ngờ — và quan trọng hơn, tận dụng tối đa phần cứng đắt đỏ đang sở hữu.