Anthropic chia sẻ bí quyết tối ưu chi phí cho Claude: Từ bộ nhớ đệm đến tinh chỉnh hiệu suất

Hiệu năng và chi phí thường được xem là một sự đánh đổi: để chi tiêu ít hơn, bạn phải chấp nhận kết quả kém hơn. Trên thực tế, chúng tôi nhận thấy rằng nhiều ứng dụng sử dụng Claude Platform có thể cắt giảm chi phí mà không làm giảm hiệu năng thông qua ba giải pháp: tối đa hóa tỷ lệ cache hit của prompt, loại bỏ các "anti-pattern" (mẫu hình phản tác dụng) khỏi prompt khi nâng cấp lên các mô hình Claude tiên tiến, và điều chỉnh mức độ nỗ lực (effort) phù hợp với tác vụ. Chúng tôi đã tích hợp hướng dẫn này vào kỹ năng claude-api. Trong bài viết này, chúng tôi sẽ chỉ ra cách Claude Code cùng với kỹ năng claude-api thường có thể tìm ra các phương thức giảm chi phí trong khi vẫn duy trì hoặc cải thiện hiệu năng.

Prompt cache

Trước khi Claude tạo phản hồi, nó sẽ xử lý prompt của bạn thành một trạng thái làm việc nội bộ. Bước này, được gọi là prefill, là phần tốn kém nhất trong việc xử lý đầu vào. Prompt caching lưu lại trạng thái đó (bộ nhớ đệm key–value, hay KV): khi một yêu cầu bắt đầu bằng cùng một tiền tố, Claude sẽ đọc lại nó thay vì tính toán lại. Các lượt đọc từ bộ nhớ đệm được tính phí chỉ bằng một phần nhỏ so với giá đầu vào đầy đủ.

Có một vài lưu ý thực tế để đảm bảo sử dụng hiệu quả prompt cache. Thứ nhất, prompt cache được gắn với một mô hình cụ thể. Thứ hai, các lượt đọc prompt cache phải khớp chính xác từng byte trên toàn bộ tiền tố của prompt. Cuối cùng, prompt cache có thời gian tồn tại (TTL) giới hạn.

Với những điểm này, dưới đây là một vài mẹo thực tế:

Cách khắc phục

Chúng tôi đã đúc kết được một vài bài học cho việc quản lý prompt cache:

Theo dõi chặt chẽ tỷ lệ cache hit của prompt. Claude Console và API chẩn đoán bộ nhớ đệm cung cấp các thông tin chẩn đoán prompt cache, bao gồm lý do gây ra lỗi cache miss (Hình 1) và vị trí chính xác nơi hai yêu cầu bắt đầu khác biệt.

Theo dõi chặt chẽ tỷ lệ cache hit của prompt. Claude Console và API chẩn đoán bộ nhớ đệm cung cấp các thông tin chẩn đoán prompt cache, bao gồm lý do gây ra lỗi cache miss (Hình 1) và vị trí chính xác nơi hai yêu cầu bắt đầu khác biệt.

Hướng dẫn (Instructions)

Các prompt có thể tích lũy những hướng dẫn nhằm vá lỗi điểm yếu của mô hình. Những hướng dẫn này có thể bị lệch so với khả năng của các mô hình Claude mới nhất. Dưới đây là các "anti-pattern" phổ biến trong việc viết prompt gây cản trở các mô hình Claude tiên tiến và có thể vô tình làm tăng chi phí:

Cách khắc phục

Chúng tôi đã cập nhật kỹ năng claude-api với một lệnh mới giúp phát hiện các anti-pattern này. Trong Claude Code, hãy chạy /claude-api prompt-audit cho các prompt, kỹ năng hoặc mô tả công cụ của bạn. Quá trình kiểm tra này bao gồm mọi thứ trong thư mục làm việc của bạn, kể cả mã nguồn ứng dụng gọi Claude API và cấu hình riêng của Claude Code (ví dụ: CLAUDE.md hoặc các kỹ năng).

