DEV Community

Cover image for GPT-6 prompt caching: giảm 90% chi phí đọc cache và cách thực sự truy cập trúng cache
Sebastian Petrus
Sebastian Petrus

Posted on Originally published at apidog.com

GPT-6 prompt caching: giảm 90% chi phí đọc cache và cách thực sự truy cập trúng cache

GPT-6 prompt caching: giảm 90% chi phí đọc cache và cách thực sự truy cập trúng cache

GPT-6 prompt caching

Mỗi vòng lặp agent bạn chạy đều gửi lại cùng một phần mở đầu: system prompt, định nghĩa công cụ, đặc tả OpenAPI, quy ước của repo. Mô hình đã thấy tiền tố đó hàng trăm lần trong ngày hôm nay, và lần nào bạn cũng trả giá input đầy đủ cho nó.

Dùng thử Apidog ngay hôm nay

Ở quy mô lớn, hóa đơn đó trở nên rất đáng kể. OpenAI cho biết nhà nghiên cứu trung vị của chính họ chi hơn 600 USD mỗi ngày cho agent lập trình, và phân vị thứ 90 chi 7.000 USD mỗi ngày. Đó là những người chạy công cụ nội bộ của một phòng lab, chứ không phải một API production đang phục vụ khách hàng.

Cùng với GPT-6 Sol và GPT-6 Luna vào ngày 22 tháng 9 năm 2026, OpenAI đã ra mắt bản phát hành prompt caching nhắm thẳng vào vấn đề này: lượt đọc input từ cache được giảm giá 90%, tỷ lệ hit mặc định cao hơn, hai thay đổi phổ biến nhất từng làm hỏng cache không còn làm hỏng cache nữa, bạn có thể đặt breakpoint tường minh, và giờ đã có Prompt Caching Dashboard cùng công cụ chẩn đoán để xem thực tế đang diễn ra gì. GitHub, khi chạy tính năng này trong production, báo cáo rằng số token prompt cần xử lý mới giảm hơn 50% trên hàng tỷ yêu cầu.

Hướng dẫn này bao gồm những gì đã thay đổi, khoản giảm giá đáng bao nhiêu tiền thật, cách bố trí prompt để cache thực sự hit, và cách kiểm tra rằng nó vẫn hit sau khi ai đó refactor system prompt của bạn.

Những gì đã ra mắt

Thay đổi Ý nghĩa với mã của bạn
Giảm giá 90% cho lượt đọc input từ cache Phần tiền tố lặp lại chỉ bị tính bằng một phần mười giá input
Tỷ lệ hit mặc định cao hơn Các tích hợp hiện có nhận được một phần lợi ích này mà không cần đổi mã
Thay đổi mức nỗ lực suy luận không còn làm hỏng cache Bạn có thể tăng từ low lên max giữa phiên và vẫn giữ prefix ấm
Thay đổi tính khả dụng của công cụ không còn làm hỏng cache Thêm hoặc bớt một công cụ mà không phải trả giá cho prefix lạnh
Breakpoint tường minh Bạn quyết định nơi prefix được cache kết thúc thay vì đoán
Prompt Caching Dashboard và công cụ chẩn đoán Tỷ lệ hit trở thành thứ bạn đo, không phải thứ bạn giả định

Ba thay đổi đầu tiên quan trọng nhất với agent. Thay đổi cuối cùng quan trọng nhất với kỹ sư phải giải thích hóa đơn tháng trước.

Phép tính

Prompt caching chỉ tác động đến token input. Giá output không đổi, nên một agent viết câu trả lời dài từ một prompt ngắn sẽ gần như không nhận ra khác biệt. Một agent đọc ngữ cảnh lớn, ổn định và đưa ra kết luận ngắn sẽ nhận ra rất rõ.

Đây là tác động của khoản giảm giá lên mức giá công bố của hai mô hình mới:

