Tìm hiểu sâu về chi phí token của LLM: Cơ chế hoạt động của bộ nhớ đệm lời nhắc

Deep Dive vào Chi phí Token của LLM — Loạt bài viết Phần 2: Cách bộ nhớ đệm lời nhắc (Prompt Caching) thực sự hoạt động Đăng ngày 6/6/2026 bởi Weidong Zhou 0 Bài viết đầu tiên trong loạt bài này, Phần 1: Nghiên cứu điển hình thực tế, kết thúc bằng một con số duy nhất: một phiên Claude Code kéo dài 31 giờ với chi phí 172,58 USD, trong đó 114,98 USD — khoảng 66% hóa đơn — là chi phí đọc từ bộ nhớ đệm. Bộ nhớ đệm không phải là một tác dụng phụ của phiên đó. Nó là khoản chi phí chiếm ưu thế, với khối lượng lớn đến mức vượt trội hơn tất cả các khoản khác cộng lại. Bất kỳ ai cố gắng lý giải chi phí LLM mà không có mô hình tư duy chính xác về cách bộ nhớ đệm hoạt động đều bỏ lỡ phần quan trọng nhất. Bài viết này là mô hình tư duy đó. Đây không phải là bài viết về chiến lược — đó là bài viết tiếp theo. Đây là bài viết về cơ chế hoạt động của bộ nhớ đệm nói riêng: cách khớp tiền tố (prefix match) thực sự diễn ra trên đường truyền, điều gì xảy ra với tin nhắn thứ hai của một cuộc hội thoại so với tin nhắn đầu tiên, điều gì xảy ra khi bạn rời đi hai ngày, và điều gì thực sự xảy ra với một tệp 800 token duy nhất mà bạn đọc vào phiên ở lượt thứ 5. Một lưu ý về phạm vi. Claude được sử dụng làm ví dụ minh họa xuyên suốt vì bề mặt bộ nhớ đệm của nó là rõ ràng nhất — mỗi lần đọc, ghi và TTL đều có một bộ đếm tương ứng trong khối sử dụng, do đó cơ chế có thể được theo dõi từng dòng. Khi GPT hoặc Gemini khác biệt theo những cách làm thay đổi câu trả lời thực tế, bạn sẽ tìm thấy một chú thích ngắn gọn về sự khác biệt giữa các nhà cung cấp. Bài viết thứ ba trong loạt bài này sẽ đi sâu hơn nhiều vào câu chuyện giữa các nhà cung cấp; ở đây mục tiêu là làm cho cơ chế của Claude trở nên vững chắc trước tiên. Nội dung bài viết này: Phần 1 — Ba câu hỏi tiết lộ cách bộ nhớ đệm thực sự hoạt động. Mọi tin nhắn trò chuyện có sử dụng bộ nhớ đệm không? Toàn bộ cửa sổ ngữ cảnh (context window) có thực sự được gửi trong mỗi lượt không? Điều gì xảy ra khi bạn tiếp tục một phiên sau hai ngày? Các câu trả lời ngắn gọn cho thấy sự bất đối xứng chi phối hầu hết mọi quyết định về chi phí của Claude. Phần 2 — Một ví dụ minh họa. Theo dõi một tệp 800 token duy nhất trong toàn bộ vòng đời của nó trong một phiên 20 lượt: đến dưới dạng đầu vào mới, ghi vào bộ nhớ đệm bị trễ một lượt, sau đó đọc từ bộ nhớ đệm trong phần còn lại của phiên. Ba sơ đồ làm cho cơ chế trở nên hữu hình. Một khi bạn có thể theo dõi 800 token, bạn có thể theo dõi bất cứ điều gì. Loạt bài viết. Đây là bài viết thứ hai trong ba bài: Phần 1: Nghiên cứu điển hình thực tế (trước) — mô hình tư duy, dựa trên một nghiên cứu điển hình thực tế trị giá 172 USD. Phần 2: Cách bộ nhớ đệm lời nhắc thực sự hoạt động (bài viết này) — ba câu hỏi và một ví dụ minh họa. Phần 3: Chiến lược và các mẫu chống (tiếp theo) — năm chiến lược được xếp hạng theo tác động, những thất bại thầm lặng làm mất đi chúng, và so sánh giữa các nhà cung cấp. Mỗi bài viết đều có giá trị riêng. Nhưng nếu bạn đến đây mà chưa đọc bài viết đầu tiên, nghiên cứu điển hình trị giá 172 USD là bằng chứng dựa trên dữ liệu về lý do tại sao bài viết này quan trọng: đọc từ bộ nhớ đệm chiếm hai phần ba hóa đơn đó, và việc hiểu sai mô hình tư duy về bộ nhớ đệm có nghĩa là tối ưu hóa sai dòng chi phí trong suốt thời gian bạn sử dụng Claude. Phần 1: Ba câu hỏi tiết lộ cách bộ nhớ đệm thực sự hoạt động Ba câu hỏi gần như ngay lập tức xuất hiện khi ai đó lần đầu tiên cố gắng lý giải về bộ nhớ đệm lời nhắc: Khi tôi gửi một tin nhắn trò chuyện, bộ nhớ đệm có thực sự được sử dụng không? Nếu cửa sổ ngữ cảnh của tôi là 53,6K token, liệu toàn bộ tải trọng có thực sự được gửi trong mỗi lượt không? Điều gì xảy ra nếu tôi tạm dừng và tiếp tục phiên sau hai ngày? Các câu hỏi nghe có vẻ đơn giản. Các câu trả lời cho thấy chính xác cách trạng thái không lưu (statelessness), tiền tố bộ nhớ đệm và TTL 5 phút tương tác — và chúng giải thích tại sao một số mẫu sử dụng lại rẻ và một số khác lại đắt một cách đáng ngạc nhiên. Câu hỏi 1 — Khi tôi gửi tin nhắn trò chuyện, Claude có thực sự sử dụng bộ nhớ đệm không? Có — gần như chắc chắn, và rất tích cực. Đây là những gì đang xảy ra với mỗi tin nhắn bạn gửi trong một công cụ như Claude Code. Mỗi khi bạn gửi tin nhắn, máy khách thực hiện một lệnh gọi API mới để gửi lại toàn bộ cuộc trò chuyện cho đến thời điểm đó. Dữ liệu gửi đi có cấu trúc đại khái như sau: [ Lời nhắc hệ thống + định nghĩa công cụ ] ← lớn, tĩnh, có thể lưu vào bộ nhớ đệm [ Lượt 1: tin nhắn của bạn + phản hồi của trợ lý ] [ Lượt 2: tin nhắn của bạn + phản hồi của trợ lý ] ... [ Lượt N: tin nhắn mới nhất của bạn ] ← chỉ có các byte thực sự mới Máy khách đặt các điểm ngắt cache_control để đánh dấu tiền tố tĩnh là có thể lưu vào bộ nhớ đệm. Với mỗi tin nhắn mới bạn gửi: Lời nhắc hệ thống + định nghĩa công cụ → đọc bộ nhớ đệm với tốc độ ~0,1x. (Chỉ riêng khối này thường là 10K–20K token.) Tất cả các lượt trò chuyện trước đó → cũng đọc bộ nhớ đệm với tốc độ ~0,1x, miễn là không có gì trước đó được chỉnh sửa. Tin nhắn mới nhất của bạn → đầu vào mới với tốc độ 1x. Phản hồi của trợ lý → đầu ra với tốc độ 5x, sau đó trở thành một phần của tiền tố được lưu vào bộ nhớ đệm trong lượt tiếp theo của bạn. Vì vậy, có, bộ nhớ đệm đang hoạt động hết công suất cho bạn trong bất kỳ cuộc trò chuyện qua lại nào. Cấu trúc kinh tế của cuộc trò chuyện bị chi phối bởi phần đuôi mới nhỏ ở cuối mỗi lượt, chứ không phải tiền tố lặp lại lớn. Điểm cần lưu ý trong 5 phút. Các mục trong bộ nhớ đệm tồn tại trong 5 phút kể từ lần đọc cuối cùng. Nếu bạn rời đi lâu hơn khoảng thời gian đó giữa các tin nhắn, mục đó sẽ hết hạn. Tin nhắn tiếp theo của bạn sẽ không đọc từ bộ nhớ đệm nữa — nó phải trả tiền để ghi lại bộ nhớ đệm từ đầu. Chúng ta sẽ quay lại vấn đề này trong Câu hỏi 3, vì đây là nơi ẩn chứa những chi phí lớn nhất. Lưu ý giữa các nhà cung cấp. Mẫu "mỗi tin nhắn đều sử dụng bộ nhớ đệm" tương tự cũng áp dụng cho GPT (tra cứu bộ nhớ đệm tự động cho các lời nhắc trên ~1K token) và trên Gemini (chỉ khi bạn đã tạo rõ ràng một đối tượng CachedContent và tiền tố vượt quá mức tối thiểu ~32K). Trên GPT, nó dễ dàng và vô hình; trên Gemini, nó yêu cầu thiết lập có chủ ý. Sự bất đối xứng: các cuộc trò chuyện Claude hoặc GPT ngắn được hưởng lợi từ việc lưu vào bộ nhớ đệm tự động khi ngữ cảnh của bạn tăng lên; các cuộc trò chuyện Gemini ngắn không thể sử dụng tính năng này. Câu hỏi 2 — Nếu cửa sổ ngữ cảnh của tôi là 53,6K token, Claude có thực sự gửi tất cả 53,6K đó trở lại API trong mỗi lượt không? Có — mọi byte của 53,6K token đó đều được truyền qua mạng trong mỗi lượt. Claude là không trạng thái: không có bộ nhớ phía máy chủ về cuộc trò chuyện của bạn. Toàn bộ dữ liệu được gửi đi mỗi lần. Nhưng "được gửi đi" và "được tính phí đầy đủ" là những điều rất khác nhau. Đây là những gì thực sự xảy ra với 53,6K đó.