Prompt caching có thể giảm chi phí và độ trễ của các yêu cầu LLM lặp lại, nhưng chỉ khi quy trình tạo ra các tiền tố ổn định, đủ mức tái sử dụng và hành vi cache-hit chấp nhận được. Bật tính năng này không đồng nghĩa với việc chứng minh được lợi tức đầu tư.
Hướng dẫn này cung cấp cho các nhóm kỹ thuật và FinOps một quy trình prompt caching thực tiễn: xác định lưu lượng đủ điều kiện, tối ưu prompt để tái sử dụng, đo lường các chỉ số cache, tính toán khoản tiết kiệm ròng và triển khai mà không che giấu các suy giảm về chất lượng hoặc độ tin cậy. Nó cũng bao gồm một cuộc kiểm tra trong bảy ngày, biến các trường sử dụng của nhà cung cấp thành quyết định: triển khai, sửa đổi hoặc dừng.
ROI của prompt caching: câu trả lời nhanh
Prompt caching thường đáng để thử khi một quy trình liên tục gửi một tiền tố lớn, giống hệt từng byte, trong khoảng thời gian lưu giữ của nhà cung cấp. Nó không tự động đáng làm chỉ vì một mô hình quảng cáo token được cache với giá chiết khấu.
Hãy dùng bộ lọc ba phần này trước khi thay đổi prompt trong môi trường production:
| Ngưỡng | Điều kiện đạt | Điều kiện dừng |
|---|---|---|
| Tái sử dụng | Cùng một tiền tố được dùng nhiều lần trước khi hết hạn | Hầu hết các tiền tố chỉ dùng một lần hoặc là duy nhất theo từng người dùng |
| Kinh tế | Khoản tiết kiệm từ lượt đọc quan sát được vượt quá chi phí ghi, lưu trữ và vận hành | Cache được tạo ra thường xuyên hơn là được tái sử dụng |
| Kết quả | Chi phí trên mỗi tác vụ được chấp nhận được cải thiện mà không làm suy giảm chất lượng hoặc độ tin cậy | Chi phí token thấp hơn dẫn đến nhiều lần thử lại hơn, đầu ra bị từ chối hoặc fallback không an toàn |
Công thức cốt lõi là:
net_savings = uncached_baseline_cost
- observed_cached_workflow_cost
- incremental_engineering_and_operations_cost
roi_percent = net_savings
/ incremental_engineering_and_operations_cost
× 100
Nếu chi phí triển khai được chia sẻ cho nhiều định danh cache, hãy khấu hao nó theo kỳ đánh giá dự kiến thay vì tính toàn bộ chi phí dự án cho một mục duy nhất.
Điều gì đã thay đổi đối với prompt caching trong năm 2026?
Prompt caching không còn là một cơ chế chiết khấu đồng nhất nữa. Thiết kế của các nhà cung cấp hiện đã khác nhau đủ nhiều để một bảng tính chung chung kiểu "cached tokens rẻ hơn" có thể cho ra câu trả lời sai.
Ví dụ, tài liệu hiện tại của GPT-5.6 từ OpenAI mô tả việc khớp tiền tố tự động, các điều khiển prompt_cache_key và cache_control rõ ràng, cùng với việc tách riêng mức sử dụng cache-read và cache-write. Các lần ghi cache cho mô hình này có thể đi kèm phí cao hơn, vì vậy phép tính điểm hòa vốn phải bao gồm chi phí tạo hoặc mở rộng cache—not chỉ các lượt đọc được giảm giá. OpenAI cũng hiển thị chi tiết token cached, uncached và cache-write trong các trường usage cho các yêu cầu được hỗ trợ.
Anthropic sử dụng các điểm ngắt cache rõ ràng và các lựa chọn thời gian sống (TTL). Context caching rõ ràng của Gemini có thể phát sinh phí lưu trữ. DeepSeek mô tả context caching tự động với tỷ lệ hit và miss riêng biệt. Tất cả các thiết kế này đều có thể tạo ra tiết kiệm, nhưng chúng cần telemetry và công thức khác nhau.
Prompt caching là gì?
Prompt caching cho phép nhà cung cấp LLM tái sử dụng tính toán cho nội dung prompt mà họ vừa xử lý gần đây. Thay vì tính phí và xử lý mọi token đầu vào lặp lại ở mức giá thông thường, nhà cung cấp có thể áp dụng mức giá đầu vào được cache thấp hơn hoặc một mức giá cache-read riêng cho phần có thể tái sử dụng.
Nội dung có thể tái sử dụng thường là một tiền tố prompt ổn định. Các ví dụ phổ biến bao gồm:
- Một prompt hệ thống dài và khối chính sách.
- Định nghĩa công cụ được chia sẻ bởi mọi lượt của agent.
- Một tài liệu lớn, sơ đồ kho mã nguồn, hoặc danh mục sản phẩm được truy vấn lặp đi lặp lại.
- Các ví dụ few-shot được tái sử dụng trong một công việc phân loại hoặc trích xuất.
- Lịch sử hội thoại được chia sẻ bởi nhiều hành động tiếp theo có thể xảy ra.
Cách triển khai của từng nhà cung cấp khác nhau. OpenAI mô tả cơ chế lưu đệm tự động cho các tiền tố prompt đủ điều kiện và hiển thị chi tiết token được lưu đệm trong phần sử dụng API; các mô hình mới hơn được hỗ trợ cũng có thể hiển thị chi tiết ghi cache. Anthropic hỗ trợ các điểm ngắt cache rõ ràng và nhiều tùy chọn thời gian sống (TTL). Google Gemini hỗ trợ các context cache rõ ràng với phí lưu trữ, trong khi DeepSeek mô tả lưu đệm ngữ cảnh tự động dựa trên đĩa với các mức giá đầu vào riêng cho cache-hit và cache-miss. Luôn xác nhận hỗ trợ mô hình hiện tại và giá cả trong tài liệu chính thức của nhà cung cấp trước khi đưa khoản tiết kiệm vào dự báo.
Sai lầm về ROI: đo mức chiết khấu thay vì quy trình
Chiết khấu trên token được cache không giống với tiết kiệm ròng. Quy trình cũng có thể phát sinh phí ghi cache, phí lưu trữ, thêm yêu cầu, độ phức tạp vận hành, hoặc suy giảm chất lượng khi các nhóm tối ưu cấu trúc prompt quá mức.
Hãy đo đơn vị thực sự quan trọng:
ROI ròng của prompt caching = chi phí đầu vào không được cache đã tránh - chi phí ghi/lưu trữ cache - chi phí triển khai và vận hành
Đối với các quyết định sản xuất, hãy liên kết kết quả đó với một đầu ra đã được chấp nhận:
Chi phí trên mỗi tác vụ được chấp nhận = tổng chi phí yêu cầu / số tác vụ thành công đã xác thực
Điều này ngăn một kết quả gây hiểu lầm, nơi chi tiêu token giảm nhưng số lần thử lại, đầu ra bị từ chối, hoặc rà soát thủ công lại tăng. Nó cũng giúp prompt caching phù hợp với một chương trình tối ưu chi phí API AI rộng hơn thay vì coi caching như một mẹo thanh toán tách biệt.
Quy trình prompt caching gồm sáu bước
1. Tìm các khối lượng công việc có tái sử dụng tiền tố thực sự
Bắt đầu từ dấu vết yêu cầu, không phải trực giác. Nhóm lưu lượng theo quy trình và ước tính có bao nhiêu token đầu vào vẫn giống hệt nhau từ đầu của một yêu cầu đến yêu cầu tiếp theo.
Các ứng viên tốt thường có bốn đặc điểm:
- Đầu vào lặp lại lớn: tiền tố có thể tái sử dụng đủ đáng kể so với hậu tố động.
- Tái sử dụng thường xuyên: nhiều yêu cầu tham chiếu cùng một tiền tố trong thời gian sống cache hiệu lực của nhà cung cấp.
- Thứ tự ổn định: hướng dẫn hệ thống, công cụ, ví dụ và tài liệu tham chiếu xuất hiện theo cùng một thứ tự.
- Độ đa dạng thấp: ứng dụng tái sử dụng một số lượng biến thể prompt có thể quản lý được thay vì tạo tiền tố duy nhất cho mỗi người dùng.
Các quy trình thường có tiềm năng cao bao gồm agent lập trình với lược đồ công cụ ổn định, trợ lý hỗ trợ được neo bởi một gói tri thức chung, các phiên hỏi đáp tài liệu, trích xuất hàng loạt với ví dụ lặp lại, và các agent nghiên cứu nhiều lượt.
Các ứng viên kém bao gồm prompt ngắn dùng một lần, tiền tố được cá nhân hóa cao, các yêu cầu thay đổi định nghĩa công cụ ở mọi lần gọi, và các công việc khối lượng thấp hiếm khi tái sử dụng một mục cache.
Xây dựng một bảng cơ sở cho từng quy trình:
| Chỉ số | Vì sao quan trọng |
|---|---|
| Số yêu cầu mỗi ngày | Quyết định khối lượng tái sử dụng |
| Số token đầu vào trung bình | Xác định tổng chi phí đầu vào |
| Số token tiền tố có thể tái sử dụng | Định nghĩa bề mặt có thể lưu vào cache |
| Các biến thể của tiền tố | Cho thấy mức độ phân mảnh |
| Khoảng thời gian tái sử dụng | Kiểm tra xem các mục còn hữu ích hay không |
| Tỷ lệ tác vụ được chấp nhận | Bảo vệ chất lượng và giá trị kinh doanh |
| P50/P95 độ trễ | Đo tác động đến hiệu năng |
2. Đặt nội dung tĩnh trước nội dung động
Prompt caching thường phụ thuộc vào việc khớp prompt từ phần đầu. Một khác biệt nhỏ ở gần đầu có thể ngăn tái sử dụng cho toàn bộ phần phía sau.
Hãy dùng thứ tự này khi nhà cung cấp và SDK cho phép:
1. Chỉ dẫn hệ thống ổn định
2. Chính sách ổn định và quy tắc an toàn
3. Định nghĩa công cụ ổn định
4. Tài liệu tham chiếu hoặc ví dụ ổn định
5. Ngữ cảnh hội thoại bán ổn định
6. Đầu vào người dùng động và giá trị lúc chạy
Không đặt dấu thời gian, ID yêu cầu, nhãn dành riêng cho người dùng, JSON sắp xếp ngẫu nhiên, hoặc các cờ tính năng thay đổi thường xuyên ở gần đầu prompt. Hãy chuẩn hóa schema công cụ và tuần tự hóa nội dung có cấu trúc một cách xác định.
Điều này không có nghĩa là được phép kết hợp dữ liệu không liên quan vào một tiền tố quá lớn. Hãy giữ nguyên ranh giới tenant, quy tắc ủy quyền, và các yêu cầu về lưu giữ dữ liệu. Một prompt rẻ hơn không đáng để đánh đổi bằng lỗi về quyền riêng tư hoặc cách ly dữ liệu.
3. Xác định chính sách nhận dạng cache và vô hiệu hóa
Ứng dụng của bạn cần một cách rõ ràng để suy luận về các phiên bản prompt, ngay cả khi nhà cung cấp tự quản lý cache.
Một nhận dạng cache thực tế có thể bao gồm:
workflow + prompt_version + tool_schema_version + knowledge_version + model_family
Theo dõi nhận dạng này trong telemetry. Khi chỉ dẫn, hợp đồng công cụ, hoặc dữ liệu tham chiếu thay đổi, hãy tăng phiên bản liên quan. Điều đó làm cho các thay đổi chi phí trở nên dễ giải thích và ngăn các nhóm nhầm lẫn việc vô hiệu hóa dự kiến với sự cố từ nhà cung cấp.
Đặt một cửa sổ tái sử dụng dựa trên hành vi tải công việc và mức hỗ trợ của nhà cung cấp. Một tác nhân tương tác tồn tại ngắn có thể hưởng lợi từ việc tái sử dụng trong vài phút. Một quy trình nghiên cứu lặp lại có thể xứng đáng với cache tường minh lâu hơn nếu chi phí lưu trữ vẫn thấp hơn việc xử lý đầu vào lặp lại.
4. Ghi nhận hits, misses, writes và các kết quả được chấp nhận
Tối thiểu, hãy ghi lại các trường sau cho mỗi lần thử:
- Nhà cung cấp, mô hình và workflow.
- Phiên bản prompt và nhận dạng cache.
- Tổng số token đầu vào, cached/read, cache-write và đầu ra khi được cung cấp.
- Trạng thái cache hit hoặc hit suy luận.
- Chi phí ước tính cho đầu vào, cache, đầu ra và tổng.
- Độ trễ, trạng thái, số lần thử lại và đường dự phòng.
- Kết quả thành công đã được xác thực hoặc tác vụ được chấp nhận.
Sử dụng các trường mức sử dụng do nhà cung cấp báo cáo làm nguồn sự thật cho tính cước khi có thể. Nếu một nhà cung cấp không trả về cờ cache-hit rõ ràng, hãy suy luận cẩn thận từ số token đã cache hoặc hồ sơ thanh toán và gắn nhãn chỉ số là suy luận.
Telemetry của prompt caching nên nằm trong cùng một trace với retry và model fallback. Nếu không, một cơn bão retry có thể trông giống như một tối ưu hóa cache thành công. Danh sách kiểm tra triển khai AI observability cho thấy cách kết nối chi phí theo từng lần thử với kết quả của ứng dụng.
5. Tính khoản tiết kiệm và khối lượng hòa vốn
Hãy sử dụng một mô hình phù hợp với cấu trúc tính phí của nhà cung cấp.
Đối với caching tự động với mức giá đọc được giảm:
gross_savings = cache_read_tokens × (uncached_input_rate - cached_input_rate)
net_savings = gross_savings - incremental_operating_cost
Đối với caching tường minh với phí ghi và lưu trữ:
net_savings = avoided_uncached_cost
- cache_write_cost
- cache_storage_cost
- incremental_operating_cost
Đối với nhà cung cấp hoặc mô hình tính các mức token khác nhau cho lượt ghi và lượt đọc cache, hãy tính vòng đời của một tiền tố có thể tái sử dụng:
uncached_scenario = prefix_tokens × total_uses × uncached_rate
cached_scenario = prefix_tokens × cache_writes × write_rate
+ prefix_tokens × cache_reads × read_rate
+ storage_cost
prefix_net_savings = uncached_scenario - cached_scenario
Đừng giả định cache_writes = 1. Một tiền tố bị thay đổi, mục hết hạn, thay đổi định tuyến hoặc làm mới tường minh có thể tạo ra thêm một lượt ghi nữa.
Bạn có thể ước tính số lần tái sử dụng hòa vốn cho một tiền tố đã cache:
break_even_reuses =
(cache_write_cost + storage_cost + implementation_cost_per_entry)
/ savings_per_cache_read
Làm tròn lên đến lần tái sử dụng nguyên tiếp theo. Sau đó cộng thêm một biên cho các lần miss, các lần vô hiệu hóa và biến động lưu lượng.
Ví dụ ROI minh họa
Giả sử một quy trình có:
- 40.000 yêu cầu mỗi tháng.
- 18.000 token đầu vào cho mỗi yêu cầu.
- Một tiền tố ổn định dài 12.000 token.
- Tỷ lệ cache-hit hiệu dụng 70%.
- Tỷ lệ đầu vào không cache là 3 đô la mỗi triệu token.
- Tỷ lệ đầu vào cache là 0,30 đô la mỗi triệu token.
- 350 đô la mỗi tháng cho chi phí kỹ thuật và giám sát đã được phân bổ.
Token được cache hàng tháng:
40,000 × 12,000 × 70% = 336,000,000 cached input tokens
Khoản tiết kiệm gộp:
336 million × ($3.00 - $0.30) / 1 million = $907.20
Tiết kiệm ròng hàng tháng:
$907.20 - $350 = $557.20
Nếu quy trình tạo ra 32.000 tác vụ được chấp nhận, caching đóng góp khoảng 0,017 đô la tiền tiết kiệm cho mỗi tác vụ được chấp nhận. Con số này có thể có ý nghĩa ở quy mô lớn, nhưng kết quả khiêm tốn hơn nhiều so với việc chỉ nêu một mức chiết khấu 90% cho input đã cache.
Các mức giá ở trên chỉ mang tính minh họa, không phải báo giá hiện tại từ nhà cung cấp. Hãy thay chúng bằng mức giá theo hợp đồng hoặc đã công bố của bạn và bao gồm phí ghi cache, lưu trữ, định giá theo khu vực, các gói dịch vụ và phí gateway nếu có áp dụng.
Phiếu tính ROI prompt caching có thể sao chép
Hãy xây dựng phiếu tính ở cấp workflow và phiên bản prompt. Tỷ lệ cache-hit gộp ở cấp tài khoản có thể che khuất một cache có lợi nhuận và nhiều cache lãng phí.
| Đầu vào | Ký hiệu | Câu hỏi ví dụ |
|---|---|---|
| Các yêu cầu đủ điều kiện | R |
Có bao nhiêu yêu cầu có thể tái sử dụng tiền tố này? |
| Token của tiền tố | P |
Có bao nhiêu token đầu tiên là ổn định? |
| Lượt đọc cache | H |
Có bao nhiêu yêu cầu đủ điều kiện thực sự đọc token đã được lưu trong cache? |
| Lượt ghi cache | W |
Tiền tố đã được tạo hoặc mở rộng bao nhiêu lần? |
| Tỷ lệ đầu vào không được cache | U |
Các token này sẽ tốn bao nhiêu nếu không có cache? |
| Tỷ lệ đọc cache | C |
Nhà cung cấp tính phí bao nhiêu cho một lượt hit? |
| Tỷ lệ ghi cache | CW |
Việc tạo mới được tính theo giá đầu vào tiêu chuẩn hay có phụ phí? |
| Chi phí lưu trữ | S |
Việc giữ lại được tính phí theo token-giờ hay đơn vị khác? |
| Chi phí vận hành | O |
Chi phí giám sát và bảo trì nào được quy cho quy trình này? |
| Các tác vụ được chấp nhận | A |
Có bao nhiêu đầu ra đã vượt qua kiểm tra chấp nhận của môi trường sản xuất? |
Hãy dùng các công thức sau:
eligible_prefix_tokens = R × P
observed_cached_tokens = H × P
baseline_prefix_cost = eligible_prefix_tokens × U
observed_prefix_cost = (H × P × C)
+ (W × P × CW)
+ S
net_savings = baseline_prefix_cost - observed_prefix_cost - O
net_savings_per_accepted_task = net_savings / A
Sử dụng các đơn vị tỷ lệ nhất quán, chẳng hạn như đô la trên token hoặc đô la trên một triệu token. Nếu chỉ một phần của tiền tố được báo cáo là đã được cache, hãy thay H × P bằng tổng token đã cache do nhà cung cấp báo cáo.
Mẹo hòa vốn cho một lần ghi cache
Khi có một lần ghi ban đầu, không có phí lưu trữ riêng và mọi lần sử dụng sau đều là hit:
break_even_reads = (write_rate - uncached_rate)
/ (uncached_rate - read_rate)
Làm tròn lên đến lượt đọc nguyên tiếp theo. Nếu tỷ lệ ghi bằng tỷ lệ đầu vào không cache thông thường, lần tái sử dụng thành công đầu tiên sẽ tạo ra tiết kiệm gộp. Nếu các lần ghi có phụ phí, sẽ cần thêm lượt đọc. Điểm hòa vốn thực tế trong sản xuất sẽ cao hơn sau các lượt miss, việc vô hiệu hóa, lưu trữ và chi phí kỹ thuật.
6. Triển khai bằng một thí nghiệm có kiểm soát
Triển khai caching như một thay đổi kỹ thuật với một nhóm đối chứng có thể đo lường.
- Chọn một quy trình có khả năng tái sử dụng cao.
- Cố định tập đánh giá và tiêu chí chấp nhận.
- Thiết lập các mốc cơ sở về chi phí, độ trễ và chất lượng khi không dùng cache.
- Chỉ tái cấu trúc tiền tố ổn định.
- Gửi một phần nhỏ lưu lượng sản xuất qua đường dẫn có cache.
- So sánh tỷ lệ hit, chi phí trên mỗi tác vụ được chấp nhận, độ trễ P95, lỗi và cơ chế dự phòng.
- Chỉ mở rộng khi mức tiết kiệm vẫn dương sau chi phí vận hành.
Chạy nhóm đối chứng và nhóm xử lý trên lưu lượng tương đương. Giữ cố định model, gói dịch vụ, đầu ra tối đa, cài đặt lấy mẫu, bộ công cụ và chính sách dự phòng khi có thể. Nếu không, một thay đổi về model hoặc định tuyến có thể bị nhầm là lợi ích từ cache.
Trước khi triển khai rộng rãi, hãy thực hiện ba bài kiểm tra vô hiệu hóa có chủ đích:
- Thay đổi phiên bản prompt và xác nhận cache cũ không bị quy sai cho quy trình mới.
- Thay đổi hoặc sắp xếp lại schema của công cụ và xác minh rằng lần miss tạo ra hiển thị trong telemetry.
- Kích hoạt đường fallback đã được phê duyệt và xác nhận rằng việc mất cache cùng chi phí tăng thêm được quy cho lần thử fallback.
Hãy tách riêng chính sách retry và fallback khỏi logic cache. Một request thất bại có thể an toàn để thử lại, không an toàn để phát lại sau khi streaming một phần, hoặc nên được xử lý tốt hơn bằng một model tương đương. Hãy dùng một chiến lược fallback model được xác định rõ thay vì coi mọi lần miss cache hoặc timeout là cùng một dạng lỗi.
Kiểm toán ROI của prompt caching trong bảy ngày
Một cuộc kiểm toán ngắn trên production đáng tin cậy hơn một dự báo được xây từ mức giảm giá cache được quảng cáo. Mục tiêu không phải là chứng minh rằng caching hoạt động nói chung. Mục tiêu là xác định liệu một workflow, phiên bản prompt, tuyến model và chính sách lưu giữ cụ thể có tạo ra giá trị lặp lại được hay không.
Tạo một dòng kiểm toán cho mỗi ngày và giữ nhóm đối chứng không dùng cache chạy xuyên suốt bài kiểm tra. Nếu lưu lượng ngày thường và cuối tuần khác nhau, hãy kéo dài bài kiểm tra cho đến khi cả hai kiểu mẫu đều xuất hiện. Đừng so sánh một ngày treatment bận rộn với một baseline lịch sử yên ắng.
| Ngày | Hành động | Bằng chứng cần thu thập | Câu hỏi quyết định |
|---|---|---|---|
| 0 | Khóa thử nghiệm | ID workflow, phiên bản prompt, model, tuyến provider, chính sách fallback, bài kiểm tra chấp nhận | Người khác có thể tái tạo lại thiết lập này không? |
| 1 | Đo nhóm đối chứng | Số request, input token, output token, chi phí, độ trễ P50/P95, tác vụ được chấp nhận | Workflow tốn bao nhiêu nếu không có caching? |
| 2 | Bật treatment giới hạn | Lần ghi cache, lần đọc, lần miss, chế độ lưu giữ, tỷ lệ lỗi | Các trường usage có đầy đủ và được phân tích đúng không? |
| 3 | Chẩn đoán tính cục bộ | Độ phân biệt prefix, danh tính cache, lý do miss, các phiên bản tool-schema | Miss là do mức tái sử dụng thấp hay do phân mảnh triển khai? |
| 4 | Kiểm tra vô hiệu hóa | Thay đổi phiên bản prompt, thay đổi công cụ, hết hạn lưu giữ | Telemetry có phân biệt được vô hiệu hóa có chủ ý với các lần miss không rõ nguyên nhân không? |
| 5 | Kiểm tra độ tin cậy | Retry và các kịch bản fallback đã được phê duyệt | Trong lúc lỗi, bao nhiêu tính cục bộ của cache bị mất? |
| 6 | Đối soát kinh tế | Chi phí baseline, chi phí quan sát được, chi phí ghi/lưu trữ, chi phí vận hành | Tiết kiệm ròng có dương sau mọi khoản phí liên quan không? |
| 7 | Ra quyết định | Tiết kiệm đã điều chỉnh theo chất lượng, khoảng tin cậy, người phụ trách, ngày rà soát tiếp theo | Nhóm nên mở rộng, sửa hay dừng? |
Hãy dùng các cohort được ghép cặp, không dùng trung bình trên toàn account
Phân công các request tương đương vào nhóm đối chứng và treatment bằng một quy tắc ổn định như hash của workflow ID cộng tenant ID. Điều này giúp giảm khả năng rằng thành phần khách hàng, độ dài prompt, hoặc độ khó tác vụ là nguyên nhân giải thích kết quả. Không loại trừ cả lỗi lẫn retry khỏi tổng chi phí; chúng là một phần của kinh tế production.
Tối thiểu, hãy phân đoạn kiểm toán theo:
- Luồng công việc và phiên bản prompt.
- Model và tuyến nhà cung cấp.
- Chế độ lưu giữ cache hoặc TTL.
- Hạng khách hàng khi các prompt khác nhau đáng kể.
- Kết quả thành công, thử lại, fallback và đầu ra bị từ chối.
Tỷ lệ cache-hit trên toàn tài khoản hữu ích cho việc giám sát nhưng yếu khi dùng để ra quyết định đầu tư. Một luồng công việc có lưu lượng cao có thể che khuất hàng chục danh tính cache liên tục được ghi vào và hiếm khi được đọc.
Thêm kiểm tra độ tin cậy và phương sai
Đừng coi một ngày tiết kiệm dương là tín hiệu triển khai. Hãy tính tiết kiệm ròng hằng ngày và xem xét biên độ, không chỉ tổng.
daily_net_savings = daily_uncached_baseline_cost
- daily_observed_cached_cost
- daily_operating_cost
quality_adjusted_savings = daily_net_savings
/ daily_accepted_tasks
Hãy dùng mức tiết kiệm ròng điều chỉnh theo chất lượng trung vị hằng ngày làm bản tóm tắt chính, sau đó báo cáo ngày tệ nhất và tỷ lệ số ngày vẫn dương. Một luồng công việc có mức tiết kiệm trung bình mạnh nhưng lặp lại nhiều ngày âm có thể nhạy với hình dạng lưu lượng, thời điểm hết hạn hoặc hành vi fallback.
Nếu lưu lượng thấp, hãy xác định số lượng quan sát tối thiểu trước khi bắt đầu kiểm toán. Một quy tắc thực tế là chờ đến khi mỗi cohort có đủ số tác vụ được chấp nhận để bao gồm các lần thử lại bình thường, các lượt miss và ít nhất một chu kỳ hết hạn lưu giữ. Con số chính xác phụ thuộc vào phương sai của luồng công việc; tránh đưa ra một kích thước mẫu phổ quát như thể có giá trị thống kê cho mọi ứng dụng.
Rubric Go, fix, hoặc stop
| Quyết định | Bằng chứng cần có | Hành động tiếp theo |
|---|---|---|
| Go | Tiết kiệm ròng dương trong hầu hết các ngày được đo; chi phí trên mỗi tác vụ được chấp nhận được cải thiện; chất lượng, lỗi và độ trễ P95 vẫn nằm trong các ngưỡng an toàn đã phê duyệt | Mở rộng lưu lượng dần dần và lên lịch rà soát sau 30 ngày |
| Fix | Có tiết kiệm gộp, nhưng việc ghi, phân mảnh prefix, hết hạn hoặc mất cache do fallback làm kết quả không ổn định | Khắc phục nguyên nhân đã xác định và chạy lại cùng một cuộc kiểm toán |
| Stop | Tiết kiệm ròng vẫn âm, chi phí trên tác vụ được chấp nhận xấu đi, hoặc luồng công việc không thể đáp ứng các ngưỡng an toàn về chất lượng, bảo mật hay độ tin cậy | Loại bỏ caching cho luồng công việc này và lưu giữ bằng chứng |
Hãy thiết lập các quy tắc dừng lỗ trước khi ra mắt. Ví dụ gồm mức tăng không chấp nhận được của các đầu ra bị từ chối, hồi quy tỷ lệ lỗi, mức tăng đáng kể của độ trễ P95, danh tính cache xuyên tenant bất ngờ, hoặc mức tăng chi tiêu hằng ngày vượt ngưỡng chịu đựng ngân sách của nhóm. Các ngưỡng dừng lỗ nên xuất phát từ các mục tiêu dịch vụ và chính sách rủi ro hiện có của sản phẩm, không phải từ một benchmark blog chung chung.
Bản ghi kiểm toán cần lưu
Lưu quyết định cuối cùng bên cạnh cấu hình prompt và routing, không phải trong một bảng tính rời rạc. Một bản ghi kiểm toán hữu ích bao gồm chủ sở hữu, ngày thử nghiệm, hash prompt, hash lược đồ công cụ, tuyến model, các mức giá đã dùng, ánh xạ trường sử dụng thô, định nghĩa tác vụ được chấp nhận, các loại trừ, tiết kiệm ròng, kết quả ngưỡng an toàn, quyết định và ngày rà soát tiếp theo.
Bản ghi này đặc biệt quan trọng khi giá cả, phiên bản model, hành vi lưu giữ hoặc các tuyến fallback thay đổi. Hãy xem xét lại quyết định khi bất kỳ giả định nào ảnh hưởng đáng kể đến việc ghi, đọc, lưu trữ hoặc các kết quả được chấp nhận thay đổi.
Bảng điều khiển KPI prompt caching
Theo dõi các chỉ số sau theo quy trình và phiên bản prompt:
| KPI | Công thức hoặc định nghĩa | Tín hiệu quyết định |
|---|---|---|
| Tỷ lệ token có thể cache | Token tiền tố có thể tái sử dụng / tổng số token đầu vào | Diện tối ưu hóa có đủ lớn không? |
| Tỷ lệ hit cache | Yêu cầu đọc cache / yêu cầu đủ điều kiện | Việc tái sử dụng có thực sự đang diễn ra không? |
| Tỷ lệ token đã cache | Token đầu vào đã cache / tổng số token đầu vào | Bao nhiêu đầu vào được hưởng mức giá thấp hơn? |
| Tiết kiệm trên mỗi yêu cầu | Chi phí cơ sở chưa cache - chi phí quan sát được | Mỗi yêu cầu có rẻ hơn không? |
| Tiết kiệm ròng | Tiết kiệm gộp - chi phí ghi, lưu trữ và vận hành | Dự án có dương về tài chính không? |
| Chi phí trên mỗi tác vụ được chấp nhận | Tổng chi phí / số tác vụ được chấp nhận | Kinh tế sau điều chỉnh chất lượng có cải thiện không? |
| Chênh lệch độ trễ P95 | P95 của cache - P95 cơ sở | Hiệu năng mà người dùng nhìn thấy có cải thiện không? |
| Tỷ lệ lý do miss | Các lần miss theo phiên bản, thứ tự, TTL hoặc nhà cung cấp | Bộ phận kỹ thuật nên khắc phục gì tiếp theo? |
| Tỷ lệ ghi/đọc cache | Số lần ghi cache / số lần đọc cache | Các mục có đang được tạo quá thường xuyên không? |
| Cardinality của tiền tố | Danh tính cache khác biệt / yêu cầu đủ điều kiện | Cá nhân hóa có đang làm phân mảnh khả năng tái sử dụng không? |
| Tỷ lệ mất cache khi fallback | Các lần thử fallback làm mất tái sử dụng cache kỳ vọng / số lần fallback | Chính sách độ tin cậy đang tốn bao nhiêu về tính cục bộ của cache |
Tỷ lệ hit cao nhưng tiết kiệm thấp có thể xảy ra khi tiền tố lặp lại nhỏ. Tỷ lệ hit thấp với tiền tố lớn vẫn có thể chỉ ra một cơ hội giá trị nếu có thể khắc phục sự phân mảnh của prompt. Hãy đọc các chỉ số cùng nhau.
Các chế độ lỗi phổ biến của prompt caching
Các giá trị động ở phần đầu
Tem thời gian, ID và siêu dữ liệu theo từng người dùng ở gần phần đầu sẽ làm phân mảnh cache. Hãy chuyển chúng xuống sau tiền tố ổn định nếu có thể.
Lược đồ công cụ thay đổi giữa các yêu cầu
Các agent thường xây dựng lại hoặc sắp xếp lại định nghĩa công cụ một cách động. Hãy chuẩn hóa thứ tự, loại bỏ các công cụ không liên quan và version hóa lược đồ một cách có chủ đích.
Các mục cache được ghi nhưng hiếm khi được tái sử dụng
Việc tạo cache rõ ràng có thể tốn nhiều hơn số tiền nó tiết kiệm được khi lưu lượng thấp hoặc TTL quá dài. Hãy đo mức tái sử dụng theo từng danh tính cache trước khi kéo dài thời gian lưu giữ.
Các đội tối ưu token nhưng bỏ qua đầu ra
Token đầu ra, các lần thử lại và việc rà soát của con người có thể chiếm phần lớn tổng chi phí. Tiếp tục đo toàn bộ yêu cầu và kết quả được chấp nhận.
Hành vi của nhà cung cấp được cho là có thể di chuyển
Cache tiền tố tự động, điểm ngắt rõ ràng, phí lưu trữ, độ dài prompt tối thiểu, các model đủ điều kiện và các trường sử dụng khác nhau tùy theo nhà cung cấp. Hãy xây dựng một adapter cho nhà cung cấp và giữ chỉ số kinh doanh trung lập với nhà cung cấp.
Fallback phá hủy tính cục bộ của cache
Chuyển đổi nhà cung cấp hoặc họ model có thể loại bỏ khả năng tái sử dụng vì cache không thể di chuyển. Điều này không có nghĩa là nên vô hiệu hóa fallback. Nó có nghĩa là độ tin cậy và chi phí cần một chính sách chung: chuyển sang dự phòng khi cần, sau đó quy trách nhiệm cho lần miss và chi phí tăng thêm một cách chính xác.
Danh sách kiểm tra triển khai của nhà cung cấp
Sử dụng một adapter cho nhà cung cấp thay vì ép mọi triển khai vào một trường boolean cache_hit:
| Mẫu của nhà cung cấp | Các trường ROI cần thu thập | Rủi ro mô hình hóa chính |
|---|---|---|
| Cache tiền tố tự động | Token được cache, token không được cache, chế độ lưu giữ, cache key khi được hỗ trợ | Khác biệt của tiền tố sẽ không thấy được nếu không có trace được phiên bản hóa |
| Điểm ngắt rõ ràng | Token tạo cache, token đọc cache, TTL | Quá nhiều điểm ngắt hoặc ghi có thể xóa sạch khoản tiết kiệm |
| Ngữ cảnh được lưu trữ rõ ràng | Chi phí tạo, số lượng token được cache, thời lượng lưu trữ và phí | Lưu giữ khi nhàn rỗi có thể tốn hơn việc gửi đầu vào lặp lại |
| Định giá hit/miss tự động | Token cache-hit và cache-miss | Định tuyến hoặc thay đổi mô hình sẽ đặt lại tính cục bộ |
Trước khi bật prompt caching cho một mô hình, hãy xác nhận:
- Caching là tự động, rõ ràng, hay cả hai?
- Những mô hình và endpoint API nào hỗ trợ?
- Áp dụng độ dài prompt tối thiểu nào?
- Tiền tố khớp được định nghĩa như thế nào?
- Có những tùy chọn TTL hoặc lưu giữ nào?
- Ghi cache, đọc cache và lưu trữ có được tính giá riêng không?
- Những trường phản hồi nào hiển thị token được cache hoặc việc tạo cache?
- Cấp dịch vụ, khu vực, cư trú dữ liệu, hoặc cài đặt zero-retention có làm thay đổi hành vi không?
- Cache có được cô lập theo dự án, tài khoản, tổ chức hay ranh giới khác không?
- Điều gì xảy ra khi yêu cầu chuyển sang mô hình hoặc nhà cung cấp khác?
Hãy dùng hướng dẫn prompt caching của OpenAI, tài liệu prompt caching của Anthropic, hướng dẫn caching ngữ cảnh của Google Gemini, và hướng dẫn caching ngữ cảnh của DeepSeek để biết chi tiết triển khai hiện tại. Giá và điều kiện đủ điều kiện của mô hình có thể thay đổi, vì vậy hãy kiểm tra lại các nguồn này trong mỗi lần rà soát chi phí quan trọng.
Kiểm tra di chuyển 2026 cho các dashboard caching OpenAI hiện có
Nếu dashboard của bạn được xây dựng trước khi hỗ trợ GPT-5.6, hãy xác minh rằng nó không gộp tất cả token tiền tố không được cache vào chi phí đầu vào thông thường. Với các yêu cầu GPT-5.6 được hỗ trợ, hãy kiểm tra riêng mức sử dụng ghi cache, ghi lại chế độ lưu giữ và phân biệt giữa ghi cache rõ ràng với đọc cache tự động. Một dashboard chỉ theo dõi cached_tokens có thể đánh giá quá cao mức tiết kiệm khi việc tạo cache có mức giá cao hơn.
Vị trí của một AI gateway
Một AI gateway hợp nhất không làm cho cache của nhà cung cấp trở nên di động. Mỗi nhà cung cấp vẫn kiểm soát ngữ nghĩa caching và tính phí của riêng họ. Tuy nhiên, một gateway có thể cung cấp cho các nhóm một nơi để chuẩn hóa định danh mô hình, định tuyến các khối lượng công việc đủ điều kiện, ghi lại mức sử dụng theo từng nhà cung cấp, so sánh chi phí trên mỗi tác vụ được chấp nhận, và thực thi chính sách dự phòng hoặc ngân sách.
Flatkey cung cấp một endpoint tương thích OpenAI và một số dư hợp nhất để truy cập nhiều họ mô hình. Điều đó giúp dễ dàng benchmark các quy trình có cache và không có cache mà không cần xây dựng lại mọi tích hợp. Hãy xác nhận hỗ trợ caching hiện tại và hành vi của nhà cung cấp đối với mô hình đã chọn trước khi coi một tuyến là đã bật cache.
Nếu bạn đang ưu tiên hợp nhất các khách hàng hiện có trước, hãy sử dụng danh sách kiểm tra di chuyển API gateway tương thích OpenAI và xem lại quyền truy cập mô hình và giá hiện tại của Flatkey.
Câu hỏi thường gặp
Prompt caching có thể tiết kiệm bao nhiêu?
Mức tiết kiệm phụ thuộc vào tiền tố có thể tái sử dụng, tỷ lệ hit, giá của nhà cung cấp, chi phí ghi hoặc lưu trữ, và chi phí triển khai. Hãy tính tiết kiệm ròng từ số token đã được cache quan sát được thay vì áp dụng mức giảm giá niêm yết cho tất cả token đầu vào.
Cần bao nhiêu cache hit để hòa vốn?
Điều này phụ thuộc vào phụ phí ghi, chiết khấu đọc, phí lưu trữ và chi phí vận hành. Với lượt ghi bị tính theo mức bình thường khi chưa cache và không có phí lưu trữ, lần đọc thành công đầu tiên sẽ tạo ra tiết kiệm token gộp. Các lượt ghi có phụ phí hoặc chính sách lưu giữ có phí sẽ cần tái sử dụng nhiều hơn. Hãy tính điểm hòa vốn từ các mức giá chính xác và số lần ghi cache quan sát được cho mô hình đã chọn.
Tỷ lệ cache hit nào là tốt?
Không có mục tiêu chung cho mọi trường hợp. Một tỷ lệ hit hữu ích là tỷ lệ tạo ra tiết kiệm ròng dương và cải thiện hoặc duy trì chi phí trên mỗi tác vụ được chấp nhận. Tiền tố lớn có thể chấp nhận tỷ lệ hit thấp hơn; tiền tố nhỏ có thể cần mức tái sử dụng rất cao.
Prompt caching có cải thiện độ trễ không?
Nó có thể giảm độ trễ xử lý đầu vào đối với các cache hit, nhưng tác động phụ thuộc vào nhà cung cấp, mô hình, kích thước prompt, đường truyền mạng và khối lượng công việc. Hãy theo dõi độ trễ P50 và P95 thay vì giả định mức cải thiện cố định.
Tôi có nên cache toàn bộ cuộc trò chuyện không?
Thông thường bạn nên tối đa hóa một tiền tố ổn định, chứ không phải mù quáng cache mọi thứ. Các lượt hội thoại sẽ tăng và thay đổi. Hãy giữ các hướng dẫn ổn định, công cụ và nội dung tham chiếu ở phần đầu, rồi nối tiếp bằng lịch sử thay đổi và đầu vào của người dùng.
Có thể dùng chung prompt đã cache giữa các nhà cung cấp không?
Không. Bộ nhớ đệm prompt phía nhà cung cấp là riêng theo từng nhà cung cấp. Nếu việc định tuyến thay đổi nhà cung cấp hoặc mô hình, hãy coi yêu cầu đó nhiều khả năng là cache miss, trừ khi nhà cung cấp nêu rõ khả năng tái sử dụng tương thích.
Prompt caching có an toàn với dữ liệu nhạy cảm không?
Hãy xem xét cách nhà cung cấp xử lý dữ liệu, cô lập cache, thời hạn lưu giữ, khu vực lưu trú dữ liệu, và các điều khoản zero-retention cho tài khoản và mô hình của bạn. Đừng dùng tối ưu chi phí để né tránh các yêu cầu về bảo mật, quyền riêng tư hoặc cô lập tenant.
Bắt đầu với một tiền tố lặp lại
Quy trình prompt caching tốt nhất là có chủ đích và hẹp: chọn một khối lượng công việc đắt đỏ, tái sử dụng cao; đưa nội dung ổn định lên đầu; quản lý phiên bản; đo hit, miss, độ trễ, chất lượng và chi phí; rồi tính ROI ròng.
Khi kết quả cải thiện chi phí trên mỗi tác vụ được chấp nhận, hãy mở rộng mô hình sang quy trình tiếp theo. Khi không, telemetry sẽ cho bạn biết vấn đề là phân mảnh prompt, khối lượng không đủ, thời gian lưu giữ ngắn, giá của nhà cung cấp, hay một khối lượng công việc vốn chưa bao giờ là ứng viên phù hợp cho caching.