Mô hình Input mỗi 1M Đọc từ cache mỗi 1M Output mỗi 1M Ngữ cảnh
GPT-6 Sol (gpt-6-sol) $2.00 $0.20 $10.00 872k
GPT-6 Luna (gpt-6-luna) $0.10 $0.01 $0.50 1M

Cột "đọc từ cache" là mức giảm 90% áp lên giá input công bố. Hãy xác nhận lại với trang giá trực tiếp trước khi lập ngân sách dựa trên đó.

Giờ đến một khối lượng công việc cụ thể. Giả sử bạn chạy một agent review mã: 40.000 token tiền tố ổn định (system prompt, schema công cụ, tài liệu OpenAPI của dịch vụ, quy ước API của bạn) cộng thêm khoảng 2.000 token diff mỗi lần chạy, 500 lần chạy mỗi ngày.

Sol, không có cache hit Sol, prefix được cache Luna, không có cache hit Luna, prefix được cache
Token prefix mỗi ngày 20M với $2.00 = $40.00 20M với $0.20 = $4.00 20M với $0.10 = $2.00 20M với $0.01 = $0.20
Token mới mỗi ngày 1M với $2.00 = $2.00 1M với $2.00 = $2.00 1M với $0.10 = $0.10 1M với $0.10 = $0.10
Chi phí input hằng ngày $42.00 $6.00 $2.10 $0.30

Đó là mức giảm khoảng 86% hóa đơn input trên Sol cho một khối lượng công việc không hề thay đổi hình dạng. Thứ duy nhất thay đổi là liệu tiền tố có giữ nguyên từng byte giữa các lần gọi hay không.

Đáng để đặt cạnh đó: Claude Opus 5.5 niêm yết lượt đọc từ cache ở mức $0.20 mỗi triệu so với $4.00 input, với ghi cache ở mức $5.00 mỗi triệu. Giá đọc rơi vào cùng mức với Sol, và Anthropic tính thêm phí rõ ràng để ghi cache. Bản ra mắt của OpenAI không nêu mức giá ghi cache cho Sol hoặc Luna — đây là một trong những câu hỏi mở ở cuối bài. Nếu bạn đang so sánh toàn bộ hóa đơn thay vì từng con số riêng lẻ, bài phân tích cuộc chiến giá mô hình AI tháng 9 năm 2026 của chúng tôi đặt cả ba bản ra mắt vào một bảng.

Vì sao cache miss thường là lỗi của chính bạn

Prompt caching khớp theo tiền tố. Cache được khóa theo chuỗi token dẫn đầu trong yêu cầu của bạn, nên byte đầu tiên khác với lần gọi trước sẽ vô hiệu hóa mọi thứ phía sau. Một ký tự sai chỗ khiến bạn mất toàn bộ khoản giảm giá 40.000 token. Những thủ phạm kinh điển, theo thứ tự gần đúng về tần suất xuất hiện trong mã thực tế:

  • Dấu thời gian, request ID hoặc trace ID được chèn vào system prompt.
  • Tên người dùng, org ID hoặc locale được đặt phía trên các hướng dẫn tĩnh thay vì phía dưới.
  • Ngữ cảnh truy xuất được chèn trước định nghĩa công cụ, nên mỗi lần truy xuất mới lại làm dịch chuyển toàn bộ tiền tố.
  • Mảng công cụ được dựng từ set hoặc dictionary, khiến thứ tự khóa JSON xáo trộn giữa các tiến trình.
  • Các ví dụ few-shot được luân phiên theo từng yêu cầu để tạo sự đa dạng.

Hai thứ nữa từng nằm trong danh sách đó và giờ đã được gỡ. Thay đổi mức nỗ lực suy luận không còn làm hỏng cache, nên một agent chạy low ở các lượt dễ và tăng lên max ở lượt khó vẫn giữ được prefix ấm xuyên suốt lần tăng mức. Thay đổi tính khả dụng của công cụ cũng không còn làm hỏng nó, nên việc đặt một công cụ nguy hiểm sau kiểm tra quyền không còn buộc phải đọc lạnh toàn bộ phần phía trên. Hai mẫu này cực kỳ phổ biến trong các framework agent, và cho đến nay chúng âm thầm vô hiệu hóa cache đúng ở những lượt tốn kém nhất.

