Các bài trong khoáBài 24/38

38 bài

Domain 4: Evaluation, Testing & Optimization·Task 4.5

Tối ưu token, độ trễ và chi phí so với hiệu năng

Thứ tự tối ưu chi phí và độ trễ, gồm đo trước, lấy các khoản tiết kiệm không mất chất lượng, rồi mới đánh đổi effort và model, và đặt trần chi tiêu.

  • 7 phút đọc
  • Đối chiếu docs 02/11/2026
  • 6 nguồn

Đọc xong bạn nắm được

  • Đo chi phí trên mỗi việc xong từ các trường usage trước khi tối ưu
  • Làm các khoản tiết kiệm không mất chất lượng trước, nhất là prompt caching
  • Chọn thời gian sống của cache theo khoảng nghỉ giữa các yêu cầu
  • Đánh đổi effort rồi model khi còn cần, và đặt trần chi tiêu cho agent

Tối ưu chi phí sai thứ tự là cách nhanh nhất để làm hỏng chất lượng: đổi sang model rẻ hơn khi chưa bật cache, cắt bớt tài liệu khi chưa biết tiền đang đi đâu. Docs của Anthropic có hẳn một thứ tự: đo, làm những gì không mất chất lượng, rồi mới đánh đổi.

Bài này giúp bạn trả lời: muốn giảm token, độ trễ và chi phí mà giữ chất lượng, làm gì trước, làm gì sau?

Ví dụ xuyên suốt: trung tâm bảo hành điện thoại

Một chuỗi trung tâm bảo hành điện thoại có hai khối việc dùng Claude:

  1. Agent tiếp nhận bảo hành: chat nhiều lượt với khách, tra lịch sử máy, đối chiếu điều kiện bảo hành (một bộ chính sách 9.000 token), tạo phiếu. Mỗi phiên trung bình 15 lượt, khách hay để đó vài phút đi tìm số IMEI rồi quay lại.
  2. Chấm lại phiếu mỗi đêm: đọc 50.000 phiếu đã đóng trong ngày, gắn nhãn nguyên nhân hỏng để báo cáo cho nhà sản xuất.

Chi phí tháng vượt dự toán 35%, và chủ đầu tư yêu cầu chất lượng không được giảm.

Bước 1: đo trước khi sửa

  • Chi phí trên mỗi việc xong, không phải trên mỗi token. Docs về tối ưu chi phí khuyên tính từng loại token trong trường usage theo đúng giá của nó (đầu vào thường, ghi cache 5 phút, ghi cache 1 giờ, đọc cache, đầu ra), cộng lại cho mọi lần gọi của cả việc.
  • Tỉ lệ đọc từ cache. Docs nói trong các vòng lặp agent, phần lớn token đầu vào nên là token đọc từ cache: đo nội bộ của Anthropic cho thấy trung vị khoảng 84%; dưới khoảng 80% thì nên tìm xem cái gì đang làm hỏng cache.
  • Phần đuôi khó nhất. Docs khuyên so trên khoảng một phần mười việc khó nhất, vì hoá đơn thường do những việc bị làm hỏng rồi làm lại quyết định.

Trong ví dụ, đo ra: agent tiếp nhận chỉ đọc được 30% đầu vào từ cache, vì system prompt có dòng "Thời gian hiện tại: ..." ở đầu, đổi theo từng giây.

Bước 2: các khoản không mất chất lượng

Docs chia đòn bẩy làm hai nhóm. Nhóm "miễn phí", không đụng tới chất lượng: bật prompt caching trước mọi đòn bẩy khác, dọn token thừa, rà lại prompt mỗi khi đổi model, đưa việc không ai chờ sang Batch API (giảm 50%), và đặt hạn mức chi tiêu làm chốt chặn cuối.

