Tóm tắt
Speculative decoding giúp vLLM xác minh nhiều token nháp trong một lượt chạy của target model thay vì luôn tiến từng token. Cách này vẫn giữ target model chịu trách nhiệm cho output cuối cùng, nhưng có thể giảm số vòng decode khi nhiều token nháp được chấp nhận.
Bài thử nghiệm năm phương pháp trên AMD Instinct MI300X và MI355X cho thấy mức tăng throughput phụ thuộc mạnh vào model, draft checkpoint, workload, độ dài proposal và acceptance behavior. Một số cấu hình vượt 2× baseline, nhưng cũng có cấu hình chỉ tăng nhẹ hoặc chậm hơn autoregressive decoding. Vì vậy, speculative decoding nên được xem là một bài toán tuning theo workload, không phải một preset chung.
Cơ chế draft-and-verify
Autoregressive decoding thông thường tạo một token, nối token đó vào context rồi chạy lượt kế tiếp. Speculative decoding chèn một draft component nhẹ hơn trước target model:
- Draft component đề xuất một chuỗi token tương lai.
- Target model kiểm tra cả chuỗi trong một verification pass.
- Token được chấp nhận từ trái sang phải.
- Khi gặp token đầu tiên bị từ chối, các candidate phía sau bị bỏ; target model cung cấp token thay thế và vòng mới bắt đầu.
Lợi ích chỉ xuất hiện khi phần decode của target model được tiết kiệm nhiều hơn chi phí tạo draft và xác minh. Acceptance rate cao chưa tự động đồng nghĩa với throughput cao nếu draft component quá nặng.
Năm phương pháp được thử
Native MTP
Multi-Token Prediction dùng nhánh dự đoán phụ đã nằm trong kiến trúc target model. Nhánh này kết hợp hidden representation của target với embedding của token gần nhất rồi tạo candidate tuần tự. Checkpoint không cần một draft model riêng, nhưng proposal dài hơn vẫn làm tăng số bước draft tuần tự.
Gemma 4 MTP
Gemma 4 dùng một MTP checkpoint đóng gói riêng và ghép với đúng target model. Draft component nhận activation từ target và dùng chung KV cache. Nó vẫn tạo token nháp tuần tự, nên num_speculative_tokens quá lớn có thể làm chi phí draft lấn át phần decode tiết kiệm được.
EAGLE-3
EAGLE-3 thu hidden state ở đầu, giữa và cuối target Transformer, nối rồi project chúng thành feature cho draft decoder. Candidate tiếp theo được tạo autoregressively từ output trước. Draft network phải được train cho target model tương ứng.
DFlash
DFlash dùng hidden state của target để dự đoán một block token song song. Cách tạo block giảm chuỗi bước tuần tự, nhưng checkpoint thường được train với block size cố định. Proposal tối đa không nhất thiết là lựa chọn nhanh nhất trong production.
DSpark
DSpark cũng khởi đầu bằng dự đoán song song, sau đó thêm causal correction nhẹ để candidate phía sau phụ thuộc vào token đã chọn trước đó. Thiết kế có confidence head để rút ngắn prefix, nhưng chức năng đó chưa hoạt động trong đường chạy vLLM dùng cho các phép đo của bài viết.
Bật speculative decoding trong vLLM
Với native MTP, không cần truyền draft checkpoint:
vllm serve <target-model> \
--speculative-config '{
"method": "mtp",
"num_speculative_tokens": 1
}'Với Gemma 4 MTP, EAGLE-3, DFlash hoặc DSpark, cấu hình thường trỏ tới checkpoint tương thích:
vllm serve <target-model> \
--speculative-config '{
"method": "<method>",
"model": "<matching-draft-checkpoint>",
"num_speculative_tokens": <N>
}'Trước khi serve, cần kiểm tra phiên bản vLLM hỗ trợ method và kiến trúc, draft checkpoint khớp target model, giá trị num_speculative_tokens hợp lệ và model card hỗ trợ hardware/backend đang dùng.
Kết quả benchmark chính
Nhóm tác giả đo output token mỗi giây trên các task GSM8K, MATH500, HumanEval, MBPP và một số workload khác. Kết quả nổi bật gồm:
- Với Gemma 4 26B, Gemma 4 MTP đạt tối đa 2,74× trên GSM8K và 2,62× trên MBPP. DFlash đạt 2,87× trên MATH500 và 2,79× trên HumanEval; EAGLE-3 nằm trong khoảng 2,11–2,27× trên bốn dataset.
- Với Gemma 4 31B, Gemma 4 MTP đạt khoảng 2× trên GSM8K và MBPP; DFlash đạt 2,34× trên MATH500 và 2,05× trên HumanEval.
- Với Qwen3 8B, mức tăng khiêm tốn hơn. DSpark nằm trong khoảng 1,15–1,63×; EAGLE-3 còn thấp hơn baseline ở phép đo MATH500 tốt nhất của nó.
- Nhóm Qwen3.5 và Qwen3.6 cho thấy hai model cùng family vẫn có điểm tối ưu khác nhau. Qwen3.6 35B A3B hợp với DFlash hơn native MTP trong các sweep được thử, trái với một số model Qwen dense.
- EAGLE-3 đạt tới 2,09× trên HumanEval với MiniMax M3 MXFP8. Với Kimi K2.5, EAGLE-3 đạt tối đa 2,33× và DFlash đạt 2,68×.
Các con số này đến từ cấu hình cụ thể trên hệ thống 8× MI300X, và MI355X cho thử nghiệm MiniMax. Chúng không phải cam kết hiệu năng cho batch size, prompt length, sampling setting hoặc concurrency khác.
Cách tuning thực tế
Bắt đầu ngắn rồi sweep
Với native MTP, N=1 là điểm bắt đầu thận trọng. Sau khi kiểm tra correctness và stability, hãy thử lần lượt 2–7. Trong benchmark, giá trị tốt nhất đổi theo model và dataset; ngay cả các model cùng family cũng không có một N chung.
Với DFlash, nên bắt đầu từ độ dài checkpoint hỗ trợ rồi thử các giá trị như 3, 7, 11 và 15. Bài viết thường thấy N=7 nằm trong nhóm nhanh hơn, nhưng một số workload đạt đỉnh ở N=11; N=15 chỉ là proposal tối đa cho checkpoint block size 16, không phải mặc định tối ưu.
Theo dõi nhiều hơn acceptance rate
Các metric quan trọng gồm:
- end-to-end throughput so với baseline;
- mean accepted length;
- overall acceptance rate;
- acceptance rate ở từng vị trí trong proposal;
- draft latency và GPU memory.
Nếu các vị trí đầu được chấp nhận thường xuyên nhưng candidate phía sau gần như không đóng góp, giảm num_speculative_tokens có thể nhanh hơn. Ngược lại, draft rất rẻ vẫn có thể đem lại throughput tốt dù acceptance rate không cao.
Benchmark đúng workload
Prompt toán, code, chat, tool use và multilingual tạo pattern acceptance khác nhau. Hãy dùng prompt, concurrency, input/output length và sampling giống production; giữ một baseline không speculative và chọn cấu hình theo metric phục vụ SLO của hệ thống. Training loss của speculator không thay thế được phép đo serving end-to-end.
Ý nghĩa với Dev
Speculative decoding đáng thử khi target-model decode đang là bottleneck và đã có draft checkpoint tương thích. Giá trị lớn nhất của bài viết không phải kỷ lục 2,87×, mà là quy trình đo: bắt đầu từ cấu hình được hỗ trợ, sweep proposal length, nhìn acceptance theo vị trí và giữ quyết định gắn với workload thật.
Nếu stack dùng AMD workstation thay vì Instinct datacenter GPU, cần thận trọng hơn khi ngoại suy. Thảo luận HN cũng nêu khoảng cách tối ưu cho R9700 giữa vLLM gốc và một số fork. Hãy xác minh bằng chính hardware, driver, ROCm và model sẽ triển khai trước khi thay đổi cấu hình mặc định.