Tối ưu hóa suy luận AI: tái sử dụng KV cache với CacheBlend cho RAG và agent

1. Vì sao doanh nghiệp cần tối ưu hóa suy luận AI

Phần lớn doanh nghiệp không tự huấn luyện mô hình nền mà dùng mô hình có sẵn, nên chi phí phát sinh hằng ngày nằm chủ yếu ở suy luận (inference): mỗi câu hỏi của người dùng, mỗi bước của agent đều chiếm thời gian GPU. Khi số người dùng tăng, prompt dài hơn và agent gọi mô hình nhiều lượt hơn, chi phí GPU, điện năng và độ trễ đều tăng theo. Câu hỏi thực tế vì thế chuyển thành: làm sao phục vụ nhiều yêu cầu hơn trên cùng số GPU mà người dùng không phải chờ lâu hơn.

Mỗi lần mô hình ngôn ngữ lớn (LLM) trả lời, quá trình suy luận gồm hai pha. Pha prefill đọc toàn bộ prompt đầu vào và tính ra KV cache, tức các vector key/value của từng token ở từng lớp attention mà mô hình cần để sinh chữ tiếp theo. Pha decode sau đó sinh từng token đầu ra. Thời gian người dùng chờ đến chữ đầu tiên, gọi là TTFT (time to first token), gần như do pha prefill quyết định.

Với chatbot ngắn, prefill không đáng kể. Nhưng ứng dụng RAG (retrieval-augmented generation) thường ghép vào prompt vài đoạn tài liệu truy xuất từ kho nội bộ, còn agent lập trình hay agent gọi công cụ thì đưa lại cùng các file, kết quả công cụ ở mỗi bước. Prompt dễ dài hàng chục nghìn token, và phần lớn nội dung trong đó GPU đã từng xử lý ở các yêu cầu trước.

Vì vậy, tối ưu hóa suy luận AI không chỉ là mua GPU mạnh hơn. Trọng tâm là giảm khối lượng tính toán thừa cho mỗi yêu cầu và khai thác phần cứng hiện có hiệu quả hơn.

2. Các hướng tối ưu hóa suy luận AI phổ biến

Có thể chia các kỹ thuật tối ưu suy luận LLM thành bốn nhóm, tác động ở các tầng khác nhau của hệ thống (Hình 1). Các nhóm này bổ sung cho nhau chứ không loại trừ nhau, và một hệ thống phục vụ trong sản xuất thường kết hợp nhiều nhóm.

• Tầng mô hình: lượng tử hóa trọng số (ví dụ FP8, INT4), dùng mô hình nhỏ hơn hoặc mô hình chưng cất. Cách này giảm bộ nhớ GPU và tăng tốc tính toán, nhưng cần kiểm tra lại chất lượng trên bài toán cụ thể.
• Engine phục vụ: continuous batching, quản lý bộ nhớ KV cache theo trang (PagedAttention trong vLLM), speculative decoding. Nhóm này chủ yếu tăng thông lượng và tốc độ sinh token ở pha decode.
• Quản lý KV cache: prefix caching, đưa KV cache ra DRAM hoặc SSD NVMe, tái sử dụng KV cache theo từng đoạn như CacheBlend. Nhóm này giảm khối lượng prefill, nên giảm TTFT và thời gian GPU khi prompt có nhiều nội dung lặp lại.
• Kiến trúc cụm: tách prefill và decode ra các máy chủ khác nhau, định tuyến yêu cầu tới node đang giữ KV cache phù hợp, chia sẻ KV cache giữa các node để tăng tỷ lệ dùng lại trong toàn cụm.

Vì sao tái sử dụng KV cache có lợi lớn với RAG và agent

