Giảm chi phí và cải thiện hiệu suất với Claude Platform

Việc tinh chỉnh bộ nhớ đệm lời nhắc (prompt caching), hướng dẫn (instructions) và mức độ nỗ lực (effort) có thể giảm chi phí sử dụng Claude mà không làm giảm hiệu suất ứng dụng.

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

Bộ nhớ đệm lời nhắc (Prompt Cache)

Trước khi Claude tạo ra phản hồi, nó trước tiên xử lý lời nhắc 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 của việc xử lý đầu vào. Bộ nhớ đệm lời nhắc lưu 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 đọc lại nó thay vì tính toán lại. Việc đọc bộ nhớ đệm được tính phí với một phần nhỏ so với giá đầu vào đầy đủ.

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

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

• Cẩn thận khi thay đổi cài đặt mức độ nỗ lực giữa cuộc hội thoại. Các cài đặt này được hiển thị trong lời nhắc trước nội dung của bạn, vì vậy chúng là một phần của tiền tố được lưu trong bộ nhớ đệm. Chỉ với một số mô hình Claude chọn lọc, bao gồm Opus 5 và Fable 5.1, bạn mới có thể cập nhật mức độ nỗ lực giữa cuộc hội thoại mà không làm hỏng bộ nhớ đệm.
• Giữ các giá trị dễ thay đổi ra khỏi tiền tố. Một dấu thời gian hoặc ID động trong lời nhắc hệ thống có thể thay đổi qua các lần gọi mô hình và làm hỏng bộ nhớ đệm.
• Tránh các định nghĩa công cụ tự sắp xếp lại thứ tự. Khi sử dụng API messages của Claude, lời nhắc được tập hợp theo một thứ tự cố định với các định nghĩa công cụ được hiển thị ở đầu. Bất kỳ thay đổi nào đối với định nghĩa công cụ sẽ làm hỏng bộ nhớ đệm.
• Cẩn thận khi phân nhánh hội thoại. Các tác nhân phụ (subagents) và nhánh (branches) chỉ chia sẻ bộ nhớ đệm của cha mẹ khi tiền tố của nhánh giống hệt nhau về mặt byte, trên cùng một mô hình và sử dụng cùng một mức độ nỗ lực.

Cách khắc phục

Chúng tôi đã tích lũy một vài bài học cho việc quản lý bộ nhớ đệm lời nhắc:

• Theo dõi tỷ lệ truy cập bộ nhớ đệm lời nhắc của bạn một cách cẩn thận. Claude Console và API chẩn đoán bộ nhớ đệm cung cấp thông tin chẩn đoán bộ nhớ đệm lời nhắc, bao gồm lý do cho các lần bỏ lỡ bộ nhớ đệm lời nhắc (Hình 1) và chính xác nơi hai yêu cầu khác nhau.

• Trì hoãn các công cụ ít được sử dụng. Khai báo tất cả các công cụ của bạn ngay từ đầu nhưng đánh dấu những công cụ ít được sử dụng là defer_loading: chúng nằm ngoài tiền tố được lưu trong bộ nhớ đệm và chỉ được thêm vào cuộc hội thoại khi Claude tra cứu chúng bằng tìm kiếm công cụ, do đó bộ nhớ đệm được bảo toàn.
• Áp dụng các bản cập nhật lời nhắc hệ thống dưới dạng tin nhắn. Một số mô hình Claude nhất định cho phép bạn thêm một hướng dẫn hệ thống dưới dạng tin nhắn giữa cuộc hội thoại thay vì chỉnh sửa lời nhắc hệ thống, điều này bảo toàn bộ nhớ đệm.
• Sắp xếp yêu cầu sao cho phần ổn định luôn ổn định. Thêm ngữ cảnh tĩnh (định nghĩa công cụ và lời nhắc hệ thống) trước và phần hội thoại đang phát triển sau chúng (Hình 2).

