Prompt caching là cơ chế lưu phần prompt lặp lại để các request LLM sau dùng lại, giảm token đầu vào phải xử lý và có thể giảm giá đọc cache Claude tới 90%. Bài này giúp bạn nhận biết phần ngữ cảnh nào nên giữ cố định, đọc số liệu usage và ước tính mức giảm chi phí thay vì chỉ nhìn tổng tiền trên hóa đơn. Với Anthropic, `cache_read_input_tokens` cho biết số token được đọc từ cache; với OpenAI, thông tin tương ứng nằm trong `prompt_tokens_details.cached_tokens`. Đây là các con số cần kiểm tra khi chatbot, RAG hoặc workflow gửi cùng một bộ hướng dẫn nhiều lần.

Tóm tắt nhanh

• Cache phù hợp với phần lặp lại như system prompt, tài liệu tham chiếu và ví dụ few-shot; dữ liệu người dùng thay đổi nên tách riêng.
• Dòng Claude tính token đọc từ cache thấp hơn token đầu vào thông thường tới 90%, nhưng mức thực tế còn tùy model và bảng giá.
• Bạn có thể xem tỷ lệ cache tại ô Token cache trong `/dashboard/usage`, rồi đối chiếu với `cache_read_input_tokens` hoặc `cached_tokens`.

Bạn nên đặt phần ít thay đổi ở đầu prompt: system prompt, tài liệu tham chiếu, ví dụ few-shot và định nghĩa tool. Phần câu hỏi, biến người dùng hoặc dữ liệu truy vấn nên nằm sau phần này. Nếu tiền tố bị thay đổi bởi một ngày cập nhật, mã người dùng hoặc thứ tự nội dung, request đó có thể không đọc được cùng cache. Cache write là lần hệ thống ghi tiền tố đủ điều kiện vào cache; nó không đồng nghĩa toàn bộ request đã được lưu. Cache read là lần request sau tái sử dụng phần đã ghi. Theo dữ liệu brief, token Claude đọc từ cache có thể rẻ hơn token đầu vào thông thường 90%, nhưng mức này phụ thuộc chính sách và cách tính giá của từng nhà cung cấp; OpenAI có trường `prompt_tokens_details.cached_tokens`, còn Anthropic có `cache_read_input_tokens` để nhận diện phần được đọc lại.

Một workflow gửi cùng bộ hướng dẫn cho 1.000 request có thể tránh xử lý lại phần ngữ cảnh lặp, nhưng mức giảm tiền phụ thuộc cache hit và bảng giá từng model. Với Claude, token đọc từ cache có thể rẻ hơn token đầu vào thông thường tới 90%; đây là mức của phần cache read, không phải toàn bộ hóa đơn.

Ghi và đọc lại phần prompt đủ điều kiện Ở request đầu, nhà cung cấp có thể thực hiện cache write: lưu phần prompt đủ điều kiện để dùng cho các request sau. Bạn cần kiểm tra điều kiện ghi, thời gian lưu và giá cache write trong tài liệu

của model; các thông tin này không giống nhau giữa Anthropic và OpenAI. Vì vậy, một request đầu tiên có thể chưa rẻ hơn request thông thường. Các request kế tiếp thực hiện cache read khi phần prompt tương ứng vẫn được nhận diện. Anthropic trả số token này trong `cache_read_input_tokens`, còn OpenAI đặt trong `prompt_tokens_details.cached_tokens`. Hai trường này cho biết bao nhiêu token được đọc lại, không cho biết toàn bộ request đã được cache.

Giữ tiền tố ổn định để giảm chi phí lặp Cache phát huy tác dụng khi tiền tố giống nhau giữa các lần gọi. Chẳng hạn, system prompt dài 4.000 token và bộ ví dụ few-shot nên đứng trước câu hỏi

