Nghiên cứu điển hình về cách Claude đạt tỷ lệ cache hit 92%
Mỗi khi một AI agent thực hiện một bước, nó phải trả một khoản "thuế".
Nó đọc lại mọi thứ từ đầu.
Hướng dẫn hệ thống. Định nghĩa công cụ. Ngữ cảnh dự án mà nó đã tải từ ba lượt trước. Tất cả. Mỗi một lượt.
Đó là "thuế ngữ cảnh". Và đối với các quy trình agent kéo dài, đó thường là khoản mục đắt đỏ nhất trong toàn bộ cơ sở hạ tầng AI của bạn.
Đây là phép tính: một prompt hệ thống với 20.000 token chạy qua 50 lượt có nghĩa là 1 triệu token tính toán dư thừa được tính phí đầy đủ, tạo ra giá trị mới bằng không.
Giải pháp là prompt caching. Nhưng để sử dụng nó hiệu quả, bạn cần hiểu những gì thực sự đang diễn ra bên dưới.
Bắt Đầu Với Những Gì Thay Đổi Và Những Gì Không Thay Đổi
Trước khi bạn có thể tối ưu hóa bất cứ điều gì, bạn cần suy nghĩ rõ ràng về cấu trúc prompt (ngữ cảnh) của agent.
Mỗi yêu cầu mà agent của bạn gửi đi có hai phần cơ bản khác nhau:
Phần tiền tố tĩnh: nó bao gồm hướng dẫn hệ thống, định nghĩa công cụ, ngữ cảnh dự án, nguyên tắc hành vi. Nội dung này giống hệt nhau qua mọi lượt của một phiên.
Phần đuôi động: tin nhắn người dùng, đầu ra công cụ, quan sát terminal. Phần này là duy nhất cho mỗi yêu cầu và phát triển khi cuộc trò chuyện tiến triển.
Sự khác biệt này là tất cả. Phần tiền tố tĩnh là phần đắt đỏ mà bạn liên tục tính toán lại mà không có lý do. Phần đuôi động là phần duy nhất thực sự cần tính toán mới.
Prompt caching hoạt động bằng cách lưu trữ trạng thái toán học của phần tiền tố tĩnh để các yêu cầu trong tương lai có thể bỏ qua việc tính toán lại hoàn toàn. Bạn trả phí để xử lý phần tiền tố đó một lần. Mỗi lượt tiếp theo đọc từ bộ nhớ thay vào đó.
Tại Sao Điều Này Hiệu Quả: Những Gì Một Transformer Thực Sự Làm
Để thực sự hiểu tại sao caching lại hiệu quả đến vậy, bạn cần hiểu những gì xảy ra bên trong mô hình khi nó đọc prompt của bạn.
Mọi yêu cầu suy luận LLM đều có hai giai đoạn:
Giai đoạn 1: Prefill
Đây là nơi mô hình xử lý toàn bộ prompt đầu vào của bạn. Nó bị ràng buộc về tính toán, có nghĩa là nó chạy các phép nhân ma trận dày đặc trên mọi token trong ngữ cảnh của bạn. Mô hình đọc mọi thứ và xây dựng một biểu diễn của nó. Đây là giai đoạn chậm và đắt đỏ.
Giai đoạn 2: Decode
Đây là nơi mô hình tạo ra các token đầu ra, từng token một. Nó bị ràng buộc về bộ nhớ hơn là tính toán vì mô hình dành phần lớn thời gian để đọc trạng thái đã tính toán trước đó thay vì chạy các phép tính nặng.
Trong giai đoạn prefill, transformer xây dựng ba vector cho mỗi token: Query, Key và Value. Cơ chế attention sử dụng chúng để tìm ra cách mỗi token liên quan đến mọi token khác trong chuỗi.
Đây là insight quan trọng: các vector Key và Value chỉ phụ thuộc vào các token đến trước chúng. Một khi chúng được tính toán cho một tiền tố nhất định, chúng không bao giờ cần thay đổi.
Hình minh họa bên dưới giải thích trực quan những gì chúng ta vừa thảo luận:
Nếu không có caching, các tensor Key-Value đó sẽ bị vứt bỏ ngay khi một yêu cầu hoàn thành. Yêu cầu tiếp theo bắt đầu lại từ đầu và tính toán lại chúng cho tất cả 20.000 token một lần nữa.
KV caching giải quyết điều này bằng cách lưu trữ các tensor đó. Cơ sở hạ tầng giữ chúng trên các máy chủ suy luận, được lập chỉ mục bằng một hàm băm mật mã của văn bản đầu vào. Khi một yêu cầu mới đến với cùng một tiền tố, hàm băm khớp, các tensor được truy xuất ngay lập tức và mô hình bỏ qua tất cả phép tính đó.
Điều này giảm độ phức tạp tính toán từ O(n²) cho mỗi token được tạo xuống còn O(n). Đối với một tiền tố 20.000 token lặp lại qua 50 lượt, đó là một sự giảm đáng kể.
Kinh Tế Học
Hiểu cấu trúc giá cả là điều làm cho quyết định kiến trúc này trở nên hệ trọng.
Đây là cách Anthropic định giá caching trên các dòng mô hình của họ:
Ba con số cần ghi nhớ:
- Cache đọc có giá 10% giá đầu vào cơ bản, giảm 90% cho mỗi token đọc từ cache
- Cache ghi có giá cao hơn 25% so với giá đầu vào cơ bản, một khoản phí nhỏ để lưu trữ các tensor KV
- Caching mở rộng 1 giờ có giá gấp 2 lần giá cơ bản
Phép tính chỉ hiệu quả nếu tỷ lệ cache hit của bạn duy trì ở mức cao. Điều này đưa chúng ta đến ví dụ thực tế tốt nhất về những gì điều đó trông như thế nào trong thực tế.
Claude Code: Một Phiên 30 Phút Đi Bộ Qua
Claude Code được xây dựng hoàn toàn xoay quanh một mục tiêu: giữ cho cache luôn "nóng".
Để hiểu điều đó có nghĩa là gì một cách cụ thể, hãy cùng xem một phiên lập trình điển hình kéo dài 30 phút trông như thế nào và theo dõi chính xác những gì được tính phí và những gì không.
Phút 0: Bắt Đầu Phiên
Claude Code tải prompt hệ thống và định nghĩa công cụ của nó. Nó cũng đọc tệp CLAUDE.md trong thư mục gốc dự án của bạn, mô tả codebase và các quy ước. Tải trọng này thường vượt quá 20.000 token.
Đây là thời điểm đắt đỏ nhất của toàn bộ phiên. Mỗi token đều mới. Nhưng bạn chỉ trả chi phí này một lần.
Phút 1 đến 5: Các Lệnh Đầu Tiên
Bạn gõ lệnh đầu tiên của mình, đại loại như "xem module xác thực và đề xuất cải tiến."
Claude Code gửi một Explore Subagent. Nó điều hướng qua codebase, mở tệp, chạy lệnh grep và xây dựng một bức tranh về mã liên quan. Tất cả điều này được thêm vào phần đuôi động.
Nền tảng tĩnh 20.000 token? Đã có trong cache. Được đọc lại với giá $0.30/MTok thay vì $3.00/MTok. Bạn chỉ trả tiền cho các đầu ra công cụ mới và tin nhắn của bạn.
Phút 6 đến 15: Công Việc Chuyên Sâu
Plan Subagent nhận được các phát hiện từ Explore Subagent. Thay vì truyền kết quả thô nguyên văn (điều này sẽ làm phần đuôi động phình to không cần thiết), Claude Code truyền một bản tóm tắt ngắn gọn. Điều này giữ cho phần hậu tố dễ quản lý và cache hiệu quả.
Bộ lập kế hoạch tạo ra một kế hoạch triển khai có cấu trúc. Bạn xem xét nó, phê duyệt nó và Claude Code bắt đầu thực hiện các thay đổi. Mỗi lượt trong vòng lặp này đọc tiền tố 20.000 token từ cache. Mỗi lần cache hit đặt lại TTL, giữ cho cache ấm cho các lượt trong tương lai.
Phút 16 đến 25: Lặp Lại
Bạn yêu cầu điều chỉnh. Claude Code sửa đổi cách tiếp cận của nó. Nhiều cuộc gọi công cụ hơn, nhiều đầu ra terminal hơn. Phần đuôi động đang phát triển, nhưng nó chỉ đại diện cho nội dung mới, duy nhất trong phiên này.
Tại thời điểm này, phiên đã xử lý tổng cộng hàng trăm nghìn token. Nhưng nền tảng 20.000 token đã được đọc từ cache mỗi lượt.
Phút 28: Chạy /cost
Nếu không có caching, một phiên như thế này dễ dàng vượt quá 2 triệu token. Ở mức giá Sonnet 4.5, đó là khoảng $6.00.
Với caching hoạt động hiệu quả cao:
- Phần lớn các token được đọc từ cache với giá $0.30/MTok
- Chỉ các token đuôi động mới được tính toán mới
Trong thực tế, bạn có thể mong đợi mức giảm chi phí 80%+ cho một tác vụ duy nhất. Bây giờ nhân nó lên với mọi người dùng, mỗi ngày.
Để tóm tắt, đây là cách bố trí prompt hệ thống trông như thế nào khi phiên tiếp tục:
Quy Tắc Phá Vỡ Mọi Thứ
Đây là điều phản trực giác nhất về prompt caching.
1 + 2 = 3. Nhưng 2 + 1 là cache miss.
Cơ sở hạ tầng băm prompt. Hàm băm là một định danh cho mật mã. Hàm băm thay đổi nếu bất cứ điều gì trong thứ tự đó thay đổi, ngay cả khi hai phần tử ở thứ tự khác nhau. Cache trống. Toàn bộ tiền tố được tính toán lại với giá đầy đủ.
Ba quy tắc sau đây:
- Không thêm hoặc bỏ bớt công cụ trong một phiên. Tiền tố được lưu trong cache bao gồm các công cụ. Thay đổi công cụ làm cho mọi thứ sau nó trở nên vô dụng.
- Không bao giờ chuyển đổi mô hình giữa phiên. Cache là dành riêng cho từng mô hình. Chuyển sang mô hình rẻ hơn giữa cuộc trò chuyện yêu cầu xây dựng lại toàn bộ cache.
- Không bao giờ thay đổi tiền tố để thay đổi trạng thái. Thay vào đó, Claude Code thêm một thẻ vào tin nhắn người dùng tiếp theo để nhắc nhở hệ thống. Tiền tố không bao giờ thay đổi.
Nó Có Nghĩa Là Gì Cho Bạn
Mọi thứ ở trên giải thích cách Claude Code xử lý caching. Các quy tắc tương tự áp dụng nếu bạn đang xây dựng agent của riêng mình.
Đây là cách cấu trúc prompt của bạn:
- Ở trên cùng là hướng dẫn hệ thống và các quy tắc. Không thay đổi ở giữa.
- Tải tất cả các công cụ bạn cần trước. Không thêm hoặc bỏ bớt chúng.
- Ngữ cảnh đã truy xuất và tài liệu sau đó. Tĩnh trong suốt thời gian.
- Ở dưới cùng, lịch sử cuộc trò chuyện và đầu ra của công cụ.
Với auto-caching được bật, điểm ngắt tự động di chuyển về phía trước khi cuộc trò chuyện tiếp diễn.
Claude Code chịu trách nhiệm về cache của chính nó. Anthropic vừa thêm auto-caching vào API của họ, vì vậy bạn có thể làm điều tương tự cho agent của riêng mình.
Nếu không có auto-caching, bạn phải nhớ ranh giới token ở đâu. Một ranh giới sai có nghĩa là không truy cập được vào cache.
Sử dụng fork an toàn với cache để nén cho giới hạn ngữ cảnh. Sử dụng cùng một prompt hệ thống, công cụ và cuộc trò chuyện, sau đó thêm phần nén như một tin nhắn mới.
Cuộc gọi nén trông gần như giống hệt cuộc gọi cuối cùng. Tiền tố được lưu trong cache được sử dụng lại. Điều duy nhất được tính phí như mới là hướng dẫn nén.
Để xem API có hoạt động không, hãy theo dõi ba trường này trong mỗi phản hồi:
- cache_creation_input_tokens: token được đưa vào bộ nhớ
- cache_read_input_tokens: token được đọc từ bộ nhớ
- input_tokens: token hoạt động như bình thường
Điểm hiệu quả cache của bạn là số token đọc so với số token tạo. Hãy theo dõi nó giống như cách bạn theo dõi thời gian hoạt động.
Những Điểm Chính
Prompt caching không phải là một tính năng bạn bật. Nó là một kỷ luật kiến trúc mà bạn xây dựng xung quanh.
Claude Code là ví dụ tốt nhất về lĩnh vực đó trông như thế nào khi được thực hiện ở quy mô lớn.
Tỷ lệ cache hit 92%. Giảm chi phí 81%.
Đây là bản thiết kế nếu bạn đang xây dựng các agent. Bạn không thể bỏ qua khoản thuế; nó tồn tại. Điều duy nhất quan trọng là bạn đang trả tiền cho nó hay loại bỏ nó.