Các engine phục vụ phổ biến như vLLM hay SGLang đã có prefix caching: lưu KV cache và dùng lại khi prompt mới bắt đầu bằng đúng chuỗi token đã gặp. Hạn chế nằm ở chữ “bắt đầu”. Prefix caching chỉ tái sử dụng được đến vị trí khác biệt đầu tiên. Trong RAG, bộ truy xuất xếp tài liệu theo điểm liên quan nên cùng một tài liệu có thể đứng thứ nhất ở câu hỏi này nhưng thứ ba ở câu hỏi khác. Chỉ cần thứ tự đổi, phần phía sau bị coi là “mới” và GPU phải prefill lại toàn bộ. Theo Tensormesh, với tải RAG mà họ thử nghiệm, prefix caching vẫn phải tính lại khoảng 90% số token của mỗi yêu cầu.

Ở quy mô hàng trăm agent hoặc hàng nghìn người dùng, lượng tính toán lặp lại này chuyển thành chi phí GPU, điện năng và TTFT cao vào giờ cao điểm. Với loại tải này, tái sử dụng KV cache bất kể vị trí là hướng đáng ưu tiên đánh giá, và CacheBlend là ví dụ tiêu biểu.

3. CacheBlend: tối ưu suy luận LLM bằng tái sử dụng KV cache

CacheBlend được nhóm tác giả từ ĐH Chicago và cộng sự trình bày trong bài báo “CacheBlend: Fast Large Language Model Serving for RAG with Cached Knowledge Fusion” tại hội nghị ACM EuroSys 2025. Theo blog LMCache, bài báo nhận giải Best Paper của hội nghị. Ba đồng tác giả Junchen Jiang, Yihua Cheng và Kuntai Du cũng là những người đồng sáng lập Tensormesh, theo trang giới thiệu của công ty. Ý tưởng chính của CacheBlend có ba phần.

Lưu KV cache theo từng đoạn, dùng lại ở mọi vị trí

Thay vì chỉ lưu theo tiền tố, hệ thống tính và lưu KV cache riêng cho từng đoạn văn bản (chunk), ví dụ từng tài liệu hoặc từng file. Khi một prompt mới chứa lại đoạn đó, ở bất kỳ vị trí nào, KV cache đã lưu được lấy ra ghép vào thay vì tính lại. Hình 2 minh họa sự khác biệt khi cùng ba tài liệu A, B, C xuất hiện lại với thứ tự khác.

Tính lại có chọn lọc để giữ chất lượng

Nếu chỉ ghép thẳng KV cache của các đoạn tính riêng rẽ, câu trả lời sẽ kém đi. Lý do là khi tính riêng, mỗi đoạn không “nhìn thấy” các đoạn đứng trước nó trong prompt mới, tức thiếu cross-attention giữa các đoạn, và thông tin vị trí cũng không khớp. Bài báo CacheBlend cho thấy cách tái sử dụng toàn phần như vậy có chất lượng thấp hơn rõ rệt so với prefill đầy đủ.

CacheBlend xử lý bằng cách chỉ tính lại một tập nhỏ token có KV cache lệch nhiều nhất so với khi prefill đầy đủ, nhóm tác giả gọi là token HKVD (high KV deviation). Việc chọn token diễn ra theo từng lớp: lớp đầu chọn rộng hơn một chút, các lớp sau thu hẹp dần. Mặc định trong bài báo là tính lại khoảng 15% token mỗi lớp; tài liệu LMCache cũng dùng tỷ lệ 0,15 trong ví dụ cấu hình. Theo bài báo, với mô hình Yi-34B, tỷ lệ tính lại từ 5% đến 18% hầu như không làm giảm điểm chất lượng so với tính lại toàn bộ.

Chồng việc tính lại với việc tải KV cache từ tầng lưu trữ

Điểm quan trọng với người làm hạ tầng: KV cache của kho tài liệu có thể rất lớn, không đủ chỗ trong bộ nhớ GPU. CacheBlend tải KV cache theo từng lớp và cho GPU tính lại lớp hiện tại trong khi lớp kế tiếp đang được tải về (Hình 3). Theo bài báo, với Llama-7B và ngữ cảnh 4K token, tính lại 15% mất khoảng 3 ms mỗi lớp, trong khi tải một lớp từ SSD NVMe mất khoảng 16 ms, nên thời gian tính lại gần như bị che hoàn toàn. Nhờ vậy KV cache có thể nằm ở thiết bị chậm hơn nhưng dung lượng lớn hơn GPU, như DRAM máy chủ hay SSD NVMe, mà không làm TTFT tăng thêm. Với mô hình lớn hơn như Llama-70B, bài báo ghi nhận việc tính lại có thể lâu hơn việc tải, khi đó bộ điều khiển sẽ chọn tỷ lệ tính lại và thiết bị lưu trữ phù hợp.

Về phía ứng dụng, Tensormesh cho biết trên nền tảng của họ, prompt vẫn là văn bản thông thường nên không cần sửa ứng dụng, và khi không có nội dung lặp lại thì hiệu năng tương đương prefix caching. Với bản mã nguồn mở, tài liệu LMCache hướng dẫn bật chế độ blending, chèn chuỗi phân cách giữa các đoạn và token hóa từng đoạn riêng trước khi gửi vào vLLM, nên đội phát triển pipeline RAG cần làm thêm một số bước tích hợp.

4. Kết quả theo các nguồn công bố

Có hai nhóm số liệu nên đọc riêng: số liệu học thuật trong bài báo, so với việc prefill lại toàn bộ; và số liệu Tensormesh công bố cho nền tảng thương mại của họ, so với prefix caching trên tải RAG cụ thể.

Hình 4 trực quan hóa hai chỉ số dưới tải mà Tensormesh công bố. Theo giải thích của hãng, chênh lệch đến từ khối lượng tính toán: với prefix caching, khoảng 90% token của mỗi yêu cầu phải tính lại; với CacheBlend, chỉ phần văn bản mới (khoảng 10%) cộng với khoảng 15% token của các tài liệu tái sử dụng cần tính. Tensormesh cũng ghi nhận ở tải nhẹ hai cách cho TTFT tương đương, khoảng một giây; khác biệt chỉ lộ rõ khi tải tăng, lúc TTFT của prefix caching vượt 10 giây trước khi đạt 1 yêu cầu/giây.

Từ số liệu trên, cách đáng tin cậy nhất để biết mức giảm chi phí suy luận AI cho doanh nghiệp mình là đo trên chính tải thực tế: tỷ lệ nội dung lặp lại, độ dài prompt, mô hình và mục tiêu TTFT. Trang chủ Tensormesh giới thiệu công cụ Demonstrator cho phép thử tỷ lệ cache hit trên prompt của chính mình; khi thử, doanh nghiệp nên dùng dữ liệu mẫu không nhạy cảm. Bước tiếp theo là một đợt PoC trên hạ tầng của doanh nghiệp, so sánh có và không có tái sử dụng KV cache.

5. Khi nào hữu ích và giới hạn cần biết

Tình huống phù hợp

• RAG trên kho tài liệu dùng chung: quy trình, chính sách, tài liệu kỹ thuật, hợp đồng mẫu được nhiều người hỏi lặp lại, mỗi lần bộ truy xuất xếp thứ tự khác nhau.
• Agent lập trình: mỗi bước agent đọc lại cùng các file trong codebase.
• Trợ lý AI gọi nhiều công cụ: kết quả công cụ và file đính kèm lặp lại giữa các lượt.

Theo Tensormesh, lợi ích tăng khi tỷ lệ tái sử dụng cao và tài liệu dài; tốc độ decode không đổi so với prefix caching, tức lợi ích tập trung ở pha prefill và TTFT. Vì vậy CacheBlend nên được xem là một mảnh trong chiến lược tối ưu tổng thể, kết hợp với các kỹ thuật ở tầng mô hình và engine phục vụ đã nêu ở mục 2.

Giới hạn theo chính các nguồn

• Không có nội dung lặp lại thì không có lợi ích: hiệu năng khi đó tương đương prefix caching (theo Tensormesh). Ở mức tái sử dụng 20%, TTFT chỉ nhanh hơn khoảng 15%.
• Chất lượng gần như, chứ không phải tuyệt đối, bằng prefill đầy đủ: Tensormesh cho biết chất lượng ngang tính lại toàn bộ trên 4 trong 5 bộ dữ liệu hỏi đáp công khai mà họ thử; bài báo ghi nhận mức chênh nhỏ về điểm F1/Rouge-L. Doanh nghiệp nên tự đánh giá trên bộ câu hỏi của mình trước khi đưa vào sản xuất.
• Phạm vi kiến trúc mô hình: bài báo nêu kỹ thuật hiện áp dụng cho mô hình dạng transformer và đã thử với Mistral-7B, Yi-34B, Llama-70B; các kiến trúc khác như Mamba, Griffin là hướng nghiên cứu tiếp.
• Phạm vi thử nghiệm: bài báo chưa nghiên cứu việc chia sẻ KV cache giữa nhiều node tính toán và chỉ đánh giá một tầng lưu trữ tại một thời điểm.
• Số liệu do hãng và nhóm tác giả tự đo: các giá trị “tới” là trường hợp thuận lợi nhất trong điều kiện thử nghiệm.

6. Hạ tầng cho tối ưu hóa suy luận AI: lưu trữ, mạng, phần mềm

CacheBlend chuyển một phần bài toán từ “thêm GPU” sang “lưu và tải KV cache hiệu quả”. Điều đó đặt ra ba câu hỏi thiết kế cho đội hạ tầng.

KV cache nằm ở đâu? KV cache của một kho tài liệu lớn thường vượt xa bộ nhớ GPU. Bài báo CacheBlend đánh giá với DRAM máy chủ và SSD NVMe cục bộ, và cho thấy nhờ tải theo lớp, tầng chậm hơn vẫn dùng được mà không cộng thêm TTFT trong nhiều cấu hình. Khi mở rộng ra nhiều máy chủ GPU, việc đặt KV cache trên storage NVMe chia sẻ hoặc object storage giúp các node dùng chung bộ đệm, nhưng đây là hướng triển khai cần kiểm chứng thêm, không phải kết quả đã đo trong bài báo. CSC đã phân tích chi tiết các tầng này trong bài Phân tầng lưu trữ KV cache cho suy luận AI; Hình 5 tóm tắt cách chọn tầng.

Mạng và băng thông có đủ không? Cơ chế chồng tải với tính chỉ hiệu quả khi tốc độ tải KV cache theo kịp. Bài báo đo SSD NVMe ở khoảng 4,8 GB/s. Khi KV cache nằm trên storage chia sẻ, băng thông mạng giữa máy chủ GPU và storage, thường ở mức 100–400G cho cụm AI, trở thành yếu tố cần sizing cùng lúc với GPU. Bài Lưu trữ cho AI: chọn object, file hay block storage có thêm góc nhìn về lựa chọn kiểu lưu trữ.

Phần mềm nào cần có? Bản cài đặt của bài báo được xây trên vLLM. Bản mã nguồn mở hiện có trong LMCache, lớp quản lý KV cache tích hợp với vLLM; tài liệu LMCache ghi chú trang hướng dẫn blending đang mô tả chế độ in-process (đã ngừng khuyến nghị) và khuyên chuyển sang chế độ MP, nên đội vận hành cần theo dõi phiên bản tương thích và quy trình nâng cấp. Với môi trường sản xuất cần công cụ vận hành, giám sát và hỗ trợ từ hãng, Tensormesh đưa CacheBlend vào nền tảng thương mại chạy trên vLLM.

Về lựa chọn GPU, lợi ích của CacheBlend không thay thế việc chọn máy chủ phù hợp với mô hình và mức tải; tham khảo cách chọn máy chủ GPU cho suy luận GenAI. Nếu đang cân nhắc giữa đầu tư hạ tầng riêng và thuê GPU cloud, việc giảm thời gian GPU mỗi yêu cầu sẽ thay đổi phép tính tổng chi phí, xem thêm mua máy chủ GPU hay thuê GPU cloud.