Bố trí [REDACTED PROMPT]

Nguyên tắc này vẫn đúng qua mọi thay đổi giá trong tương lai: sắp xếp ngữ cảnh theo tần suất thay đổi, ổn định nhất ở trên cùng.

  1. Hướng dẫn system hoặc developer giống hệt nhau cho mọi người dùng.
  2. Schema công cụ và hàm, được tuần tự hóa theo thứ tự cố định.
  3. Tài liệu tham chiếu dài dùng chung: tài liệu OpenAPI, hướng dẫn phong cách, schema cơ sở dữ liệu.
  4. Ngữ cảnh theo tenant hoặc theo dự án ít khi thay đổi.
  5. Các chunk truy xuất, thay đổi theo từng truy vấn.
  6. Lượt người dùng và bất kỳ thứ gì có yếu tố thời gian trong đó.

Các lớp một đến ba là cache của bạn. Nếu bắt buộc phải có dấu thời gian trong prompt, hãy đặt nó ở lượt người dùng, không phải trong system message. Nếu danh sách công cụ của bạn được lắp ráp động, hãy sắp xếp nó và cố định thứ tự khóa JSON để hai tiến trình tuần tự hóa nó giống hệt nhau.

from openai import OpenAI

client = OpenAI()

STATIC_PREFIX = [
    {"role": "developer", "content": SYSTEM_INSTRUCTIONS},   # never changes
    {"role": "developer", "content": OPENAPI_DOCUMENT},      # changes on deploy
]

response = client.responses.create(
    model="gpt-6-sol",
    reasoning={"effort": "low"},
    tools=SORTED_TOOL_SCHEMAS,
    prompt_cache_key="review-agent:v7",
    input=STATIC_PREFIX + [
        {"role": "user", "content": f"Review this diff:\n{diff}"},  # volatile, last
    ],
)

print(response.usage)
Enter fullscreen mode Exit fullscreen mode

Các breakpoint tường minh trong bản phát hành này cho phép bạn đánh dấu nơi tiền tố được cache kết thúc thay vì dựa vào nền tảng để suy ra. Điều này hữu ích nhất khi lớp bốn lớn: một khối theo tenant ổn định với một khách hàng và khác với khách hàng tiếp theo, nơi bạn muốn ranh giới được vẽ có chủ đích thay vì rơi vào bất kỳ token nào mà heuristic chọn.

Hãy đánh phiên bản cho chính cache key, như trong review-agent:v7 ở trên. Khi bạn cố ý thay đổi tiền tố, hãy tăng phiên bản, và bạn sẽ thấy giai đoạn lạnh trong số liệu của mình thay vì tự hỏi vì sao chi phí tăng vọt.

Hãy kiểm chứng, đừng giả định

Đối tượng usage trên mỗi phản hồi cho bạn biết có bao nhiêu token input được phục vụ từ cache. Hãy đọc nó, ghi log nó và đặt cảnh báo trên đó. Một dạng cơ bản:

usage = response.usage
cached = usage.input_tokens_details.cached_tokens
total_in = usage.input_tokens

print(f"cache hit rate: {cached / total_in:.0%}  billed fresh: {total_in - cached}")
Enter fullscreen mode Exit fullscreen mode

Tên trường trong các đoạn mã trên đến từ hình dạng API OpenAI hiện tại chứ không phải từ thông báo ra mắt, nên hãy kiểm tra chúng với tài liệu tham chiếu trước khi phát hành. Nguyên tắc không đổi: phản hồi cho bạn biết sự thật, nên hãy đưa con số đó lên dashboard.

Prompt Caching Dashboard và công cụ chẩn đoán mới bao quát góc nhìn toàn hệ thống, nơi bạn sẽ thấy mẫu mà GitHub báo cáo: hơn 50% token prompt không còn cần xử lý mới trên hàng tỷ yêu cầu. Đó là phép đo toàn nền tảng, và cách duy nhất để biết con số của chính bạn là đo nó.

