LLM Prompt Caching: Tính khoản tiết kiệm mà không đếm trùng token

Prompt caching có thể giảm chi phí khi bạn gửi lặp lại cùng một chỉ dẫn hoặc ngữ cảnh cho LLM. Mức tiết kiệm phụ thuộc vào số lần cache thực sự trúng, các nhóm tính phí của nhà cung cấp, và tần suất nội dung được cache được dùng lại trước khi hết hạn.

Giá đọc cache thấp chỉ là một phần của phép tính. Lần ghi có thể có giá riêng, token đầu ra vẫn tốn tiền, và tổng input được báo cáo có thể đã bao gồm token được cache. Hướng dẫn này giải thích cách lập một ước tính hữu ích và đối chiếu với nhật ký mức sử dụng. Các ví dụ minh họa dùng mức giá giả định rõ ràng, không phải kết quả đo được từ ứng dụng hay ưu đãi từ nhà cung cấp.

Xác định nhà cung cấp thực sự cache những gì

Prompt caching thường liên quan đến ngữ cảnh đầu vào có thể dùng lại. Đừng nhầm với việc ứng dụng trả về một câu trả lời đã lưu mà không gọi mô hình.

Tài liệu context caching của DeepSeek mô tả việc khớp các đơn vị tiền tố prompt được lưu lại. Tính năng này bật mặc định, nhưng hoạt động theo kiểu cố gắng hết sức. Các yêu cầu trông giống nhau không đảm bảo sẽ trúng cache, và input được cache không có nghĩa là câu trả lời trước đó sẽ được trả về nguyên vẹn.

Với ứng dụng của bạn, hãy phân biệt ba cơ chế:

• Prompt caching của nhà cung cấp: dịch vụ suy luận dùng lại phần xử lý input đủ điều kiện và báo cáo các nhóm mức sử dụng riêng.
• Cache phản hồi ở ứng dụng: ứng dụng của bạn trả về kết quả đã lưu, có thể tránh hẳn một lần gọi mô hình.
• Cache truy xuất hoặc tài liệu: ứng dụng của bạn tránh lặp lại việc trích xuất hoặc truy xuất, nhưng vẫn có thể gửi đoạn văn bản thu được cho mô hình.

Hãy đo riêng từng cơ chế. Nếu không, một thay đổi trong truy xuất tài liệu có thể bị nhầm là ưu đãi suy luận, hoặc một lần trúng cache phản hồi có thể bị tính là trúng cache của nhà cung cấp.

Chia input thành các nhóm không chồng lấn

Hãy bắt đầu từ schema mức sử dụng của endpoint bạn chọn, không phải từ một công thức đoán mò. DeepSeek báo cáo prompt_cache_hit_tokens và prompt_cache_miss_tokens. Các API khác có thể hiển thị trường khác hoặc bảng phân tách lồng nhau.

Nếu một phản hồi báo cáo tổng 10,000 token input, trong đó có 8,000 token được cache, thì phần input chưa cache còn lại là 2,000. Tính phí cả 10,000 theo giá chưa cache rồi cộng thêm 8,000 theo giá đã cache là tính trùng một phần của yêu cầu.

Với dịch vụ có giá trúng và trượt riêng, một ước tính token mô hình cơ bản là:

cost = miss_tokens / 1M × miss_rate + hit_tokens / 1M × hit_rate + output_tokens / 1M × output_rate

Chỉ dùng công thức đó khi nó khớp với định nghĩa của nhà cung cấp. Nếu dịch vụ báo cáo riêng phần tạo cache hoặc lưu trữ cache, hãy đối chiếu các nhóm đó trước khi cộng phí. Giá ghi cache có thể thay thế một nhóm khác hoặc là một khoản phí cộng thêm; bảng giá phải làm rõ sự khác biệt đó.

Hãy ghi đơn vị tiền tệ, đơn vị đo, model ID, nhà cung cấp và ngày bên cạnh phép tính của bạn. Một con số tính theo nghìn token không thể thay nguyên vào công thức tính theo triệu token.

Tính cả lần ghi đầu tiên và vòng đời

Hướng dẫn tính phí suy luận của Kimi phân biệt các lần ghi cache của K3 theo thời gian tồn tại, với hai loại năm phút và một giờ. Phần input trúng cache được tính theo giá trúng cache mà không bị tính thêm phí ghi cache. Đó là quy tắc của nền tảng trực tiếp, không phải bằng chứng rằng một gateway dùng cùng cách hạch toán.

Một câu hỏi hữu ích là một prefix sẽ được dùng lại bao nhiêu lần trong khi mục cache còn hiệu lực. Hãy xét cách tính phí giả định sau cho một prefix một triệu token:

Khoản phí	Giá giả định
Xử lý prefix không dùng cache	$1.00 mỗi lần dùng
Lần ghi cache đầu tiên, thay thế cách tính input thông thường	$1.25
Mỗi lần đọc cache sau đó	$0.10

Năm lần dùng không cache tốn $5.00. Một lần ghi rồi bốn lần đọc tốn $1.65, tiết kiệm 67% cho prefix đó. Nếu chỉ dùng một lần, đường có cache tốn hơn: $1.25 thay vì $1.00.

Giả định rằng lần ghi thay thế cách tính input thông thường là rất quan trọng. Nếu một nhà cung cấp thực tế tính thêm phí ghi, công thức sẽ thay đổi. Những mức giá này chỉ minh họa cách làm; không phải báo giá hiện tại của Kimi hay cheapaimodel.

Với cách tính kiểu thay thế này, hãy so sánh write_cost + (uses − 1) × read_cost với uses × ordinary_cost. Sau đó lặp lại phép tính cho số lần dùng dự kiến trong thời gian tồn tại thực tế. Một lần đọc rẻ không giúp được gì nếu mọi yêu cầu đều đến sau khi mục cache đã hết hạn.

Tính mức tiết kiệm trên toàn bộ yêu cầu

Giảm giá input không giống với mức giảm giá theo phần trăm trên hóa đơn cuối cùng. Giả sử một khối lượng công việc không cache có $10 phí input và $20 phí output. Giả sử 80% input đó trở thành trúng cache, mỗi lần đọc tốn 10% mức giá input thông thường, và không có phí ghi thêm.

Phí input mới là $2 cho các lần trượt cache cộng $0.80 cho các lần trúng cache, tức $2.80. Tổng thành $22.80 thay vì $30: tiết kiệm 24% trên tổng thể, dù mức giá của phần được cache giảm 90%.

Câu trả lời dài, output suy luận, gọi công cụ, thử lại và lưu trữ có thể làm tổng thay đổi thêm. Hãy dùng mức sử dụng được tính phí do endpoint trả về thay vì chỉ đếm câu trả lời cuối cùng nhìn thấy được. Với giá mô hình hiện tại, hãy bắt đầu với so sánh giá, rồi áp dụng cách dùng thực tế của bạn.

Thiết kế một phép đo hữu ích

Thu thập đủ thông tin để so sánh cùng loại với nhau:

• Mô hình và tuyến nhà cung cấp, thời điểm yêu cầu và cấu hình liên quan.
• Tổng input, trúng cache, trượt cache, tạo cache và output ở nơi được báo cáo.
• Các dịch vụ tính phí riêng và khoản phí được ghi nhận của tài khoản.
• Kết quả có đạt tiêu chí chấp nhận của ứng dụng hay không.

Hãy tính tỷ lệ trúng cache theo trọng số token: tổng token trúng cache chia cho tổng token input đủ điều kiện. Lấy trung bình phần trăm theo từng yêu cầu có thể gây nhầm lẫn khi một yêu cầu rất nhỏ và một yêu cầu lớn có cùng trọng số.

Giữ các chỉ dẫn ổn định và ngữ cảnh dùng lại trước khi thay đổi nội dung riêng cho từng tác vụ, nếu cách sắp xếp đó phù hợp với quy tắc prefix mà nhà cung cấp công bố. Đừng sắp xếp lại chỉ dẫn bảo mật hay xóa ngữ cảnh cần thiết chỉ để đạt tỷ lệ khớp cao hơn. Kiểm tra chất lượng đầu ra sau khi thay đổi cấu trúc prompt.

Đối chiếu trước khi mở rộng

So sánh một mẫu nhỏ các bản ghi mức sử dụng với góc nhìn thanh toán của nhà cung cấp. Kiểm tra các hạng mục bị thiếu, làm tròn, khung giá khác nhau, và phí ghi hoặc phí công cụ trước khi cho rằng biên lai sai.

cheapaimodel công bố mức giá input, output và cache-read trên trang bảng giá. Xác nhận quy tắc tính phí ghi và các quy tắc tính phí khác của mô hình áp dụng trước khi coi một tổng phụ ba cột là biên lai đầy đủ. Với những khác biệt riêng của K3, xem hướng dẫn API Kimi.

Kết quả hữu ích là chi phí thấp hơn cho mỗi kết quả được chấp nhận. Chỉ số token đã cache lớn hơn không đủ để chứng minh ứng dụng trở nên rẻ hơn hay hiệu quả hơn.