Đo lường bốn tín hiệu độ trễ khác nhau
Một con số độ trễ duy nhất sẽ che khuất nơi người dùng phải chờ. Chat streaming có thể tạo cảm giác nhanh nhờ TTFT thấp ngay cả khi quá trình hoàn tất toàn bộ mất nhiều thời gian hơn, trong khi tác vụ trích xuất hàng loạt có thể chỉ quan tâm đến thời lượng đầu-cuối.
- Thời gian đến token đầu tiên: khoảng thời gian từ lúc bắt đầu yêu cầu đến khi nhận được token đầu tiên qua streaming.
- Thông lượng sinh token: số token đầu ra chia cho thời gian sinh token.
- Thời lượng đầu-cuối: khoảng thời gian từ lúc bắt đầu yêu cầu đến khi nhận được phản hồi hoàn chỉnh.
- Độ tin cậy: số phản hồi thành công chia cho tổng số lần thử.
Kiểm soát khối lượng công việc điểm chuẩn
Sử dụng một tập prompt cố định đại diện cho khối lượng công việc dự kiến. Ghi lại ID mô hình, route của nhà cung cấp, khu vực, các tham số yêu cầu, số token đầu vào và độ dài đầu ra được yêu cầu.
- Thực hiện các yêu cầu khởi động trước khi ghi nhận số liệu đo lường.
- Ngẫu nhiên hóa thứ tự nhà cung cấp để giảm sai lệch theo thời điểm trong ngày.
- Lặp lại các bài kiểm thử trong nhiều khoảng thời gian có lưu lượng khác nhau.
- Tách riêng kết quả streaming và không streaming.
Sử dụng phân phối thay vì ảnh chụp bảng xếp hạng
Báo cáo các giá trị trung vị, p90 và p95 cùng với kích thước mẫu. Một route có giá trị trung vị nhanh nhất nhưng thường xuyên xuất hiện độ trễ cực lớn có thể mang lại trải nghiệm production kém hơn so với một route chậm hơn đôi chút nhưng ổn định hơn.
{
"sample_size": 100,
"ttft_ms": { "median": 640, "p95": 1840 },
"output_tokens_per_second": { "median": 42.1 },
"end_to_end_ms": { "median": 5120, "p95": 9080 },
"success_rate": 0.98
}Các giá trị trên là định dạng báo cáo mang tính minh họa, không phải kết quả điểm chuẩn CometAPI trực tiếp.
Công bố phương pháp trong mọi báo cáo
Một điểm chuẩn chỉ hữu ích khi người đọc có thể hiểu nội dung được đo lường và tái tạo phương pháp thực hiện. Hãy nêu rõ các giới hạn, đồng thời giải thích liệu route của nhà cung cấp có được cố định hay được tự động lựa chọn.