Prompt caching là gì? Cách một prompt lặp lại được tái sử dụng

Prompt caching nghĩa là API ghi nhớ phần đầu của yêu cầu và tái sử dụng nó vào lần sau khi bạn gửi cùng phần đầu đó. Bạn vẫn gửi toàn bộ văn bản mỗi lần gọi, nhưng nhà cung cấp có thể bỏ qua công đoạn đọc lại phần lặp lại, và một số nhà cung cấp tính giá phần đó thấp hơn. Nó chỉ hoạt động với phần đầu của yêu cầu, và chỉ khi phần đầu đó giống hệt nhau.

Con bot hỗ trợ cứ đọc lại cùng một trang#

Giả sử bạn vận hành một bot hỗ trợ với 2.000 ticket mỗi ngày. Mỗi yêu cầu bắt đầu bằng cùng 3.000 token: giọng điệu, quy tắc hoàn tiền, chính sách vận chuyển. Sau đó là tin nhắn một dòng của khách hàng, đại loại như "Đơn hàng của tôi đâu?" (Nếu vẫn còn mơ hồ về token, hãy bắt đầu với token là gì.)

Không có caching, nhà cung cấp đọc lại toàn bộ 3.000 token quy tắc cho ticket số 1, ticket số 2, và ticket số 2.000. Cùng một trang, đọc 2.000 lần. Có caching, yêu cầu đầu tiên trả giá đầy đủ để đọc nó, và các yêu cầu sau bắt đầu bằng cùng văn bản có thể tái sử dụng công việc đó.

Hướng dẫn API của DeepSeek (kiểm tra ngày 24 tháng 10 năm 2026) mô tả chính xác điều này: context caching bật mặc định, không cần thay đổi mã, và một yêu cầu sau có tiền tố trùng lặp được tính là "cache hit". Chỉ phần đầu vào được cache. Câu trả lời được tạo mới mỗi lần.

Thế nào là "giống nhau": quy tắc tiền tố#

Cache khớp từ ký tự đầu tiên trở đi. Ngay khi yêu cầu của bạn khác với yêu cầu đã cache, mọi thứ sau điểm đó đều là mới. Đó là lý do thứ tự trong yêu cầu của bạn quan trọng hơn độ dài của nó.

Đây là lỗi âm thầm giết chết caching. Một lập trình viên muốn bot biết thời gian và đặt nó ở đầu:

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

Thời gian thay đổi mỗi giây, nên ngay dòng đầu tiên đã khác ở mỗi yêu cầu, và không gì sau đó có thể khớp. Cách sửa là chuyển mọi thứ thay đổi xuống cuối:

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

Giờ thì 3.000 token quy tắc đứng đầu và giữ nguyên. Logic tương tự áp dụng cho hai trường hợp phổ biến khác: một cuộc trò chuyện dài gửi lại toàn bộ lịch sử mỗi lượt, nên các tin nhắn cũ là phần đầu lặp lại sẵn có (xem thêm trong vì sao một cuộc trò chuyện dài tốn hơn), và một agent lặp lại định nghĩa công cụ và hướng dẫn ở mỗi bước.

Caching cũng chỉ là nỗ lực tốt nhất. DeepSeek cho biết cache mất vài giây để xây dựng, một lần hit cần khớp đầy đủ với một đơn vị tiền tố cache đã có, không có tỷ lệ hit được đảm bảo, và các cache không dùng sẽ bị xóa, thường trong vài giờ đến vài ngày. Vì vậy một yêu cầu thứ hai gửi nửa giây sau yêu cầu đầu có thể chưa hit, và lần hit có thể bao phủ ít hơn toàn bộ tiền tố của bạn.

Cách nhìn thấy: các trường cache trong usage#

Bạn không cần đoán xem nó có hoạt động không. Mỗi nhà cung cấp báo cáo điều đó trong phần usage của phản hồi, dưới tên trường riêng của họ.

DeepSeek dùng hai trường:

• prompt_cache_hit_tokens — token đầu vào được tìm thấy trong cache
• prompt_cache_miss_tokens — token đầu vào không được tìm thấy

Giả sử ticket hỗ trợ đầu tiên của bạn trả về prompt_cache_hit_tokens: 0 và prompt_cache_miss_tokens: 3200, và một ticket sau đó một phút hiển thị prompt_cache_hit_tokens: 3000 và prompt_cache_miss_tokens: 200. 3.000 token quy tắc đã được tái sử dụng; chỉ tin nhắn khách hàng mới và vài token được đọc từ đầu. Nếu con số hit vẫn bằng không ở mọi lần gọi, hãy xem phần đầu yêu cầu của bạn: có gì đó trong đó đang thay đổi.

Anthropic hoạt động khác, vì bạn đánh dấu phần cần cache. Bạn thêm cache_control với type ephemeral vào yêu cầu hoặc vào một content block:

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

Theo tài liệu prompt caching của Anthropic (kiểm tra ngày 24 tháng 10 năm 2026), phản hồi báo cáo ba con số: cache_creation_input_tokens (ghi vào cache lúc này), cache_read_input_tokens (đọc từ đó), và input_tokens (những gì đến sau cache breakpoint cuối cùng). Giả sử lần gọi đầu hiển thị cache_creation_input_tokens: 10000, cache_read_input_tokens: 0; lần thứ hai hiển thị 0 và 10000. Đó là một lần ghi cache tiếp theo là một lần đọc cache.

