Tìm cache miss đằng sau hóa đơn OpenAI

Cập nhật September 26, 2026 · đăng lần đầu September 26, 2026

Bảng điều khiển cache cho bạn biết lượng tái sử dụng đã giảm. Nhưng tự nó không cho biết thay đổi nào trong yêu cầu gây ra việc giảm đó, hay nó tốn bao nhiêu. Bản phát hành ngày 8 tháng 9 năm 2026 của OpenAI đã đưa Prompt Cache Diagnostics ra phổ biến chung trong Responses API cho GPT-5.6 và các mô hình được hỗ trợ sau đó. Việc hữu ích cho FinOps là biến mức giảm số token được cache thành một cuộc điều tra ngắn, có thể lặp lại.

So sánh yêu cầu bị trượt cache

Lưu ID của một phản hồi gần đây, đã hoàn tất, mà bạn kỳ vọng tiền tố sẽ được tái sử dụng. Ở yêu cầu Responses API tương tự tiếp theo từ cùng tổ chức, đặt prompt_cache_options.comparison_response_id thành ID đó. Sau đó đọc prompt_cache_diagnostics trên phản hồi mới, cùng với usage.input_tokens_details.cached_tokens. Tùy chọn so sánh chỉ yêu cầu một chẩn đoán; nó không tải lại cuộc hội thoại trước và cũng không thay đổi hành vi cache. Hướng dẫn chẩn đoán của OpenAI có các ví dụ yêu cầu chạy được.

const next = await client.responses.create({
  model: model,
  instructions: stableInstructions,
  input: nextInput,
  tools: stableTools,
  prompt_cache_options: { comparison_response_id: baseline.id }
});
console.log(next.prompt_cache_diagnostics);
console.log(next.usage.input_tokens_details.cached_tokens);

Đoạn mã trên giả định baseline là một phản hồi gần đây đã hoàn tất, còn các biến khác là dữ liệu yêu cầu của bạn. Hãy giữ tiền tố đủ dài và ổn định để có thể cache: OpenAI ghi nhận mức tối thiểu là 1,024 token cho GPT-5.6 trở lên. Một prompt nhỏ hoặc khác biệt hoàn toàn không phải là phép thử cache miss có ý nghĩa.

Sửa nguyên nhân, không sửa chỉ số

Kết quả cache_miss có thể trỏ tới việc đổi mô hình, tầng dịch vụ, định nghĩa hoặc thứ tự công cụ, khóa cache, định dạng phản hồi, mức nỗ lực suy luận, mức chi tiết (verbosity), hoặc ngữ cảnh đã được nén. Ví dụ, việc đổi tên một schema công cụ trông vô hại cũng có thể làm vô hiệu tiền tố có thể tái sử dụng. Hãy so sánh cấu hình yêu cầu và các byte đầu tiên của prompt, khôi phục tính ổn định ở những chỗ thay đổi là vô ý, rồi chạy lại phép so sánh với cùng baseline. OpenAI báo cáo nguyên nhân đầu tiên mà họ tìm thấy, nên có thể xuất hiện một nguyên nhân khác sau khi bạn sửa cái đầu tiên.

Đừng ép một lần trúng cache nếu thay đổi là có chủ đích. Một mô hình khác có thể làm giảm tổng chi phí tác vụ dù mất tái sử dụng cache; nén ngữ cảnh có thể giảm ngữ cảnh trong tương lai. Hãy đánh giá toàn bộ yêu cầu và tác vụ, không đánh giá riêng tỷ lệ trúng cache. Baseline đã hết hạn hoặc kết quả unavailable là chưa đủ kết luận, không phải bằng chứng rằng cache đã thất bại.

Chuyển phát hiện thành tiền