• Thực hiện các thay đổi đối với mô hình hoặc mức độ nỗ lực khi bộ nhớ đệm lời nhắc sắp bị hỏng. Một số thao tác nhất định, như nén (compaction), đã viết lại phần lớn bộ nhớ đệm (cuộc hội thoại). Đó là một thời điểm tốt để chuyển đổi mô hình hoặc mức độ nỗ lực, vì bạn đang phải trả tiền cho một lần bỏ lỡ anyway.
• Di chuyển điểm ngắt bộ nhớ đệm khi cuộc hội thoại phát triển. Với Claude Platform, bạn có thể đặt bộ nhớ đệm tự động để áp dụng điểm ngắt bộ nhớ đệm cho khối có thể lưu trong bộ nhớ đệm cuối cùng.
• Làm nóng bộ nhớ đệm trước (Pre-warm the cache). Để giảm độ trễ, hãy gửi một yêu cầu với max_tokens: 0 và một điểm ngắt bộ nhớ đệm rõ ràng, sử dụng cùng cài đặt mức độ nỗ lực như lưu lượng truy cập thực tế của bạn. Điều này xử lý lời nhắc và ghi nó vào bộ nhớ đệm mà không tạo ra bất cứ điều gì. Nếu bạn chạy nó khi bắt đầu phiên (ví dụ: trong khi người dùng đang nhập), yêu cầu thực tế đầu tiên sẽ truy cập vào một bộ nhớ đệm đã được làm nóng.
• Không vượt quá TTL của bộ nhớ đệm lời nhắc. TTL bộ nhớ đệm 5 phút được tính từ khi bắt đầu yêu cầu. Nếu một tác nhân bị chặn bởi các lệnh gọi công cụ hoặc yêu cầu tác nhân phụ chạy lâu hơn 5 phút, bộ nhớ đệm của cha mẹ sẽ hết hạn trước khi kết quả quay trở lại. Trong những trường hợp như vậy, hãy cân nhắc đặt TTL 1 giờ cho tiền tố.

Hướng dẫn (Instructions)

Lời nhắc có thể tích lũy các hướng dẫn để vá các điểm yếu của mô hình. Các 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à một số "phản mẫu" (anti-patterns) phổ biến khi viết lời nhắc có thể cản trở các mô hình Claude tiên tiến và vô tình làm tăng chi phí:

• Nghi thức xác minh (Verification rituals). Các hướng dẫn như "kiểm tra lại công việc của bạn" hoặc "xác minh hai lần trước khi trả lời" thường được các mô hình tiên tiến hiểu theo nghĩa đen và có thể lãng phí token.
• Các bộ tăng cường sự kỹ lưỡng và nhấn mạnh (Thoroughness and emphasis boosters). "Hãy kỹ lưỡng tối đa", "QUAN TRỌNG: BẠN LUÔN PHẢI…" có thể dẫn đến sự dài dòng và các lệnh gọi công cụ bổ sung khi làm việc với các mô hình tiên tiến.
• Các quy trình bắt buộc và khung nháp (Mandatory procedures and scratchpad scaffolds). Các quy trình gồm các bước cố định (ví dụ: "hãy suy nghĩ từng bước trong một bản nháp") hoặc các mẫu suy luận là những nghi thức mà các mô hình tiên tiến không cần. Khung này có thể chồng lên khả năng suy luận tự nhiên và sử dụng các token không cần thiết.
• Ví dụ lỗi thời (Stale examples). Các ví dụ few-shot được tinh chỉnh cho các chế độ lỗi của một mô hình cũ hơn có thể dạy một mô hình tiên tiến bắt chước các chuỗi suy luận dài dòng trên các yêu cầu không cần đến chúng.
• Các quy tắc mâu thuẫn (Contradictory rules). Các mô hình tiên tiến giỏi hơn trong việc tuân theo hướng dẫn. Các hướng dẫn mâu thuẫn ("luôn hoàn tiền theo chính sách" so với "không bao giờ hoàn tiền nếu không có sự leo thang") có thể được các mô hình tiên tiến tuân theo một cách cứng nhắc hơn, dẫn đến hiệu suất giảm sút.
• Cấu hình lỗi thời (Dated configuration). Các cài đặt được viết cho một thế hệ Claude cũ hơn (ví dụ: ngân sách suy nghĩ thủ công) có thể bị Claude Platform từ chối với các mô hình mới hơn.

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 để phát hiện các phản mẫu này. Trong Claude Code, hãy chạy /claude-api prompt-audit đối với các lời nhắc, kỹ năng hoặc mô tả công cụ của bạn. Quá trình kiểm tra bao gồm mọi thứ trong thư mục làm việc của bạn, bao gồm mã ứng dụng gọi Claude API và cấu hình của riêng Claude Code (ví dụ: CLAUDE.md hoặc các kỹ năng).