Chế độ lỗi diễn ra âm thầm. Không có gì báo lỗi khi cache ngừng hit. Một đồng nghiệp thêm request ID vào system prompt để debug, tiền tố trở nên lạnh, và tín hiệu duy nhất là một dòng tăng chậm trên hóa đơn ba tuần sau đó.

Điều đó biến nó thành một bài kiểm tra hồi quy, không phải vấn đề giám sát. Hãy đối xử với endpoint mô hình như bất kỳ API nào bạn phụ thuộc: lưu yêu cầu trong Apidog, khẳng định rằng usage.input_tokens_details.cached_tokens vượt một ngưỡng sàn ở lần gọi thứ hai trong một kịch bản, và chạy nó theo lịch trong CI. Hai lần gọi liên tiếp — một để làm ấm và một để khẳng định — là toàn bộ bài kiểm tra, và một cuộc refactor prompt giết chết cache sẽ thất bại trên pull request thay vì trên hóa đơn.

Ghi chú về độ trễ

Cache cắt bớt công việc được thực hiện trước token đầu tiên, nên nó thường giúp cả thời gian đến token đầu tiên lẫn chi phí. Đừng mong nó cứu các chế độ suy luận.

Artificial Analysis, một bên thứ ba, đo thời gian đến token đầu tiên là 102,15 giây với GPT-6 Sol và 124,23 giây với GPT-6 Luna trên các biến thể suy luận "max" của họ. Đó không phải những con số bạn sẽ thấy ở mức nỗ lực low, và chúng không phải số liệu từ nhà cung cấp, nên hãy xem chúng mang tính định hướng. Luận điểm vẫn đúng dù thế nào: không khoản giảm giá cache nào biến ngân sách suy nghĩ hai phút thành tương tác được. Hãy đo độ trễ theo từng mức nỗ lực trước khi bạn hứa hẹn một thời gian phản hồi. Hướng dẫn API GPT-6 Astra của chúng tôi đề cập chi tiết hơn về các mức nỗ lực.

Những gì buổi ra mắt chưa trả lời

Có bốn điều đáng xác nhận trước khi bạn cam kết một thiết kế dựa trên điều này:

  • Liệu ghi cache có bị tính phí trên Sol và Luna không, và ở mức nào.
  • Một tiền tố được cache tồn tại bao lâu khi không có lưu lượng, và liệu các kiểm soát lưu trữ từ thời GPT-5.6 có được giữ nguyên không.
  • Liệu mức giá đọc từ cache của GPT-6 Astra có chuyển sang cùng mức giảm 90% hay không, vì tài liệu ra mắt chỉ đề cập các mô hình mới.
  • Tên tham số chính xác cho các breakpoint tường minh, vì thông báo mô tả theo khả năng chứ không theo trường.

Không điều nào trong số đó chặn công việc bố trí. Thứ tự ổn định trước, cache key có phiên bản và một khẳng định trên token được cache đều có lợi bất kể câu trả lời là gì.

Bản tóm tắt ngắn

Hãy sắp xếp prompt theo mức biến động và giữ yếu tố thời gian ra khỏi system message. Đánh phiên bản cho cache key để những thay đổi có chủ đích là hữu hình. Đọc cached_tokens trên mọi phản hồi và đặt một ngưỡng sàn cho nó trong CI. Giờ bạn có thể tăng mức nỗ lực suy luận và bật/tắt công cụ thoải mái, vì cả hai đều không còn làm mất tiền tố của bạn nữa. Để hiểu nền tảng về cơ chế này, bài giải thích của chúng tôi về cách prompt caching hoạt động bao quát các kiến thức cơ bản.

Giá của các mô hình này sẽ lại thay đổi. Lúc nào cũng vậy. Kỷ luật bố trí prompt là phần tiếp tục mang lại lợi ích sau khi bản ra mắt tiếp theo đặt lại mọi con số trong bảng.

Top comments (0)