5.4 Biên lợi ích của speculative decoding

“Tỉ lệ chấp nhận bản nháp 80%, chắc chắn nhanh hơn?” Đó là hiểu nhầm phổ biến nhất về speculative decoding. Tỉ lệ chấp nhận chỉ nói đoán có trúng không; không nói đoán một lần mất bao lâu, nghiệm thu một đoạn tốn bao nhiêu tính, cache thừa đã đẩy bao nhiêu request ra. Mỗi vòng commit nhiều Token hơn, mỗi vòng cũng lâu hơn — chia hai cái mới ra lợi ích thật.

Mục này trước hết dùng một sổ đơn giản suy ra điều kiện tăng tốc, rồi lần lượt đưa đồng thời, ngữ cảnh dài, lượng hóa, lịch và streaming vào. Mục tiêu không phải một “độ dài speculative tối ưu” phổ quát, mà để bạn giải thích được: vì sao bộ điều kiện này nhanh hơn, đổi bộ khác thì không đáng.

⏰ Độ mới của thông tin: công thức suy luận không phụ thuộc framework; gợi ý, tham số và giới hạn liên quan vLLM dựa trên tài liệu v0.32.0 (phát hành 2026-10-18). Định nghĩa tỉ lệ chấp nhận và độ dài chấp nhận trung bình ở mục 5.2 mục 7.

📑 Mục lục

• 1. Định nghĩa lợi ích trước: một vòng commit bao nhiêu Token
• 2. Sổ hiệu năng: suy điều kiện tăng tốc từ tiền tố được chấp nhận
• 3. Độ dài speculative: đoán thêm khi nào thành lãng phí
• 4. Code và hội thoại: nhãn tác vụ không phải kết luận hiệu năng
• 5. Đồng thời cao và ngữ cảnh dài: sức tính dư thay đổi
• 6. Chồng với lượng hóa: trước hết chốt chuẩn đúng
• 7. Lịch và streaming: sau khi mỗi lần tiến dài hơn
• 8. Thực hành tính sổ và ngưỡng triển khai
• Tóm tắt
• Checklist tự kiểm
• Tài liệu tham khảo

---

1. Định nghĩa lợi ích trước: một vòng commit bao nhiêu Token

Một vòng đề xuất $\gamma$ ứng viên. Gọi $K\in\{0,\ldots,\gamma\}$ là độ dài tiền tố được chấp nhận liên tục. Khi không bị EOS hoặc trần độ dài cắt, số Token commit vòng này là:

$$L=K+1$$

Số 1 thêm vào là Token sửa ở vị trí từ chối đầu tiên, hoặc Token thưởng sau khi chấp nhận hết. Vì vậy dù không ứng viên nào qua, vòng này vẫn tiến được một bước.

📌 Điểm then chốt: “ít nhất tiến một Token” là bảo đảm tiến độ, không phải bảo đảm hiệu năng. Một vòng thất bại toàn phần tốn thời gian Draft cộng nghiệm thu mà chỉ đổi lấy một bước Decode thường.

---

2. Sổ hiệu năng: suy điều kiện tăng tốc từ tiền tố được chấp nhận

2.1 Độ dài commit kỳ vọng

Với $K$ số nguyên không âm, có đồng nhất thức xác suất đuôi:

$$\mathbb E[L]=1+\sum_{i=1}^{\gamma}\Pr(K\ge i)$$

Gọi $a_i$ là xác suất có điều kiện “đã chấp nhận $i-1$ cái đầu thì cái thứ $i$ cũng được chấp nhận”. Theo quy tắc chuỗi:

$$\Pr(K\ge i)=\prod_{j=1}^{i}a_j$$

Bước này không cần giả sử các vị trí độc lập. Nếu đơn giản hóa thêm mọi $a_i$ bằng cùng một $a$:

$$\mathbb E[L]=1+a+a^2+\cdots+a^\gamma=\frac{1-a^{\gamma+1}}{1-a}\quad(a\ne1)$$

Khi $a=1$ lấy giới hạn $\gamma+1$. Phương án độ dài động và dạng cây mỗi vòng số ứng viên khác nhau; dùng thẳng độ dài chấp nhận trung bình đo được $1+C/R$.

2.2 Mẫu số là cả một vòng đầy đủ

Gọi thời gian trung bình mỗi Token của Decode thường là $T_0$, thời gian trung bình một vòng speculative là:

$$T_{\text{round}}=T_{\text{draft}}+T_{\text{verify}}+T_{\text{other}}$$

