Bỏ qua để vào nội dung chính
Prompt Caching Trên Anthropic API: Ngưỡng Hoà Vốn Là 22%

Prompt Caching Trên Anthropic API: Ngưỡng Hoà Vốn Là 22%

Bởi Ethan Carter
16 thg 8, 20263 phút đọc

Cache write đắt hơn input thường 1.25-2 lần. Dưới hit rate ~22%, cache 5 phút đang khiến bill của bạn tăng, không giảm. Đây là cách tự đo hit rate thật.

Bạn bật prompt caching trên Anthropic API vì mọi hướng dẫn cắt giảm chi phí đều nói vậy. Nhưng ít ai nhắc: caching có một điểm hoà vốn, và nếu traffic của bạn không đạt tới đó, bill sẽ tăng chứ không giảm.

Cache write không miễn phí — nó có phụ phí

Theo phân tích trên dev.to, trên Anthropic API, caching không chỉ có một mức giá mà có hai, tính theo bội số của giá input token thường (1.0×):

  • Cache write, TTL 5 phút: 1.25× giá input thường.
  • Cache write, TTL 1 giờ: 2.0× giá input thường.
  • Cache read (cache hit): 0.1× giá input thường — tức giảm 90%.

Cơ chế khớp theo prefix chính xác: chỉ cần đổi một byte gần đầu prompt, toàn bộ phần sau bị tính là cache miss.

Ngưỡng hoà vốn: khoảng 22%

Bài viết tính ra điểm hoà vốn theo hit rate h, hệ số ghi W và hệ số đọc R: caching có lợi khi (1-h)·W + h·R thấp hơn giá input thường, tương đương hit rate tối thiểu (W-1)/(W-R). Thay số cụ thể: cache 5 phút hoà vốn ở khoảng 21.7% hit rate; cache 1 giờ — do phí ghi gấp đôi — cần tới khoảng 52.6% mới hoà vốn.

Ví dụ minh hoạ từ bài viết: một support bot chạy claude-sonnet-5 (giá niêm yết 2.00 USD/1 triệu input token), prefix 20K token, 200 request/ngày. Không cache: 8.00 USD/ngày. Hit rate 90%: 1.72 USD/ngày. Nhưng ở hit rate 15% — request quá thưa khiến cache hết hạn trước khi được đọc lại — chi phí là 8.62 USD/ngày, tức đắt hơn cả không cache.

Cách tự đo hit rate thật, đừng ước lượng

Mỗi response từ Anthropic API đều trả về số liệu cache_creation_input_tokens, cache_read_input_tokensinput_tokens. Chạy traffic thật qua các trường này để tính hit rate thay vì đoán. Nếu hit rate ra 0% dù prefix giống hệt nhau ở mọi request, bài viết chỉ ra nguyên nhân thường gặp: một timestamp hoặc UUID chèn vào system prompt, hoặc json.dumps không sort key khiến thứ tự field đổi mỗi lần — phá vỡ prefix match.

Một chi tiết khác cần lưu ý: ngưỡng độ dài tối thiểu để cache được áp dụng khác nhau theo từng model, và không tăng đơn điệu theo thế hệ model mới — theo bài viết: 512 token trên Claude Opus 5, 1024 token trên Opus 4.8 và Sonnet 5, 4096 token trên Opus 4.6 và Haiku 4.5. Một prompt 3K token có thể cache được trên model này nhưng âm thầm không cache trên model khác, không hề báo lỗi.

Việc nên làm ngay

  • Đo hit rate thật của traffic production trước khi kết luận caching đang tiết kiệm hay đang đốt thêm tiền.
  • Nếu traffic thưa hoặc prefix theo từng user (ít khi lặp lại), cân nhắc tắt cache 1 giờ — nó cần hit rate cao hơn hẳn để hoà vốn so với mặc định 5 phút.
  • Kiểm tra prefix có field nào đổi theo từng request (timestamp, UUID, thứ tự key JSON) — đây là nguyên nhân phổ biến khiến cache hit rate về 0 mà không ai nhận ra.

Không spam, hủy đăng ký bất kỳ lúc nào.

Bài viết liên quan