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: tìm lưu lượng đủ điều kiện, định hình 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 hay độ tin cậy.
Prompt caching là gì?
Prompt caching cho phép nhà cung cấp LLM tái sử dụng phần 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 theo mức giá thông thường, nhà cung cấp có thể áp dụng mức giá cached-input 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 system prompt 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 lại.
- Các ví dụ few-shot được tái sử dụng trong một tác vụ phân loại hoặc trích xuất.
- Ngữ cảnh hội thoại được chia sẻ cho một số hành động tiếp theo có thể xảy ra.
Cách triển khai giữa các nhà cung cấp khác nhau. OpenAI mô tả bộ nhớ đệm tự động cho các tiền tố prompt đủ điều kiện và hiển thị chi tiết token được cache trong API usage. Anthropic hỗ trợ các cache breakpoint rõ ràng và nhiều tùy chọn time-to-live. Google Gemini hỗ trợ context cache rõ ràng với phí lưu trữ, trong khi DeepSeek mô tả context caching tự động dựa trên đĩa với 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 chiết khấu thay vì đo quy trình
Chiết khấu cho token được cache không giống với khoản tiết kiệm ròng. Quy trình cũng có thể tạo ra phí cache-write, phí lưu trữ, thêm yêu cầu, độ phức tạp vận hành, hoặc các suy giảm chất lượng khi các nhóm tối ưu cấu trúc prompt quá mạnh tay.
Hãy đo đúng đơn vị quan trọng:
ROI prompt caching ròng = chi phí đầu vào không cache được tránh - chi phí ghi/lưu trữ cache - chi phí triển khai và vận hành
Đối với 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 đã được xác thực
Điều này ngăn một kết quả gây hiểu lầm, trong đó chi tiêu token giảm nhưng số lần thử lại, đầu ra bị từ chối hoặc khối lượng xem xét của con người 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ì xem caching như một mẹo tính cước riêng lẻ.
Quy trình prompt caching gồm sáu bước
1. Tìm các workload có tái sử dụng tiền tố thực sự
Bắt đầu bằng trace của yêu cầu, không phải trực giác. Nhóm lưu lượng theo quy trình làm việc và ước tính có bao nhiêu token đầu vào vẫn giống hệt nhau từ đầu 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 có kích thước đáng kể so với phần 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 khoảng thời gian cache hiệu lực của nhà cung cấp.
- Thứ tự ổn định: các hướng dẫn hệ thống, công cụ, ví dụ và tài liệu tham khảo xuất hiện theo cùng một thứ tự.
- Số lượng biến thể 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 một tiền tố duy nhất cho mỗi người dùng.
Các quy trình có tiềm năng cao điển hình bao gồm tác nhân lập trình với lược đồ công cụ ổn định, trợ lý hỗ trợ dựa trên một gói tri thức dùng chung, các phiên hỏi đáp tài liệu, trích xuất theo lô với các ví dụ lặp lại, và các tác nhân nghiên cứu nhiều lượt hội thoại.
Các trường hợp kém phù hợp bao gồm các prompt ngắn dùng một lần, các 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 tác vụ 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 nó quan trọng |
|---|---|
| Số yêu cầu mỗi ngày | Xác định khối lượng tái sử dụng |
| Số token đầu vào trung bình | Thiết lập tổng chi phí đầu vào |
| Số token của tiền tố có thể tái sử dụng | Xác định bề mặt có thể cache |
| Số biến thể 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 liệu 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 |
| Độ trễ P50/P95 | Đ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 tiên. 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. Hướng dẫn hệ thống ổn định
2. Chính sách ổn định và các quy tắc an toàn
3. Định nghĩa công cụ ổn định
4. Tài liệu tham khảo 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à các giá trị thời gian chạy
Không đặt dấu thời gian, mã 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 phần đầu của prompt. Chuẩn hóa lược đồ 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 gộ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, các quy tắc ủy quyền, và yêu cầu lưu giữ dữ liệu. Một prompt rẻ hơn không đáng để đánh đổi bằng một lỗi về quyền riêng tư hoặc cách ly.
3. Xác định danh tính cache và chính sách 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ự động quản lý cache.
Một danh tính cache thực tiễn có thể bao gồm:
workflow + prompt_version + tool_schema_version + knowledge_version + model_family
Theo dõi danh tính này trong telemetry. Khi hướng dẫn, hợp đồng công cụ, hoặc dữ liệu tham khảo thay đổi, hãy tăng phiên bản liên quan. Điều đó giúp giải thích được các thay đổi chi phí và ngăn các nhóm nhầm lẫn giữa việc vô hiệu hóa dự kiến với sự cố từ nhà cung cấp.
Thiết lập một khoảng thời gian tái sử dụng dựa trên hành vi của khối lượng công việc và sự hỗ trợ của nhà cung cấp. Một tác tử tương tác có vòng đờ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ể biện minh cho một cache tường minh dài hơn nếu chi phí lưu trữ vẫn thấp hơn chi phí 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à quy trình làm việc.
- Phiên bản prompt và danh tính cache.
- Tổng input, cached/read, cache-write và output tokens khi được hiển thị.
- Trạng thái cache hit hoặc hit suy luận.
- Chi phí ước tính cho input, cache, output và tổng.
- Độ trễ, trạng thái, số lần retry và đường fallback.
- 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 usage do nhà cung cấp báo cáo làm nguồn sự thật cho thanh toán khi có sẵn. 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ố lượng cached-token hoặc hồ sơ thanh toán và gắn nhãn chỉ số là suy luận.
Telemetry của prompt caching thuộc 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 như một tối ưu hóa cache thành công. Danh sách kiểm tra triển khai AI observability AI observability implementation checklist cho thấy cách kết nối chi phí theo từng lần thử với kết quả ứng dụng.
5. Tính toán mức 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
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 đó thêm một biên độ cho miss, invalidation và biến động lưu lượng.
Ví dụ ROI có tính toán
Giả sử một quy trình làm việc có:
- 40.000 yêu cầu mỗi tháng.
- 18.000 tokens đầu vào mỗi yêu cầu.
- Một tiền tố ổn định 12.000 tokens.
- Tỷ lệ cache-hit hiệu dụng 70%.
- Tỷ lệ input không cache là 3 đô la cho mỗi triệu tokens.
- Tỷ lệ input có cache là 0,30 đô la cho mỗi triệu tokens.
- 350 đô la mỗi tháng cho chi phí kỹ thuật và giám sát được khấu hao.
Cached tokens hàng tháng:
40,000 × 12,000 × 70% = 336,000,000 cached input tokens
Mức tiết kiệm gộp:
336 million × ($3.00 - $0.30) / 1 million = $907.20
Mức tiết kiệm ròng hàng tháng:
$907.20 - $350 = $557.20
Nếu quy trình làm việc tạo ra 32.000 tác vụ được chấp nhận, caching đóng góp khoảng 0,017 đô la tiết kiệm cho mỗi tác vụ được chấp nhận. Điều đó có thể đáng kể ở quy mô lớn, nhưng kết quả này 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 được 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 giá đã công bố của bạn và bao gồm cả chi phí ghi cache, lưu trữ, định giá theo khu vực, các cấp dịch vụ và phí cổng (gateway) nếu có.
6. Triển khai với 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 bộ đánh giá và các tiêu chí chấp nhận.
- Thiết lập các đường cơ sở về chi phí, độ trễ và chất lượng khi chưa dùng cache.
- Chỉ tái cấu trúc phần 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.
Giữ các chính sách thử lại và dự phòng tách biệt khỏi logic cache. Một yêu cầu thất bại có thể an toàn để thử lại, không an toàn để phát lại sau khi đã stream một phần, hoặc được phục vụ tốt hơn bởi một mô hình tương đương. Hãy dùng một chiến lược dự phòng mô hình được xác định rõ thay vì coi mọi cache miss hay timeout là cùng một kiểu lỗi.
Bảng điều khiển KPI của 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 ra 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 | Vùng tối ưu hóa có đủ lớn không? |
| Tỷ lệ cache-hit | Yêu cầu cache-read / yêu cầu đủ điều kiện | Việc tái sử dụng có thực sự xảy ra không? |
| Tỷ lệ token được cache | Token đầu vào được cache / tổng số token đầu vào | Bao nhiêu đầu vào được hưởng mức giá thấp hơn? |
| Mức tiết kiệm trên mỗi yêu cầu | Chi phí cơ sở khi chưa dùng cache - chi phí quan sát được | Mỗi yêu cầu có rẻ hơn không? |
| Mức tiết kiệm ròng | Tổng tiết kiệm - chi phí ghi, lưu trữ và vận hành | Dự án có mang lại lợi ích 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ế học sau khi điều chỉnh chất lượng có cải thiện không? |
| Chênh lệch độ trễ P95 | P95 có 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ệ nguyên nhân miss | Các lần miss theo phiên bản, thứ tự, TTL hoặc nhà cung cấp | Kỹ thuật nên sửa gì tiếp theo? |
Tỷ lệ hit cao nhưng mức tiết kiệm thấp có thể xảy ra khi tiền tố lặp lại quá nhỏ. Tỷ lệ hit thấp với một tiền tố lớn vẫn có thể cho thấy một cơ hội giá trị nếu có thể khắc phục sự phân mảnh 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 ở đầu
Dấu 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 phần tiền tố ổn định khi có thể.
Schema của công cụ thay đổi giữa các yêu cầu
Các agent thường dựng lại hoặc sắp xếp lại định nghĩa công cụ một cách động. Chuẩn hóa thứ tự, loại bỏ các công cụ không liên quan và version hóa schema một cách có chủ đích.
Mục cache được ghi nhưng hiếm khi được tái sử dụng
Việc tạo cache một cách rõ ràng có thể tốn kém hơn số tiề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 định danh cache trước khi kéo dài thời gian lưu giữ.
Các nhóm tối ưu token nhưng bỏ qua đầu ra
Token đầu ra, số lần thử lại và việc xem xét của con người có thể chiếm phần lớn tổng chi phí. Hãy tiếp tục đo lường 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 giả định là có thể di chuyển
Bộ nhớ đệm 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 mô hình đủ đ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 bộ điều hợp cho nhà cung cấp và giữ chỉ số kinh doanh trung lập với nhà cung cấp.
Phương án dự phòng làm mất tính cục bộ của cache
Chuyển đổi nhà cung cấp hoặc họ mô hình 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 phương án dự phòng. 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, rồi ghi nhận đúng lượt bỏ lỡ và chi phí tăng thêm.
Danh sách kiểm tra triển khai của nhà cung cấp
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à điểm cuối API nào hỗ trợ?
- Áp dụng độ dài prompt tối thiểu nào?
- Định nghĩa một tiền tố khớp như thế nào?
- Có những tùy chọn TTL hoặc lưu giữ nào?
- Việc ghi cache, đọc cache và lưu trữ có được đị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ác thiết lập service tier, khu vực, cư trú dữ liệu hoặc không lưu giữ có làm thay đổi hành vi không?
- Cache có bị 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 sử dụng hướng dẫn prompt caching của OpenAI, tài liệu prompt caching của Anthropic, hướng dẫn context caching của Google Gemini, và hướng dẫn context caching của DeepSeek để nắm các 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.
Gateway AI phù hợp ở đâu
Một AI gateway hợp nhất không làm cho cache của các 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 mình. Tuy nhiên, một gateway có thể giúp các đội có một nơi để chuẩn hóa định danh mô hình, định tuyến khối lượng công việc đủ điều kiện, ghi nhận việ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 điểm cuối 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 việc đánh giá các quy trình có cache và không có cache dễ dàng hơn mà không cần xây dựng lại mọi tích hợp. Hãy xác nhận khả năng hỗ trợ caching hiện tại của mô hình được chọn và hành vi của nhà cung cấp 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 client hiện có trước, hãy dùng danh sách kiểm tra di chuyển sang API gateway tương thích OpenAI và xem quyền truy cập mô hình và giá hiện tại của Flatkey.
Các 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, phí ghi hoặc lưu trữ, và chi phí triển khai. Hãy tính mức tiết kiệm ròng từ số token đã được cache quan sát được thay vì áp dụng mức giảm niêm yết cho tất cả token đầu vào.
Tỷ lệ cache-hit nào là tốt?
Không có mục tiêu chung nào áp dụng cho mọi trường hợp. Một tỷ lệ trúng hữu ích là tỷ lệ tạo ra khoản tiết kiệm ròng dương và cải thiện hoặc giữ nguyên chi phí trên mỗi tác vụ được chấp nhận. Các tiền tố lớn có thể chấp nhận tỷ lệ trúng thấp hơn; các 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 lượt trúng cache, nhưng hiệu quả 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ột mức cải thiện cố định.
Tôi có nên cache toàn bộ cuộc hội thoại 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 trao đổi trong cuộc hội thoại sẽ tăng lên và thay đổi. Hãy giữ các chỉ dẫn ổn định, công cụ và nội dung tham chiếu ở phần đầu, sau đó nối phần lịch sử thay đổi và đầu vào của người dùng.
Các prompt đã cache có thể được chia sẻ 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 cho từng nhà cung cấp. Nếu định tuyến làm thay đổi nhà cung cấp hoặc mô hình, hãy xem yêu cầu đó như một lần nhiều khả năng cache miss, trừ khi nhà cung cấp nêu rõ khả năng tái sử dụng tương thích trong tài liệu.
Prompt caching có an toàn cho dữ liệu nhạy cảm không?
Hãy xem xét việc xử lý dữ liệu, tách biệt cache, thời gian lưu giữ, cư trú dữ liệu và các điều khoản zero-retention của nhà cung cấp cho tài khoản và mô hình của bạn. Đừng dùng tối ưu chi phí để обход qua 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 thu hẹp: chọn một khối lượng công việc tốn kém, có mức tái sử dụng cao; đưa nội dung ổn định lên đầu; gắn phiên bản cho nó; đo lượt trúng, lượt trượt, độ 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ẫu đó sang quy trình tiếp theo. Khi không cải thiện, dữ liệu đo lường sẽ cho bạn biết vấn đề là phân mảnh prompt, khối lượng chưa đủ, thời gian lưu giữ ngắn, giá của nhà cung cấp, hay khối lượng công việc vốn dĩ chưa bao giờ là ứng viên phù hợp cho caching.
