Việc bật prompt caching chẳng giúp tôi tiết kiệm được gì cả—thực tế là hóa đơn OpenAI-API của tôi đã tăng thêm khoảng một phần tư. Thủ phạm là một dòng duy nhất thay đổi theo mỗi yêu cầu: một dấu thời gian (timestamp) được nhúng trong system prompt.

Các nhà cung cấp LLM cho phép các nhà phát triển cache các đoạn prompt để cắt giảm chi phí xử lý token. Một lượt đọc cache (một “hit”) có chi phí chỉ bằng 1/10 mức giá thông thường, trong khi một lượt ghi cache (một “miss”) tốn khoảng 1,25 lần giá bình thường. Nếu việc ghi xảy ra nhưng đoạn được cache không bao giờ được đọc, khoản phí 25% tăng thêm đó sẽ bị lãng phí. Đó chính xác là những gì đã xảy ra khi dấu thời gian khiến prompt không khớp với bất kỳ mục cache hiện có nào.

Tại sao caching có thể phản tác dụng

Prompt caching hoạt động bằng cách khớp chính xác chuỗi byte của phần được cache. Nhà cung cấp sẽ băm (hash) đầu vào; nếu mã hash khớp với một mục đã lưu, hệ thống sẽ tái sử dụng kết quả tính toán trước đó và áp dụng mức giá đọc rẻ. Bất kỳ sự thay đổi nào—thậm chí chỉ một ký tự duy nhất—cũng sẽ làm mất sự trùng khớp và buộc hệ thống phải tính toán lại từ đầu, với mức phí ghi cao hơn.

Trong trường hợp của tôi, system prompt bắt đầu bằng:

Current session started: 2026-07-14T09:41:07Z

Vì dấu thời gian được cập nhật cho mỗi lần gọi API, vài byte đầu tiên của yêu cầu không bao giờ giống hệt nhau. Nhà cung cấp đã coi mỗi lần gọi là một mục cache mới, tính phí premium cho việc ghi và không bao giờ ghi nhận lượt đọc. Kết quả là cache_creation_input_tokens tăng đều đặn trong khi cache_read_input_tokens vẫn ở mức bằng không, một dấu hiệu rõ ràng cho thấy cache chưa bao giờ được hit.

Cách nhận biết cache bị lỗi

Nhật ký sử dụng (usage logs) do API cung cấp có hai bộ đếm chính:

  • cache_creation_input_tokens – các token kích hoạt việc ghi.
  • cache_read_input_tokens – các token được hưởng lợi từ việc đọc.

Khi chỉ số đầu tiên tăng lên và chỉ số sau giữ nguyên, nghĩa là cache không được tái sử dụng. Một cách kiểm tra nhanh là lặp lại chính xác cùng một yêu cầu hai lần; lần gọi thứ hai sẽ cho thấy sự gia tăng đột biến của các token đọc nếu cache đang hoạt động bình thường.

Cách khắc phục vấn đề

Cách khắc phục rất đơn giản: đảm bảo vùng được cache là tĩnh (static) giữa các lần gọi. Hãy tuân theo hai quy tắc sau:

  1. Đặt nội dung bất biến lên đầu. System prompt, định nghĩa công cụ (tool definitions), hoặc bất kỳ hướng dẫn nào không bao giờ thay đổi nên chiếm các byte đầu tiên của yêu cầu.
  2. Thêm nội dung có thể thay đổi vào cuối. Dấu thời gian, văn bản do người dùng tạo, ID yêu cầu, hoặc bất kỳ dữ liệu nào thay đổi theo mỗi lần gọi phải nằm sau đoạn đã được cache.

Nếu chỉ cần một ký tự thay đổi, mã hash sẽ thay đổi và tình trạng cache miss sẽ tiếp diễn. Việc sắp xếp lại prompt để dấu thời gian nằm ở cuối sẽ khôi phục tỷ lệ cache hit và đưa hóa đơn trở lại mức chi phí thấp như mong đợi.

Khi nào caching thực sự có ích

