Phản hồi streaming và các lượt sinh bị bỏ dở
Cập nhật September 9, 2026 · đăng lần đầu September 9, 2026
Streaming làm sản phẩm AI cảm giác nhanh, nhưng cũng khiến một phản hồi chưa xong dễ bị nhầm với một yêu cầu đã hủy. Người dùng đóng tab, mất kết nối, hoặc bấm dừng; nhà cung cấp có thể vẫn tiếp tục sinh chữ cho đến khi yêu cầu bị hủy hoặc đầu ra chạm giới hạn. Phần phản hồi hiển thị ngắn hơn, nhưng hóa đơn không nhất thiết ngắn hơn.
Phần đuôi bị bỏ là chi phí thật
Theo dõi ba sự kiện riêng biệt: thời gian đến token đầu tiên, số token đã gửi tới client, và số token đã sinh phía upstream. Khoảng chênh giữa đầu ra đã gửi và đầu ra đã sinh chính là phần đuôi bị bỏ. Đó là công việc người dùng không bao giờ nhận được, và nó có thể lớn trong các câu trả lời dài, agent lập trình và quy trình dùng công cụ.
Đừng chỉ đo điều này như một tỷ lệ phần trăm trên số yêu cầu. Một số ít lượt sinh bị bỏ với số token lớn có thể chiếm phần lớn lãng phí. Hãy báo cáo số token đầu ra bị bỏ và chi phí của chúng theo tính năng, mô hình, thiết bị, loại kết nối và lý do hủy.
Việc hủy phải truyền được lên upstream
Dừng trình duyệt hiển thị không giống với dừng yêu cầu tới mô hình. Hãy truyền việc client ngắt kết nối hoặc hành động dừng tường minh qua gateway đến yêu cầu gửi nhà cung cấp. Đặt một khoảng chờ ngắn cho các lần kết nối lại, rồi mới hủy. Với quy trình agent, hãy hủy lượt sinh đang chạy và mọi công việc công cụ đang xếp hàng mà cha của nó không còn tồn tại.
Giữ một định danh yêu cầu có tính idempotent để một cuộc đua giữa các lệnh hủy không tạo ra ghi nhận kế toán bị trùng. Ghi lại việc nhà cung cấp có xác nhận đã hủy hay chưa; nếu không, hãy xếp số token còn lại vào chi tiêu chưa chắc chắn thay vì âm thầm coi đó là khoản tiết kiệm.
Dùng một KPI tốt hơn
Chi phí mỗi yêu cầu gây hiểu lầm khi nhiều phản hồi bị bỏ. Hãy dùng chi phí mỗi phản hồi đã gửi và chi phí mỗi tác vụ thành công, rồi hiển thị tỷ lệ bỏ dở bên cạnh cả hai. Một thay đổi sản phẩm làm tăng thời gian đến token đầu tiên có thể làm tăng tỷ lệ bỏ dở ngay cả khi tổng số token mỗi yêu cầu không đổi.
Các kiểm soát thực tế
- Phát một sự kiện hủy kèm yêu cầu, tính năng, mô hình và bộ đếm token.
- Hủy công việc upstream khi ngắt kết nối và khi có lệnh dừng tường minh.
- Giới hạn đầu ra tối đa cho khối lượng công việc tương tác.
- So sánh token đã sinh, đã gửi và đã tính phí khi đối soát hóa đơn.
- Cảnh báo khi chi phí token bị bỏ tăng nhanh hơn khối lượng tác vụ thành công.
Liên quan
Liên quan
Bạn muốn áp dụng điều này cho hệ thống của mình? Hãy mang theo hóa đơn nhà cung cấp, nhật ký gateway và các quy trình chính; chúng tôi sẽ xác định yếu tố chi phí và hướng tiết kiệm. Đặt lịch kiểm toán miễn phí →