Hướng dẫn bộ đệm mã Claude của kỹ sư Anthropic tiết kiệm 300 triệu Token mỗi tuần

Tiêu đề gốc: How Anthropic Engineers Actually Save Tokens Tác giả gốc: Nate Herk Dịch: Peggy, BlockBeats

Tác giả gốc:律动BlockBeats

Nguồn gốc bài viết:

Chuyển thể: Mars Finance

Lời người biên tập: Nhiều người khi sử dụng Claude Code, cảm nhận rõ ràng nhất là Token tiêu thụ quá nhanh, các cuộc hội thoại dài dễ bị hết hạn mức. Nhưng từ góc nhìn của kỹ sư Anthropic, thực sự ảnh hưởng đến chi phí không phải là bạn viết bao nhiêu mã, mà là hệ thống có thể liên tục tái sử dụng ngữ cảnh đã xử lý hay không.

Chủ đề chính của bài viết chia sẻ là cách tiết kiệm Token thông qua cơ chế cache. Trong vòng một tuần, tác giả đã tái sử dụng hơn 3 tỷ Token nhờ cache, lượng cache trong ngày đạt tới 91 triệu. Vì chi phí cho Token cache chỉ bằng 10% của Token nhập bình thường, điều này có nghĩa là 91 triệu Token cache thực tế tính phí khoảng 9 triệu Token thông thường. Lý do tại sao cuộc hội thoại dài của Claude Code lại trông "bền bỉ" hơn không phải vì mô hình hoạt động miễn phí, mà là do lượng ngữ cảnh lặp lại được tái sử dụng thành công.

Chìa khóa của prompt caching nằm ở việc "đừng làm gián đoạn cache". Claude Code sẽ phân lớp cache các phần như lời nhắc hệ thống, định nghĩa công cụ, CLAUDE.md, quy tắc dự án và hội thoại lịch sử; chỉ cần phần tiền tố của yêu cầu sau này giữ nguyên, Claude có thể đọc trực tiếp cache mà không cần xử lý lại toàn bộ ngữ cảnh. Nội bộ của Anthropic cũng theo dõi tỷ lệ tái sử dụng prompt cache, vì nó không chỉ ảnh hưởng đến hạn mức của người dùng mà còn liên quan trực tiếp đến chi phí dịch vụ mô hình và hiệu quả vận hành.

Với người dùng thông thường, không cần hiểu tất cả các chi tiết nền tảng, chỉ cần nắm vững một vài thói quen quan trọng: đừng để hội thoại bị bỏ quên quá 1 giờ; khi chuyển đổi nhiệm vụ, thực hiện chuyển giao phiên làm việc; tránh thay đổi mô hình quá thường xuyên; các tài liệu lớn nên để trong Projects, thay vì dán đi dán lại vào hội thoại.

Bài viết này, thay vì nói về một mẹo tiết kiệm Token, lại cung cấp một phương pháp sử dụng Claude Code theo tư duy kỹ sư hơn: xem ngữ cảnh như một tài sản, giữ cache liên tục tái sử dụng, giảm thiểu tính toán lặp lại trong các cuộc hội thoại dài.

Dưới đây là nội dung gốc:

Tuần này tôi đã tiết kiệm được 3 tỷ Token, trong đó ngày nhiều nhất là 91 triệu, tổng cộng hơn 3 tỷ trong một tuần.

Tôi không thay đổi bất kỳ cài đặt nào. Đó chỉ là prompt caching hoạt động bình thường phía sau.

Nhưng khi tôi thực sự hiểu được cache là gì, và làm thế nào để tránh làm gián đoạn cache, thì trong cùng hạn mức sử dụng, cuộc hội thoại của tôi có thể kéo dài lâu hơn. Vì vậy, tôi tổng hợp một hướng dẫn nhập môn 80/20 về prompt caching của Claude Code, không đi sâu vào các chi tiết API.

TL;DR

Chi phí cho Token cache chỉ bằng 10% của Token nhập bình thường. 91 triệu Token cache, thực tế tính phí khoảng 9 triệu Token.

Phiên bản đăng ký Claude Code có TTL cache là 1 giờ; API mặc định là 5 phút; Sub-agent luôn là 5 phút.

Cache được phân thành ba lớp: lớp hệ thống, lớp dự án, lớp hội thoại.

Chuyển đổi mô hình giữa các cuộc hội thoại sẽ phá vỡ cache, kể cả khi bật chế độ "opus plan".

Cache tính phí như thế nào?

Mỗi Token được cache đều có chi phí bằng 10% của Token nhập.

Vì vậy, khi dashboard của tôi hiển thị có 91 triệu Token trúng cache trong một ngày, thì thực tế phí chỉ khoảng 9 triệu Token. Đây cũng là lý do khi dùng Claude Code lâu dài có cảm giác như hội thoại gần như "miễn phí" kéo dài.

Trong dashboard có hai con số đáng chú ý:

Cache create: Chi phí phát sinh khi ghi nội dung vào cache, sẽ có tác dụng trong các lượt hội thoại tiếp theo.
Cache read: Token Claude tái sử dụng từ cache, như CLAUDE.md, định nghĩa công cụ, các tin nhắn trước đó. Chi phí thấp hơn 10 lần so với xử lý lại từ đầu.