Prompt caching phát huy hiệu quả trong các kịch bản mà cùng một bộ hướng dẫn được tái sử dụng nhiều lần:

  • Agent loops nơi AI liên tục gọi lại một tập hợp các công cụ cố định.
  • Chat sessions tham chiếu đến một tài liệu dài, tĩnh trong khi chỉ có truy vấn mới nhất của người dùng thay đổi.
  • Bulk data extraction nơi cùng một prompt phân tách (parsing prompt) được áp dụng cho nhiều bản ghi.

Đối với các lần gọi đơn lẻ (single-shot calls) bao gồm ngữ cảnh mới mỗi lần—như một câu hỏi duy nhất với phần mở đầu riêng biệt—caching không mang lại lợi ích nào và thậm chí có thể làm tăng chi phí nếu yêu cầu vô tình kích hoạt việc ghi.

Những cạm bẫy tiềm ẩn

Ngay cả khi bản thân prompt là tĩnh, yêu cầu vẫn có thể bị thay đổi ở các bước sau:

  • Proxies hoặc các bộ tổng hợp (aggregators) thực hiện sắp xếp lại hoặc chèn thêm khoảng trắng có thể làm hỏng sự trùng khớp từng byte.
  • Các dịch vụ gateway chèn thêm header xác thực hoặc sửa đổi định dạng JSON có thể vô tình làm thay đổi đoạn được cache.

Việc kiểm tra thông qua gateway bằng cách gửi cùng một yêu cầu hai lần và kiểm tra các bộ đếm đọc sẽ giúp xác minh rằng đường dẫn caching vẫn được giữ nguyên.

Bức tranh chi phí rộng hơn

Khoản phụ phí 25% cho việc ghi không phải là hình phạt cho việc sử dụng caching; nó phản ánh chi phí tính toán bổ sung cần thiết để lưu trữ đoạn đó cho việc tái sử dụng trong tương lai. Khi xảy ra cache hit, chi phí sẽ giảm đáng kể—thường chỉ còn một phần nhỏ so với mức giá thông thường. Chìa khóa là phải để hệ thống thực sự hit được cache. Nếu không, bạn sẽ phải trả phí premium mà không tiết kiệm được gì.

Lập luận ngược lại: caching không hề chết

Một số nhà phát triển lập luận rằng sự phức tạp khi quản lý các phần prompt tĩnh so với động sẽ lớn hơn lợi ích tiết kiệm được. Quan điểm đó đã bỏ qua thực tế là nhiều quy trình vận hành (production pipelines) đã tách biệt cấu hình (tĩnh) khỏi dữ liệu người dùng (động). Bằng cách cấu trúc prompt một cách phù hợp, chính cơ chế caching đã giúp ích cho những nhà phát triển API ban đầu có thể được tận dụng mà không cần thêm nỗ lực nào. Sự đánh đổi ở đây chỉ là một chút kỷ luật trong việc thiết kế prompt, chứ không phải là một lỗi cơ bản của công nghệ.

Những việc cần theo dõi tiếp theo

  • Theo dõi hai bộ đếm cache trong bảng điều khiển sử dụng (usage dashboard) của bạn hàng tuần.
  • Kiểm tra việc xây dựng prompt để xác nhận rằng bất kỳ thành phần biến đổi nào cũng nằm sau khối đã được cache.
  • Chạy thử nghiệm A/B có và không có caching trên một khối lượng công việc đại diện để định lượng mức tiết kiệm thực tế.
  • Xác thực gateway bằng cách so sánh payload yêu cầu thô trước và sau khi qua bất kỳ proxy nào.

Bài học rút ra

Prompt caching có thể cắt giảm mạnh chi phí LLM API, nhưng chỉ khi phân đoạn được cache thực sự giống hệt nhau giữa các lần gọi. Một dấu thời gian ngẫu nhiên hoặc bất kỳ token động nào khác ở đầu prompt sẽ buộc hệ thống phải thực hiện một thao tác ghi tốn kém mỗi lần, làm tăng hóa đơn. Bằng cách đưa các hướng dẫn tĩnh lên đầu và dành phần dữ liệu thay đổi cho phần cuối, bạn sẽ để cache thực hiện đúng vai trò của nó và kiểm soát tốt các chi phí của mình.