Vì sao cache hit của AI agent sụp đổ: GPT, Claude và gateway có thể kiểm toán
Hướng dẫn dựa trên nguồn sơ cấp về lỗi cache của agent bên thứ ba, prompt caching của GPT và Claude, đo lường có thể tái lập và cơ chế bù công khai của Modelflare.
Bộ nhớ đệm của một agent AI không phải là một ô bật/tắt. Đây là hợp đồng về giao thức, định tuyến và kế toán. Bài viết giải thích vì sao agent bên thứ ba có thể có tỷ lệ cache hit rất thấp dù mô hình upstream hỗ trợ prompt caching, cơ chế và cách đo của GPT khác Claude như thế nào, và một gateway có thể kiểm toán cần cam kết điều gì.
Quyết định trong một câu
Không đặt agent production nhạy cảm với cache sau một agent hoặc gateway bên thứ ba không hiển thị usage native, không giữ prefix ổn định, không duy trì affinity của model và route, không công khai TTL và mẫu số, và không đối soát được với sổ cái bền vững. “Có hỗ trợ cache” là một lời quảng bá tính năng; tỷ lệ hit đo được trên traffic đủ điều kiện mới là sự thật vận hành.
Điều này không khẳng định mọi agent bên thứ ba đều thất bại. Tài liệu công khai không thể chứng minh phần trăm trên toàn nhà cung cấp nếu thiếu corpus cố định, model cố định, khoảng quan sát rõ ràng và bằng chứng usage theo request. Kết luận chặt chẽ hơn là một lớp chuyển đổi không minh bạch tạo ra nhiều điểm đứt độc lập và có thể biến cache hợp lệ của provider thành đường dẫn gần như luôn lạnh. Với traffic production phụ thuộc vào cache, không có bằng chứng đã là lý do để không chọn đường dẫn đó.
Xác định mẫu số trước khi nói về phần trăm
Provider thường báo cáo ba nhóm khác nhau. R là token đọc từ cache, W là token ghi vào cache, còn U là input token được xử lý mà không tái sử dụng. Với prefix đủ điều kiện cache, hit rate có thể so sánh là:
eligible_hit_rate = R / (R + W)
Với toàn bộ input gửi đến model, tỷ lệ tái sử dụng là:
input_reuse_share = R / (R + W + U)
Hai con số trả lời hai câu hỏi khác nhau. Dashboard chia cho toàn bộ input có thể trông thấp khi agent gửi nhiều request ngắn không đủ điều kiện. Dashboard chỉ chia traffic đủ điều kiện lại có thể che khuất việc suffix động vẫn chiếm phần lớn chi phí. Hãy báo cáo cả hai, quy tắc đủ điều kiện và khoảng thời gian.
Bằng chứng nằm ở các field của provider, không phải huy hiệu màu xanh trong giao diện agent:
| Tín hiệu | Field OpenAI | Field Claude | Điều được chứng minh |
|---|---|---|---|
| Prefix được tái sử dụng | input_tokens_details.cached_tokens |
cache_read_input_tokens |
Token được phục vụ từ entry khớp |
| Entry cache mới | input_tokens_details.cache_write_tokens |
cache_creation_input_tokens |
Token dùng để tạo hoặc gia hạn entry |
| Input không tái sử dụng | input_tokens - input_tokens_details.cached_tokens - input_tokens_details.cache_write_tokens (suy ra cẩn thận) |
input_tokens sau breakpoint |
Input ngoài prefix; ngữ nghĩa khác nhau |
| Đối chiếu | request ID, model và route | request ID, model và route | Lần thử của provider tạo ra usage |
Ví dụ tổng hợp, không phải telemetry production của Modelflare: R=720,000, W=80,000, U=200,000 cho eligible hit rate 720,000 / 800,000 = 90%, nhưng tỷ lệ tái sử dụng trên toàn input là 720,000 / 1,000,000 = 72%. Chỉ công bố một số sẽ che giấu mẫu số.
input_tokens_details.cache_write_tokens=0 không chứng minh “không có cache”: một lần đọc không tạo entry mới. Nếu response của bên thứ ba thiếu field usage, đó cũng không phải số 0; đó là lỗi observability và phải ghi là không thể kiểm toán.
Vì sao đường dẫn agent mất hit dù model hỗ trợ cache
Vấn đề thường nằm giữa ứng dụng và provider. Những điểm đứt thường gặp nhất là:
- Byte động xuất hiện quá sớm. Timestamp, request ID, người dùng, cờ thử nghiệm hoặc ngày hiện tại thay đổi làm prefix đổi trước các chỉ dẫn có thể tái sử dụng.
- Tool bị serialize lại. Thêm, xóa, sắp xếp lại hoặc serialize schema tool không xác định làm thay đổi prefix chính xác; chỉ riêng thứ tự key JSON cũng có thể tạo miss.
- Fallback đổi danh tính cache. Cân bằng tải giữa model alias, region, tổ chức hoặc credential không dùng chung một entry toàn cục.
- Adapter bỏ qua điều khiển native. Loại
cache_control,prompt_cache_key, tùy chọn retention hoặc chi tiết usage biến tính năng thành best effort không nhìn thấy. - Prompt ngắn hơn ngưỡng. Một lượt agent ngắn có thể hợp lệ nhưng không đủ điều kiện cache.
- Vượt qua cửa sổ TTL. Entry Claude năm phút hoặc retention OpenAI theo model có thể hết hạn trong lúc chờ con người.
- Race khi warm-up song song. Các request đầu tiên đồng thời có thể đến trước khi response đầu tiên làm entry sẵn sàng.
- Lịch sử bị viết lại. Tóm tắt, nén, cắt bớt hoặc serialize khác đi làm prefix thay đổi thay vì nối thêm ở cuối.
Không lỗi nào trong số này cần nhà cung cấp cố ý lừa dối. Đây là hệ quả có thể dự đoán khi gateway coi request agent là văn bản tự do và không giữ hợp đồng cache của provider. Cảnh báo thực tế rất rõ: nếu agent không chỉ ra được breakpoint nào thất bại, bạn không thể định giá hay gỡ lỗi traffic phụ thuộc cache một cách đáng tin cậy.
GPT và Claude có ý tưởng tương tự nhưng ngữ nghĩa khác nhau
Cả hai đều yêu cầu prefix tái sử dụng khớp tuyệt đối, nhưng cách điều khiển và hạch toán khác nhau. Bảng dưới dựa trên tài liệu chính thức đã kiểm tra ngày 2026-08-25; tên model, ngưỡng và retention có thể thay đổi.
| Khía cạnh | OpenAI prompt caching | Claude prompt caching |
|---|---|---|
| Đơn vị tái sử dụng | Toàn bộ prefix context đã render, gồm instruction, tool, history và phần đa phương thức | Prefix theo thứ tự tới breakpoint cache_control: tool, system, messages |
| Độ dài tối thiểu | Hướng dẫn hiện tại nêu 1.024 token hiển thị cho GPT-5.6+ và thường 2.048 ở model cũ | Theo model, khoảng 512–4.096 token; prompt ngắn hơn không được cache |
| Điều khiển | Cache ngầm; breakpoint rõ ràng và prompt_cache_key ổn định ở model được hỗ trợ |
Cache tự động cấp cao hoặc breakpoint theo block; tối đa bốn và lookback 20 block |
| Retention | GPT-5.6+ hỗ trợ TTL 30 phút; model cũ có mode với cửa sổ điển hình của provider | TTL mặc định năm phút, được làm mới khi dùng; tùy chọn một giờ có giá write cao hơn |
| Cấu trúc giá | Hướng dẫn GPT-5.6+ hiện tại: write 1,25× và read 0,1× input cơ bản | Write năm phút 1,25×, một giờ 2×; read 0,1× |
| Bằng chứng usage | input_tokens_details.cached_tokens và, nếu có, input_tokens_details.cache_write_tokens |
cache_read_input_tokens, cache_creation_input_tokens và input_tokens sau breakpoint |
| Invalidator phổ biến | Thay đổi model, tool, setting, overflow máy hoặc thay đổi trước breakpoint | Thay đổi model, system, tool, message; thiếu message trước đó hoặc miss khi warm-up song song |
OpenAI cho biết entry cache nằm trên từng máy: prompt_cache_key giúp nhóm và định tuyến nhưng không ghim một máy hay đảm bảo hit. Claude ghi rõ việc khớp tuyệt đối, cô lập theo workspace và chẩn đoán như tools_changed, messages_changed. Gateway che giấu những khác biệt này không thể biến tài liệu provider thành một lời hứa duy nhất một cách trung thực.
Các hệ số giá cho thấy tác động. Với model OpenAI được trích dẫn, một lần write rồi một lần read tốn khoảng 1.25 + 0.10 = 1.35× đơn vị input không cache; mười request tái sử dụng hoàn toàn tốn khoảng 1.25 + 9×0.10 = 2.15×, không phải 10×. Đây là phép tính minh họa chính thức, không phải hóa đơn Modelflare hay cam kết cho mọi model.
Chi phí của adapter có thể đo được
Hãy dùng ma trận lỗi thay vì ảnh chụp màn hình. Cố định prompt, model, credential và tốc độ; mỗi lần chỉ đổi một biến và lưu object usage gốc.
| Thay đổi có kiểm soát | Tín hiệu mong đợi | Agent không minh bạch có thể giấu gì | Diễn giải phát hành |
|---|---|---|---|
| Chỉ nối thêm lượt người dùng | R tăng sau W đầu tiên |
Lịch sử bị viết lại hoặc route mới | Prefix được giữ |
| Thêm timestamp vào system prompt | R về 0 hoặc xuất hiện W mới |
Byte nào đã đổi | Prefix động phá cache |
| Đổi thứ tự một thuộc tính tool | tools_changed hoặc write mới |
Hành vi serializer | Schema phải xác định |
| Chia traffic giữa alias hoặc máy | R thấp và dao động hơn |
Route và key được chọn | Thiếu affinity |
| Chờ quá TTL được công bố | Write mới sau khi hết hạn | Thời điểm hết hạn và mode retention | Đo riêng các khoảng chờ của người |
| Gửi song song hai request đầu giống nhau | Một hoặc cả hai có thể write | Race warm-up và thứ tự thử | Burst lạnh không đo năng lực |
Lưu request ID, mode streaming, thời gian event đầu tiên, model chính xác, route được chọn, field cache và timestamp UTC. Che prompt, key và nội dung khách hàng. Nếu gateway chỉ trả tổng input đã chuẩn hóa, hãy đánh dấu lần chạy không thể kiểm toán; chiều bị thiếu không phải số 0 để tự bịa.
Bản ghi audit có thể tái lập
Đây là một format tổng hợp nhỏ. Envelope trung lập với provider, còn usage giữ field native. Đây không phải benchmark.
{"request_id":"demo-001","timestamp":"2026-08-25T02:00:00Z","model":"MODEL_ID","route":"route-a","stream":true,"usage":{"input_tokens":1000000,"input_tokens_details":{"cached_tokens":0,"cache_write_tokens":1000000}}}
{"request_id":"demo-002","timestamp":"2026-08-25T02:00:03Z","model":"MODEL_ID","route":"route-a","stream":true,"usage":{"input_tokens":1000000,"input_tokens_details":{"cached_tokens":720000,"cache_write_tokens":80000}}}
Chạy ít nhất năm pha: warm-up tuần tự, hội thoại chỉ nối thêm, thay đổi system động, thay đổi thứ tự tool và replay sau khoảng TTL. Giữ field read/write native của từng provider và so sánh R/(R+W) cùng R/(R+W+U) theo pha, route, model và ngày UTC. Một con số trộn không đủ để duyệt agent cho production.
Modelflare đảm bảo gì và không đảm bảo gì
Trang trạng thái công khai của Modelflare hiện mô tả OpenAI Cache Hit Rate Guarantee. Với request đủ điều kiện, đáp ứng yêu cầu caching của OpenAI và tạo cache hợp lệ, tỷ lệ theo ngày được tính theo ngày lịch UTC. Nếu thấp hơn tier áp dụng, phần chênh lệch được bù và hiển thị ở Dashboard → Token Usage Analysis. Các tier công khai hiện là 65%, 75%, 85%.
Ranh giới này là có chủ ý:
- Bảo đảm áp dụng cho traffic OpenAI đủ điều kiện và hợp lệ, không áp dụng cho request ngắn hoặc luôn thay đổi nên không bao giờ đủ điều kiện.
- Bảo đảm không biến model, schema tool, route hay TTL thay đổi thành prefix có thể tái sử dụng.
- Tính theo ngày UTC và ghi credit qua giao diện tài khoản đã công bố; không phải lời hứa mọi request đều hit.
- Bằng chứng usage native và phép tính eligibility vẫn bắt buộc. Mẫu số rõ ràng giúp kiểm chứng khoản bù.
Đó là khác biệt giữa một cam kết dịch vụ có thể kiểm toán và khẩu hiệu của agent bên thứ ba: cam kết đầu tiên nêu rõ quần thể đủ điều kiện, cửa sổ, ngưỡng và nơi ghi credit.
Lợi thế giá và tính chính danh vận hành là hai bằng chứng riêng
Trang giá công khai hiện cũng hiển thị tỷ lệ khuyến mãi 0.015 cho lần nạp đầu ở campaign/group áp dụng, cùng mức tối thiểu và điều kiện được công bố. Đây là ưu đãi giá, không phải bảo đảm cache. Hãy kiểm tra trang trực tiếp về phạm vi model và quy tắc thanh toán trước khi mua.
Tài liệu trust và pháp lý công khai xác định Havenbyte LLC là đơn vị vận hành và mô tả hoạt động đặt tại Hoa Kỳ. Tài liệu nêu Stripe là bộ xử lý thanh toán cho thanh toán, hóa đơn, hoàn tiền và kiểm soát gian lận. Đây là tín hiệu về trách nhiệm và lưu ký, không phải tuyên bố về đăng ký tại một bang hay chứng nhận cụ thể.
Khuyến nghị cho agent production
Chỉ chọn agent bên thứ ba khi vượt qua checklist sau:
- Chuyển tiếp điều khiển cache native và trả về read/write native.
- Giữ byte của prefix instruction và tool ổn định giống hệt, rồi mới thêm state động.
- Hiển thị model, route, ranh giới tổ chức/khu vực, mode TTL và request ID.
- Ghi riêng warm-up tuần tự và song song, không lấy trung bình để che khuất.
- Định nghĩa bằng văn bản traffic đủ điều kiện, mẫu số, cửa sổ UTC, ngưỡng và khoản bù.
- Cho phép xuất bằng chứng theo request mà không lộ key hoặc nội dung khách hàng.
Nếu có câu trả lời “không”, đừng dùng đường dẫn đó cho workload có kinh tế phụ thuộc vào tái sử dụng cache. Hãy thử đường dẫn trực tiếp của provider hoặc chọn gateway có thể kiểm toán như Modelflare với cùng corpus. Xem thêm định tuyến AI API đáng tin cậy, theo dõi chi phí AI API, giá và trust.
Nguồn và ngày xác minh
Các nguồn sơ cấp sau được kiểm tra vào 2026-08-25. Chúng mô tả hợp đồng của provider và chính sách công khai hiện tại của Modelflare, nhưng không chứng minh hit rate phổ quát của một agent bên thứ ba không nêu tên.
- Hướng dẫn OpenAI Prompt Caching
- Giá OpenAI API
- Hướng dẫn Anthropic Prompt Caching
- Chẩn đoán cache Anthropic
- Trạng thái và bảo đảm cache Modelflare
- Giá và điều kiện hiện tại của Modelflare
- Trust và đơn vị vận hành Modelflare
FAQ: Hit rate thấp của bên thứ ba có luôn là gian lận không?
Không. Prompt ngắn, prefix thay đổi, route phân tán, TTL hết hạn hoặc field thiếu có thể là nguyên nhân. Cho đến khi thử nghiệm có kiểm soát tìm ra nguyên nhân, kết luận đúng là “không tái lập được” hoặc “không thể kiểm toán”.
FAQ: Có thể so sánh Claude và GPT bằng một con số không?
Chỉ sau khi chuẩn hóa mẫu số và giữ nguyên field native. Hãy so sánh cùng corpus và cùng pha, không so tổng dashboard trộn lẫn.
FAQ: Có bù thì còn cần prefix ổn định không?
Có. Khoản bù chỉ giới hạn rủi ro tài chính của traffic cache OpenAI đủ điều kiện; nó không làm request không đủ điều kiện trở nên tái sử dụng được và không sửa agent viết lại prefix.