ViệcTrong ví dụ
Sửa thứ phá cache, bật cache cho phần ổn địnhChuyển dòng thời gian xuống cuối; cache định nghĩa tool, system prompt và bộ chính sách 9.000 token
Dọn token thừaCắt kết quả tra lịch sử máy chỉ còn các trường cần; với nhiều tool thì dùng tool search
Việc không ai chờ đưa vào batch50.000 phiếu mỗi đêm vào Message Batches: nửa giá, đa số lô xong dưới 1 giờ, tối đa 24 giờ

Chọn thời gian sống của cache theo khoảng nghỉ. Cache mặc định sống 5 phút, làm mới mỗi lần dùng; tuỳ chọn 1 giờ có giá ghi gấp đôi giá đầu vào (so với 1,25 lần của loại 5 phút). Docs đưa số đo: khi cứ 10 lượt có 1 lượt đến sau một khoảng nghỉ dài, giữ mặc định 5 phút tốn hơn 54%; khi 20 lượt mới có 1 lượt như vậy, hai lựa chọn tốn gần bằng nhau. Khách bảo hành hay nghỉ vài phút giữa chừng, nên cân nhắc cache 1 giờ; job chạy liên tục với khoảng cách vài giây thì giữ 5 phút.

Dọn context với hội thoại dài (context editing, compaction) giúp phiên dài không tràn context, nhưng docs lưu ý chúng không tự nhiên là "miễn phí": xoá bớt nội dung có thể làm hỏng cache. Đo chi phí trên mỗi việc khi bật và khi tắt rồi mới giữ.

Bước 3: đánh đổi khi vẫn cần

Nhóm thứ hai có thể ảnh hưởng chất lượng: đổi model, hạ effort, giới hạn độ dài đầu ra, ngân sách cho phiên, kiến trúc nhiều model. Thứ tự hợp lý:

  1. Hạ effort trước. Docs về effort nói mức low hợp cho việc đơn giản và subagent; effort ảnh hưởng mọi token đầu ra, kể cả số lời gọi tool.
  2. Rồi mới đổi model, so bằng chi phí trên mỗi việc xong trên bộ test của mình.
  3. Chạy thấp, làm lại phần hỏng ở mức cao. Docs mô tả cách chạy mọi việc ở effort thấp và chỉ chạy lại việc hỏng ở effort cao; trong thử nghiệm của Anthropic rẻ hơn khoảng 40% so với chạy tất cả ở mức cao mà tỉ lệ đạt như nhau. Điều kiện: phải có tín hiệu cho biết việc nào hỏng (như bộ test tự động), và việc hỏng mất gấp đôi thời gian.
  4. Định tuyến: câu thường cho model nhẹ, câu khó cho model nặng, giảm cả chi phí lẫn độ trễ cho phần lớn lưu lượng.

Bước 4: đặt trần chi tiêu

  • max_tokens là trần cho một câu trả lời, model không nhìn thấy nó. Docs nói hạ nó xuống không làm model tiết kiệm hơn, chỉ làm câu trả lời bị cắt giữa chừng; với việc agent docs gợi ý đặt khoảng 64.000. Đặt trần cao không làm mọi yêu cầu tốn hơn, vì đó chỉ là mức tối đa.
  • Ngân sách cho phiên trên Claude Managed Agents là điểm dừng cứng: chạm mức thì phiên tạm dừng. Agent SDK có max_budget_usd.
  • Hạn mức chi tiêu của workspace là chốt chặn cuối cùng.

Nguồn

  1. Exam Guide CCAR-P v1.0, Domain 4(mở tab mới)
  2. Optimizing for cost and intelligence (Claude Docs)(mở tab mới)
  3. Prompt caching (Claude Docs)(mở tab mới)
  4. Batch processing (Claude Docs)(mở tab mới)
  5. Effort (Claude Docs)(mở tab mới)
  6. Manage tool context (Claude Docs)(mở tab mới)

Nắm rồi thì thử sức với đề

Xem khoá luyện thi
Tối ưu token, độ trễ và chi phí so với hiệu năng · Anthropic Exam Pro