Cùng một model, chatbot nhanh gấp ba. Bên trong speculative decoding.

Bạn chạy cùng một model mã mở trên hai nhà cung cấp. Cùng trọng số, cùng prompt, cùng nhiệt độ. Một bên trả chữ ra mượt như nước, bên kia nhỏ giọt. Chênh lệch có thể tới ba lần, và nó không nằm ở model. Nó nằm ở cách token rời khỏi GPU.

Kỹ thuật đứng sau phần lớn khoảng cách đó tên là speculative decoding. Ý tưởng nghe gần như gian lận: cho một model nhỏ và nhanh đoán trước vài token kế tiếp, rồi bắt model lớn kiểm tra cả xâu đoán đó trong đúng một lượt tính. Đoán trúng thì lấy hết. Đoán trật thì cắt tại chỗ trật và sửa. Điểm mấu chốt: luật chấp nhận được thiết kế sao cho phân phối đầu ra không đổi một chút nào so với chạy model lớn thẳng tay. Đây là tốc độ miễn phí, không phải một đánh đổi chất lượng.

Bài gốc là của Yaniv Leviathan, Matan Kalman và Yossi Matias ở Google, công bố cuối năm 2022 và trình bày tại ICML 2023. Trên T5-XXL họ đo được nhanh hơn 2 tới 3 lần, không train lại, không đụng vào kiến trúc. Bốn năm sau, kỹ thuật này là mặc định trong vLLM, trong stack TPU của Google, và là lý do một model Flash trả lời nhanh tới mức khó tin.

Để hiểu vì sao trò đoán trước lại có lãi, phải nhìn vào thứ thật sự tốn thời gian ở bước decode. Trực giác thông thường là GPU đang bận tính toán. Sai. Ở batch nhỏ, GPU đang bận chờ bộ nhớ.

Sinh một token nghĩa là đẩy một vector qua toàn bộ mạng. Muốn làm thế, mọi trọng số của model phải được nạp từ HBM về các đơn vị tính. Với một model 8B ở fp16, đó là khoảng 16GB phải chảy qua bus bộ nhớ, chỉ để đẻ ra một chữ. Phép nhân ma trận thực tế thì bé xíu so với lượng dữ liệu vừa nạp. Các nhân tính toán làm xong việc rồi ngồi không, chờ đợt trọng số kế tiếp.

Đây là chỗ trò đoán ăn tiền. Nếu bạn đưa vào một lượt tính năm token thay vì một, trọng số vẫn chỉ nạp đúng một lần. Phần việc thêm chỉ là ma trận rộng hơn năm cột, thứ mà phần cứng đang rảnh sẵn sàng nuốt. Chính blog kỹ thuật của Google mô tả đúng điều này khi nói về TPU: trên phần cứng cao cấp, thời gian bị chi phối bởi việc nạp trọng số chứ không phải phép toán. Nói cách khác, bốn token kia gần như miễn phí, miễn là bạn có gì đó để đưa vào kiểm tra.

Một vòng speculative decoding có ba nhịp.

Nhịp một, đoán. Model nháp, gọi là drafter, sinh k token kế tiếp theo cách thường. Drafter có thể là một model nhỏ cùng họ, hoặc một đầu dự đoán nhẹ gắn thẳng vào model lớn. Vì nó bé nên k lượt của nó vẫn rẻ hơn một lượt của model lớn.

Nhịp hai, kiểm tra. Model lớn nhận cả prefix lẫn k token nháp và chạy một lượt forward. Nhờ cơ chế nhân quả của attention, một lượt này cho ra phân phối xác suất tại cả k cộng một vị trí, tức là nó vừa chấm điểm mọi token nháp vừa chuẩn bị sẵn token tiếp theo.

Nhịp ba, chấp nhận hoặc từ chối. Đây là phần đẹp nhất. Gọi q là xác suất drafter gán cho token nó vừa đoán, p là xác suất model lớn gán cho chính token đó. Token được nhận với xác suất bằng p chia q, chặn trên ở 1. Nếu bị từ chối tại vị trí thứ i, hệ thống cắt bỏ phần đuôi và lấy một token mới rút từ phân phối hiệu p trừ q, phần âm cắt về 0 rồi chuẩn hoá lại.

Chứng minh trong bài gốc cho thấy quy trình này sinh ra token theo đúng phân phối của model lớn. Không phải xấp xỉ, không phải gần đúng. Nếu drafter đoán ngu, bạn mất công vô ích nhưng kết quả vẫn chuẩn. Nếu drafter đoán giỏi, bạn lấy được nhiều token cho mỗi lượt của model lớn. Và khi cả k token đều được nhận, model lớn tặng thêm một token miễn phí từ vị trí cuối, nên một lượt có thể trả về tới k cộng một token.

Vì mọi thứ dồn vào chuyện đoán trúng hay trật, chỉ số quan trọng nhất không phải TFLOPS mà là acceptance length: trung bình bao nhiêu token được nhận trên mỗi lượt của model lớn. Đó chính là hệ số tăng tốc thô.

EAGLE-3, drafter phổ biến nhất năm 2026, đo được trung bình 2,77 token mỗi lượt trên 11 lĩnh vực của SPEED-Bench. Nhưng con số trung bình giấu mất điều thú vị: nó lệch rất mạnh theo loại nội dung. Code đạt 3,16. Toán 3,12. RAG 3,11. Đa ngôn ngữ 3,07.

Quy luật rất người: những gì dễ đoán thì chạy nhanh. Code đầy cú pháp bắt buộc, dấu đóng ngoặc, tên biến vừa khai báo xong. RAG thì phần lớn câu trả lời là trích lại đoạn văn bản đã nằm sẵn trong context. Ngược lại, một đoạn văn sáng tạo, nhiều lựa chọn từ ngang nhau, sẽ làm drafter trật liên tục và tốc độ tụt về gần mức thường.

Hệ quả thực tế cho người dùng: cùng một hệ thống, tác vụ sinh code hoặc tóm tắt tài liệu sẽ cảm giác nhanh hơn hẳn tác vụ viết nội dung tự do. Đó không phải ảo giác.

Một, đoán theo cây thay vì theo chuỗi. Bản gốc đoán một đường thẳng: nếu token thứ hai trật, ba token sau vứt hết. Tree drafting đưa ra nhiều ứng viên tại mỗi vị trí, tạo thành một cây, rồi dùng tree attention để model lớn kiểm tra tất cả nhánh trong cùng một lượt. Vì lượt kiểm tra gần như miễn phí, thêm nhánh nghĩa là thêm cơ hội trúng mà hầu như không thêm chi phí.

Hai, duyệt cả khối thay vì từng token. Nhóm Ziteng Sun, Uri Mendlovic, Yaniv Leviathan và cộng sự chỉ ra rằng luật chấp nhận từng token một là chưa tối ưu. Block verification duyệt cả khối nháp cùng lúc, và họ chứng minh được nó tối ưu về số token kỳ vọng mỗi vòng, đồng thời không bao giờ tệ hơn cách cũ. Thực đo thêm 5 tới 8 phần trăm wall-clock, không thêm dòng code phức tạp nào, vẫn giữ nguyên tính lossless. Đây là loại cải tiến hiếm: bật lên là có, không cần cân nhắc.

Ba, làm cho việc đoán rẻ đi. Nghịch lý của 2026 là drafter đã trở thành nút thắt mới. EAGLE-3 gọi drafter một cách tuần tự, và các lượt đó ngốn khoảng 30 phần trăm độ trễ. SpecBlock, công bố tháng 5 năm 2026, cho drafter đẻ 4 token phụ thuộc nhau trong một lượt duy nhất, đồng thời dùng một đầu xếp hạng để phân bổ độ rộng nhánh theo từng vị trí thay vì cắt top-k cứng. Kết quả: nhanh hơn EAGLE-3 từ 8 tới 13 phần trăm trong khi chỉ tốn 44 tới 52 phần trăm chi phí drafting, kéo thời gian đoán từ khoảng 17ms xuống khoảng 7ms trên model đích cỡ 8B. Bên vLLM, P-EAGLE đi hướng song song hoá và báo cáo nhanh hơn EAGLE-3 gốc tới 1,69 lần.