Ví dụ, chúng tôi đã thử nghiệm việc di chuyển mô hình từ Opus 4.8 sang Opus 5 trên một điểm chuẩn hỗ trợ khách hàng. Chúng tôi bắt đầu với một lời nhắc sạch và cấy một phản mẫu tại một thời điểm (một cài đặt suy nghĩ đã ngừng hoạt động, một cặp quy tắc hoàn tiền mâu thuẫn, một bản nháp thủ công, "xác minh hai lần", "hãy kỹ lưỡng tối đa" và một quy trình sáu bước bắt buộc), tạo ra sáu lời nhắc kế thừa.

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

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 sao chép tra cứu đơn hàng trên mỗi lần hoàn tiền. Các bộ tăng cường sự nhấn mạnh ("hãy kỹ lưỡng tối đa") đã trở thành hàng chục lượt tìm kiếm kiến thức không cần thiết.

Chạy /claude-api prompt-audit đã loại bỏ các phản mẫu, 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ụ bổ sung và suy luận trùng lặp đã được loại bỏ. Độ chính xác tăng vì ba lý do. Cài đặt suy nghĩ đã ngừng hoạt động khiến API từ chối 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 trả trong khi yêu cầu khách hàng xác nhận. Và bản nháp thủ công xung đột với khả năng suy nghĩ tích hợp sẵn của Opus 5: trong ba phiếu yêu cầu, nó đã viết lệnh gọi công cụ bên trong suy luận của mình và không bao giờ thực thi nó.

Mức độ nỗ lực (Effort)

Mức độ nỗ lực bảo Claude "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.

Sự đánh đổi giữa chi phí và hiệu suất giữa các mức độ nỗ lực trên một mô hình duy nhất có thể khác nhau. Ví dụ, Claude Fable 5 đạt 11.5% ở mức nỗ lực thấp với chi phí $5.35 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 mỗi tác vụ; thay đổi mức độ nỗ lực làm tăng điểm số lên khoảng 2.7 lần (+19 điểm) với chi phí gấp khoảng 3.5 lần (Hình 4).

Trên Claude Fable 5.1, Humanity's Last Exam (không có công cụ) cho thấy một đường cong dốc với bước cuối cùng giảm dần. Nó đạt khoảng 53% ở mức nỗ lực thấp với chi phí khoảng $0.30 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; bước cuối cùng lên mức tối đa thêm khoảng nửa điểm với chi phí tăng 46%. Mức tăng này nằm trong nhiễu giữa các lần chạy của điểm chuẩn, vì vậy bạn trả nhiều tiền hơn mà không có lợi ích đo lường được.

Mức độ nỗ lực có thể bị hiệu chỉnh sai theo một trong hai hướng:

• Cho rằng cao hơn luôn tốt hơn. Mức nỗ lực cao có thể gây ra suy nghĩ quá mức (over-thinking). Claude dành nhiều thời gian cân nhắc hơn mức cần thiết cho nhiệm vụ, điều này làm tăng chi phí và độ trễ, và có thể làm giảm chất lượng câu trả lời. Sự cân nhắc chỉ hữu ích khi vẫn còn bằng chứng để tìm kiếm.
• Thiên về mức nỗ lực thấp. Đặt quá thấp, Claude dừng lại trước khi có đủ bằng chứng. Nó thực hiện ít lệnh gọi công cụ hơn, vì vậy nó có thể trả lời từ kết quả tìm kiếm đầu tiên thay vì kết quả thứ ba. Nó suy nghĩ ít hơn về các bước khó và bỏ qua bước kiểm tra mà nó thường chạy. Câu trả lời trông có vẻ hoàn chỉnh, nhưng nó được xây dựng trên thông tin một phần.

Cách khắc phục

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

• Thử nghiệm các mô hình mạnh hơn ở mức nỗ lực thấp hơn. Một mô hình mạnh hơn ở mức nỗ lực thấp có thể rẻ hơn một mô hình yếu hơn làm việc chăm chỉ (mức nỗ lực cao). Ví dụ, trên CursorBench 3.2, Claude Fable 5.1 ở mức nỗ lực thấp có hiệu suất tương đương với Fable 5 ở mức nỗ lực cao với chi phí chỉ bằng một phần ba (Hình 5). Hai điều khiến mô hình mới hơn rẻ hơn: ở mức nỗ lực thấp, nó làm ít việc hơn cho mỗi tác vụ và việc đọc bộ nhớ đệm lời nhắc của Fable 5.1 được định giá ở mức $0.25 mỗi triệu token so với $1.00 của Fable 5. Ngay cả với giá của Fable 5, Fable 5.1 ở mức nỗ lực thấp sẽ có chi phí thấp hơn khoảng 40%.

• Hiểu hình dạng nhiệm vụ của bạn. Việc đo lường hiệu suất ứng dụng trên một loạt các mức độ nỗ lực là một cách hữu ích để hiểu sự đánh đổi giữa chi phí và hiệu suất cho nhiệm vụ cụ thể của bạn. Trên một đánh giá chưa bão hòa, một đường cong chi phí-hiệu suất phẳng giữa các mức độ nỗ lực cho thấy nhiệm vụ không bị giới hạn bởi sức mạnh tính toán suy luận; việc tăng mức độ nỗ lực là không có lợi.

Việc hiệu chỉnh này thường liên quan đến việc chạy một đánh giá trên các mô hình và mức độ nỗ lực. Trong Claude Code, /claude-api hillclimb thực hiện tìm kiếm này cho bạn: nó chia đá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 nó trên một điểm chuẩn hỗ trợ khách hàng, bắt đầu từ Opus 4.8 ở mức nỗ lực mặc định (cao). Trình leo đồi (hillclimber) đầu tiên thử 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 huấn luyện 98.9% và cắt giảm chi phí xuống còn 2.6 cent mỗi phiếu yêu cầu (Hình 6).

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

Trên 14 phiếu yêu cầu dành riêng mà quá trình tìm kiếm 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í

Bộ nhớ đệm lời nhắc, hướng dẫn và mức độ 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ập đến nhiều hơn nữa. Để thực hiện kiểm toán chi phí toàn diện cho mã ứng dụng sử dụng Claude API, chúng tôi đã thêm /claude-api cost-optimize: nó lập hồ sơ về nơi chi tiêu của bạn, áp dụng các biện pháp giảm chi phí và nếu bạn cung cấp một đánh giá, nó sẽ hiển thị mức độ đánh đổi giữa tiết kiệm và hiệu suất.

cost-optimize bắt đầu bằng cách tìm ra nơi token của bạn đi: từ báo cáo sử dụng và chi phí của tổ chức bạn nếu bạn có khóa API Claude Admin, từ đối tượng sử dụng trên mỗi phản hồi API nếu ứng dụng của bạn ghi lại nó, hoặc nếu cả hai đều không có, bằng cách đọc mã 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ả dụng, bắt đầu với bộ nhớ đệm lời nhắc, 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 (batching) các công việc không cần giám sát. Nếu bạn cung cấp một đánh giá, nó sẽ đi xa hơn và tính toán chi phí và hiệu suất trên các mức độ nỗ lực và lựa chọn mô hình. Chúng tôi đã chạy điều này trên bốn điểm chuẩn công khai với Sonnet 5 làm mức cơ sở (Hình 7):

