KV Cache là bộ nhớ đệm lưu trữ các trạng thái key-value (KV states) đã tính toán trong quá trình suy luận của mô hình ngôn ngữ lớn (LLM), để tái sử dụng thay vì tính lại từ đầu mỗi khi mô hình xử lý thêm nội dung mới. Ngày 5/11/2026, Supermicro, IBM và NVIDIA đã công bố một giải pháp KV cache lưu trữ chung, tích hợp máy chủ lưu trữ all-flash Supermicro Petascale dùng CPU AMD EPYC 9005 Series (“Turin”), phần mềm IBM Storage Scale, framework suy luận NVIDIA Dynamo và switch NVIDIA Spectrum-X Ethernet. Theo công bố, giải pháp này giảm thời gian tới token đầu tiên (TTFT) cho cửa sổ ngữ cảnh dài so với hệ thống không có KV cache, đồng thời cải thiện hiệu quả sử dụng GPU, thông lượng và khả năng mở rộng.
Bài viết này giải thích KV cache từ gốc — từ cơ chế attention, hai pha prefill và decode của suy luận LLM, cho đến vì sao ngữ cảnh dài và các AI agent khiến KV cache phình to vượt khỏi bộ nhớ GPU — rồi phân tích giải pháp Supermicro–IBM–NVIDIA gồm những gì, phù hợp với ai, và so sánh với các cách tối ưu suy luận khác như quantization, speculative decoding hay continuous batching. Cuối bài là checklist giúp doanh nghiệp tự đánh giá có cần đầu tư hạ tầng KV cache hay không. Lưu ý: bài viết chỉ nêu các cải thiện hiệu năng theo đúng công bố chung của ba hãng — giảm TTFT và cải thiện hiệu quả GPU cùng thông lượng — và không tự thêm bất kỳ hệ số lần hay con số hiệu năng cụ thể nào.
KV Cache là gì?
KV Cache là viết tắt của Key-Value Cache — bộ nhớ đệm lưu các cặp key và value mà mô hình Transformer đã tính ra cho các token đã xử lý, để khi mô hình cần xử lý token tiếp theo, nó có thể dùng lại các giá trị đã tính thay vì tính lại toàn bộ từ đầu. Hiểu đơn giản: KV cache là “bản nháp tính toán” mà LLM giữ lại trong lúc trò chuyện, để mỗi câu trả lời mới không phải làm lại toàn bộ phép tính của những gì đã nói trước đó.
Để hiểu vì sao KV cache tồn tại, cần hiểu cách LLM sinh văn bản. Mô hình ngôn ngữ lớn không viết ra cả câu trả lời trong một lần, mà sinh từng token một — mỗi token có thể là một từ, một phần của từ, hoặc một ký tự đặc biệt. Mỗi khi sinh token mới, mô hình phải “nhìn lại” toàn bộ các token trước đó để quyết định token tiếp theo nên là gì. Cơ chế để nhìn lại đó gọi là attention. Và chính attention là nơi KV cache phát huy tác dụng.
Attention và key-value states
Trong kiến trúc Transformer — nền tảng của hầu hết LLM hiện nay như GPT, Claude, Llama hay Gemini — mỗi token đầu vào được biến đổi thành ba vector: query (Q), key (K) và value (V). Có thể hình dung bằng một phép ẩn dụ quen thuộc: query là “câu hỏi” mà token hiện tại đang đặt ra, key là “nhãn” của từng token trước đó để đối chiếu, và value là “nội dung” thực sự của từng token đó. Khi mô hình muốn biết token hiện tại liên quan đến token nào trong quá khứ, nó so sánh query với các key, tính ra trọng số attention, rồi lấy trung bình có trọng số của các value tương ứng.
Điểm mấu chốt là: với một token đã xử lý xong, key và value của nó không thay đổi trong suốt phần còn lại của phiên suy luận. Token thứ nhất có key và value cố định, dù mô hình đang sinh token thứ mười hay token thứ một nghìn. Vì vậy, thay vì tính lại key và value cho toàn bộ các token trước đó mỗi khi sinh token mới — một công việc lặp lại gây lãng phí rất lớn — mô hình tính một lần rồi lưu lại. Nơi lưu trữ đó chính là KV cache.
Nói cách khác, KV cache biến một bài toán có độ phức tạp tăng theo bình phương độ dài ngữ cảnh thành một bài toán mà mỗi token mới chỉ cần tính toán cho chính nó, rồi đọc lại các giá trị đã lưu. Đây là tối ưu nền tảng, gần như mọi hệ thống suy luận LLM hiện đại đều dùng, từ chatbot trên điện thoại đến cụm GPU trong trung tâm dữ liệu.
Hai pha của suy luận LLM: prefill và decode
Suy luận LLM gồm hai pha rõ rệt: prefill và decode. Hiểu rõ hai pha này là chìa khóa để hiểu vì sao KV cache quan trọng và vì sao giải pháp của Supermicro, IBM và NVIDIA lại nhắm vào thời gian tới token đầu tiên.
Pha prefill: xử lý toàn bộ đầu vào
Pha prefill là giai đoạn mô hình xử lý toàn bộ prompt đầu vào — ví dụ toàn bộ lịch sử trò chuyện, toàn bộ tài liệu đính kèm, toàn bộ system prompt — và chuyển chúng thành các token, đồng thời tính ra key-value states cho tất cả các token đó. Đây là pha tính toán nặng và có thể xử lý song song: vì toàn bộ đầu vào đã có sẵn ngay từ đầu, mô hình có thể tính key và value cho mọi token cùng lúc trên GPU.
Kết quả của pha prefill là hai thứ: một là KV cache chứa key-value states của toàn bộ prompt, hai là token đầu tiên của câu trả lời. Thời gian từ lúc người dùng gửi yêu cầu đến lúc nhận được token đầu tiên này gọi là TTFT — Time To First Token, thời gian tới token đầu tiên. TTFT là chỉ số trải nghiệm người dùng quan trọng bậc nhất trong các ứng dụng tương tác: với chatbot, TTFT dài nghĩa là người dùng phải chờ lâu mới thấy chữ đầu tiên hiện ra; với coding assistant, TTFT dài nghĩa là gợi ý code xuất hiện chậm sau mỗi lần gõ.
Pha decode: sinh từng token một
Pha decode là giai đoạn mô hình sinh lần lượt từng token của câu trả lời. Mỗi bước decode, mô hình chỉ cần tính key và value cho một token mới duy nhất, rồi đọc lại KV cache của tất cả các token trước đó để tính attention. Đây là pha khó song song hóa: token sau phụ thuộc vào token trước, nên mô hình phải sinh tuần tự, token này xong mới đến token kia. Vì vậy pha decode thường bị giới hạn bởi băng thông bộ nhớ — tốc độ đọc KV cache — nhiều hơn là bởi khả năng tính toán thuần túy của GPU.
Chính ở đây KV cache thể hiện giá trị: nếu không có KV cache, mỗi bước decode sẽ phải tính lại key và value cho toàn bộ ngữ cảnh, khiến thời gian sinh mỗi token tăng theo độ dài ngữ cảnh và nhanh chóng trở nên không chấp nhận được. Với KV cache, chi phí mỗi bước decode gần như không đổi theo độ dài ngữ cảnh, chỉ tăng theo dung lượng bộ nhớ cần đọc. Nhưng đổi lại, dung lượng KV cache tăng tuyến tính theo độ dài ngữ cảnh — và đó chính là vấn đề khi ngữ cảnh ngày càng dài.
Vì sao ngữ cảnh dài và AI agent làm KV cache phình to?
Trong những năm đầu của LLM, cửa sổ ngữ cảnh chỉ vài nghìn token, KV cache dễ dàng nằm gọn trong bộ nhớ GPU. Ngày nay, nhiều mô hình hỗ trợ ngữ cảnh hàng trăm nghìn, thậm chí hàng triệu token. Một phiên làm việc với tài liệu dài, một cuộc trò chuyện kéo dài nhiều giờ, hay một tác vụ phân tích cả một codebase — tất cả đều tạo ra lượng KV state khổng lồ. Khi KV cache vượt quá bộ nhớ GPU (HBM) và cả bộ nhớ CPU (RAM), hệ thống buộc phải offload — chuyển KV cache ra các tầng lưu trữ dung lượng lớn hơn nhưng chậm hơn, thường là ổ SSD/NVMe hoặc lưu trữ mạng.
Các workflow AI agent càng làm vấn đề trầm trọng hơn. Một agent không chỉ hỏi đáp một lượt mà thực hiện nhiều lượt liên tiếp: suy luận, gọi công cụ, đọc kết quả, suy luận tiếp. Mỗi lượt lại thêm token vào ngữ cảnh, và KV cache cứ thế lớn dần qua từng lượt. Coding assistant cũng tương tự: mỗi lần lập trình viên gõ thêm, toàn bộ ngữ cảnh gồm code hiện tại, lịch sử chỉnh sửa và tài liệu tham khảo đều phải được tính đến. RAG (Retrieval-Augmented Generation) với ngữ cảnh dài thì đưa cả các đoạn tài liệu truy xuất được vào prompt, làm ngữ cảnh dài thêm nữa. AI đa phương thức còn cộng thêm token hình ảnh và âm thanh, mỗi loại đều sinh ra KV state của riêng nó.
Kết quả là một nghịch lý: GPU ngày càng mạnh về tính toán, nhưng suy luận LLM ngày càng bị giới hạn bởi bộ nhớ — cụ thể là dung lượng và băng thông của nơi lưu KV cache. Một GPU có thể tính rất nhanh, nhưng nếu nó phải chờ đọc KV cache từ bộ nhớ chậm, hoặc tệ hơn, phải tính lại KV state vì cache đã bị xóa do hết chỗ, thì toàn bộ hệ thống chậm lại. Đây chính là nút thắt mà giải pháp KV cache lưu trữ của Supermicro, IBM và NVIDIA nhắm tới: đưa KV cache ra khỏi GPU nhưng vẫn giữ tốc độ truy cập đủ nhanh để không làm chậm suy luận.
Các tầng lưu trữ KV cache và sự đánh đổi
KV cache có thể được lưu ở nhiều tầng khác nhau, mỗi tầng là một sự đánh đổi giữa tốc độ, dung lượng và chi phí. Hiểu rõ các tầng này giúp doanh nghiệp biết mình đang ở đâu và cần đầu tư thêm ở tầng nào.
| Tầng lưu trữ | Tốc độ truy cập | Dung lượng | Chi phí | Phù hợp khi nào |
|---|---|---|---|---|
| GPU HBM | Nhanh nhất | Nhỏ nhất, vài chục đến vài trăm GB mỗi GPU | Đắt nhất trên mỗi GB | Ngữ cảnh ngắn, phiên đang hoạt động, yêu cầu độ trễ thấp nhất |
| CPU RAM | Nhanh, chậm hơn HBM nhiều lần | Lớn hơn HBM, hàng trăm GB đến vài TB mỗi máy chủ | Trung bình | Mở rộng ngữ cảnh vượt HBM, phiên tạm nghỉ có thể quay lại |
| SSD / NVMe cục bộ | Chậm hơn RAM rõ rệt | Lớn, hàng TB đến hàng chục TB | Thấp | Lưu cache phiên dài, tái sử dụng prefix giữa các phiên |
| Lưu trữ mạng (network storage) | Phụ thuộc mạng, nhưng có thể rất nhanh với Ethernet tốc độ cao | Rất lớn, mở rộng gần như không giới hạn | Thấp trên mỗi GB, chia sẻ được giữa nhiều máy chủ | Chia sẻ KV cache giữa nhiều GPU và máy chủ, mở rộng không gián đoạn |
Nguyên tắc vận hành chung là: dữ liệu càng “nóng” — tức càng có khả năng được dùng lại ngay — thì càng nên ở tầng nhanh; dữ liệu càng “nguội” thì càng có thể đẩy xuống tầng chậm hơn, rẻ hơn. KV cache của phiên đang trò chuyện dở là dữ liệu nóng, cần ở HBM. KV cache của một phiên đã tạm dừng nhưng người dùng có thể quay lại là dữ liệu ấm, có thể để ở RAM hoặc SSD. KV cache của các đoạn prompt dùng chung — ví dụ system prompt, tài liệu RAG được nhiều người dùng cùng truy vấn — là dữ liệu có thể chia sẻ, và lưu trữ mạng là nơi phù hợp để nhiều máy chủ cùng đọc.
Thách thức kỹ thuật nằm ở chỗ việc di chuyển KV cache giữa các tầng phải đủ nhanh để không làm chậm suy luận. Nếu việc đọc KV cache từ SSD hay từ lưu trữ mạng chậm hơn việc tính lại từ đầu, thì cache trở nên vô nghĩa. Vì vậy giải pháp lưu trữ KV cache không chỉ cần dung lượng lớn mà còn cần băng thông cao và độ trễ thấp — và đó là lý do giải pháp của Supermicro, IBM và NVIDIA kết hợp cả phần cứng lưu trữ all-flash, phần mềm lưu trữ phân tán và mạng Ethernet tốc độ cao trong cùng một kiến trúc.
Prefix caching: tái sử dụng phần chung của ngữ cảnh
Một kỹ thuật liên quan mật thiết với KV cache lưu trữ là prefix caching — lưu cache theo tiền tố chung. Trong thực tế, nhiều yêu cầu khác nhau có chung phần đầu của prompt: cùng một system prompt, cùng một tài liệu RAG, cùng một đoạn code nền. Thay vì tính lại KV state cho phần chung này mỗi lần, hệ thống lưu KV cache của tiền tố đó và tái sử dụng cho mọi yêu cầu có cùng tiền tố. Kỹ thuật này đặc biệt hiệu quả trong các ứng dụng multi-tenant — nhiều người dùng cùng dùng một hệ thống với cùng bối cảnh chung — và là một trong những lý do KV cache cần được lưu bền vững (persistent) thay vì chỉ tồn tại trong bộ nhớ GPU rồi mất đi khi phiên kết thúc.
Chính từ “persistent” trong tên gọi giải pháp — persistent KV cache — đã nói lên điểm khác biệt cốt lõi: KV cache không còn là bộ nhớ đệm tạm thời sống chết cùng phiên suy luận, mà trở thành một lớp dữ liệu bền vững, có thể lưu trữ, chia sẻ và tái sử dụng qua nhiều phiên, nhiều người dùng và nhiều máy chủ. Khi KV cache trở thành dữ liệu bền vững, nó cần một hạ tầng lưu trữ thực sự — và đó là lúc các nhà cung cấp hạ tầng như Supermicro, IBM và NVIDIA bước vào.
Giải pháp KV cache của Supermicro, IBM và NVIDIA gồm những gì?
Giải pháp được ba hãng công bố ngày 5/11/2026 là một kiến trúc tích hợp, trong đó mỗi hãng đóng góp một thành phần trong ngăn xếp hạ tầng suy luận. Supermicro cung cấp máy chủ lưu trữ all-flash Petascale, sử dụng CPU AMD EPYC 9005 Series với tên mã “Turin”. Đây là tầng phần cứng lưu trữ: các ổ flash cho tốc độ đọc ghi cao và độ trễ thấp, đủ nhanh để phục vụ KV cache mà không trở thành nút thắt mới của hệ thống. Việc dùng CPU AMD EPYC thế hệ mới cho máy chủ lưu trữ cũng phản ánh xu hướng dùng CPU mạnh cho các tác vụ lưu trữ và mạng, để giải phóng GPU cho đúng việc của nó là tính toán.
IBM đóng góp phần mềm IBM Storage Scale — nền tảng lưu trữ phân tán cho phép nhiều máy chủ cùng truy cập vào cùng một không gian lưu trữ KV cache. Vai trò của lớp phần mềm này là biến nhiều máy chủ lưu trữ rời rạc thành một hệ thống thống nhất: KV cache có thể được chia sẻ giữa các GPU và máy chủ khác nhau, dung lượng có thể mở rộng thêm mà không làm gián đoạn hệ thống đang chạy, và dữ liệu vẫn sẵn sàng ngay cả khi một thành phần gặp sự cố — tức tính sẵn sàng cao mà ba hãng đề cập trong công bố.
NVIDIA đóng góp hai thành phần: framework suy luận NVIDIA Dynamo và switch NVIDIA Spectrum-X Ethernet. Dynamo là framework suy luận phục vụ LLM, chịu trách nhiệm quản lý KV cache trong quá trình suy luận — quyết định cache nào giữ, cache nào offload, cache nào chia sẻ giữa các yêu cầu. Spectrum-X Ethernet là hạ tầng mạng tốc độ cao kết nối các máy chủ GPU với các máy chủ lưu trữ, đảm bảo việc đọc KV cache từ lưu trữ mạng đủ nhanh để không làm chậm pha decode. Sự kết hợp này cho thấy giải pháp không chỉ là “thêm ổ cứng cho máy chủ AI” mà là một kiến trúc hệ thống, trong đó phần cứng, phần mềm lưu trữ, framework suy luận và mạng được thiết kế để hoạt động cùng nhau.
Giải pháp này phù hợp với ai?
Trước hết, giải pháp này hướng tới các tổ chức tự vận hành hạ tầng suy luận LLM quy mô lớn: nhà cung cấp dịch vụ AI, doanh nghiệp triển khai chatbot và agent nội bộ cho hàng nghìn người dùng, tổ chức chạy RAG trên kho tài liệu lớn với ngữ cảnh dài, và đội ngũ phát triển coding assistant cho quy mô tổ chức. Điểm chung của các đối tượng này là khối lượng suy luận đủ lớn để chi phí GPU trở thành vấn đề, và ngữ cảnh đủ dài để KV cache trở thành nút thắt thực sự.
Theo công bố, giải pháp giảm thời gian tới token đầu tiên cho cửa sổ ngữ cảnh dài so với hệ thống không có KV cache, đồng thời cải thiện hiệu quả sử dụng GPU, thông lượng và khả năng mở rộng. Nói cách khác, cùng một cụm GPU, hệ thống có thể phục vụ nhiều yêu cầu hơn, phản hồi nhanh hơn ở lượt đầu tiên, và mở rộng dung lượng cache khi nhu cầu tăng mà không phải dừng hệ thống. Đây là những lợi ích vận hành trực tiếp: GPU là tài sản đắt đỏ nhất trong hạ tầng AI, nên bất kỳ cải thiện nào về hiệu quả sử dụng GPU cũng quy ra được thành tiền.
Ngược lại, giải pháp này không dành cho mọi doanh nghiệp. Một doanh nghiệp chỉ dùng LLM qua API của nhà cung cấp, hoặc chạy mô hình nhỏ trên một vài GPU với ngữ cảnh ngắn, sẽ không gặp nút thắt KV cache — và cũng không cần đầu tư hạ tầng lưu trữ chuyên biệt. Bài toán KV cache lưu trữ chỉ xuất hiện khi ba điều kiện cùng đúng: ngữ cảnh dài, lượng yêu cầu lớn, và hạ tầng suy luận tự vận hành. Checklist ở phần sau sẽ giúp doanh nghiệp tự xác định mình có thuộc nhóm này hay không.
So sánh KV cache lưu trữ với các cách tối ưu suy luận khác
KV cache lưu trữ không phải là cách duy nhất để tăng tốc suy luận LLM. Dưới đây là các phương pháp tối ưu phổ biến và mối quan hệ của chúng với KV cache — trong thực tế, các phương pháp này thường được kết hợp với nhau chứ không thay thế nhau.
| Phương pháp | Vấn đề giải quyết | Cách hoạt động | Quan hệ với KV cache |
|---|---|---|---|
| KV cache lưu trữ | KV state vượt bộ nhớ GPU, tính lại tốn kém | Lưu KV states đã tính vào bộ nhớ bền vững và tái sử dụng | Chính là phương pháp đang xét |
| Quantization | Mô hình và KV cache quá lớn | Giảm độ chính xác số học của trọng số và KV state, ví dụ từ 16-bit xuống 8-bit hoặc 4-bit | Bổ sung: quantization làm KV cache nhỏ lại, nên cần ít bộ nhớ hơn ở mọi tầng |
| Speculative decoding | Pha decode sinh token tuần tự, chậm | Dùng mô hình nhỏ dự đoán trước nhiều token, mô hình lớn chỉ kiểm chứng | Bổ sung: vẫn cần KV cache, nhưng số bước decode giảm nên tổng thời gian giảm |
| Continuous batching | GPU nhàn rỗi khi chờ các yêu cầu kết thúc khác nhau | Gộp các yêu cầu đang xử lý thành batch linh hoạt, thêm yêu cầu mới ngay khi có chỗ trống | Bổ sung: batching làm tăng tổng KV cache cần giữ cùng lúc, nên càng cần quản lý cache tốt |
| Prefix caching | Tính lại phần prompt chung cho mọi yêu cầu | Lưu và tái sử dụng KV cache của tiền tố chung giữa các yêu cầu | Trùng lặp một phần: prefix caching là một ứng dụng của KV cache lưu trữ |
| Pruning và distillation | Mô hình quá lớn so với nhu cầu | Cắt bỏ phần không cần thiết của mô hình hoặc chưng cất thành mô hình nhỏ hơn | Gián tiếp: mô hình nhỏ hơn sinh KV state nhỏ hơn, giảm áp lực lên cache |
Một điểm đáng lưu ý trong bảng trên là các phương pháp này tương tác với nhau theo cả hai chiều. Continuous batching giúp GPU bận rộn hơn, nhưng cũng làm tăng tổng dung lượng KV cache cần giữ cùng lúc, vì nhiều yêu cầu đang xử lý song song đồng nghĩa với nhiều bộ KV state cùng tồn tại. Quantization giúp KV cache nhỏ lại, nhưng đổi lại có thể làm giảm nhẹ chất lượng đầu ra tùy mức độ nén. Vì vậy, tối ưu suy luận LLM là một bài toán cân bằng hệ thống: không có một kỹ thuật duy nhất nào giải quyết mọi vấn đề, mà cần kết hợp nhiều kỹ thuật theo đúng đặc điểm workload của mình.
Trong bức tranh đó, KV cache lưu trữ đóng vai trò là “hạ tầng nền”: nó không làm mô hình thông minh hơn hay sinh token nhanh hơn theo từng bước, mà nó loại bỏ công việc tính lại lãng phí và giải phóng GPU khỏi nút thắt bộ nhớ. Một hệ thống đã có KV cache lưu trữ tốt vẫn có thể — và thường nên — áp dụng thêm quantization, speculative decoding và continuous batching để tối ưu thêm. Ngược lại, một hệ thống chưa giải quyết được nút thắt KV cache thì các tối ưu khác cũng chỉ phát huy được một phần tác dụng, vì GPU vẫn phải chờ bộ nhớ.
Checklist: doanh nghiệp có cần đầu tư hạ tầng KV cache không?
Trước khi quyết định đầu tư vào hạ tầng KV cache lưu trữ, doanh nghiệp nên trả lời các câu hỏi dưới đây. Nếu phần lớn câu trả lời là “có”, hạ tầng KV cache có khả năng mang lại giá trị rõ rệt; nếu phần lớn là “không”, doanh nghiệp có thể chưa cần đầu tư ở giai đoạn này.
- Ngữ cảnh có dài không? Các phiên làm việc có thường xuyên vượt quá vài chục nghìn token không — ví dụ trò chuyện dài nhiều lượt, tài liệu RAG lớn, codebase lớn trong coding assistant? Nếu ngữ cảnh chỉ vài nghìn token, KV cache vẫn nằm gọn trong GPU và chưa cần offload.
- Có nhiều yêu cầu dùng chung tiền tố không? Nhiều người dùng có cùng system prompt, cùng tài liệu tham khảo hay cùng bối cảnh chung không? Nếu có, prefix caching trên KV cache lưu trữ sẽ tiết kiệm được nhiều phép tính lặp lại.
- Có chạy AI agent đa lượt không? Agent thực hiện nhiều lượt suy luận và gọi công cụ liên tiếp, mỗi lượt lại kéo dài ngữ cảnh? Đây là workload làm KV cache phình to nhanh nhất.
- GPU có đang bị giới hạn bởi bộ nhớ thay vì tính toán không? Hãy đo mức sử dụng bộ nhớ GPU so với mức sử dụng nhân tính toán. Nếu bộ nhớ thường xuyên đầy trong khi nhân tính toán còn nhàn, nút thắt nằm ở bộ nhớ — đúng vấn đề KV cache lưu trữ giải quyết.
- TTFT có đang là vấn đề trải nghiệm không? Người dùng có phàn nàn về thời gian chờ token đầu tiên, đặc biệt với ngữ cảnh dài không? Nếu có, giảm TTFT là lợi ích trực tiếp và đo được.
- Có tự vận hành hạ tầng suy luận không? Doanh nghiệp có cụm GPU riêng hay dùng API của nhà cung cấp? Nếu dùng API, bài toán KV cache thuộc về nhà cung cấp, không phải doanh nghiệp.
- Quy mô có đủ lớn để chi phí hạ tầng được bù đắp không? Hạ tầng lưu trữ all-flash và mạng tốc độ cao là khoản đầu tư đáng kể. Hãy ước tính chi phí GPU tiết kiệm được nhờ hiệu quả sử dụng cao hơn và thông lượng tăng thêm, rồi so sánh với chi phí đầu tư.
- Có yêu cầu về tính sẵn sàng cao và mở rộng không gián đoạn không? Hệ thống có cần chạy liên tục và mở rộng dung lượng khi nhu cầu tăng mà không dừng dịch vụ không? Đây là hai tính năng mà giải pháp Supermicro–IBM–NVIDIA nhấn mạnh.
Một cách tiếp cận thực tế là bắt đầu bằng đo lường, không phải bằng mua sắm. Trước khi đầu tư hạ tầng mới, doanh nghiệp nên đo TTFT theo độ dài ngữ cảnh, đo mức sử dụng bộ nhớ GPU, đo tỷ lệ cache hit của prefix caching nếu đã có, và đo thông lượng yêu cầu trên mỗi GPU. Các số đo này cho biết nút thắt thực sự nằm ở đâu — có thể là KV cache, nhưng cũng có thể là mạng, là hàng đợi yêu cầu, hay là chính mô hình quá lớn so với nhu cầu. Đầu tư đúng nút thắt thì hiệu quả, đầu tư sai nút thắt thì chỉ tốn tiền mà hệ thống vẫn chậm.
Hạn chế và những điều cần lưu ý
Giải pháp của Supermicro, IBM và NVIDIA là một công bố về kiến trúc hạ tầng, không phải một sản phẩm đóng gói duy nhất với bảng giá cụ thể. Bài viết này chỉ nêu các cải thiện theo đúng công bố chung — giảm thời gian tới token đầu tiên cho ngữ cảnh dài và cải thiện hiệu quả sử dụng GPU, thông lượng và khả năng mở rộng — mà không tự thêm bất kỳ con số hiệu năng cụ thể nào, vì các con số đó không có trong nguồn công bố được cung cấp. Doanh nghiệp quan tâm cần tìm hiểu thêm về cấu hình cụ thể, điều kiện đo lường và chi phí triển khai thực tế trước khi ra quyết định.
Một lưu ý kỹ thuật quan trọng là KV cache lưu trữ không làm giảm tổng lượng tính toán của lần đầu tiên một nội dung được xử lý — nó chỉ giúp các lần sau không phải tính lại. Nếu mỗi yêu cầu của doanh nghiệp đều có ngữ cảnh hoàn toàn mới, không trùng lặp với bất kỳ yêu cầu nào trước đó, thì lợi ích của KV cache lưu trữ sẽ rất hạn chế. Lợi ích lớn nhất xuất hiện khi có sự trùng lặp: cùng tiền tố, cùng tài liệu, cùng phiên kéo dài nhiều lượt. Vì vậy, hiệu quả thực tế của giải pháp phụ thuộc rất nhiều vào đặc điểm workload của từng doanh nghiệp.
Cuối cùng, việc offload KV cache ra lưu trữ mạng đặt ra yêu cầu về bảo mật. KV cache chứa toàn bộ nội dung ngữ cảnh — bao gồm cả dữ liệu nhạy cảm trong prompt và tài liệu của người dùng — dưới dạng các trạng thái số học. Nếu KV cache được lưu bền vững và chia sẻ giữa nhiều máy chủ, doanh nghiệp cần đảm bảo nó được bảo vệ tương tự như dữ liệu gốc: mã hóa khi lưu trữ và khi truyền, kiểm soát truy cập chặt chẽ, và có chính sách xóa cache khi phiên kết thúc hoặc khi dữ liệu hết hạn lưu trữ. Đây là điểm mà đội ngũ vận hành cần làm việc cùng đội ngũ bảo mật ngay từ giai đoạn thiết kế, không nên để đến khi hệ thống đã chạy mới bổ sung.
Câu hỏi thường gặp (FAQs)
KV Cache là gì?
KV Cache là bộ nhớ đệm lưu trữ các trạng thái key-value mà mô hình Transformer đã tính ra cho các token đã xử lý, để tái sử dụng thay vì tính lại mỗi khi sinh token mới. Nhờ KV cache, mỗi bước sinh token chỉ cần tính toán cho token mới nhất rồi đọc lại các giá trị đã lưu, thay vì tính lại toàn bộ ngữ cảnh từ đầu. Đây là tối ưu nền tảng mà gần như mọi hệ thống suy luận LLM hiện đại đều sử dụng.
Prefill và decode trong suy luận LLM là gì?
Prefill là pha mô hình xử lý toàn bộ prompt đầu vào, tính ra key-value states cho mọi token và sinh token đầu tiên của câu trả lời; thời gian tới token đầu tiên này gọi là TTFT. Decode là pha mô hình sinh lần lượt từng token tiếp theo, mỗi bước chỉ tính key và value cho một token mới rồi đọc lại KV cache của các token trước đó. Prefill nặng về tính toán song song, còn decode thường bị giới hạn bởi băng thông bộ nhớ khi đọc KV cache.
TTFT là gì và vì sao nó quan trọng?
TTFT là viết tắt của Time To First Token — thời gian từ lúc người dùng gửi yêu cầu đến lúc nhận được token đầu tiên của câu trả lời. TTFT quan trọng vì nó quyết định cảm nhận về tốc độ của người dùng: chatbot có TTFT dài khiến người dùng phải chờ lâu mới thấy chữ đầu tiên hiện ra, dù tổng thời gian sinh toàn bộ câu trả lời có thể không chênh lệch nhiều. Với ngữ cảnh dài, pha prefill tốn nhiều thời gian hơn, nên TTFT càng dài — và đó chính là chỉ số mà giải pháp KV cache lưu trữ của Supermicro, IBM và NVIDIA nhắm tới cải thiện.
Vì sao ngữ cảnh dài làm KV cache phình to?
Dung lượng KV cache tăng tuyến tính theo độ dài ngữ cảnh: mỗi token thêm vào đều sinh thêm một cặp key-value cần lưu trữ. Khi ngữ cảnh dài hàng trăm nghìn token, lượng KV state có thể vượt bộ nhớ GPU và cả bộ nhớ CPU, buộc hệ thống phải offload ra SSD hoặc lưu trữ mạng. Các workflow AI agent đa lượt, coding assistant và RAG ngữ cảnh dài càng làm vấn đề trầm trọng hơn, vì mỗi lượt tương tác lại thêm token vào ngữ cảnh và KV cache cứ thế lớn dần.
Giải pháp KV cache của Supermicro, IBM và NVIDIA gồm những gì?
Giải pháp được công bố ngày 5/11/2026 gồm bốn thành phần chính: máy chủ lưu trữ all-flash Supermicro Petascale dùng CPU AMD EPYC 9005 Series (“Turin”), phần mềm IBM Storage Scale để chia sẻ và mở rộng KV cache giữa nhiều máy chủ, framework suy luận NVIDIA Dynamo để quản lý KV cache trong quá trình suy luận, và switch NVIDIA Spectrum-X Ethernet để kết nối GPU với lưu trữ ở tốc độ cao. Theo công bố, giải pháp giảm thời gian tới token đầu tiên cho cửa sổ ngữ cảnh dài so với hệ thống không có KV cache, đồng thời cải thiện hiệu quả sử dụng GPU, thông lượng và khả năng mở rộng, với tính sẵn sàng cao và khả năng mở rộng dung lượng không gián đoạn.
KV cache lưu trữ khác gì so với quantization và speculative decoding?
KV cache lưu trữ giải quyết vấn đề tính lại KV state lãng phí bằng cách lưu và tái sử dụng các giá trị đã tính, trong khi quantization giảm kích thước của mô hình và KV cache bằng cách hạ độ chính xác số học, còn speculative decoding tăng tốc pha decode bằng cách dùng mô hình nhỏ dự đoán trước nhiều token để mô hình lớn kiểm chứng. Ba phương pháp này bổ sung cho nhau chứ không thay thế nhau: một hệ thống có thể vừa lưu KV cache ra bộ nhớ bền vững, vừa dùng quantization để cache nhỏ lại, vừa dùng speculative decoding để sinh token nhanh hơn.
Doanh nghiệp nhỏ có cần đầu tư hạ tầng KV cache không?
Phần lớn doanh nghiệp nhỏ chưa cần đầu tư hạ tầng KV cache chuyên biệt. Bài toán KV cache lưu trữ chỉ thực sự xuất hiện khi ngữ cảnh dài, lượng yêu cầu lớn và doanh nghiệp tự vận hành hạ tầng suy luận LLM của mình. Nếu doanh nghiệp dùng LLM qua API của nhà cung cấp, hoặc chạy mô hình nhỏ với ngữ cảnh ngắn, KV cache vẫn nằm gọn trong GPU và nhà cung cấp đã lo phần tối ưu. Doanh nghiệp nên bắt đầu bằng việc đo TTFT, mức sử dụng bộ nhớ GPU và thông lượng hiện tại để xác định nút thắt thực sự trước khi quyết định đầu tư.
KV cache lưu trữ có rủi ro bảo mật gì?
KV cache chứa toàn bộ nội dung ngữ cảnh dưới dạng trạng thái số học, bao gồm cả dữ liệu nhạy cảm trong prompt và tài liệu của người dùng. Khi KV cache được lưu bền vững và chia sẻ giữa nhiều máy chủ, doanh nghiệp cần bảo vệ nó như dữ liệu gốc: mã hóa khi lưu trữ và khi truyền, kiểm soát truy cập chặt chẽ, và có chính sách xóa cache khi phiên kết thúc hoặc khi dữ liệu hết hạn lưu trữ. Đây là yêu cầu cần được thiết kế ngay từ đầu, cùng với đội ngũ bảo mật, chứ không nên bổ sung sau khi hệ thống đã vận hành.
KV Cache là một trong những khái niệm quan trọng nhất để hiểu vì sao suy luận LLM tốn kém và chậm ở quy mô lớn — và cũng là nơi mà những cải tiến hạ tầng như giải pháp của Supermicro, IBM và NVIDIA tạo ra giá trị thực. Khi ngữ cảnh ngày càng dài và AI agent ngày càng phổ biến, bài toán không còn là “GPU có đủ mạnh không” mà là “bộ nhớ có đủ nhanh và đủ lớn để nuôi GPU không”. Doanh nghiệp nào hiểu rõ nút thắt này và đo lường đúng trước khi đầu tư sẽ triển khai AI hiệu quả hơn nhiều so với doanh nghiệp chỉ chạy theo việc mua thêm GPU.
Nếu doanh nghiệp của bạn đang vận hành chatbot, AI agent hay hệ thống RAG với ngữ cảnh dài và muốn tư vấn giải pháp hạ tầng AI phù hợp với quy mô và loại workload của mình, hãy liên hệ AIA qua hotline 0939 936 168 để được tư vấn giải pháp AI.