$T_{\text{other}}$ gồm sampling, bảo trì cache, đồng bộ CPU/GPU và lịch. Dưới điều kiện đơn giản hóa một request, Decode ổn định, bỏ vòng biên đầu/cuối, tỉ lệ tăng tốc:

$$S\approx\frac{T_0\cdot\mathbb E[L]}{\mathbb E[T_{\text{round}}]}$$

Muốn nhanh hơn phải thỏa $\mathbb E[T_{\text{round}}]<T_0\cdot\mathbb E[L]$: thời gian một vòng phải ít hơn Decode thường sinh cùng số Token. Khi đo dùng “tổng Token đã commit / tổng thời gian”; đừng lấy trung bình số học tỉ lệ tốc độ từng vòng.

2.3 Nghiệm thu không miễn phí

Nghiệm thu $\gamma+1$ vị trí một lần có thể tái sử dụng cùng một lần đọc trọng số, nâng arithmetic intensity. Nhưng lượng tính, Attention, ghi KV ứng viên và xử lý Logits đều tăng theo số vị trí. Batch nhỏ thì $T_{\text{verify}}$ gần $T_0$; ứng viên dài, Batch lớn hoặc ngữ cảnh dài thì nó vượt rõ $T_0$.

Vẫn ví dụ biên tập viên: duyệt một đoạn nhanh hơn tự viết, nhưng duyệt mười trang không thể bằng duyệt một câu — thời gian trợ lý viết cũng phải tính.

---

3. Độ dài speculative: đoán thêm khi nào thành lãng phí

Trong mô hình đơn giản $a$ cố định, tăng ứng viên từ $\gamma$ lên $\gamma+1$ chỉ tăng độ dài commit kỳ vọng thêm:

$$\Delta\mathbb E[L]=a^{\gamma+1}$$

Càng về sau, cơ hội mọi vị trí trước đều qua càng nhỏ. Với $a=0.8$, ứng viên thứ 1 mang lại 0.8 Token kỳ vọng; thứ 8 chỉ khoảng 0.168. Chi phí Draft và nghiệm thu mỗi vị trí thêm không giảm theo đó, nên sau một độ dài nào đó đoán thêm là lỗ ròng.

3.1 Độ sâu và độ rộng là hai ngân sách

Speculative dạng chuỗi chỉ chỉnh độ sâu; phương án cây (mục 5.3) còn chỉnh số nhánh mỗi tầng. Cây càng rộng, cơ hội tìm đường chấp nhận được càng lớn, nhưng nút không được chọn cũng phải tính hết. Vì vậy chỉ báo “độ sâu speculative 4” chưa đủ — còn phải báo mỗi vòng thực sự nghiệm thu bao nhiêu nút.

3.2 Độ dài động: điều chỉnh theo tải

Độ dài tối ưu đổi theo tải. Dynamic Speculative Decoding của vLLM dùng num_speculative_tokens_per_batch_size đặt độ dài theo dải đồng thời, ví dụ [[1, 64, 3], [65, 128, 1], [129, 512, 0]] nghĩa là đồng thời 1–64 đoán 3, 65–128 đoán 1, từ 129 trở lên không speculative. Lý do tài liệu đưa: Batch $B$, mỗi request đoán $\gamma$ ứng viên thì Batch nghiệm thu hiệu dụng khoảng $B\times\gamma$; quá một ngưỡng sẽ kéo chậm TPOT.

Trong v0.32.0 tính năng này đã đo trên EAGLE, EAGLE-3 và DFlash; bật Data Parallel thì tự lui về độ dài cố định. Còn Adaptive Verification quyết định độ dài nghiệm thu từng request, hỗ trợ các phương án bản nháp dựa mô hình như EAGLE, MTP, DFlash, DSpark và Draft độc lập: DSpark dùng đầu độ tin cậy sẵn có; các phương án còn lại dùng xác suất chấp nhận ước lượng online. Nó yêu cầu CUDA Graph đầy đủ, không hỗ trợ LoRA và Pipeline Parallel.

Chiến lược tốt tối ưu “mỗi đơn vị thời gian tiến bao nhiêu đầu ra đạt chuẩn”, không đơn độc đẩy tỉ lệ chấp nhận lên cao nhất.

---

4. Code và hội thoại: nhãn tác vụ không phải kết luận hiệu năng

“Code tỉ lệ chấp nhận cao, hội thoại mở lợi ích hạn chế” là kinh nghiệm phổ biến, nhưng thứ thật sự có tác dụng là mức lặp lại lịch sử và khớp phân phối:

Nhiệt độ, Top-p, cách alignment của mô hình và phân phối Prompt đều ảnh hưởng chấp nhận. Một đề “chép nguyên code” không đại diện mọi tác vụ code; một đề sáng tạo nhiệt độ cao cũng không đại diện mọi hội thoại.

⚠️ Lưu ý: Benchmark Token ngẫu nhiên hợp để khống chế biến hiệu năng, nhưng không có cấu trúc lặp của nghiệp vụ thật. Muốn đánh giá lợi ích thực của N-gram/Suffix phải dùng Prompt thật.

---

5. Đồng thời cao và ngữ cảnh dài: sức tính dư thay đổi

5.1 Continuous Batching đã ăn bớt một phần nhàn

Đồng thời thấp mỗi bước chỉ xử lý ít request; đơn vị tính của Target phần lớn nhàn, speculative đúng lúc dùng phần đó. Đồng thời tăng, Continuous Batching để một lần đọc trọng số phục vụ nhiều request hơn — Decode thường tự lấp đầy sức tính.

Lúc đó thêm ứng viên chuyển từ “dùng sức tính nhàn” sang “tranh sức tính với request khác”. Tài liệu vLLM cũng định vị speculative decoding là giảm độ trễ giữa Token ở kịch bản QPS trung/thấp, bị giới hạn băng thông bộ nhớ. Bảng chọn phương pháp đưa đánh giá định tính: EAGLE, MTP lợi ích cao ở QPS thấp, trung đến cao ở QPS cao; N-gram và Suffix lợi ích thấp đến trung ở QPS thấp, trung ở QPS cao. Đầu tài liệu còn nói các phương pháp đơn giản này tăng tốc hạn chế nhưng không tăng tải lúc cao điểm.

Đồng thời cao cũng không nhất định vô hiệu: Draft chính xác hơn, bản nháp song song và Kernel phù hợp vẫn có thể giữ lợi ích. Nên vẽ đường cong theo tải, đừng phủ nhận hết bằng một kinh nghiệm.

5.2 Ngữ cảnh dài tăng đọc/ghi và trạng thái tạm

Ngữ cảnh càng dài, Attention mỗi vị trí nghiệm thu càng đắt, ứng viên cũng chiếm thêm KV; cache riêng của Draft độc lập cũng tăng theo ngữ cảnh. Batch có $B$ request, mỗi cái dành khoảng $\gamma$ vị trí ứng viên, bậc thô của KV Target thêm là:

$$M_{\text{candidate}}\approx B\cdot\gamma\cdot m_{\text{KV/token}}$$

Ước lượng này bỏ qua làm tròn trang, slot lookahead, tiền tố chia sẻ và bố cục cây — chỉ để chỉ ra hạng mục thừa. Dung lượng thực lấy theo log engine.

5.3 Preempt có thể ăn mất lợi ích trên giấy

Trọng số Draft và cache tạm giảm không gian KV khả dụng, có thể kích hoạt thêm preempt và recompute, hoặc khiến engine nhận ít request hơn. Một vòng nghiệm thu nhanh hơn mà cả request hoàn thành chậm hơn không mâu thuẫn.

Vì vậy khi ghi độ dài chấp nhận, hãy ghi cùng dung lượng KV, số lần preempt, số request thành công và throughput thực.

---

6. Chồng với lượng hóa: trước hết chốt chuẩn đúng

6.1 Lượng hóa Draft và lượng hóa Target là hai chuyện

• Chỉ lượng hóa Draft: thay đổi phân phối đề xuất $q$. Theo chứng minh mục 5.1, đầu ra cuối vẫn là $p$ của Target chưa lượng hóa; chỉ đổi tốc độ và tỉ lệ chấp nhận.
• Lượng hóa Target: chuẩn nghiệm thu thành $p_{\text{quant}}$. Speculative decoding bảo đảm nhất quán với mô hình đã lượng hóa; không khôi phục độ chính xác gốc.
• Nghiệm thu xấp xỉ + lượng hóa: hai thay đổi chồng lên nhau; đánh giá chất lượng riêng.

Module như EAGLE, MTP đọc đặc trưng Target đã thấy đặc trưng độ chính xác gốc lúc huấn luyện. Target đổi phương án lượng hóa thì phân phối đặc trưng đổi theo; tỉ lệ chấp nhận có thể giảm — phải đo lại. Ghi chú phát hành v0.32.0 có một bản sửa cho tỉ lệ chấp nhận Draft = 0% trên checkpoint NVFP4 dòng DeepSeek-V4. Tổ hợp kiểu đó đáng kiểm riêng.

6.2 Tỉ lệ tăng tốc không nhân trực tiếp

