Prompt Caching: Giảm Chi Phí Gọi API Claude

Hoá đơn API Claude tháng đầu làm mình giật mình, không phải vì gọi nhiều, mà vì mỗi lần gọi đều gửi lại nguyên một tài liệu dài làm ngữ cảnh. Bật prompt caching xong, hoá đơn tháng sau giảm hẳn dù số lượt gọi gần như không đổi.

Prompt caching là gì?

Prompt caching là cơ chế lưu tạm phần ngữ cảnh lặp lại giữa các lần gọi API, ví dụ một tài liệu tham chiếu dài hay bộ hướng dẫn hệ thống cố định, để các lần gọi sau không phải xử lý lại từ đầu phần đó. Lưu ý nếu bạn dùng Claude Code thì caching đã được bật sẵn bên trong; bài này dành cho lúc bạn tự gọi API trong ứng dụng của mình.

📌 Chưa chắc nên chọn gì? Đọc trước Học AI: Dùng Claude, ChatGPT, Gemini Đúng Việc — hướng dẫn tổng hợp của Kudomax về học ai.

Cache hoạt động theo kiểu khớp tiền tố: bạn đặt một điểm đánh dấu trong request, toàn bộ nội dung từ đầu request tới điểm đó được lưu lại. Lần gọi sau, nếu phần tiền tố giống hệt từng byte thì được đọc từ cache với giá rẻ; chỉ cần lệch một ký tự ở bất kỳ đâu trong tiền tố là cache trượt và mọi thứ tính giá đầy đủ như thường.

Bật cache tiết kiệm được bao nhiêu?

Hai con số quyết định bài toán: token đọc từ cache rẻ hơn khoảng 90% so với token input thường, còn lượt ghi cache đầu tiên đắt hơn khoảng 25%. Nghĩa là chỉ cần phần đã cache được dùng lại một lần là bạn đã có lời, dùng lại càng nhiều lần lời càng đậm.

Cache mặc định sống 5 phút và được làm mới mỗi lần dùng lại, nên ứng dụng gọi liên tục sẽ giữ cache sống mãi mà chỉ trả phí ghi đúng một lần. Luồng gọi thưa hơn thì có tuỳ chọn cache 1 giờ với phí ghi cao hơn, đáng cân nhắc khi mỗi người dùng quay lại sau vài chục phút.

Đánh dấu cache trong request như thế nào?

Thêm trường cache_control kiểu ephemeral vào khối nội dung muốn cache, mọi thứ từ đầu request tới khối đó sẽ được lưu. Ví dụ tối giản với hướng dẫn hệ thống kèm tài liệu dài:

{
  "model": "claude-sonnet-4-6",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "Bạn là trợ lý trả lời theo tài liệu sau... (tài liệu dài)",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "Điều khoản đổi trả ghi gì?" }
  ]
}

Ba giới hạn cần nhớ. Một, mỗi request đặt tối đa 4 điểm đánh dấu cache. Hai, phần muốn cache phải đạt độ dài tối thiểu tuỳ mô hình, cỡ từ vài trăm tới vài nghìn token; ngắn hơn ngưỡng thì API vẫn chạy bình thường nhưng âm thầm không cache gì cả. Ba, cache gắn với từng mô hình: đổi model là phải ghi cache mới từ đầu.

Muốn biết cache có ăn không, đọc hai trường trong phần usage của response: cache_creation_input_tokens là số token vừa ghi vào cache, cache_read_input_tokens là số token đọc được từ cache. Gọi lặp lại mà trường đọc vẫn bằng 0 thì chắc chắn có thứ gì đó đang phá tiền tố.

Thứ tự nội dung trong request nên xếp ra sao?

Nguyên tắc duy nhất: phần ổn định đứng trước, phần thay đổi đứng sau điểm cache cuối cùng. API ghép request theo thứ tự tools rồi tới system rồi tới messages, nên danh sách công cụ và hướng dẫn hệ thống cố định là ứng viên cache tốt nhất, còn câu hỏi mới của người dùng luôn nằm cuối. Đặt bất kỳ thứ gì biến thiên vào đầu request, như dấu thời gian hiện tại trong system prompt, là toàn bộ cache phía sau vỡ theo ở mọi lần gọi.

Ví dụ thật: workflow gọi lặp lại mỗi ngày thì sao?

Ca dễ thấy lời nhất là các luồng tự động gọi Claude đều đặn với cùng một bộ hướng dẫn. Workflow của mình trong bài nối Claude Code với n8n để tự động hoá content gửi kèm bản mô tả giọng thương hiệu dài gần hai nghìn token ở mọi lượt gọi; đặt một điểm cache ngay sau khối đó là phần này chỉ bị tính giá đầy đủ ở lượt đầu mỗi phiên chạy, các lượt sau trong cùng đợt chỉ trả giá đọc cache.

Chatbot hỏi đáp trên một bộ tài liệu cũng cùng công thức: tài liệu nằm trong system prompt được cache, mỗi câu hỏi mới chỉ tốn thêm vài chục token giá đầy đủ. Càng nhiều người hỏi liên tục, tỷ trọng token giá rẻ càng cao.

Khi nào không cần bật và lỗi nào hay gặp?

Không cần bật khi mỗi lần gọi dùng ngữ cảnh khác hẳn nhau, vì không có phần lặp lại để tận dụng, bạn chỉ tốn thêm 25% phí ghi mà không bao giờ được đọc lại. Ứng dụng gọi quá thưa, cách nhau nhiều giờ, cũng không hợp cache 5 phút; hoặc dùng bản 1 giờ, hoặc chấp nhận giá thường.

• Chèn dữ liệu biến thiên vào tiền tố: dấu thời gian, tên người dùng, ID phiên nằm trước điểm cache làm cache trượt ở mọi lần gọi mà không báo lỗi gì.
• Đổi danh sách tools giữa các lần gọi: tools nằm đầu tiền tố, thêm bớt một công cụ là toàn bộ cache phía sau vỡ.
• Cache phần quá ngắn: dưới ngưỡng tối thiểu của mô hình thì không có gì được lưu, phí ghi cũng không bị tính nhưng bạn tưởng đã tiết kiệm mà thực ra không.
• Không kiểm tra usage: tin rằng cache chạy mà chưa từng nhìn cache_read_input_tokens, tới cuối tháng mới biết hoá đơn không giảm.

Bước tiếp theo cụ thể: mở đoạn code gọi API tốn nhất của bạn, đo xem phần ngữ cảnh nào lặp nguyên vẹn giữa các lần gọi, đặt một điểm cache_control ngay sau phần đó rồi so hai trường usage trước và sau. Nửa giờ làm việc này thường là nửa giờ đáng tiền nhất tháng. Còn nếu bạn đang dựng agent gọi API nhiều lượt liên tiếp, xem thêm Claude Agent SDK để tích hợp cache ngay trong vòng lặp agent.