Bỏ qua điều hướng

Prompt caching: Ngừng trả quá nhiều tiền cho AI

Prompt caching giúp giảm tới 90% chi phí xử lý và 85% độ trễ cho các hệ thống LLM làm việc với ngữ cảnh (context) lớn, nhờ tái dùng phần prompt tĩnh.

Tuan Tran Van
8 phút đọc
Mục lục (7 phần)
  1. Prompt caching là gì?
  2. Prompt caching hoạt động như thế nào?
  3. Vì sao prompt caching giúp bạn tiết kiệm chi phí?
  4. Khi nào prompt caching phát huy tác dụng?
  5. Những lỗi khiến bạn không nhận được cache hit
  6. Nên bắt đầu tiết kiệm từ đâu?
  7. Tài liệu tham khảo

Prompt caching là kỹ thuật lưu trữ các phần tĩnh của một prompt — như hướng dẫn hệ thống (system instructions), tài liệu tham khảo hoặc các ví dụ mẫu — để mô hình không phải xử lý lại chúng từ đầu trong các yêu cầu (request) tiếp theo. Bằng cách tái sử dụng trạng thái tính toán của các tiền tố (prefix), kỹ thuật này giúp bạn giảm chi phí vận hành lên đến 90% và cắt giảm độ trễ phản hồi tới 85%.

Trong hạ tầng AI quy mô lớn, việc tính toán lặp lại cùng một ngữ cảnh (context) dài là nguyên nhân chính gây lãng phí tài nguyên. Prompt caching giải quyết vấn đề này bằng cách cho phép mô hình "nhảy" thẳng đến phần nội dung mới, thay vì phải đọc lại toàn bộ dữ liệu tĩnh từ đầu mỗi khi bạn gửi một tin nhắn mới trong cùng một phiên làm việc.

Minh hoạ prompt caching tái dùng phần ngữ cảnh tĩnh đã được xử lý để tiết kiệm chi phí gọi AI

Prompt caching là gì?

Theo tài liệu kỹ thuật từ Anthropic và IBM, prompt caching là phương thức tối ưu cho phép LLM tiếp tục xử lý từ các tiền tố (prefix) cụ thể đã được lưu trong bộ nhớ đệm. Thay vì mã hóa và tính toán lại toàn bộ dữ liệu đầu vào cho mỗi request, mô hình sẽ truy xuất trạng thái ngữ cảnh đã được xử lý trước đó.

Khác với caching truyền thống (deterministic) — vốn trả về cùng một kết quả cố định cho một đầu vào cố định — prompt caching trong LLM lưu trữ trạng thái ngữ cảnh (context state). Điều này có nghĩa là mô hình vẫn tạo ra các phản hồi linh hoạt dựa trên phần biến đổi của prompt, nhưng trên một nền tảng kiến thức tĩnh đã được "tiêu hóa" sẵn. Đặc điểm này đặc biệt quan trọng với các hệ thống RAG (Retrieval-Augmented Generation) hoặc các tác vụ xử lý tài liệu dài.

Prompt caching hoạt động như thế nào?

Quy trình xử lý prompt của mô hình bao gồm ba bước: Tokenization (mã hóa), Vectorization (véc-tơ hóa) và Compute Attention. Trong đó, Compute Attention là bước tốn kém nhất do độ phức tạp O(n²) khi tính tích vô hướng (dot product) giữa mọi token trong prefix. Prompt caching giúp tái sử dụng kết quả của bước này.

Sơ đồ ba bước xử lý prompt — Tokenization, Vectorization, Compute Attention — và vị trí cache lưu lại kết quả của phần tiền tố (prefix) tĩnh

Anthropic hiện hỗ trợ hai cơ chế triển khai:

  1. Automatic caching: Hệ thống tự đặt điểm ngắt cache ở khối nội dung hợp lệ cuối cùng. Cơ chế này dịch chuyển điểm ngắt theo sự phát triển của hội thoại, lý tưởng cho chat nhiều lượt.
  2. Explicit cache breakpoints: Kỹ sư chủ động đánh dấu các khối tĩnh bằng tham số cache_control. Lưu ý: khối chứa cache_control phải là khối cuối cùng của phần tiền tố tĩnh để đảm bảo hiệu quả.

Cấu hình minh họa:

json
{
  "role": "user",
  "content": [
    {
      "type": "text",
      "text": "Đây là tài liệu hướng dẫn kỹ thuật dài 50 trang...",
      "cache_control": { "type": "ephemeral" }
    },
    {
      "type": "text",
      "text": "Dựa vào tài liệu trên, hãy phân tích lỗi hệ thống sau: [Lỗi]"
    }
  ]
}

Vì sao prompt caching giúp bạn tiết kiệm chi phí?

Việc tối ưu ngân sách dựa trên ba thành phần giá (theo cấu trúc của Anthropic):

  • Cache writes: phí ghi nội dung vào cache, thường bằng 1,25 lần giá base input.
  • Cache hits: phí đọc từ cache, chỉ bằng 0,1 lần (10%) giá base input.
  • Base input tokens: giá cơ bản cho phần nội dung chưa được cache (nằm sau điểm ngắt).