Lượng hóa và speculative đều giảm nút thắt băng thông bộ nhớ của Decode. Lượng hóa giảm lượng đọc trọng số Target, nên tính nghiệm thu trước đó bị băng thông che có thể lộ rõ hơn; đồng thời nó cũng giải phóng GPU memory, chừa chỗ cho nhiều ứng viên và request hơn.

Vì vậy “lượng hóa nhanh 1.5 lần, speculative nhanh 2 lần” không suy ra tổ hợp nhanh 3 lần. Phải đo riêng baseline gốc, chỉ lượng hóa, chỉ speculative và tổ hợp, và ghi rõ chuẩn chất lượng từng cái.

📌 Điểm then chốt: Sổ độ chính xác chương 4 và bảo đảm sampling chương 5 phải căn trên cùng một Target rồi mới nói lợi ích tổ hợp.

---

7. Lịch và streaming: sau khi mỗi lần tiến dài hơn

7.1 Scheduler phải quản nhiều hơn một vị trí mới

Bật speculative xong, mỗi bước engine dành chỗ cho ứng viên, phân ngân sách Token, rồi cập nhật tiến độ thật của từng request theo kết quả chấp nhận. Trong cùng một Batch, số ứng viên, độ dài chấp nhận và hạn mức đầu ra còn lại của các request có thể khác nhau.

Nửa trên hình là một vòng của scheduler; nửa dưới là trạng thái ba request cùng Batch khi vòng kết thúc (ô xanh lá = ứng viên chấp nhận, ô xanh dương = Token Target bổ sung, ô xám nét đứt = slot KV bị rollback):

Đường này tương tác với Continuous Batching, Chunked Prefill, hình dạng cố định của CUDA Graph và lịch bất đồng bộ. Ví dụ Dynamic SD trong v0.32.0 chỉ V2 Model Runner hỗ trợ CUDA Graph đầy đủ. Tổ hợp nào dùng được lấy theo tài liệu và log khởi động của phiên bản bạn dùng.

7.2 TPOT nhỏ hơn, chữ ra chưa chắc đều hơn

Một lần nghiệm thu speculative có thể trả vài Token, vòng sau lại phải chờ một lúc — người dùng thấy streaming giống “nhảy từng đoạn”.

• TPOT: sau Token đầu, thời gian trung bình mỗi Token.
• ITL / khoảng streaming: khoảng dừng giữa hai lần trả liền nhau. Một chunk có thể chứa nhiều Token; không đồng nhất với thời gian một Token.
• TTFT: gồm xếp hàng và Prefill; giảm số vòng Decode giúp ít.

Đánh giá phải nhìn cùng TTFT, TPOT, khoảng dừng streaming và thời gian end-to-end. Kịch bản tương tác thời gian thực còn cần P95/P99 và khoảng dừng dài nhất nghiệp vụ chấp nhận được.

7.3 Điều kiện dừng và đầu ra có cấu trúc phải có hiệu lực kịp

Nếu tiền tố chấp nhận xuất hiện EOS, Stop String hoặc chạm trần đầu ra, chỉ commit phần trước điểm kết. Ràng buộc có trạng thái như structured output, Tool Calling cũng phải cập nhật theo từng tiền tố ứng viên; num_draft_tokens trong chỉ số từng request của vLLM đã trừ các ứng viên bị ràng buộc structured output hủy sớm.

Khi gặp vấn đề, trước hết để sinh thường và cấu hình speculative đơn giản nhất chạy thông, rồi thêm tính năng từng cái, dễ khoanh bước nào đổi tính đúng hoặc hiệu năng.

---

8. Thực hành tính sổ và ngưỡng triển khai

8.1 Chấp nhận giống nhau, mẫu số có thể hoàn toàn khác

Dưới đây là mô hình chi phí giả định chỉ dùng thư viện chuẩn. Hằng số thời gian chỉ để minh họa — không tương ứng GPU hay mô hình thật nào.

def expected_length(conditional_acceptance):
    """E[L] = 1 + Σ Pr(K >= i); đầu vào là xác suất chấp nhận có điều kiện a_i từng vị trí."""
    survival, total = 1.0, 1.0
    for a in conditional_acceptance:
        assert 0 <= a <= 1
        survival *= a
        total += survival
    return total