Nếu Cache read của bạn cao, chứng tỏ bạn đang dùng cache hiệu quả; nếu thấp, nghĩa là bạn đang trả phí cho cùng một ngữ cảnh nhiều lần.

Thariq của Anthropic có câu rất ấn tượng: "Chúng tôi thực sự theo dõi tỷ lệ trúng cache prompt, một khi tỷ lệ này thấp quá, sẽ có cảnh báo, thậm chí kích hoạt cảnh báo SEV."

Anh ấy còn viết một bài rất hay trên X. Khi tỷ lệ trúng cache cao, sẽ xảy ra bốn điều cùng lúc: Claude Code cảm giác nhanh hơn, chi phí dịch vụ giảm, hạn mức của bạn bền hơn, các cuộc mã hóa dài trở nên khả thi hơn.

Nhưng nếu tỷ lệ trúng cache thấp, ai cũng thiệt.

Vì vậy, động lực của cả hai bên đều thống nhất: Anthropic muốn tỷ lệ trúng cache cao hơn, còn bạn cũng muốn như vậy. Những thói quen nhỏ tưởng chừng vô hại, nhưng âm thầm reset cache, mới là thứ gây cản trở lớn nhất.

Cache tăng trưởng như thế nào trong mỗi vòng hội thoại?

Cache dựa trên "prefix matching", tức là "khớp tiền tố".

Không cần đi sâu kỹ thuật, bạn chỉ cần hiểu một điểm: miễn là phần nội dung trước một vị trí nào đó trùng khớp hoàn toàn với nội dung đã cache, Claude có thể tái sử dụng phần Token đó.

Một cuộc hội thoại mới hoàn toàn thường diễn ra như sau:

Theo tài liệu Claude Code, một hội thoại mới thường bắt đầu như thế này:

Vòng hội thoại đầu tiên: chưa có cache. Lời nhắc hệ thống, ngữ cảnh dự án (ví dụ CLAUDE.md, memory, quy tắc), và tin nhắn đầu tiên sẽ được xử lý lại và ghi vào cache.

Vòng hội thoại thứ hai: tất cả nội dung của vòng đầu đã được cache. Claude chỉ cần xử lý phản hồi mới và tin nhắn tiếp theo. Chi phí sẽ thấp hơn nhiều.

Vòng hội thoại thứ ba: tương tự. Các nội dung trước đó vẫn còn trong cache, chỉ cần xử lý phần mới nhất.

Cache có thể phân thành ba lớp:

Theo X của Thariq:

Lớp hệ thống (System layer): gồm các lệnh cơ bản, định nghĩa công cụ (read, write, bash, grep, glob) và phong cách output. Đây là cache toàn cục.

Lớp dự án (Project layer): gồm CLAUDE.md, memory, quy tắc dự án. Cache theo dự án.

Lớp hội thoại (Conversation): gồm phản hồi và tin nhắn, sẽ tăng dần theo từng vòng.

Nếu trong hội thoại, hệ thống hoặc dự án có thay đổi, tất cả nội dung phải được cache lại từ đầu. Đây là thao tác đắt nhất. Ví dụ, bạn đã nói đến vòng 16, rồi đột nhiên thay đổi lời nhắc hệ thống hoặc tạm dừng một giờ, thì tất cả Token từ vòng 1 trở đi đều phải xử lý lại.

1 giờ và 5 phút: sự nhầm lẫn dễ xảy ra

Đây là điểm dễ gây hiểu lầm nhất.

Claude Code bản đăng ký: TTL mặc định là 1 giờ.

API của Claude: TTL mặc định là 5 phút. Bạn có thể trả phí để nâng lên 1 giờ.
Sub-agent của mọi kế hoạch: luôn là 5 phút.

Chat trên web Claude.ai: không có ghi chính thức. Có thể giống bản đăng ký, nhưng chưa xác nhận.

Vài tháng trước, nhiều người phàn nàn hạn mức Claude tiêu hao quá nhanh. Có người nghĩ Anthropic đã âm thầm giảm TTL từ 1 giờ xuống 5 phút mà không thông báo. Nhưng thực tế, TTL của Claude Code vẫn là 1 giờ.

Vấn đề là, tài liệu của Claude Code và API riêng biệt, vốn là hai thứ hoàn toàn khác nhau, gây ra nhiều nhầm lẫn.

Nếu bạn chạy nhiều workflow Sub-agent hoặc dùng API trực tiếp, thì 5 phút rất quan trọng. Nhưng với 95% người dùng Claude Code, điều cần chú ý thực sự là khoảng thời gian 1 giờ.

Ba thói quen giúp 95% người dùng

Dưới đây là những điều tôi thấy thực sự hữu ích trong sử dụng hàng ngày.

Đừng để quá lâu không hoạt động

