Hướng dẫn chi phí Prompt Caching: Cache Hits, Prefixes và chi phí API thực tế

Chi phí prompt caching phụ thuộc vào ba biến số: phần prompt của bạn là prefix có thể tái sử dụng nhiều đến mức nào, tần suất prefix đó lặp lại trong cửa sổ hoạt động của cache, và cách một nhà cung cấp định giá việc ghi vào cache so với cache hits. Nếu xác định đúng ba con số này, caching có thể giảm đáng kể hóa đơn token đầu vào cho các tác vụ lặp đi lặp lại; nếu sai, bạn có thể phải trả phí ghi cao cho một bộ nhớ cache không bao giờ được tái sử dụng.

Hướng dẫn này phân tách những gì các nhà cung cấp tài liệu hóa, những gì bạn có thể xác minh trên các giao diện API công khai và những gì bạn nên kiểm thử trước khi cam kết chi tiêu sản xuất cho một chiến lược caching.

Những điểm chính cần lưu ý

• Chi phí prompt caching có hai thành phần: chi phí ghi (thường bị tính phí khi một mục cache mới được tạo) và chi phí hit (thường bị tính phí khi một yêu cầu tái sử dụng mục đó). Tài liệu của Anthropic mô tả rõ ràng sự khác biệt giữa ghi và hit này; bạn nên xác nhận các hệ số nhân hiện tại trên trang tài liệu trước khi lập mô hình chi phí.
• Cache hits yêu cầu một prefix khớp chính xác hoặc gần như chính xác cho đến một điểm ngắt (breakpoint) được xác định. Việc sắp xếp lại các hướng dẫn hệ thống, định nghĩa công cụ hoặc các ví dụ few-shot trước điểm ngắt đó sẽ làm mất hiệu lực của cache và buộc phải ghi lại.
• Các mục cache sẽ hết hạn sau một thời gian tồn tại (time-to-live) do nhà cung cấp xác định. Nếu lưu lượng yêu cầu của bạn cho một prefix nhất định quá thưa thớt để nằm trong cửa sổ đó, bạn sẽ phải trả phí ghi lặp đi lặp lại thay vì tích lũy tiết kiệm từ hit.
• Tài liệu của OpenRouter lưu ý rằng hành vi và giá cả của prompt caching thay đổi tùy theo nhà cung cấp và model cơ sở, vì vậy một chiến lược caching giúp tiết kiệm tiền trên backend này không tự động chuyển sang backend khác. Hãy kiểm tra hỗ trợ cho từng model trước khi định tuyến lưu lượng dựa trên mức tiết kiệm giả định.

Prompt Caching thực sự tính phí bạn những gì

Prompt caching cho phép nhà cung cấp API lưu trữ đại diện đã xử lý của một prefix prompt để các yêu cầu tiếp theo chia sẻ prefix đó có thể bỏ qua các tính toán dư thừa. Mô hình thanh toán theo sau đó không phải là "token được cache là miễn phí". Nó giống với việc "token được cache rẻ hơn khi tái sử dụng, nhưng lần ghi đầu tiên tốn kém hơn một token đầu vào tiêu chuẩn".

Tài liệu về prompt caching của Anthropic trình bày cấu trúc này một cách trực tiếp: một yêu cầu tạo mục cache mới được tính phí khác với một yêu cầu hit vào mục hiện có. Các hệ số nhân chính xác thay đổi theo thời gian và theo model, vì vậy hãy coi bất kỳ con số nào bạn thấy trong một bài đăng blog, bao gồm cả bài này, là thứ cần xác minh so với tài liệu hiện tại thay vì một hằng số cố định.

Hệ quả thực tế là prompt caching là một khoản đặt cược vào việc tái sử dụng. Nếu system prompt, lược đồ công cụ hoặc khối ngữ cảnh được truy xuất của bạn được gửi một lần và không bao giờ lặp lại, caching sẽ thêm một khoản phí ghi mà không có khoản tiết kiệm hit bù đắp. Nếu cùng khối đó được gửi hàng trăm lần trong cửa sổ hoạt động của cache, khoản tiết kiệm từ hit có thể vượt xa chi phí ghi.

Cách Cache Hits hoạt động: Prefixes, Prefixes và Breakpoints

Cache hits dựa trên prefix, không phải dựa trên nội dung theo nghĩa mơ hồ. Phần được cache của một prompt phải khớp với yêu cầu đến từng token cho đến điểm mà ranh giới cache, đôi khi được gọi là breakpoint, được thiết lập. Tài liệu của Anthropic mô tả đây là một cơ chế rõ ràng, nơi các nhà phát triển đánh dấu phần nào của prompt đủ điều kiện để cache, thường là các hướng dẫn hệ thống ổn định, định nghĩa công cụ và các tài liệu tham khảo dài không thay đổi giữa các lần gọi.

