Chi phí API AI: token và nhóm mô hình

Theo dõi chi phí API AI hữu ích nhất khi mỗi khoản trừ có thể gắn với một yêu cầu, một mô hình, một nhóm mô hình và một đơn vị công việc đã đo. Tổng theo tháng cho biết chi tiêu thay đổi; bản ghi từng yêu cầu giải thích vì sao.

Modelflare kết hợp giá mô hình, usage thực đo, chính sách nhóm và nhật ký yêu cầu để người dùng kiểm tra chi phí mà không phải ước tính chỉ từ văn bản nhìn thấy.

Bốn lớp tạo nên chi phí một yêu cầu

1. Giá mô hình

Mỗi mô hình có cơ sở tính giá riêng. Nhiều mô hình văn bản tách token đầu vào và đầu ra; API hình ảnh, âm thanh, xếp hạng lại hoặc loại khác có thể dùng đơn vị đo khác. Một số tính năng còn dùng quy tắc giá nâng cao có phiên bản, không thể biểu diễn bằng một đơn giá token cố định.

Hãy dùng Mô hình & Giá để xem hợp đồng mô hình và định dạng API hiện tại, thay vì chép giá vào mã ứng dụng.

2. Usage thực đo của yêu cầu

Gateway ghi lại usage do nhà cung cấp trả về hoặc hệ thống tính cho yêu cầu đã hoàn tất. Với mô hình văn bản tính theo token, đầu vào và đầu ra được giữ riêng vì giá có thể khác nhau.

Văn bản streaming thấy trong terminal không phải căn cứ tính phí đáng tin cậy. Item công cụ, suy luận, đầu vào cache, token đã chuẩn hóa hoặc trường usage riêng của nhà cung cấp có thể được tính dù không hiện thành văn bản trợ lý thông thường.

3. Hệ số nhóm mô hình

Nhóm định tuyến thực tế có thể áp dụng hệ số bán hàng lên chi phí sử dụng cơ bản. Ví dụ, hệ số nhóm 0.9 nghĩa là yêu cầu được tính bằng 90% chi phí cơ bản của mô hình.

Hệ số chỉ áp dụng cho sử dụng. Nó không thay đổi lượng tín dụng mà một lần nạp thêm vào ví.

4. Bản ghi cuối của yêu cầu

Nhật ký sử dụng liên kết số tiền đã tính với mô hình, nhóm, trạng thái, token, thời gian và những metadata vận hành an toàn khác. Yêu cầu thất bại hoặc bị hủy có thể đi theo cách quyết toán khác, vì vậy kết quả đã lưu đáng tin cậy hơn ước tính phía ứng dụng khách.

Nên so sánh gì khi chi tiêu thay đổi

• Mô hình: lưu lượng có chuyển sang mô hình với giá đầu vào, đầu ra hoặc tính năng khác không?
• Nhóm: nhóm chính hoặc dự phòng có hệ số khác không?
• Giao thức: chuyển giữa Chat Completions và Responses có làm cấu trúc usage thay đổi không?
• Kích thước đầu vào: prompt, ngữ cảnh truy xuất, tệp hoặc kết quả công cụ có tăng không?
• Kích thước đầu ra: giới hạn phản hồi hoặc vòng lặp agent có tạo nhiều đầu ra hơn không?
• Trạng thái và thử lại: thất bại có sinh thêm những lần thử đã hoàn tất không?
• Thời gian: thời gian sinh dài hơn có đi cùng nhiều đầu ra hơn hay chỉ là chờ?

Hãy cô lập tải bằng ID yêu cầu ổn định hoặc khóa riêng của ứng dụng, thay vì so sánh lưu lượng tài khoản không liên quan.

Đặt ranh giới chi phí thực tế

Tách khóa theo khối lượng công việc

Dùng khóa khác nhau cho production, development, tự động hóa và công cụ cá nhân. Mỗi khóa có thể có tên, thời hạn, chính sách nhóm và hạn mức hữu hạn hoặc không giới hạn.

Chọn nhóm có chủ đích

Đừng chỉ nhìn tên nhóm. Hãy kiểm tra khả năng cung cấp mô hình hiện tại, hệ số, điều kiện truy cập, RPM và chính sách dự phòng. Nhóm chính rẻ hơn cùng dự phòng chấp nhận được có thể dễ dự đoán hơn lựa chọn ngầm khó giải thích.

Giảm đầu vào trước khi siết đầu ra

System prompt dài, lịch sử lặp, tài liệu truy xuất và kết quả công cụ thường chiếm phần lớn usage đầu vào. Loại bỏ ngữ cảnh không còn ảnh hưởng đến câu trả lời và tránh gửi lại dữ liệu không đổi khi ứng dụng khách có thể tham chiếu hoặc cache an toàn.

Xem lại vòng lặp agent

Một thao tác của người dùng có thể tạo nhiều yêu cầu mô hình. Hãy theo dõi từng vòng công cụ và lần thử lại; câu trả lời cuối cùng nhìn thấy không nhất thiết tương ứng với một lệnh gọi API.

Vì sao ước tính phía ứng dụng khách bị lệch

Tokenizer cục bộ hoặc đếm ký tự hữu ích cho việc lập kế hoạch nhưng có thể khác usage tính phí vì:

• nhà cung cấp chuẩn hóa hoặc đếm nội dung khác nhau;
• cache, suy luận, hình ảnh, âm thanh hoặc công cụ có thể có giá riêng;
• quyết toán dùng mô hình và nhóm thực tế đã chọn;
• thất bại và hoàn tiền phụ thuộc vòng đời yêu cầu thật;
• giá có thể thay đổi trong khi yêu cầu cũ giữ kết quả đã ghi.

Khi đối soát tài chính, hãy so khớp bản ghi usage và ví đã lưu. Không suy ngược số dư tài khoản từ một trường hiển thị duy nhất.

Quy trình rà soát có thể lặp lại

1. Lọc nhật ký sử dụng theo một khóa API và khoảng thời gian.
2. Nhóm yêu cầu theo mô hình và nhóm đã chọn.
3. So sánh đầu vào, đầu ra, trạng thái và chi phí từng yêu cầu.
4. Kiểm tra các ngoại lệ như thử lại, ngữ cảnh dài, vòng lặp công cụ hoặc chuyển dự phòng.
5. Xác nhận giá trực tiếp và chính sách nhóm trước khi đổi định tuyến.
6. Đặt hạn mức khóa hữu hạn nếu tải cần giới hạn chi tiêu cứng.
7. Kiểm tra lại cùng các số đo sau khi thay đổi.

Kiểm soát chi phí bắt đầu từ việc quy đúng nguồn. Khi mô hình, nhóm, usage và kết quả yêu cầu vẫn liên kết với nhau, nhóm có thể tối ưu nguyên nhân chi tiêu thực tế thay vì đoán từ tổng số liệu.