Speculative decoding làm vLLM chậm hơn: toán acceptance rate

Bạn bật --speculative-config trên vLLM, gửi một request curl và thấy token bay vèo vèo. Rồi chạy load test 64 user đồng thời: throughput tổng tụt xuống, dù vẫn cùng GPU, cùng target model, cùng bộ prompt.

Cả hai phép đo đều đúng — chúng chỉ đang đo hai chế độ bottleneck khác nhau. Dưới đây là phần toán cần làm trước khi bật cờ này lên production, theo một phân tích đăng trên Dev.to.

Acceptance rate α mới là biến quyết định, không phải γ

Draft model nhỏ đoán trước γ token, target model verify cả γ vị trí trong một forward pass. Theo bài viết, số token kỳ vọng mỗi bước của model lớn là (1 - α^(γ+1)) / (1 - α), với α là acceptance rate. Ở α = 0,8 và γ = 4, con số đó là 3,36 token mỗi bước.

Chỗ dễ hiểu sai: kéo dài draft không cứu được một draft model yếu. Tác giả tính ở α = 0,4, tăng γ từ 4 lên 8 chỉ đưa token mỗi bước từ 1,65 lên 1,67, trong khi chi phí mỗi bước tăng từ 1,2 lên 1,4 lần forward pass — speedup rơi về khoảng 1,19x.

Hai ràng buộc đi kèm: draft model phải dùng chung tokenizer với target, vì verify so sánh token ID; và speculative decoding chỉ đổi tốc độ, không đổi chất lượng output — nếu chất lượng đổi, lỗi nằm ở chỗ khác.

Vì sao concurrency cao làm nó lỗ

Speedup chỉ tồn tại khi decode còn memory-bandwidth bound, tức batch nhỏ. Bài viết lấy thông số H100 công bố — khoảng 990 TFLOPS BF16 so với khoảng 3,35 TB/s bandwidth, tức khoảng 295 FLOP mỗi byte trước khi compute trở thành nút thắt.

Load test của tác giả: 64 sequence đồng thời, mỗi sequence verify 4 draft token cộng 1 vị trí bonus, thành 320 vị trí token mỗi forward pass — đã vượt qua điểm gãy. Khi đã compute bound, verify γ+1 vị trí tốn xấp xỉ γ+1 lần, và bảng tác giả đưa ra không có dòng nào thắng:

Acceptance rate α	Speedup khi compute bound (γ = 4)
0,9	0,79x
0,8	0,65x
0,6	0,44x
0,4	0,32x

Một bài học cùng hướng đến từ chỗ khác: nhóm Cascadia chạy model 975B tổng / 41B active trên 11 máy Intel Core Ultra X7 358H, và phải đo ở 15 mức concurrency từ 1 đến 176 stream mới thấy đỉnh 60,29 token/s decode tổng ở mức 88 stream. Không có con số throughput nào đúng nếu tách khỏi mức concurrency thật của bạn.

Đo α trên traffic thật trước khi tin bất kỳ con số nào

vLLM expose counter speculative decoding trên endpoint Prometheus: curl -s localhost:8000/metrics | grep spec_decode. Tên metric đổi theo phiên bản nên hãy grep thay vì hardcode. Từ đó, accepted / drafted là acceptance rate mỗi token, còn 1 + accepted / drafts là số token trung bình mỗi bước target.

Với α = 0,7, tác giả ước tính speedup lần lượt khoảng 2,31 / 1,26 / 0,87 / 0,53 ứng với verify_cost bằng 1, 2, 3 và 5 — điểm hoà vốn nằm quanh verify_cost ≈ 2,6. Temperature cao và prompt lệch domain đều kéo α xuống, nên một con số speedup luôn gắn với đúng một cặp model, một temperature, một domain và một batch size.

Việc nên làm tuần này

• Giữ num_speculative_tokens trong khoảng 2-4; draft dài chỉ có lãi khi α trên khoảng 0,8.
• Tắt speculation khi batch đầy — tìm disable_by_batch_size trong speculative config của phiên bản bạn dùng. Nếu bản đó không hỗ trợ, tách deployment: traffic latency-sensitive đi bản speculative, traffic bulk đi bản thường.
• Workload sửa code hoặc rewrite tài liệu: thử n-gram (prompt lookup) drafting với {"method": "ngram", "num_speculative_tokens": 4, "prompt_lookup_max": 4} — không cần draft model, acceptance cao trên text copy nhiều.
• Đo α tách theo từng workload. Một con số trung bình gộp chat lẫn batch sẽ che mất đúng chỗ đang lỗ.