base_ms = 10.0  # giả sử Decode thường 10 ms mỗi Token
print(f"{'γ':>2} {'E[L]':>6} {'bản nháp rẻ':>8} {'bản nháp đắt':>8}")
for gamma in [1, 2, 4, 8]:
    length = expected_length([0.8] * gamma)
    cheap_round = 10 + 0.7 * gamma + 0.1 * gamma ** 2  # bản nháp nhanh, nghiệm thu tăng chậm
    costly_round = 10 + 5.0 * gamma + 0.8 * gamma ** 2  # bản nháp chậm, nghiệm thu tăng nhanh
    print(f"{gamma:>2} {length:>6.3f} "
          f"{base_ms * length / cheap_round:>8.3f} "
          f"{base_ms * length / costly_round:>8.3f}")

assert expected_length([0.0] * 4) == 1
assert expected_length([1.0] * 4) == 5

Hai phương án có cùng xác suất chấp nhận có điều kiện: cái rẻ đạt khoảng 2.3 lần ở $\gamma=4$ rồi tụt ở $\gamma=8$; cái đắt chỉ hơi nhanh khi $\gamma\le2$, từ $\gamma=4$ đã chậm hơn Decode thường. Thí nghiệm thật thì thay hai hàm chi phí giả bằng thời gian vòng và thống kê commit đo được.

8.2 Bốn ngưỡng trước khi lên production

Khi độ dài chấp nhận trung bình tăng, thời gian vòng cũng dài, mà TPOT không cải — khoanh lần lượt Draft, nghiệm thu, sampling và bảo trì cache. Nếu chỉ tốt khi không tải, đo lại ở tải mục tiêu rồi quyết có bật theo kịch bản hay giao Dynamic SD tự hạ cấp.

---

📝 Tóm tắt

• Độ dài commit mỗi vòng là tiền tố chấp nhận liên tục cộng 1; vòng biên có thể bị điều kiện dừng cắt.
• $\mathbb E[L]=1+\sum_i\Pr(K\ge i)$ không yêu cầu vị trí độc lập; xác suất chấp nhận có điều kiện $a$ cố định chỉ là mô hình đơn giản hóa.
• Điều kiện tăng tốc là thời gian cả vòng thấp hơn Decode thường sinh cùng số Token.
• Ứng viên thứ $\gamma+1$ chỉ mang thêm $a^{\gamma+1}$ Token kỳ vọng — lợi ích giảm dần; độ rộng cây cũng có chi phí.
• Dynamic SD chỉnh độ dài speculative theo dải đồng thời; đồng thời cao có thể tự giảm hoặc tắt speculative.
• Code và hội thoại chỉ là nhóm thí nghiệm; cấu trúc lặp và khớp phân phối mới giải thích khác biệt.
• Đồng thời cao, ngữ cảnh dài và preempt đổi sức tính nhàn và ngân sách bộ nhớ; vLLM định vị speculative ở QPS trung/thấp.
• Lượng hóa Draft không đổi chuẩn đầu ra; lượng hóa Target thì có; hai tỉ lệ tăng tốc không nhân trực tiếp.
• TPOT, khoảng dừng streaming, dung lượng và chất lượng nghiệp vụ cùng quyết định có triển khai không.

🎯 Checklist tự kiểm

• Suy được độ dài commit kỳ vọng từ tiền tố chấp nhận liên tục
• Giải thích vì sao nhân chuỗi xác suất chấp nhận có điều kiện không cần giả sử độc lập
• Viết được điều kiện tăng tốc gồm Draft, nghiệm thu và overhead khác
• Dùng $a^{\gamma+1}$ giải thích lợi ích giảm dần theo độ dài speculative
• Viết được cấu hình num_speculative_tokens_per_batch_size phân dải theo đồng thời cho vLLM và giải thích căn cứ
• Giải thích vì sao Prompt ngẫu nhiên không đủ để đánh giá N-gram/Suffix
• Phân tích đồng thời cao, ngữ cảnh dài và preempt ăn lợi ích speculative thế nào
• Phân biệt lượng hóa Draft và lượng hóa Target đối với chuẩn đầu ra
• Giải thích vì sao TPOT tốt hơn không bảo đảm khoảng dừng streaming tốt hơn
• Ra quyết định triển khai theo bốn ngưỡng: tính đúng, chất lượng, độ trễ, dung lượng

📚 Tài liệu tham khảo

• Fast Inference from Transformers via Speculative Decoding (Leviathan et al., 2023)
• Accelerating Large Language Model Decoding with Speculative Sampling (Chen et al., 2023)
• vLLM — Speculative Decoding (bảng chọn phương pháp)
• vLLM — Dynamic Speculative Decoding
• vLLM — Adaptive Verification
• vLLM — Per-Request Acceptance Metrics
• vLLM v0.32.0 Release Notes
• vLLM v0.32.0 — V1 Scheduler