Câu “DeepSeek V4 dùng ít hơn 98% bộ nhớ” nghe rất hấp dẫn, nhất là với những đội đang đau đầu vì chi phí GPU. Nhưng điểm dễ gây hiểu nhầm nằm ở chữ bộ nhớ: bằng chứng hiện có ủng hộ việc DeepSeek V4 nén mạnh KV cache trong suy luận ngữ cảnh dài, chứ chưa đủ để kết luận toàn bộ nhu cầu VRAM khi triển khai mô hình giảm 98% [5][
13][
14].
Nói ngắn gọn: nếu dùng con số 98% để làm tiêu đề thì được nhiều lượt chú ý; nếu dùng nó để lập kế hoạch mua GPU, tính công suất phục vụ hay viết tài liệu marketing thì rất dễ sai.
Kết luận an toàn nhất lúc này
Cách diễn đạt thận trọng hơn là:
DeepSeek V4 sử dụng Hybrid Attention, Compressed Sparse Attention (CSA) và Heavily Compressed Attention (HCA) để giảm đáng kể áp lực KV cache trong suy luận ngữ cảnh dài; nhưng dữ liệu công khai hiện chưa đủ để nói rằng tổng VRAM triển khai mô hình giảm 98% [
13][
14].
Phân biệt này rất quan trọng. KV cache là một trong các nút thắt lớn của mô hình ngôn ngữ khi xử lý ngữ cảnh dài, nhưng nó không phải toàn bộ chi phí bộ nhớ của một hệ thống serving.
Tài liệu chính thức xác nhận điều gì?
Trang tin API của DeepSeek ghi nhận DeepSeek-V4 Preview được phát hành ngày 24/4/2026 [5]. Model card của DeepSeek V4 cho biết dòng mô hình gồm DeepSeek-V4-Pro và DeepSeek-V4-Flash; V4 được mô tả là một dòng mô hình ngôn ngữ Mixture-of-Experts (MoE), giữ lại DeepSeekMoE framework và chiến lược Multi-Token Prediction (MTP), đồng thời bổ sung các thay đổi kiến trúc như Hybrid Attention Architecture [
14].
Phần liên quan trực tiếp nhất đến chuyện “tiết kiệm bộ nhớ” là cách V4 xử lý attention cho ngữ cảnh dài. Bài kỹ thuật của NVIDIA nói rằng Compressed Sparse Attention (CSA) dùng dynamic sequence compression để nén KV entries, qua đó giảm memory footprint của KV cache, rồi dùng DeepSeek Sparse Attention (DSA) để làm attention matrices thưa hơn; Heavily Compressed Attention (HCA) còn nén mạnh hơn bằng cách gộp KV entries của nhiều nhóm token thành một compressed entry duy nhất, giúp giảm kích thước KV cache [13].
Vì vậy, dữ liệu hiện có cho phép nói: DeepSeek V4 có thiết kế nhằm giảm kích thước KV cache và chi phí tính toán attention trong ngữ cảnh dài. Nhưng đó chưa phải là bằng chứng cho thấy mọi thành phần VRAM đều giảm theo cùng một tỷ lệ.
98%, 90% và 9,5 lần: đừng trộn ba con số này
Trong các nguồn hiện có, con số 98% xuất hiện trực tiếp nhất trong một bài viết do người dùng tạo trên LinkedIn, với tiêu đề nói rằng “DeepSeek Sparse Attention Shrinks KV Memory by 98 Percent in Real World Serving” [21]. Nội dung kiểu này có thể là đầu mối để truy vết, nhưng không nên xem như thông số chính thức của DeepSeek.
Một con số bên thứ ba dễ đối chiếu hơn là 10% KV cache. Wccftech đưa tin rằng so với DeepSeek V3.2, DeepSeek V4 chỉ cần 27% single-token inference FLOPs và 10% key-value (KV) cache [20]. Nếu chỉ hiểu theo “10% KV cache”, nghĩa là KV cache giảm khoảng 90%; nhưng mốc so sánh ở đây là DeepSeek V3.2, và điều đó không đồng nghĩa mọi độ dài context, batch size, cấu hình phần cứng hoặc tổng VRAM đều giảm 90% [
20].
Một số tiêu đề khác mô tả DeepSeek V4 có nhu cầu bộ nhớ thấp hơn 9,5 lần [3]. Ngay cả khi quy đổi đơn giản, 1/9,5 tương đương còn khoảng 10,5% nhu cầu, tức giảm khoảng 89,5%; con số này vẫn không phải 98%, và vẫn cần biết nó đang nói về KV cache, một kịch bản ngữ cảnh dài cụ thể hay toàn bộ bộ nhớ triển khai [
3].
| Cách nói | Tình trạng bằng chứng | Cách hiểu thận trọng hơn |
|---|---|---|
| Tổng VRAM giảm 98% | Chưa thấy tài liệu chính thức ủng hộ | Không nên đưa vào thông số mua sắm, triển khai hoặc quảng bá [ |
| KV cache được nén mạnh | Có tài liệu kỹ thuật ủng hộ | CSA/HCA nhắm vào việc nén KV entries trong ngữ cảnh dài [ |
| Chỉ còn 10% KV cache | Xuất hiện trong bài bên thứ ba | Có thể hiểu là giảm khoảng 90% KV cache so với V3.2 trong bối cảnh được nêu, không phải giảm tổng VRAM [ |
| Bộ nhớ thấp hơn 9,5 lần | Tiêu đề tin bên thứ ba | Xấp xỉ giảm 89,5%, nhưng vẫn cần xác định phạm vi so sánh [ |
Vì sao KV cache không phải là toàn bộ VRAM?
KV cache đặc biệt quan trọng khi mô hình xử lý context dài. Bài giới thiệu của Hugging Face về DeepSeek V4 giải thích rằng trong các agentic workload kéo dài, kết quả từ công cụ liên tục được thêm vào context; các token tiếp theo phải xử lý một ngữ cảnh ngày càng dài hơn, trong khi single-token inference FLOPs và kích thước KV cache đều tăng theo sequence length [17]. Phiên bản GitHub của bài này cũng mô tả các lỗi thường gặp trong tác vụ dài: trace vượt quá context budget, KV cache lấp đầy GPU, hoặc các vòng gọi công cụ làm tác vụ chậm dần [
22].
Nhưng khi triển khai đầy đủ một mô hình, VRAM không chỉ dành cho KV cache. Ngay cả bài LinkedIn nêu con số 98% cũng tách riêng shared weights, expert weights, activations, KV cache và framework overhead [21]. Điều này cho thấy khi tính hạ tầng, cần nhìn từng thành phần riêng: KV cache có thể giảm rất mạnh trong một kịch bản ngữ cảnh dài, nhưng không thể tự động suy ra toàn bộ serving stack sẽ giảm VRAM theo cùng tỷ lệ.
CSA/HCA là tối ưu kỹ thuật, không phải “con số thần kỳ”
Điểm đáng chú ý của DeepSeek V4 là nó nhắm vào một trong những phần đắt đỏ nhất khi suy luận ở quy mô million-token context: attention và KV cache trên chuỗi rất dài. Theo mô tả của NVIDIA, CSA/HCA nén KV entries, làm attention matrices thưa hơn và gộp KV entries của nhiều tập token để giảm kích thước KV cache cũng như chi phí tính toán [13].
Báo cáo kỹ thuật DeepSeek V4 cũng nói đến các tối ưu hạ tầng cho suy luận và huấn luyện, chẳng hạn thiết kế một single fused kernel cho các MoE modules để chồng lấp computation, communication và memory access [2]. Đây là các tối ưu hiệu năng đáng chú ý, nhưng vẫn không phải bằng chứng trực tiếp cho tuyên bố “tổng VRAM giảm 98%”.
Khi đánh giá DeepSeek V4, nên nhìn vào gì?
Nếu bạn đang cân nhắc DeepSeek V4 cho tài liệu dài, hội thoại dài hoặc workflow kiểu agent, điều quan trọng không phải là chạy theo tiêu đề “98%”, mà là xác định nút thắt của bạn có thật sự nằm ở KV cache hay không. Dữ liệu công khai hiện đủ để nói V4 có tối ưu rõ ràng cho KV cache trong ngữ cảnh dài, nhưng chưa đủ để đưa “98% less memory” vào tài liệu mua sắm, capacity planning hoặc thông điệp marketing [13][
20][
21][
22].
Cách chắc chắn hơn là benchmark bằng chính workload của bạn: độ dài context, batch size, concurrency, serving engine và phần cứng cụ thể. Nếu hệ thống chủ yếu bị giới hạn bởi KV cache, thiết kế nén của V4 có thể rất giá trị. Nếu nút thắt nằm ở model weights, activations, framework overhead hoặc chiến lược phục vụ đồng thời, việc KV cache giảm mạnh sẽ không tự động biến thành mức tiết kiệm tổng VRAM tương ứng [13][
21][
22].
