Tính phí và giới hạn tần suất

Trang này giải thích quá trình trừ phí của một yêu cầu từ lúc gửi đến lúc quyết toán, và việc yêu cầu có bị tính phí hay không khi lỗi, bị hủy hoặc bị giới hạn tần suất. Đơn giá và cách tính phí của từng loại mô hình xem tại Giá mô hình.

Khi nào bị trừ phí

Mỗi yêu cầu đều trải qua hai bước “tạm giữ → quyết toán”:

1. Tạm giữ: trước khi chuyển yêu cầu đến upstream, hệ thống tạm giữ một khoản chi phí ước tính từ quota của key và số dư tài khoản. Nếu một trong hai không đủ, yêu cầu bị từ chối ngay, không được gửi đến upstream.
2. Quyết toán: sau khi yêu cầu hoàn tất, hệ thống tính chi phí thực tế theo mức sử dụng thực mà upstream trả về. Phần tạm giữ thừa được hoàn lại, phần thiếu được trừ thêm.

Cách tính chi phí ước tính:

Loại mô hình	Cách ước tính
Tính phí theo token	Số token đầu vào cộng max_tokens trong yêu cầu, ước tính theo đơn giá của mô hình
Mô hình giá bậc thang	Ước tính theo mức giá cao nhất, khi quyết toán mới tính theo bậc thực tế
Tính phí theo lần hoặc theo ảnh	Tạm giữ trực tiếp đơn giá mỗi lần
Tác vụ bất đồng bộ (video, nhạc, v.v.)	Tạm giữ số tiền ước tính khi gửi, quyết toán sau khi tác vụ kết thúc

Mẹo

max_tokens càng lớn, số tiền tạm giữ càng cao. Khi số dư eo hẹp, nếu yêu cầu bị từ chối do tạm giữ thất bại, bạn có thể giảm max_tokens xuống mức thực sự cần.

Lỗi có bị tính phí không

Nguyên tắc là: không phát sinh mức sử dụng phải tính phí thì không tính phí, số tiền tạm giữ được hoàn lại toàn bộ.

Kịch bản	Có tính phí
Key không hợp lệ, đã hết hạn, hoặc số dư, quota của key không đủ	Không tính phí, yêu cầu không được gửi đến upstream
Tham số yêu cầu sai, mô hình không khả dụng, không có kênh khả dụng	Không tính phí
Bị giới hạn tần suất (429)	Không tính phí
Upstream trả lỗi (4xx / 5xx)	Không tính phí, số tiền tạm giữ được hoàn lại toàn bộ
Upstream trả về thành công nhưng mức sử dụng bằng 0	Không tính phí
Upstream bị ngắt hoặc hết thời gian chờ trong lúc stream	Tính phí theo nội dung đã tạo
Tác vụ bất đồng bộ thất bại hoặc hết thời gian chờ (không hoàn tất trong 24 giờ)	Không tính phí, số tiền tạm giữ được hoàn lại toàn bộ

Thử lại và chuyển dự phòng

RouteAPI tự động thử lại hoặc chuyển sang kênh khác khi upstream gặp lỗi. Cả quá trình chỉ tạm giữ một lần và quyết toán một lần, các lần thử thất bại không bị tính phí; bạn chỉ trả tiền cho lần thành công cuối cùng. Nếu cuối cùng mô hình dự phòng hoàn tất yêu cầu, phí được tính theo giá của mô hình thực sự phục vụ yêu cầu đó.

Với yêu cầu streaming, một khi đã bắt đầu xuất nội dung cho bạn thì sẽ không thử lại nữa. Khi đó nếu upstream bị ngắt, phí được tính theo phần đã tạo.

Tự hủy có bị tính phí không

Kịch bản	Có tính phí
Yêu cầu không streaming, ngắt kết nối trước khi nhận phản hồi	Không tính phí, số tiền tạm giữ được hoàn lại toàn bộ
Yêu cầu streaming, ngắt kết nối giữa chừng	Có tính phí, xem giải thích bên dưới
Tác vụ bất đồng bộ (video, nhạc, Midjourney)	Không hỗ trợ hủy sau khi gửi

Khi yêu cầu streaming bị ngắt giữa chừng, upstream thường đã và đang tạo nội dung và sẽ tiếp tục tạo đến khi xong. RouteAPI sẽ tiếp tục đọc đầu ra của upstream cho đến khi quá trình tạo kết thúc, và tính phí theo mức sử dụng thực mà upstream đã tạo chứ không chỉ phần bạn đã nhận. Để kiểm soát khoản chi phí này, hãy dùng max_tokens để giới hạn độ dài đầu ra.

Giới hạn tần suất

Để bảo vệ sự ổn định của nền tảng và upstream, nền tảng có thể giới hạn tần suất yêu cầu mô hình của mỗi tài khoản. Giới hạn được tính theo tài khoản; mọi API key trong cùng một tài khoản dùng chung hạn mức.

Khi bị giới hạn tần suất, hệ thống trả về 429 Too Many Requests, nội dung phản hồi có cùng định dạng với các lỗi khác:

{
  "error": {
    "message": "... (request id: ...)",
    "type": "error",
    "code": ""
  }
}

• Yêu cầu bị giới hạn tần suất bị từ chối trước khi tạm giữ, không tính phí.
• Khi upstream trả về 429, RouteAPI tự động chuyển sang kênh khác để thử lại. Chỉ khi vẫn bị giới hạn tần suất sau khi thử lại thì 429 mới được trả về cho bạn.
• Phản hồi không kèm header Retry-After. Khuyến nghị client thử lại theo kiểu backoff mũ, ví dụ 1 giây, 2 giây, 4 giây, kèm ngẫu nhiên (jitter).
• Tách ra nhiều API key không làm tăng hạn mức giới hạn tần suất. Nếu cần tần suất yêu cầu cao hơn, hãy liên hệ với chúng tôi.

API nền tảng (/api/open/v1) có quy tắc giới hạn tần suất riêng, xem tại Lỗi và giới hạn của API nền tảng.

Đối chiếu khoản trừ phí

Trong nhật ký usage, bạn có thể xem chi tiết từng yêu cầu bị trừ phí:

Trường	Mô tả
Thời gian	Thời điểm yêu cầu
Key	Tên API key đã gửi yêu cầu
Mô hình	Mô hình thực tế được tính phí
Thời gian xử lý / token đầu tiên	Tổng thời gian; yêu cầu streaming còn hiển thị độ trễ token đầu tiên
Đầu vào	Số token đầu vào; khi trúng cache, số đọc cache và ghi cache được hiển thị riêng
Đầu ra	Số token đầu ra
Chi phí	Số tiền thực tế bị trừ cho lần này
Chi tiết	Đơn giá, hệ số và quá trình tính phí

Trường usage trong phản hồi API cũng trả về mức token sử dụng của lần này:

Trường	Mô tả
prompt_tokens	Token đầu vào
completion_tokens	Token đầu ra; token lý luận của mô hình lý luận cũng được tính vào đây
total_tokens	Tổng đầu vào và đầu ra
prompt_tokens_details.cached_tokens	Token đầu vào trúng cache

Nếu tài khoản có chiết khấu riêng, chi phí trong nhật ký đã là số tiền sau chiết khấu.