Phân tầng lưu trữ KV cache cho suy luận AI: từ HBM đến S3
Data / Storage • AI Storage • KV cache
Lưu trữ KV cache đang trở thành một tầng storage cho AI mới: khi chatbot nhiều lượt, RAG và agent làm ngữ cảnh dài ra, bộ nhớ GPU không còn đủ chỗ giữ KV cache, và tính lại từ đầu thì tốn GPU và làm người dùng chờ lâu. Bài viết giải thích các tầng lưu trữ KV cache từ HBM, RAM, NVMe cục bộ tới flash dùng chung và S3, cách tính dung lượng cần giữ, và cách phân tầng lưu trữ KV cache phù hợp với từng khối lượng công việc suy luận AI.
1. Vì sao lưu trữ KV cache phải rời khỏi GPU?
Khi mô hình ngôn ngữ đọc prompt (pha prefill), nó tạo ra các cặp key và value cho từng token ở từng lớp. Đó là KV cache: trạng thái đã tính của ngữ cảnh, giúp pha decode không phải tính lại lịch sử khi sinh token mới. Bài KV data trong GenAI là gì đã giải thích khái niệm; bài này tập trung vào câu hỏi hạ tầng: đặt KV cache ở đâu.
Theo độ dài ngữ cảnh
Dung lượng KV cache tăng theo số token × số phiên, trong khi chi phí tính lại lịch sử tăng còn nhanh hơn.
Ngữ cảnh được dùng nhiều lần
Chatbot nhiều lượt, RAG có prefix chung, agent gọi công cụ nhiều bước đều đọc lại cùng một ngữ cảnh.
Không cần độ bền tuyệt đối
Theo NVIDIA, KV cache là dữ liệu dẫn xuất, mất thì tính lại được, nên storage cho nó ưu tiên tốc độ, điện năng và chi phí hơn độ bền.
Đây chính là loại “Agent data” mới do AI tạo ra: không phải dữ liệu nghiệp vụ gốc, nhưng giữ lại được thì GPU làm ít việc hơn và người dùng nhận token đầu tiên sớm hơn.
2. KV cache chiếm bao nhiêu dung lượng?
Dung lượng KV cache của mỗi token được tính từ cấu hình mô hình:
Llama 3.1 70B: 2 × 80 × 8 × 128 × 2 byte (BF16) = 327.680 byte ≈ 320 KiB/token
Lưu KV ở FP8: ≈ 160 KiB/token
Cấu hình 80 lớp, 8 KV head, head_dim 128 lấy từ tài liệu kỹ thuật Llama 3 của Meta. Từ đó:
| Kịch bản | Token giữ lại | KV cache | Tầng phù hợp |
|---|---|---|---|
| 1 phiên hỏi đáp ngắn | 8K | ≈ 2,5 GiB | G1 (GPU) |
| 1 phiên đọc hợp đồng dài | 128K | ≈ 40 GiB | G1 nếu đang chạy, G2/G3 khi tạm dừng |
| 200 phiên agent đồng thời | 200 × 32K | ≈ 2.000 GiB (≈ 2,1 TB) | Vượt GPU; cần G2 lớn và G3 |
| Giữ lịch sử 2.000 phiên để quay lại trong ngày | 2.000 × 32K | ≈ 20 TiB (≈ 21 TB) | G3.5 / G4 dùng chung |
Để so sánh, một máy chủ 8× RTX PRO 6000 có 768 GB bộ nhớ GPU, và sau khi trừ trọng số mô hình chỉ chứa được vài chục phiên 32K ở BF16. Phần còn lại phải được đẩy xuống tầng thấp hơn hoặc bỏ đi rồi tính lại. Cách tính VRAM cho trọng số và KV cache được trình bày trong bài chọn máy chủ GPU Supermicro cho suy luận GenAI.
3. Các tầng lưu trữ KV cache: từ G1 đến G4
NVIDIA Dynamo KV Block Manager (KVBM) chia nơi chứa KV cache thành bốn tầng: G1 bộ nhớ GPU, G2 RAM của CPU, G3 SSD NVMe cục bộ, G4 storage từ xa hoặc trên cloud. Đầu năm 2026, NVIDIA bổ sung tầng G3.5: flash gắn qua Ethernet, tối ưu cho KV cache, dùng chung ở mức pod, trong nền tảng CMX dựa trên BlueField-4 (công bố 01/2026, khi đó gọi là Inference Context Memory Storage Platform; Cloudian và Supermicro nằm trong danh sách đối tác) (Hình 1).
| Tầng | Phương tiện | Phạm vi | Vai trò | Điểm cần lưu ý |
|---|---|---|---|---|
| G1 | HBM/GDDR trên GPU | 1 GPU | KV đang dùng cho decode | Đắt nhất, cạnh tranh chỗ với trọng số mô hình |
| G2 | RAM CPU | 1 máy chủ | Vùng đệm, nhận KV vừa rời GPU | KVBM khuyến nghị cache CPU ít nhất bằng cache GPU |
| G3 | NVMe cục bộ | 1 node | Giữ KV “ấm” dung lượng lớn | Cache đĩa nên ít nhất bằng cache CPU; không dùng chung giữa node |
| G3.5 | Flash qua Ethernet (NVMe-oF, RDMA) | Pod nhiều node | Chia sẻ ngữ cảnh giữa các node GPU | Cần mạng RDMA/độ trễ thấp; hệ sinh thái đang hình thành |
| G4 | File hoặc S3 object storage | Toàn hệ thống | Lưu lâu dài lịch sử phiên, ngữ cảnh ít dùng | Độ trễ mili giây; cần băng thông cao để nạp kịp |
4. Cơ chế offload và onboard KV cache
KVBM quản lý KV cache theo khối. Khối rời GPU được sao chép sang RAM bằng CUDA, rồi ghi xuống đĩa qua NIXL, thư viện truyền dữ liệu của NVIDIA (dùng POSIX hoặc GPUDirect Storage khi có). Khi cần lại, khối trên đĩa có thể được đọc thẳng vào bộ nhớ GPU. Với tầng G4, KVBM coi storage là một kho khối dữ liệu truy cập qua NIXL, nên các hãng storage tích hợp bằng plugin NIXL của mình (Hình 2).
Hai nguyên tắc sizing từ tài liệu KVBM: cache CPU nên ít nhất bằng cache GPU, và cache đĩa ít nhất bằng cache CPU, vì KVBM hoạt động kiểu ghi xuyên (write-through) qua các tầng. Ngoài Dynamo, LMCache là lớp quản lý KV cache mã nguồn mở tích hợp với vLLM, hỗ trợ nhiều backend như RAM, đĩa cục bộ, GPUDirect Storage, NIXL, S3 và Redis. SGLang dùng HiCache với backend NIXL.
5. Tái sử dụng KV cache thay vì tính lại prefill
Lợi ích của các tầng lưu trữ KV cache đến từ một phép so sánh: nạp KV đã lưu nhanh hơn bao nhiêu so với chạy lại prefill cho toàn bộ ngữ cảnh (Hình 3). Prefill ngữ cảnh dài rất tốn GPU, nên khi tỷ lệ tái sử dụng cao, chênh lệch rất lớn.
Một thiết kế kiểm chứng của Supermicro (08/2026) cho kết quả cùng chiều: chạy gpt-oss-120b trên máy chủ 4× RTX PRO 6000, đặt toàn bộ KV cache ở tầng G4 trên IBM Storage Scale ECE chạy trên các node storage Supermicro Petascale, TTFT của một request 130K token giảm từ 32,14 giây (không cache) xuống dưới 0,6 giây. NVIDIA cũng lưu ý offload hiệu quả nhất khi cache vượt bộ nhớ GPU và lợi ích tái sử dụng lớn hơn chi phí truyền dữ liệu. Nghĩa là nếu request hầu như không lặp lại ngữ cảnh, thêm tầng lưu trữ KV cache sẽ không đem lại nhiều.
6. Chọn tầng lưu trữ KV cache theo khối lượng công việc
Không phải hệ thống inference nào cũng cần đủ năm tầng. Ba câu hỏi dưới đây giúp xác định điểm dừng hợp lý (Hình 4).
- Chatbot hỏi đáp ngắn, ít lặp lại: G1 và G2 với prefix caching của engine là đủ.
- Trợ lý tri thức nội bộ, RAG với tài liệu dùng chung: thêm G2 lớn và G3 NVMe cục bộ để giữ prefix của các tài liệu phổ biến.
- Agent nhiều bước, nhiều node GPU, người dùng quay lại phiên cũ: cần tầng dùng chung để node nào nhận request cũng nạp được ngữ cảnh, kèm G4 để lưu lịch sử dài hạn.
7. Gợi ý kiến trúc storage cho inference nhiều tầng
Với hạ tầng inference nhiều node GPU, storage cho inference nên được thiết kế như một hệ nhiều tầng, mỗi tầng dùng sản phẩm phù hợp nhất thay vì một hệ thống làm mọi việc. Với danh mục CSC phân phối, một kiến trúc tham khảo gồm:
| Tầng | Thành phần gợi ý | Điểm đáng chú ý |
|---|---|---|
| G1–G3 | Máy chủ GPU Supermicro với RAM lớn và NVMe cục bộ | Cấu hình RAM, NVMe theo nguyên tắc cache CPU ≥ cache GPU, cache đĩa ≥ cache CPU |
| Flash dùng chung | Lightbits NVMe/TCP trên máy chủ Supermicro | Block storage phân tán chạy trên Ethernet tiêu chuẩn, không cần NIC đặc biệt; Lightbits công bố độ trễ dưới mili giây và ra mắt Inferra, engine điều phối KV cache, tháng 09/2026 |
| Object dùng chung | Cloudian HyperStore với S3 over RDMA | Có plugin RDMA cho NIXL đã thử nghiệm với Dynamo KVBM; Cloudian là đối tác của nền tảng NVIDIA CMX |
| Điều phối | NVIDIA Dynamo KVBM hoặc LMCache, trên vLLM / TensorRT-LLM / SGLang | Quyết định chính sách offload, định tuyến request về nơi có sẵn KV |
Cách tiếp cận software-defined storage (SDS) giúp doanh nghiệp không bị khóa vào một hãng: tầng flash và tầng object chạy trên máy chủ x86 tiêu chuẩn, mở rộng độc lập theo nhu cầu. Lightbits Inferra là sản phẩm mới công bố; các thông số như số phiên đồng thời tăng tới 16 lần là con số của hãng chưa kèm điều kiện thử nghiệm, nên cần PoC trước khi đưa vào thiết kế. Lightbits hiện chưa nằm trong danh sách đối tác NVIDIA CMX công bố 01/2026. Tham khảo thêm RDMA cho S3 và giải pháp storage cho AI và HPC của CSC.
8. Câu hỏi thường gặp
KV cache là gì và vì sao cần lưu trữ riêng?
KV cache là các cặp key, value mô hình tạo ra khi đọc ngữ cảnh. Khi ngữ cảnh dài và được dùng lại nhiều lần, KV cache vượt bộ nhớ GPU; lưu nó ở RAM, NVMe hoặc storage dùng chung giúp tránh tính lại prefill và giảm thời gian ra token đầu tiên.
Một token chiếm bao nhiêu dung lượng KV cache?
Tính bằng 2 × số lớp × số KV head × head_dim × byte. Với Llama 3.1 70B ở BF16 là khoảng 320 KiB/token, tức khoảng 40 GiB cho một phiên 128K token.
G1, G2, G3, G4 trong lưu trữ KV cache là gì?
Đây là cách NVIDIA Dynamo phân tầng: G1 bộ nhớ GPU, G2 RAM CPU, G3 NVMe cục bộ, G4 storage từ xa. NVIDIA bổ sung G3.5 là flash dùng chung qua Ethernet trong nền tảng CMX.
Khi nào cần tầng lưu trữ KV cache dùng chung?
Khi nhiều node GPU cần truy cập cùng ngữ cảnh, khi agent chạy nhiều bước hoặc người dùng quay lại phiên cũ, và tổng KV cần giữ vượt dung lượng RAM và NVMe của từng node.
Object storage S3 có đủ nhanh cho KV cache không?
Với RDMA, S3 có thể phục vụ KV cache cho ngữ cảnh dài. Trong thử nghiệm của Cloudian, nạp KV cache 120K token qua S3/RDMA cho P95 TTFT 7,59 giây so với 158,86 giây khi tính lại. Kết quả cần được kiểm chứng bằng PoC.