Ví dụ, chúng tôi đã thử nghiệm việc chuyển đổi mô hình từ Opus 4.8 sang Opus 5 trên một bộ tiêu chuẩn đánh giá hỗ trợ khách hàng. Chúng tôi bắt đầu với một prompt sạch và lần lượt thêm vào từng anti-pattern (một thiết lập tư duy đã lỗi thời, một cặp quy tắc hoàn tiền mâu thuẫn, một bản nháp thủ công, lệnh "xác minh hai lần", "hãy cực kỳ kỹ lưỡng" và một quy trình sáu bước bắt buộc), tạo ra sáu prompt cũ.

Chúng tôi chạy từng prompt trên Opus 4.8, trên Opus 5 với chỉ ID mô hình thay đổi, và trên Opus 5 sau khi chạy /claude-api prompt-audit một lần cho mỗi prompt (Hình 3 hiển thị mức trung bình của sáu trường hợp này).

Hình 3 | Ảnh hưởng của các anti-pattern trong prompt khi chuyển đổi mô hình từ Opus 4.8 sang Opus 5.

Với Opus 5, các nghi thức xác minh ("xác minh hai lần") sử dụng các token không cần thiết bằng cách lặp lại việc tra cứu đơn hàng trong mỗi lần hoàn tiền. Các từ ngữ tăng cường nhấn mạnh ("hãy cực kỳ kỹ lưỡng") trở thành hàng chục lượt tìm kiếm cơ sở tri thức không cần thiết.

Việc chạy /claude-api prompt-audit đã loại bỏ các anti-pattern, giúp giảm chi phí trung bình 14,6% và tăng độ chính xác trung bình 5,3%. Chi phí giảm vì các lệnh gọi công cụ thừa và suy luận trùng lặp đã bị loại bỏ. Độ chính xác tăng vì ba lý do. Thiết lập tư duy lỗi thời khiến API từ chối thẳng thừng mọi yêu cầu định tuyến. Các quy tắc hoàn tiền mâu thuẫn khiến Opus 5 giữ lại bốn khoản hoàn tiền đáng lẽ phải thực hiện trong khi chờ khách hàng xác nhận. Và bản nháp thủ công xung đột với khả năng tư duy tích hợp của Opus 5: trên ba phiếu hỗ trợ, nó đã viết lệnh gọi công cụ bên trong phần suy luận của mình và không bao giờ thực thi nó.

Nỗ lực (Effort)

Nỗ lực cho Claude biết "cần làm việc chăm chỉ đến mức nào". Ở mức nỗ lực thấp, Claude thường đưa ra kết luận nhanh hơn. Ở mức nỗ lực cao, Claude cân nhắc, xác minh và khám phá các phương án thay thế trước khi trả lời.

Chi phí so với hiệu năng trên các mức nỗ lực khác nhau của cùng một mô hình có thể thay đổi. Ví dụ, Claude Fable 5 đạt điểm 11,5% ở mức nỗ lực thấp với chi phí 5,35 USD mỗi tác vụ trên FrontierCode Diamond (50 tác vụ khó nhất). Ở mức nỗ lực tối đa, Fable 5 đạt 30,9% với chi phí 19,00 USD mỗi tác vụ; thay đổi mức nỗ lực làm tăng điểm số khoảng 2,7 lần (+19 điểm) với chi phí tăng khoảng 3,5 lần (Hình 4).

Trên Claude Fable 5.1, bài kiểm tra Humanity's Last Exam (không dùng công cụ) cho thấy một đường cong dốc với bước cuối cùng có hiệu quả giảm dần. Nó đạt khoảng 53% ở mức nỗ lực thấp với chi phí khoảng 0,30 USD mỗi câu hỏi và khoảng 61% ở mức nỗ lực tối đa với chi phí khoảng 2,23 USD; bước tăng cuối cùng lên mức tối đa chỉ thêm khoảng nửa điểm nhưng tốn thêm 46% chi phí. Mức tăng này nằm trong phạm vi sai số giữa các lần chạy của bộ tiêu chuẩn, vì vậy bạn phải trả nhiều tiền hơn mà không thu được kết quả đo lường được.

