Cách giảm hóa đơn Claude API: Hướng dẫn thực tế về chi phí token

Cách tư duy về ngân sách token

Mỗi yêu cầu có hai yếu tố tạo nên chi phí:

• Token đầu vào: câu lệnh hệ thống, tin nhắn người dùng, lịch sử hội thoại, định nghĩa công cụ, tài liệu truy xuất và mọi phần tiền tố được lưu bộ nhớ đệm vẫn được tính khi không có trong bộ nhớ đệm.
• Token đầu ra: phản hồi của mô hình, bao gồm cả nội dung dài dòng ngoài ý muốn và các lần thử lại.

Một công thức tư duy hữu ích là:

request_cost ≈ input_tokens × input_rate + output_tokens × output_rate

Điều đó nghe có vẻ hiển nhiên, nhưng nó thay đổi cách bạn tìm nguyên nhân gây tốn chi phí. Nếu yêu cầu trung bình có đầu ra “rẻ” nhưng đầu vào đắt, thì cắt bớt 400 token khỏi câu lệnh hệ thống có thể quan trọng hơn việc yêu cầu mô hình trả lời ngắn gọn hơn.

Bắt đầu từ việc chọn mô hình

Không phải tác vụ nào cũng cần mô hình mạnh nhất. Trong các hệ thống thực tế, lựa chọn mô hình thường là cách tối ưu hóa ít tốn kém nhất.

Một bẫy phổ biến là “mặc định chọn mô hình cao cấp hơn”. Các nhóm thường gửi mọi câu lệnh đến mô hình cao cấp nhất vì cảm thấy an toàn hơn. Trong thực tế, đó là một khoản bảo hiểm đắt đỏ cho những tác vụ không được hưởng lợi từ nó. Xây dựng một lớp định tuyến thường đáng công sức bỏ ra:

• Haiku cho phân loại nhanh, trích xuất JSON, gán nhãn nhật ký và sàng lọc ban đầu.
• Sonnet cho phần lớn khối lượng công việc của tác tử hoặc công cụ dành cho nhà phát triển.
• Opus chỉ khi tác vụ thực sự cần khả năng suy luận mạnh hơn, tổng hợp tinh tế hơn hoặc bạn đã đo lường chi phí của việc thất bại.

Một chính sách đơn giản và hiệu quả là:

1. Thử Haiku cho các tác vụ có cấu trúc với chi phí thấp.
2. Chuyển lên Sonnet nếu độ tin cậy thấp hoặc đầu ra sai định dạng.
3. Chỉ chuyển lên Opus cho những trường hợp thực sự khó.

Chuỗi chuyển đổi dự phòng như vậy thường rẻ hơn việc trả mức giá Opus cho mọi yêu cầu.

Mạnh tay cắt gọn câu lệnh hệ thống

Câu lệnh hệ thống là nơi lãng phí token ẩn ngay trước mắt. Nó thường phình to như nợ kỹ thuật: một dòng chính sách ở đây, một quy tắc văn phong ở kia, năm ví dụ chẳng ai xóa.

Nội dung nên loại bỏ

• Các chỉ dẫn trùng lặp mà ứng dụng đã thực thi.
• Những đoạn dài về việc “hãy hữu ích” nhưng không thay đổi hành vi.
• Các ví dụ cũ về trường hợp đặc biệt không còn quan trọng.
• Nội dung chính sách lặp lại trong mọi yêu cầu.
• Mô tả công cụ dài dòng khi một lược đồ gọn là đủ.

Nội dung nên giữ lại

• Các ràng buộc hành vi bắt buộc.
• Quy tắc định dạng đầu ra.
• Các chỉ dẫn thiết yếu về an toàn.
• Những ví dụ tối thiểu giúp cải thiện đáng kể độ tin cậy.

Trong thực tế, tôi đã thấy các nhóm cắt hàng trăm hoặc hàng nghìn token khỏi phần tiền tố lặp lại mà không làm thay đổi chất lượng của mô hình. Bí quyết là xử lý câu lệnh hệ thống như mã dùng trong môi trường vận hành: xóa nội dung không còn tác dụng, loại bỏ quy tắc trùng lặp và chỉ giữ lại những gì tác động đến hành vi.

Một cách làm tốt hơn là biểu diễn bằng cấu trúc thay vì văn xuôi:

{
  "style": "concise",
  "output": "json",
  "must_include": ["root_cause", "next_steps"],
  "must_avoid": ["speculation", "apologies"]
}