Điều này dẫn đến một hệ quả kỹ thuật trực tiếp: bất cứ thứ gì bạn đặt trước breakpoint cache phải giống hệt nhau về byte giữa các yêu cầu, bao gồm cả khoảng trắng và thứ tự. Một sai lầm phổ biến là chèn các biến theo yêu cầu (như dấu thời gian hoặc ID người dùng) vào system prompt trước ranh giới cache. Biến đơn lẻ đó sẽ làm hỏng cache cho toàn bộ prefix, và bạn phải trả phí ghi trên mỗi lần gọi thay vì tích lũy hit.

Cách khắc phục rất đơn giản: giữ nội dung thực sự tĩnh (định nghĩa công cụ, hướng dẫn phong cách, tài liệu tham khảo lớn) trong prefix được cache, và đẩy bất kỳ thứ gì cụ thể theo yêu cầu vào suffix không được cache, thường là tin nhắn của người dùng.

Thời gian tồn tại của cache quan trọng không kém thiết kế prefix. Tài liệu của Anthropic mô tả thời gian cache mặc định được tính bằng phút, với tùy chọn thời gian dài hơn cho các khối lượng công việc cần thiết. Nếu mô hình lưu lượng của bạn gửi một prefix chia sẻ vài phút một lần, một cache tồn tại ngắn hạn có thể hết hạn trước khi yêu cầu tiếp theo đến, và bạn sẽ phải trả phí ghi lặp đi lặp lại. Các khối lượng công việc tần suất cao (phiên trò chuyện, vòng lặp tác nhân, đường ống xử lý hàng loạt chạy liên tiếp) là những ứng viên tốt hơn nhiều so với các cuộc gọi thưa thớt, không thường xuyên.

Lập mô hình chi phí API thực tế: Phương pháp tiếp cận

Thay vì khẳng định một tỷ lệ tiết kiệm, hãy lập mô hình khối lượng công việc của riêng bạn với hình dạng sau. Ví dụ này minh họa cấu trúc yêu cầu về mặt khái niệm; hãy kiểm tra tên trường chính xác và giá hiện tại trên tài liệu của nhà cung cấp trước khi bạn triển khai nó.