Nỗ lực có thể bị điều chỉnh sai lệch theo cả hai hướng:

Cách khắc phục

Có một số cách hữu ích để hiệu chỉnh mức nỗ lực:

Việc hiệu chỉnh này thường bao gồm việc chạy đánh giá trên các mô hình và mức nỗ lực khác nhau. Trong Claude Code, lệnh /claude-api hillclimb thực hiện việc tìm kiếm này cho bạn: nó chia bộ đánh giá của bạn thành các tập huấn luyện và kiểm tra, đề xuất các thay đổi cấu hình, và đọc các ví dụ huấn luyện thất bại để sửa chữa những gì nó tìm thấy.

Chúng tôi đã chạy lệnh này trên một bộ tiêu chuẩn hỗ trợ khách hàng, bắt đầu từ Opus 4.8 ở mức nỗ lực mặc định (cao). Thuật toán hillclimb trước tiên thử nghiệm Opus 5 ở mức nỗ lực thấp, áp dụng prompt-audit để loại bỏ các nghi thức gọi công cụ bắt buộc, các bước nháp và các quy tắc mâu thuẫn. Điều đó đã vượt qua mức cơ sở của Opus 4.8 với độ chính xác tập huấn luyện là 98,9% và giảm chi phí xuống còn 2,6 cent mỗi phiếu hỗ trợ.

Sau đó, nó chuyển xuống Sonnet 5 ở mức nỗ lực thấp, vốn còn rẻ hơn ở mức 1 cent mỗi phiếu, nhưng độ chính xác giảm xuống còn 88,9%. Bằng cách đọc các phiếu hỗ trợ huấn luyện bị lỗi, Claude đã thêm các quy tắc định tuyến và tham chiếu chéo giới hạn hoàn tiền vào prompt, đưa Sonnet 5 trở lại mức 98,9% với cùng chi phí.

Trên 14 phiếu hỗ trợ tách biệt mà thuật toán chưa từng thấy, cấu hình cuối cùng đạt 90,5% so với 78,6% của thiết lập ban đầu, với chi phí chỉ bằng khoảng một phần năm.

Tự động hóa việc giảm chi phí

Prompt caching, hướng dẫn và nỗ lực là những đòn bẩy phổ biến để giảm chi phí. Tài liệu của chúng tôi còn đề cập đến nhiều hơn thế. Để thực hiện kiểm toán chi phí toàn diện cho mã nguồn ứng dụng sử dụng Claude API, chúng tôi đã thêm lệnh /claude-api cost-optimize: nó lập hồ sơ về nơi chi tiêu của bạn đổ vào, áp dụng các biện pháp giảm chi phí và, nếu bạn cung cấp một bộ đánh giá, nó sẽ cho thấy sự đánh đổi giữa tiết kiệm chi phí và hiệu năng.

cost-optimize bắt đầu bằng việc tìm xem các token của bạn đi đâu: từ báo cáo sử dụng và chi phí của tổ chức nếu bạn có khóa Claude Admin API, từ đối tượng sử dụng (usage object) trên mỗi phản hồi API nếu ứng dụng của bạn ghi nhật ký, hoặc nếu cả hai đều không có, nó sẽ đọc mã nguồn xây dựng yêu cầu của bạn và ước tính.

Sau đó, nó xếp hạng các khoản tiết kiệm khả thi, bắt đầu với prompt caching, cắt giảm những gì mỗi yêu cầu mang theo (bao gồm cả prompt-audit), giới hạn đầu ra và xử lý hàng loạt các tác vụ không cần giám sát. Nếu bạn cung cấp một bộ đánh giá, nó sẽ tiến xa hơn và tính toán chi phí cũng như hiệu năng trên các mức nỗ lực và lựa chọn mô hình khác nhau.

Chúng tôi đã chạy lệnh này trên bốn bộ tiêu chuẩn công khai, bắt đầu với Sonnet 5 làm mức cơ sở (Hình 7):