GPU chạy 30% công suất — bạn vẫn trả 100% tiền

Speculative decoding đấu thêm model nhỏ vào pipeline, để GPU thật sự làm việc thay vì ngồi chờ token từng cái một.

Câu hỏi mà ít team tự hỏi

Bạn đang chạy inference cho coding agent hay writing assistant, hóa đơn GPU tháng nào cũng tăng, nhưng đã bao giờ bạn nhìn vào GPU utilization chưa? Nói thẳng ra thì: trong giai đoạn decode — lúc model sinh token từng cái một — phần cứng của bạn bị nghẽn ở memory bandwidth, không phải compute. GPU có hàng nghìn core mà phần lớn thời gian chỉ ngồi chờ đọc weight từ bộ nhớ.

Giống như một đường dây điện thiết kế chịu 100 ampe, nhưng thiết bị đầu cuối chỉ kéo 30. Bạn trả tiền cho toàn bộ đường dây, mà chỉ dùng một phần ba.

Đấu thêm mạch phụ — speculative decoding

Ý tưởng cốt lõi: thay vì để model lớn (target model) tự sinh từng token một, bạn đặt thêm một model nhỏ (draft model) chạy kèm. Model nhỏ "đoán trước" n token tiếp theo, rồi model lớn verify tất cả trong một forward pass duy nhất.

Bản chất thật sự: bạn đang đổi compute thừa lấy latency thấp hơn. Model lớn vốn đã underutilized khi decode — giờ nó nhận cả batch n token để verify cùng lúc, tận dụng compute mà trước đó bỏ phí.

Kết quả? Benchmark trên AWS Trainium với Qwen3 cho thấy tăng tốc lên đến 3x cho workload decode-heavy. Không mất chất lượng output vì model lớn vẫn là người quyết định cuối cùng — token nào không khớp, loại ngay.

Hai "nút vặn" bạn thật sự kiểm soát

Speculative decoding khi deploy chỉ cần quan tâm hai thứ:

1. Chọn draft model

Draft model phải cùng tokenizer (hoặc tương thích) với target model. Lý tưởng là phiên bản nhỏ hơn trong cùng họ — ví dụ Qwen3-0.6B làm draft cho Qwen3-32B. Model nhỏ quá thì đoán sai nhiều, model lớn quá thì mất ý nghĩa tăng tốc.

2. num_speculative_tokens

Số token mà draft model đề xuất mỗi lần. Đặt quá thấp (2–3) thì lợi ích không đáng kể. Đặt quá cao (16–20) thì tỷ lệ reject tăng, verification pass nặng hơn. Vùng sweet spot thường rơi khoảng 5–8, nhưng phụ thuộc workload cụ thể của bạn.

Kịch bản thực tế: team 4 người ở Sài Gòn

Ví dụ cụ thể: giả sử một team nhỏ đang self-host Qwen3-32B trên vLLM để chạy internal coding assistant. Mỗi response trung bình sinh khoảng 500 token, nhận vào khoảng 100 token context — tỷ lệ output/input 5:1, decode-heavy điển hình. Hóa đơn inference chiếm phần lớn chi phí hạ tầng, user phàn nàn latency cao.

Bước đi hợp lý:

  1. Benchmark baseline — đo inter-token latency với speculative decoding tắt
  2. Thêm draft model — load Qwen3-0.6B cùng pipeline, bật speculative decoding trong vLLM
  3. Tune — thử num_speculative_tokens từ 4 đến 10, đo latency + acceptance rate ở mỗi mức
  4. So sánh — cùng prompt set, latency giảm bao nhiêu phần trăm? Throughput tăng bao nhiêu?

Kịch bản thứ hai: team đang build AI writing assistant cho nội bộ, output dài (bài blog, email dài). Đây cũng là decode-heavy workload — speculative decoding giúp user không phải nhìn con trỏ nhấp nháy chờ đợi.

Bẫy mà mình thấy hay mắc nhất

"Draft model nào cũng được" — Sai. Nếu draft model dùng tokenizer khác target model, output sẽ lỗi âm thầm. Không phải lỗi crash — mà là loại lỗi bạn đọc output thấy "hơi kỳ" nhưng không biết tại sao. Như cắm thiết bị 110V vào ổ 220V — không nổ ngay, nhưng cháy dần từ bên trong.

"Speculative decoding lúc nào cũng nhanh hơn" — Không hẳn. Với prompt-heavy workload (input dài, output ngắn), giai đoạn prefill chiếm phần lớn thời gian — speculative decoding hầu như không giúp gì. Biết workload profile của mình trước khi bật.

"Bật lên rồi quên" — Acceptance rate thay đổi theo dạng content. Code generation có pattern khác hẳn summarization. Nên monitor acceptance rate liên tục và sẵn sàng điều chỉnh num_speculative_tokens.

Thử ngay chiều nay

Nếu bạn đang chạy vLLM (0.7.x trở lên), đây là bước tối thiểu:

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen3-32B \
  --speculative-model Qwen/Qwen3-0.6B \
  --num-speculative-tokens 5 \
  --tensor-parallel-size 4

Chạy benchmark trước/sau với cùng prompt set. Ghi lại bốn con số: latency P50, P99, throughput (tokens/sec), và acceptance rate. Nếu acceptance rate dưới 40%, draft model chưa phù hợp — thử model khác hoặc giảm num_speculative_tokens.

Với team đang dùng Kubernetes, quy trình deploy tương tự — chỉ thêm flag vào container spec. AWS có hướng dẫn cụ thể cho Trainium instance, nhưng nguyên lý áp dụng cho bất kỳ phần cứng nào vLLM hỗ trợ.

Một takeaway duy nhất

Speculative decoding không phải tối ưu kiểu "thêm tài nguyên" — mà là tối ưu kiểu "dùng hết tài nguyên đang có". GPU của bạn đã đủ mạnh, nó chỉ đang ngồi chờ việc.

Đừng tin mình, thử đi rồi biết.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo