[ blog · deep-dive ]7 min read

Vì sao API chỉ nên tính phí khi thành công — Lập luận cho việc tính phí theo HTTP 200

Sarah ChoyĐăng ngày 3 tháng 5, 20267 phút đọc

Hầu hết API tính phí trên mọi lệnh gọi có thể tính tiền. Các agent AI liên tục thử lại đối với những dịch vụ upstream không ổn định — nghĩa là mô hình cũ 'luôn tính phí' thực chất đang đánh thuế lên khả năng phục hồi. Đây là lập luận cho việc chỉ tính phí khi HTTP 200, và nó thay đổi điều gì trong cách bạn thiết kế agent.

Tóm tắt

•Các agent AI thử lại một cách hợp lý khi gặp lỗi tạm thời (5xx, timeout, rate limit). Theo cách tính phí 'luôn tính phí', mỗi lần thử lại là một khoản phí thật — biến một upstream có uptime 99,5% thành mức phạt chi phí 5× trong khoảng 0,5% tệ hại đó.
•'Chỉ tính phí khi HTTP 200' căn chỉnh động lực của nhà cung cấp với động lực của khách hàng: nhà cung cấp khắc phục sự bất ổn, khách hàng không phải trả tiền cho nó.
•Nó cũng mở khóa các mẫu thiết kế — ngân sách thử lại quyết liệt, prefetching lạc quan, các lệnh gọi dư thừa — những thứ mà 'luôn tính phí' khiến trở nên đắt đỏ không thể chấp nhận.
•Hầu hết nhà cung cấp không làm điều này vì hạ tầng cũ của họ gắn việc đo đếm vào lệnh gọi upstream, chứ không phải phản hồi. Đó là một hạn chế của hệ thống tính phí được khoác lên dưới dạng chính sách.

Hành vi mà chúng tôi đang cố khuyến khích

Các agent AI là một loại API client kiểu mới. Chúng không phải là những integration doanh nghiệp cẩn trọng của năm 2015, bắt được một lỗi rồi gửi email cho một kỹ sư trực. Chúng là những vòng lặp mà khi có thứ gì đó thất bại, sẽ ngủ một lát rồi thử lại — đôi khi năm hay mười lần — và thậm chí không hề hiển thị kết quả cho con người. Toàn bộ ý nghĩa của vòng lặp là để các lỗi tạm thời trở nên vô hình đối với người dùng cuối.

Đó là một mẫu hình tuyệt vời. Nó tạo ra những sản phẩm có khả năng phục hồi. Nó che giấu khỏi người dùng cái thực tế hỗn độn của internet công cộng. Vấn đề là mô hình tính phí API được thiết lập trong một kỷ nguyên khi việc thử lại còn hiếm và đủ tốn kém để mặc định bị ngăn cản. Nó vẫn vận hành theo cách đó. Mỗi lần thử lại là một lệnh gọi có thể tính tiền, bất kể nó có trả về gì hay không.

Cụ thể: một agent gọi tới một API có uptime 99,5% và thử lại tới năm lần khi gặp lỗi tạm thời sẽ, trong khoảng 0,5% tệ hại đó, tạo ra tới 5× số lệnh gọi — và 5× hóa đơn. Agent đã làm đúng. Khách hàng phải trả cho sự bất ổn của upstream.

Lựa chọn thay thế đơn giản hơn

Chỉ tính phí khi HTTP 200. Cụ thể, chỉ trên một phản hồi thành công với hình dạng phản hồi đã được ghi tài liệu. Mọi thứ khác — 4xx cho lỗi của bên gọi, 5xx cho lỗi của chúng tôi, timeout, rate limit, các phản hồi một-phần-nhưng-sai-định-dạng — đều miễn phí.

Nghe có vẻ là một thay đổi nhỏ. Không phải vậy. Nó thay đổi điều gì là hợp lý về mặt kinh tế đối với cả hai phía:

Nhà cung cấp giờ đây có một động lực tài chính trực tiếp để khắc phục sự bất ổn. Mỗi lỗi 503 chập chờn là một thương vụ bị bỏ lỡ, không phải bữa trưa miễn phí. Chúng tôi nhận ra rằng việc áp dụng tính phí chỉ-khi-thành-công là lực lượng đơn lẻ lớn nhất kéo công việc về độ tin cậy lên đầu roadmap — không có mẹo bảng tính nào khiến thời gian downtime trông ổn khi bạn đang từ bỏ doanh thu từ những lệnh gọi đó.
Khách hàng có thể định cỡ ngân sách thử lại một cách quyết liệt. Một vòng lặp 5 lần thử lại với backoff theo cấp số nhân là điều hiển nhiên khi trường hợp tệ nhất của một lỗi tạm thời là một lệnh gọi tính phí (lần thành công cuối cùng) thay vì sáu (một lần tính phí cho mỗi lần thử).
Thị trường có thể so sánh các API theo đô-la-trên-mỗi-lệnh-gọi-thành-công thay vì đô-la-trên-mỗi-lần-thử. Đó mới là đơn vị đúng. Nếu cả hai API đều công bố '$0.001 mỗi lệnh gọi' nhưng một bên ở mức uptime 99,9% còn bên kia ở 95%, thì chi phí mà người dùng nhìn thấy chênh nhau 5× theo 'luôn tính phí', và đúng bằng 0% theo 'chỉ khi thành công'. Người mua nên chọn cái nào là điều hiển nhiên — và 'chỉ khi thành công' làm cho điều đó trở nên rõ ràng.

Điều gì thay đổi trong cách bạn xây dựng agent

1. Ngân sách thử lại trở nên miễn phí

Theo cách tính phí 'luôn tính phí', ngân sách thử lại đúng đắn cho một trình xử lý lỗi tạm thời là khoảng 1–2 lần thử — vượt quá đó thì chi phí của những lần thất bại lặp lại bắt đầu có ý nghĩa. Theo 'chỉ khi thành công', ngân sách là 'người dùng chờ được bao lâu thì bấy nhiêu'. Chúng tôi thường xuyên thấy các vòng lặp agent với mẫu 5 lần thử lại, backoff theo cấp số nhân, có jitter mà nếu theo cách tính phí cũ sẽ là liều lĩnh.

2. Prefetching lạc quan trở nên rẻ

Một mẫu hình đắt đỏ không thể chấp nhận theo 'luôn tính phí': khởi động một lệnh gọi tìm kiếm mang tính phỏng đoán trong khi người dùng vẫn còn đang gõ, phòng khi truy vấn được dự đoán là đúng. Nếu dự đoán sai, bạn vứt bỏ kết quả. Theo 'chỉ khi thành công' điều này rẻ vì các lệnh gọi bị hủy / không dùng đến vẫn trả về thành công nhưng bạn loại bỏ phản hồi — nên bạn trả một khoản phụ phí nhỏ cho khả năng dự đoán và độ trễ. Theo 'luôn tính phí', mỗi dự đoán sai là một lệnh gọi tính phí, khiến heuristic này quá đắt để đưa vào sản phẩm.

3. Các lệnh gọi dư thừa trở thành công cụ về độ tin cậy

Đôi khi chiến lược độ tin cậy rẻ nhất là bắn hai request tới hai API khác nhau, lấy cái nào trả về trước, rồi loại bỏ cái chậm hơn. Theo 'luôn tính phí' điều đó nhân đôi hóa đơn của bạn. Theo 'chỉ khi thành công' nó miễn phí cho lệnh gọi bị loại bỏ (bạn không dùng phản hồi, bạn không trả tiền cho nó). Bỗng nhiên những chiến lược hedging từng là các trừu tượng đắt đỏ trở nên thực tế.

'Thành công' phải có nghĩa là gì

Mô hình chỉ vận hành nếu 'thành công' là rõ ràng không mơ hồ. Chúng tôi định nghĩa nó một cách chặt chẽ:

HTTP 200 với schema phản hồi đã ghi tài liệu — có thể tính phí.
HTTP 200 với một lỗi được bọc trong body phản hồi — không tính phí (đây sẽ là lỗ hổng phá vỡ toàn bộ mô hình).
HTTP 4xx — không tính phí. Bao gồm 401 (auth), 402 (không đủ credit), 422 (validation), 404 (không tìm thấy trong một số ngữ cảnh).
HTTP 5xx — không tính phí.
HTTP 429 (rate limit) — không tính phí.
Lỗi mạng / timeout trước edge của chúng tôi — không tính phí.

Đối với các endpoint hàng loạt (ví dụ URL Extract với 25 URL trong một lệnh gọi), cả lệnh gọi xét tổng thể là một HTTP 200 nếu bất kỳ URL nào thành công, được tính phí theo mức giá trên mỗi URL. Trường status theo từng URL cho bên gọi biết những URL nào đã thất bại. Công việc đã được làm; nó có thể tính phí.

Vì sao hầu hết nhà cung cấp không làm điều này

Ba lý do, theo thứ tự mức độ quan trọng của từng cái:

Hạ tầng tính phí. Mẫu hình tiêu chuẩn là đo đếm tại API gateway, trước khi biết phản hồi. Gateway phát ra một sự kiện có thể tính tiền vào Kafka, hệ thống tính phí tổng hợp lại, hóa đơn được gửi đi. Đấu nối lại việc đo đếm để kích hoạt sau khi dịch vụ upstream đã trả lời bằng một mã trạng thái đòi hỏi hoặc (a) gắn gateway với tình trạng sức khỏe của backend (tạo ra các chế độ lỗi mới) hoặc (b) viết một pipeline đối soát để hoàn lại credit một cách hồi tố cho các lệnh gọi thất bại. Cả hai đều là công việc kỹ thuật thật sự.
Thói quen. Mẫu hình này được thiết lập bởi các backend đáng tin cậy — Twilio, AWS, Stripe. Nó hoạt động tốt khi upstream của bạn ở mức uptime 99,99%. Những API bọc quanh LLM, scraping web, hay gọi tới các đối tác dữ liệu chậm chạp thì kém tin cậy hơn nhiều, nhưng mẫu hình tính phí được thừa hưởng từ kỷ nguyên đáng tin cậy và chưa bao giờ được cập nhật.
Doanh thu. 'Luôn tính phí' đơn giản là nhiều tiền hơn. Hầu hết nhà cung cấp chưa phải cạnh tranh trên chiều này vì phần lớn khách hàng của họ chưa phải là lưu lượng agent, và người dùng đồng bộ là con người chịu đựng những lỗi thi thoảng tốt hơn là chịu đựng việc phải đọc một mô hình tính phí.

Lý do đầu tiên là kỹ thuật thật sự. Lý do thứ hai và thứ ba là quán tính. Cả hai sẽ nhường bước khi lưu lượng agent trở thành phần lớn lượng tiêu thụ API — điều mà các đường xu hướng cho thấy đang diễn ra trong vòng 18 tháng đối với hầu hết các API công khai.

Cần tìm gì với tư cách người mua

Nếu bạn đang đánh giá các API dữ liệu cho một workload agent, ba câu hỏi rõ ràng:

'Các bạn chỉ tính phí khi HTTP 200, hay trên mỗi lần thử có thể tính tiền?' — cần một câu trả lời thẳng thắn. Đừng chấp nhận 'thường thì' hay 'tùy gói'.
'HTTP 207 / thành công một phần được tính phí như thế nào?' — moi ra câu trả lời về lỗ hổng.
'Uptime công bố của các bạn là bao nhiêu, và cơ chế hoàn tiền theo SLA là gì nếu các bạn không đạt được?' — 'chỉ khi thành công' là một tín hiệu mạnh nhưng không thay thế cho một SLA thực sự. Cả hai đều nên hiện diện.

Sự dịch chuyển mà điều này đang chỉ tới

Các agent AI thay đổi kinh tế đơn vị của mọi API mà chúng chạm tới. Những API được thiết kế cho kỷ nguyên agent trông khác đi — hình dạng đơn giản hơn, schema có thể dự đoán, auth thân thiện với máy, định giá minh bạch — và mô hình tính phí của chúng cũng trông khác đi. 'Chỉ khi thành công' là một trong những sự dịch chuyển đơn giản hơn. Cái khó hơn, vẫn còn ở phía trước, là tìm ra cách định giá các quy trình agent nhiều bước xuyên qua các nhà cung cấp khi không một bên đơn lẻ nào sở hữu toàn bộ con đường.

Còn bây giờ, hãy đòi hỏi 'chỉ khi thành công' từ những nhà cung cấp mà bạn có thể. Hãy xây dựng các agent tận dụng nó. Và khi bạn đi mua một API, hãy tính toán theo đô-la-trên-mỗi-lệnh-gọi-thành-công, không phải đô-la-trên-mỗi-lần-thử.

Câu hỏi thường gặp

Chẳng phải 'chỉ khi thành công' khuyến khích nhà cung cấp phân loại sai thành công thành thất bại hay sao?

Về lý thuyết thì có, nhưng áp lực ngược lại còn mạnh hơn: các developer so sánh API dựa trên đô-la-trên-mỗi-lệnh-gọi-hữu-ích trong thực tế, và đó chính xác là điều mà 'chỉ khi thành công' đo lường. Một nhà cung cấp lén lút phân loại lại thành công thành thất bại sẽ đối mặt với một hàng đợi support giận dữ và một vệt đánh giá công khai chỉ trong vài ngày. Thị trường đủ nhỏ để điều này tự điều chỉnh.

Nếu lệnh gọi của tôi thành công một phần thì sao — ví dụ, một extract hàng loạt mà 2 trong 25 URL thất bại?

Hai mô hình hợp lý. (a) Cả lệnh gọi là HTTP 200 nếu bất kỳ URL nào thành công; các thất bại theo từng URL được báo cáo trong status theo từng URL. Công việc đã diễn ra, nên nó có thể tính phí. (b) HTTP 207 (multi-status) cho phần thành công một phần — mỗi URL được tính phí riêng. Chúng tôi chọn (a) vì nó làm cho việc định giá có thể dự đoán: agent biết rằng một HTTP 200 thành công nghĩa là trường hợp tệ nhất là chi phí credit đã công bố. (b) 'công bằng' hơn nhưng khó lập ngân sách hơn.

Điều gì được tính là thất bại?

Quy tắc của chúng tôi: một HTTP 4xx rõ ràng là lỗi của bên gọi (body sai định dạng, thiếu auth, không đủ credit) thì không bị tính phí. HTTP 5xx không bao giờ bị tính phí — đó là vấn đề của chúng tôi. Lỗi mạng và timeout ở phía chúng tôi không bao giờ bị tính phí. Rate limit (429) không bao giờ bị tính phí. Thứ duy nhất bị tính phí là một HTTP 200 với hình dạng phản hồi đã công bố.

Vì sao hầu hết nhà cung cấp tính phí trên mọi lệnh gọi?

Ba lý do, phần lớn mang tính lịch sử. (1) Các hệ thống tính phí cũ đo đếm tại API gateway, trước khi biết phản hồi. Việc đấu nối để tính phí kích hoạt một cách hồi tố dựa trên trạng thái phản hồi không hề đơn giản. (2) Mẫu hình này được Twilio và AWS thiết lập trong một kỷ nguyên có backend đáng tin cậy; những API bọc quanh LLM hay scraping web kém tin cậy hơn nhiều, nên giả định đó không còn đứng vững. (3) Nó cho nhiều doanh thu hơn. Hai lý do đầu là cái cớ; lý do thứ ba mới là sự thật.

Có trường hợp nào mà 'luôn tính phí' hợp lý không?

Khi lệnh gọi thực sự tiêu tốn một chi phí cố định trong mỗi lần gọi bất kể kết quả — ví dụ, một thao tác phần cứng (SMS đã gửi), một mutation có tính nguyên tử ở ranh giới (cập nhật DNS), hoặc một dịch vụ mà backend của nó không thể phân biệt 'chúng tôi đã thử và thất bại' với 'chúng tôi đã làm và bạn không nhận ra'. Với các API dữ liệu kiểu đọc và API tìm kiếm thì mô hình này không phù hợp.