{
  "model": "claude-sonnet-5",
  "system": [
    {
      "type": "text",
      "text": "You are a support agent. Full policy document follows...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "What is the refund window for order 48213?" }
  ]
}

Dấu hiệu cache_control trên khối hệ thống báo hiệu rằng nội dung này là một ứng viên caching. Lần gọi đầu tiên trong một phiên sẽ trả phí ghi cho khối đó. Mọi lần gọi tiếp theo trong cửa sổ hoạt động của cache tái sử dụng cùng một prefix sẽ trả phí hit thay vì tỷ lệ đầu vào đầy đủ cho các token đó.

Để ước tính liệu việc này có đáng để triển khai cho dịch vụ của bạn hay không, hãy thu thập bốn con số từ nhật ký của riêng bạn:

1. Kích thước prefix: số lượng token của nội dung ổn định mà bạn dự định cache (system prompt, lược đồ công cụ, tài liệu tham khảo).
2. Tần suất gọi trong cửa sổ TTL: bao nhiêu yêu cầu tái sử dụng chính xác prefix đó trong thời gian hoạt động của cache.
3. Tỷ lệ ghi và hit: lấy từ tài liệu hiện tại của nhà cung cấp, không giả định từ trí nhớ.
4. Tính biến đổi của suffix: liệu phần không được cache của prompt có nhỏ so với phần được cache hay không, vì mức tiết kiệm tỷ lệ thuận với lượng prompt tổng nằm sau breakpoint cache.

Nếu prefix của bạn lớn, tần suất gọi trong cửa sổ TTL cao và suffix nhỏ, caching có khả năng giảm chi phí. Nếu bất kỳ điều kiện nào trong ba điều kiện đó yếu, hãy chạy so sánh chi phí song song trước khi triển khai rộng rãi caching. Hướng dẫn của TokenLab về việc cắt giảm chi phí API AI đi qua một loạt các đòn bẩy rộng hơn ngoài caching, bao gồm lựa chọn model và xử lý hàng loạt, tại /blog/cut-ai-api-costs-30-percent.

Bảng quyết định: Khi nào Prompt Caching mang lại hiệu quả

Mô hình khối lượng công việc	Cache có khả năng giúp ích	Ghi chú
System prompt dài hoặc lược đồ công cụ được tái sử dụng qua nhiều cuộc gọi trong một phiên	Có	Trường hợp kinh điển; chi phí ghi được khấu hao qua các hit
Tài liệu truy xuất lớn được tái sử dụng qua một loạt câu hỏi tiếp theo ngắn	Có, nếu các cuộc gọi nằm trong TTL	Xác nhận TTL so với tài liệu hiện tại trước khi giả định cửa sổ tái sử dụng
Prompt dùng một lần không có lưu lượng lặp lại	Không	Phí ghi cao mà không có hit để bù đắp
Prompt có tính biến đổi cao nơi phần "ổn định" liên tục thay đổi	Không	Bất kỳ thay đổi nào trước breakpoint đều làm mất hiệu lực của cache
Vòng lặp tác nhân với các định nghĩa công cụ lặp lại qua nhiều lượt	Có	Lược đồ công cụ là ứng viên caching hàng đầu
Công việc hàng loạt tần suất thấp cách nhau ngoài TTL cache	Không	Cache hết hạn trước khi tái sử dụng; trả phí ghi mỗi lần
Định tuyến đa nhà cung cấp nơi chỉ một số backend hỗ trợ caching	Xác minh theo model	Đừng giả định hỗ trợ caching chuyển đổi giữa các nhà cung cấp

Sử dụng bảng này như một danh sách kiểm tra ban đầu, không phải là câu trả lời cuối cùng. Xác nhận TTL, giá ghi/hit và cơ chế breakpoint so với tài liệu của nhà cung cấp cho model cụ thể mà bạn dự định sử dụng, vì các chi tiết này thay đổi và khác nhau theo dòng model.

Sự khác biệt giữa các nhà cung cấp bạn nên xác minh trước khi cam kết

Prompt caching không được triển khai giống hệt nhau ở mọi nơi, và điều đó quan trọng nếu bạn định tuyến lưu lượng qua nhiều nhà cung cấp hoặc model. Tài liệu của OpenRouter về các phương pháp hay nhất cho prompt caching lưu ý rằng hỗ trợ và hành vi caching khác nhau tùy theo nhà cung cấp cơ sở, nghĩa là một chiến lược được điều chỉnh cho cơ chế cache của một model không tự động áp dụng khi bạn chuyển đổi model hoặc định tuyến qua một backend khác.

Nếu kiến trúc của bạn sử dụng định tuyến model để kiểm soát chi phí (ví dụ: gửi các tác vụ phân loại thông thường đến một model chi phí thấp hơn như DeepSeek V4 Flash, GLM-5.2 hoặc Gemini 3.5 Flash trong khi dành Claude Sonnet 5 hoặc GPT-5.5 cho các tác vụ suy luận khó hơn), bạn cần kiểm tra hỗ trợ caching độc lập cho từng model trong bảng định tuyến đó. Một chiến lược caching được xác nhận so với tài liệu của một model không phải là một giả định an toàn cho model khác. Trang xếp hạng của TokenLab theo dõi các khác biệt ở cấp độ model mà bạn có thể sử dụng làm điểm tham chiếu ban đầu tại /models/rankings, và phân tích điểm chuẩn định tuyến tại /blog/ai-model-routing-benchmark-cost-per-task bao gồm cách các quyết định định tuyến tương tác với chi phí trên mỗi tác vụ, điều này cộng hưởng với các quyết định caching thay vì thay thế chúng.

Hạn chế của phân tích này

Hướng dẫn này mô tả cơ chế chung của prompt caching như được tài liệu hóa bởi Anthropic và được tham chiếu bởi OpenRouter tính đến các ngày quan sát ở trên. Nó không bao gồm các hệ số nhân ghi/hit chính xác, thời gian TTL chính xác hoặc giá cả theo model, vì những con số đó thay đổi và khác nhau theo model. Trước khi bạn xây dựng mô hình chi phí cho lưu lượng sản xuất, hãy lấy các con số hiện tại trực tiếp từ tài liệu của nhà cung cấp được liên kết ở trên thay vì dựa vào bất kỳ con số cố định nào được trích dẫn trong nội dung của bên thứ ba, bao gồm cả bài viết này. Hành vi caching cho các model định hướng suy luận, prompt đa phương thức và cửa sổ ngữ cảnh rất dài cũng có thể khác với mô hình prefix-caching chung được mô tả ở đây; hãy xác minh so với tài liệu cho model cụ thể mà bạn dự định sử dụng.

Câu hỏi thường gặp

Prompt caching có luôn giảm chi phí API không? Không. Nó chỉ giảm chi phí khi một prefix ổn định được tái sử dụng đủ thường xuyên trong cửa sổ hoạt động của cache để bù đắp chi phí ghi. Các prompt thưa thớt hoặc có tính biến đổi cao thường tốn kém hơn khi bật caching so với khi không bật.

Điều gì làm hỏng một cache hit? Bất kỳ thay đổi nào đối với nội dung prompt trước breakpoint cache, bao gồm khoảng trắng, thứ tự token hoặc một biến đơn lẻ được chèn vào một system prompt vốn tĩnh. Việc khớp phải chính xác cho đến breakpoint.

Prompt caching có được triển khai giống nhau trên tất cả các nhà cung cấp không? Không. Anthropic tài liệu hóa một cơ chế cache-control rõ ràng với giá ghi và hit được xác định. Tài liệu của OpenRouter lưu ý rằng hỗ trợ và giá cả caching thay đổi tùy theo nhà cung cấp và model cơ sở, vì vậy bạn nên xác minh hỗ trợ theo từng model thay vì giả định nó chuyển đổi được.

Nếu bạn đang đánh giá xem prompt caching, định tuyến model hoặc kết hợp cả hai có phù hợp với mô hình lưu lượng của bạn hay không, hãy bắt đầu với TokenLab để so sánh các tùy chọn model và cấu trúc chi phí trước khi bạn cam kết chi tiêu sản xuất.