Phía TPU, con số còn mạnh hơn. Trong bài đo tháng 5 năm 2026 của Google trên TPU v5p với Llama-3.1-8B, cách nháp kiểu diffusion đạt trung bình nhanh hơn 3,13 lần trên toàn bộ dataset, và trên tập toán math500 thời gian sinh mỗi token rơi từ 8,02ms xuống 1,40ms. Khi so trực tiếp trong điều kiện serving, cách này đạt 2,29 lần còn EAGLE-3 đạt 1,30 lần.

Tại I/O 2026, Google nói thẳng rằng block verification và tree-structured drafting, cài đặt tối ưu cho kiến trúc TPU, chính là thứ tạo ra tốc độ hiện tại của Gemini 3.5 Flash. Model đó đang chạy ở mức trên 280 token đầu ra mỗi giây, nhanh tới mức nhiều người tưởng nó là một model nhỏ hơn thực tế.

Toàn bộ lập luận miễn phí dựa trên một giả định: GPU đang rảnh tính toán vì kẹt băng thông bộ nhớ. Giả định đó đúng khi phục vụ ít request cùng lúc. Khi bạn nhồi hàng chục request vào một batch, GPU đã bận thật, và mỗi token nháp bị từ chối trở thành phép tính vứt đi. Số liệu của EAGLE 3.1 trên Kimi K2.6 cho thấy rõ đường cong này: nhanh hơn 2,03 lần khi phục vụ một người, còn 1,71 lần ở bốn, và 1,66 lần ở mười sáu.

Chi phí thứ hai là bộ nhớ. Drafter phải nằm cùng chỗ với model lớn, ăn thêm VRAM và thêm một KV cache riêng. Với GPU đã chật, phần VRAM đó có thể đáng giá hơn nếu dùng để tăng batch.

Chi phí thứ ba ít ai nói: drafter phải hợp với model đích. Một drafter luyện trên hội thoại tiếng Anh đem đi đoán cho tác vụ sinh SQL tiếng Việt sẽ trật liên tục, acceptance length tụt về gần 1, và bạn trả tiền cho phần nháp mà không nhận lại gì. Đây là lý do các bản EAGLE được huấn luyện riêng cho từng model đích.

Cuối cùng, hãy đọc kỹ chữ lossless. Một số biến thể phổ biến nới lỏng luật chấp nhận để nhận nhiều token hơn, và khi làm thế thì phân phối đầu ra không còn giống bản gốc nữa. Chúng vẫn hữu ích, nhưng đó là một quyết định sản phẩm, không phải một tối ưu thuần kỹ thuật. Nếu nhà cung cấp quảng cáo tốc độ mà không nói rõ luật chấp nhận, đó là câu đáng hỏi lại.

Bài học lớn nhất cho người chọn công cụ năm 2026: khi bạn đo hai nhà cung cấp trên cùng một model mã mở và thấy chênh lệch tốc độ, rất có thể bạn không đang đo model. Bạn đang đo drafter của họ, luật duyệt của họ, và mức batch họ đang chạy.

Điều đó cũng đổi cách đọc bảng giá. Speculative decoding không làm model thông minh hơn, nó chỉ làm mỗi lượt tính đắt tiền của GPU sinh ra nhiều chữ hơn. Vì phân phối đầu ra giữ nguyên, chi phí mỗi token giảm mà không có ô nào trong bảng chất lượng bị đánh đổi. Đó là loại tối ưu hiếm hoi trong ngành này.

Và nếu bạn đang tự dựng hệ thống phục vụ model, thứ tự ưu tiên khá rõ. Bật speculative decoding trước, vì nó là mức tăng lớn nhất cho công sức bỏ ra. Bật block verification vì nó không bao giờ tệ hơn. Rồi mới tính tới việc luyện một drafter riêng cho đúng loại nội dung mà người dùng của bạn thật sự gõ vào.