06 · Xác suất, lấy mẫu và thống kê benchmark
Nguồn: fanout.sh / inference-eng / 00-04 · ~8 phút
Ghi chú
Đầu ra của model là một lần rút ngẫu nhiên từ một phân phối xác suất, nên cùng một prompt cho ra văn bản khác nhau với độ dài khác nhau. Điều đó làm latency của request thành một phân phối lệch có đuôi dài: hãy báo P50 / P95 / P99, đừng chỉ báo trung bình. Percentile ở đuôi cần rất nhiều mẫu, nên luôn nói rõ bao nhiêu mẫu. Và một chênh lệch đo được chỉ có ý nghĩa khi nó lớn hơn nhiễu giữa các lần chạy.
Hai câu đố có chung một gốc là tính ngẫu nhiên: một benchmark cho 41,6 tok/s, sau khi đổi cấu hình thì cho 42,4 tok/s (nhanh hơn thật không?), và hỏi model cùng một câu hai lần thì được hai câu trả lời khác nhau.
1. Phân phối và lấy mẫu
- Với "the sky is", model trả về xác suất cho mọi token tiếp theo có thể có: blue 62%, clear 14%, dark 8%, mọi thứ còn lại 16%. Mỗi kết quả nhận một số trong [0, 1] và tổng của chúng đúng bằng 1.
- Lấy mẫu (sampling) = một lần rút ngẫu nhiên. Xếp các xác suất nối đuôi nhau trên đoạn 0–1, chọn một điểm ngẫu nhiên đều; nó rơi vào đoạn của token nào thì token đó được chọn.
Trái: mỗi token sở hữu một đoạn trên đường 0–1. Phải: qua vài lần rút, "blue" dao động; qua hàng nghìn lần thì ổn định ở 62%.
Quan trọng
Mỗi token là một lần rút mới. Đó là lý do cùng một prompt có thể cho câu trả lời khác nhau.
2. Tính ngẫu nhiên lọt vào hiệu năng
Một câu trả lời kết thúc khi model rút trúng token kết thúc văn bản (end-of-text). Xác suất nhỏ cho chuyện đó ở mỗi bước khiến có câu trả lời dừng sau 40 token, có câu kéo tới 400. Mỗi bước decode tốn thời gian gần như nhau, nên độ dài câu trả lời quyết định thời gian của request.
Mô phỏng: cùng một prompt gửi 1.000 lần cho ra độ dài câu trả lời trải rất rộng.
Vì vậy một benchmark không bao giờ đo một latency; nó đo một phân phối latency.
3. Trung bình, trung vị và phần đuôi
1.000 request (minh hoạ): phần lớn quanh 1 giây, nhưng xếp hàng và câu trả lời dài kéo một cái đuôi sang phải.
| Đại lượng tóm tắt | Cách tính | Ở đây | Dùng để |
|---|---|---|---|
| Trung bình (mean) | Tổng ÷ số lượng | 1,3 s (bị đuôi kéo sang phải) | Gần như không mô tả ai khi đuôi dài |
| Trung vị (P50) | Request ở giữa: một nửa nhanh hơn, một nửa chậm hơn | 1,1 s | Request điển hình |
Phần đuôi, những request chậm nhất, chính là thứ người dùng phàn nàn.
4. Percentile mô tả phần đuôi
Sắp xếp 1.000 giá trị latency. P50 là giá trị ở vị trí 500, P95 ở 950 (95% nhanh hơn), P99 ở 990 (chỉ 1 trên 100 chậm hơn).
Ở đây P50 = 1,1 s, P95 = 2,5 s, P99 = 4,6 s.
Vì sao phải quan tâm tới 1 trên 100? Trang web và agent thật thực hiện nhiều lần gọi cho mỗi thao tác của người dùng:
Mỗi thao tác càng nhiều lần gọi, càng hay có người gặp phải một lần gọi chậm.
Quan trọng
Phần đuôi của từng lần gọi trở thành trải nghiệm điển hình của cả tác vụ. Đó là lý do mục tiêu serving được đặt theo percentile, ví dụ P99 time to first token < 2 s.
5. Một percentile cần bao nhiêu mẫu?
Chỉ với 100 request, P99 là giá trị ở vị trí 99, do một request chậm nhất duy nhất quyết định. Chạy lại bài test là request đó đổi, nên P99 nhảy lung tung.
Mô phỏng các lần chạy lại: P99 từ 100 request dao động rất rộng; từ 10.000 request thì gần như không nhúc nhích.
Quy tắc kinh nghiệm: khoảng 100 mẫu nằm ngoài percentile bạn báo cáo cho ước lượng ổn định tới khoảng 1/√100 = 10%.
| Báo cáo | Tỷ lệ nằm ngoài | Số request cần |
|---|---|---|
| P50 (trung vị) | 50% | 200 |
| P95 | 5% | 2.000 |
| P99 | 1% | 10.000 |
Mẹo
Mỗi khi thấy một con số P99, hãy hỏi: trên tổng bao nhiêu request?
6. Speedup thật, hay chỉ là nhiễu?
Quay lại 41,6 so với 42,4 tok/s. Cách làm trung thực: chạy mỗi cấu hình vài lần. Năm lần mỗi bên: A rơi vào khoảng ~40,5 tới gần 43, B từ ~41,5 tới 43. Hai khoảng chồng lên nhau rất nhiều.
- Độ lệch chuẩn (standard deviation) (độ trải của các lần chạy): σ ≈ 0,8 tok/s.
- Sai số chuẩn (standard error) của trung bình giảm theo √n: SE = σ/√n = 0,8/√5 ≈ 0,4.
- Với hiệu của hai trung bình, dải nhiễu vào khoảng ±1 tok/s. Chênh lệch quan sát được chỉ là 0,7, nằm trong nhiễu.
Với 5 lần chạy mỗi bên, dải nhiễu cắt qua 0: không thể kết luận B nhanh hơn. Chạy gấp 4 lần thì dải hẹp đi một nửa; nếu 0,7 vẫn giữ nguyên thì nó sẽ vượt khỏi 0.
Quan trọng
Trước khi gọi một thứ là speedup, hãy so nó với nhiễu giữa các lần chạy.
7. Tóm tắt
