Lưu đệm prompt trên OpenAI, Claude và Gemini

Nếu các prompt của bạn chia sẻ một tiền tố dài, ổn định — một chỉ dẫn hệ thống lớn, một danh mục công cụ, một tài liệu mà bạn cứ hỏi đi hỏi lại — thì prompt caching cho phép nhà cung cấp bỏ qua việc xử lý lại tiền tố đó và tính phí nó với mức chiết khấu sâu. Cả ba OpenAI, Anthropic, và Google đều cung cấp tính năng này, và phần thưởng ở khắp nơi đều giống nhau: chi phí đầu vào thấp hơn và thời-gian-tới-token-đầu-tiên nhanh hơn trên phần được cache. Điều khác nhau là ai quyết định cái gì được cache. OpenAI cache tự động theo tiền tố. Anthropic buộc bạn đánh dấu các điểm cache một cách tường minh. Gemini cache ngầm định theo mặc định và cũng phơi bày một đối tượng cache tường minh. Bài viết này lập bản đồ ba bề mặt điều khiển đó, các trường usage mà mỗi bên trả về, và cách cấu trúc một prompt để cache thật sự trúng.

Kiểm tra lần cuối: 2026-07-15. Mức tối thiểu theo từng mô hình, TTL, và các hệ số nhân giá cả đều thay đổi; hãy xác nhận với các trang giá và caching được liên kết của từng nhà cung cấp trước khi bạn dựa vào một con số cụ thể.

Một quy tắc mà cả ba đều chia sẻ: cache tiền tố, biến đổi phần đuôi

Mọi nhà cung cấp đều cache một tiền tố của prompt và khớp trên các byte chính xác. Hệ quả thực tế là giống hệt nhau giữa các nhà cung cấp: đặt những phần giữ nguyên lên trước, và những phần thay đổi ở sau cùng. Một system prompt, các ví dụ few-shot, các định nghĩa công cụ, và một tài liệu tham chiếu lớn thuộc về phần đầu; câu hỏi hiện tại của người dùng thuộc về phần cuối. Sắp xếp lại chúng và bạn dịch chuyển ranh giới giữa "có thể cache" và "không," và một chỉnh sửa sớm duy nhất — thậm chí một dấu thời gian được chèn vào system message — làm vô hiệu mọi thứ phía sau nó. Đây là thay đổi có đòn bẩy cao nhất mà bạn có thể thực hiện, và nó miễn phí.

Caching cũng có một kích thước tối thiểu. Các prompt ngắn không đáng cache và các nhà cung cấp đơn giản là không cache, nên chiết khấu chỉ xuất hiện một khi tiền tố được cache vượt qua một ngưỡng khác nhau theo từng mô hình. Dưới ngưỡng đó, bạn trả mức đầu vào bình thường và thấy số token được cache bằng không.

OpenAI: tự động, dựa trên tiền tố, được hích bởi prompt_cache_key

Caching của OpenAI là tự động — bạn không cần chọn tham gia. Caching được bật tự động cho các prompt dài từ 1024 token trở lên, và việc khớp hoạt động dựa trên tiền tố của prompt. Khi một yêu cầu tái sử dụng một tiền tố đã được cache, các token được tái dùng sẽ tính phí theo mức đầu-vào-đã-cache được chiết khấu và xuất hiện trong đối tượng usage dưới dạng cached_tokens: dưới usage.prompt_tokens_details trên Chat Completions, và dưới usage.input_tokens_details trên Responses API. Các yêu cầu dưới ngưỡng báo cáo cached_tokens bằng không.

Bạn không điều khiển caching trực tiếp, nhưng bạn có thể tác động đến việc định tuyến với prompt_cache_key. Các yêu cầu chia sẻ một tiền tố chung dài nhưng đến từ những người dùng hoặc đường dẫn khác nhau có thể rơi vào các backend cache khác nhau; đặt cùng một prompt_cache_key trên các yêu cầu liên quan sẽ được kết hợp với hash tiền tố để định tuyến chúng cùng nhau và cải thiện tỷ lệ trúng cache. Trên các mô hình mới hơn, khóa này là thứ làm cho việc khớp trở nên đáng tin cậy, và OpenAI gợi ý giữ lưu lượng trên mỗi khóa ở mức vừa phải thay vì phun hàng nghìn yêu cầu mỗi phút qua một khóa duy nhất.

