4 loại cache trong quy trình triển khai LLM

Khi các ứng dụng LLM ngày càng trở nên phức tạp, chi phí suy luận và độ trễ trở thành những yếu tố đặc biệt quan trọng. Một yêu cầu duy nhất có thể chứa hàng nghìn, thậm chí hàng triệu token bao gồm các chỉ dẫn hệ thống, lịch sử hội thoại, tài liệu được truy xuất, định nghĩa công cụ và dữ liệu đầu vào từ người dùng. Việc xử lý lại cùng một thông tin nhiều lần gây lãng phí cả thời gian lẫn tài nguyên tính toán.

Cơ chế lưu cache giúp tránh được sự lặp lại này. Tuy nhiên, lưu cache LLM không chỉ là một kỹ thuật đơn lẻ; những loại cache khác nhau hoạt động ở những giai đoạn khác nhau trong hệ thống phục vụ và giải quyết các vấn đề riêng biệt. Trong bài viết này, chúng ta sẽ cùng tìm hiểu 4 loại cache chính: KV cache, Prefix cache, Prompt cache và Semantic cache.

4 loại cache chính trong LLM Serving

LLM Serving là quá trình đưa các mô hình ngôn ngữ lớn (Large Language Model) đã được huấn luyện vào hệ thống thực tế để xử lý các yêu cầu suy luận từ người dùng hoặc ứng dụng một cách nhanh chóng, ổn định và tối ưu chi phí. 

1. KV Cache: Ghi nhớ những gì mô hình đã xử lý

Hãy bắt đầu với cache đóng vai trò nền tảng trong mọi quy trình suy luận của các mô hình ngôn ngữ lớn (LLM) tự hồi quy hiện đại: KV cache.

Khi LLM tạo ra phản hồi, nó không tạo ra toàn bộ câu trả lời cùng một lúc. Thay vào đó, nó tạo ra từng token một theo cơ chế tự hồi quy. Ví dụ, nếu mô hình đang tạo câu "Quantum computing is a new approach to computation" (Điện toán lượng tử là một phương pháp tiếp cận mới đối với tính toán), nó có thể tạo ra theo trình tự: "Quantum" → "computing" → "is" → "a" → "new" → "approach" → … và cứ thế tiếp tục.

Tại mỗi bước tạo token, Transformer sử dụng cơ chế chú ý để xác định cách token mới tương tác với các token đã xuất hiện trước đó. Trong quá trình tính toán sự chú ý này, mô hình tạo ra các tensor Key (K) và Value (V) cho những token mà nó đã xử lý. Các tensor này rất hữu ích cho những token tiếp theo, vì các token trong tương lai cần tham chiếu đến ngữ cảnh trước đó.

Nếu không có cơ chế lưu cache, mô hình sẽ phải liên tục tính toán lại từ đầu các biểu diễn K/V liên quan đến những token trước đó. Khi chuỗi văn bản được tạo ra ngày càng dài, công việc lặp lại này trở nên cực kỳ tốn kém tài nguyên và mất nhiều thời gian. Và tất nhiên, chẳng ai muốn nhận phản hồi chậm chạp cả.

KV cache giải quyết vấn đề này bằng cách lưu trữ các tensor K/V đã tính toán trước đó vào bộ nhớ - thường là bộ nhớ GPU - và đây chính là thứ được gọi là KV Cache. Khi cần tạo token tiếp theo, mô hình có thể tái sử dụng các trạng thái K/V đã lưu thay vì phải tính toán lại chúng.

Ý tưởng cốt lõi rất đơn giản: Tính toán trạng thái K/V một lần, lưu trữ chúng và tái sử dụng trong các bước giải mã tiếp theo.

Hãy xem xét một câu lệnh (prompt) có nội dung "I love LLMs." Trong giai đoạn tiền xử lý (prefill) ban đầu, mô hình xử lý câu lệnh này và tạo ra các trạng thái K/V cho những token đó. Các trạng thái này được đưa vào KV cache. Khi mô hình bắt đầu tạo phản hồi, các trạng thái đã lưu có thể được tái sử dụng, đồng thời token mới được tạo ra sẽ đóng góp thêm trạng thái K/V của chính nó.

Đây là một trong những lý do khiến KV cache trở nên cực kỳ quan trọng đối với quá trình suy luận tự hồi quy. Thay vì phải liên tục tái tạo trạng thái chú ý của toàn bộ cuộc hội thoại tại mỗi bước giải mã, hệ thống phục vụ sẽ duy trì trạng thái đó và bổ sung dần dần vào nó.

Tuy nhiên, có một hạn chế quan trọng: KV cache truyền thống thường gắn liền với một chuỗi hoặc một yêu cầu đang hoạt động. Khi yêu cầu đó hoàn tất, trạng thái KV của nó không tự động hữu ích cho một yêu cầu khác trong tương lai không liên quan. Và điều này dẫn chúng ta đến kỹ thuật tiếp theo.

2. Prefix Cache: Tái sử dụng phần đầu của một yêu cầu khác

Trong một yêu cầu LLM đang được xử lý, KV cache giúp mô hình tránh việc tính toán lại các token đã được xử lý trước đó. Tuy nhiên, điều gì sẽ xảy ra khi một yêu cầu hoàn toàn mới gửi đến nhưng lại có phần mở đầu giống hệt một yêu cầu trước đó? Thông thường, mô hình không có lý do gì để tính toán lại phần tiền tố (prefix) chung đó từ đầu - nhưng nếu không có cơ chế prefix caching, đó chính xác là điều sẽ xảy ra.

Đây chính là lúc prefix caching phát huy tác dụng.

Cách thức hoạt động của Prefix Cache

Giả sử một ứng dụng gửi câu lệnh (prompt) sau:

Bạn là trợ lý AI của Acme. Hãy tuân thủ các chính sách công ty này… Sử dụng các công cụ này khi cần thiết… Chính sách hoàn tiền là gì?

Một người dùng thứ hai có thể gửi:

Bạn là trợ lý AI của Acme. Hãy tuân thủ các chính sách công ty này… Sử dụng các công cụ này khi cần thiết… Làm thế nào để tôi hủy gói đăng ký?

Các câu hỏi thì khác nhau, nhưng phần lớn nội dung của câu lệnh lại giống hệt nhau. Câu lệnh hệ thống, các chính sách, hướng dẫn và định nghĩa công cụ đều có thể là những phần dùng chung.

Thay vì phải xử lý lại toàn bộ phần tiền tố này, prefix caching cho phép hệ thống phục vụ tái sử dụng các trạng thái KV đã được tính toán cho phần nội dung chung đó.

3. Prompt Cache: Cho phép nhà cung cấp LLM lưu cache cho prompt

Hãy xem xét một kịch bản hơi khác so với các trường hợp nêu trên. Thay vì tự triển khai mô hình, bạn sử dụng LLM thông qua một nhà cung cấp dịch vụ API. Ứng dụng của bạn có thể liên tục gửi một prompt hệ thống rất lớn, bao gồm tài liệu, hướng dẫn, định nghĩa công cụ, ví dụ và các thông tin ngữ cảnh khác. Mặc dù câu hỏi của người dùng thay đổi theo từng lần, nhưng phần lớn nội dung prompt - có thể lên tới hàng chục nghìn token - vẫn giữ nguyên trong suốt quá trình tương tác.

Việc xử lý đi xử lý lại cùng một nội dung ngữ cảnh như vậy có thể gây lãng phí tài nguyên. Do đó, một số nhà cung cấp LLM cung cấp tính năng Prompt caching, cho phép lưu lại các phần của prompt thường xuyên được sử dụng trên cơ sở hạ tầng của họ. Khi có yêu cầu tiếp theo chứa cùng nội dung có thể lưu vào cache, nhà cung cấp có thể tái sử dụng trạng thái đã xử lý trước đó thay vì coi toàn bộ prompt là dữ liệu đầu vào mới.

Điểm quan trọng cần lưu ý là cache này thường do nhà cung cấp quản lý. Ứng dụng của bạn gửi prompt tuân theo cơ chế lưu trữ của nhà cung cấp, trong khi nhà cung cấp chịu trách nhiệm lưu trữ và tái sử dụng dữ liệu đã được lưu trong cache.

Tùy thuộc vào nhà cung cấp, tính năng Prompt caching có thể giúp giảm cả độ trễ lẫn chi phí xử lý đầu vào. Cơ chế hoạt động cụ thể, thời gian lưu trữ trong cache, yêu cầu tối thiểu về số lượng token và chính sách giá cả đều phụ thuộc vào từng nhà cung cấp; do đó, bạn nên luôn đối chiếu các thông tin chi tiết này với API cụ thể mà mình đang sử dụng.

Đến đây, có thể bạn sẽ thắc mắc: chẳng phải prompt caching về cơ bản cũng giống như prefix caching hay sao?

Xét về mặt khái niệm, quả thực có nhiều điểm tương đồng. Cả hai đều được thiết kế để tận dụng nội dung prompt lặp lại và đều có thể liên quan đến việc tái sử dụng trạng thái mô hình đã được tính toán trước đó. Sự khác biệt chủ yếu nằm ở serving layer và thuật ngữ mà hệ thống sử dụng.