Có một cái bẫy trên màn hình. Các prompt ngắn hơn mức tối thiểu của model (512, 1.024 hoặc 4.096 token, tùy model) được xử lý mà không cache và không báo lỗi. Bạn sẽ thấy số không ở cả hai trường cache và không có cảnh báo. Thời gian sống mặc định là 5 phút, được làm mới miễn phí mỗi lần dùng; một ttl tùy chọn là 1h giữ nó lâu hơn.

Nó ảnh hưởng gì đến hóa đơn của bạn#

Caching thay đổi giá của phần lặp lại, nên đáng để tính một lần. Anthropic liệt kê các hệ số nhân trên giá đầu vào cơ bản: một lần ghi cache với thời gian sống 5 phút tốn 1,25×, một lần đọc tốn 0,1× (0,05× cho Opus 5.5 và Sonnet 5.5). Lấy một tiền tố 10.000 token được tái sử dụng trong 20 yêu cầu trong cửa sổ 5 phút, dùng mức đọc 0,1× tiêu chuẩn:

10.000 × 20 = 200.000 token theo giá cơ bản không có caching

10.000 × 1,25 = 12.500 cho yêu cầu đầu tiên ghi cache

19 × 10.000 × 0,1 = 19.000 cho 19 yêu cầu đọc nó

12.500 + 19.000 = 31.500 token-tương đương có caching

Vậy phần lặp lại tốn chưa đến một phần năm so với không cache. Cái bẫy: nếu 5 phút trôi qua giữa các yêu cầu, yêu cầu tiếp theo lại ghi cache ở 1,25×, và một tiền tố ít dùng có thể tốn hơn cả không cache.

Giờ là con bot từ đầu, như một baseline giá đầy đủ thông thường. 2.000 yêu cầu mỗi ngày, 3.000 token đầu vào và khoảng 300 token đầu ra mỗi lần:

2.000 × 3.000 = 6.000.000 token đầu vào mỗi ngày

2.000 × 300 = 600.000 token đầu ra mỗi ngày

Bảng dưới đây định giá khối lượng công việc của ngày đó trên mọi model CheapTokens hiện có, bên cạnh OpenRouter:

DeepSeek-V4-Flash rẻ hơn OpenRouter về tổng, khi tính cả đầu vào và đầu ra, và khối lượng công việc vừa vặn dễ dàng: context 380K và tối đa 32.768 token đầu ra mỗi câu trả lời. Đây là chi phí giá đầy đủ của khối lượng công việc: token đầu vào × giá mỗi token. Một tiền tố dài ổn định là nơi phần đầu vào đó lớn nhất.

Tự thử trong năm phút#

Kế hoạch: gửi cùng một system prompt dài hai lần với các câu hỏi khác nhau và xem usage. Đặt văn bản quy tắc của riêng bạn vào support_rules.txt (một hoặc hai trang văn bản là đủ). Endpoint là CheapTokens API tương thích OpenAI, và bạn có thể lấy key từ tài khoản của mình.

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

Cần kiểm tra gì trong kết quả in ra: prompt_tokens cho bạn biết yêu cầu của bạn lớn cỡ nào. Cả hai yêu cầu đều mang cùng văn bản SYSTEM, nên phần lớn con số đó lặp lại từ yêu cầu này sang yêu cầu kia — gần đúng bằng kích thước tệp quy tắc của bạn. Phần đầu lặp lại đó là phần mà một nhà cung cấp có caching, như DeepSeek API hoặc Anthropic ở trên, có thể tái sử dụng. Giờ là bài tập về thứ tự: thêm một dòng với thời gian hiện tại (datetime.now()) vào đầu SYSTEM và chạy lại. Hai yêu cầu không còn chia sẻ phần đầu, vì chúng khác nhau ngay từ dòng đầu tiên. Đặt cùng dòng đó ở cuối prompt và phần đầu chung lại trở về.

Một danh sách kiểm tra ngắn cho prompt của riêng bạn:

1. Văn bản ổn định trước: hướng dẫn, quy tắc, định nghĩa công cụ, ví dụ.
2. Văn bản thay đổi sau: ngày, tên người dùng, tin nhắn mới nhất.
3. Giữ tiền tố giống hệt từng byte — kể cả một dấu cách thừa cũng tính.
4. Kiểm tra kích thước tối thiểu của nhà cung cấp trước khi tự hỏi vì sao không có gì được cache.
5. Xem các trường usage sau khi thay đổi, không phải trước.

Để định giá khối lượng công việc của riêng bạn, mở trang giá và nhập kích thước đầu vào và đầu ra của bạn, hoặc bắt đầu từ trang DeepSeek. Khi yêu cầu đầu tiên hoạt động, cùng phép ước tính chỉ mất một phút cho bất kỳ prompt nào bạn viết. Về chi phí hai phía của một yêu cầu, xem token đầu vào so với đầu ra.