của khách hàng; chỉ phần câu hỏi, mã đơn hoặc đoạn truy vấn RAG thay đổi ở cuối. Chèn timestamp, mã phiên hoặc nội dung người dùng vào đầu prompt có thể làm phần lặp không còn khớp. Để ước tính tiền, hãy tách ba khoản: token input thông thường, token input đọc từ cache và token output. Nếu 10.000 token đầu vào được gửi lại 20 lần nhưng chỉ 8.000 token mỗi lần được ghi nhận ở trường cache read, bạn chưa thể lấy 10.000 làm mẫu số cho tỷ lệ hit. Dùng số usage thực tế rồi đối chiếu với giá cache read của model. Prompt caching cũng cho bạn một chỉ số để đánh giá thời gian xử lý trong chatbot, RAG hoặc workflow nhiều request. Cache hit cao nhưng phản hồi vẫn chậm có thể cho thấy phần truy vấn động, hàng đợi hoặc thời gian sinh output mới là nút thắt; chưa có cơ sở gán toàn bộ mức cải thiện cho caching.

Một request có thể vẫn tốn nhiều token dù câu hỏi người dùng chỉ thay đổi vài dòng, nếu system prompt và tài liệu tham chiếu bị đặt sai vị trí. Quy trình dưới đây giúp bạn kiểm tra cache bằng dữ liệu usage thật, thay vì suy đoán từ thời gian phản hồi.

Bước 1: Tách phần cố định khỏi dữ liệu động Tách `system prompt`, tài liệu tham chiếu, định nghĩa quy tắc và ví dụ few-shot thành một tiền tố cố định. Đặt câu hỏi, mã đơn hàng hoặc nội dung khách gửi ở phần thay đổi phía sau. Ví dụ chatbot bán hàng có thể giữ nguyên 8.000 token chính sách đổi trả, còn `order_id` và câu hỏi mới

được truyền ở cuối request.

Bước 2: Giữ nguyên tiền tố trong mọi request Trong application code, tạo một biến hoặc template riêng cho phần cố định rồi nối dữ liệu động sau đó. Với workflow n8n, giữ cùng cấu trúc prompt trong node gọi LLM cho một tác vụ; không chèn thời gian hiện tại, mã phiên hoặc câu hỏi người dùng vào giữa `system prompt` và tài liệu. Chỉ một thay đổi nhỏ ở tiền tố cũng có thể khiến request không dùng lại đúng vùng cache.

Bước 3: Lưu usage response Gửi một nhóm request có cùng tiền tố nhưng câu hỏi khác nhau, sau đó lưu `usage`

của từng response cùng model, thời điểm và mã workflow. Nên có request đầu tiên để tạo cache và các request tiếp theo để đọc cache; nếu chỉ kiểm tra một lần, bạn chưa có dữ liệu so sánh cache write với cache read.

Bước 4: Đọc đúng trường token cache Với Anthropic, ghi nhận giá trị `cache_read_input_tokens`. Với OpenAI, đọc `prompt_tokens_details.cached_tokens` trong phần usage. Đồng thời lưu tổng token đầu vào và token đầu ra để tránh nhầm việc có cached token với việc toàn bộ request

được miễn phí. Ô Token cache trong `/dashboard/usage` là nơi đối chiếu thêm tỷ lệ cache

của các request đi qua RevidAPI.

Bước 5: Tính tỷ lệ và đối chiếu billing Tính `tỷ lệ token cache = token đọc từ cache / tổng token đầu vào × 100`. Chẳng hạn một request có 8.000 token đầu vào, trong đó 7.200 token nằm ở `cache_read_input_tokens`, thì tỷ lệ là 90%; đây là tỷ lệ token, không phải mức giảm hóa đơn. Sau đó so sánh billing trước và

sau khi bật caching trên cùng model, số request, độ dài prompt và sản lượng output. Theo brief, dòng Claude có token đọc từ cache có thể rẻ hơn 90% so với token đầu vào thông thường, nhưng mức tiền thực tế còn phụ thuộc bảng giá và cách nhà cung cấp tính cache write.

Một prompt có cache read nhưng vẫn có thể không đáng tiền nếu phần tiền tố thay đổi qua từng request. Chẳng hạn, bạn đặt ngày, mã đơn hàng hoặc câu hỏi khách hàng vào trước system prompt; mỗi lần thay đổi như vậy có thể làm giảm cache hit rate, trong khi phần nội dung cố định không được tái sử dụng như kỳ vọng.

