Prompt caching Claude có thể phản tác dụng nếu đặt breakpoint sai
Prompt caching Claude chỉ có lợi khi cùng một prefix được đọc lại đủ sớm và không thay đổi. Với giá chuẩn, cache 5 phút hòa vốn sau một cache hit; cache một giờ cần hai hit. Nếu breakpoint bao gồm timestamp, request ID hoặc nội dung thay đổi, mỗi request có thể tạo một lần ghi mới với giá cao hơn input thông thường.
Để tính đúng hóa đơn, cần tách token ghi cache, token đọc cache, input không cache và output. Sau đó đối chiếu khoảng cách giữa request, tỷ lệ hit thực tế và vị trí breakpoint; prefix dài tự nó không bảo đảm tiết kiệm.
Công thức tính toàn bộ chi phí
Gọi P là số token của prefix có thể cache; B là giá input cơ bản trên một triệu token; w và r lần lượt là hệ số ghi và đọc; W là số lần ghi; H là số cache hit. Gọi U là tổng input không được cache, O là tổng output và Bout là giá output. Khi đó: chi phí = [P × B × (wW + rH) + U × B + O × Bout] / 1.000.000.
Tài liệu prompt caching của Anthropic quy định lần ghi TTL 5 phút có hệ số 1,25, lần ghi TTL một giờ có hệ số 2 và cache hit có hệ số 0,1 so với giá input cơ bản. Tài liệu cũng xác nhận TTL được làm mới khi cache được sử dụng; thời gian sống được tính từ lúc request bắt đầu, nên thời gian sinh response nằm trong cửa sổ này.
Để so sánh, chi phí không cache là [(P × N + U) × B + O × Bout] / 1.000.000, với N là tổng số request. Output và phần input động không được giảm giá, vì vậy mức tiết kiệm trên toàn hóa đơn thường thấp hơn mức giảm riêng của prefix.
Ngưỡng hòa vốn phụ thuộc số lần đọc
Giả sử prefix được ghi một lần và h request sau đều hit. Cache rẻ hơn xử lý input thông thường khi w + hr < 1 + h, tương đương h > (w − 1) / (1 − r). Với r = 0,1, TTL 5 phút cần ít nhất một hit; TTL một giờ cần ít nhất hai hit.
Kết quả này chỉ đúng khi các request sau thực sự đọc entry ban đầu. Nếu N request có cùng độ dài prefix nhưng mỗi request lặp lại chỉ hit với xác suất q, chi phí kỳ vọng của prefix, tính theo đơn vị giá input cơ bản, là w + (N − 1)[qr + (1 − q)w]. So sánh biểu thức này với N để thấy tỷ lệ hit thấp có thể xóa toàn bộ lợi ích.
Ví dụ, với 10 request, hệ số đọc 0,1 và các lần miss đều tạo entry mới, TTL 5 phút cần tỷ lệ hit kỳ vọng lớn hơn khoảng 24,2%; TTL một giờ cần hơn khoảng 58,5%. Đây là phép tính điều kiện từ các hệ số giá, không phải tỷ lệ bảo đảm cho một ứng dụng cụ thể.
Ba workload cho thấy TTL thay đổi hóa đơn
Workload 1 — hai request liên tiếp: giả sử Claude Sonnet 4.6 nhận prefix 20.000 token, mỗi request có thêm 2.000 input động và tạo 1.000 output. Với giá input 3 USD, ghi 5 phút 3,75 USD, cache read 0,30 USD và output 15 USD trên một triệu token, tổng phí có cache là 0,123 USD; không cache là 0,162 USD. Một hit đã bù được phần ghi cao hơn.
Workload 2 — bốn request cách nhau 15 phút: giả sử mỗi request dùng prefix 50.000 token, thêm 2.000 input động và tạo 1.000 output. TTL 5 phút hết hạn trước mỗi request, khiến bốn lần ghi đưa tổng phí lên 0,834 USD, cao hơn 0,684 USD khi không cache. TTL một giờ cho một lần ghi và ba lần đọc, đưa tổng xuống 0,429 USD.
Workload 3 — timestamp nằm trước breakpoint: giả sử prefix 100.000 token được gửi 10 lần. Nếu timestamp thay đổi làm cả 10 request ghi lại cache 5 phút, riêng prefix tốn 3,75 USD, so với 3 USD khi không cache. Nếu chuyển timestamp ra sau breakpoint, một lần ghi cộng chín lần đọc chỉ tốn 0,645 USD cho prefix.
Quy tắc chọn TTL vì thế khá hẹp: dùng 5 phút khi các lần tái sử dụng thường cách nhau dưới 5 phút; cân nhắc một giờ khi khoảng nghỉ dài hơn 5 phút nhưng prefix vẫn có ít nhất hai lần đọc trước khi hết hạn. Nếu khoảng nghỉ thường vượt một giờ hoặc khả năng tái sử dụng thấp, phí ghi có thể không được thu hồi.
Breakpoint phải kết thúc phần prefix ổn định
Claude xử lý prefix theo thứ tự tools, system rồi messages. Thay đổi tool, chỉ dẫn hệ thống hoặc nội dung khác trước breakpoint có thể làm mất entry tương ứng và các phần cache phía sau. Timestamp, dữ liệu riêng của request, câu hỏi hiện tại và ngữ cảnh RAG thay đổi theo truy vấn nên thường phải nằm sau breakpoint mà ứng dụng muốn tái sử dụng.
Breakpoint đặt trên một block động không giúp hệ thống tự nhận ra phần ổn định đứng trước nó. Cache chỉ được ghi tại các điểm đã đánh dấu; cơ chế nhìn lùi chỉ có thể tìm entry từng được ghi trong request trước. Với các lớp thay đổi ở tần suất khác nhau, có thể dùng breakpoint riêng cho chỉ dẫn ổn định và cho tài liệu hoặc lịch sử hội thoại được tái sử dụng.
Một đánh giá trên hơn 500 phiên agent cho thấy kiểm soát ranh giới cache và loại kết quả tool động khỏi phần tái sử dụng tạo lợi ích nhất quán hơn cache toàn bộ ngữ cảnh. Nghiên cứu ghi nhận mức giảm chi phí 41–80% trong các cấu hình được thử, nhưng đó là kết quả benchmark trên ba nhà cung cấp, không phải cam kết cho mọi workload Claude.
Xác nhận cache hit bằng response usage
Không nên suy luận cache hit chỉ từ độ trễ. Ví dụ đối soát của Respan kiểm tra trực tiếp ba trường trong response usage: cache_creation_input_tokens cho token vừa ghi, cache_read_input_tokens cho token đọc lại và input_tokens cho phần input không được đọc hoặc ghi vào cache.
- Ở request đầu tiên, cache_creation_input_tokens phải lớn hơn 0 nếu prefix đủ điều kiện; cache_read_input_tokens thường bằng 0.
- Ở request tiếp theo với cùng prefix và TTL còn hiệu lực, cache_read_input_tokens phải lớn hơn 0. Một hội thoại tăng dần có thể vừa đọc phần cũ vừa ghi phần mới.
- Nếu cache_creation_input_tokens lớn ở hầu hết request nhưng cache_read_input_tokens gần 0, hãy so sánh payload theo thứ tự để tìm timestamp, khoảng trắng, thứ tự tool hoặc block động đã lọt vào prefix.
- Nếu cả hai trường đều bằng 0, kiểm tra độ dài tối thiểu áp dụng cho mô hình và nền tảng, vị trí cache_control và loại block được đánh dấu.
- Tính tỷ lệ hit riêng cho từng breakpoint và nhóm request có khoảng cách tương tự; một tỷ lệ chung cho toàn ứng dụng có thể che giấu workload đang ghi lại cache liên tục.
Chỉ đổi TTL sau khi usage xác nhận prefix thực sự hit. TTL dài không sửa được breakpoint sai: nó có thể làm lần ghi ngoài ý muốn tăng từ 1,25 lên 2 lần giá input cơ bản.
Đọc thêm:
Đăng ký bản tin
Nhận tin Web3, AI và tiền mã hóa mới nhất ngay trong hộp thư.