Prompt caching: giảm chi phí LLM 10x, đo trên 393 model API

Agent RAG của bạn lên production, traffic tăng gấp ba, hoá đơn API tăng gấp ba theo. Bạn đi cắt context, đổi sang model rẻ hơn, nén lại system prompt — chất lượng câu trả lời tụt, còn chi phí thì không giảm đúng như kỳ vọng.

Hầu hết bảng giá LLM có một dòng thứ ba mà gần như không ai đưa vào spreadsheet so sánh: giá cho cached input. Bài này chỉ ra cách bật nó, ba cái bẫy làm nó im lặng trả về 0, và cách bạn tự xác minh trên stack của mình trong vài phút.

Phần lớn hoá đơn của bạn là token lặp lại

Một tác giả trên Dev.to đã đo chi phí thực tế của prompt caching và công bố toàn bộ số liệu. Bài viết bóc tách một prompt RAG hỗ trợ khách hàng điển hình — theo tác giả là số đo thật, không phải ước lượng:

Thành phần prompt	Token	Tỷ lệ	Tính chất
System prompt	96	32%	giống nhau ở mọi request
Retrieved context	143	48%	thường ổn định trong một session
Conversation history	55	18%	phần đầu ổn định
User message	6	2%	phần duy nhất thực sự mới

Kết luận của bài đo: 98% prompt đó là nội dung lặp lại đang bị tính giá đầy đủ. Với workload agent và RAG, đây là nơi tiền của bạn thực sự nằm — không phải ở chỗ prompt dài hay ngắn.

Anthropic chỉ cache khi bạn yêu cầu

Đây là phát hiện đáng chú ý nhất. Tác giả gửi cùng một system prompt ~2.600 token tới Claude Sonnet hai lần, cách nhau mười phút, qua một API gateway. Không cấu hình cache:

cold: input=2253 cached=0 cost=$0.00470600
warm: input=2251 cached=0 cost=$0.00464200

Theo bài viết: "Nothing cached. Full price both times. No error, no warning, no hint that a 90% discount was available." Không có tín hiệu nào trong response cho bạn biết bạn đang trả giá đầy đủ.

Vẫn prompt đó, thêm marker cache_control vào system message (ví dụ minh hoạ, không phải code production):

"messages": [
  {"role": "system", "content": [
     {"type": "text", "text": PREFIX,
      "cache_control": {"type": "ephemeral"}}]},
  {"role": "user", "content": question}
]

cold: input=2628 cached=0    written=2614 cost=$0.00676300
warm: input=2626 cached=2614 written=0    cost=$0.00068680

Tác giả kết luận request thứ hai trở đi rẻ hơn 90%. Nhưng để ý con số cold: $0.00676 so với $0.00464 khi không cache — đắt hơn khoảng 46%. Đó là cache write premium. Bạn có lãi từ request thứ hai; nếu prompt chỉ gửi đúng một lần, cache làm bạn lỗ.

OpenAI cache mặc định, nhưng có ngưỡng

Cùng phép thử với GPT-4o-mini, không cấu hình gì:

cold: input=1355 cached=0    cost=$0.00021525  1737ms
warm: input=1355 cached=1280 cost=$0.00011145  1223ms

1.280 trong 1.355 input token được phục vụ từ cache — bài viết ghi nhận rẻ hơn 48% và nhanh hơn 30%, không đổi một dòng code. Nếu team bạn giả định caching là tự động ở mọi provider, phần traffic Anthropic có thể đang tốn nhiều hơn cần thiết mà không có tín hiệu nào báo cho bạn.

Ba cái bẫy đưa cache hit về 0

Cache match theo prefix, và match chính xác. Tác giả đổi đúng một ký tự ở đầu prompt: cached từ 1280 về 0, mọi token phía sau bị xử lý lại ở giá đầy đủ. Hệ quả trực tiếp cho cách bạn dựng prompt:

• Timestamp, user ID, session ID ở đầu system prompt — bài viết nói rõ những thứ này vô hiệu hoá cache ở mọi request. Nguyên tắc: nội dung ổn định lên đầu, nội dung động xuống cuối.
• Prefix quá ngắn — theo bài, OpenAI bỏ qua caching dưới 1.024 token (2.048 với model cũ hơn). Dưới ngưỡng, bạn trả giá đầy đủ và không nhận được lỗi nào; cached_tokens chỉ trả về 0. Chính tác giả gần như publish số liệu tiết kiệm cho một prompt 317 token không thể cache được.
• TTL ngắn — cache entry hết hạn sau khoảng năm phút không hoạt động (Anthropic có cửa sổ một giờ dạng trả phí). Bẫy tinh vi: bài viết nói Anthropic tính tuổi cache từ lúc bắt đầu request, và thời gian generate cũng bị trừ vào đó. Một response stream bốn phút chỉ còn để lại khoảng một phút cho request tiếp theo kịp hit.

Một yếu tố nữa ngoài tầm kiểm soát: theo bài, cached state của OpenAI nằm trên từng máy cụ thể, và trên khoảng 15 request/phút, overflow routing có thể đẩy request sang máy không có entry khớp — tham số prompt_cache_key tồn tại để cải thiện việc này. Hit rate vì vậy một phần là thuộc tính hạ tầng, không chỉ của prompt.

Cache support là tiêu chí chọn model, không chỉ là config

Tác giả kéo giá toàn bộ 393 model trên platform đang dùng: 248 model (63%) có giá cache, 145 không. Mức giảm thấp nhất 1,0x, trung vị đúng 10x, cao nhất 120,8x.

Hai hàm ý: khoảng một phần ba model không hỗ trợ caching, nên đây phải là tiêu chí chọn model ngay từ đầu; và các entry 1,0x — theo bài là model open-weight nhỏ như Granite 8B hay gpt-oss-20b — không phải bẫy, chỉ là nơi caching vô nghĩa về kinh tế vì input đã gần như miễn phí.

So với các đòn giảm chi phí khác

Tác giả đo ba đòn trên cùng một workload:

Đòn	Tác động	Giá phải trả về chất lượng
Đổi sang model rẻ hơn	tới 26x	thay đổi câu trả lời
Cache một prefix ổn định	39–90%	không
Cắt retrieved context	60%	~10%, thay đổi câu trả lời

Đánh giá của người viết bài: caching là đòn duy nhất không phải trả giá về chất lượng — cùng token đó, giá thấp hơn. Đó là lý do nên xử lý caching trước khi tối ưu prompt hay hạ cấp model: hai đòn kia đánh vào output, đòn này không.

Kiểm tra stack của bạn tuần này

Thứ tự việc nên làm, theo đúng những gì các số đo chỉ ra:

1. Gọi API hai lần với cùng prefix, cách nhau vài giây, đọc cached_tokens trong usage. Trả về 0 nghĩa là bạn chưa cache gì.
2. Đếm token phần prefix ổn định. Dưới 1.024 token thì đừng kỳ vọng gì ở OpenAI — hãy gộp thêm nội dung ổn định lên đầu.
3. Grep prompt template để tìm timestamp, user ID, session ID nằm trước nội dung tĩnh. Đẩy hết xuống cuối.
4. Với Anthropic, thêm cache_control vào system message và chấp nhận request đầu đắt hơn.
5. Kiểm tra model bạn đang dùng có công bố giá cached input hay không.

Cần theo dõi: bài đo ghi rõ đây là số liệu ngày 25/08/2026 chạy qua một gateway duy nhất, giá lĩnh vực này thay đổi theo tuần, và các con số toàn catalog là giá công bố chứ không phải traffic thật — chỉ hai phép thử cold/warm là đo trực tiếp. Bedrock và Vertex có implementation caching riêng, chưa được đo. Nếu production của bạn chạy trên hai nền tảng đó, hãy tự đo trước khi tin bất kỳ con số nào ở trên.