Quản lý chi phí và token - giá, dự toán, prompt caching, theo dõi mức dùng

Hoá đơn Claude không tăng đều theo số người dùng. Nó tăng theo số token, và một vài lựa chọn thiết kế (gửi lại cả bảng thuật ngữ mỗi lần, để câu trả lời dài vô tội vạ, không bật cache) có thể làm chi phí gấp mấy lần mà không ai để ý.

Bài này giúp bạn trả lời: một yêu cầu tốn bao nhiêu tiền, dự toán thế nào, prompt caching tiết kiệm ở đâu, và theo dõi chi phí ra sao?

Ví dụ xuyên suốt: công ty dịch thuật hợp đồng

Một công ty dịch thuật dùng Claude Sonnet 5.5 hỗ trợ biên dịch viên dịch hợp đồng thương mại Anh sang Việt. Mỗi yêu cầu gửi:

• System prompt và bảng thuật ngữ pháp lý của công ty: khoảng 30.000 token, giống hệt nhau ở mọi yêu cầu.
• Đoạn hợp đồng cần dịch: khoảng 2.000 token.
• Bản dịch trả về: khoảng 2.500 token.

Ứng dụng có ba tính năng: dịch, rà soát thuật ngữ, tóm tắt hợp đồng. Mỗi ngày khoảng 3.000 yêu cầu. Tháng này hoá đơn tăng gấp đôi, và không ai biết tính năng nào gây ra.

Token vào và token ra có giá khác nhau

Mỗi model có hai đơn giá, tính theo triệu token (MTok):

Với các model này, token đầu ra đắt gấp 5 lần token đầu vào. Mô hình chi phí phải tính riêng hai đơn giá; một câu trả lời dài thường tốn hơn một prompt dài cùng số token.

Các hệ số làm đổi đơn giá

Docs nói các hệ số này cộng dồn với nhau: hệ số cache áp chung với giảm giá Batch và hệ số nơi xử lý, và cả hai hệ số đó cũng áp lên trên giá fast mode.

Dự toán chi phí

Mô hình chi phí cần đủ năm thứ: số yêu cầu, số token đầu vào trung bình, số token đầu ra trung bình, bảng giá của model đã chọn, và phần tiết kiệm nhờ cache. Tính thử cho tính năng dịch:

Phí ghi cache: mỗi lần ghi 30.000 token ở giá 1,25 lần ($2,50/MTok) là $0,075, chỉ trả khi cache chưa có hoặc đã hết hạn.

Prompt caching: đặt điểm cache đúng chỗ

Prompt caching cho phép phần đầu của prompt được đọc lại từ cache thay vì xử lý lại. Cache tính theo tiền tố, theo đúng thứ tự tools, system, messages, tới khối có cache_control. Đề thi nhắc tới đặt điểm cache (cache check-pointing). Những điều cần nắm:

• Chỉ cache được đầu vào. Phần hợp để cache là phần tĩnh lặp lại giữa các yêu cầu: system prompt, chỉ dẫn, tài liệu dùng chung, định nghĩa tool. Đầu ra của model không phải là thứ prompt caching lưu.
• Hai cách bật: một trường cache_control ở cấp cao nhất của yêu cầu (cache tự động, điểm cache đặt ở khối cuối có thể cache), hoặc đặt cache_control trên từng khối, tối đa 4 điểm.
• Đặt điểm cache ở khối cuối cùng giống hệt nhau giữa các yêu cầu. Chèn thứ thay đổi (giờ hiện tại, mã người dùng) vào trước điểm cache là làm hỏng cache.
• Hội thoại dài: hệ thống chỉ dò ngược tối đa 20 khối từ mỗi điểm cache. Nếu một lượt thêm từ 20 khối trở lên, thêm một điểm cache gần nội dung cũ hơn.
• Ngưỡng tối thiểu: 512 token với các model mới nhất (Fable 5.1, Opus 5.5, Sonnet 5.5, Haiku 5.5). Ngắn hơn thì không được cache, và API không báo lỗi.
• Thời gian sống mặc định 5 phút, có thể chọn 1 giờ với giá ghi gấp đôi.

{
  "system": [
    { "type": "text", "text": "Bạn là biên dịch viên pháp lý... <bang_thuat_ngu>...</bang_thuat_ngu>",
      "cache_control": { "type": "ephemeral" } }
  ],
  "messages": [{ "role": "user", "content": "Dịch đoạn sau: ..." }]
}

Đếm trước, đo sau, theo từng tính năng

Đếm trước khi gửi. Endpoint POST /v1/messages/count_tokens nhận cùng đầu vào như một yêu cầu Messages (system, tool, ảnh, PDF) và trả số token ước tính. Docs nói nó miễn phí, có giới hạn số yêu cầu mỗi phút riêng, không trừ vào giới hạn của việc tạo message. Dùng nó để kiểm prompt có vừa giới hạn không, chọn model, hay so số token khi đổi sang model có tokenizer khác.

Đo sau khi gửi. Trường usage của mỗi phản hồi cho biết số token thật:

Cộng ba trường đầu mới ra tổng token đầu vào. Nếu cache_read_input_tokens luôn bằng 0 thì cache không trúng: kiểm lại vị trí điểm cache và ngưỡng tối thiểu.

Theo tính năng. API báo cáo mức dùng của tổ chức lọc được theo API key, workspace, model, nhưng không biết "tính năng" của bạn là gì. Muốn biết tính năng nào tốn tiền, ghi usage của mỗi lời gọi kèm nhãn tính năng vào log, hoặc dùng API key hay workspace riêng cho từng tính năng. Docs khuyên dùng Usage and Cost Analytics API cho tích hợp mới; Usage and Cost Admin API là bản cũ.

Trong ví dụ, sau khi gắn nhãn, đội thấy tính năng tóm tắt gửi nguyên hợp đồng 80.000 token mỗi lần và trả về bản tóm tắt dài 6.000 token. Đó mới là thứ cần sửa, không phải cắt đều mọi tính năng.