Các công cụ suy luận và cơ sở hạ tầng phục vụ tự host thường sử dụng prefix caching, trong khi những nhà cung cấp LLM thường triển khai prompt caching như một tính năng API. Thay vì coi chúng là hai thuật toán hoàn toàn tách biệt, sẽ chính xác hơn nếu xem chúng là các chiến lược lưu trữ cache có mối liên hệ chặt chẽ, được triển khai ở những lớp khác nhau trong hệ thống LLM.

4. Semantic Cache: Khi bạn hoàn toàn không cần đến LLM

Ba cơ chế lưu trữ cache trước đó chủ yếu tập trung vào việc tái sử dụng kết quả tính toán của mô hình. Semantic cache áp dụng một cách tiếp cận khác. Thay vì đặt câu hỏi liệu ta có thể tránh xử lý lại các token này hay không, nó xem xét liệu câu hỏi này đã từng được giải đáp trước đó hay chưa.

Giả sử người dùng hỏi: "Thủ đô của Pháp là gì?". Yêu cầu được gửi đến LLM và mô hình phản hồi: "Paris". Semantic cache có thể lưu lại tương tác này. Sau đó, một người dùng khác có thể hỏi: "Thành phố nào là thủ đô của Pháp?" Hai câu hỏi này không giống hệt nhau về mặt văn bản, nhưng ý nghĩa của chúng lại cực kỳ tương đồng.

Một hệ thống cache truyền thống dựa trên việc khớp chuỗi ký tự chính xác sẽ coi đây là hai truy vấn khác nhau. Ngược lại, semantic cache chuyển đổi truy vấn thành một embedding (vector biểu diễn ngữ nghĩa của văn bản). Truy vấn mới sau đó có thể được so sánh với các embedding của những truy vấn đã được lưu trong cache thông qua kỹ thuật tìm kiếm độ tương đồng.

Nếu độ tương đồng vượt quá ngưỡng đã thiết lập, hệ thống có thể xác định rằng câu hỏi mới đủ giống với một câu hỏi trước đó. Thay vì phải gọi lại LLM, hệ thống có thể trả về câu trả lời đã được tạo ra trước đó.

Đây là lý do tại sao semantic cache có tiềm năng mang lại hiệu quả tiết kiệm lớn hơn nhiều so với các loại cache khác. Một lần truy xuất thành công từ semantic cache có thể loại bỏ hoàn toàn yêu cầu suy luận từ LLM.

Tất nhiên, điều này đi kèm với một sự đánh đổi quan trọng: Tương đồng không phải lúc nào cũng có nghĩa là tương đương. Ví dụ, "Doanh thu của Apple là bao nhiêu?" và "Doanh thu của Apple trong năm 2025 là bao nhiêu?" là những câu hỏi có liên quan nhưng đòi hỏi các câu trả lời khác nhau. Do đó, semantic cache cần một ngưỡng tương đồng được lựa chọn kỹ lưỡng và thường cần thêm logic kiểm chứng. Một cơ chế cache quá "mạnh tay" có thể trả về câu trả lời liên quan đến chủ đề câu hỏi nhưng lại không chính xác đối với yêu cầu cụ thể đó.

Cách 4 loại cache phối hợp với nhau

Các kỹ thuật này sẽ dễ hiểu hơn nhiều nếu chúng ta coi chúng là các lớp tối ưu hóa khác nhau thay vì 4 loại cache cạnh tranh lẫn nhau. Một quy trình khái quát điển hình bắt đầu bằng việc tra cứu trong semantic cache. Nếu không tìm thấy câu trả lời trước đó đủ tương đồng, yêu cầu sẽ được chuyển đến mô hình; tại đây, các phần tiền tố (prefix) của prompt lặp lại có thể được tái sử dụng thông qua cơ chế lưu trữ tiền tố (prefix caching) hoặc lưu trữ prompt ở cấp độ nhà cung cấp dịch vụ. Trong quá trình suy luận, KV cache sau đó sẽ hỗ trợ giúp việc giải mã tự hồi quy (autoregressive decoding) diễn ra hiệu quả hơn.

Kiến trúc cụ thể sẽ khác nhau tùy theo các công cụ suy luận và nhà cung cấp API, nhưng điểm mấu chốt là nhiều cơ chế lưu cache có thể cùng tồn tại trong một ứng dụng; chúng không nhất thiết phải là các giải pháp thay thế lẫn nhau.