Các trường hợp cần cân nhắc Không phải model và nhà cung cấp nào cũng dùng cùng ngưỡng lưu cache, thời gian sống cache hoặc cách tính giá. Mức giảm tối đa khoảng 90% thường chỉ áp dụng cho token đầu vào

được đọc từ cache theo chính sách riêng; hãng chưa công bố một tỷ lệ chung cho mọi model. Vì vậy, đừng lấy mức 90% để dự toán toàn bộ hóa đơn.

Chatbot chăm sóc khách hàng cho shop online Một shop bán mỹ phẩm có thể giữ cố định bộ chính sách đổi trả, thời gian giao hàng, quy định hoàn tiền và 10–20 câu trả lời mẫu ở phần đầu prompt. Tin nhắn

của khách như “đổi màu son được không?” hoặc “đơn ở Đà Nẵng bao lâu tới?” chỉ nằm ở phần thay đổi. Sau request đầu tiên, các request tiếp theo có thể đọc lại cùng tiền tố thay vì gửi toàn bộ nội dung chính sách để xử lý lại. Cách này phù hợp khi chatbot nhận hàng trăm câu hỏi mỗi ngày nhưng bộ quy định chỉ đổi mỗi tuần. Đội vận hành vẫn phải tạo phiên bản prompt mới sau mỗi lần sửa chính sách; nếu nội dung cũ và mới bị trộn trong cùng cache, bot có thể trả lời sai điều kiện đổi hàng. Khi kiểm tra usage, Anthropic cho biết số token đọc từ cache qua `cache_read_input_tokens`, còn OpenAI thể hiện ở `prompt_tokens_details.cached_tokens`.

Hỏi đáp kho tài liệu nội bộ Một công ty ở Việt Nam có thể đưa quy chế nhân sự, hướng dẫn dùng phần mềm và tài liệu sản phẩm vào phần tham chiếu cố định, rồi cho nhân viên đặt câu hỏi riêng trong từng request. Ví dụ, 80 nhân viên cùng hỏi về ngày nghỉ phép, quy trình duyệt chi phí hoặc điều kiện báo mất thiết bị; phần tài liệu nền giữ nguyên, chỉ câu hỏi và lịch sử ngắn

của từng người thay đổi. Mô hình này chỉ có ý nghĩa khi nhiều phiên thật sự dùng chung một tiền tố đủ ổn định. Với một workload giả định gồm 100 request, mỗi request lặp 100.000 token đầu vào, cách gửi thường dùng 10 triệu token. Nếu lần đầu ghi 100.000 token và 99 lần sau đọc cache với mức giá thấp hơn 90% cho phần token đó, chi phí quy đổi là 1 + 99 × 0,1 = 10,9 đơn vị thay vì 100 đơn vị; output và phần prompt động chưa tính. Đây là phép minh họa, không phải kết quả đo hay báo giá thực tế

của RevidAPI. Hãy đối chiếu ô Token cache trong `/dashboard/usage` trước khi kết luận workload của bạn có giảm chi phí.

Một request LLM qua RevidAPI chỉ cho bạn biết cache có hiệu quả hay không khi bạn đọc cả `usage` trong response và ô Token cache trên Dashboard Usage. Đừng suy ra tỷ lệ trúng cache từ thời gian phản hồi hoặc số token output.

Đọc usage từ request LLM Bạn có thể gọi endpoint tương thích OpenAI bằng `POST https://revidapi.com/v1/chat/completions`. Model và giá token xem tại `GET https://revidapi.com/v1/chat/models`; ví dụ dưới đây dùng `claude-sonnet-5` và header `x-api-key`.

curl https://revidapi.com/v1/chat/completions \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"claude-sonnet-5","messages":[{"role":"user","content":"Xin chào"}]}'

Sau khi nhận JSON, mở object `usage` để tìm thông tin token do model và gateway trả về. Với Anthropic, trường cần đối chiếu là `cache_read_input_tokens`; với OpenAI, tìm `prompt_tokens_details.cached_tokens`. Hai trường này cho biết phần input