Nếu đã rảnh quá 1 giờ, nội dung cũ gần như đã hết hạn cache. Tin nhắn tiếp theo của bạn sẽ phải xây dựng cache lại từ đầu. Trong trường hợp này, thay vì tiếp tục "hồi sinh" một hội thoại cũ đã nguội, tốt hơn là làm rõ ràng chuyển giao rồi bắt đầu hội thoại mới, thường sẽ tiết kiệm chi phí hơn.

Khi chuyển nhiệm vụ, cứ bắt đầu lại từ đầu

/compact hoặc /clear vốn đã phá cache rồi, nên cứ dùng đúng lúc để reset hoàn toàn.

Mình đã tạo một kỹ năng chuyển giao phiên làm việc, thay thế /compact. Nó sẽ tổng kết những gì đã làm, các quyết định còn đang chờ, các file quan trọng, rồi thực thi /clear, dán phần tóm tắt đó vào, như thể không có gì bị gián đoạn.

Lệnh compact đôi khi chạy chậm, còn kỹ năng chuyển giao này thường xong trong chưa đầy một phút.

Trong chat Claude, nên để các tài liệu lớn vào Projects

Cơ chế cache của Claude.ai chưa có hướng dẫn chính thức rõ ràng, nhưng Projects rõ ràng tối ưu hơn so với hội thoại thông thường. Vì vậy, nếu dán tài liệu lớn, tốt nhất là để trong Project, chứ không dán trực tiếp vào hội thoại.

Những thao tác nào âm thầm phá cache?

Có vài việc sẽ làm reset cache mà không báo trước:

Chuyển đổi mô hình: cache dựa trên tiền tố, mỗi mô hình có cache riêng. Chuyển mô hình, lần sau yêu cầu sẽ không có cache nào được dùng, phải đọc lại toàn bộ lịch sử.

Chế độ "Opus plan": chế độ này dùng Opus trong giai đoạn lập kế hoạch, Sonnet trong thực thi. Đã từng đề xuất trong các video tối ưu token, có lý do. Nhưng cần hiểu rằng, mỗi lần chuyển plan, về bản chất là chuyển mô hình, đồng nghĩa phải xây dựng cache mới. Về lâu dài, vẫn giúp kéo dài hạn mức, nhưng bạn cần biết rõ chuyện gì đang xảy ra phía dưới.

Chỉnh sửa CLAUDE.md giữa chừng: việc này không có tác dụng ngay lập tức, phải đợi lần khởi động lại tiếp theo mới áp dụng. Cache hiện tại không bị ảnh hưởng.

Dashboard Token miễn phí của tôi

Ảnh chụp tôi trình bày trước đây là từ một dashboard token.

Đây là một kho GitHub đơn giản. Bạn cung cấp liên kết cho Claude Code, nó sẽ chạy trên localhost, đọc tất cả các hội thoại của bạn, không bắt đầu từ con số 0. Bạn có thể xem dữ liệu input, output, cache create, cache read hàng ngày.

Lưu ý: dashboard này thống kê Token trên thiết bị của bạn. Nếu chuyển từ desktop sang laptop, số liệu sẽ không hoàn toàn khớp. Mỗi thiết bị có bộ thống kê riêng.

Tổng kết

Prompt caching là một lĩnh vực có thể nghiên cứu sâu. Bài của Thariq còn đầy đủ hơn, nếu muốn xem toàn diện, đáng để đọc.

Nhưng bạn không cần hiểu hết tất cả chi tiết để hưởng lợi. Chỉ cần nắm vững 80/20: cache Token rẻ hơn 10 lần Token bình thường; TTL của Claude Code là 1 giờ; chuyển đổi mô hình sẽ phá cache; chuyển giao rõ ràng giữa các nhiệm vụ thường tiết kiệm hơn so với để hội thoại cũ "hết hạn" rồi tiếp tục.

Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
  • Phần thưởng
  • 5
  • Đăng lại
  • Retweed
Bình luận
Thêm một bình luận
Thêm một bình luận
GateUser-0fdb3438
· 5giờ trước
Chiến lược bộ đệm +1, lần tới thiết kế kiến trúc cần lên kế hoạch rõ ràng về vòng đời của ngữ cảnh
Xem bản gốcTrả lời0
BudgetDeFi
· 8giờ trước
Việc tái sử dụng bộ đệm mới là bí quyết thực sự để giảm chi phí, tiết kiệm 300 triệu Token đủ để chạy bao nhiêu vòng thử nghiệm
Xem bản gốcTrả lời0
0xPeachy
· 8giờ trước
Muốn biết trong 3 tỷ này có bao nhiêu phần trăm là các đoạn mã lặp lại, cảm thấy tỷ lệ tái sử dụng mã trong dự án có lẽ rất cao
Xem bản gốcTrả lời0
DrawTheCandlestickChartIn
· 8giờ trước
Người dùng Claude Code vui mừng khôn xiết, cuối cùng cũng biết hạn mức đã đi đâu
Xem bản gốcTrả lời0
GateUser-83c80dd0
· 8giờ trước
9,1 triệu đơn hàng lượng bộ nhớ đệm trong ngày, tỷ lệ trúng phải cao đến mức nào? Tò mò về chi tiết chiến lược bộ nhớ đệm của họ
Xem bản gốcTrả lời0
  • Đã ghim