Thời gian lưu giữ có thể điều khiển được. Các mô hình mới hơn chấp nhận prompt_cache_options với một ttl (30 phút là tuổi thọ tối thiểu được hỗ trợ và cũng là mặc định), trong khi các mô hình trước đó dùng prompt_cache_retention, mà các mục trong bộ nhớ của nó thường vẫn hoạt động trong vài phút không hoạt động và có thể được kéo dài lên tới 24 giờ. Trên các mô hình mới nhất, các token được ghi vào cache được báo cáo riêng dưới dạng cache_write_tokens và định giá ở mức 1.25× mức đầu vào chưa cache; các mô hình cũ hơn không thêm phí ghi. Một gateway truyền prompt_cache_key và prompt_cache_retention thẳng lên thượng nguồn, nên bạn giữ được cùng những núm điều khiển đó sau một base URL duy nhất.

Anthropic: dấu cache_control, tự động hoặc tường minh

Anthropic chỉ cache phần được một dấu cache_control bao phủ, nhưng bạn không phải tự đặt mọi điểm ngắt. Có hai chế độ. Cache tự động thêm một trường cache_control duy nhất ở cấp cao nhất của yêu cầu; hệ thống đặt điểm ngắt tại khối cuối cùng có thể cache và dịch nó về phía trước khi cuộc hội thoại dài ra, phù hợp với chat nhiều lượt. Điểm ngắt tường minh đặt cache_control trực tiếp trên từng khối nội dung để kiểm soát chính xác phần nào được cache. Ví dụ dưới đây dùng một điểm ngắt tường minh trên tài liệu hướng dẫn ổn định:

import anthropic
client = anthropic.Anthropic(base_url="https://your-gateway.example.com", api_key="AVE_GATEWAY_API_KEY")

client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system=[
        {"type": "text", "text": "You are a contract analyst."},
        {
            "type": "text",
            "text": LONG_STATIC_PLAYBOOK,        # the expensive, stable prefix
            "cache_control": {"type": "ephemeral"},
        },
    ],
    messages=[{"role": "user", "content": "Summarize the indemnity clause."}],
)

Bạn có thể định nghĩa tối đa 4 điểm ngắt cache (dấu tự động ở cấp cao nhất dùng một trong bốn điểm), nhờ đó cache các phần thay đổi ở tần suất khác nhau: một system prompt hiếm khi chỉnh sửa sau một điểm ngắt, một tài liệu theo phiên sau điểm khác. Độ dài tối thiểu có thể cache phụ thuộc vào mô hình; nhiều mô hình hiện tại, gồm Claude Opus 4.8 và Sonnet 5, bắt đầu từ 1.024 token, còn một số bậc yêu cầu 2.048 hoặc 4.096. Prompt ngắn hơn mức tối thiểu vẫn được xử lý lặng lẽ mà không cache — không có lỗi, chỉ không có chiết khấu.

Việc hạch toán usage là tường minh và đáng đọc kỹ. Các phản hồi trả về ba số đếm riêng biệt: cache_creation_input_tokens (các token được ghi vào một mục cache mới), cache_read_input_tokens (các token được phục vụ từ cache), và input_tokens (mọi thứ sau điểm ngắt cuối cùng). Tổng đầu vào là tổng của ba số, và nếu cả hai số đếm cache đều bằng không, thì không có gì được cache. Tuổi thọ cache mặc định là 5 phút, được làm mới miễn phí mỗi lần mục được sử dụng, nên một cache đang được trúng liên tục sẽ giữ ấm một cách hiệu quả; một tùy chọn "ttl": "1h" kéo dài nó với chi phí ghi cao hơn. Các hệ số nhân giá là công khai: một lần ghi cache 5 phút tốn 1.25× đầu vào cơ bản, một lần ghi 1 giờ tốn 2×, và mỗi lần đọc cache tốn 0.1× đầu vào cơ bản. Chiết khấu đọc 10× đó chính là lý do để bận tâm.

Gemini: ngầm định theo mặc định, tường minh khi bạn cần điều khiển

Mặc định của Google là ít công sức nhất: caching ngầm định được bật tự động cho Gemini 2.5 và các mô hình mới hơn, và tiết kiệm chi phí được chuyển giao tự động khi một yêu cầu trúng cache. Bạn cấu trúc prompt với nội dung chung lên trước, gửi các yêu cầu có tiền tố tương tự gần nhau về thời gian, và đọc số token được cache từ metadata usage. Các mức tối thiểu cũng áp dụng ở đây — các bậc Flash và Pro hiện tại bắt đầu cache ở mức vài nghìn token, và thế hệ mới hơn yêu cầu một tiền tố lớn hơn.