Biểu đồ so sánh ba mức giá của prompt caching — ghi cache 1,25×, đọc cache 0,1×, và input thường — cho thấy mức tiết kiệm tới 90% khi cache hit

Dữ liệu thực tế cho thấy hiệu quả kinh tế rõ rệt:

  • Chat với sách (100k token): chi phí giảm 90%, TTFT giảm từ 11,5 giây xuống 2,4 giây.
  • Hội thoại nhiều lượt (10 lượt chat): chi phí giảm trung bình 53%.
  • TTL (Time-to-Live): mặc định cache tồn tại 5 phút và tự làm mới mỗi khi có cache hit. Bạn có thể chọn TTL 1 giờ để phục vụ các tác vụ thưa thớt hơn, với phí ghi cache bằng 2 lần giá base input.

Khi nào prompt caching phát huy tác dụng?

Dưới góc độ kiến trúc hệ thống và quản lý trạng thái, prompt caching phát huy tối đa giá trị trong các kịch bản giảm tải cho việc quản lý KV-cache:

  1. Trợ lý lập trình (coding assistants): giữ toàn bộ codebase hoặc định nghĩa API trong ngữ cảnh để duy trì tính nhất quán khi sinh code.
  2. Xử lý tài liệu lớn: phân tích báo cáo tài chính, hồ sơ pháp lý dài. Người dùng có thể đặt hàng chục câu hỏi xoay quanh một tài liệu mà không phải trả tiền xử lý lại tài liệu đó.
  3. Many-shot prompting: dùng hàng chục ví dụ (shot) chất lượng cao để định hướng mô hình, thay vì chỉ 1–2 ví dụ như thông thường.
  4. Agentic search & tool use: các tác vụ lặp lại với bộ công cụ (tool) cố định. Cache định nghĩa tool giúp giảm đáng kể độ trễ cho mỗi bước suy luận của agent. Notion đã áp dụng cách này để tăng tốc độ phản hồi cho người dùng cuối.

Bốn tình huống prompt caching phát huy giá trị nhất — trợ lý lập trình, xử lý tài liệu lớn, many-shot prompting và agentic search / tool use

Những lỗi khiến bạn không nhận được cache hit

Đây là những "cái bẫy" kiến trúc mà ngay cả kỹ sư nhiều kinh nghiệm cũng dễ mắc:

  • Vi phạm thứ tự vô hiệu hóa (hierarchy of invalidation): cache tuân theo thứ tự Tools → System → Messages. Nếu bạn thay đổi bất kỳ thứ gì ở tầng Tools (tên, mô tả, tham số), toàn bộ cache của SystemMessages phía sau sẽ bị hủy hoàn toàn.
  • Bẫy lookback window (20 block): hệ thống chỉ dò các lần ghi cache trước đó trong phạm vi 20 block gần nhất. Nếu hội thoại kéo dài và điểm ngắt mới cách điểm ghi cache cũ hơn 20 block, hệ thống sẽ gây cache miss dù nội dung phía trước không đổi. Giải pháp là đặt thêm các điểm ngắt trung gian.
  • Tính bất ổn của prefix: cache hoạt động dựa trên hash của toàn bộ nội dung tính từ đầu đến điểm ngắt. Chỉ cần chèn một timestamp hoặc đổi thứ tự tool ở đầu prompt, hash sẽ đổi và gây cache miss toàn phần.
  • Ngưỡng token tối thiểu: mỗi model có ngưỡng kích hoạt cache khác nhau. Cụ thể, Claude Haiku 4.5 yêu cầu 4.096 token, trong khi Haiku 3.5 là 2.048 token và Sonnet 5 là 1.024 token. Prompt ngắn hơn ngưỡng này sẽ không được cache.
  • Thay đổi tham số vận hành: đổi model hoặc đổi reasoning level (ở các model hỗ trợ suy luận sâu) sẽ làm hỏng tính nhất quán của cache.

Nên bắt đầu tiết kiệm từ đâu?

Lộ trình tối ưu nên đi từ dễ đến khó. Bắt đầu bằng automatic caching cho các luồng chat nhiều lượt — đây là phần dễ tối ưu nhất vì hệ thống tự quản lý điểm ngắt khi lịch sử hội thoại dài lên. Với hệ thống phức tạp hơn, hãy đặt explicit breakpoint thủ công ngay sau system prompt và định nghĩa tool, và chắc chắn điểm ngắt nằm ở khối cuối cùng của phần tĩnh. Nếu ứng dụng nhạy cảm về độ trễ, dùng kỹ thuật pre-warming: gửi một request với max_tokens: 0 để "làm nóng" cache trước khi người dùng gửi request thật.

Quan trọng nhất là đừng tối ưu trong mù mờ. Hãy theo dõi hai trường trong API response: cache_creation_input_tokens cho biết bạn đang đầu tư bao nhiêu vào việc ghi cache, còn cache_read_input_tokens cho biết bạn thực sự tiết kiệm được bao nhiêu. Nếu trường read liên tục bằng 0, cấu trúc prompt của bạn đang có vấn đề — và bạn vẫn đang trả nguyên giá cho từng request.

Tài liệu tham khảo

Đọc tiếp

Chia sẻ bài viết

X / TwitterFacebookLinkedIn