cache_missed_tokens ước tính số token có thể tái sử dụng đã bị mất so với phản hồi so sánh. Đây không phải là số token được tính phí. Kết quả cache_hit tương tự cũng không chứng minh được khoản tiết kiệm bằng đô la. Để có chi phí đầu vào thực tế, hãy thu thập tổng input_tokens, cached_tokens và cache_write_tokens của từng phản hồi, rồi áp dụng đơn giá hiện hành của mô hình và tầng xử lý đó. Với GPT-5.6 trở lên, hướng dẫn prompt caching của OpenAI nêu rằng đọc cache có giá bằng 0.1 lần đơn giá đầu vào chưa cache, còn ghi cache có giá bằng 1.25 lần đơn giá đó.

ordinary = input_tokens - cached_tokens - cache_write_tokens
weighted_input = ordinary + 0.1 * cached_tokens + 1.25 * cache_write_tokens
input_cost = weighted_input * input_price_per_million / 1_000_000

Đây là các loại token loại trừ lẫn nhau: đừng cộng thêm phụ phí ghi cache cho những token đã được tính ở đơn giá ghi. Công thức này chỉ bao gồm đầu vào; khi tính chi phí cho mỗi tác vụ hoàn thành thành công, hãy thêm đầu ra, công cụ, các lần thử lại và các khoản phí khác. Hãy dùng bảng giá hiện hành của nhà cung cấp thay vì giá cố định trong bài viết.

Một kiểm tra hằng tuần hữu ích

1. Nhóm lưu lượng có thể so sánh theo khối lượng công việc, mô hình và tầng dịch vụ; vẽ biểu đồ tỷ lệ token được cache và chi phí đầu vào cho mỗi tác vụ hoàn thành.
2. Lấy mẫu những đợt suy giảm đột ngột, so với baseline gần đây, và ghi lại lý do chẩn đoán cùng thay đổi mã có người phụ trách.
3. Sửa sai lệch vô ý ở tiền tố hoặc cấu hình; giữ các thay đổi có chủ đích về chất lượng hoặc định tuyến nếu kinh tế tổng thể của tác vụ được cải thiện.
4. Xác nhận kết quả trên lưu lượng production tiêu biểu và đối chiếu khoản tiết kiệm quan sát được với hóa đơn.

Bản thân chẩn đoán không mất phí tính năng thêm, nhưng các yêu cầu kiểm thử bổ sung vẫn bị tính phí bình thường. Lợi ích không phải là một biểu đồ tỷ lệ trúng đẹp hơn. Đó là lời giải thích có căn cứ về lý do chi phí đầu vào của một khối lượng công việc cụ thể thay đổi, và liệu bản sửa đề xuất có thực sự làm giảm hóa đơn hay không.

Các câu hỏi đội ngũ thường đặt ra

Chẩn đoán cache trúng có chứng minh yêu cầu rẻ hơn không?

Không. Nó chỉ cho biết không phát hiện cache miss nào so với baseline đã chọn. Hãy kiểm tra cached_tokens thực tế và các loại token được tính giá của yêu cầu trước khi khẳng định có tiết kiệm.

Chẩn đoán có thể so sánh hai yêu cầu OpenAI bất kỳ không?

Không. Hãy dùng một baseline gần đây đã hoàn tất từ cùng tổ chức, và chỉ kỳ vọng quy trình này trên các mô hình Responses API từ GPT-5.6 trở lên được hỗ trợ. Bản ghi so sánh có thể hết hạn.

Có nên loại bỏ mọi cache miss không?

Không. Việc chuyển mô hình, đổi tầng dịch vụ hoặc ngữ cảnh đã nén có thể là chủ đích. Hãy so sánh chất lượng, độ trễ và chi phí cho mỗi tác vụ hoàn thành thành công trước khi đảo ngược thay đổi.

Liên quan

• Kinh tế của prompt caching
• Phân bổ chi phí prompt cache
• Chi phí cho mỗi tác vụ thành công

Bạn muốn áp dụng điều này cho hệ thống của mình? Hãy mang theo hóa đơn nhà cung cấp, nhật ký gateway và các quy trình chính; chúng tôi sẽ xác định yếu tố chi phí và hướng tiết kiệm. Đặt lịch kiểm toán miễn phí →

Quay lại finopsllm.com