được đọc từ cache, nhưng cách tính giá vẫn phải xem theo model trong danh sách giá

của RevidAPI. Claude có thể tính phần cache read rẻ hơn 90% token input thông thường theo dữ liệu brief; hãng hoặc model cụ thể vẫn là nguồn quyết định cuối cùng.

Đối chiếu trên Dashboard Gửi vài request có cùng system prompt hoặc tài liệu cố định, chỉ thay câu hỏi người dùng, rồi kiểm tra ô Token cache tại `/dashboard/usage`. So sánh token cache với tổng input token trong cùng khoảng thời gian; một request đơn lẻ không đủ để kết luận workflow đã hit cache ổn định. Nếu tiền tố thay đổi do chèn timestamp, lịch sử chat hoặc dữ liệu khách hàng lên trước, số đọc cache có thể thấp dù nội dung nhìn gần giống nhau.

Nối vào workflow Bạn có thể dựng luồng kéo-thả tại `/workflow/`, tham khảo mẫu n8n ở `https://revidapi.com/revidapi/workflow/`, hoặc import JSON tại `https://n8n.revidapi.com/`. Trong node LLM, giữ system prompt và phần tài liệu tham chiếu ở vị trí cố định; đưa câu hỏi, mã đơn hàng hoặc dữ liệu mới vào phần sau. Khi cần tự động hóa, chỉ chọn endpoint LLM xuất hiện trong tài liệu hoặc dashboard, rồi lưu lại response `usage` để đối chiếu với Token cache. Không tự thêm path TTS, lipsync, download hay AI Studio vào workflow đo prompt caching.

Prompt caching là gì?

Prompt caching là cơ chế lưu phần prompt lặp lại, chẳng hạn system prompt, tài liệu tham chiếu hoặc ví dụ few-shot, để các request sau không phải xử lý lại toàn bộ tiền tố đó. Bạn vẫn gửi dữ liệu mới, nhưng phần ngữ cảnh ổn định có thể

được đọc từ cache.

Claude có thể rẻ hơn bao nhiêu khi đọc cache? Theo dữ liệu trong brief, token đầu vào

được đọc từ cache trên Claude có thể rẻ hơn tới 90% so với token đầu vào thông thường. Đây là mức tối đa theo chính sách và cách tính giá

của nhà cung cấp, không phải mức tiết kiệm cố định cho toàn bộ request.

Nên cache phần nào

của prompt? Hãy đặt system prompt, tài liệu tham chiếu, ví dụ few-shot và định nghĩa tool ổn định vào phần có thể tái sử dụng. Phần câu hỏi của người dùng, bộ lọc theo phiên hoặc dữ liệu thời điểm hiện tại nên để sau tiền tố ổn định; nếu tiền tố thay đổi ở mỗi request, cache hit có thể không xảy ra.

Cache read có miễn phí toàn bộ request không? Không. Cache read chỉ áp dụng cho số token

được đọc lại; token động, token output và các quy tắc tính phí khác vẫn được tính. Với Anthropic, bạn có thể kiểm tra trường `cache_read_input_tokens`; với OpenAI, xem `prompt_tokens_details.cached_tokens` trong usage response.

Xem tỷ lệ cache hit ở đâu?

Trong RevidAPI Dashboard Usage, mở Token cache để xem lượng token

được nhận diện từ cache. Khi đối chiếu chi phí, hãy ghi lại cả tổng input token, cached token và output token, vì chỉ nhìn một con số cache chưa đủ để kết luận request đã rẻ hơn bao nhiêu.

Khám phá workflow miễn phí tại AI Tạo ảnh & Video và lấy API key tại API Marketplace RevidAPI.

Tích hợp Veo 3.1 Omni với RevidAPI giúp tự động hóa TTS, lipsync và xuất video qua AI Studio. Developer có thể ghép n8n workflow với endpoint thật trên dashboard — phù hợp creator và startup Việt muốn scale sản xuất video AI mà không cần hạ tầng riêng.