• LegalBench (giảm ~58% chi phí): cost-optimize đề xuất lưu vào bộ nhớ đệm một tiền tố dùng chung giữa các tác vụ, đặt mức nỗ lực thấp và xử lý các tác vụ qua Batch API. Token suy nghĩ giảm từ 102,779 xuống 8,284 và tỷ lệ đậu (pass rate) vẫn nằm trong nhiễu và chi phí giảm khoảng ~58%.
• tau2-bench retail (giảm ~73% chi phí): Bằng cách triển khai bộ nhớ đệm lời nhắc với vị trí điểm ngắt rõ ràng, cost-optimize đã giảm chi tiêu 72% trong khi vẫn giữ tỷ lệ đậu không đổi.
• OfficeQA Pro (giảm ~52% chi phí): cost-optimize đã thêm xử lý hàng loạt và lưu vào bộ nhớ đệm tài liệu, giúp giảm chi phí từ $136.20 xuống $64.87.
• SWE-bench Verified (giảm ~55% chi phí): cost-optimize phát hiện ra rằng cấu hình mặc định đã lưu vào bộ nhớ đệm chính xác. Khoản tiết kiệm đến từ việc đặt mức độ nỗ lực ở mức trung bình và giới hạn đầu ra của tác nhân chỉ trong vài câu ngắn gọn. Số bước trung bình mỗi tác vụ giảm từ 29 xuống 17 và token lời nhắc giảm từ 75.2M xuống 33.7M.

Bắt đầu

Hãy bắt đầu với /claude-api prompt-audit khi bạn đã di chuyển sang một mô hình Claude tiên tiến và muốn kiểm tra các lời nhắc hiện có của mình. Nó quét các lời nhắc, kỹ năng và mô tả công cụ trong thư mục làm việc của bạn. Đây có thể là mã ứng dụng gọi Claude API hoặc cấu hình của Claude Code (CLAUDE.md, skills). Nó loại bỏ các phản mẫu phổ biến có thể cản trở các mô hình tiên tiến.

Hãy sử dụng /claude-api cost-optimize khi ứng dụng của bạn sử dụng Claude API và bạn muốn kiểm toán chi phí. Nó lập hồ sơ chi tiêu token và sau đó thử nghiệm các đòn bẩy khác nhau: nó áp dụng prompt-audit, nhưng cũng kiểm tra các cách để giảm chi phí thông qua bộ nhớ đệm lời nhắc, xử lý hàng loạt các công việc không cần giám sát hoặc giới hạn đầu ra. Nếu bạn cung cấp một đánh giá, nó sẽ đo lường sự đánh đổi giữa mức độ nỗ lực và lựa chọn mô hình.

Cuối cùng, hãy sử dụng /claude-api hillclimb để tìm kiếm sự đánh đổi giữa chi phí và hiệu suất. Với một đánh giá, Claude chia nó thành các tập huấn luyện và kiểm tra, sau đó đề xuất các bản cập nhật cho ứng dụng của bạn nhằm giảm chi phí trong khi vẫn duy trì hiệu suất cơ sở. Claude đọc các trường hợp huấn luyện thất bại để hướng dẫn tìm kiếm và cấu hình cuối cùng được đánh giá trên tập kiểm tra dành riêng.

Để tìm hiểu thêm:

• Xem tài liệu của chúng tôi tại đây
• Xem sách dạy nấu ăn (cookbook) về giảm chi phí của chúng tôi tại đây
• Xem kỹ năng claude-api tại đây; kỹ năng này cũng được tích hợp sẵn trong Claude Code
• Xem bài viết này trên Claude Blog tại đây

Được viết bởi Lance Martin (@RLanceMartin), Brad Abrams (@brada), Isabella He (@IsabellaKHe) và Ben Lehrburger (@benlehrburger).