Cách đó dễ xem xét hơn ba đoạn chỉ dẫn viết theo lối diễn giải.

Dùng bộ nhớ đệm câu lệnh cho các phần tiền tố ổn định

Nếu bộ công nghệ của bạn hỗ trợ lưu câu lệnh vào bộ nhớ đệm, hãy dùng tính năng này cho mọi nội dung lặp lại giữa các yêu cầu: câu lệnh hệ thống, lược đồ công cụ, ví dụ mẫu và các khối chính sách dài.

Ý chính không phải là “lưu bộ nhớ đệm thì miễn phí”. Nó không miễn phí. Lợi ích là bạn không còn phải trả lại toàn bộ mức giá cho cùng một phần tiền tố trong mỗi lệnh gọi.

Nội dung phù hợp để lưu bộ nhớ đệm

• Câu lệnh hệ thống dùng chung cho toàn sản phẩm
• Định nghĩa hàm/công cụ lớn
• Chỉ dẫn truy xuất được tái sử dụng
• Ví dụ cố định về định dạng hoặc văn phong
• Khung tác tử hiếm khi thay đổi

Nội dung không phù hợp để lưu bộ nhớ đệm

• Ngữ cảnh người dùng riêng cho từng yêu cầu
• Tài liệu vừa được truy xuất
• Chỉ dẫn thay đổi nhanh chóng
• Nội dung ghi chép tạm riêng cho từng phiên

Sai lầm phổ biến là đặt nội dung thường xuyên thay đổi vào phần tiền tố rồi thắc mắc vì sao tỷ lệ trúng bộ nhớ đệm thấp. Để thu được lợi ích, hãy giữ đoạn được lưu bộ nhớ đệm ổn định và chuyển dữ liệu riêng của từng yêu cầu xuống sau đoạn đó.

Ví dụ về cấu trúc yêu cầu:

{
  "system": "Stable application prompt + tool definitions + output contract",
  "messages": [
    { "role": "user", "content": "New ticket text here" }
  ]
}

Nếu bạn giữ phần ổn định đúng là ổn định, bộ nhớ đệm sẽ có cơ hội phát huy tác dụng thực sự. Nếu phần tiền tố thay đổi ở mỗi yêu cầu, bạn chỉ đang trả chi phí quản lý bộ nhớ đệm mà không nhận được lợi ích nào.

Đặt max_tokens Một cách nghiêm túc

Một trong những chi phí âm thầm dễ phát sinh nhất là giới hạn đầu ra quá lớn. Nếu bạn đặt max_tokens ở mức rất lớn “để phòng hờ”, bạn tạo điều kiện cho những phản hồi dài, đặc biệt khi mô hình không chắc chắn hoặc diễn đạt dài dòng.

Dùng mức giới hạn thấp nhất vẫn đáp ứng được tác vụ.

Các khoảng giới hạn thực tế

• Trích xuất / phân loại: 32–128 token
• Tóm tắt ngắn: 128–256 token
• Bản diff mã / phần giải thích: 256–800 token
• Sinh nội dung mở: chỉ cao đến mức cần thiết

Nếu tác vụ là “trả về một đối tượng JSON”, hãy đặt giới hạn cứng. Nếu tác vụ là “giải thích kiến trúc này”, đừng cho mô hình dư dung lượng để viết cả một cuốn tiểu thuyết trừ khi bạn muốn như vậy.

Nhiều nhóm cũng quên giới hạn vòng lặp thử lại. Nếu việc phân tích cú pháp thất bại và bạn tự động yêu cầu mô hình thử lại với cùng giới hạn đầu ra rộng rãi, chi phí đầu ra cho một thao tác của người dùng có thể tăng gấp đôi hoặc gấp ba.

Gộp các tác vụ nhỏ thành lô

Xử lý theo lô hữu ích khi bạn có nhiều tác vụ nhỏ, độc lập với lượng chỉ dẫn phụ trợ tương tự nhau.

Thay vì làm thế này:

• 50 yêu cầu phân loại riêng biệt
• 50 lời nhắc hệ thống lặp lại
• 50 định nghĩa công cụ lặp lại

Hãy làm thế này:

• Một yêu cầu chứa 50 mục
• Một khối chỉ dẫn dùng chung
• Một schema đầu ra gọn

Mẫu lời nhắc ví dụ:

Classify each item into one of: bug, feature, question, billing.