Khi bạn cần caching được đảm bảo và điều khiển tuổi thọ tường minh, API generateContent của Gemini cung cấp context caching tường minh thông qua một đối tượng CachedContent: bạn tải lên nội dung một lần, nhận một handle, đặt một TTL, và tham chiếu handle đó trên các lệnh gọi tiếp theo. Caching tường minh đảm bảo chiết khấu cho nội dung mà bạn biết mình sẽ tái sử dụng (một PDF dài, một video, một tập chỉ dẫn cố định) thay vì để mặc cho suy nghiệm ngầm định. Số token được cache hiện ra trong usageMetadata (dưới dạng cachedContentTokenCount trên generateContent), mà một gateway chuẩn hóa thành cùng trường token-được-cache mà nó báo cáo cho các nhà cung cấp khác.

Một gateway có thể và không thể chuẩn hóa cái gì

Sau một endpoint tương thích OpenAI duy nhất, gateway chuyển tiếp các điều khiển cache mà mỗi nhà cung cấp hiểu và gộp các trường usage khác nhau thành một dạng hạch toán chung — cached_tokens cho lượt đọc cùng các số đếm tạo cache — để yêu cầu được cache xuất hiện giống nhau trong nhật ký sử dụng bất kể thượng nguồn. Gateway cũng áp dụng các tỷ lệ tính phí có thể cấu hình: tỷ lệ đọc cache tính phí đầu vào đã cache thấp hơn mức bình thường và tỷ lệ tạo cache (mặc định 1.25×) cho lượt ghi, được công bố theo từng mô hình trên trang giá công khai.

Tuy nhiên hãy tường minh về các giới hạn. Ba nhà cung cấp không phơi bày cùng những núm điều khiển, nên việc chuẩn hóa gây mất mát theo cả hai chiều:

• Điều khiển không ánh xạ một-một. OpenAI cache theo tiền tố mà không có khái niệm điểm ngắt tường minh, trong khi Anthropic yêu cầu dấu cache_control — tự động hoặc tối đa bốn điểm tường minh — và không có cache tiền tố ngầm định kiểu OpenAI; prompt_cache_key không có ý nghĩa với Gemini. Cơ chế truyền thẳng chuyển tiếp phần thượng nguồn hỗ trợ và bỏ qua phần còn lại.
• Ngữ nghĩa TTL khác nhau. ttl của OpenAI là tuổi thọ tối thiểu, của Anthropic là một cửa sổ 5 phút (hoặc 1 giờ) cố định được làm mới khi dùng, và TTL tường minh của Gemini được đặt theo từng đối tượng cache. "Một giờ" không có cùng ý nghĩa trên cả ba.
• Từ vựng usage khác nhau. Anthropic tách riêng việc tạo cache 5 phút và 1 giờ; OpenAI chỉ tách đọc và ghi trên các mô hình mới hơn; Gemini báo cáo một số đếm nội-dung-được-cache duy nhất. Gateway ánh xạ những cái này thành các trường chung nhưng không thể bịa ra một sự phân biệt mà một nhà cung cấp chưa bao giờ báo cáo.

Hãy coi gateway như nơi cho bạn một cái nhìn tính phí duy nhất và một đường truyền thẳng duy nhất, chứ không phải như một lớp làm cho ba thiết kế caching khác nhau hành xử giống hệt nhau. Khi có nghi ngờ, hãy đọc usage thô mà gateway ghi lại và đối chiếu nó với tài liệu của chính nhà cung cấp.

Làm cho cache thật sự trúng

Bốn thói quen quyết định liệu caching có ích hay lặng lẽ chẳng làm gì:

1. Đưa nội dung ổn định lên đầu. Chỉ dẫn, công cụ, và tài liệu tham chiếu trước; lượt của người dùng sau cùng. Đây là quy tắc duy nhất quan trọng nhất.
2. Giữ tiền tố ổn định theo byte. Không có dấu thời gian, ID yêu cầu, hay thứ tự công cụ bị xáo trộn trong vùng được cache. Một byte thay đổi ở đầu làm vô hiệu phần còn lại.
3. Gửi các yêu cầu liên quan gần nhau về thời gian. Cache hết hạn; gom các công việc tương tự trong cửa sổ TTL giữ cho các mục ấm. Một cache nhàn rỗi là một cache nguội.
4. Xác minh bằng usage, không phải bằng cảm giác. Hãy xác nhận cached_tokens (hoặc tương đương của nhà cung cấp) khác không trước khi tuyên bố có tiết kiệm. Caching mà bạn giả định nhưng không bao giờ đo lường là một nguồn phổ biến của những khoản giảm chi phí tưởng tượng.

Prompt caching là mục có lợi tức cao nhất trong thực đơn rộng hơn của công việc chi phí trong giảm chi phí LLM API, và nó ghép cặp tự nhiên với quản lý cửa sổ ngữ cảnh LLM: cùng cái tiền tố ổn định mà bạn cache thường chính là ngữ cảnh mà nếu không thì bạn sẽ gửi lại và bị tính phí lại trên mỗi lượt.

FAQ

Caching có giảm chi phí token đầu ra không?

Không. Caching chỉ áp dụng cho các token đầu vào (prompt) — cái tiền tố mà nhà cung cấp có thể tái sử dụng. Các token đầu ra được sinh mới mỗi lần gọi và tính phí ở mức đầu ra bình thường bất kể trạng thái cache. Nếu chi phí của bạn bị chi phối bởi những lần sinh dài thay vì những prompt dài, caching dịch chuyển sai con số; hãy nhìn vào độ dài đầu ra và lựa chọn mô hình thay vào đó.

Nếu cả hai số đếm đọc-cache và ghi-cache đều bằng không, thì caching đã thất bại phải không?

Nó có nghĩa là không có gì được cache cho yêu cầu đó — thường vì tiền tố dưới kích thước tối thiểu có thể cache của mô hình, tiền tố đã thay đổi kể từ lần gọi trước, hoặc (đối với các sơ đồ tường minh) bạn đã không đánh dấu một điểm ngắt. Các nhà cung cấp không báo lỗi trên một prompt không thể cache; họ chỉ tính phí nó ở mức đầu vào tiêu chuẩn. Hãy đọc các trường usage để xác nhận thay vì giả định một lần trúng.

Một lần trúng cache có được đảm bảo nếu tôi gửi lại đúng cùng một tiền tố không?

Không. Cache là nỗ lực tốt nhất (best-effort) và có giới hạn thời gian. Các mục hết hạn sau TTL của chúng, và một lần trúng cũng phụ thuộc vào việc định tuyến — đó là lý do OpenAI phơi bày prompt_cache_key để lái các yêu cầu liên quan tới cùng một backend. Hãy thiết kế caching như một tối ưu hóa thường có ích, chứ không phải một sự đảm bảo mà bạn có thể tính vào hóa đơn.

Một yêu cầu gateway duy nhất có thể dùng caching của OpenAI, Anthropic, và Gemini thay thế cho nhau không?

Bạn có thể gửi các điều khiển caching qua một endpoint, nhưng mỗi cái chỉ được hiểu bởi thượng nguồn của riêng nó: cache_control tới Anthropic, prompt_cache_key tới OpenAI, một handle CachedContent tường minh tới Gemini. Gateway chuẩn hóa usage được báo cáo thành các trường chung; nó không thể làm cho một nhà cung cấp tôn trọng chỉ thị caching của một nhà cung cấp khác.

Đo một cặp trước và sau thực tế

Chọn prompt lặp lại nhiều nhất — prompt có tiền tố cố định lớn nhất — và chạy nó hai lần qua gateway trong vòng một phút. Ở lần gọi thứ nhất, tiền tố được ghi vào cache; ở lần thứ hai, nó nên được đọc từ cache. Kiểm tra nhật ký sử dụng và xác nhận yêu cầu thứ hai báo cáo số token đã cache khác không cùng khoản phí đầu vào thấp hơn lần đầu. Cặp trước và sau trên chính lưu lượng của bạn cho biết mức tiết kiệm thực tế tốt hơn nhiều so với bất kỳ hệ số nhân công bố nào.

Tài liệu tham khảo

• OpenAI: lưu đệm prompt
• Anthropic: lưu đệm prompt
• Google Gemini: lưu đệm ngữ cảnh
• Bảng giá OpenAI API
• Bảng giá Anthropic