Trả tiền API theo lượt gọi hay thuê bao SaaS: ngưỡng hòa vốn nằm ở đâu?
API trả theo lượt gọi thường hợp lý hơn khi sản phẩm còn ít tác vụ hoặc lưu lượng biến động; thuê bao SaaS có thể rẻ hơn khi tải đủ lớn, ổn định và gói tháng bao phủ đầu ra tương đương. Ngưỡng hòa vốn là sản lượng tại đó tổng chi phí để hoàn thành một tác vụ đạt yêu cầu của hai phương án bằng nhau.
Muốn tìm đúng ngưỡng, startup phải quy đổi cả hai lựa chọn về cùng một đơn vị, chẳng hạn một hồ sơ được làm giàu hoặc một tác vụ agent hoàn tất. Phép so sánh cần tính số lượt thực thi, retry, số kết quả bị tính phí, phần vượt hạn mức và công sức kiểm soát; chia giá thuê bao cho giá niêm yết của một lượt gọi là chưa đủ.
1. Quy đổi về chi phí của một tác vụ hoàn tất
Tài liệu giá của Monid nêu hai cấu trúc: PER_CALL thu khoản cố định cho mỗi lần thực thi, còn PER_RESULT thu theo từng kết quả và có thể kèm phí cơ bản. Các ví dụ trong tài liệu là 0,003 USD mỗi lượt gọi và 0,001 USD mỗi kết quả cộng 0,002 USD phí cơ bản; đó là ví dụ cho từng endpoint, không phải giá chung của toàn bộ nền tảng.
Với giá theo lượt gọi, có thể viết chi phí biến đổi tháng là V_api = N × k × (1 + r) × p. Trong đó N là số tác vụ cần hoàn tất, k là số lượt gọi ban đầu cho mỗi tác vụ, r là số lượt retry phát sinh tính trên một lượt ban đầu và p là giá mỗi lượt. Tổng chi phí còn phải cộng phí nền tảng cố định F_api và chi phí tích hợp, giám sát, đối soát G_api.
Với giá theo kết quả, công thức biến đổi là V_api = A × b + R × q: A là tổng số lần chạy kể cả retry, b là phí cơ bản mỗi lần, R là số kết quả bị tính tiền và q là đơn giá kết quả. Theo ví dụ giá của Monid, một lần chạy trả về 20 kết quả có giá 0,002 + 20 × 0,001 = 0,022 USD, trước chi phí nội bộ và mọi lần chạy lại.
2. Công thức xác định ngưỡng hòa vốn
Trước hết, chỉ đếm các tác vụ đạt tiêu chuẩn ở mẫu số. Chi phí API biến đổi bình quân u_api bằng tổng phí thực thi của kỳ chia cho số tác vụ sử dụng được; tác vụ lỗi, dữ liệu trùng và đầu ra bị loại vẫn nằm ở tử số nếu chúng thực sự bị tính tiền.
Viết tổng chi phí API là C_api = F_api + G_api + N × u_api. Với SaaS, dùng C_saas = S + L + G_saas + N × u_saas, trong đó S là thuê bao cơ bản, L là ghế hoặc tiện ích bắt buộc và u_saas là phí biến đổi bình quân, gồm cả phần vượt hạn mức nếu có thể phân bổ theo tác vụ.
Khi phí biến đổi không đổi trong vùng đang xét, ngưỡng sản lượng là N* = (S + L + G_saas − F_api − G_api) / (u_api − u_saas). Công thức chỉ cho một ngưỡng dương có ý nghĩa khi API có chi phí biến đổi cao hơn SaaS và hai bên tạo ra đầu ra tương đương. Nếu phí vượt mức thay đổi theo bậc, phải tính riêng từng bậc thay vì dùng một đường chi phí duy nhất.
Ví dụ giả định: gói SaaS giá 49 USD mỗi tháng, không có phí vượt mức; API tốn 0,0033 USD cho một tác vụ hoàn chỉnh sau retry; các chi phí cố định khác bằng nhau. Ngưỡng xấp xỉ 14.849 tác vụ mỗi tháng. Giới hạn ghế, đồng thời hoặc xuất dữ liệu của SaaS sẽ làm ngưỡng thay đổi, còn doanh nghiệp hạch toán bằng VND nên quy đổi hai phương án theo cùng một tỷ giá kế toán.
3. Retry làm hóa đơn và năng lực sử dụng lệch khỏi nhu cầu
Retry phải được đo bằng số lần thực thi phát sinh, không phải tỷ lệ tác vụ từng gặp lỗi. Nếu 10.000 tác vụ cần một lượt gọi ban đầu và tạo thêm 1.000 lần thử, hệ số thực thi là 1,1. Với agent nhiều bước, nên tính riêng từng endpoint vì một bước lỗi có thể kích hoạt lại nhiều phần của chuỗi.
Hướng dẫn lỗi 429 của OpenAI cho biết SDK chính thức đã tự retry một số lỗi giới hạn tốc độ, yêu cầu không thành công vẫn được tính vào giới hạn theo phút, và vòng retry bổ sung cần giới hạn cả số lần lẫn tổng thời gian. Đây không phải quy tắc tính phí chung cho mọi API, nhưng cho thấy số yêu cầu nghiệp vụ không phản ánh đầy đủ số lần thực thi thực tế.
Điều kiện thu tiền khi lỗi phụ thuộc nhà cung cấp và endpoint. Nhật ký chi phí vì thế cần nối được tác vụ gốc với từng lần thử, trạng thái đầu ra, số kết quả và khoản phí thực tế. Khi chưa có dữ liệu vận hành, nên lập một kịch bản retry cao thay vì mặc định tỷ lệ này bằng không.
4. Ba kịch bản tải có thể cho ba lựa chọn khác nhau
Các phép tính dưới đây là ví dụ giả định, dùng mức 0,003 USD mỗi lượt trong tài liệu Monid và gói SaaS giả định 49 USD mỗi tháng. Chúng chưa gồm thuế, tỷ giá, phí kết nối hoặc nhân sự và chỉ có giá trị khi hai phương án tạo ra kết quả tương đương.
- Tải thấp: 1.000 tác vụ, mỗi tác vụ một lượt ban đầu, retry 5%. API có 1.050 lượt, tương đương 3,15 USD; trả theo dùng có lợi thế lớn nếu chi phí tích hợp không xóa hết phần chênh lệch.
- Tải biến động: 4.000–20.000 tác vụ, retry 10%. Chi phí API dao động từ 13,20 đến 66 USD. SaaS rẻ hơn ở tháng cao điểm nhưng tạo công suất trả trước chưa dùng ở tháng thấp, nên cần so tổng chi phí của một chu kỳ tải đại diện.
- Tải ổn định: 30.000 tác vụ, retry 2%. API tốn khoảng 91,80 USD; gói 49 USD có lợi thế nếu không thu thêm phí và đáp ứng cùng yêu cầu về chất lượng, giới hạn và xuất dữ liệu.
Vì vậy, mô hình trả theo mức dùng đáng cân nhắc khi số ghế không phản ánh lượng công việc thực tế. Với tải dao động quanh điểm hòa vốn, cấu trúc lai gồm phí nền tảng thấp và phần dùng thực tế có thể dễ kiểm soát hơn một thuê bao cố định.
5. Chi phí kiểm soát quyết định ngưỡng cuối cùng
API không chỉ có giá endpoint. Quy trình của Monid cho phép agent khám phá công cụ, kiểm tra schema và giá trước khi chạy; nền tảng đảm nhiệm phần tin cậy, thanh toán và hoàn tất giao dịch giữa agent với công cụ. Biết giá trước khi gọi hỗ trợ đặt trần ngân sách, nhưng startup vẫn phải xác định đầu ra hợp lệ và điều kiện được phép retry.
G_api nên gồm thời gian xây tích hợp, theo dõi chi tiêu, chống gọi trùng, đánh giá chất lượng và xử lý lỗi nhà cung cấp. G_saas gồm quản trị tài khoản, đào tạo, thao tác thủ công còn lại, kiểm tra hạn mức và xuất dữ liệu. Có thể quy đổi mỗi phần thành số giờ mỗi tháng nhân với chi phí giờ nội bộ, miễn là dùng cùng phương pháp cho cả hai phía.
Thay vì giữ một con số hòa vốn duy nhất, nên tính ba ngưỡng: tải cơ sở, kịch bản xấu khi retry hoặc số kết quả tăng, và tải cao điểm khi SaaS bắt đầu thu vượt mức. API phù hợp khi phần lớn tải nằm dưới các ngưỡng; thuê bao có lợi khi sản lượng ổn định vượt ngưỡng và các giới hạn hợp đồng vẫn đáp ứng nhu cầu. Nếu kết quả thay đổi giữa các kịch bản, độ linh hoạt và trần chi tiêu trở thành một phần của quyết định, không phải chi tiết phụ sau phép chia.
Đọc thêm:
Đăng ký bản tin
Nhận tin Web3, AI và tiền mã hóa mới nhất ngay trong hộp thư.