Items:
1. "App crashes after login"
2. "Can you add dark mode?"
3. "How do I reset my password?"

Và quy ước đầu ra:

[
  {"id": 1, "label": "bug"},
  {"id": 2, "label": "feature"},
  {"id": 3, "label": "question"}
]

Cách này giảm phần phụ trợ lặp lại và thường cải thiện thông lượng. Đánh đổi nằm ở phạm vi ảnh hưởng của lỗi: nếu một mục sai định dạng, cả lô có thể cần được khôi phục. Với các luồng xử lý có giá trị cao hoặc phục vụ người dùng và nhạy cảm với độ trễ, các lô nhỏ hơn vẫn có thể phù hợp hơn.

Truyền trực tuyến cải thiện khả năng phản hồi, không giảm chi phí token

Truyền trực tuyến rất hữu ích cho trải nghiệm người dùng và đôi khi cho việc kiểm soát chi phí, nhưng bản thân nó không không tự động giảm số token bị tính phí một cách thần kỳ. Bạn vẫn phải trả tiền cho mọi nội dung mô hình tạo ra.

Điểm mà truyền trực tuyến thực sự hữu ích là dừng sớm:

• Người dùng thấy tiến trình sớm hơn.
• Ứng dụng của bạn có thể hủy khi đã có đủ nội dung.
• Bạn có thể dừng một câu trả lời dài mất kiểm soát trước khi nó chạm giới hạn đã cấu hình.

Điểm cuối này rất quan trọng. Nếu bạn đang tạo câu trả lời cho một bộ phân tích cú pháp ở bước sau và 120 token đầu tiên đã chứa JSON cần thiết, đừng tiếp tục thu thập thêm 800 token giải thích.

Trong thực tế, truyền trực tuyến đáng dùng khi ứng dụng của bạn có thể phản ứng ngay trong lúc nội dung đang được tạo. Nếu bạn chỉ truyền nội dung vào nhật ký rồi vẫn chờ toàn bộ câu trả lời, bạn nhận được lợi ích về trải nghiệm người dùng nhưng không giảm được nhiều chi phí.

Đo chi phí theo từng yêu cầu, không chỉ theo tháng

Chi phí hằng tháng cho bạn biết mình đang có vấn đề. Các chỉ số ở cấp yêu cầu cho bạn biết vấn đề nằm ở đâu.

Ít nhất hãy theo dõi:

• input_tokens
• output_tokens
• cache_hit_tokens nếu có
• tên mô hình
• endpoint / luồng tính năng
• độ trễ
• số lần thử lại
• tỷ lệ bị cắt ngắn hoặc lỗi phân tích cú pháp

Một payload ghi nhật ký đơn giản có thể trông như sau:

usage = response["usage"]

record = {
    "model": response["model"],
    "input_tokens": usage["input_tokens"],
    "output_tokens": usage["output_tokens"],
    "latency_ms": latency_ms,
    "cache_hit_tokens": usage.get("cache_read_input_tokens", 0),
    "request_type": "ticket_summary",
}
print(record)

Sau đó tính chi phí tập trung:

def estimate_cost(input_tokens, output_tokens, input_rate, output_rate):
    return (input_tokens * input_rate) + (output_tokens * output_rate)

Mức giá chính xác phụ thuộc vào nhà cung cấp và mô hình của bạn, nhưng quy trình vẫn như nhau. Khi bạn có thể xếp hạng yêu cầu theo chi phí, các nguyên nhân thường hiện ra rõ ràng:

• Một lời nhắc “nhỏ” có phần tiền tố ẩn khổng lồ
• Một lệnh gọi công cụ gửi lại toàn bộ tài liệu ở mỗi lượt
• Một giới hạn đầu ra bằng 10x mức tác vụ cần
• Một vòng lặp thử lại âm thầm tăng gấp đôi mức sử dụng
• Một tuyến xử lý lẽ ra nên dùng Haiku nhưng luôn dùng Opus

Tránh lãng phí âm thầm

Phần lớn việc lãng phí token khá tẻ nhạt, nên thường lọt qua quá trình rà soát mã.

Những nguyên nhân phổ biến

• Gửi lại cùng một lịch sử hội thoại dài ở mỗi lượt
• Đưa vào toàn bộ tệp mã nguồn khi chỉ cần một bản diff
• Yêu cầu văn xuôi khi JSON có cấu trúc là đủ
• Trả về phần giải thích dài dòng cho các hệ thống máy xử lý
• Truyền schema công cụ có kích thước lớn hơn chính tác vụ
• Để các lần thử lại tự động chạy lại cùng một lời nhắc tốn kém
• Giữ nhật ký hoặc ghi chú nội bộ trong ngữ cảnh của mô hình

Một bẫy đặc biệt khó chịu là “mở rộng ngữ cảnh để hỗ trợ”. Các hệ thống truy xuất thường lấy quá nhiều nội dung vì có người muốn bảo đảm chắc chắn. Nếu mô hình chỉ cần ba đoạn liên quan nhất, đừng đưa cho nó toàn bộ tài liệu chỉ vì tầng chia đoạn khiến việc đó trở nên dễ dàng.

Một trường hợp khác: nếu bạn bọc mô hình bằng một lời nhắc thứ hai yêu cầu “hãy ngắn gọn”, có thể bạn vừa thêm token để giải quyết vấn đề dài dòng vốn nên được xử lý bằng một schema đầu ra chặt chẽ hơn.

Thiết kế yêu cầu thực tế

Đây là một mẫu hoạt động tốt cho nhiều tác vụ trong môi trường production:

request = {
    "model": "claude-sonnet-4.6",
    "max_tokens": 180,
    "system": "Extract the root cause and next action. Return strict JSON.",
    "messages": [
        {
            "role": "user",
            "content": "Investigate this incident summary: ... "
        }
    ]
}

Vì sao cấu trúc này hiệu quả:

• Mô hình được chọn đủ mạnh cho suy luận ở mức vừa phải.
• Giới hạn đầu ra hạn chế sự dài dòng mất kiểm soát.
• Lời nhắc hệ thống ngắn gọn và cụ thể.
• Định dạng đầu ra thuận tiện cho máy xử lý.
• Payload của người dùng chỉ chứa đầu vào cần thiết cho tác vụ.

Nếu bạn cần thêm ngữ cảnh, hãy bổ sung có chủ đích. Đừng để ngữ cảnh vô tình tích tụ.

Những yếu tố thực sự tác động đến hóa đơn

Nếu phải xếp hạng những biện pháp mang lại hiệu quả lớn nhất, tôi sẽ chọn:

1. Chọn mô hình rẻ hơn cho các tác vụ đơn giản
2. Cắt giảm phần dư thừa trong lời nhắc
3. Giới hạn max_tokens thật chặt
4. Dùng bộ nhớ đệm lời nhắc cho các tiền tố ổn định
5. Gộp các tác vụ nhỏ độc lập thành lô
6. Đo mức sử dụng ở cấp yêu cầu
7. Ngăn các vòng lặp thử lại làm chi phí tăng gấp đôi

Thứ tự đó rất quan trọng. Các nhóm thường bắt đầu bằng những kỹ thuật tối ưu hóa cầu kỳ trước khi sửa vấn đề rõ ràng: họ đơn giản là đang yêu cầu quá nhiều, quá thường xuyên, từ mô hình đắt nhất với quá nhiều ngữ cảnh.

Những điểm thực tiễn cần ghi nhớ

• Sử dụng Haiku cho việc trích xuất và định tuyến đơn giản, Sonnet cho phần lớn công việc phát triển sản phẩm, và Opus chỉ khi tác vụ thực sự cần đến.
• Hãy xem cuộc thảo luận về lời nhắc hệ thống như một nguồn phát sinh chi phí; xóa phần văn xuôi lặp lại và chỉ giữ những chỉ dẫn làm thay đổi hành vi.
• Bật bộ nhớ đệm lời nhắc cho các tiền tố ổn định như chính sách, schema công cụ và ví dụ few-shot.
• Đặt max_tokens ở mức trần thấp nhất vẫn hữu ích và xem xét lại cho từng tác vụ.
• Gộp thành lô các tác vụ nhỏ độc lập khi phần chỉ dẫn phụ trợ chiếm phần lớn.
• Theo dõi token đầu vào, token đầu ra, lượt trúng bộ nhớ đệm, số lần thử lại và độ trễ cho từng yêu cầu.
• Chú ý đến sự lãng phí âm thầm: lịch sử lặp lại, nội dung truy xuất quá lớn, đầu ra dài dòng và các vòng lặp thử lại tự động.

Nếu bạn muốn, tôi có thể chuyển nội dung này thành một bài viết đi kèm với ví dụ cụ thể về bảng điều khiển chi phí và một vài quy tắc định tuyến cho Haiku/Sonnet/Opus.